Re: Sharing merge conflict resolution between multiple developers
On Mon, Aug 11, 2014 at 04:59:15PM +1200, Chris Packham wrote: > 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 This came up once a while back. Here's the discussion: http://thread.gmane.org/gmane.comp.version-control.git/169187 I proposed a solution there where developers push their partial resolutions, and the integrator (or just "next person" if it is a chain of developers) uses "git checkout" to pull the fixes. But note that I never actually _used_ that in practice. It was a thought experiment, so there may be gotchas. -Peff -- 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
Re: Sharing merge conflict resolution between multiple developers
On Mon, Aug 11, 2014 at 4:29 PM, Chris Packham wrote: >> So, the "recording" phase may go something like 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. > > So how would someone else pickup that postimage and use it? > > git checkout $this > git merge $that > git fetch $remote ':/merge-fix/$this-$that postimage' > git show ':/merge-fix/$this-$that postimage' | git apply (or patch -p1) For a simpler case that would work, but because we are not saving just a patch but two full trees to compare (i.e. merge-fix/$this-$that is the postimage, its ^1 is the preimage), you should be able to use the three-way merge in a similar way cherry-pick works. In fact, that is how rerere replays the recorded resolution, not with a "patch -p1". -- 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
Re: Sharing merge conflict resolution between multiple developers
On Tue, Aug 12, 2014 at 6:44 AM, Junio C Hamano wrote: > Chris Packham 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 >> > > 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. So how would someone else pickup that postimage and use it? git checkout $this git merge $that git fetch $remote ':/merge-fix/$this-$that postimage' git show ':/merge-fix/$this-$that postimage' | git apply (or patch -p1) edit > > "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. I feel a toy patch coming on. -- 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
Re: Sharing merge conflict resolution between multiple developers
IIUC, this might help, http://www.mail-archive.com/git@vger.kernel.org/msg56418.html http://www.mail-archive.com/git@vger.kernel.org/msg56468.html -- 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
Re: Sharing merge conflict resolution between multiple developers
Le 11 août 2014 07:50, "Christian Couder" a écrit : > > This should be possible using "git imerge" which is separate tool. Sorry I sent the above using the gmail app on my mobile phone and unfortunately I can't make it send plain text emails. (Emails which are not plain text are rejected by vger.kernel.org.) Best, Christian. -- 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
Re: Sharing merge conflict resolution between multiple developers
Chris Packham 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 > 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
Sharing merge conflict resolution between multiple developers
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 git mergetool ... git commit -m "WIP: Merge upstream" --something-like--all-but-not developer B: git pull developer_A git reset HEAD^ git mergetool ... git commit -m "WIP: Merge upstream" --something-like--all-but-not developer A: git pull developer_B git reset HEAD^ git mergetool git commit 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
