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

[John Ralls]

On May 22, 2011, at 12:54 PM, Christian Stimming wrote:

> Am Sonntag, 22. Mai 2011 schrieb John Ralls:
>> 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
> 
> Yes, absolutely, for the normal git workflow.
> 
> However, here we are talking about the git-svn branch from which we want to 
> dcommit to SVN. The IMHO unexpected part here is this:
> 
>> git checkout trunk
>> git rebase feature
>> git svn dcommit
> 
> I.e. why is the "trunk" rebased on top of the "feature" branch, then being d-
> committed? Either all of the feature branch should go into SVN, in which case 
> I would rebase "feature" on top of "trunk" (i.e. the other way round compared 
> to the above steps). Or the "feature" commits should not (yet) be committed, 
> in which case I would do
> 
>> git checkout feature
>> git merge trunk
> 
> and then occasionally cherry-pick some of "feature"'s commits into trunk and 
> d-commit from there. In the end, I would again rebase "feature" on top of 
> "trunk" and this way d-commit all the commits that haven't been cherry-picked 
> to trunk before.
> 
> I agree this "git merge trunk" is written in the end of this new section, and 
> that's what I have expected. But the "git rebase feature" still looks 
> unexpected to me.

Sorry, you're right. I got the direction of rebase backwards. So it should be

git checkout feature
git rebase trunk
(Or just `git rebase trunk feature` which does both steps at once)
git svn dcommit

You're probably right about cherry-picking, too. (You can cherry-pick all of the changes at once with `git cherry-pick ..trunk` when checked out in feature.) Rebasing might have contributed to Geert's remote refs getting messed up.

Starting with 
     B - D - E		Feature
  /
A  - C - F		Trunk

Rebasing does this:

                 B' - D' - E'  
               /
A - C- F  

If you dcommit with E' checked out (which is where you'll be after the rebase), Github:Gnucash/gnucash will see

A - C - F - B" - D" - E"

When you run git-update you'll have 

                  B' - D' - E'
               /
A - C - F - B" - D" - E" 

And a merge will adjust your references to 

                  B'   -   D'   -   E'
               /                     /
A - C - F - B" - D" - E" 

On the other hand, cherry-picking the whole thing will produce
    B - D - E
  /
A  - C - F - B' - D' - E'

Which after dcommitting, git-updating, and merging will look like:

    B       -        D      -      E
  /                                  /
A  - C - F - B" - D" - E"

Which is a better reflection of history and has less chance of references getting screwed up. On the other hand, you have to make sure that your checked out on trunk at E' when you dcommit (or say `git svn dcommit trunk`) or you'll wind up dcommitting your feature branch to subversion, which will make a bit of a mess.

Regards,
John Ralls