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

On Thu, Oct 21 2021, brian m. carlson wrote:

[[PGP Signed Part:Undecided]]
On 2021-10-20 at 23:35:43, Ævar Arnfjörð Bjarmason wrote:

quoted

On Wed, Oct 20 2021, brian m. carlson wrote:

quoted

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

Isn't it preferable to recommend --delete-before for that reason?
I.e. --delete-after will produce subtle corruption of e.g. refs
potentially pointing to the wrong thing.

But if you recommend --delete-before I think (but maybe I'm missing some
cases) that it will be more likely to produce obvious corruption,
e.g. git dying due to missing objects.

Anyway, I'm also happy to just leave this as-is, it just stood out to me
as od..

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

quoted

quoted

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

...or just leave it as-is is also fine with me, whatever you think is
best.