> why it seems Github goes out of its way to hide the typical commit tree navigation
Wild guess: because those kinds of features requires the back end to execute Git implementation code which can invoke some pretty expensive cases. Imagine that across thousands and thousands of repositories being accessed at once.
They want to steer the user toward doing a clone and doing their own in-depth drilling on the copy.
CGIT caches for better performance; but caches require extra storage and some sure-fire expiry mechanism so it doesn't grow and grow. Caching things for internet rando visitors doesn't seem like a good idea.
Github has the blame view of files, which is much more expensive.
Not the idea of a decentralised system, is it?
that would be worthless for most people, and for the sqlite authors, who'd surely have a million people pressing the 'fork' button.
it also isn't what anyone in the thread, or post, were asking for.
perhaps you'd be so kind as to provide a link to a page on github which demonstrates the same graph structure?
... across all forks, which makes the UI much more cluttered than it needs to be. What if you are only interested in commits in your own repo?
Github really does seem to lack a clean equivalent of `git log --graph`.
Eg https://github.com/sindresorhus/delay/network tells me that this work is being maintained actively, but most forks are not merging back. Another one might tell me work on the main fork is stalled, and many users are now doing PRs against a fork of the original.
GitHub and GitLab offer nothing comparable. The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at all on mobile."
This is a valid point. I've always wondered why it seems Github goes out of its way to hide the typical commit tree navigation that so many git clients support (Sourcetree, gitk, tortoisegit, etc).