git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: geoffrey.russell@gmail.com, sverre@rabbelier.nl,
	Johannes Sixt <j.sixt@viscovery.net>,
	Miklos Vajna <vmiklos@frugalware.org>,
	git@vger.kernel.org
Subject: Re: Guided merge with override
Date: Wed, 18 Jun 2008 09:31:13 -0700	[thread overview]
Message-ID: <7viqw6zovi.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.DEB.1.00.0806181627260.6439@racer> (Johannes Schindelin's message of "Wed, 18 Jun 2008 16:28:42 +0100 (BST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Thinking about this again, there could be a problem: in case of complex 
> merges, it is possible that the sides are switched around for an 
> intermediate merge.  IOW you'd expect it to take "theirs", but it really 
> takes "ours".

Are you thinking about using this in merge-recursive?

I do not think there is any reason to use this during intermediate merges
done inside merge-recursive.  The point of recursive merge is to create a
neutral intermediate merge result, with conflicts and all.  Do this only
during the final round and you are fine (for some definition of "fine" ---
I still have not heard a convincing argument as to why it is even a good
thing to be able to take one side for only parts that did conflict, while
taking the change from the other side in places that did not).

  reply	other threads:[~2008-06-18 16:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-16  4:16 Guided merge with override Geoff Russell
2008-06-16  9:25 ` Miklos Vajna
2008-06-16 10:16   ` Johannes Sixt
2008-06-16 21:16     ` Miklos Vajna
2008-06-16 22:21     ` Sverre Rabbelier
2008-06-16 22:45       ` Geoff Russell
2008-06-17 20:04         ` Junio C Hamano
2008-06-18 15:19           ` Johannes Schindelin
2008-06-18 15:28             ` Johannes Schindelin
2008-06-18 16:31               ` Junio C Hamano [this message]
2008-06-18 19:29                 ` Johannes Schindelin
2008-06-20  7:38                 ` [PATCH 1/2] git-merge-file --ours, --theirs Junio C Hamano
2008-06-20  7:48                   ` [PATCH 2/2] git-merge-recursive-{ours,theirs} Junio C Hamano
2008-06-20 12:58                     ` Johannes Schindelin
2008-06-21  9:46                       ` Junio C Hamano
2008-06-21 16:29                         ` Johannes Schindelin
2008-06-21 16:56                         ` Jakub Narebski
2008-06-17  6:16       ` Guided merge with override Johannes Sixt
2008-06-17  8:53         ` Sverre Rabbelier
2008-06-17  9:48           ` Johannes Schindelin
2008-06-17  9:53             ` Sverre Rabbelier
2008-06-17 10:17               ` Johannes Schindelin

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=7viqw6zovi.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=geoffrey.russell@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=j.sixt@viscovery.net \
    --cc=sverre@rabbelier.nl \
    --cc=vmiklos@frugalware.org \
    /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).