Comment by timdorr | Hacker News Reader

Comment by timdorr | Hacker News Reader

Parent Full thread

> 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.

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... :)

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...)

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.

> 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.

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.

Reply on news.ycombinator.com