On Thu, Dec 08, 2022 at 02:01:05AM -0500, Jeff King wrote: > On Thu, Dec 08, 2022 at 02:16:31AM +0100, Michal Suchánek wrote: > > > > A "git gc" on a "live" repo is always racy in theory, but the odds that > > > you'll run into data corrupting trouble tends to approach zero as you > > > increase the gc.pruneExpire setting, with the default 2 weeks being more > > > than enough for even the most paranoid user. > > > > And that two weeks expiration applies to what, exactly? > > > > For commits there is author date and commit date but many other objecs > > won't have these I suppose. And the date when the object is pushed into > > the repository is unrelated to these two, anyway. > > In this case it's the mtime on the object file (or the pack containing > it). But yes, it is far from a complete race-free solution. So if you are pushing a branch that happens to reuse commits or other objects from an earlier branh that might have been collected ín the meantime you are basically doomed. How likely that is depends a lot on your workflow. People deleting a branch and then pushing another variant in which many objects are the same is a risk. People exporting files from somewhere and adding them to the repo which are bit-identical when independently exported by multiple people and sometimes deleting branches is a risk. ... Thanks Michal
