I’ve never found myself backed into a corner and I suspect this is part of its success: some people have codebases where it’s a problem (branch names which are files, for instances) but most people don’t encounter this sort of thing and it works just fine.

Ever sat through user training on microsoft office? How to use email? The weird one-off enterprise apps that nobody else has ever heard of?

They’re unbearably tedious to users that can get by in a new tool with a 5 minute crash course, intuition and light googling.

Then git shows up and has the audacity to ask professionals to learn its mental model.

Once you do the interface isn’t great, but not particularly esoteric. The problem isn’t that users see dense-sounding things like “directed acyclic graph of revisions”, it’s that they assume they can competently manipulate one without knowing what that means.

I do think the interface could use cleanup, but can any ammount of cleanup prevent needing to know the mental model of git?

Mercurial has the same "DAG of revisions" model as git, and works just fine, because it has a good UI.

Darcs has a more unusual mental model than git, and works just fine, because it has a good UI.

People keep saying this, and this keeps not matching my experience of helping people with VCS issues at Mozilla.

Mercurial's model is roughly "append only list of commits, that separately form a DAG". This list model is leaked all over the place. For example the default `hg log` view just dumps that list rather than telling you anything about the history of the current working copy. To get that you need to add -f, which of course in most contexts means "do something unsafe". Worse, the list model is exposed in the local revision ids, which are prominently presented in the UI, and users have to learn that these ids aren't sharable with other users when discussing a revision. Also the most prominent "symbolic ref" in mercurial is "tip" which means "commit at the last position in the internal list", and so is sometimes the current head, and other times is some random commit from the remote.

Giving people help in mercurial is also super-challenging because, unless you are in some controlled environment, the first question is always "which extensions do you have enabled" and for complex tasks the next step is often "you should enable and learn to use <some extension>".

Which isn't to say that Mercurial is overall particuarly bad. There are some areas in which it's really an improvement over git (revset specifiers are pretty awesome, for example). But I often feel like praise for the UI comes from people who have internalised its flaws, and is repeated by people who haven't actually used it, but dislike git and are happy to accept something that confirms their preconceptions.

There are a couple more flaws. The commandline is not very consistent, and the complete model is way too complicated IMHO. I can work with it now, but it took me a long time to grasp all of the concepts that I need - without feeling the need for distibuted version control. About that: It's kind of ironic that git is hailed for being distributed, but everyone just uses github, a centralized system.

Edit: You're right, but my point was that the revert command treats a commit like a set of changes, not like the state of of a repo (since you can't revert the state of a repo, but you can revert changes).

If you checkout a commit, the commit represents the state of the repository. If you revert a commit, the commit represents a set of changes.

Git's interface is far, far more complicated than its model. Personally I spent years not learning about the model because I thought it would be as complicated as the interface. When I realised that the model is basically as simple as what you get when you view the "network" on GitHub then I started loving Git.

It's fun to be cynical, but surely this is just yet another example of how hard it is to "just change" something for all sorts of reasons.

It's funny that you bring up hubris when the pinnacle of developer hubris is "surely it can't be too hard to {build it, change it, replace it} -- I could do it!"

* Checkout a file called a/b

* Checkout branch b from remote a

* Checkout a local branch called a/b

I've seen people end up with local branches with names like 'upstream/mybranch', then get super-confused about how these branches aren't "upstream". git should really ban local branches with a / in their name.

  touch -- -l
  ls *

  touch -- -l
  ls -- *

  rm master
  git checkout -- master
  git checkout a1b1
  git checkout master -- master

You'll note that, for example, your "rm" didn't require a double-hyphen.

The OC's point (and maybe the GP's point [1]), ultimately, is about git command syntax ambiguity. With traditional Unix commands, there's not much ambiguity. At worst, there's merely no obvious way to pass an argument that's a filename starting with a hyphen. The question "what does 'ls -l' do?" would not plausibly have an answer of "output '-l' if a directory entry with that name exists" in addition to "output a long listing of all directory entries".

[1] Does git actually behave differently based on the existence of a directory entry named "master" or does it merely require extra effort to work with such an entry, which would actually be directly analagous to filenames beginning with a hyphen?

