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