Re: Multiple branches and git-svn

David Watson [off-list ref] writes:

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.

Full agreement.

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?

Git svn needs to recognize a merge for what it is, and has to ignore
the branch which has been merged, looking further for git-svn-id lines
or whatever.  Cherrypicking is harder to contain.  Basically, I think
it is a mistake to use something as fragile as the git-svn-id line in
the log for determining the branch to use for committing.  Instead, a
fixed association of git branches with git-svn should be established.
Even if one needs to write this manually into some configuration file.
Before git-svn does not have reliable information, it should refuse to
commit.  One could specify this on the command line, too: that is a
small price to pay for being sure that one commits where one wants to.

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.

Yes.

-- 
David Kastrup