On Tue, Aug 11, 2009 at 10:55 PM, tom fogal<tfogal@xxxxxxxxxxxxxx> wrote: > This gets to be a mess when trunk changes: I'll rebase + potentially > fix some conflicts. Other developers with some of the experimental > patches will svn update, and get similar conflicts. These might differ > in subtle ways, and now exchanging patches gets more difficult. We use git-svn at Versabanq, and our process is very simple: never use rebase, period. Instead, do all your work in a branch *other* than the git-svn main branch. When you're ready to merge your stuff into svn, do: git checkout git-svn git svn rebase git checkout myworkingbranch git merge git-svn # and resolve any conflicts git checkout git-svn git merge --no-ff myworkingbranch # the --no-ff is very important here! git svn dcommit This basically results in a *single* commit getting sent to svn, rather than the batch of all the git commits you've been working on. Most svn users don't care about this, because they lose all that granularity whenever they merge a branch anyhow. Meanwhile, all your git users never have to worry about rebasing *anything* and can use the normal git merge/pull stuff. Have fun, Avery -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html