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