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

On 9/17/07, Andreas Ericsson [off-list ref] wrote:

Lars Hjemli wrote:

quoted

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