sharing git work while downstream from svn?

How do others manage distributed version control when everyone is forced to rebase all the time?

To give a concrete example: in one project where I have this issue, there's a developer who is effectively 'downstream' from me. There's a few other developers who are peers, w/ commit bits set on the centralized server. I'll make some patches that should end up on our centralized trunk, and some that our for our experimental sub-project, so I use format-patch and send patches around for those.

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.

I'm not sure getting them to use git would even help. Once I rebase, I screw my downstream. Yet I can't avoid rebasing since I need to update.

As I recall, some members of the gcc community are handling this problem, somehow. How do you do it? Or do you just not collaborate at the git level?

Thanks,

-tom

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

[snip]

... but I, as a git user forced to live in an svn world, *do* value all of that history. When I find a bug a month later, I want git-bisect to be useful. Further, when I'm reviewing sets of changes in a search for some particular change, I want to be able to skip over large sets of patches simply by looking at the first line of a commit log. If I squash all that history down, I have to wade into the patch itself.

-tom

That's the great thing! Your git history never gets lost with this technique, since you *never* rewind any branches. The detailed history just never makes it into svn, which has no way of representing it anyhow.

As a bonus, the fact that your git history becomes more and more detailed vs. the svn history slowly makes your case for switching everybody else to git that much stronger :)

Have fun,

Avery

P.S. Shameless plug: I wrote the chapter about git-svn in O'Reilly's "Version Control With Git," in which I described this technique in more detail. (I *don't* make any money on commissions on that book, as I'm not the primary author.)