From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: <git@vger.kernel.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Eric Sunshine <sunshine@sunshineco.com>,
Derrick Stolee <stolee@gmail.com>, Jeff King <peff@peff.net>
Subject: Re: [PATCH v3 3/4] gitfaq: add entry about syncing working trees
Date: Wed, 03 Jul 2024 22:21:55 -0700 [thread overview]
Message-ID: <xmqqjzi191fw.fsf@gitster.g> (raw)
In-Reply-To: <20240704003818.750223-4-sandals@crustytoothpaste.net> (brian m. carlson's message of "Thu, 4 Jul 2024 00:38:17 +0000")
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> -Credentials
> ------------
> +Credentials and Transfers
> +-------------------------
I can see (and appreciate) that you struggled to find a good section
to piggyback on, instead of giving this topic its own section. But
do these two make a good mix? They seem to be totally different
topics.
> +It is important not to use a cloud syncing service to sync any portion of a Git
> +repository, since this can cause corruption, such as missing objects, changed
> +or added files, broken refs, and a wide variety of other corruption. These
> +services tend to sync file by file on a continuous basis and don't understand
> +the structure of a Git repository. This is especially bad if they sync the
> +repository in the middle of it being updated, since that is very likely to
> +cause incomplete or partial updates and therefore data loss.
A naïve reader may say "but isn't it the point of these cloud
syncing service that they will eventually catch up???" and we may
want to have a good story why it does not work.
You create many objects in one repository in loose form, cloud
syncing service kicks in to transfer them to the second
repository, and then in the original repository an auto-gc kicks
in so some of the loose objects fail to propagate. The packfile
that is the result of auto-gc will eventually propagate to the
second repository, but before it completes, the second
repository would be in an inconsistent state, and especially if
the ref updates are propagated before objects, then the second
repository will be in a corrupt state. It would be a disaster
if another auto-gc kicked in there.
is one scenario I came up with.
next prev parent reply other threads:[~2024-07-04 5:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-04 0:38 [PATCH v3 0/4] Additional FAQ entries brian m. carlson
2024-07-04 0:38 ` [PATCH v3 1/4] gitfaq: add documentation on proxies brian m. carlson
2024-07-04 0:38 ` [PATCH v3 2/4] gitfaq: give advice on using eol attribute in gitattributes brian m. carlson
2024-07-04 5:22 ` Junio C Hamano
2024-07-04 21:10 ` brian m. carlson
2024-07-04 0:38 ` [PATCH v3 3/4] gitfaq: add entry about syncing working trees brian m. carlson
2024-07-04 5:21 ` Junio C Hamano [this message]
2024-07-04 21:08 ` brian m. carlson
2024-07-06 5:50 ` Junio C Hamano
2024-07-04 0:38 ` [PATCH v3 4/4] doc: mention that proxies must be completely transparent brian m. carlson
2024-07-04 1:25 ` [PATCH v3 0/4] Additional FAQ entries Junio C Hamano
2024-07-04 5:22 ` Junio C Hamano
2024-07-04 21:23 ` brian m. carlson
2024-07-06 5:59 ` Junio C Hamano
2024-07-08 0:52 ` brian m. carlson
2024-07-06 6:47 ` Jeff King
2024-07-06 17:18 ` Junio C Hamano
2024-07-09 23:37 ` [PATCH v4 " brian m. carlson
2024-07-09 23:37 ` [PATCH v4 1/4] gitfaq: add documentation on proxies brian m. carlson
2024-07-09 23:37 ` [PATCH v4 2/4] gitfaq: give advice on using eol attribute in gitattributes brian m. carlson
2024-07-09 23:37 ` [PATCH v4 3/4] gitfaq: add entry about syncing working trees brian m. carlson
2024-07-09 23:37 ` [PATCH v4 4/4] doc: mention that proxies must be completely transparent brian m. carlson
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqjzi191fw.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
--cc=stolee@gmail.com \
--cc=sunshine@sunshineco.com \
/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.
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 NNTP newsgroup(s).