Re: Multiple branches and git-svn

David Kastrup [off-list ref] writes:

David Watson [off-list ref] writes:

quoted

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.

quoted

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.

PostScriptum: that is probably all nonsense.  git-svn fetch knows what
to fetch, and probably also what to merge (this should be quite
similar to git pull's behavior), and git-svn rebase/dcommit should not
do anything different.

-- 
David Kastrup