107 comments

[ 2.9 ms ] story [ 159 ms ] thread
I built this to scratch my own itch, as somebody who frequently reads GitHub code and feels annoyed having to click countless of links to navigate through a large project. Hope it is useful for other people too.
OMG thank you! I have so many cloned repos somewhere on my disk, just to browse the code. Now it's time to implement super-fast-github-git-grep.js --- my productivity will explode.
I would put $5 toward a github public repo grep
You are super awesome, I'm poor but somebody should throw money at you.
Mad props. Any chance of a Safari port? Its extension system is not very different from Chrome's. EDIT: and you shouldn't be shy to plug your gittip page: https://www.gittip.com/buunguyen/
Thanks. You're right, Safari port shouldn't require much change. Let me nail the Chrome version first, there are a number of issues reported in the project page that I want to take a look.

Also thanks for featuring my gittip page, I almost forgot I had one.

This will save countless electrons that might otherwise have been displaced while opening many new tabs to view the source files.
And very well scratched sir. I enjoy flitting about github repo's and it's a pain to have to pull every repo I want to have a gander at.
This is incredible. Thank you.
Brilliant - it's often quite slow to change between directories in the web view, this is blazingly fast. Especially useful for deeply nested (templated) projects.
I'd love to see a setting that makes the tree view collapsed by default. If I have some time later I might whip up a pull req.
The tree should already be collapsed by the default (or it's a bug). However, the extension remembers the selection state, so if you expand some folders, you will see them remained expanded the next time you visit the same repository. Is there any chance you talked about this scenario?
I meant the entire left pane collapsed by default. Right now on page load it automatically pops out.

edit: looks like I'm insane. working as you described it. nice job!

If you toggle it off (by clicking the small hamburger icon at the bottom-left corner), it should remained hidden even if you navigate to other repositories. The only exception is when it needs to prompt for the personal access token (to access private repositories or deal with GitHub API limit). Is it not the behavior you're observing or expecting?
I've been using Firefox almost exclusively for months. This may very well make me go back to Chrome. Looks amazing!
Would love to see a Firefox port.
It doesn't seems to be using any Chrome api, so porting it to the Firefox SDK should be a trivial matter.

See https://gist.github.com/Spittie/93adf218040d470abd40 (http://81.4.126.121/i/1400019350.png), probably the hardest part is "fixing" the css if it's using some only webkit- feature. Also I'm not sure if it's possible to load local images withing the page-mod api, but embedding them as base64 images is easy enough.

EDIT: oh well, Enjoy: https://github.com/Spittie/octotree No pull-requests because I've moved pretty much everything to make it working. The right way would probably be to use some build system, but who has time for that? :)

Wow, that's fast, thanks a lot. Let me see if I can roll out a build script and merge your code (as well as the Safari fork made by another person).
If you do, that would be awesome, considering that I'm too lazy to maintain the firefox version for a lot of time :)

Not that I did change a lot of stuff, but with everything in a different folder I can't just git pull from your repository.

And thanks for the great extension!

Done. I've added a build script to generate structures for Chrome, Firefox and Safari. The prebuilt packages for Firefox and Safari are here: https://github.com/buunguyen/octotree/tree/master/dist. Thanks again for the direction.
That was fast! I can't edit my old comment, but I've changed the readme to point to your repository. When this thread die, I'll delete it.
I was also looking for a port for Firefox as well, since I've been switching to it for a while now. Thanks a lot!
Is there a way to use this for Github Enterprise repos?
You would just have to switch out https://api.github.com/ with https://{Your company's Github Enterprise location}/api/v3/
Do you know if GitHub Enterprise imposes an API limit for unauthenticated requests? If it does, does it support personal access token? (See https://github.com/buunguyen/octotree#github-api-rate-limit.)

Depending on the answers, it could be very simple change, i.e. allow users to configure API subdomain. Unfortunately, I don't have any GitHub Enterprise deployment in handy at this moment to find out.

> If it does, does it support personal access token?

Yes, it does support tokens.

Thanks for confirming. Then it should be straightforward to support. I'll hope to have access to a Enterprise deployment to test out.
Thank you! That's solved my immediate problem. Now to refactor so that we can dynamically determine the URL based on the current path...
Fantastic! You planning to add Bitbucket support? That would be really nice. :)
+1 I'd also use bitbucket supported version of this
Good idea. Having nicer icons and align the icon with the text would even more awesome.
Wow, giving it a quick try I can't believe how fast it is. This is one of those things that I've always desperately needed, and I never knew until now.

Be sure to tweet it at some of the github engineers– Thy should bring this into their core product.

To me, the lack a fast tree browser has been one of the biggest weakness of the Github interface. This plugin solves that problem exceeding well. Github should hire the author, and officially fund his efforts to make it a first class feature that does not require a plugin.
Honest question: What is this good for? I guess I don't use github (or any other visual vcs) enough.. but I really can't see any point in browsing file structure of the repo in a web browser.
It seems like you are getting down-voted but I'm very curios about this as well. It has always seemed to me that the tree browser was very inefficient way of browsing a file structure especially if you get into the realm of deep directories and long file names.
A directory tree may not be the most optimal solution, but it's easier to browse than the default github view...
Personally I use it when trying to view past changes and understand what the state of the repo was at that particular moment.

Frankly, right now I just have a hard time remembering what path I was going down with the current process of traversing the file structure.

It's good for when you want to browse a code base written in Java due to the deep folder hierarchies. And the reason somebody might do that is that they might be choosing between several different libraries, and want to evaluate the quality of their code a little before downloading them.
I browse repos on github pretty frequently. Some use cases:

- It's someone else's repo (eg, a gem I'm using), and I just want to see one line real quick, rather than cloning the whole project locally and finding it there.

- It's my repo, but I my local working copy is on a different branch or has uncommitted changes, so I don't want to bother stashing + changing branches just to look up one line

- I'm poking around several repos that I have no intention of using- eg, looking at an interview candidate's public repos

For the "my repo, wrong branch" use case, you have some options:

  git show other-branch:path/to/file
or:

  git grep -e pattern other-branch
git-grep is indescribably awesome. To be fair though, I search github pretty frequently because it means I can search issues also. If issues were git repos themselves it would be a different ballgame.
I am not a Java hater, but any Java or Scala repo has a very deep tree. Clicking down and refresh page is not fun. Also consider when you want to open multiple files which are on different levels of the tree. Without the tree ready you would go back and forth between pages or having multiple new tabs opened to open each file.
For me, the biggest issue was lack of syntax highlight on pull requests. I've created this Chrome extension to fix it: https://chrome.google.com/webstore/detail/gh-diff-highlight/...

Contributions[1] are welcomed :)

[1] https://github.com/danielribeiro/github-diff-highlight-exten...

protip: you can press 't' when you're in the repo for Sublime-like search for files -- which I find more useful than a tree browser
I find that feature useful when I am already familiar with a code base. However, when I am spelunking unfamiliar code bases, a good tree browser would make the effort quicker (e.g. speeding conventions directory hierarchies to get to the meat of the implementation). Since I find myself performing such discovery fairly often, I see this extension being a real time saver.
do you know that you can press T on a repo page and get a nice fuzzy search? i find it much more efficient than clicking through a tree.
Search will never be a substitute for hierarchical organization of information in all cases. Imagine if the taxonomic tree of life was abandoned in favor of a fuzzy search on organism attributes. Sometimes the relationships between conceptual elements, whether files or organism, are more important than a fuzzy key word.

For this reason I detest the Windows 7 start menu for its anti-organization UI, for example.

What about enterprise GitHub support?
(comment deleted)
You can also press `t` on any repo on github to find files/filetypes quickly.
I use 't' all the time to look up files as well.

I guess this extension makes it easier to get an overview of the directory structure, but that's something I rarely need.

I'm sceptical of browser plugins in general. There are so many browser plugins that change under the hood and do malicious things. It would be easy for the author of this plugin to scrape all your source code and phone it home.

I understand the concern. This extension is open-source/MIT [1], hope that brings a little peace of mind. If not, you can just pack the extension from its source instead of installing from Chrome Store.

[1] https://github.com/buunguyen/octotree

Find files is certainly useful for coding, not so much exploring. I would have no idea what to search for when exploring a new repo. Besides, even when coding with IDEs with find-files feature, I mostly navigate using the tree. Guess I like tree view :).
I'd love to see something like this being on the site by default. Maybe just a button next to the repository title where you'd be able to toggle between the current view and the tree view. Both of these options have their advantages for different use cases.

