Hacker News Reader

Comment by WolfeReader | Hacker News Reader

No. The advantage of Git (and Darcs, Hg, and others) over SVN/TFS is twofold:

1. A much better merging strategy which remembers previous conflict resolutions. This is possible in both diff and snapshot VCS's.

2. Distributed repositories. Instead of storing history in one centralized server, which is prone to several kinds of failure, Git/Darcs/Hg/Fossil etc. all replicate history to each client by default. This makes it very difficult to actually lose code or history, which definitely happened in older centralized systems.

View on HN

> which remembers previous conflict resolutions

IMHO this is far from the truth. git is a mess with conflicts and nothing is remembered. When you rebase an old branch a few times, you stumble upon merge conflicts every time you have to rebase that old code. It's really infuriating.

I think git became popular for 2 reasons: cheap branches, and Linus Torvalds.

> The git rerere functionality is a bit of a hidden feature. The name stands for “reuse recorded resolution” and, as the name implies, it allows you to ask Git to remember how you’ve resolved a hunk conflict so that the next time it sees the same conflict, Git can resolve it for you automatically.

https://git-scm.com/book/en/v2/Git-Tools-Rerere

Git does indeed remember conflict resolutions (if the ReReRe feature is enabled), but in practice it's only helped me a handful of times.

(And I am big on obsessively rebasing and cleaning up history before pushing a change.)

Ah, you're a rebaser. That's why you have this issue. As someone who prefers merge commits, this has been entirely a non-issue for me.

Rebasing is very important for people who don't understand how git works.

Merging works fine, as long as Git knows how to resolve the ancestry. Rebasing breaks that (save for hacks like rerere).

Cheap branches are important. Git is no worse and in most cases far better than any other VCS when it comes to conflicts.

If you are getting conflicts over and over you should change your pattern of use to stop causing them, it's quite possible to do.

You say that as if using git isn't a team sport. I only have control over my behavior, and that goes double for what happens after $(git pull) or its $(git rebase) friend

If only there were a way to influence the behavior of other humans...

I've never had any major frustrations with 'lots of conflicts'. There's something peculiar about what you are doing.

I would sit down and write down what the 'features/benefits' are of your current git workflow. Then you can brainstorm about things you can change about what you are doing to get those benefits without the frustrations (like maybe you don't need to rebase as much or at all, or you can avoid rebasing work branches and just squash the final commit on top of main, I don't know what you are doing but my point is there are endless variations of how to collaborate on git and lots of them don't cause 'lots of conflicts'), and then work with your team to get them. When you are successful they will thank you for making their lives less frustrating. Or you can be secure in the belief that there's nothing you can do, either way.

Being able to merge code is important, distributed repositories is nice but nobody switched to get that.

Apart from making merging much much less painful, the huge selling point was that SVN was extremely slow. Changing branches required chatting with the server in most cases, and could take a minute or two. You couldn't just switch back and forth between branches.

"Changing branches required chatting with the server in most cases, and could take a minute or two."

Which is directly solved by being a DVCS, yes. Your second paragraph contradicts your first.

Darcs and Pijul can change branches very rapidly despite being diff-based, because they too are DVCS (and the inverse patches basically already got computed upon commit, so it's easy on the CPU).

But Darcs replaces slow branch changes with something that no other VCS has (that I'm aware of), slow commits! Making a commit can take 5 minutes!

Reply on news.ycombinator.com