git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Riesen <raa.lkml@gmail.com>
To: Jay Soffian <jaysoffian@gmail.com>
Cc: Jeff King <peff@peff.net>,
	Joshua Jensen <jjensen@workspacewhiz.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Sharing a massive distributed merge
Date: Thu, 17 Mar 2011 19:48:54 +0100	[thread overview]
Message-ID: <AANLkTi=Fnacc9JamGdOEYhHY8PJgaidSLmif_z5Qdfp0@mail.gmail.com> (raw)
In-Reply-To: <AANLkTinQYjq=NiHK6MK0tA5AEE7=NCg8kthJT9Xz=xNk@mail.gmail.com>

On Thu, Mar 17, 2011 at 18:58, Jay Soffian <jaysoffian@gmail.com> wrote:
> 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?

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

  reply	other threads:[~2011-03-17 18:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-16 20:12 Sharing a massive distributed merge Joshua Jensen
2011-03-17  5:21 ` Jay Soffian
2011-03-17  6:38   ` Jeff King
2011-03-17  7:04     ` Jay Soffian
2011-03-17  7:30       ` Jeff King
2011-03-18  5:49         ` Jeff King
2011-03-24  3:03           ` Joshua Jensen
2011-03-17  8:53     ` Alex Riesen
2011-03-17 14:10       ` Jay Soffian
2011-03-17 14:54         ` Alex Riesen
2011-03-17 17:58           ` Jay Soffian
2011-03-17 18:48             ` Alex Riesen [this message]
2011-03-17 19:15               ` Jeff King
2011-03-17 19:53                 ` Alex Riesen
2011-03-17 20:54                 ` Junio C Hamano
     [not found]   ` <10061287.5697.1300343903667.JavaMail.trustmail@mail1.terreactive.ch>
2011-03-17  7:51     ` Where do all the tips go? (Was: Re: Sharing a massive distributed merge) Victor Engmark
2011-03-17  8:01       ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTi=Fnacc9JamGdOEYhHY8PJgaidSLmif_z5Qdfp0@mail.gmail.com' \
    --to=raa.lkml@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jaysoffian@gmail.com \
    --cc=jjensen@workspacewhiz.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).