Re: [PATCH 0/3] rebase: learn --keep-base

> Denton Liu <liu.denton@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.

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