Re: sharing git work while downstream from svn?

From: Avery Pennarun <apenwarr@gmail.com>
Date: Aug 11, 2009, 23:17 UTC
Message-ID: <32541b130908111617m12fa4b97vddfa9793dff31f29@mail.gmail.com>
In-Reply-To: <auto-000020209671@sci.utah.edu>

On Tue, Aug 11, 2009 at 11:14 PM, tom fogal<tfogal@alumni.unh.edu> wrote:

Show 21 quoted lines

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