3

The scenario that i would like to discuss is I have a merge repository which is shared repository where developers will cd into to resolve merge conflicts.

  1. there are 2 or more merge conflicts in a single file.
  2. each conflict has to be resolved different user.
  3. each developer cd into this repository to resolve merge conflict.
  4. let say foo.c has 3 merge conflicts
  5. one user resolves a single conflict in foo.c and does save in a graphical merge tool

Now GIT recognizes this as "git add" though there are still conflicts in other parts of the file. Then if another developer does "git mergetool foo.c" it doesnt pop up foo.c for conflicts.

Is there a graphical tool that resolves this issue. Allows multiple users to resolve and save conflicts in the same file.

Senthil A Kumar
  • 10,306
  • 15
  • 44
  • 55

1 Answers1

1

This scenario doesn't really make sense...

Firstly, if there is a conflict, then that conflict only exists on the one merge commit, which doesn't exist yet! (It's still on the user's machine, possibly in the index, but certainly not even in their local tree).

The other users do not have a conflict at all, until they do a merge, or rebase.

Supposing you do have three users doing the exact same merge, for whatever the reason may be, and therefore they have the same conflicts.

Lets further suppose that they, as you suggest, each have a conflict that only they can reconcile, then they should each rebase their work on the latest version of the code, and reconcile any conflicts in the process.

In other words, the situation you seem to be describing is as follows: (Correct me if I'm wrong):

  1. We have three devs, Charlie, John, and Matt, who are all working off the master branch, which is at commit aaaaaaa.
  2. They all also work on an 'unstable' branch, which is at commit bbbbbbbb, which has diverged from 'master'.
  3. They all, at the same time, decide that they should merge the 'unstable' branch into 'master', individually.
  4. They all, at the same time, realise that they have commits they can't reconcile.

Ideally, what should be done in this situation, is that 'unstable' should be merged in by any developer who knows how to do the merge. Perhaps they will choose to merge it a few commits at a time, rather than directly merge the two heads, or perhaps they choose to rebase the whole thing - whatever, but only one developer needs to do this.

The more frequently this is done, the easier the merge/rebase operation will be.

The remaining developers will then be able to use the merge commit.

Arafangion
  • 11,517
  • 1
  • 40
  • 72
  • Well this is not what am thinking of....to be better explained. Am trying to merge 2 bare repository instead of merging to branches in actual data repository. Merging 2 bare repositories is not possible as there is not working directory, so i create a clone from 1 bare repo (A) called merge_A and pull changes from 2 bare repo (B), so merge conflicts occur in merge_A. Now lets say foo.c has 3 conflicting lines, and 3 devs have to cd into merge_A and resolve it. – Senthil A Kumar Dec 01 '10 at 10:29
  • Is there a reason why those three devs can't do the merge in their own repositories? Why do they need to huddle around the one tiny screen and fight over the keyboard? The conflicts you are talking about will *rarely* be just the one file, it'll be half the project fighting over which types to use! – Arafangion Dec 01 '10 at 11:08
  • This project is a huge one, spread across countries, so i will making this project as shared repo (660) so each dev will cd into this shared path and make the changes. – Senthil A Kumar Dec 02 '10 at 12:27
  • Spread across countries? cd into the shared path? Something sounds confused here. :( (The different countries aren't even *tangentially* relevant to this conversation!) – Arafangion Dec 02 '10 at 12:41