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

From: Jeff King <peff@peff.net>
Date: Feb 27, 2017, 20:51 UTC
Message-ID: <20170227205151.rjhod347ddhmdmxp@sigill.intra.peff.net>
In-Reply-To: <xmqqzih7whrw.fsf@gitster.mtv.corp.google.com>

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

Show 10 quoted lines

> Jeff King <peff@peff.net> 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 ;-)

OK, thanks for confirming.

Show 11 quoted lines

> > 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