Hi Junio,
On Sun, Mar 24, 2019 at 10:15:31PM +0900, Junio C Hamano wrote:
> Denton Liu <liu.den...@gmail.com> 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.
Thanks for the clarification. I'll try my best to write future cover
letters more clearly.
>
> 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".
It's useful in the case of "-x", although that is a grey area since "-x"
uses interactive machinery internally. Aside from "-x", I can't really
think of a situation where we would use "--keep-base" 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.
>
>
>
Thanks,
Denton
