3 ms·
Try it on something that isn't a trivially sized repository. E.g. on linux.git it takes 4-5 seconds on a warm cache on SSD to show anything, whereas "git log" i
by avar 9y ago
Try it on something that isn't a trivially sized repository. E.g. on linux.git it takes 4-5 seconds on a warm cache on SSD to show anything, whereas "git log" is instantaneous. This is because to show the graph it needs to search forward through the history before knowing how to paint it.
Then when it does show something it's pretty useless on complex histories, e.g. on linux.git a few dozen pages down into the output we're at 140 characters on graph lines before we even get to showing the commit id and climbing. Scroll down a bit more and all you're going to see is jumbled graph line output as the commit info is entirely pushed off-screen.
- bowmessage 9y agoFair enough - that's a great point. But I do wonder if the average git beginner is dealing with such complex repositories. Perhaps there could be a `git log --simple` or whatever equivalent, and those developers working on gigantic repositories could alias as necessary.
- avar 9y agoThere's no rule of thumb that git beginners start with their own repositories. Maybe they clone a big project like linux or git, or start working as a junior dev at a company with an established code base. It's important that git work sensibly by default without you needing to know there's a --simple. Also --oneline --graph can get really nasty on even small repos, particularly those made by beginners who are doing redundant merging. But yes, all of those are technically solvable, e.g. git itself could fall back on the simpler view given some heuristic, but I think given the principle of least astonishment it makes sense for all the commands to work sensibly by default whatever the complexity of the repo.