[jimktrains2]

I think git provides a sane level of abstraction.

I don't think it provides the most consistent UI or helpful help, though. Once you move away from "learning git commands" to "learning how git works" and kind of figuring out which parts the commands refer to has helped also. That's still terrible though.

[ivix]

>I don't think it provides the most consistent UI or helpful help, though.

Understatement! Git is one of the most user-hostile tools I've ever seen. And I've used Sendmail.

[pqh]

Just read the manual.

https://git-scm.com

[lmm]

Most of the abstraction is fine. The staging area model is a total mess though. The way that staging interacts with other commands (e.g. stash) is constantly surprising.

[jefurii]

Git stage is "These are the things I'm planning to do", and git commit is "OK now do these things". Lots of carpenters draw plans before they start cutting but we don't think that's so hard do we?

I had trouble with Git until I discovered "git add -p".

I'll grant that Git could do with a revision of its commands and args.

[sirmarksalot]

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.

[jefurii]

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.]

[lmm]

> Git stage is "These are the things I'm planning to do", and git commit is "OK now do these things". Lots of carpenters draw plans before they start cutting but we don't think that's so hard do we?

But when a carpenter stashes and unstashes their things, they don't suddenly find out they're magically planning to do a lot of things that they weren't previously planning to do.

[jefurii]

Ha, that's a great way to put it. There's also "It is easy to shoot your foot off with git, but also easy to revert to a previous foot and merge it with your current leg" tho it's not quite as easy as the quote makes it out to be. Wish I knew who said that.

[lhuser123]

> I don't think it provides the most consistent UI

That reminded a video where Linus Torvals is been interviewed and he says that if he ever have to make good UI to get out of a desert island, he would die there.

[hyperhopper]

http://stevelosh.com/blog/2013/04/git-koans/