From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH 4/4] doc: add a FAQ entry about syncing working trees
Date: Thu, 21 Oct 2021 02:33:49 +0200 [thread overview]
Message-ID: <211021.86mtn3mcph.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <YXCuQ3KID6iq0vwa@camp.crustytoothpaste.net>
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:
>>
>> 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.
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.
>>
>> > +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.
next prev parent reply other threads:[~2021-10-21 0:41 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-20 1:06 [PATCH 0/4] Additional FAQ entries brian m. carlson
2021-10-20 1:06 ` [PATCH 1/4] gitfaq: add advice on monorepos brian m. carlson
2021-10-20 4:45 ` Bagas Sanjaya
2021-10-20 10:54 ` Ævar Arnfjörð Bjarmason
2021-10-20 21:19 ` brian m. carlson
2021-10-20 11:55 ` Johannes Schindelin
2021-10-20 14:11 ` Philip Oakley
2021-10-20 22:22 ` brian m. carlson
2021-10-25 10:44 ` Philip Oakley
2021-10-20 1:06 ` [PATCH 2/4] gitfaq: add documentation on proxies brian m. carlson
2021-10-20 11:57 ` Johannes Schindelin
2021-10-20 22:17 ` brian m. carlson
2021-10-20 14:48 ` Junio C Hamano
2021-10-20 22:19 ` brian m. carlson
2021-10-20 1:06 ` [PATCH 3/4] gitfaq: give advice on using eol attribute in gitattributes brian m. carlson
2021-10-20 1:21 ` Eric Sunshine
2021-10-20 1:27 ` brian m. carlson
2021-10-20 12:02 ` Johannes Schindelin
2021-10-20 22:25 ` brian m. carlson
2021-10-21 12:02 ` Johannes Schindelin
2021-10-20 1:06 ` [PATCH 4/4] doc: add a FAQ entry about syncing working trees brian m. carlson
2021-10-20 4:58 ` Bagas Sanjaya
2021-10-20 14:05 ` Philip Oakley
2021-10-20 23:35 ` Ævar Arnfjörð Bjarmason
2021-10-21 0:03 ` brian m. carlson
2021-10-21 0:33 ` Ævar Arnfjörð Bjarmason [this message]
2021-10-20 1:06 ` [PATCH 4/4] gitfaq: add " brian m. carlson
2021-10-20 1:38 ` Eric Sunshine
2021-10-20 21:36 ` brian m. carlson
2021-10-20 12:09 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=211021.86mtn3mcph.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).