Hacker News new | ask | show | jobs
by JTyQZSnP3cQGa8B 493 days ago
> 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.
5 comments
reshlo 493 days ago
> 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

link
kelnos 493 days ago
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.)

link
WolfeReader 492 days ago
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.
link
ltbarcly3 492 days ago
Rebasing is very important for people who don't understand how git works.
link
Nullabillity 493 days ago
Merging works fine, as long as Git knows how to resolve the ancestry. Rebasing breaks that (save for hacks like rerere).
link
ltbarcly3 493 days ago
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.

link
mdaniel 493 days ago
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
link
ltbarcly3 493 days ago
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.

link