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

[Denton Liu <liu.denton@gmail.com>]

Hi all,

On Tue, Jul 14, 2020 at 10:38:23PM +0200, Johannes Schindelin wrote:
> > 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?

It behaves this way mostly for unimportant reasons. The first is that my
workflow before implementing this feature invoked running
`git rebase --onto master... master` and I wanted to replicate that.

More importantly, one feature of using the upstream I considered is
documented in t3431. Essentially, if we have the following graph,

	A---B---D---E    (master)
	     \
	      C*---F---G (side)
	
	C was formerly part of master but master was rewound to remove C

running `git rebase --keep-base --fork-point master` would drop C.

> Those are interesting questions, indeed.
> 
> And I dare to suspect that the answer is indeed: `--keep-base` really
> should not only substitute `onto` but also `upstream` with the merge base.

I would be open to changing the behaviour since the commit dropping
isn't really a feature that I use very often. However, I am worried
about pulling the rug out from other people if they use it since this is
a documented feature in git-rebase.txt.

Thanks,
Denton

> Ciao,
> Dscho