git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.



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