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: Fri, 05 Jul 2024 22:50:05 -0700	[thread overview]
Message-ID: <xmqqv81j3w8i.fsf@gitster.g> (raw)
In-Reply-To: <ZocPYKyVzSDIekTK@tapette.crustytoothpaste.net> (brian m. carlson's message of "Thu, 4 Jul 2024 21:08:48 +0000")

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> The most common situation we see is that refs tend to be renamed to
> things like "refs/heads/main 2", which is obviously not a valid refname
> and doesn't work, or the ref gets rolled back to an older version.
> Working trees also get stuck into weird states where files keep coming
> back or getting deleted, or the index gets two differently named copies,
> neither of which is "index".
>
> It is _less_ likely that objects are renamed, but it could be that the
> tool thinks they've been legitimately deleted if the loose objects get
> packed and then they do get deleted elsewhere without another source of
> those objects existing.

Yeah, any time two repositories that are "cloud synched" are
accessed simultaneously, all h*ll can easily break loose.  You may
move your 'master' branch to a commit while the other one may move
their 'master' branch to a different commit.  You may end up having
"master" that points at one of these commits but one of you may have
already lost the only reference to the commit you wanted to have at
the tip of your 'master' branch.  One of you may even trigger auto-gc
to spread the damage.

> If we have users who ask about this, I'm happy to answer them on the
> list.  I don't want to explain the various and sundry scenarios in the
> FAQ entry in order to keep it short, but I can find several examples of
> problems if need be.

OK, that approach would work as long as you are still involved in
the project, but having even one concrete example would help in the
longer term to (1) reduce the bus factor and (2) save time you do
not have to spend responding to every such question.

Thanks.

  reply	other threads:[~2024-07-06  5:50 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
2024-07-04 21:08     ` brian m. carlson
2024-07-06  5:50       ` Junio C Hamano [this message]
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=xmqqv81j3w8i.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).