git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Creating remote branch called HEAD corrupts remote clones

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 20, 2011, 19:53 UTC
Message-ID
<7v62tjs66r.fsf@alter.siamese.dyndns.org>
In-Reply-To
<ih1449$ul6$1@dough.gmane.org>
Stephen Kelly <steveire@gmail.com> writes:
Show 8 quoted lines
> 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?

Previous: Wesley J. LandakerNext: Jeff King
Message 9 of 40 in “Creating remote branch called HEAD corrupts remote clones”
  1. Stephen KellyJan 17, 2011
  2. Stephen KellyJan 20, 2011
  3. Thomas RastJan 20, 2011
  4. Stephen KellyJan 20, 2011
  5. Erik Faye-LundJan 20, 2011
  6. Stephen KellyJan 20, 2011
  7. Felipe ContrerasJan 20, 2011
  8. Wesley J. LandakerJan 20, 2011
  9. Junio C HamanoJan 20, 2011
  10. Jeff KingJan 20, 2011
  11. Junio C HamanoJan 20, 2011
  12. Jeff KingJan 20, 2011
  13. Felipe ContrerasJan 20, 2011
  14. Junio C HamanoJan 21, 2011
  15. Felipe ContrerasJan 22, 2011
  16. Stephen KellyFeb 20, 2011
  17. Stephen KellyApr 26, 2011
  18. Felipe ContrerasApr 26, 2011
  19. Stephen KellyApr 27, 2011
  20. Felipe ContrerasApr 27, 2011
  21. Stephen KellyApr 27, 2011
  22. Felipe ContrerasApr 27, 2011
  23. Stephen KellyApr 27, 2011
  24. Felipe ContrerasApr 27, 2011
  25. Erik Faye-LundApr 27, 2011
  26. Erik Faye-LundApr 27, 2011
  27. Stephen KellyMay 2, 2011
  28. Erik Faye-LundMay 2, 2011
  29. Felipe ContrerasMay 3, 2011
  30. Stephen KellyMay 3, 2011
  31. Felipe ContrerasMay 3, 2011
  32. Erik Faye-LundMay 4, 2011
  33. only warn about ambiguous refs if stderr is a ttyErik Faye-Lund, May 9, 2011
  34. Jeff KingMay 9, 2011
  35. Erik Faye-LundMay 9, 2011
  36. Jeff KingMay 9, 2011
  37. Erik Faye-LundMay 9, 2011
  38. Jeff KingMay 9, 2011
  39. Junio C HamanoMay 9, 2011
  40. Jeff KingMay 9, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.