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

Re: "disabling bitmap writing, as some objects are not being packed"?

From
David Turner <novalis@novalis.org>
Date
Dec 16, 2016, 21:40 UTC
Message-ID
<1481924416.28176.19.camel@frank>
In-Reply-To
<20161216213214.z3mzkp2xqnwrqkh2@sigill.intra.peff.net>
On Fri, 2016-12-16 at 16:32 -0500, Jeff King wrote:
Show 21 quoted lines
> On Fri, Dec 16, 2016 at 01:28:00PM -0800, Junio C Hamano wrote:
> 
> > > 2. I don't understand what would cause that message.  That is, what bad
> > > thing am I doing that I should stop doing?  I've briefly skimmed the
> > > code and commit message, but the answer isn't leaping out at me.
> > 
> > Enabling bitmap generation for incremental packing that does not
> > cram everything into a single pack is triggering it, I would
> > presume.  Perhaps we should ignore -b option in most of the cases
> > and enable it only for "repack -a -d -f" codepath?  Or detect that
> > we are being run from "gc --auto" and automatically disable -b?  I
> > have a feeling that an approach along that line is closer to the
> > real solution than tweaking report_last_gc_error() and trying to
> > deduce if we are making any progress.
> 
> Ah, indeed. I was thinking in my other response that "git gc" would
> always kick off an all-into-one repack. But "gc --auto" will not in
> certain cases. And yes, in those cases you definitely would want
> --no-write-bitmap-index. I think it would be reasonable for "git repack"
> to disable bitmap-writing automatically when not doing an all-into-one
> repack.

I do not have alternates and am not using --local. Nor do I have .keep packs.

I would assume, based on the documentation, that auto gc would be doing
an all-into-one repack:
"If the number of packs exceeds the value of gc.autopacklimit, then
 existing packs (except those marked with a .keep file) are
 consolidated into a single pack by using the -A option of git
 repack."

I don't have any settings that limit the size of packs, either. And a manual git repack -a -d creates only a single pack. Its loneliness doesn't last long, because pretty soon a new pack is created by an incoming push.

Unless this just means that some objects are being kept loose (perhaps because they are unreferenced)?

Previous: Jeff KingNext: Jeff King
Message 5 of 21 in “"disabling bitmap writing, as some objects are not being packed"?”
  1. David TurnerDec 16, 2016
  2. Jeff KingDec 16, 2016
  3. Junio C HamanoDec 16, 2016
  4. Jeff KingDec 16, 2016
  5. David TurnerDec 16, 2016
  6. Jeff KingDec 16, 2016
  7. pack-objects: don't warn about bitmaps on incremental packDavid Turner, Dec 16, 2016
  8. Jeff KingDec 17, 2016
  9. David TurnerDec 19, 2016
  10. Duy NguyenDec 17, 2016
  11. David TurnerFeb 8, 2017
  12. Duy NguyenFeb 8, 2017
  13. David TurnerFeb 8, 2017
  14. Duy NguyenFeb 8, 2017
  15. Junio C HamanoFeb 8, 2017
  16. David TurnerFeb 8, 2017
  17. Jeff KingFeb 8, 2017
  18. David TurnerFeb 8, 2017
  19. Jeff KingFeb 8, 2017
  20. Junio C HamanoFeb 9, 2017
  21. Jeff KingFeb 9, 2017

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.