From: Avery Pennarun <apenwarr@gmail.com>
Date: Wed, 13 May 2009 17:28:04 GMT
Subject: Re: Trying to sync two svn repositories with git-svn (repost)
Message-ID: <32541b130905131028i5c4b1a31j7f760f8157507df6@mail.gmail.com>
In-Reply-To: <20090513120922.GP15420@raven.wolf.lan>

On Wed, May 13, 2009 at 8:09 AM, Josef Wolf <jw@raven.inka.de> wrote:
> Now here's the problem:  This last dcommit does simply a reset, because
> nothing has changed since the last dcommit.  So a5cf3..c3ff2 are _not_
> marked as ancestors of svn-2/trunk, causing those cherries to be rebased
> at the next dcommit with real changes.

I find this a *bit* curious, since each dcommit should be adding the
cherry-picked changes you just now picked from the opposite branch,
right?  If you weren't going to change anything, then you wouldn't
have needed to do the cherry picks at all; you could have just done a
merge -s ours in both directions in the first place.

Anyway, regardless of the above, AFAIK there's no way to force svn to
make an empty commit, which is a problem in this case.  You can make a
nonempty commit, though; I've done this in the past by just adding a
newline to the end of some arbitrary file.  Basically:

git merge -s ours whatever
echo >>Makefile
git add Makefile
git commit --amend
git svn dcommit

Silly, but it works.

> Unfortunately, dcommit doesn't seem to have an option to force rebase
> instead of resetting.

Well, in fact it *is* rebasing, which throws away the extra commit
because it thinks that commit didn't do anything.  I've experienced
this problem a few times in the past, but I knew what was happening
and I figured my case was too rare to matter.  Perhaps not.

This could be considered a bug in git-svn, so I cc:'d Eric Wong, who I
think is the main git-svn developer.  Anyway, try the workaround
above.

Good luck,

Avery