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
