From: tom fogal <tfogal@alumni.unh.edu>
Date: Tue, 11 Aug 2009 23:14:38 GMT
Subject: Re: sharing git work while downstream from svn?
Message-ID: <auto-000020209671@sci.utah.edu>
In-Reply-To: <32541b130908111603v1e3f6c42peac792caf7097e0d@mail.gmail.com>

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