sharing git work while downstream from svn?

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

sharing git work while downstream from svn?

From: tom fogal <hidden>
Date: 2016-06-15 22:47:13

How do others manage distributed version control when everyone is
forced to rebase all the time?

To give a concrete example: in one project where I have this issue,
there's a developer who is effectively 'downstream' from me.  There's
a few other developers who are peers, w/ commit bits set on the
centralized server.  I'll make some patches that should end up on our
centralized trunk, and some that our for our experimental sub-project,
so I use format-patch and send patches around for those.

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.

I'm not sure getting them to use git would even help.  Once I rebase,
I screw my downstream.  Yet I can't avoid rebasing since I need to
update.

As I recall, some members of the gcc community are handling this
problem, somehow.  How do you do it?  Or do you just not collaborate at
the git level?

Thanks,

-tom

Re: sharing git work while downstream from svn?

From: Avery Pennarun <hidden>
Date: 2016-06-15 22:47:13

On Tue, Aug 11, 2009 at 10:55 PM, tom fogal[off-list ref] 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.
We use git-svn at Versabanq, and our process is very simple: never use
rebase, period.

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:

git checkout git-svn
git svn rebase
git checkout myworkingbranch
git merge git-svn
   # and resolve any conflicts
git checkout git-svn
git merge --no-ff myworkingbranch   # the --no-ff is very important here!
git svn dcommit

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.  Meanwhile, all your
git users never have to worry about rebasing *anything* and can use
the normal git merge/pull stuff.

Have fun,

Avery
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help