sharing git work while downstream from svn?

sharing git work while downstream from svn?

[tom fogal]

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

Re: sharing git work while downstream from svn?

[Avery Pennarun]

On Tue, Aug 11, 2009 at 10:55 PM, tom fogal<tfogal@alumni.unh.edu> 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

Re: sharing git work while downstream from svn?

[tom fogal]

Avery Pennarun <apenwarr@gmail.com> writes:
> On Tue, Aug 11, 2009 at 10:55 PM, tom fogal<tfogal@alumni.unh.edu> 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.
> 
> 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:
[snip]
> 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.

... 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

Re: sharing git work while downstream from svn?

[Avery Pennarun]

On Tue, Aug 11, 2009 at 11:14 PM, tom fogal<tfogal@alumni.unh.edu> wrote:
> Avery Pennarun <apenwarr@gmail.com> writes:
>> On Tue, Aug 11, 2009 at 10:55 PM, tom fogal<tfogal@alumni.unh.edu> 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.
>>
>> 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:
> [snip]
>> 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.
>
> ... 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.

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.)