merge fast forward

[Masklinn]

On 17 mai 2010, at 22:37, Steve Borho <steve at borho.org> wrote:
> On Mon, May 17, 2010 at 3:22 PM, Masklinn <masklinn at masklinn.net>  
> wrote:
>> On 2010-05-17, at 20:13 , Faheem Mitha wrote:
>>>
>>>
>>> Hi Everyone,
>>>
>>> An extract from chatter on #mercurial on IRC. I thought I'd post  
>>> in case anyone had any thoughts about this. A short addition -  
>>> actually one could include in this case all cases where merges  
>>> could be handled programatically, ie.
>>>
>>> hg merge other --fast-forward --select-everything-from-other-branch
>>>
>>> The only cases one really needs to use the wd are ones which  
>>> cannot be handled programatically, ie. which require a merge editor.
>>>
>>>                                                       Regards,  
>>> Faheem.
>>>
>>> 12:42 < faheem_> it would be nice if there was a merge in memory  
>>> option for merges you know will work without manual intervention
>>> 12:44 < muggs> faheem_: bypassing the working copy?
>>> 12:45 < muggs> something like:  hg merge OTHER --fast-forward
>>> 12:45 < muggs> if any file merges are required, it aborts?
>>> 12:49 < muggs> it's probably not easy to divorce the merge  
>>> algorithm from the dirstate
>>> 12:49 < faheem_> muggs: are they closely linked together?
>>> 12:50 < muggs> it's where it resolves renames, permissions, and such
>>> 13:00 < faheem_> muggs: one problem with that approach is that  
>>> there could
>>> still be conflicts with working copy
>>> 13:00 < faheem_> which you wouldn't know about till you tried to  
>>> update to the merge
>>> 13:01 < faheem_> since obviously such an operation wouldn't change  
>>> the wd
>>> 13:01 < muggs> sure, it's equivalent to doing a quick clone,  
>>> merging, commiting, pulling, then deleting the clone
>>> 13:02 < faheem_> muggs: yes
>>> 13:02  * muggs wonders if you could just allocate a fake dirstate  
>>> to merge with
>>> 13:03 < muggs> btw: I use the term fast-forward for a reason; this  
>>> is the technical term for conflict-less merges.  git has special  
>>> code for them
>>
>> Uh… fast-forward isn't a merge without conflicts, it's a merge whe 
>> re there is no divergence (though it's a subset of merges with no  
>> conflicts, they're not the same thing).
>>
>> Example:
>>
>>          A---B---C topic
>>         /
>>    D---E master
>>
>> in this case, if you merge topic into master you get
>>
>>          A---B---C topic
>>         /         \
>>    D---E-----------F master
>>
>> but if you merge with fast forward enabled you end up with
>>
>>    D---E---A---B---C master
>>
>> Note how the final graphs are entirely different.
>
> Ah, it's actually a rebase.  My lack of git knowledge strikes again.
> This will need another catch-phrase.
>
Yes, I guess it can be seen as a very restricted kind of rebase  
specifically for the cases where there is nothing to rebase.