Conversely, attached HEAD means a branch is being updated whenever you make a commit, e.g. when you make commits on your local master.

I checked out master but now my commit is no longer there. HELP!

Can I somehow push my changes to you so you can fix it?

Ah let's intuitively try:

git log --graph --decorate $(git rev-list -g --all)

For comparisson:

- mercurial would show your commit all the time, no matter what currently is checked out.

- Only when you push, you have to force it, to create a new head in the remote repository because most workflows expect you to merge heads locally.

When you move out of detached head state by checking out another branch Git tells you how to save your work to a branch.

It could very usefully try harder to avoid getting into that state in the first place.

Am I missing something here? How do you get into a detached HEAD state without explicitly taking an obviously weird action, like finding and checkout out a commit hash instead of a branch, and why would it make sense for git to not be in a detached HEAD state should you do that?

Most people don't think about doing a hard reset to the last good commit, and then soft resetting to HEAD~. Instead, they just "git checkout $LAST_GOOD_COMMIT". And afterwards they may even continue by working with a detached HEAD

But this isn't an obviously weird action? It happens all the time when you need to branch off from a previous point.

Maybe you're unexpectedly releasing a hotfix, maybe your current development is going in a bad direction, maybe you need to test something against a previous state.

Several times that I've helped junior developer out of a detached HEAD state, when I asked what they thought they were doing before it happened, the answer was "I was just doing my normal rebase before..."

That's a great idea and it really confuses me why they don't add obviously useful things to the interface.

But the tool is not conceptually difficult. All the difficulty of git is in the trap its "UI" creates for no reason. The concepts are easy. I taught Darcs to a frontend/flash developer 15 years ago, and it's not because I'm a great teacher.

Every digital damage can be undone by wasting enough time.

Detached is just that: you can party on it all you want, but it's not going to go anywhere when you commit unless you go out of your way.

Just think how many person-hours were wasted by that team huddled around the monitor...

GIT: The Swiss-Army Chainsaw of Version Management.

It's also the easiest way to understand git.

You could learn to read by memorizing the shapes of thousands of words without learning the alphabet or how it matches up to sounds. I'm sure people have done it. But the failure mode when encountering a new word is complete and utter bewilderment that this new shape is unfamiliar, rather than a graceful degradation you get if you understand the alphabet. The same is true of git.

The UI does a remarkably good job of hiding the elegant underpinnings from you.

In this case, I have a single suggestion for you: Give the following extra arguments to git clone.

  --reference /path/to/existing/clone/ --dissociate

As a polygot developer working in multiple languages, editors and ecosystems, git has been the one tool that I'm always using, and that makes it always worth investing more time into learning how to use it better.

"This merge went completely sideways. But I haven't pushed anything."

"Okay, do this to export the commits you made as a patch file. Move those somewhere safe. Delete your repo. Reclone. Apply the patches. Commit. Start merge over again."

Also I can recognize whatever that weird error message is that means someone deleted a file in one branch and I edited it in another. Usually results in just "git rm (file); and git merge --continue".

  git merge --abort

Flight rules, process workflows, protocols (both network protocols, and protocols of mission critical human activity), they all belong to the idea of limiting yourself to a set pattern of activity when dealing with something that can practically give you infinite possibilities. Because infinite possibilities give decision fatigue and analysis paralysis.

By 2D code I mean code in a text editor: the two dimensions of lines and columns.

By 3D code I mean: lines, columns, time (meaning commit timestamps)

By 4D code I mean: lines, columns, time, time travel (you can go back to older commits and rewrite your revision history).

git's wall is thick, made of brick and reinforced concrete, and you'll be heading toward it at 200kph. You'll get going again eventually, once the metaphoric car gets glued back together.

Non-metaphorically, my experience has been that with SVN, Mercurial, et. al., a few quick web searches and I'm on my way. With git, "wait a minute...run that by me again?" I've used git for going on a decade, and now that I'm in an SVN shop I do sorely miss it. But, man, it's got some sharp edges.

Up until this day navigating code feels more natural on the site that on native apps like sourcetree. I really miss the ease to see the same file from two different branches or commits, the feature might be there in native apps but I just couldn’t find it.

I know, right? This 'evil' thing is going places.