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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx/

-- 
Kaartic



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux