Re: [PATCH 4/4] doc: add a FAQ entry about syncing working trees

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Oct 21, 2021, 00:03 UTC
Message-ID: <YXCuQ3KID6iq0vwa@camp.crustytoothpaste.net>
In-Reply-To: <211021.86r1cfmfhh.gmgdl@evledraar.gmail.com>

On 2021-10-20 at 23:35:43, Ævar Arnfjörð Bjarmason wrote:

Show 15 quoted lines

> 
> 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?

Yes. The goal is that if something goes wrong, you have all the objects you did before, even if you have some potentially invalid refs. The goal is to make it a little less risky if you interrupt it with a Ctrl-C because you realize the destination contained data you wanted. I always prefer --delete-after for that reason, assuming the destination has sufficient disk space.

It shouldn't make a difference in a successful end state, however.

Show 9 quoted lines

> 
> > +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.

I can recommend something like that.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA