On Thu, Oct 05, 2017 at 07:25:52PM +0200, Andreas Krey wrote: > 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