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

[Sam Vilain <sam@vilain.net>]

Lars Hjemli wrote:
> [...sorry for making this such a long thread...]
>
> On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
>   
>> Lars Hjemli wrote:
>>     
>>> On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
>>>
>>>       
>>>> 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.

>>> 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.