Re: git-svn set-tree bug

From: Steven Grimm <koreth@midwinter.com>
Date: Jun 11, 2007, 06:58 UTC
Message-ID: <466CF2A0.4080604@midwinter.com>
In-Reply-To: <20070611042509.GA19866@muzzle>

Eric Wong wrote:

> Doable?  Yes.  However, I think using grafts is quite hackish and
> unreliable[1].  I'd rather just have users using set-tree if
> they want to deal with non-linear history in the first place.
>

Agreed about grafts being hackish and unreliable. But they were what I had to work with, given that I know little enough about git-svn's internals to be able to implement Junio's more robust idea.

IMO set-tree is not much of an option. In my environment it is unacceptable for there to be any possibility of accidentally and silently overwriting some other change that just happened to hit the svn repo right before I committed my change, which (unless it has changed since I last tried it) set-tree will happily do. I can get away with doing that maybe once before my company's release manager will, quite justifiably, require me to stop using git and switch back to the standard svn client.

> I'd personally avoid any sort of non-linear history when interacting
> with SVN repositories, however.
>

Which is a shame since git loses a lot of its utility without nonlinear history. For example, the script I posted uses git to do merges between svn branches. It works wonderfully even if, as you and Junio point out, its use of grafts to record svn merges scales poorly and is potentially susceptible to corruption. Thanks to the ability to record the fact that my merges between svn branches were actually merges, my git clone has a more complete picture of what's in my svn repository than the svn repository itself does!

-Steve