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

Lars Hjemli wrote:

Ok. I'll try to explain why I needed --no-ff in the first place:

I have two git-svn brances, lets call them FEATURE and RELEASE. At one
point, I did
  $ git checkout FEATURE
  $ git merge RELEASE
  $ git svn dcommit

Now, my coworkers can continue testing/developing on top of the
subversion branch FEATURE (I'm currently the only git user), knowing
that every bugfix from RELEASE have been merged.

A few days later, FEATURE is completed and tested and should be
integrated in RELEASE. I did

  $ git checkout RELEASE
  $ git merge FEATURE
  $ git svn dcommit -n

and noticed that git-svn wanted to commit the result to FEATURE, since
the merge actually was a fast-forward. If this was a a pure git
environment it would be no problem, but as I needed to get a merge
revision on top of the subversion RELEASE branch, I was in trouble.
  

I understand.  But if you could specify a target branch of "RELEASE" to
dcommit (which git-svn might know based on which svn tracking branch it
was branched from), then it should be able to do the same thing that
'svn merge' would do on svn 1.5+, or 'svk sm' does.  Which is to write
to the SVN repository a squash merge, and write svn properties to let
merge-aware svn tools know which SVN revisions are being squashed.

My options:
* rebase FEATURE onto RELEASE: this would have duplicated ~150
revisions from FEATURE onto RELEASE in subversion
  

Yes, not desirable.

* merge --squash: this would have created the wanted history in
subversion, but my git history would have lacked the info that
everything in FEATURE had been integrated into RELEASE (this could
have been fixed by editing the grafts file)
  

This is a current deficiency in git-svn; bidirectional merge tracking is
not there yet.

* merge --no-ff: this made both the subversion history and my local
git history reflect what actually happened.

So I went for the --no-ff option.

If this use-case isn't good enough, oh well. I can always carry the
patch forward in my git repo ;-)
  

And you'll probably need to keep it around until bidirectional merge
handling is in.

Sam.