Re: git svn clone/fetch hits issues with gc --auto
- Date: Wed, 10 Oct 2018 07:41:25 -0400
- From: Martin Langhoff <martin.langhoff@xxxxxxxxx>
- Subject: Re: git svn clone/fetch hits issues with gc --auto
On Wed, Oct 10, 2018 at 7:27 AM Ævar Arnfjörð Bjarmason
> As Jeff's
> 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
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".
- ask interesting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted ~ http://github.com/martin-langhoff
by shiny stuff