Re: [PATCH v2 2/2] Teach @{-1} to git merge

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> - update-ref does _not_ interpret @{-<n>} as the branch name (which I 
>   find okay, as update-ref is plumbing), but instead creates the file 
>   '.git/@{-<n>}' (which I think is a bug).

I do not think it make any sense for update-ref to expand @{-1} to the
name of the last branch, as you end up creating a not-a-ref ".git/next"
and not ".git/refs/heads/next".  It might be Ok to say that @{-1} expands
to refs/heads followed by the name of the last branch only for this
plumbing command, but such an inconsistency feels very wrong.

The particular plumbing command, following the example of recent loosening
the rule back to "HEAD is allowed to point outside refs/heads/", should be
allowed to create anything that passes check_ref_format(), and perhaps bit
more because we would need to allow ".git/HEAD".

> Now, show-branch indeed does not substitute the branch _name_, but 
> otherwise it works correctly, no?
> otherwise it works correctly, no?  And given the fact that show-branch 
> does not substitute "HEAD" with the current branch name, either,...

The tip commits come from get_sha1(), so obviously it would "work", but it
does not show what branch it talks about.  HEAD is shown only when the
user says HEAD (e.g. "git show-branch master HEAD") so I do not see much
similarity there.

The advertised new feature is that you can use the @{-1} syntax anywhere
you would use a branch name and it would work as if you typed the name of
the branch, so in that sense show-branch that shows @{-1} and does not
show the name of the branch is a bug.

It is the same thing for "git-merge @{-1}".  Sure, it would record a
correct tree in the resulting commit, but without the fix it would say
"Merge branch @{-1}" which is wrong and needs to be fixed.

And no, "update-ref @{-1}" should not create ".git/next" when you were on
'next' the last time.  When you say "update-ref next", you may have typed
the four characters and that may look the same as the name of a branch,
but obviously the argument to the command does not *mean* the name of a
branch, so it falls outside the "anywhere you would use a branch name"
rule.