Comment by sirmarksalot
7 years ago
The issue isn't with the level of abstraction, but with the side-effect based workflow of some of the more common commands. The most visible of these is unstaging a file.
The syntax is "git reset -- <file path>". What does that do? Well, it tells git not to change the head pointer. Of course, it wasn't going to do that anyway, but as a side effect of not doing anything, it makes a decision about what to do with all the staged files. The default resolution is to unstage everything so that everything that happened between the old head and the new head can go in the stage. When you add the "--", you're telling it to only apply that resolution to the specified files.
So what you're actually telling Git is, "don't do anything, but when you don't do anything, move these files out of the stage so that you have room for all the files that you're not going to stage."
And this is why I used Git for an entire year without actually knowing what "git reset" does.
I'll not argue with you that Git's syntax is weird. It's an airplane that was launched as a kite by Linus and then assembled into an airliner while in flight by the passengers. Could definitely do with a revision.
The neat thing is that Git is an expression of that UNIX philosophy in which tools have various layers that are separated. You can have the crazy Git syntax but you can also write another command (or a GUI) that wraps Git and gives you the set of sane commands you wish it had, and which covers 90% of your use-cases, while still keeping the original around in case you need it.
[Disclaimer: I've spent the past couple years doing exactly this (the GUI part) for a digital archives application. And to lmm's point up above my app does hide the staging step from the end-user.]