Almost guilty as hovertext-charged. (Go read the hovertext. I’ll wait here.)

As a “git guy”, I (unlike the friend whose phone number is in git.txt) do start with written tutorial explanations built from lists of commands to accomplish common tasks—including recovering from common problems. But whenever people complain that Git isn’t “intuitive” (which, being interpreted, usually means that it is a poor match for their mental model), I do start them on the path to a better mental model. A high-level understanding of what Git is trying to do can make many of its behaviors (if not its command-line option structure) intuitive.

At least I start these conversations with “my recommendation to use Git isn’t based on its simple command-line interface” before I point out the radical simplicity hiding inside. And its roots are simple for you only if you know basic data structures. And it is simple in practice only when its model is a good match for what you are actually trying to do. If you understand something about the model, you are more likely to be happy with your decision whether to use Git in any particular instance.

This XKCD not withstanding, those conversations have been effective—I’ve seen the “lightbulb turn on” and the developers who came to me for help turn around and help others.

And “git help” is still my favorite Git command.

xkcd: Git

Jürgen Erhard October 30, 2015 06:49

The only intuitive interface is the nipple, everything else is learned.  (And even the nipple is being debated :D)

Michael K Johnson October 30, 2015 08:36

+Jürgen Erhard ugh, sorry, that’s quite an old chestnut… It is not only wrong in intent as you allude to (ask any midwife or lactation consultant), but also confuses intuition and instinct.

My complaint about that phrase is that by conflating intuition and instinct, it hides the true value of a really intuitive interface: one in which a parsimonious mental model leads to generally correct assumptions regarding behavior not yet specifically learned.

My view of git is that having a good mental model will make it more likely that you will understand what you can do with it, but that translates poorly to the command line interface in practice. Therefore, the interface isn’t intuitive because in practice it still surprised people who have a good model of the underlying operations.

This is why “git help” is my favorite git command.

Eugene Crosser October 30, 2015 09:29

As a “git guy” by necessity after I and a number of colleagues where transferred to a project that uses git, I encountered a lot of mentality “but I can save my changes elsewhere, do a fresh clone, apply my changes, commit and push, right?”. Infuriating, but also a sign that not all is well with git.

Mike Melanson October 30, 2015 11:14

Extremely cathartic comic. :-)

Curtis Olson October 30, 2015 11:31

I think of git as a super powerful car engine that can do just about anything.  You the driver just need to know how and when to move the pistons up and down, when to schedule fuel, and when to ignite the spark.  I imagine there are about 6 people in the world who can do this effortlessly.  The really cool thing though is can also make pancakes with your car engine by just moving he pistons different ways … it’s pretty simple actually, just type these 23 command lines in order (of course updated for your own situation.)

David Megginson October 30, 2015 15:19

The only way I could see the hovertext on my phone was via Feedly.  xkcd is my favourite strip, but the site’s usability is getting stale.

Curtis Olson October 30, 2015 15:22

Why doesn’t he put the cartoon in a git repository, then you could “git checkout alt” to see the alternative punch line.  Just don’t forget to return to the main branch afterwards.  I always have to google to figure out how to pull remote branches over locally … something like git checkout -b <branch>?  Or does that create the branch?  Never mind, I’ll just try it and see what happens.

David Megginson October 30, 2015 15:25

Can I send my comments as pull requests?

Curtis Olson October 30, 2015 15:27

I thought comments > /dev/null

Eugene Crosser October 30, 2015 16:46

+David Megginson go to m.xkcd.com, there’s touchable (alt-text) there. Lack of “responsive design” is of course a shame…

Michael K Johnson October 30, 2015 16:54

I use Firefox on android and just long-touch to see the hovertext.

David Megginson October 30, 2015 17:48

Nice!

John Pitney October 31, 2015 00:01

Long-touch shows the alt text on Chrome/Android here. By the way, fossil SCM is good, too.

David Megginson October 31, 2015 04:18

I see that now, too — fairly new for Android Chrome?

Michael K Johnson October 31, 2015 08:31

Fossil is opinionated in ways that limit its utility. The comparison with git on the fossil web site really doesn’t display a clear understanding of git, either. I have tremendous respect for its author and would not tell others to avoid fossil if they buy into its model, but I don’t buy into its model myself. Additionally, we have the network effects of git “winning” that lead to a whole ecosystem of tools around git.

Simo Sorce October 31, 2015 08:58

The problem of the fossil vs git is that it completely misses the mark. Seem like a table written by a marketing guy that never used a dvcs and doesn’t know what matters…

