Re: Regression in 'git branch -m'?

From: Jeff King <peff@peff.net>
Date: Oct 5, 2017, 18:33 UTC
Message-ID: <20171005183303.f77dpkhs5ztxlmyv@sigill.intra.peff.net>
In-Reply-To: <20171005172552.GA11497@inner.h.apk.li>

On Thu, Oct 05, 2017 at 07:25:52PM +0200, Andreas Krey wrote:

Show 25 quoted lines

> I got something that looks like a regression somewhere since 2.11.
> This script
> 
>   set -xe
>   rm -rf repo
>   git init repo
>   cd repo
>   git commit -m nix --allow-empty
>   git branch -m master/master
>   git rev-parse HEAD
>   git branch
>   git status
> 
> causes .git/HEAD to still contain 'ref: refs/heads/master' and to fail
> in the rev-parse step with
> 
>   + git rev-parse HEAD
>   HEAD
>   fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
>   Use '--' to separate paths from revisions, like this:
>   'git <command> [<revision>...] -- [<file>...]'
> 
> This is with 2.15.0.rc0; with 2.11.0 (and 2.11.0.356.gffac48d09) it still works.
> 
> I'm going to do a bisect on this as battery permits.

Looks like 31824d180d (branch: fix branch renaming not updating HEADs correctly, 2017-08-24). This is in v2.15.0-rc0, so we should figure it out before the upcoming release.

I didn't dig very far, but it looks like the branch name is important "foo" doesn't trigger the problem but "master/master" does. "master/foo" also does, but "foo/master" does not. So I suspect it's something about how resolve_ref handles the failure when it would not be able to create the ref because of the d/f conflict. So it's probably related to losing the RESOLVE_REF_READING in the final hunk of that patch. That's just a guess for now, though.

-Peff