Re: Multiple branches and git-svn

On Aug 21, 2007, at 1:56 PM, David Watson wrote:

Yes, that's quite true. It took me quite a while to figure that out  
when I
first started using git-svn, and its non-sensicalness nearly put me  
off using
git entirely. My workflow at this point is to use git-cherry-pick - 
e to pull in
any changes from other branches, then delete the git-svn-id line.

Essentially, merging using git-svn is almost entirely broken, since an
inconsistent tool is worthless - you spend more time figuring out  
if it's going
to break, and working around the breakage, than you save using it.

To me this sounds exaggerated, I fell in the pitfall once after a git- 
rebase but never had the problem again since then.

Now, I'm not sure this is 100% the fault of git-svn. Perhaps  
keeping its
metadata about which SVN branch it's connected to isn't the best  
thing, but
git-merge is doing exactly what you ask for. Perhaps we need a  
merge command in
git-svn that does the right thing? Although what that right thing  
would be, I'm
not quite sure.  Either way, there needs to be a BIG GIGANTIC  
WARNING in the
git-svn manual that if you actually use git for what it claims to  
be great at
(i.e., merging) you may be in for a world of pain, with your  
coworkers and boss
coming at you with pitchforks and torches. Especially because there  
are
so many git users who need to interoperate with SVN.

IMO the only think that git-svn dcommit needs is an option to specify  
to which SVN branch you want to commit in case you want your commit  
to go in another branch than that specified in the last git-svn-id line.

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory