Re: git svn clone/fetch hits issues with gc --auto

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Oct 10 2018, Martin Langhoff wrote:

> On Wed, Oct 10, 2018 at 7:27 AM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> As Jeff's
>> https://public-inbox.org/git/20180716175103.GB18636@sigill.intra.peff.net/
>> and my https://public-inbox.org/git/878t69dgvx.fsf@evledraar.gmail.com/
>> 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.

Oh yeah, don't get me wrong. I think this whole thing sucks, and as the
linked threads show I've run into various sucky edge cases of this.

I'm just saying it's hard in this case to remove one piece without the
whole Jenga tower collapsing, and it's probably a good idea in some of
these cases to pester the user about what he wants, but probably not via
gc --auto emitting the same warning every time, e.g. in one of these
threads I suggested maybe "git status" should emit this.

>
>>  - 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."

Yup. That would be better. Right now we don't write anything
machine-readable to the log, and we'd need to start doing that. E.g. we
could just as well be reporting that gc --auto is segfaulting and that's
why you have all this garbage. We just "cat" it.

>>  - 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".

I tried to find this out in my reply-to-myself in
https://public-inbox.org/git/877eiqf2nk.fsf@evledraar.gmail.com/

But as noted just looked at this briefly, and I don't use git-svn for
years now, so I don't know and might be missing something.