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

From: Denton Liu <liu.denton@gmail.com>
Date: Jul 15, 2020, 03:20 UTC
Message-ID: <20200715032014.GA10818@generichostname>
In-Reply-To: <nycvar.QRO.7.76.6.2007142236060.52@tvgsbejvaqbjf.bet>

Hi all,

On Tue, Jul 14, 2020 at 10:38:23PM +0200, Johannes Schindelin wrote:

Show 7 quoted lines

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