On 2007.10.01 10:13:45 +0200, Lars Hjemli wrote:
quoted text
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html