Hacker News Reader

Comment by payne92 | Hacker News Reader

Part of Github's secret sauce: Web source tree browsing that's front and center, that's relatively decent, with OK search. (versus making the log/history the central part of the Web UI as other tools seem to do)

There are SO many times I need a short peek at something, and am glad don't have to clone/download, etc.

View on HN

> Web source tree browsing that's front and center, that's relatively decent, with OK search.

The source browsing feels barely adequate to me. There are so many simple things they could do to make it better.

• Show file sizes. When I'm exploring a repo I'm unfamiliar with, one thing that's helpful for me is to get a sense of what the code is like. To do this, I want to look at some of the larger files; that's where I'll probably find the more interesting code. As it is I just click around on random files hoping to find something interesting.

• Show real dates instead of the vaguely rounded off "how long ago". If it says "a month ago", well, what is it, two weeks or six? And why not show the time? A couple of times I've been looking for a code change and I didn't remember what day it was but I did remember it was right before lunch, maybe around 11:30 or so. It feels like their priority is a "clean and simple" display as opposed to a useful and informative display.

• Fix the display for code that indents with tabs. It still defaults to 8 columns, which hardly anyone (with a few notable exceptions) likes. And you, the user, can't override this. They did recently start honoring the indent_size setting if you have a .editorconfig file, but that really misses the point. Many of us who use tabs don't want to specify an indent_size. That's one of the virtues of tabs: people who read the code can use whatever indentation they prefer. The indent size for tabs should be a user preference setting. As it is, I started adding indent_size=4 to my .editorconfig files just to get a decent looking display on GitHub.

• Use a readable font on mobile. Courier, really? And not such low contrast! Everything is hard to read on mobile, and they even disabled pinch-zoom so I can't make the text a little bigger.

• Show a directory tree on the left. If I'm exploring a repo, I'd like to get the big picture of the directory layout, and also have an easy way to click around to look at the various directories. As it is, I have to do a lot of back and forth. Google Code had this from the beginning.

Edit: Thank you everyone for the helpful replies! I learned some great tips from you all.

I actually prefer the "time since" method. Don't have to do date maths in your head to see how active the repo/file is.

> Fix the display for code that indents with tabs.

Hidden feature: you can actually add ?ts=2 (or 4) to the URL. It would be nice to be able to configure it, though.

You can use a simple Stylish rule to force it to your preferred indentation:

https://userstyles.org/styles/70979/github-better-sized-tabs...

This is what I do, and now GitHub styles match my editor styles. It makes my brain tranquil.

Hovering over any time on GitHub shows the absolute time.

That's as bad for compairing as giving file sizes in bytes, kilobytes and megabytes in the same listing.

> Show file sizes

Those are at the top of the display of file contents. However, they aren't in the tree view, as you've stated. Unfortunately, this is hard because I don't believe Git stores this info in their index of files, which is what is used to generate the tree view. It might be infeasible to gather that data for the tree view.

> Show real dates instead of the vaguely rounded off "how long ago".

If you hover over any relative date, the real date is shown. It's on the title attribute for any relative date.

> Use a readable font on mobile.

The have Consolas and "Liberation Mono" on the font stack, but those probably aren't on your phone. They are limited in font selection because they have switched to native fonts. This avoids the download of some giant font file that contains all the possible glyphs (which is needed on a site like GitHub's). Unfortunately, the monospace options on mobile are pretty limited: http://iosfonts.com/

> Show a directory tree on the left.

Best tip I can offer is to type `t` to search by file name. Works great and has partial matching support, which makes it really quick to navigate to certain key files.

The tree doesn't tell you when the blob was last modified either. If they can show last modified time (and commit message), showing file size is surely even easier.

Size = 0 is a common case, useful to highlight, and (I think) should have a common hash value. __init__.py files are a great place to look if they're not empty, but most are.

Just had to test what the other keys did.

What i found:

t = search file

j/k = move down/down (selected file)

w = select branch

s = focus search field

y = expands url

Anyone know any more?

EDIT: Found this https://help.github.com/articles/using-keyboard-shortcuts/

Press ? on any page.

Would _love_if that became standard practice.

It kinda is. Across most Google products it is (gmail, music, calendar, etc). Most hotkey JS libraries I've seen also use ? as the default for seeing all of the bound hotkeys, so anyone who uses a library should have it by default too. It's always the first thing I try on a website.

Interesting. Thanks.

OHHHH! It works on gitlab as well!

That's incredible.

Oh my, this just led to me finding https://github.com/issues.

