Re: git-svn set-tree bug

[Steven Grimm <koreth@midwinter.com>]

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