[BUG] Incosistent repository state when trying to rename HEAD in the middle of a rebase

I just noticed this recently while trying to see if a recent change [1] that disallowed the possibility of creating HEAD also allowed renaming branches named "HEAD" that were created using previous versions that allowed it. Unfortunately (or fortunately (?)), I was in the middle of an interactive rebase while trying this out and as a consequence observed weird behaviour as shown in the following output,

    $ git branch -m HEAD head-1
    warning: Renamed a misnamed branch '|�?' away

The most interesting thing with the above output was that I really didn't have any branch named "HEAD" while trying this. Further, the most crucial thing about the above issue is it left the repository in an inconsistent state by removing ".git/HEAD" and thus leaving the repository in an inconsistent state. This results in git not recognizing it as a git repository itself! I had to do a "git init" to fix this (I guess I lose at least something as a consequence as it checks out the 'master' by default; though I'm not sure).

git 2.11.0 shows a "branch doesn't exist" error (not exactly) in the above case,

    $ hgit b -m HEAD head-1
    error: refname refs/heads/HEAD not found
    fatal: Branch rename failed

My reproduction recipe for the above issue is as follows,

    git init test &&
    cd test &&
    echo "Test file" >test &&
    git add test &&
    git commit -m "Initial commit" &&echo "Test" >test &&git add test &&
    git c -m "Second commit" &&
    git rebase-i HEAD~

At this point use the 'edit' command for "Second commit" and close the editor and try the following,

    $ git branch -m HEAD head-1

This should show the issue. Any git operation after this should report the following error,

    fatal: Not a git repository (or any parent up to mount point /)
    Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set)

Re-initializing the repository should bring the repository back to the position it was before the issue (to some extent though the staging area might become cluttered as the 'master' branch is checked out by default.)

I'm still surprised as to why ".git/HEAD" was treated as a branch. I thought of digging into this but didn't get the time now so thought of informing to the people in the mailing list. One last thing, I suspect this to be a consequence of that change I specified in the beginning, though I might be just guessing around.

[1]: https://public-inbox.org/git/20171013051132.3973-1-gitster@pobox.com/

I was able to spare some time to dig into this and found a few things.

First, it seems that the issue is more generic and the BUG kicks in whenever HEAD is not a symbolic ref. I noticed that because when HEAD is a symbolic ref there was a change in the error message shown by git. In (2.11.0) I get this error message,

    error: refname refs/heads/HEAD not found
    fatal: Branch rename failed

while in the version build from 'next', I get the following error message,

    error: refname HEAD is a symbolic ref, renaming it is not supported
    fatal: Branch rename failed

    That made me suspicious and I wanted to find where the error message
    got changed and bisected this which pointed to,

    9416812db (branch: forbid refs/heads/HEAD, 2017-10-13)

    This is the same commit which also causes the bug of allowing HEAD to
    be renamed when it is not a symbolic ref. I found a way to fix this but
    am not so sure if it's the right way to do this. (the diff patch is
    found at the end of this mail).

    One more observation I made was that without the patch at the end it is
    NOT possible to rename a branch named "HEAD" created using the older
    version!

    On Sat, 2017-10-28 at 22:28 +0530, Kaartic Sivaraam wrote:
    >     git rebase-i HEAD~

Small correction here. Now you could replace that with the simpler,

    git checkout HEAD^

Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:

Interesting.  

Shortly we'll be rewinding the tip of 'next', and it is a good opportunity to kick any not-so-well-cooked topic back to 'pu', so let's figure out what is going on after that happens (at which point let's eject the "branch name sanity" topic out of 'next').

On Thursday 02 November 2017 01:21 PM, Junio C Hamano wrote:

Let me detail a little more about my observations just for the sake of completeness. The change that forbid refs/heads/HEAD caused issues only when HEAD wasn't a symbolic link because of the following reasons,

1) The change resulted in 'strbuf_check_branch_ref' returning with 
failure when the name it received (sb) was HEAD *without* interpreting 
it as "refs/heads/HEAD" into 'ref'. This resulted in the violation of 
the expectation of it's callers that it would have interpret 'ref' which 
was the major cause of the issue.

It wouldn't have been an issue if we had checked for the existence of a "branch" (refs/heads/) rather than checking for the existence of a "ref" (which allowed HEAD to pass the test).

2) This did not cause issues when HEAD was a symbolic ref because there 
was a check for attempting to rename in a symbolic ref in 
'files_copy_or_rename_ref'. The check throws an error when trying to 
rename a symbolic ref which resulted in suspicious error message I got.

So, IIUC the issue doesn't occur when 'ref' is intrepreted before the check for 'HEAD'. That's possibly why the diff patch I sent in the previous mail fixed the issue.

Also, it would be nice if we check for the existence of a "branch" when we want to know whether a branch exists rather than simply doing a 'ref_exists' on the interpreted ref.

Does the above explanation give an idea about what's happening?

--- Kaartic