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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano venit, vidit, dixit 02.05.2011 12:25:
> 
> On May 2, 2011 1:42 AM, "Michael J Gruber" <git@xxxxxxxxxxxxxxxxxxxx
> <mailto:git@xxxxxxxxxxxxxxxxxxxx>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]