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. Regards, Christian _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
