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

John Ralls jralls at ceridwen.us
Sat May 21 18:53:30 EDT 2011


On May 21, 2011, at 2:52 PM, Christian Stimming wrote:

> 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.

The procedure in the Wiki page is what I think is correct (and what I've done). 

It's perfectly normal in git to get part of a complicated feature done and copy that bit to the main branch (trunk for us, but "master" is the usual name in git repos) and then to keep working on the feature branch. In that case one should periodically merge the main branch into the feature branch so that the feature branch stays reasonably close to the main branch.  That's not allowed in the released version of subversion because of the way it handles merges (and has no concept of rebasing or cherry-picking). The development branch of subversion is supposed to handle this better... I haven't tried it though.

Regards,
John Ralls



More information about the gnucash-devel mailing list