From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Mon, 02 May 2011 11:04:56 GMT
Subject: Re: [RFC/largely untested/PATCH] sha1_name: interpret ~n as HEAD~n
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:
> 
> 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