Re: [RFC/largely untested/PATCH] sha1_name: interpret ~n as HEAD~n

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: May 2, 2011, 11:04 UTC
Message-ID: <4DBE8FD8.90303@drmicha.warpmail.net>
In-Reply-To: <BANLkTinxszGhtYobuvci5Yi8eTHW+pi2wA@mail.gmail.com>

Junio C Hamano venit, vidit, dixit 02.05.2011 12:25:

Show 14 quoted lines

> 
> On May 2, 2011 1:42 AM, "Michael J Gruber" <git@drmicha.warpmail.net
> <mailto:git@drmicha.warpmail.net>> wrote:
> 
>> Regarding rebase -i -<n>:
>> git-rebase (-i) does not have a log/rev-list like interface at all (just
>> like git-cherry does not), and introducing an argument which looks like
>> it did would just increase the user confusion, I'm afraid.
> 
> That cuts both ways. Some people can already be confused by it not being
> in line with the log family. Just like format-patch that was born
> without the log family interface later learned it, it is not impossible
> to teach rebase the same, no?
>

Just because we went in a wrong direction then, is it good to go in the same direction now?

I'm not saying it necessarily was a wrong direction, I just don't consider that an argument.

You can consider my "log --cherry" being part of a long time plan to git rid of "kinda-loggish but not log-like" command interfaces (in that case git-cherry).

Introducing a shortcut ~n for HEAD~n does not introduce new inconsistencies (it's a shortcut for a commit, for every command which takes a commit) - and does not contradict introducing -n at all, btw. But introducing -n means introducing a range like revision argument to a command which does not grok ranges at all, so that is a much deeper decision.

Michael