

Ask HN: How often do you have merge conflicts? - seyz

I'm thinking about a tool to detect merge conflicts as soon as possible (realtime ?).<p>Before that, I would like to know if you have often merge conflicts. If yes, these merge conflicts often become a "merge hell" ?<p>Would you potentialy be interested by this tool ?<p>EDIT: I'm talking about a merge conflict in the source code of a project. Often detected with SCMs like git, hg, svn, etc.
======
cjbprime
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.

------
swalberg
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?

~~~
seyz
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 ?

~~~
swalberg
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.

~~~
seyz
Ok great. Thanks for your comments. Can I ask you how much developers
(approximatively) work on your company ?

~~~
swalberg
On my team, 6. On another team, 20ish.

------
powatom
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.

------
ZachWick
Small 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
Great. Thanks for this comment.

------
bkanber
Small team manager here -- not often at all. Most people are working on
different components simultaneously so conflicts rarely arise.

~~~
seyz
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.

