Hi List, At $dayjob we maintain internal forks of the a number of upstream repositories. Unsurprisingly updating these forks can be extremely problematic, especially when it's only one person doing the merge. Fortunately most of us are in the same physical location so it is possible to drag in someone who knows more about the code than the person merging but I can't see that scaling with remote developers. Is there any way where we could share the conflict resolution around but still end up with a single merge commit. I'm thinking of something like the following workflow developer A: git merge $upstream <conflicts> git mergetool ... <resolves some of the conflicts> git commit -m "WIP: Merge upstream" --something-like--all-but-not developer B: git pull developer_A git reset HEAD^ <at this point it's be nice if developer B's work tree and index were in the same state as developer A's before they ran 'git commit'> git mergetool ... <resolves the conflicts that they know about> git commit -m "WIP: Merge upstream" --something-like--all-but-not developer A: git pull developer_B git reset HEAD^ git mergetool .... <finishes off anything left> git commit <It'd be really nice if MERGE_MSG was retained through all of this> git push Any thoughts on if something like this is currently possible? Is this something other git users would find useful? Thanks, Chris -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html