"Curtin, Eric" <Eric.Curtin@xxxxxxxx> writes: > Hi Guys, > > Sometimes in our private git instance in the company I work for we > merge branches that have been forked for months and there can be > several or more people involved in the conflict resolution. > > At the moment we have two options: > > - One person, a branch manager, solves them by ringing people, holding > meetings, using best judgement, etc. > - Somebody solves the conflicts they are involved with, marks > everything as resolved and pushes (leaving <<< ==== >>>> delimiters in > for unsolved conflicts) for the next person to continue. This sort of > works although you falsely mark everything as resolved, leaving merge > tools useless and many broken, unbuildable commits around in the > branch. > > Note: rebase and squashing commits is banned in our org, basically > anything that would rewrite history on a remote branch. > > Is there any existing or upcoming feature in git that could help make > conflict resolution a more distributed, collaborative kind of task? That'd be great. What we sometimes do when such a case appears (rather rarely due to frequent merges, I admit) is to copy /entire/ git directory holding the merge in progress to the next person in charge. This is the only way that I'm aware of that keeps ability to do things like: $ f=foo.cc; git diff :1:./$f :3:./$f and $ f=foo.cc; git diff :1:./$f :2:./$f that helps a lot with complicated conflicts. So, if such a solution ever appears, it'd apparently need a method of sharing or re-creating (parts of) the index? Doesn't sound as an easy problem. -- Sergey
