Re: git-svn merge helper

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Oct 2, 2007, 21:14 UTC
Message-ID: <20071002211400.GA992@atjola.homenet>
In-Reply-To: <8c5c35580710010113v7d4ad14bt129b7cb12d8f4fb8@mail.gmail.com>

On 2007.10.01 10:13:45 +0200, Lars Hjemli wrote:

Show 15 quoted lines

> On 10/1/07, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
> > On Oct 1, 2007, at 4:50 AM, Björn Steinbrink wrote:
> > > Then how does that work? The manpage explicitly says that I should not
> > > use git-{pull,merge} on branches I want to dcommit from. And a trivial
> > > test immediately got the expected effect of git-svn trying to
> > > commit to
> > > trunk instead of the branch.
> >
> > Ah, yes, you're right.  Well, this will work the day we can pass an
> > option to git-svn dcommit to tell it where the commit must be sent.
> >
> 
> This is fixed in the latest version of git-svn (yet to be released).
> There is no need for an extra option, git-svn dcommit now handles
> merges between subversion branches correctly.

Thanks, but there's still a case that fails.

One common pattern in SVN is to have the feature branch following the trunk. In git terms, that would mean that the feature branch is continually rebased onto the HEAD of the HEAD AFAICT (although SVN of course cannot represent that). The problem with that is, that git doesn't create a merge commit in that case and git-svn gets confused again.

git checkout mybranch git merge master # Creates a merge commit git checkout master git merge mybranch # Does just fast forward

Is there anyway to force a merge commit or some other work around?

Thanks, Björn