[LUDOC-212] git pull alternates between origin/HEAD and origin/master

• Status: Resolved
• Project: Lustre Documentation
• Type: Bug
• Priority: Major
• Reporter: Ryan Haasken
• Assignee: Richard Henwood (Inactive)
• Resolution: Fixed

Environment

Running git version 1.8.0 on SLED 11 SP2.

• Severity: 3

Description

In my local copy of the Lustre manual git repository, 'git pull' alternates between pulling origin/HEAD and origin/master, and causes merge conflicts.

Here is the output and the steps to reproduce the problem:

haasken@lnx-haasken whamcloud $ git clone git://git.whamcloud.com/doc/manual lustre-manual
Cloning into 'lustre-manual'...
remote: Counting objects: 1387, done.
remote: Compressing objects: 100% (603/603), done.
remote: Total 1387 (delta 990), reused 1156 (delta 781)
Receiving objects: 100% (1387/1387), 1.30 MiB | 593 KiB/s, done.
Resolving deltas: 100% (990/990), done.
haasken@lnx-haasken whamcloud $ cd lustre-manual/
haasken@lnx-haasken lustre-manual $ git status
# On branch master
nothing to commit, working directory clean
haasken@lnx-haasken lustre-manual $ git pull
From git://git.whamcloud.com/doc/manual
 + e405045...5b5e7eb HEAD       -> origin/HEAD  (forced update)
Already up-to-date.
haasken@lnx-haasken lustre-manual $ git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 69 and 1 different commit each, respectively.
#
nothing to commit, working directory clean
haasken@lnx-haasken lustre-manual $ git pull
From git://git.whamcloud.com/doc/manual
 + 5b5e7eb...e405045 master     -> origin/master  (forced update)
Already up-to-date.
haasken@lnx-haasken lustre-manual $ git status
# On branch master
nothing to commit, working directory clean

The git pull will continue alternating between origin/master and origin/HEAD. Note the "69 and 1 different commit each" message reported by git status. This looks similar to the issue reported in this stack overflow question: http://stackoverflow.com/questions/7900471/git-pull-alternates-between-two-different-origin-master-branches

Please look into what is causing this and fix it. This is interfering with my work. I am not sure whether origin/master or origin/HEAD is correct.

Comments

[Richard Henwood (Inactive)]

I can't reproduce your issue - but the discussion on the link you've included indicates something isn't right with the repo. I will investigate.

[Richard Henwood (Inactive)]

I do not have sufficient privileges to delete the remove HEAD branch so I've requested assistance.

[Ryan Haasken]

It's strange that you can't reproduce the issue. Am I cloning the correct git repo?

Here are the versions of git with which I have seen the problem:

git version 1.7.10.4 on SLES 11 SP2
git version 1.8.0 on SLES 11 SP2

I don't think that should matter, but I'm providing the info just in case.

[Ryan Haasken]

Thanks, Richard. Are you sure that would be the correct solution? I just want to be sure we don't lose commits because of that "69 and 1 different commit each, respectively" message.

[Christopher Morrone]

I believe that Richard's solution is the correct one.

"HEAD" is a special reference that, generally speaking, really only makes sense in a local repository. It is a symbolic reference that always points to the last commit that was checked out. It is not the name of a branch, though it may point to a branch name.

Since the server's repository should usually be "bare" (meaning there is not checked out code) there should not really be a HEAD. But sometimes HEAD on the server is used to point to the default branch that should be checked out on a clone operation (that is right, "master" does not necessarily need to be the default branch. You could have a repository without a master branch altogether.)

If you do ls-remote on the server there are two "HEAD" references:

$ git ls-remote origin |grep HEAD
59d5a7081e4e2fbf90cf9eaefc3fa2854f1391f1	HEAD
5b5e7eb8786cbbe31809177129acf027d2a6bd5b	refs/heads/HEAD

The latter is the one that is causing problems and needs removal.

So don't worry about losing commits. refs/heads/HEAD was just a mistake from back on March 19th.

[Ryan Haasken]

Per Christopher's analysis, it seems like this should be an easy fix if somebody has the proper permissions. Richard, what happened with your request for assistance?

[Richard Henwood (Inactive)]

I'm asking the admin team if there is any update on this work.

[Richard Henwood (Inactive)]

I'm pleased to report this issue was fixed recently by one of the team.

$ git ls-remote origin | grep HEAD
5ab432e3aa43fa289eaa747db0cec6969797202f	HEAD

[Ryan Haasken]

That's great! As expected, I don't see the alternating git pull anymore, thanks!