Stephen Kelly <steveire@xxxxxxxxx> writes: > There were also messages like this: > > $ git pull > remote: Counting objects: 5, done. > remote: Total 3 (delta 0), reused 0 (delta 0) > Unpacking objects: 100% (3/3), done. > From /home/kde-devel/dev/src/playground/git/tmp/remote > + 1434cd2...dd30974 HEAD -> origin/HEAD (forced update) Stephen, thanks, I think you have found a bug, not in this step but one step before this 'git pull', where Bob pushes to the remote for the first time after making a commit. This issue is inherent in the way how the 'separate remotes' layout introduced in 1.6.0 arranges the remote tracking mappings. The refs/remotes/origin/HEAD in Bob's repository is supposed to be a symbolic ref that points at the primary branch of the 'origin' remote (typically its master), e.g. "ref: refs/remotes/origin/master". But in general, local 'refs/remotes/origin/X' for any value of X is to copy 'refs/heads/X' from the 'origin'. Oops. If the origin repository has 'refs/heads/HEAD', these rules obviously conflict with each other. In this particular case, Bob pushes the change to his refs/heads/master to the remote to update its refs/heads/master. The push at the same time tries to pretend that it fetched from the remote to update Bob's tracking branches, so refs/remotes/origin/master in Bob's repository is also updated to point at this commit. However, because Bob's refs/remotes/origin/HEAD is a symbolic ref that points at his refs/remotes/origin/master, its value is also updated by this push. Bob's next fetch from remote will then notice that remotes/origin/HEAD he has is different from refs/heads/HEAD the remote has, and tries to update it, which would obviously a non-fast-forward. I personally think it is reasonable to forbid HEAD or anything all caps that ends with "_HEAD" as branch names. Opinions? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html