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

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

[Kaartic Sivaraam]

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/

-- 
Kaartic

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

[Kaartic Sivaraam]

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^



diff --git a/sha1_name.c b/sha1_name.c
index c7c5ab376..4345e14c9 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1334,7 +1334,13 @@ int strbuf_check_branch_ref(struct strbuf *sb, const char *name)
        strbuf_branchname(sb, name, INTERPRET_BRANCH_LOCAL);
        if (name[0] == '-')
                return -1;
+
        strbuf_splice(sb, 0, 0, "refs/heads/", 11);
+
+       /* HEAD is not to be used as a branch name */
+       if(!strcmp(sb->buf, "refs/heads/HEAD"))
+               return -1;
+
        return check_refname_format(sb->buf, 0);
 }
 

HTH,
Kaartic

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

[Junio C Hamano]

Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:

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

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').

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

[Kaartic Sivaraam]

On Thursday 02 November 2017 01:21 PM, Junio C Hamano wrote:
> Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:
> 
>> 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.
> 
> Interesting.
>

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.


> 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').

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


---
Kaartic