[bsder]

Let's start here: http://randyfay.com/content/avoiding-git-disasters-gory-stor...

So, the solution to the fact that the merging UI is a pile of garbage is HAVE A SINGLE PERSON ALWAYS DO THE MERGE. Excuse me? The whole point of a distributed revision control system is so I don't have to have a single choke point. That's the definition of distributed.

Then there was the KDE disaster: http://jefferai.org/2013/03/29/distillation/

Yeah, the root fault wasn't Git. However, at no point did Git flag that something was going horribly wrong as the repository got corrupted and deleted. Other distributed SCM systems I have used tend to squawk very loudly if something comes off disk wrong.

Maybe the underlying git data structures are fine, but, man, the UI is a pile of crap.

And, I won't even get into rebase, because that seems to be a religious argument.

[smharris65]

The issues in the randyfay.com post are due to a misunderstanding when using git as a "centralized" repo like SVN. Git, by design, does not enforce a central repo even if you designate one logically. These issues can be completely avoided if you merge the right way:

http://tech.novapost.fr/merging-the-right-way-en.html

[pjc50]

Well, that confirms that the "obvious" workflow of "git pull" is dangerous. At least it explains all the spurious merges. Why on earth did it ship with this broken design? Why doesn't git pull do the right thing by default?

[judk]

Yup, and Windows is broken because ctrl-c copies text instead of killing a process.

Why doesn't Windows do the right thing by default?

Oh, its because a different system behaves differently.

DVCS is fundamentally more complex than VCS.

[craigching]

I believe you can flip a switch to turn on only allowing FF merges which should alleviate the situation. Certainly FF merges make a lot of things easier and "cleaner".

I guess maybe the reason git doesn't do this by default might be because the idea of rebasing early on (the "omg you're overwriting history in a RCS!!!!!") was a bit taboo and it's taken time for people to get used to the idea. Note that I'm just speculating about that, I did follow the git discussion early on and I know that people then (and still are to some degree) afraid of "rewriting history" (note that I quote that because I don't really see it that way).

[taeric]

I'm not sure I follow. The advice for the "single person always do the merge" is essentially make sure the people doing the merges are experts. These mistakes do not seem like the kind of thing I have heard of experts doing.

Seriously, you can not call yourself a git expert, if you think rebase is a difficult thing to explain.

Might you sometimes make mistakes? Sure. I hardly see this as a systemic thing, though.

The mirror shenanigans I agree suck. Not sure what the real takeaway is there, other than don't rely on mirror as a good form of backup.

[jamesgeck0]

So, the solution to the fact that the merging UI is a pile of garbage is HAVE A SINGLE PERSON ALWAYS DO THE MERGE. Excuse me?

That isn't what the post advocates. He says that having a single person approve the pull request is a good idea, but approving the pull isn't the same thing as manually doing a merge. Projects I've worked on required that the submitter merge master into their branch before their PR would be accepted.