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: 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>,
	Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH v2 3/3] gitfaq: add entry about syncing working trees
Date: Mon, 08 Nov 2021 16:10:05 -0800	[thread overview]
Message-ID: <xmqqtugm42aq.fsf@gitster.g> (raw)
In-Reply-To: <xmqqmtmes3ix.fsf@gitster.g> (Junio C. Hamano's message of "Mon, 08 Nov 2021 14:09:42 -0800")

Junio C Hamano <gitster@pobox.com> writes:

> Doesn't rsync work the same per-file fashion, and the only reason
> why it is a better fit is because it is not continuous, not
> attempting to "sync" while the repository is in use, until the user
> explicitly says "OK, I am ready to go home, so let's stop working
> here and send everything over to home with rsync"?

OK, so not "per-file" but "continuous" is the root problem, and
"cloud" would be a good word because all the popular ones share that
"continuous" trait.

This part of the proposed patch text may need rethinking a bit.

> +or added files, broken refs, and a wide variety of other corruption.  These
> +services tend to sync file by file and don't understand the structure of a Git
> +repository.  This is especially bad if they sync the repository in the middle of

That is, "file by file" is not a problem per-se, "don't understand
the structure" is a huge problem, and "continuous" may contribute to
the problem further.

I wonder if you let the "cloud" services to continuously sync your
repository, then go quiescent for a while and then start touching
the destination, it would be sufficient, though.  The refs with
funny "2" suffixes and the like are the symptom of two sides
simultanously mucking with the same file (e.g ".git/refs/main") and
the "cloud sync" could not decide what the right final outcome is,
right?

I also wonder if we add a way to transfer reflog entries, that imply
the object reachability, say "git push --with-reflog", over the
wire, it would be sufficient to do everything with Git.

Before you go home, you'd do

    git stash save --untracked && git stash apply
    git push --mirror --with-reflog --with-stash

to save away modified and untracked files to a stash entry [*], and push
all the refs with their reflog entries (including refs/stash which
normally gets refused because it has only two levels).

    Side note. If there were a variant of "git stash save" that only
    saves away without modifying the working tree and the index, I'd
    use that single command instead of "save and immediately restore
    by applying" kludge.

Then at the destination, you'd figure out what the current branch
was (the stash message should record tha name of the branch), check
that branch out, and running "git stash pop" will give you pretty
much the same environment.

  reply	other threads:[~2021-11-09  0:10 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 [this message]
2021-11-14 23:40         ` brian m. carlson
     [not found]     ` <YYmmBMkwy6bpVpzI@camp.crustytoothpaste.net>
2021-11-09  0:02       ` Eric Sunshine
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=xmqqtugm42aq.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=bagasdotme@gmail.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    --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).