Re: [PATCH v3 3/4] gitfaq: add entry about syncing working trees

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 6, 2024, 05:50 UTC
Message-ID: <xmqqv81j3w8i.fsf@gitster.g>
In-Reply-To: <ZocPYKyVzSDIekTK@tapette.crustytoothpaste.net>

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

Show 11 quoted lines

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