git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taylor R Campbell <git@campbell.mumble.net>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "Matěj Cepl" <mcepl@cepl.eu>, git@vger.kernel.org
Subject: Re: Synchronous replication on push
Date: Mon, 4 Nov 2024 13:35:44 +0000	[thread overview]
Message-ID: <20241104133544.A04D760A95@jupiter.mumble.net> (raw)
In-Reply-To: <ZyY74N_NjmaJ2677@tapette.crustytoothpaste.net> (sandals@crustytoothpaste.net)

> Date: Sat, 2 Nov 2024 14:49:04 +0000
> From: "brian m. carlson" <sandals@crustytoothpaste.net>
> 
> On 2024-11-02 at 13:35:11, Taylor R Campbell wrote:
> > I'm asking about how to configure a _single_ frontend remote, from the
> > perspective of developers who are pushing from their development
> > workstations, so that it replicates to one or many backend stores.
> > This is, for example, the usage model of Github's proprietary
> > implementation.
> 
> I don't think there's built-in functionality for this and I'm not sure
> that it can be done without additional software.

I'm happy to write some additional software.

But I would like to understand what constraints there are on, e.g.,
pre-receive hooks and the ref updates of git push that make them
collide in the ways I discovered, so that I can understand how to make
that additional software reliable.

For example:

- Can I suppress the local ref updates of the remote in git push, just
  like git send-pack doesn't attempt any local ref updates of the
  remote?  Or can I defer them to the post-receive hook?

  (By `local ref updates of the remote', I mean updates of the refs
  that live in the local repository for the remote.backend.fetch or
  remote.backend.push refspecs, rather than refs that exist in the
  remote repository which obviously I do want to update.)

- Can I use git send-pack with a custom remote transport?

- When I git clone --mirror, explicitly disable the mirror flag, and
  then git push in the pre-receive hook, why is there an error message
  printed even though the push exits with status zero and appears to
  have had all the effects I want?

- What undesirable side effects can git push have in a mirror cloned
  with git clone --mirror, but with the mirror flag subsequently
  disabled?

- What undesirable side effects can git push have in a pre-receive
  hook if I explicitly disable the quarantine environment by unsetting
  GIT_QUARANTINE_PATH in the environment?

> If you really wanted to try to do this with out of the box Git, you
> could create a `pre-receive` hook that did policy controls and then on
> success, took all of the objects from the quarantine and rsynced them
> (without overwriting) to the remote store, and then use the
> `reference-transaction` hook to replicate the reference transaction to
> the remote side via SSH or something.  I haven't tested this, so it
> might or might not work, but you could try it.

Thanks, can you expand on how this would work with the constraints I
listed in my question?  Recapitulating:

   One option, of course, is to use a replicated file system like
   glusterfs, or replicated block store like DRBD.  But that

   (a) likely requires a lot more round-trips than git push/send-pack,
   (b) can't be used for replication to other git hosts like Github, and
   (c) can't be used for other remote transports like git-cinnabar.

It sounds like rsyncing over ssh is incompatible with (b) and (c), but
perhaps I misunderstood what you're getting at.  I tried to see if
there is some way that reference-transaction hooks help me here but
there wasn't anything obvious to me.

  reply	other threads:[~2024-11-04 13:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-02  2:06 Synchronous replication on push Taylor R Campbell
2024-11-02 10:09 ` Matěj Cepl
2024-11-02 13:35   ` Taylor R Campbell
2024-11-02 14:49     ` brian m. carlson
2024-11-04 13:35       ` Taylor R Campbell [this message]
2024-11-04 14:40         ` Konstantin Ryabitsev
2024-11-04 15:50           ` Taylor R Campbell
2024-11-04 22:36         ` brian m. carlson
2024-11-04 23:47 ` Jeff King
2024-11-05  1:34   ` Taylor R Campbell

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=20241104133544.A04D760A95@jupiter.mumble.net \
    --to=git@campbell.mumble.net \
    --cc=git@vger.kernel.org \
    --cc=mcepl@cepl.eu \
    --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).