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