git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Jose Gisbert <jose.gisbert@live.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Using git svn rebase at quarantine environment or a feasible alternative to synchronize git and svn repositories
Date: Mon, 1 Oct 2018 10:53:44 -0400	[thread overview]
Message-ID: <20181001145344.GA26349@sigill.intra.peff.net> (raw)
In-Reply-To: <VI1PR0902MB2223EA3FC0ACE7E9AFB7A6ACE2EF0@VI1PR0902MB2223.eurprd09.prod.outlook.com>

On Mon, Oct 01, 2018 at 08:12:49AM +0000, Jose Gisbert wrote:

> My proposal consists to import the svn repository to git using git svn and set
> receive.denyCurrentBranch to updateInstead. Then install pre-receive and
> post-receive hooks and set that repository as the central repository for git
> users.
> 
> The pre-receive hook does git svn rebase and, if there is an update at the svn
> repository, rejects the push and instructs the user to do git pull. The
> post-receive hook does git svn dcommit to update the state of the svn
> repository, then instructs the user to do git pull too.
> [...]
> However I'm stuck at this point because the pre-receive hook it's not allowed
> to do git svn rebase because update refs are not allowed at the quarantine
> environment. I was sure that I tried this solution with a past version of git
> and it worked, but now I doubt this because the restriction to update refs at
> quarantine environment was delivered at version 2.13, that dates from April
> 2017, if I'm not wrong.

As you noticed, this used to be allowed. But it's dangerous, because if
the movement of the objects out of quarantine fails, then you're left
with a corrupted ref (ditto, anybody looking at the ref after update but
before quarantine ends will see what appears to be a corrupted
repository).

There are two solutions I can think of:

  1. The unsafe thing is to just unset $GIT_QUARANTINE_PATH before
     running "git svn rebase". That will skip the safety check
     completely, enabling the pre-v2.13 behavior. I don't really
     recommend this, but modulo the race and unlikely file-moving
     errors, it would probably generally work.

  2. Store intermediate results from pre-receive not as actual refs, and
     then install the refs as part of the post-receive. I don't think
     there's out of the box support for this, since "git svn rebase" is
     always going to call "git rebase", which is going to try to write
     refs.

     The smoothest thing would be for the refs code to see that
     $GIT_QUARANTINE_PATH is set, write a journal of ref updates into a
     file in that path, and then have the quarantine code try to apply
     those ref updates immediately after moving the objects out of
     quarantine (with the usual lease-locking mechanism).

     That's likely to be pretty tricky to implement, so I'm not even
     going to try to sketch out a patch in this email.

     You might be able to do something similar by hand by using a
     temporary sub-repository. E.g., "clone -s" to a temp repo, do the
     rebase there, and then in the post-receive fetch the refs back.
     That's less efficient, but the boundaries of the operation are very
     easy to understand.

> I come here asking for help because I think this is the appropriate place to
> do so. I apologise if this is not the case. Any help is welcome. If anything
> needs to be clarified, please, ask me to do so. I can share with you the
> source code of the hook scripts, if necessary.

This is definitely the right place. Sorry I don't have a better answer!

-Peff

  parent reply	other threads:[~2018-10-01 14:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-01  8:12 Using git svn rebase at quarantine environment or a feasible alternative to synchronize git and svn repositories Jose Gisbert
2018-10-01  8:55 ` Ævar Arnfjörð Bjarmason
2018-10-01 14:17   ` Jose Gisbert
2018-10-01 15:00     ` Ævar Arnfjörð Bjarmason
2018-10-02 10:29       ` Jose Gisbert
2018-10-01 14:53 ` Jeff King [this message]
2018-10-02 10:28   ` Jose Gisbert
2018-10-02 14:27     ` Jeff King

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181001145344.GA26349@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=jose.gisbert@live.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).