On Wed, Oct 20 2021, brian m. carlson wrote: > +The recommended approach is to use `rsync -a --delete-after` (ideally with an > +encrypted connection such as with `ssh`) on the root of repository. You should > +ensure several things when you do this: What's the reason to recommend --delete-after in particular? I realize that e.g. in the .git directory not using *A* delete option *will* cause corruption, e.g. if you can leave behind stale loose refs with an up-to-date pack-refs file. But isn't that equally covered by --delete and --delete-before? I'm not very well worsed in rsync, but aren't the two equivalent as far as the end-state goes? If the intention with --delete-after over --delete or --delete-before is to somehow make the repository useful during the transfer, doesn't that go against the later advice of: > +* The repository is in a quiescent state for the duration of the transfer (that > + is, no operations of any sort are taking place on it, including background > + operations like `git gc`). Also for this: > +Be aware that even with these recommendations, syncing in this way is > +potentially risky since it bypasses Git's normal integrity checking for > +repositories, so having backups is advised. Perhaps we should recommend running a "git gc" or other integrity check after (or "git fsck"), although those don't cover some cases, e.g. the pack-refs v.s. loose refs problem in the case of a missing --delete-whatever.
