On Fri, 19 Mar 2010, Avery Pennarun wrote:
For example, I'd be very happy to learn that your new design would
allow two people to independently pull from svn://, do work in their
respective copies of the git repositories, branch and merge all day
long, pull from each other, and then push back to svn without a)
making a mess of the svn repo and causing zillions of conflicts, or b)
linearizing history and losing git's complex DAG.
In the current version of git-svn this is very hard. 'git svn dcommit'
generates entirely new git commit objects corresponding to the ones
that were created in svn... but which nevertheless have your merge
history included, which is awesome. But if a new person clones the
svn repo from scratch, he will end up with git commits corresponding
to those same ones from svn, but *without* the merge history, and
therefore with different commit ids, and which therefore prevent
push/pulling between other people who have cloned the repo.
I've been working on a script that does 2-way integration with an
upstream CVS repo, using git-cvsimport and git-cvsexportcommit to do the
difficult parts.
I solved this problem you mention by rebasing in both directions onto
detached HEADs and exporting the result, meaning that the history is
permanently diverged from a DAG standpoint. Of course, over time, the
rebase would become increasingly messy and horrible, so I created a
couple of placeholder refs which are updated after the import/export is
finished. These mark the last time it was done, and allow you only to
attempt to apply the commits which are new on each side.
It's still very green and I've already worked though a number of pretty
hairy problems, so I'm not going to say it's a bulletproof solution.
But it does work.
Dave
--
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