Jeff King <p...@peff.net> writes: > > 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). > 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. > 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.
