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

["Lars Hjemli" <hjemli@gmail.com>]

On 9/17/07, Andreas Ericsson <ae@op5.se> wrote:
> 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