Re: [PATCH] Add new @ shortcut for HEAD

[Felipe Contreras <felipe.contreras@gmail.com>]

On Tue, Apr 30, 2013 at 5:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> That means "git checout @" should work the same way as "git checkout
>>> HEAD", "git log @~4" would work the same way as "git log HEAD~4",
>>> "git update-ref @ $(git rev-parse master)" should update the HEAD
>>> without creating $GIT_DIR/@, etc.
>>>
>>> You can't go any simpler than that rule, and there is no room for
>>> confusion if that rule is properly implemented.
>>
>> I disagree. I can do 'git log @{-1}-4', but I cannot do 'git
>> update-ref @{-1}'. Why? Because the '@' notation is for revision
>> parsing, and 'git update-ref' doesn't do revision parsing.
>>
>> I'd say, everywhere where you could do @{-1}, you should be able to do @.
>
> Yes, @{-1} is about a ref, the branch that you were on previously.
> That is why you can do
>
>         git checkout fc/at-head
>         git checkout master...
>         git am -s <./+fc-updated-at-head-series.mbox
>         git co -B @{-1}
>
> We wouldn't be able to do the last step, if @{-1} evaluated it down
> to the object name, losing the refname.
>
> If "update-ref @{-1}" does not grok @{-1}, probably there needs a
> call to interpret_nth_prior_checkout() in the codepath.

Maybe, but the closest thing would be dwim_ref(), which would also use
rev parsing rules, so there might ambiguous refs.

Since 'update-ref master' updates the 'master' ref, and not
'refs/heads/master' (IOW; no parsing at all), I think it makes sense
that @{-1} is not parsed, and neither is @.

If the user really really wants rev parsing, she can use 'git rev-parse'.

Cheers.

-- 
Felipe Contreras