3 ms·

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

• u801e 10y ago
  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.
  • recentdarkness 10y ago
    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.
    • u801e 10y ago
      > 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.