git-svn and local feature branch (git svn dcommit error ?)

[Christian Stimming]

Am Samstag, 21. Mai 2011 schrieb Geert Janssens:
> I probably created this by dcommitting from two separate git working
> branches without first waiting for a repo sync, then git-updating and then
> rebasing my working branches to the new trunk.
> 
> Anyway the solution is the remove the .git/svn directory to reset git-svn's
> metadata. After that, dcommit worked again.
> 
> I can see also now that this probably can be avoided altogether by using
> your workflow, namely rebasing trunk on the working branch you want to
> dcommit instead of the other way around. That ensures all dcommits happen
> from the same branch (trunk).

Right, that's what I would have suggested as well (probably). I'd say that 
since all commits to SVN inherently need to be rebased on SVN-trunk, the 
developer should probably rebase or cherry-pick them to his local trunk 
tracking branch, then always svn-dcommit from that same trunk tracking branch.

> I'll note that this was not clear from our git wiki page. I have added an
> example workflow so other new users of our git setup don't have to make the
> same mistakes. Can you proofread my additions to make sure I didn't write
> too much nonsense ?

Why do you run the rebase the way you do? You rebase your trunk on your local 
feature branch, which means you will change your trunk branch:

I would have expected that the other way round first: Your feature branch need 
to be rebased on trunk because for SVN, any of your changes must be rebased on 
SVN's trunk anyway. Then, you can "rebase" (or rather: fast-forward) your 
local trunk on feature which means your local trunk is based on SVN-trunk plus 
all commits from your feature branch. Then, you can dcommit.

I wouldn't expect a "git merge" anywhere in this workflow, again because SVN 
forces us to rebase for anything that is dcommitted. The only exception would 
be to keep around a feature branch that is based on some older trunk commit 
and it contains stuff that is not (yet) in SVN trunk. However, in that case I 
would cherry-pick specific commits from the feature branch into trunk, dcommit 
those to SVN, and only then run "git checkout feature; git merge trunk". But 
you won't need that if your feature branch was dcommitted to SVN in full 
anyway.

Regards,

Christian