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

Lars Hjemli wrote:

[...sorry for making this such a long thread...]

On 9/18/07, Sam Vilain [off-list ref] wrote:
  

quoted

Lars Hjemli wrote:
    

quoted

On 9/18/07, Sam Vilain [off-list ref] wrote:

      

quoted

I think that writing a real fast-forward merge should only happen on
dcommit, not git merge, because that is what is required for SVN.

        

I don't think git-svn has any way of knowing that the user wanted a
merge, unless a merge commit is present. So the user would have to
specify the set of commits which should be considered a merge during
dcommit (this would actually resemble how merges are performed in
subversion).

      

Sure it can.  If you're committing to branch X, and the current tree has
a whole lot of commits above that, then it should do the only thing you
can do with SVN.

Which is write a squash commit, and set the "svn:merge" and/or
"svk:merge" properties to represent what happened.
    

I often have prepared a series of local commits which I _want_ to
preserve as different subversion revisions.
  

But for the scenario we are discussing the revisions already exist
upstream otherwise there would be no fast forward merge.  So, if you
want that behaviour you can use cherry-pick on the git side and the
correct behaviour for git-svn is to write svn merge properties.

Also, doing a --squash means that I loose the merge history in git
(and then I need to edit the grafts file again)
  

There is no merge history in git, it was a fast forward.

quoted

quoted

Sidenote: this might be slightly controversial, but I've sometimes
missed a --no-ff option to 'git merge' when working on plain git
repositories; IMHO preserving the 'logical' merge history when the
merge of a topic branch results in a fast-forward can be interesting.
      

If you really want one, use git commit-tree directly.
    

Yeah, that's an option, but --no-ff is somewhat less work ;-)
  

Sure.  I just don't see a good use case for it from this yet.

Sam.