git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
AZAndy Zhang <zhgdrx@gmail.com>
Date
Aug 1, 2021, 08:59 UTC
Message-ID
<CAJcwCMPaX4qTBfxG6UwswFXCAkGE1meX8GOFNQueKXmfHPMJ2Q@mail.gmail.com>
In-Reply-To
<xmqqmtqij63t.fsf@gitster.g>
On Tue, Jul 20, 2021 at 6:23 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 20 quoted lines
>
> 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 ;-)
>

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".

Show 30 quoted lines
> 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.
>
>
Previous: Sergey Organov
Message 7 of 7 in “why "git rebase" searching the duplicate patches in <upstream branch> rather than in <new base branch>?”
  1. Andy ZhangJul 19, 2021
  2. Felipe ContrerasJul 19, 2021
  3. Junio C HamanoJul 19, 2021
  4. Sergey OrganovJul 20, 2021
  5. Junio C HamanoJul 20, 2021
  6. Sergey OrganovJul 20, 2021
  7. Andy ZhangAug 1, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.