In the meantime that's a great solution. Thanks!

This is a fantastic extension! Browsing is fast and efficient, and creating the token for my private repos was painless.

A "search for files/folders named ..." feature would be a nice bonus, too, so that you can quickly get to the right spot in a big hierarchy.

To the author (https://twitter.com/buunguyen): please add a donation link somewhere so I can send you a thank-you (or you can just e-mail me with your PayPal/other address; my e-mail's in my profile).

Adding a private token took a few seconds - just a little irritating. It links to a Readme, which then links to the page to get your token

Instead, why doesn't the plugin just link directly to the page which generates the token if it detects that the repo is private?

Actually there are 2 links, the one named "Create token" goes directly to the token generation page. The "Help" link goes to Readme just in case people wonder why they have to enter the token. I guess you clicked on the "Help" link instead of "Create Token" link?
A "search for files/folders named ..." feature already exists on GitHub. Just press "t".
Is there an easy way to extend this so that it can also be used when accessing Enterprise Github installations, e.g. `github.mycompany.com`?
A couple of people have asked for this in comments (and someone reported it on GitHub as well). I don't have a deployment handy so it's hard to build out. I hope someone can submit a PR. (Or wait until I can get a deployment to build/test.)
I've started poking around at it, in hopes of making a PR, but feel like I am making poor progress. It was trivial to change some things (like linking to /settings/tokens/new instead of including the hostname), but then my API key won't work.

I suspect that our enterprise installation uses a different API version than the live Github site, as I am having a hard time figuring out what an error 406 (vs the ones you catch) means. (And, the tree that I get is undefined.)

I'm surely doing something wrong. (I had hacked up the github.js library to use `github.ourcompany.com` for its API domain, which is probably wrong.) I will have to look for more info on API access to enterprise instances, because this is a feature which would make reading our various codebases __much__ more convenient.

Thank you for such an inspiring plugin!

should be something like: http(s)://github.ourcompany.com/api/v3
This is seriously excellent.

I bet Github have had this feature on their issue tracker for years - and I suspect it probably just got bumped a good few places up the list.