On Wed, Oct 10, 2018 at 7:27 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > As Jeff's > https://public-inbox.org/git/20180716175103.GB18636@xxxxxxxxxxxxxxxxxxxxx/ > and my https://public-inbox.org/git/878t69dgvx.fsf@xxxxxxxxxxxxxxxxxxx/ > note it's a bit more complex than that. Ok, my bad for not reading the whole thread :-) thanks for the kind explanation. > - The warning is actionable, you can decide to up your expiration > policy. A newbie-ish user shouldn't need to know git's internal store model _and the nuances of its special cases_ got get through. > - We use this warning as a proxy for "let's not run for a day" Oh, so _that's_ the trick with creating gc.log? I then understand the idea of changing to exit 0. But it's far from clear, and a clear _flag_, and not spitting again the same warning, or differently-worded warning would be better. "We won't try running gc, a recent run was deemed pointless until some time passes. Nothing to worry about." > - This conflation of the user-visible warning and the policy is an > emergent effect of how the different gc pieces interact, which as I > note in the linked thread(s) sucks. It sure does, and that aspect should be easy to fix...(?) > So it's creating a lot of garbage during its cloning process that can > just be immediately thrown away? What is it doing? Using the object > store as a scratch pad for its own temporary state? Yeah, thats suspicious and I don't know why. I've worked on other importers and while those needed 'gc' to generate packs, they didn't generate garbage objects. After gc, the repo was "clean". cheers, m -- martin.langhoff@xxxxxxxxx - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted ~ http://github.com/martin-langhoff by shiny stuff
