git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Sharing merge conflict resolution between multiple developers

From
Chris Packham <judge.packham@gmail.com>
Date
Aug 11, 2014, 23:29 UTC
Message-ID
<CAFOYHZAaF+Dve1DwUUd-k6Nh3+nOZzNVUQAD0quN4crRAjfCLQ@mail.gmail.com>
In-Reply-To
<xmqqd2c67tok.fsf@gitster.dls.corp.google.com>
On Tue, Aug 12, 2014 at 6:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 43 quoted lines
> Chris Packham <judge.packham@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.
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
Show 5 quoted lines
>
> "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.
Previous: Junio C HamanoNext: Junio C Hamano
Message 3 of 10 in “Sharing merge conflict resolution between multiple developers”
  1. Chris PackhamAug 11, 2014
  2. Junio C HamanoAug 11, 2014
  3. Chris PackhamAug 11, 2014
  4. Junio C HamanoAug 12, 2014
  5. Nico WilliamsAug 11, 2014
  6. Jeff KingAug 17, 2014
  7. Signinig a commit with multiple signaturesJason Pyeron, Aug 17, 2014
  8. Jeff KingAug 19, 2014
  9. Jason PyeronAug 19, 2014
  10. Christian CouderAug 11, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.