4 ms·
Ask HN: How often do you have merge conflicts?
I'm thinking about a tool to detect merge conflicts as soon as possible (realtime ?).
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.
- deleted 14y ago[deleted]
- seyz 14y agoThanks for your answer but I think that my question was not clear enough. I was talking about merge conflict detection... in source code. Often detected with a tool like git, mercurial, subversion, etc.
- bkanber 14y agoSmall team manager here -- not often at all. Most people are working on different components simultaneously so conflicts rarely arise.
- seyz 14y agoYes. 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.
- ZachWick 14y agoSmall team (~10) of developers: I rarely encounter merge conflicts due to our method of doling out tasks. We generally try to group tasks together based on similarities, and our codebase is very modular.
- seyz 14y agoGreat. Thanks for this comment.
- swalberg 14y agoWe 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?
- seyz 14y agoIf 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 ?
- swalberg 14y agoMaybe 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.
- cjbprime 14y agoI'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.
- powatom 14y agoSmall 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.