Re: Itches with the current rev spec

[Johannes Sixt <j.sixt@viscovery.net>]

Am 4/26/2013 10:19, schrieb Yann Dirson:
>> 2. git rebase -i master fails unless I've rebased my branch on top of
>> master.  I always wished I could do the equivalent of 'git rebase -i
>> master..', but I can't.  Can we give the A..B syntax a new meaning in
>> the context of rebase, namely $(git merge-base A B)? 
> 
> If I understand well, you're refering to a problem that also annoys me,
> ie. using "rebase -i" to just edit your local commits, without rebasing
> onto the lastest revision on the upstream branch, right ?  That is, just
> another wart of having a single command for arguably-different use cases,
> or of having the single-argument version of rebase use that argument for
> 2 very different things (cut-off point and destination), but I won't try
> to address either of these today :)
> 
> In that case, what about just adding a new flag to "rebase -i", that would
> prevent the single-argument to be interpreted as destination ?  I really
> consider this a workaround for a suboptimal CLI, but since we don't want
> to change the rebase CLI before at least 2.0, that could fill the gap for now.
> 
> As for the flag itself, what about --here ?  Obviously it would only be
> meaninglful together with -i, and be exclusive with --onto.

How about this:

Allow alternative spelling of

   git rebase -i master topic

like this:

   git rebase -i master..topic

(as always, the default for topic is HEAD).

Then by extension (cf. git diff, where A...B shows the diff between the
mergebase and B)

   git rebase -i master...topic

would rebase onto the mergebase, which in practice will be the fork point
of topic, i.e., a "non-rebasing rebase".

-- Hannes