I'm guessing I should be slightly embarrassed to have not realised that existed - was it there before they changed the top bar to black a few days ago? (I now see that there's a link to it from said bar...)

> Unfortunately, this is hard because I don't believe Git stores this info in their index of files,

I don't know if they keep a work tree on the server side, but if they did, then it would be trivial to store the file size as determined from the file on disk and display it on the front-end regardless of the type of view. Alternatively, they could determine the size from the blob associated with the file in the object store.

> keep a work tree on the server side

That's complicated by the fact you could be viewing any commit, not just HEAD of master.

Presumably the branch/tag/commit that's currently chosen is stored in the session. You can retrieve the size of a blob by running

    git cat-file -s commit:path/to/file

and the tree object has a listing of the blobs and trees it references. I would think they could do this and store the results when a particular commit is chosen from the drop-down menu on the web page.

Just because you can get it, it doesn't mean that this is efficient and fast enough to do when you are browsing through the directories. Now imagine the slowness, since caching this doesn't even make remotely sense for many repos.

> Just because you can get it, it doesn't mean that this is efficient and fast enough to do when you are browsing through the directories.

It's already doing this for the last time modified value it retrieves or calculates for each file and directory as I'm browsing through the repo. That requires determining which commit last changed each file and in the case of directories, which commit most recently changed one of the files within the directory.

The file sizes, on the other hand, are available by determining which blob is associated with the file. That file to blob mapping available by recursing through the trees associated with the commit that's currently selected. This does not require iterating through multiple commits, unlike the former case, and it shouldn't be any more complex.

It's pretty cheap to get the file size with decompressing the whole blob. You can decompress just the first hundred of so bytes of the .git blob object, which starts with "blob {size}\x00". For example, using Python:

   >>> import zlib
   >>> f = open('.git/objects/00/331d4c2e12984f70df4a3dd3bc7296825faab0', 'rb')
   >>> zlib.decompressobj().decompress(f.read(100))
   b'blob 11708\x00...'

So that particular file is 11708 bytes. It still requires an open and read operation. But they could cache that on a per-file or per-tree basis, so it's very doable.

At least until you try to open up https://github.com/Homebrew/homebrew-core/tree/master/Formul... :)

> Show a directory tree on the left

The OctoTree extension is great for this (all browsers, and works for both Github and Gitlab)

What I want most is "jump to definition". Maybe not as full fledged as the true IDE, but just ctags like behavior is immensely helpful.

The Sourcegraph Chrome extension provides this for Python, JavaScript and a few other languages I think.

I known. But their language support is very limited.

I've made codesearch.xyz with that purpose. It lets you enter repo URL and then it lets you search and browse the code.

I'd be really happy if they parsed the code and indexed definitions vs usage in search. A lot of times when I'm digging through a project I'll find a function and want to look up the definition. Ok, try searching for the type and function name, nothing, it must be type, a line break, then the function name. A lot of times I end up clicking through pages of search results trying to find something that is a little elusive. It would be awesome if they did it like IDEs and you could filter searches by usage or definitions (go to declaration sort of thing). Given the number of languages they would have to implement that over, I don't think it will happen, but it would be cool.

> Show file sizes

https://github.com/harshjv/github-repo-size

> GitHub Plus [1][2] does that and more.

Features

1. Displays repo size.

2. Displays each file size in every active branch (not applicable for folder / symlink).

3. Show download link for each individual file (not applicable for folder / symlink).

4. Copy file's contents directly to Clipboard (just won't work for markdown files).

5. Download file while viewing it's contents.

[1] https://github.com/softvar/github-plus

[2] https://chrome.google.com/webstore/detail/github-plus/anlikc...

To me the real killer is that the code formatter is too slow on mobile, with no way (AFAIK) of opting out.

> Show a directory tree on the left.

FYI there's a Chrome extension for that

https://chrome.google.com/webstore/detail/octotree/bkhaagjah...

It can be a bit of a faff to set up with private repos, but it's a fantastic tool, well worth trying out if you want directory-tree navigation in GitHub.

> • Fix the display for code that indents with tabs. It still defaults to 8 columns

God made the ASR-33 with 8-column tabs for a reason. ;-)

As for style, it is relatively easy to make a browser plugin that overrides the default styles of a site. While working for Canonical, I did one for Launchpad:

https://chrome.google.com/webstore/detail/launchpad-tweaks/p...

> Fix the display for code that indents with tabs. It still defaults to 8 columns, which hardly anyone (with a few notable exceptions) likes

I still think GH's insistence on 8-space tabs is part of a secret conspiracy campaign to get people to stop using tabs. It always looks bad when you look at tabbed source code in there, so the easier way to avoid it is to start using spaces instead.

