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

Re: git push to a non-bare repository

From
Nicolas Pitre <nico@cam.org>
Date
Mar 19, 2007, 04:08 UTC
Message-ID
<alpine.LFD.0.83.0703182355570.18328@xanadu.home>
In-Reply-To
<20070319035351.GI20658@spearce.org>
On Sun, 18 Mar 2007, Shawn O. Pearce wrote:
Show 21 quoted lines
> Theodore Tso <tytso@mit.edu> wrote:
> > So I dug a little more deeply, and the problem is that the reflog for
> > master was getting updated, but not the reflog for HEAD, and that's
> > what "git reflog" was showing --- hence my confusion.
> > 
> > What are the rules for when HEAD's reflog should get updated, and is
> > this documented anywhere in the man pages?
> 
> It is buried down in write_ref_sha1 (in refs.c).  The rule is if the
> name of the ref given to us for update does not match the actual
> ref we are about to change, we log to both the original ref name
> given and the actual ref name.
> 
> This handles the case of HEAD being a symref to some actual branch;
> we update the HEAD reflog and the actual branch reflog whenever
> someone updates HEAD.  Which is what we are usually doing from
> tools like git-checkout.
> 
> receive-pack isn't updating the HEAD reflog as its updating the
> actual branch, not HEAD.  If you pushed instead to HEAD you should
> see the HEAD reflog entry too.

This is indeed a corner case. And it was never considered before as great care was made at the time to be sure pushes wouldn't create any reflogs on the remote side, which is effectively done by not automatically enabling reflogs on bare repos.

> Its a little ugly here as I'm not sure we should always update
> HEAD's reflog if HEAD points at a branch we are actually updating.
> Maybe we should though in receive-pack ?

If the meaning of HEAD changed (although indirectly) because HEAD happens to point to the branch that just got updated then logically the HEAD reflog should be updated too. On the other hand the HEAD reflog should reflect operations performed on HEAD. Since the push updates the branch directly it is not exactly performing some operation on HEAD since HEAD could point anywhere and that wouldn't change the push at all.

Meaning that for the discussion of pushing to a non-bare repository with a dirty working tree... If the branch being pushed into is not pointed to by HEAD then no consideration what so ever about the working tree should be made, and no update to the HEAD reflog made of course.

Nicolas
Previous: Shawn O. PearceNext: Theodore Tso
Message 13 of 27 in “git push to a non-bare repository”
  1. Matthieu MoyMar 18, 2007
  2. Junio C HamanoMar 18, 2007
  3. Sam VilainMar 18, 2007
  4. Jakub NarebskiMar 18, 2007
  5. Junio C HamanoMar 18, 2007
  6. Theodore TsoMar 19, 2007
  7. Junio C HamanoMar 19, 2007
  8. Shawn O. PearceMar 19, 2007
  9. Theodore TsoMar 19, 2007
  10. Shawn O. PearceMar 19, 2007
  11. Theodore TsoMar 19, 2007
  12. Shawn O. PearceMar 19, 2007
  13. Nicolas PitreMar 19, 2007
  14. Theodore TsoMar 19, 2007
  15. Junio C HamanoMar 19, 2007
  16. Nicolas PitreMar 19, 2007
  17. Nicolas PitreMar 19, 2007
  18. Sam VilainMar 19, 2007
  19. Junio C HamanoMar 20, 2007
  20. Junio C HamanoMar 20, 2007
  21. Theodore TsoMar 19, 2007
  22. Shawn O. PearceMar 19, 2007
  23. Junio C HamanoMar 19, 2007
  24. Matthieu MoyMar 19, 2007
  25. Jakub NarebskiMar 19, 2007
  26. Neil SchemenauerMar 21, 2007
  27. Sergio CallegariMar 19, 2007

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.