Re: Sharing a massive distributed merge

From: Jay Soffian <jaysoffian@gmail.com>
Date: Mar 17, 2011, 17:58 UTC
Message-ID: <AANLkTinQYjq=NiHK6MK0tA5AEE7=NCg8kthJT9Xz=xNk@mail.gmail.com>
In-Reply-To: <AANLkTikfp_d00zrtU8kuvyUk81gGMkOXEVDNXr-hRhBU@mail.gmail.com>

On Thu, Mar 17, 2011 at 10:54 AM, Alex Riesen <raa.lkml@gmail.com> wrote:

Show 10 quoted lines

> 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 $ 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?

j.