Chris Packham <judge.pack...@gmail.com> writes: > Is there any way where we could share the conflict resolution around > but still end up with a single merge commit.
One idea that immediately comes to me is to use something like "rerere" (not its implementation and storage, but the underlying idea) enhanced with the trick I use to fix-up merges in my daily integration cycle (look for "merge-fix" in howto/maintain-git.txt in Documentation/). > developer A: > git merge $upstream > <conflicts> And then commit this immediately, together with conflict markers (i.e. "commit -a"), and discard it with "reset --hard HEAD^" *after* storing it somewhere safe. And then redo the same merge, resolve the conflicts and commit the usual way. The difference between the final conflict resolution and the original conflicted state can be used as a reference for others to redo the same conflict resolution later elsewhere. That can most easily be done by creating a commit that records the final state whose parent is the one you recorded the initial conflicted state. So, the "recording" phase may go something like this: git checkout $this git merge $that git commit -a -m 'merge-fix/$this-$that preimage' git branch merge-fix/$this-$that git reset --hard HEAD^ git merge $that edit git commit -a -m 'merge $that to $this' git checkout merge-fix/$this-$that git read-tree -m -u HEAD $this git commit -a -m 'merge-fix/$this-$that postimage' The rough idea is "git show merge-fix/$this-$that" will show the "patch" you can apply on top of the conflicted state other people would get by running "git merge $that" while on "$this" branch. "rerere" essentially does the above recording (and replaying) per-path and it comes with a clever indexing scheme to identify which previous conflict resolution would apply to the conflicts you see in your working tree. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html