Taylor Blau <me@xxxxxxxxxxxx> writes: > To summarize Jonathan's point (as I think I severely misunderstood it > before), if two writers are repacking a repository with unreachable > objects. The following can happen: > > - $NEWGIT packs the repository and writes a cruft pack and .mtimes > file. > > - $OLDGIT packs the repository, exploding unreachable objects from the > cruft pack as loose, setting their mtimes to "now". And if these repeat, alternating new and old versions of Git, we will keep refreshing the unreachable objects' mtimes forever. But once you stop using old versions of Git, perhaps in 3 release cycles or so, we'll eventually be able to purge them, right? > One approach (that Jonathan suggested) is to prevent the above situation > by introducing a format extension, so $OLDGIT could not touch the > repository. But this comes at a (in my view, significant) cost which is > that $OLDGIT can't touch the repository _at all_. An extension would be > desirable if cross-version interaction resulted in repository > corruption, but this scenario does not lead to corruption at all. A repository may not be in a healthy state, when tons of unreachable objects stay around forever, but it probably is a bit too harsh to call it "corrupt". > Another approach (courtesy Stolee, in an off-list discussion) is that we > could introduce an optional extension available as an opt-in to prevent > older versions of Git from interacting in a repository that contains > cruft packs, but is not required to write them. That smells too magic; let's not go there. > A third approach (and probably my preferred direction) is to indicate > clearly via a combination of updates to Documentation/cruft-packs.txt > and the release notes that say something along the lines of: > > If you use are repacking a repository using both a pre- and > post-cruft packs version of Git, please be aware that you will lose > information about the mtimes of unreachable objects. I do not quite see how it helps. After hearing "... will lose information about the mtimes ...", what concrete action can a user take? Or a sys-admin? It's not like use of cruft-pack is mandatory when you upgrade the new version of Git, right? Perhaps use of cruft-pack should be guarded behind a configuration variable so that users who might want to use mixed versions of Git will be protected against accidental use of new version of Git that introduces the forever-renewing untracked objects problem? Perhaps a configuration variable, repack.cruftPackEnabled, that is by default disabled, can be used to protect people who do not want to get into the "keep refreshing mtime" loop from using the cruft packs by mistake? repack.cruftPackEnabled can probably be part of the "experimental" feature set, if we think it is the direction in the future.
