Re: [PATCH] git-merge: add option --no-ff

From: Lars Hjemli <hjemli@gmail.com>
Date: Sep 17, 2007, 13:16 UTC
Message-ID: <8c5c35580709170616i49a8836hb60423c5eebf601d@mail.gmail.com>
In-Reply-To: <46EE7584.8010202@op5.se>

On 9/17/07, Andreas Ericsson <ae@op5.se> wrote:

Show 23 quoted lines

> Lars Hjemli wrote:
> > This new option forces all merges to create a "true" merge commit, i.e. a
> > commit with multiple parents.
> >
> > Although a fast-forward would normally be The Right Thing, it isn't when the
> > branches to be merged originated in subversion and the merge commit will
> > be pushed back by means of 'git svn dcommit'. In these cases, a fast-
> > forward merge simply will not work.
> >
> >       If there is no `-s` option, a built-in list of strategies
> >       is used instead (`git-merge-recursive` when merging a single
> >       head, `git-merge-octopus` otherwise).
> > +
> > +--no-ff::
> > +     Force the creation of a merge commit even when the merge would
> > +     have resolved as a fast-forward operation.
>
> + Although a fast-forward would normally be The Right Thing, it isn't when the
> + branches to be merged originated in subversion and the merge commit will
> + be pushed back by means of 'git svn dcommit'. In these cases, a fast-
> + forward merge simply will not work.
>
> Otherwise someone will sit down and try to figure out why this is necessary.

True.

> I'm having trouble understanding why this is needed, but I'll take your word
> for it ;-)

I'll try to explain:

When 'git-svn dcommit' decides which commits it should push back subversion, it scans the output from 'git-log --first-parent HEAD' looking for embedded 'git-svn-id' lines. These lines contain the url of the upstream subversion repository + the subversion revision number. So the problem with fast-forward merges of subversion branches is that the output from 'git-log --first-parent HEAD' will show commits from the wrong subversion branch (the fast-forwarded commits).

This could maybe be fixed in git-svn if it learned a different way of discovering the upstream subversion branch, but then it would make git-svn commit n revisions to subversion (again, the fast-forwarded commits) instead of a single merge-commit. This would look (in subversion) like a series of n cherry-picks from the merged branch.

Btw: maybe the --no-ff section in merge-options.txt could just link to
git-svn.txt, which in turn could have some lengthy explanation about
merge --no-ff/dcommit behaviour?

-- larsh