Re: sharing git work while downstream from svn?

From: tom fogal <tfogal@alumni.unh.edu>
Date: Aug 11, 2009, 23:14 UTC
Message-ID: <auto-000020209671@sci.utah.edu>
In-Reply-To: <32541b130908111603v1e3f6c42peac792caf7097e0d@mail.gmail.com>

Avery Pennarun <apenwarr@gmail.com> writes:

Show 8 quoted lines

> 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