git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Paolo Bonzini <bonzini@gnu.org>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] provide a new "theirs" strategy, useful for rebase --onto
Date: Sun, 08 Jun 2008 01:16:34 -0700	[thread overview]
Message-ID: <7vmylwl4t9.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <484B49D5.8080708@gnu.org> (Paolo Bonzini's message of "Sun, 08 Jun 2008 04:54:13 +0200")

Paolo Bonzini <bonzini@gnu.org> writes:

>> Because original E' was an amend of E, its log message explained
>> everything E did and more.  You cannot leave that same commit message in
>> E''.  What you did in E was already explained in the history, so now you
>> would want to talk about the incremental change on top of it when you
>> desribe E''.  For that, replaying of E' must stop to allow you to fix up
>> the log message.
>
> Yes, I had suggested in the original thread to follow up with a "git
> rebase -i" to fix the commit message, because "git-rebase--interactive
> --help" did not show a -s option.  However, I found out that it does
> support it, so it is probably better to use "git rebase -i -s theirs
> --onto ..." directly.

Yeah, but that is only about the commit log message.  The issue of
recording a wrong tree when commits X and Y exist is not alleviated, is
it?

> You mean that I should a) drop the example from git-rebase.1, b)
> reword it to clarify it, c) drop the patch completely?

I have to say that the rebase example is too misleading --- unless it is
accompanied by a lot of disclaimers, its risk to give broken result to
people probably is worse than the benefit. I am afraid that we would need
a lot better use case to justify the use of "theirs" than what you wrote.

I have occasionally seen valid situations to use "ours", but I personally
haven't been in a situation that merge using "theirs" is a good solution.
Obviously if you start from a wrong branch, you should be in the situation
that you would want to merge using "theirs", just like when you started
from the right branch and would use "ours", but in practice that never
happened to me as far as I can recall.  I am not sure where this asymmetry
comes from.

On the other hand, I've sometimes heard people say "when I get a merge
conflict, I'd want to discard what I did _only in the conflicted part_."
I am not sure if such a conflict resolution makes much sense in practice,
but perhaps people know that their changes are worthless crap anyway, and
do not even care about their work themselves, to the point that they would
rather discard what they did than spend more time to fix them up properly.
Whether that makes sense or not, what they want is different from "theirs"
(which is opposite of "ours"); they want to keep their own changes for
parts that did not conflict, and give up what they did only in the
conflicted part.  Perhaps such a kind of mixed conflict resolution should
be supported under the name of "theirs", even though that would make
"ours" and "theirs" _not_ the opposite of each other.  I dunno...

  reply	other threads:[~2008-06-08  8:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-06 10:59 [PATCH] provide a new "theirs" strategy, useful for rebase --onto Paolo Bonzini
2008-06-06 11:27 ` Peter Karlsson
2008-06-06 11:28 ` Paolo Bonzini
2008-06-06 14:14 ` Miklos Vajna
2008-06-06 23:08 ` Junio C Hamano
2008-06-08  2:54   ` Paolo Bonzini
2008-06-08  8:16     ` Junio C Hamano [this message]
2008-06-08 13:38       ` Paolo Bonzini
2008-06-08 20:59         ` Junio C Hamano
2008-06-08 23:06           ` Paolo Bonzini

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=7vmylwl4t9.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=bonzini@gnu.org \
    --cc=git@vger.kernel.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).