git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Git List <git@vger.kernel.org>, Jeff King <peff@peff.net>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH v2 3/3] gitfaq: add entry about syncing working trees
Date: Mon, 8 Nov 2021 19:02:54 -0500	[thread overview]
Message-ID: <CAPig+cTN+ktteGYv6dm_Qr=FejiwRMGwRW9p--7s46H7sxa3JQ@mail.gmail.com> (raw)
In-Reply-To: <YYmmBMkwy6bpVpzI@camp.crustytoothpaste.net>

On Mon, Nov 8, 2021 at 5:34 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> On 2021-11-08 at 00:12:14, Eric Sunshine wrote:
> > Taking into consideration that people who are experiencing such
> > corruption will likely include the name of the syncing service in
> > their search query, would it make sense to mention some well-known
> > services here in order to make it more likely that people will
> > actually find this entry? Something like this, perhaps:
> >
> >     It is important not to use a cloud syncing service (such as DropBox,
> >     FooBar, CowMoo, BuzzingBee, etc.) to sync any portion of a Git
> >     repository...
>
> There are a lot of these services.  My preference is to not name
> specific ones here, just like we don't name specific ones when we state
> that you shouldn't use an antivirus or firewall other than the Windows
> default, mostly because I'm not interested in angering corporate
> lawyers.  My advice on this topic is always general: XYZ is a cloud
> syncing service, and you should not use any cloud syncing services for Git.

My "would it make sense" question arose from taking into consideration
how people are likely to use a search engine for a particular problem:

    BuzzingBee syncing corrupted git repository

Without naming specific services or tools, it seems much less likely
that people will find this FAQ entry, thus will end up posting to
StackOverflow (or wherever) anyhow -- despite your intention and
effort behind the FAQ in the first place. I'm thinking about
discoverability -- which is the same reason I suggested in my review
of the other patch that it might be a good idea to add actual error
messages a person might encounter with a CRLF shell script or an LF
batch file.

> Additionally, the popular options differ by region.  For example, there
> are some services which are probably popular in China which are not
> popular elsewhere, and I don't think it's a good idea to try to guess
> which ones happen to be most popular around the world.

The other way to look at it is that listing many popular services
(wherever they happen to be) makes it more likely that search engines
will lead them to this FAQ entry and alleviate the need to post a
question somewhere.

Anyhow, it was just a thought. I think I've said all I have to say on
this subject. As I mentioned in response to the cover letter, all of
my comments were of the bikeshedding variety, and I didn't see any
show-stoppers in the series as posted.

> > > +* There are no additional worktrees enabled for your repository.
> >
> > I don't fully understand this restriction. Can you explain it (at
> > least here in the email discussion)?
>
> If you sync the main repository and working tree, but not the worktrees
> themselves, then you end up with incorrect data in the .git directory,
> which contains information about the worktree.

I still don't follow. What incorrect data will be in the .git
directory? Do you mean the absolute path pointing from the .git
directory to the worktree?

> More importantly, it can
> contain absolute path information, which would be undesirable even if
> you did sync the worktrees, say, if you used two different usernames
> (and hence two different home directories) on the two systems.

Okay, I figured that that was probably one of your concerns, but it
was difficult to tell from the raw "no additional worktrees". On the
other hand, I can easily see people syncing between machines in which
they have the same username and same directory structure, so this
bullet point seems overly restrictive.

> > > +* You are not using a separate Git directory outside of your repository root.
> >
> > Same question about this restriction.
>
> Again, if you sync the root of the working tree but don't sync the
> separate Git directory, you won't have copied the index or any of the
> other data.

Okay, again, this is indeed what I thought you might have in mind, but
it was difficult to be sure. And, again, this seems overly restrictive
since there may be plenty of scenarios in which this works well.

I suppose both of these points would feel more reasonable if they
didn't sound like hard requirements, perhaps by explaining that the
simple case of no worktrees and no separate repository has the least
restrictions and is easiest to get up and running; more complex cases
can work too with the caveat that worktree and separate repository
directories ought to be synced too, and that pathnames need to be
identical on all machines.

  parent reply	other threads:[~2021-11-09  0:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-07 22:55 [PATCH v2 0/3] Additional FAQ entries brian m. carlson
2021-11-07 22:55 ` [PATCH v2 1/3] gitfaq: add documentation on proxies brian m. carlson
2021-11-07 23:27   ` Eric Sunshine
2021-11-08  1:53     ` brian m. carlson
2021-11-08 21:24       ` Junio C Hamano
2022-01-04 13:40   ` Johannes Schindelin
2021-11-07 22:55 ` [PATCH v2 2/3] gitfaq: give advice on using eol attribute in gitattributes brian m. carlson
2021-11-07 23:48   ` Eric Sunshine
2021-11-08  2:09     ` brian m. carlson
2021-11-07 22:55 ` [PATCH v2 3/3] gitfaq: add entry about syncing working trees brian m. carlson
2021-11-08  0:12   ` Eric Sunshine
2021-11-08 22:09     ` Junio C Hamano
2021-11-09  0:10       ` Junio C Hamano
2021-11-14 23:40         ` brian m. carlson
     [not found]     ` <YYmmBMkwy6bpVpzI@camp.crustytoothpaste.net>
2021-11-09  0:02       ` Eric Sunshine [this message]
2021-11-08  0:16 ` [PATCH v2 0/3] Additional FAQ entries Eric Sunshine
2022-01-04 13:53   ` Johannes Schindelin
2022-01-04 13:54 ` Johannes Schindelin
2022-01-06  1:58   ` 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='CAPig+cTN+ktteGYv6dm_Qr=FejiwRMGwRW9p--7s46H7sxa3JQ@mail.gmail.com' \
    --to=sunshine@sunshineco.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=bagasdotme@gmail.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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.
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).