On Tue, Apr 30, 2013 at 5:27 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> 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
--
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