Ask HN: How often do you have merge conflicts?
6 comments
[deleted](1)
I'm a Linux kernel maintainer. Conflicts happen, but git makes the resolution straightforward, and can even try different merge strategies (git merge -X "ours"/"octopus"/etc). I wouldn't ever describe it as having been "merge hell". Maybe if it were a different SCM.
Linux has the "linux-next" tree, which merges feature branches together every night; Stephen Rothwell fixes up context conflicts in that tree which saves a lot of time, and the e-mails he generates also function as a notification that the code you're working with has conficts.
Having a nightly merge of all feature branches seems like the right kind of granularity of notification to me.
Linux has the "linux-next" tree, which merges feature branches together every night; Stephen Rothwell fixes up context conflicts in that tree which saves a lot of time, and the e-mails he generates also function as a notification that the code you're working with has conficts.
Having a nightly merge of all feature branches seems like the right kind of granularity of notification to me.
We get them regularly, maybe a couple a week. But for the most part you know what you are getting into. It usually comes up in code review that there's going to be a problem.
What I don't get though is how a realtime notification would help me. If my editor started flashing that I was in conflict, what would I do differently?
What I don't get though is how a realtime notification would help me. If my editor started flashing that I was in conflict, what would I do differently?
If you are notified in realtime, the merge conflict will be based on approximatively 1 line. It's easier to resolve it.
Suppose the "developer 1" working on a big feature during two weeks and a "developer 2" working on another big feature. If you detect the merge conflict at the end of the sprint, it can be difficult to resolve. Don't you think ?
Suppose the "developer 1" working on a big feature during two weeks and a "developer 2" working on another big feature. If you detect the merge conflict at the end of the sprint, it can be difficult to resolve. Don't you think ?
Maybe the nature of our conflicts is different. Resolving things at the end is rarely that big of a hassle for us. I'd rather do it all at once after I'm done the work than interrupt my train of thought to fix it at the time.
Small team working on fairly big systems - we rarely have any merge conflicts due to the way we divide work up.
They can be a pain in the arse when something has gone wrong though - but it's not really something we spend a lot of time worrying about. If it happens we just deal with it.
They can be a pain in the arse when something has gone wrong though - but it's not really something we spend a lot of time worrying about. If it happens we just deal with it.
Small team manager here -- not often at all. Most people are working on different components simultaneously so conflicts rarely arise.
Yes. I'm pretty sure that if you have a perfect organization in your team work, there's no need to have a tool like that.
Personally, I already create a merge conflict... alone :-) But it's because I am (was ? I hope...) not well organized.
Personally, I already create a merge conflict... alone :-) But it's because I am (was ? I hope...) not well organized.
Before that, I would like to know if you have often merge conflicts. If yes, these merge conflicts often become a "merge hell" ?
Would you potentialy be interested by this tool ?
EDIT: I'm talking about a merge conflict in the source code of a project. Often detected with SCMs like git, hg, svn, etc.