From: Junio C Hamano <gitster@pobox.com>
To: John Keeping <john@keeping.me.uk>
Cc: git@vger.kernel.org, Ted Felix <ted@tedfelix.com>
Subject: Re: [PATCH 2/2] rebase: omit patch-identical commits with --fork-point
Date: Tue, 15 Jul 2014 15:06:01 -0700 [thread overview]
Message-ID: <xmqqmwcatgza.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <01d69c566e04256fb0321ab9685d1f05a80cb41d.1405451643.git.john@keeping.me.uk> (John Keeping's message of "Tue, 15 Jul 2014 20:14:03 +0100")
John Keeping <john@keeping.me.uk> writes:
> When the `--fork-point` argument was added to `git rebase`, we changed
> the value of $upstream to be the fork point instead of the point from
> which we want to rebase. When $orig_head..$upstream is empty this does
> not change the behaviour, but when there are new changes in the upstream
> we are no longer checking if any of them are patch-identical with
> changes in $upstream..$orig_head.
>
> Fix this by introducing a new variable to hold the fork point and using
> this to restrict the range as an extra (negative) revision argument so
> that the set of desired revisions becomes (in fork-point mode):
>
> git rev-list --cherry-pick --right-only \
> $upstream...$orig_head ^$fork_point
>
> This allows us to correctly handle the scenario where we have the
> following topology:
>
> C --- D --- E <- dev
> /
> B <- master@{1}
> /
> o --- B' --- C* --- D* <- master
>
> where:
> - B' is a fixed-up version of B that is not patch-identical with B;
> - C* and D* are patch-identical to C and D respectively and conflict
> textually if applied in the wrong order;
> - E depends textually on D.
>
> The correct result of `git rebase master dev` is that B is identified as
> the fork-point of dev and master, so that C, D, E are the commits that
> need to be replayed onto master; but C and D are patch-identical with C*
> and D* and so can be dropped, so that the end result is:
>
> o --- B' --- C* --- D* --- E <- dev
>
> If the fork-point is not identified, then picking B onto a branch
> containing B' results in a conflict and if the patch-identical commits
> are not correctly identified then picking C onto a branch containing D
> (or equivalently D*) results in a conflict.
>
> This change allows us to handle both of these cases, where previously we
> either identified the fork-point (with `--fork-point`) but not the
> patch-identical commits *or* (with `--no-fork-point`) identified the
> patch-identical commits but not the fact that master had been rewritten.
>
> Reported-by: Ted Felix <ted@tedfelix.com>
> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---
> git-rebase--am.sh | 6 ++++--
> git-rebase--interactive.sh | 2 +-
> git-rebase.sh | 7 ++++---
> 3 files changed, 9 insertions(+), 6 deletions(-)
Can we have some tests, too?
The changes look correct from a cursory reading.
Thanks.
next prev parent reply other threads:[~2014-07-15 22:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-03 15:14 [BUG] rebase no longer omits local commits Ted Felix
2014-07-03 19:09 ` John Keeping
2014-07-03 22:25 ` John Keeping
2014-07-07 17:56 ` Junio C Hamano
2014-07-07 21:14 ` John Keeping
2014-07-15 19:14 ` [PATCH 1/2] rebase--am: use --cherry-pick instead of --ignore-if-in-upstream John Keeping
2014-07-15 19:14 ` [PATCH 2/2] rebase: omit patch-identical commits with --fork-point John Keeping
2014-07-15 19:48 ` Ted Felix
2014-07-15 22:06 ` Junio C Hamano [this message]
2014-07-16 19:23 ` [PATCH v2 1/2] rebase--am: use --cherry-pick instead of --ignore-if-in-upstream John Keeping
2014-07-16 19:23 ` [PATCH v2 2/2] rebase: omit patch-identical commits with --fork-point John Keeping
2014-07-16 20:26 ` Junio C Hamano
2014-07-16 21:27 ` John Keeping
2014-07-16 21:36 ` Ted Felix
2014-07-17 9:36 ` John Keeping
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=xmqqmwcatgza.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=john@keeping.me.uk \
--cc=ted@tedfelix.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.