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.
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.
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.
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.
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
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.
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 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.
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.
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.
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.
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.
Here's an idea: Automatically expand all the tree until there are more than 1 items in the level
e.g. src->com->twitter->scalding->scala->test (in this example, these are all folders in hierarchy and they are the only one until the 'test' so expanding them automatically all the way through makes sense).
That's a good idea, those 'fake' Java directories can be displayed collapsed inline as a single node of the hierarchy, thus saving all their indent space.
Great work but i want to point out one small feature that Github has but not known to everyone.
Press 't' when you go to a repository, it will activate the file finder. From there you can just start typing for the file/folder name you want to see and it will filter the repo instantly.
Reasonable point you got there. Since I am mostly working on the repos that i am involved, it becomes very handy for me. I agree that it may not be so useful for unknown repos to explore.
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 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.
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?
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?
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).
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?
This is great. It would be even better if you could resize the tree. Some projects have really deep trees and at a certain point you can't seem the names of the files.
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.
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.
I had the same idea a couple weeks ago but never finished it: https://github.com/Gowiem/GitHubTree. Crazy to see this. Glad somebody got around to it. Thanks man!
I don't really find the tree view useful. But I wish there was a way to see the code weight by individual files and whole repos: as KLOCS, size, anything. Is there such an extension?
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.
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.
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? :)
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.
Great extension, except in private repos, every time I click on a file (from github proper) the extension animates outward while telling me that it doesn't work with private repos. Extremely annoying and resulted in uninstall :(
edit: i'm not willing to give extension access to private repos, that would defeat the point of being private
Private repos require your authorization. I guess you'll be more frustrated if I could code up something to access your private repos without your authorization, won't you? The instructions to create and set the token is here: https://github.com/buunguyen/octotree#github-api-rate-limit.
Hi there, a better idea is to not animate and to just show a link at the bottom corner. So I get the goodies when everything works, and if it doesn't work, it stays out of my way.
