Ask HN: How often do you have merge conflicts?

https://news.ycombinator.com/item?id=4495667

by seyz • 14 years ago

5 11 14 years ago

news.ycombinator.com

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.

bkanber• 14 years ago

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

seyz4• 14 years ago

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.

ZachWick• 14 years ago

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.

seyz4• 14 years ago

Great. Thanks for this comment.

swalberg3• 14 years ago

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?

seyz4• 14 years ago

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 ?

swalberg3• 14 years ago

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.

cjbprime• 14 years ago

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.

powatom• 14 years ago

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.

Ask HN: How often do you have merge conflicts?

Related Stories