Re: [PATCH] t6300: avoid creating refs/heads/HEAD

Jeff King [off-list ref] writes:

This comes originally from Junio's 84679d470. I cannot see how naming
the new branch HEAD would make any difference to the test, but perhaps I
am missing something.

Nah, I think it was just a random string that came to mind and the
topic being "ah we blindly dereference something when showing %(HEAD)"
it was plausible I thought of "H E A D" as that random string before
I used my usual other random strings like frotz ;-)

I noticed this while digging on a nearby issue around "git branch -m @".
This does happen to be the only test that checks that we can make a
branch called refs/heads/HEAD, and I found it because it triggers if you
try to disallow "git branch -m HEAD". :)

About that "nearby" one, does it even make sense to do the interpret
thing on the <new> name?  I can understand "please rename the branch
I was previously on to this new name" wanting to say @{-1} when the
user does not recall the exact spelling of a long name, but I do not
quite see how "to this new name" part benefits by the "interpret
branch name" magic in the first place.

If we care about that, though, I think we should make an explicit test
for "git branch HEAD". But I'm not sure we _do_ care about that. Making
a branch called HEAD is moderately insane, and I don't think it would be
unreasonable for us to outlaw it at some point.

Yeah, at that point we would have "test_must_fail git branch HEAD".

On Mon, Feb 27, 2017 at 11:33:23AM -0800, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

This comes originally from Junio's 84679d470. I cannot see how naming
the new branch HEAD would make any difference to the test, but perhaps I
am missing something.

Nah, I think it was just a random string that came to mind and the
topic being "ah we blindly dereference something when showing %(HEAD)"
it was plausible I thought of "H E A D" as that random string before
I used my usual other random strings like frotz ;-)

OK, thanks for confirming.

quoted

I noticed this while digging on a nearby issue around "git branch -m @".
This does happen to be the only test that checks that we can make a
branch called refs/heads/HEAD, and I found it because it triggers if you
try to disallow "git branch -m HEAD". :)

About that "nearby" one, does it even make sense to do the interpret
thing on the <new> name?  I can understand "please rename the branch
I was previously on to this new name" wanting to say @{-1} when the
user does not recall the exact spelling of a long name, but I do not
quite see how "to this new name" part benefits by the "interpret
branch name" magic in the first place.

Yeah, it's arguable whether the "new" side of a rename should do any
interpretation at all. At the same time, the bug is in the underlying
function that assumes you can slap "refs/heads/" in front of the results
of interpret_branch_name(). And that function gets used in a lot of
places, including the "old" side of a rename. So:

  git branch @{-1} foo

should clearly work. Doing:

  git branch @{upstream} foo

is more debatable. It _does_ work, but only if your upstream is actually
a local branch (otherwise it tries to rename refs/heads/origin/master or
some such nonsense. It happens to fail most of the time because you
probably don't have such a branch, but it's still wrong to even look at
that).

I suspect there are a lot of other places that are less clear cut. E.g.,
I think just:

  git branch foo bar

will put "foo" through the same interpretation. So you could do:

  git branch -f @{-1} bar

Is that insane? Maybe. But it does work now.

-Peff