Request for rebaseif extension to be provided by default with rebase

[Sébastien Deleuze]

I don't think so, fast forward merge after a pull is more about changes
already commited locally before the pull.

On Sat, Jun 18, 2011 at 10:21 AM, Tony Mechelynck <
antoine.mechelynck at gmail.com> wrote:

> On 18/06/11 09:07, Sébastien Deleuze wrote:
>
>> The functionnality I talk about is not real rebase (I would be
>> dangerous) but fast foward merge done automatically after a git pull.
>> http://stackoverflow.com/**questions/2850369/why-uses-**
>> git-fast-forward-merging-per-**default<http://stackoverflow.com/questions/2850369/why-uses-git-fast-forward-merging-per-default>
>>
>> It seems to me that what is closer of git fast forward merge is
>> Mercurial is rebaseif, but this may be not technically right.
>>
>> A fast forward merge is less powerfull than a rebase (even than a
>> rebaseif) but much more secure.
>> In GIt SCM book, it is described as the following :
>>
>>
>>      Fast-forward merges
>>
>> There is one special case not mentioned above, which is treated
>> differently. Normally, a merge results in a merge commit with two
>> parents, one for each of the two lines of development that were merged.
>>
>> However, if the current branch has not diverged from the other--so every
>> commit present in the current branch is already contained in the
>> other--then git just performs a "fast forward"; the head of the current
>> branch is moved forward to point at the head of the merged-in branch,
>> without any new commits being created.
>>
>> I don't know how to call this in Mercurial world ...
>>
>
> An update? Here is an extract from "hg help update":
>
>     The following rules apply when the working directory contains
>> uncommitted
>>    changes:
>>
>>    1. If neither -c/--check nor -C/--clean is specified, and if the
>> requested
>>       changeset is an ancestor or descendant of the working directory's
>>       parent, the uncommitted changes are merged into the requested
>> changeset
>>       and the merged result is left uncommitted. If the requested
>> changeset
>>       is not an ancestor or descendant (that is, it is on another branch),
>>       the update is aborted and the uncommitted changes are preserved.
>>
>
> IIUC, Mercurial lacks the concept of "a branch already contained in
> another" -- if all the changesets of the one are already part of the other,
> then it's the same branch.
>
> Best regards,
> Tony.
> --
> Sorry.  I forget what I was going to say.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110618/2f8546ce/attachment.htm>