Re: why "git rebase" searching the duplicate patches in <upstream branch> rather than in <new base branch>?

From: Junio C Hamano <gitster@pobox.com>
To: Andy Zhang <zhgdrx@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: why "git rebase" searching the duplicate patches in <upstream branch> rather than in <new base branch>?
Date: Mon, 19 Jul 2021 15:23:18 -0700	[thread overview]
Message-ID: <xmqqmtqij63t.fsf@gitster.g> (raw)
In-Reply-To: <CAJcwCMPHFNHi5i=xRg=GAJL5HiUfKu_KUPwYwELofLLtOAK1bg@mail.gmail.com> (Andy Zhang's message of "Tue, 20 Jul 2021 01:45:01 +0800")

Andy Zhang <zhgdrx@gmail.com> writes:

> why "git rebase" searching the duplicate patches in <upstream
> branch> rather than in <new base branch>?
>
> hi, all:
>
>  I am reading the help of "git rebase", it says:
>     "If the upstream branch already contains a change you have made
> (e.g., because you mailed a patch which was applied upstream), then
> that commit will be skipped. "
>
>  But, because we are applying commits to <new base branch> rather than
> to <upstream branch>, I really don't understand why we are searching
> the duplicate patches in <upstream branch> rather than in <new base
> branch>?

It is either a design bug or a documentation bug, or both ;-)

I do think it makes sense to skip commits from the branch we are
rebasing that have equivalent commits in the upstream, as it is
expected that upstream might have already applied/cherry-picked some
of the changes you are rebasing, and you do not want to use the same
change twice.

When we are transplanting a series of commits from an old base to
totally unrelated base using the --onto option, e.g. when replaying
the contents of 'topic' relative to 'next' down to 'master' in your
topology, however,

> Old tree is:
>
> o---o---o---o---o  master
>     \
>      o---o---o---o---o  next
>                       \
>                        o---o---o  topic

it is not necessarily obvious where to stop digging back at.  In the
above picture where 'master' and 'next' have ancestry relationship,
we could try to see if the three commits on 'topic' branch being
replayed match any of the commits in next..master range, but when
using the --onto option, there does not have to be any relationship
between the <upstream> and <new base> (they do not have to share a
root commit).  So from that point of view, it probably makes sense
to default to --no-reapply-cherry-picks when --onto is used, while
defaulting --reapply-cherry-picks when --onto is not used.