merge fast forward

[Steve Borho]

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

> I don't know if you can do that easily with local branches in mercurial, with remotes it's the default behavior of `hg pull`.

No, that's not what Faheem was asking for.  What he wants is to be
able to generate a merge changeset without affecting dirstate if the
three file sets (working changes, branch A changes, branch B changes)
do not intersect.  In theory one could generate a new manifest and
changeset and update the working parent without having to shelve your
working changes.

I don't know if I advocate such a feature.  I'm just trying to explain it.

--
Steve Borho