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

Re: [PATCH 2/2] repack -ad: prune the list of shallow commits

From
Jeff King <peff@peff.net>
Date
Jul 18, 2018, 17:45 UTC
Message-ID
<20180718174505.GA3084@sigill.intra.peff.net>
In-Reply-To
<CACsJy8DW8=FoRyEwAy48S76q0gxQbrS3emHou7QDhHqzwJRu+g@mail.gmail.com>
On Wed, Jul 18, 2018 at 07:31:40PM +0200, Duy Nguyen wrote:
Show 19 quoted lines
> > Sort of an aside to the patch under discussion, but I think it may make
> > sense for prune_shallow() to take a callback function for determining
> > whether a commit is reachable.
> >
> > I have an old patch that teaches git-prune to lazily do the reachability
> > check, since in many cases "git repack" will have just packed all of the
> > loose objects. But it just occurred to me that this patch is totally
> > broken with respect to prune_shallow(), because it would not set the
> > SEEN flag (I've literally been running with it for years, which goes to
> > show how often I use the shallow feature).
> >
> > And if we were to have repack do a prune_shallow(), it may want to use a
> > different method than traversing and marking each object SEEN.
> 
> All of this sounds good. The only thing I'd like to do a bit
> differently is to pass the reachable commits in prune_shallow() as a
> commit-slab instead of taking a callback function. I'll refactor this
> code, move prune_shallow() to a separate command prune-shallow and do
> the locking thing.

I think using a slab is much nicer than the current global-struct flags. But it's not as flexible as a callback, for two reasons:

  - in the lazy case, the caller might not even have loaded the slab
    yet. On the other hand, it might be sufficient to just be broad
    there, and just always pre-populate the slab when
    is_repository_shallow(), before we even call into prune_shallow().
    If we have _any_ entries in the shallow file, we'd need to compute
    reachability.
  - it precludes any optimizations that compute partial reachability.
    Asking "is XYZ reachable" is a much easier question to answer than
    "show me the full reachability graph." At the least, it lets you
    stop the graph traversal early. And with generation numbers, it can
    even avoid traversing down unproductive segments of the graph.

I think it's OK to switch to a slab for now if you don't want to do the callback thing. But I think a callback is probably long-term the right thing (and I actually think it may be _less_ work to implement, since then prune would probably be OK sticking with the global struct flags).

-Peff
Previous: Duy NguyenNext: Duy Nguyen
Message 15 of 47 in “repack -ad: fix after `fetch --prune` in a shallow repository”
  1. 0/2 repack -ad: fix after `fetch --prune` in a shallow repositoryJohannes Schindelin via GitGitGadget, Jul 13, 2018
  2. 1/2 repack: point out a bug handling stale shallow infoJohannes Schindelin via GitGitGadget, Jul 11, 2018
  3. 2/2 repack -ad: prune the list of shallow commitsJohannes Schindelin via GitGitGadget, Jul 11, 2018
  4. Jeff KingJul 13, 2018
  5. Johannes SchindelinJul 14, 2018
  6. Jeff KingJul 16, 2018
  7. Junio C HamanoJul 17, 2018
  8. Johannes SchindelinJul 19, 2018
  9. Junio C HamanoJul 19, 2018
  10. Junio C HamanoJul 20, 2018
  11. Jeff KingJul 20, 2018
  12. Duy NguyenJul 17, 2018
  13. Jeff KingJul 17, 2018
  14. Duy NguyenJul 18, 2018
  15. Jeff KingJul 18, 2018
  16. Duy NguyenJul 18, 2018
  17. Duy NguyenJul 17, 2018
  18. Duy NguyenJul 17, 2018
  19. Johannes SchindelinJul 19, 2018
  20. 0/2 repack -ad: fix after `fetch --prune` in a shallow repositoryJohannes Schindelin via GitGitGadget, Jul 17, 2018
  21. 1/2 repack: point out a bug handling stale shallow infoJohannes Schindelin via GitGitGadget, Jul 17, 2018
  22. 2/2 repack -ad: prune the list of shallow commitsJohannes Schindelin via GitGitGadget, Jul 17, 2018
  23. Eric SunshineJul 17, 2018
  24. Jeff KingJul 17, 2018
  25. Jeff KingJul 17, 2018
  26. Johannes SchindelinJul 19, 2018
  27. 0/3 repack -ad: fix after fetch --prune in a shallow repositoryJohannes Schindelin via GitGitGadget, Oct 22, 2018
  28. 1/3 repack: point out a bug handling stale shallow infoJohannes Schindelin via GitGitGadget, Oct 22, 2018
  29. Junio C HamanoOct 24, 2018
  30. Johannes SchindelinOct 24, 2018
  31. Johannes SchindelinOct 24, 2018
  32. 2/3 shallow: offer to prune only non-existing entriesJohannes Schindelin via GitGitGadget, Oct 22, 2018
  33. Junio C HamanoOct 24, 2018
  34. Johannes SchindelinOct 24, 2018
  35. Johannes SchindelinOct 24, 2018
  36. Jonathan TanOct 25, 2018
  37. Johannes SchindelinOct 26, 2018
  38. Jonathan TanOct 26, 2018
  39. Johannes SchindelinOct 29, 2018
  40. 3/3 repack -ad: prune the list of shallow commitsJohannes Schindelin via GitGitGadget, Oct 22, 2018
  41. Junio C HamanoOct 24, 2018
  42. Johannes SchindelinOct 24, 2018
  43. Johannes SchindelinOct 23, 2018
  44. 0/3 repack -ad: fix after fetch --prune in a shallow repositoryJohannes Schindelin via GitGitGadget, Oct 24, 2018
  45. 1/3 repack: point out a bug handling stale shallow infoJohannes Schindelin via GitGitGadget, Oct 24, 2018
  46. 3/3 repack -ad: prune the list of shallow commitsJohannes Schindelin via GitGitGadget, Oct 24, 2018
  47. 2/3 shallow: offer to prune only non-existing entriesJohannes Schindelin via GitGitGadget, Oct 24, 2018

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.