Re: [PATCH 2/1] repack: warn if bitmaps are explicitly enabled with keep files
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 3, 2019, 18:10 UTC
- Message-ID
- <xmqqftnn0z1t.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20190703173814.GA29348@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 7 quoted lines
> > A much more robust solution would be to stop conflating user-provided > permanent .keep files with temporary locks. I think that was a mistaken > design added many years ago. We probably could introduce a different > filename for the temporary locks (though I am not entirely convinced > they are necessary in the first place, as gc expiration-times would > generally save a racily-written packfile anyway).
True, true (and I tend to agree).
Show 5 quoted lines
> Or perhaps we could differentiate our temporary locks from "real" .keep > files by looking at the content; I think our locks always say something > like "(receive|receive)-pack \d+ on .*", and it wouldn't be too onerous > to commit to that, I think (or even adjust it to something even more > unambiguous).
True, but it may be overkill to open and read.
Show 6 quoted lines
> It does muddy the meaning of packed_git.pack_keep a bit. Some callers > would want to consider it kept in either case (i.e., for purposes of > pruning, we delete neither) and some would want it kept only for > non-locks (for packing, duplicating the objects is OK). So I think we'd > end up with two bits there, and callers would have to use one or the > other as appropriate.
Yeah, I agree that we'd need to treat them separately in the longer run.
Thanks.