"Show a directory tree on the left"

if you use Chrome, try out Octotree

> disabled pinch zoom

Can anyone explain to me why this is even a feature?

Why did the powers that be decide that web sites should be able to prevent pinch zooming? Why do mobile browsers not provide the option to disable this bug?

I agree, it is a real PITA when using <7" phones.

> Why do mobile browsers not provide the option to disable this bug?

In Firefox, you can set browser.ui.zoom.force-user-scalable to true.

Unfortunately, if have JavaScript enabled, some pages are still able to disable the zoom.

> Part of Github's secret sauce: Web source tree browsing that's front and center, that's relatively decent,

Plus decent rendering of README.md at the same base URL.

You get a decent homepage for your project by just pushing your repo.

I wish GitLab just copied the base project page of GitHub.

We're thinking about adding the file tab to the default view in https://gitlab.com/gitlab-org/gitlab-ce/issues/26834

Going to second this.

I love the idea of gitlab but I absolutely cannot enjoy the UI. I have trouble understanding the layout of the project from the base URL. I don't have that problem at all on github.

Edit: I'm a fool. I swapped gitlab and bitbucket. BB interface is absolutely bad to me.

Even though you did not mean to say so, I would actually agree that the UI of gitlab is not great either. GitHub's UI/UX is better than Gitlab imo.

I wish github would add an option for a case sensitive search. Tired of getting back ThisThing when I specifically want thisthing (lower case).

Also, the search documentation is spread out and seems to be missing guidance on features that are crucial. For example, AND works as you would expect (like: hello AND world), but it isn't mentioned anywhere.

This this this. I would spend so much time on GitHub if the search were better. I'm tempted to say that search is less than OK. I do have a huge Java repo, but I'm usually shocked when I quickly find what im querying for.

Using google and site:github.com? I never use the search on the site...

And then clicking Tools->Verbatim because google otherwise gives results that are wildly different from what you specify..

I can't believe I've missed this. The quality of my search results at google has been steadily going downhill, and I'm often left with a thought along the lines of, "But if you just searched for only the words I used..."

Anyway, thanks for posting it!

There should be a search mode for IT professionals. That way, things like curly braces, numbers, and non-words are still treated as meaningful.

It still boggles my mind that there is no (good) way to search all an organization's repos at once. The docs (e.g. [0] but also in other places) claim you can just put "org:foo" in the search bar, but it has never worked for me.

[0] https://help.github.com/articles/searching-code/

"user:foo" will search an organisation named foo.

I'm always stuped by the fact that when I search for SomeClass I get a dozen of results from tests and the actual class SomeClass in a file called SomeClass.x appears on page 4. Haven't found a way yet to exclude those pesky tests.

why not just full regex

regex search is slow and difficult to index efficiently.

It's plenty fast for many purposes. I grep large source code repos all the time. It's very fast as long as you avoid grepping large binary files for no reason.

The link below shows timings for various regex on a 20MiB text file for several different regex softwares. The best code never exceeds half a second for even the worst expressions. Most are much faster.

http://sljit.sourceforge.net/regex_perf.html

For most reasonable search regexes, it's reasonably fast if your repository is already cached in memory. However, it's still fairly heavyweight, and the cost of running even these reasonable searches hundreds or thousands of times a second becomes significant.

When you add to this the fact that it's possible to deliberately construct regexes that are much more complicated to evaluate (particularly if you allow extensions beyond a true regular language) - potentially being a DoS target - and many repos won't be cached when the search comes in (or caching them would also be very expensive), the costs just get higher.

In contrast, a simple keyword search can be performed with a predictable, low cost, so it's no wonder that they'd prefer to implement this instead.

>When you add to this the fact that it's possible to deliberately construct regexes that are much more complicated to evaluate (particularly if you allow extensions beyond a true regular language) - potentially being a DoS target

Only if you allow extensions, but then they aren't regular expressions.

Backreferences aren't really an extension though, are they?

Re2 excludes them specifically .

Backreferences are certainly an extension. They are the primary reason that regular expression engines that allow them are slow.

Ahhh, "extension" meaning not in the POSIX basic definition. Sure. Though I don't know many tools that implement REs in that basic form. They almost all include features outside that definition.

No, extension as in it is not regular. Nothing to do with POSIX. RE2, Go and Rust do not provide backreference support in exchange for predictable performance.

There are plenty of regex engines that are guaranteed O(n) for all regexes they accept. There's re2, go-regex, and rust-regex just to list a few popular ones.

