Re: [RFC] should `git rebase --keep-base` imply `--reapply-cherry-picks` ?

> On 14/07/2020 04:10, Denton Liu wrote:
> >
> > On Mon, Jul 13, 2020 at 10:44:06PM -0400, Philippe Blain wrote:
> > >
> > > I learned today that doing `git rebase --keep-base master` will drop
> > > commits that were cherry-picked from master to the current branch. I
> > > was simply doing a code clean up on my feature branch (the full
> > > command was `git rebase -i --keep-base master`), and this kind of
> > > confused me for a moment.
> >
> > Glad I'm not the only one using this feature :)
> >
> > > Is this a sane default ? I understand that it is a good default when
> > > we are rebasing *on top* of master, but here I'm just doing some
> > > squashing and fixup's and I did not want the commit I had
> > > cherry-picked from master to disappear (yet). In fact, because it
> > > was dropped, it created a modify/delete conflict because in a
> > > subsequent commit in my feature branch I'm modifying files that are
> > > added in the commit I cherry-picked.
> >
> > So if I'm not mistaken, if we have the following graph
> >
> >  A - B - C - D (master)
> >       \
> >         - C' - D (feature)
> >
> > and we do `git rebase --keep-base master` from feature, C' will be
> > dropped? Indeed, I am surprised by how this interacts with the
> > default setting of --reapply-cherry-picks.
>
> To me the question is why are we looking at the upstream commits at all
> with `--keep-base`? I had expected `rebase --keep-base` to be the same
> as `rebase $(git merge-base [--fork-point] @{upstream} HEAD)` but
> looking at the code it seems to be `rebase --onto $(git merge-base
> @{upstream} HEAD) @{upstream}`. I didn't really follow the development
> of this feature - is there a reason we don't just use the merge-base as
> the upstream commit?