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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: May 2, 2011, 08:42 UTC
Message-ID: <4DBE6E77.3030703@drmicha.warpmail.net>
In-Reply-To: <m21v0kw1es.fsf@igel.home>

Andreas Schwab venit, vidit, dixit 30.04.2011 11:09:

Show 18 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>
>>> Jeff King <peff@peff.net> writes:
>>>
>>>> It also conflicts a little with the shell's "~user" syntax, though
>>>> presumably you don't have users named "1" and "2".
>>>
>>> Well, you sorta do if you did use pushd.
>>
>> Yeah, I was also worried about that.  Or some arcane system
>> misinterpreting "~0" as the home directory of root ;-)
> 
> On non-arcane systems ~0 is expanded to the current directory.
> 
> Andreas.
>

[cumulative reply :)]

While we could use a short-hand for HEAD also I don't think ~0 really is a concern.

Regarding consistency: We try to have reasonable defaults and try to dwim (which are different things) even if that breaks consistency/systematics, because useful/reasonable and "what I mean" depend on the context.

"^" resp. ".." and "..." are ambiguous and cannot be resolved easily because for most commands they can mean two things resp. require two arguments. (".." and "..." could maybe default do "@{u}..HEAD" etc.)

"~<n>" can only take a revision argument to its left, and also it needs an argument to its left (as opposed to "^"). Therefore we can default it unambiguously and without braking any current usage (that I know of).

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.

Michael