> 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
