4 ms·
The problem is that every git command tries to be extremely flexible. That means the documentation for command X has to cover everything X can do, and when you
by stevelosh 17y ago
The problem is that every git command tries to be extremely flexible. That means the documentation for command X has to cover everything X can do, and when you're just trying to find out how to do action A you have to skim through all the other crap X can do.
For example, 'git help checkout' clocks in at 236 lines. 'git checkout' can change the revision/branch you're at, create a new branch, or revert files without changing HEAD.
The help output for the equivalent Mercurial commands:
* hg help update: 38 lines
* hg help revert: 41 lines
* hg help branch: 24 lines
If I want to revert a file's contents in a git repo I need to wade through 236 lines to figure out the exact command I need. With Mercurial I need to wade through 41, because I know: "Oh, I'm reverting a file, I need an 'hg revert' command of some kind."
Mercurial commands each do one thing (rarely two, almost never more than that) and do it well. If you want to combine commands, write a script. This makes the documentation concise and easy to read as you're working.
Git commands each try to be flexible enough to do many different things. The price you pay is that any time you need to read through the documentation it's an exercise in trying to search for a word in a man page and hoping everything you need is somewhere nearby.