Denton Liu <liu.denton@xxxxxxxxx> writes:
> This series teaches rebase the --keep-base option.
>
> 'git rebase --keep-base <upstream>' is equivalent to
> 'git rebase --onto <upstream>... <upstream>' or
> 'git rebase --onto $(git merge-base <upstream> HEAD) <upstream>' .
>
> This seems to be a common case that people (including myself!) run
> into; I was able to find these StackOverflow posts about this use
> case:
Since this is 0/3 I won't complain too loudly, but read the above
again while pretending that you didn't know what your initial
motivating example was. The last three lines does not explain
anything useful to such a reader, and the reader needs to decipher
the two sample commands to guess what you wanted to achieve.
Before "teaches rebase the --keep-base option", you must tell what
you wanted to do with that new feature to attract readers---convince
them your new contribution is worth their time to read over.
If I understand correctly, what "--onto $(git merge-base @{u} HEAD) @{u}"
lets you express is:
no matter how much progress the upstream has made while I
was away from the keyboard, I want to rebase the current
topic on top of the same commit from the upstream, on which
I based the current iteration of the topic.
I suspect that such a rebase will become no-op without "-i". Am I
mistaken? I am not sure if "--keep-base" is useful without "-i".
But of course, it would be useful with "-i", i.e. when you want to
further polish the topic. You need to give <upstream> to the command
to let it know where their work stops and your work begins,
i.e. letting the command figure out what commits to replay. But in
such a workflow, you do not want <upstream> to affect on top of what
commit the replayed history is built. And "keep base" would be a
very direct way to achieve that.
