Re: Itches with the current rev spec

From: Yann Dirson <dirson@bertin.fr>
Date: Apr 26, 2013, 08:19 UTC
Message-ID: <20130426101946.433f2d12@chalon.bertin.fr>
In-Reply-To: <CALkWK0n97VLtiR96VEy86645NVoDL2rS-g7LBuLb=JpncdH6VA@mail.gmail.com>

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

-- 
Yann Dirson - Bertin Technologies