On Tue, Aug 11, 2009 at 11:14 PM, tom fogal<tfogal@xxxxxxxxxxxxxx> wrote: > Avery Pennarun <apenwarr@xxxxxxxxx> writes: >> On Tue, Aug 11, 2009 at 10:55 PM, tom fogal<tfogal@xxxxxxxxxxxxxx> 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.) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html