Michael K Johnson October 31, 2015 10:59

+Simo Sorce I don’t get that impression from it—at least, he’s definitely not a marketing guy. :-)

I think fossil is more closely related to mercurial than to git; for example, the focus on historical accidence over essence as part of the tool. Mercurial at least grew patch sets as a mechanism to implement a historical record of essence; I’m not aware of any tool-supported equivalent for fossil.

But yes, I agree that the opinionated design means that it doesn’t address many of the real needs that git does, and the comparison page does not demonstrate an awareness of the ways that his desiderata can be implemented and enforced in git, such as using signed tags, nor does it reflect an understanding of underlying git design at least as I see it.

But hey, at least you can export from fossil into git, so if someone starts with fossil and then realizes a need that fossil doesn’t meet, they aren’t trapped!

David Megginson October 31, 2015 11:05

I haven’t had time to look into Fossil yet, but what I loved about git, moving from earlier version-control systems, was the idea of cloning — when clients ask me about disaster recovery (e.g. if GitHub shut down), I tell them that every developer has a full backup of the source-code repo.

David Megginson October 31, 2015 11:05

If fossil goes further and gives every dev a local copy/backup of the issues as well, I could see that as a selling point.

Michael K Johnson October 31, 2015 11:14

The full backup capability is of course a common feature of most DVCSs. Git lets you choose.

Issues could be implemented on top of git as an orphan branch, just like the github gh-pages branch. And then you could decide whether you wanted it in your clone. Someone may have even implemented it. It would be a reasonable extension. I haven’t looked.

John Pitney October 31, 2015 16:55

+Michael K Johnson Mind sharing some details on what in the fossil vs. git writeup displays a lack of understanding about git?  DRH is the kind of guy who would likely fix the writeup if errors are brought to his attention.  (Certainly not a marketing guy who doesn’t use a DVCS!  He wrote one!)  

I’m a git user, too, and I didn’t mean to imply that Fossil was somehow better than git.  When I first got into DVCS usage, git was poorly supported on Windows, and I do have to work on that platform much of the time.  If git had worked well on Windows back then, I might never have tried Fossil. 

Michael K Johnson October 31, 2015 18:23

I have tremendous personal respect for DRH and don’t imagine for a moment that he would write a word that was intentionally wrong or misleading. I just think that his perspective leads to a misleading presentation from a disinterested point of view.

His developer vs. feature branch comparison assumes the asymmetric flow, but Git is often used with a shared central model with multiple committers successfully. (Gerrit as the Git server makes that work even better.) His “pile of files” can be interpreted as loose files where the normal case is packed files though I guess he’s talking about the whole directory. I’m not confident that his claim that Git is subject to data loss on power loss during commit is accurate; a link to substantiation referencing current code base would be worthwhile. The checkouts per repository section is either misleading or wrong depending on how you read it; it at least misses that you can share the objects and that doing so is a normal case that happens by default when you clone at the filesystem level; that is, you could interpret what he wrote as true but I think it’s misleading from the point of view of what the user is looking for. His points about audit again miss the mark; in real use with normal servers that implement authentication models (e.g. gitolite, gitlab, gerrit) you can choose which users (including no users) have sufficient permissions to revise history (force push, deleting references, etc.), and the hash history mean that signed tags give you equivalent guarantees of audit trail.

That’s my impression as a Git user who came from strongly preferring Mercurial to understanding Git and feeling hamstrung every time I have to go back and use Mercurial; it’s like being an emacs or vi user on a system with only nano. It’s not that you can’t do the work, but you miss the tools. I did play with fossil and expect that the quality lives up to the quality of anything else DRH does. It’s just that I’ve gotten used to what I can do with Git that nothing else provides…

Simo Sorce October 31, 2015 18:36

+John Pitney​ of course it is obvious he wrote a SCM system, I said “as if”. +Michael K Johnson​ already made all the points I would have made, I’ll just add that it is sad this guy built a whole new system when he could have built it on top of git and have a superior plumbing with a nice interface.

Michael K Johnson October 31, 2015 18:59

+Simo Sorce We disagree about “sad”. I think that the author of sqlite is entitled to write whatever he enjoys doing, and I don’t think that implementing his desiderata and sharing the result is in any way sad. Just like I use vim everyday and don’t think that nano is a waste of time. It’s just different—which doesn’t mean that it meets my needs.

I just think that he might not be the most disinterested source of a comparison between fossil and git. :-)

Imported from Google+ — content and formatting may not be reliable