Re: [PATCH] Add new @ shortcut for HEAD
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Apr 30, 2013, 22:38 UTC
- Message-ID
- <CAMP44s3=frHWUh8rQ5kTooUJqwAtkEG37MaeY3Ho6G7-kwZQ_w@mail.gmail.com>
- In-Reply-To
- <7vsj27ac2a.fsf@alter.siamese.dyndns.org>
On Tue, Apr 30, 2013 at 5:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 29 quoted lines
> 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