Re: [PATCH v3] repack: enable bitmaps by default on bare repos

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

On Fri, May 24 2019, SZEDER Gábor wrote:

> On Fri, May 24, 2019 at 01:17:06PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, May 24 2019, SZEDER Gábor wrote:
>>
>> > On Fri, May 24, 2019 at 11:01:39AM +0200, Ævar Arnfjörð Bjarmason wrote:
>> >> I don't think it's a performance problem to have an old commit-graph
>> >> lying around. But if you turn on the commit-graph, run gc a bunch, then
>> >> turn it off in config we'll have it lying around forever, even if you do
>> >> subsequent gc's.
>> >>
>> >> So I think we should delete such things on the general principle that
>> >> the end-state of a gc's shouldn't be the accumulation of the values of
>> >> past configuration options if we can help it.
>> >>
>> >> Maybe that screws over other users who did a "commit-graph write"
>> >> without setting gc.writeCommitGraph, but I think the only sane thing to
>> >> do is to make "gc" fully 'own' such things if its turned on at all.
>> >
>> > Note that there is 'core.commitGraph' as well; as long as it's
>> > enabled, no commit-graph files should be deleted.
>>
>> Why? If we won't update it or write it if it's not there, why keep it
>> around?
>
> To read it, if 'core.commitGraph' says that is should be read.
>
>> It means the commit-graph code and anything else (like bitmaps) needs to
>> deal with stale data for the common and default gc --auto case.
>>
>> You also can't have e.g. a global core.commitGraph=true config along
>> with a per-repo gc.writeCommitGraph=true config do what you expect.
>>
>> Now just because you wanted to write it for some you'll end up keeping
>> it around forever because you'd also want to optimistically always use
>> it if it's there.
>
> This is exactly what I expect it to do.

Do you also expect base packs with an associated bitmap to have an
implicit *.keep flag under gc with pack.writeBitmaps=false and
pack.useBitmaps=true?

>> Note that I'm talking about the *default* gc semantics, they don't have
>> to cover all advanced use-cases, just be good enough for most, and it's
>> also important that they're as simple as possible, and don't result in
>> stuff like "my performance sucks because I turned this config option on
>> once a year ago for 2 days".