Re: Sharing a massive distributed merge

From: Alex Riesen <raa.lkml@gmail.com>
Date: Mar 17, 2011, 18:48 UTC
Message-ID: <AANLkTi=Fnacc9JamGdOEYhHY8PJgaidSLmif_z5Qdfp0@mail.gmail.com>
In-Reply-To: <AANLkTinQYjq=NiHK6MK0tA5AEE7=NCg8kthJT9Xz=xNk@mail.gmail.com>

On Thu, Mar 17, 2011 at 18:58, Jay Soffian <jaysoffian@gmail.com> wrote:

Show 21 quoted lines

> On Thu, Mar 17, 2011 at 10:54 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
>> On Thu, Mar 17, 2011 at 15:10, Jay Soffian <jaysoffian@gmail.com> wrote:
>>> On Thu, Mar 17, 2011 at 4:53 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
>>>> What if they just revert the rest? Reset the files to their states before
>>>> merge.
>>>
>>> That's the same as checkout --ours which is sometimes a valid
>>> resolution for a file. So I think "I resolved this file" needs to be
>>> recorded either way.
>>
>> But it is recorded: the file is different now!
>
> Let's say we have:
>
>  a---b---c
>   \
>    d---e
>
> $ git checkout c
> $ git merge e  # files "foo" and "bar" conflict
> $ git checkout --ours foo  # correct resolution for foo

I doubt that'll be a correct resolution. Someone have to look at the conflict markers, right?

Show 10 quoted lines

> $ git checkout HEAD bar    # "revert" bar to its pre-merge state
> $ git add foo
> $ git commit
>
> In the merge commit, both "foo" and "bar" are identical to their
> pre-merge state. There's no effective difference between the "checkout
> --ours" and "reset the files to their states before the merge".
>
> So again, how do you tell the difference here?
>

The difference may be simple (git diff --name-status c^..), it just does not help. The merge commit will record the branches as merged and an attempt by the maintainer to merge this partial merge commit will just fast-forward. So it was a stupid idea either way.

How about not to record the merge as a merge commit, but just resolve as much as possible, commit _only_ what was resolved, and revert everything else. Including files merged cleanly, as the last merge by maintainer will have to clean merge them anyway. And of course, commit as normal:

  $ git merge --squash --no-commit e

The maintainer will have to collect the branches with resolved conflicts, and fix up the conflicts left.

Could be less work, given good coordination of who resolves what...