RE: Using git svn rebase at quarantine environment or a feasible alternative to synchronize git and svn repositories

[Jose Gisbert <jose.gisbert@live.com>]

> 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 read about the dangers of updating refs at the pre-receive hook at
git-receive-pack man pages and, of course, it's something to take into
account. But, given that this setup will be temporary and the technical
complexity of the other solutions you propose (solution #2 seems unfeasible
and I don't know where to find and how to modify refs code or quarantine code)
I'm more predisposed to try solution #1 by now.

Moreover, assuming that solution #1 will generally work and the facts that:

- I think it would be possible to us to recover from a corrupted repository
  somehow easily. Couldn't we, for instance, reset from a failed push and try
  it again?
- the chances of corrupting the svn repository, our reference here, seem small
  because git svn dcommit is the last operation in the chain and is only
  performed when everything else went ok
- we are a small team and git is not our main CVS, so we can stop pushing to
  git while we fix the repository

I'm more inclined to apply this solution. Maybe I'm being too much optimistic
with my assumptions.

Nevertheless I will investigate the "clone -s" alternative. It seems easy to
implement and performance is currently not a limitation for us.

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

Thank you for your elaborated response Jeff. It has been a pleasure to write
to the git community email group.

Regards,

Jose