From: Junio C Hamano <gitster@pobox.com>
To: Sergey Organov <sorganov@gmail.com>
Cc: Andy Zhang <zhgdrx@gmail.com>, git@vger.kernel.org
Subject: Re: why "git rebase" searching the duplicate patches in <upstream branch> rather than in <new base branch>?
Date: Tue, 20 Jul 2021 08:36:33 -0700 [thread overview]
Message-ID: <xmqqczrdhu9q.fsf@gitster.g> (raw)
In-Reply-To: <87a6mhgxv4.fsf@osv.gnss.ru> (Sergey Organov's message of "Tue, 20 Jul 2021 12:04:15 +0300")
Sergey Organov <sorganov@gmail.com> writes:
> Similar problem should exist for explicitly specified <upstream> that
> might happen to have little in common with the current <branch>, right?
I do not think so. Plain-vanilla rebase is to carry forward our
changes on top of updated upstream, which means that there is
x--x--x (side)
/
---o---o---o---o---o---o (upstream)
^
(old upstream)
inherently ancestry relationship between the old upstream and the
current upstream when rebasing 'side' to 'upstream'.
> I don't actually like this.
You do not have to ;-) because I was not suggesting to change any
existing behaviour. It was merely me thinking aloud, how I might
do the feature if I were designing it from scratch now.
> Overall, it seems that we should take the <newbase> rather than
> <upstream> (that is still <upstream> when --onto is not specified), and
> apply the skipping logic from there, to whatever depth the merge-base
> will give us. If it's already implemented this way, then only the manual
> page needs to be fixed.
Sounds sensible. I didn't check what the actual code does ;-)
next prev parent reply other threads:[~2021-07-20 15:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAJcwCMPU9EhRkqeei_LnYyTJRZUQgHCvomrBbW0Qn+Jp1yhQfQ@mail.gmail.com>
2021-07-19 17:45 ` why "git rebase" searching the duplicate patches in <upstream branch> rather than in <new base branch>? Andy Zhang
2021-07-19 18:17 ` Felipe Contreras
2021-07-19 22:23 ` Junio C Hamano
2021-07-20 9:04 ` Sergey Organov
2021-07-20 15:36 ` Junio C Hamano [this message]
2021-07-20 16:44 ` Sergey Organov
2021-08-01 8:59 ` Andy Zhang
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=xmqqczrdhu9q.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=sorganov@gmail.com \
--cc=zhgdrx@gmail.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.