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

Re: dangling commits and blobs: is this normal?

From
Jeff King <peff@peff.net>
Date
Apr 22, 2009, 19:58 UTC
Message-ID
<20090422195854.GA14146@coredump.intra.peff.net>
In-Reply-To
<I5p8gPPuE_qW2RDhwiqxCWDuMtnuvvgtSkeTkxby6rlj_FKtpERaBA@cipher.nrlssc.navy.mil>
On Wed, Apr 22, 2009 at 02:45:29PM -0500, Brandon Casey wrote:
Show 16 quoted lines
> > Yes, it's a bit more work for you, but having "git gc" optimize by
> > default for git's performance seems to be the only sensible course.
> > Your idea of what is "big enough" above is somewhat outside the realm of
> > git, so you have to pay the price to specify it by tweaking the
> > keep-files.
> 
> But isn't git-gc supposed to be the "high-level" command that just does
> the right thing?  It doesn't seem to me to be outside the scope of this
> command to make a decision about trading off speed/io for optimal repo
> layout.  In fact, it does do this already.  The default window, depth and
> compression settings are chosen to be "good enough", not to produce the
> absolute optimum repo.
> 
> I'm just pointing out that everything is a trade off.  So I think saying
> something like "gc must optimize for git's performance" is not entirely
> accurate.  We make tradeoffs now.  Other tradeoffs may be helpful.

Sure, but my point was that git doesn't even know _how_ to make that tradeoff. It doesn't know what you consider a reasonable size of backup for your incremental backups, how often you might want to rollover your keep files, how often you expect to commit and how big the commits will be, etc.

So it does the most reasonable thing, which is to optimize for git itself based on what it does know. If there is any improvement to be made, it is probably to make a simpler way for the user to specify that external knowledge to git (because tweaking .keep files really is unnecessarily complex for Matthieu's scenario). And maybe that is just adding a config variable analagous to "gc.autopacklimit" to be used for regular gc, but that would default to 0 (i.e., default to the current behavior of always repacking).

But I don't think it makes sense to change the default.
-Peff
Previous: Brandon CaseyNext: Nicolas Pitre
Message 8 of 21 in “dangling commits and blobs: is this normal?”
  1. John DlugoszApr 21, 2009
  2. Jeff KingApr 22, 2009
  3. Brandon CaseyApr 22, 2009
  4. Nicolas PitreApr 22, 2009
  5. Matthieu MoyApr 22, 2009
  6. Jeff KingApr 22, 2009
  7. Brandon CaseyApr 22, 2009
  8. Jeff KingApr 22, 2009
  9. Nicolas PitreApr 22, 2009
  10. Matthieu MoyApr 23, 2009
  11. Nicolas PitreApr 22, 2009
  12. Brandon CaseyApr 22, 2009
  13. Nicolas PitreApr 22, 2009
  14. Jeff KingApr 22, 2009
  15. Nicolas PitreApr 22, 2009
  16. Geert BoschApr 23, 2009
  17. Shawn O. PearceApr 23, 2009
  18. Geert BoschApr 23, 2009
  19. Matthias AndreeApr 23, 2009
  20. Nicolas PitreApr 23, 2009
  21. John DlugoszApr 22, 2009

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.