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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Oct 20, 2021, 23:35 UTC
Message-ID: <211021.86r1cfmfhh.gmgdl@evledraar.gmail.com>
In-Reply-To: <20211020010624.675562-5-sandals@crustytoothpaste.net>

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.