Resolving a part of conflict in a file in GIT

The scenario that i would like to discuss is I have a merge repository which is开发者_Go百科 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.

---

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.