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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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.