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

Re: gc and repack ignore .git/*HEAD when checking reachability

From
Josh Triplett <josh@joshtriplett.org>
Date
Jul 9, 2016, 05:23 UTC
Message-ID
<20160709052314.GC23426@x>
In-Reply-To
<20160708235053.GA26097@thunk.org>
On Fri, Jul 08, 2016 at 07:50:53PM -0400, Theodore Ts'o wrote:
Show 9 quoted lines
> On Fri, Jul 08, 2016 at 01:30:06PM -0700, Junio C Hamano wrote:
> > 
> > I can imagine I'd start hacking on a project that I rarely touch, give up
> > resolving a "git pull" from an unconfigured place (hence, some stuff is
> > only reachable from FETCH_HEAD), and after 2*N days, come back
> > to the repository and find that I cannot continue working on it.
> 
> Sure, but that's something that could happen today, and no one has
> really complained, have they?
Until now. :)
Show 13 quoted lines
> > Turning the rule to "*_HEAD we know about, and those we don't that
> > are young" would not change the situation, as I may be depending on
> > some third-party tool that uses its OWN_HEAD just like we use
> > FETCH_HEAD in the above example.
> > 
> > So I dunno if that is a good solution. If we are going to declare that
> > transient stuff will now be kept, i.e. keeping them alive is no longer
> > end user's responsibility, then probably we should make it end user's
> > responsibility to clean things up.
> 
> Well, the question is what does "transient" stuff really mean?  If we
> keep them forever, then are they really any different from stuff under
> refs/heads?

No, they're not. And I don't think they should be; HEAD itself is *not* transient, as a detached HEAD can reference valuable non-transient objects.

In an ideal world, HEAD and all other such refs would live somewhere under refs, to avoid the special case.

> Maybe pester the user if there is stale *_HEAD files, but don't
> actually get rid of the objects?

Why pester at all? Just leave them, and if the user has large objects they don't care about and wants to decrease the size of the repository, they can follow the advice from the git-gc manpage: "If you are expecting some objects to be collected and they aren’t, check all of those locations and decide whether it makes sense in your case to remove those references." (Where "those locations" will need to expand to mention "*HEAD".)

(Also, I'd suggest "*HEAD", possibly limited to characters matching [-_A-Z], rather than "*_HEAD".)

- Josh Triplett
Previous: Theodore Ts'oNext: Josh Triplett
Message 8 of 27 in “gc and repack ignore .git/*HEAD when checking reachability”
  1. Josh TriplettJul 8, 2016
  2. Junio C HamanoJul 8, 2016
  3. Josh TriplettJul 8, 2016
  4. Junio C HamanoJul 8, 2016
  5. Theodore Ts'oJul 8, 2016
  6. Junio C HamanoJul 8, 2016
  7. Theodore Ts'oJul 8, 2016
  8. Josh TriplettJul 9, 2016
  9. Josh TriplettJul 8, 2016
  10. Johannes SchindelinJul 9, 2016
  11. Josh TriplettJul 9, 2016
  12. Duy NguyenJul 9, 2016
  13. Johannes SchindelinJul 10, 2016
  14. Duy NguyenJul 10, 2016
  15. Johannes SchindelinJul 10, 2016
  16. Duy NguyenJul 10, 2016
  17. Johannes SchindelinJul 11, 2016
  18. Junio C HamanoJul 11, 2016
  19. Johannes SchindelinJul 12, 2016
  20. Jeff KingJul 12, 2016
  21. Duy NguyenJul 12, 2016
  22. Jeff KingJul 12, 2016
  23. Duy NguyenJul 12, 2016
  24. Johannes SchindelinJul 13, 2016
  25. Duy NguyenJul 13, 2016
  26. Johannes SchindelinJul 13, 2016
  27. Duy NguyenJul 15, 2016

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.