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

On Tue, Jul 20, 2021 at 6:23 AM Junio C Hamano [off-list ref] wrote:

Andy Zhang [off-list ref] writes:

quoted

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 ;-)

It should NOT be a documentation bug, because, in my experiment, I
observe that, "git"'s behavior is exactly the same as documentation.
So, it should be "work as design".

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,

quoted

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.