I have a fairly advanced knowledge of git (that is, at the level of porcelain and plumbing commands; I haven't touched the C codebase itself) and I intend to give gitless a try when I get back to work on Monday.
My reason is that, while I'm a fan of git the technology, I think the default git CLI is an unmitigated fucking nightmare and I begrudge every neuron of space that I have to waste remembering how it works. Unfortunately, none of the graphical tools I've tried are as good. So I'm eager to try an alternative command line porcelain that's not so completely batshit insane. If it works out, maybe I can reclaim some of that wasted space.
- Command line switches are inconsistent. For example, to list remotes you use -v but to list branches you use -l
- Speaking of command line switches, how about that bizarre need to separate paths in certain commands with "--" so that the parser doesn't get confused? I can never remember when that's necessary.
- There's weird overlap between the porcelain commands that make them harder to learn than they should be. For example, git checkout can do the work of git branch. git pull usually does the work of git fetch. Some common operations get their own commands, while others require you to use switches on other commands. It really shows that git evolved organically from a bunch of shell scripts used by one particular dev team until it katamari damacy'd into a big agglomeration of random parts.
- Poor defaults, such as git push --force not having the behavior of --force-with-lease, and also git push pushing all branches at once by default.
- Many of git's mechanisms are overly complex and lead to a depressing number of bewildered users. E.g. witness the confusion and conflicting advice at https://stackoverflow.com/questions/6089294/why-do-i-need-to... Another example is git reset, which is invariably a nightmare to explain to an intern or new developer who hasn't used git yet. Trying to learn what git reset does from reading the man page is like trying to learn calculus by examining the digits of pi.
Firstly, I agree that Git has a learning curve. However, trying to learn anything based on man pages alone is not a good idea, in my opinion man pages are for reference and not a substitute for more extensive documentation. Of course, sometimes man pages are the only document one has, but this is not so in the case of Git. I myself am not a Git expert, but after reading about what problems people have with Git, it feels like people should perhaps not go for the most exotic commands by default, and they should use a topic branch based workflow. And they should read the Pro Git book and I mean this in a good way :)
As for the switches, one can just as well use "git branch -v" to list branches, I usually pipe to grep if looking for a branch. For the "git remote", it actually does show you the remotes without any switches, but the URL of the remote is not the remote... To see the URLs you'll need the verbose switch. Maybe this is right, maybe not, I do think it makes sense.
The two dashes is actually not a Git peculiarity. It comes from getopt and POSIX.2 to signal the end of options. Compare with e.g. to rm a file that's called "-rf", you'll have to do "rm -- -rf" in the shell.
As for the intern, just tell them "Git reset moves backwards in commit history". Of course there are details (and you can get back to the future with e.g. git reflog), but it should be accurate enough description to an intern who is new to Git, since that's what "git reset" is mostly used for anyway. IMO "git reset -p" and such are somewhat advanced usage.
The problem with the Stack Overflow link is that Git is not tracking that upstream branch, just because the local and remote branches happen to have the same name after a push does not mean they are the same and should be tracked. I'd argue that if one works with topic branches, that kind of situation is kind of remedied automagically through the workflow... Anyway, Tzen's answer there is the correct one (when including the typofixes in the comments).
Also, thanks for the link to the Git man page generator, it's great!
Because they have a lot of other things to deal with. I have enough other things I have to learn and I simply don't have the time to become a git expert.