They still use Perl-like syntax, and might still be able to parse non-regular languages, but you don't need to worry about users deliberately crafting regexes to eat up CPU time like PCRE.

Do you remember Google code search? Difficult yes, but definitely not slow. This seems like it would be a high value feature as well.

Actually, I would really just be happy with better docs. In code search, for example, this appears to work:

foo AND bar NOT baz OR fizz

So, it supports AND, NOT, and OR. Nowhere, though, does it say that. I don't know if I can group these to get around precedence either. Parenthesis are ignored. It does mention NOT somewhere. And, there's no navigation to search help by the search button. I had to google to find out any help was available.

Also, it ignores some characters for unknown reasons. Like $, for example. That's a meaningful sigil in Perl, PHP, and so on...it's quite frustrating that it's ignored.

> this appears to work: foo AND bar NOT baz OR fizz

`AND` being implicit in `bar NOT baz`, and in `foo bar`. Also AND/OR is per file, rather than line which I wondered after reading this comment.

There's some information here [0] that's mainly centred on issues/PRs, but some transferable (this might be what you referred to that does mention NOT). There's also a bit more information here [1]; it does at least acknowledge that `$` will be swallowed.

[0] - https://help.github.com/articles/search-syntax

[1] - https://help.github.com/articles/searching-code/

I am always amazed at how hard it is to find something with GitHub's search, when `git grep` works so well.

git grep is far more expensive and slower the what GitHub does, especially on large repositories.

So... ?

grep works on the actual, full repo data and not a precomputed index (which is computationally speaking orders of magnitude faster).

No online service in the world does not index things.

If you need full access to everything, why not just clone the repo and do these things in the comfort of your command line?

If you're using chrome / chromium, and you don't know already, then you may be cheered to find out about the Octotree extension: https://github.com/buunguyen/octotree

readme says that it also works in ff and safari

Thank you for introducing this to me, that is amazing.

Check out Sourcegraph: web source tree browsing with jump to def, find refs, and a bunch of other intelligent features. For example, try diving into the Go std lib: https://sourcegraph.com/github.com/golang/go/-/blob/src/net/...

(Disclaimer: I'm one of the creators. We currently only support Go officially, but other languages soon on the way via the open-source Language Server Protocol standard. Also, big fans of GitHub and glad to see this move!)

Even just being able to browse code when I'm on the go on my phone is useful!

I am guilty of occasionally even viewing my own projects on github to avoid having to put down what I'm doing to check what's in production...

It's unfortunate that their mobile site is very watered down compared to desktop. Every time I view something on my phone I have to request the desktop version of the site.

agree - I do the same too.

I do that for every site i can think of because, as a person with very poor eyesight, the ability to zoom seems better on desktop-site pages than on mobile-site pages.

On iOS, Safari Reader helps solve this problem on text heavy pages. I crank the font size up to 16–18px with white text on black background.

Firefox mobile (at least on Android) has an option that prevents sites from disabling zooming in.

Chrome also has an accessibility option for this. That discovery solved my problems with a lot of sites.

For what it's worth, there are git client apps that you can run on your phone. I've found them to be... usually nicer than GitHub.

Any particular ones you'd recommend.

The "t" key shortcut to do repo wide file search is one off my favorite features.

> with OK search

As far as I can tell, Gitlab (still) doesn't have search within repo. It's one of the most useful features on Github for me; often I want to see the definition or uses of some symbol without having to clone the repo. I don't understand why Gitlab doesn't seem to support it.

I just tried on my Gitlab 8.16 and it seems to be able to do that. If you go to the Code tab, it shows snippets of files that contain the search term.

It does, but I believe you need GitLab EE with ElasticSearch turned on: https://docs.gitlab.com/ee/integration/elasticsearch.html

> OK search

Damn... I can't even manage to figure out how it works. I consider myself extremely lucky when it returns the expected result, and that seldom happens.

Could not agree more while I was learning to program, it took me months before realizing that it was possible to Browse a Google Code project online.

GitHub code search + file navigation is so good, that I prefer it to search/navigate code vs opening a VS.NET sln of a repo already cloned locally.

git grep is still much better than github's search, when it comes to code. Github search doesn't show enough when there are many matches in the same file.

Not when searching for files, find-as-you-type lets you type the least chars/camelHumpsNotation to quickly find + open files you're looking for and its deep linkability lets you quickly share code fragments with remote devs.

Ctrl-P in SublimeText.

I actually dislike their "tree browsing", which is not a tree .. herein lies the problem.

What I like in github .. it's a multiformat http file viewer.

same reason i like npm 'run this in your browser' feature. lets u play around with the actual implementation

Reply on news.ycombinator.com