Request for rebaseif extension to be provided by default with rebase

[Sébastien Deleuze]

@Tony hg update is just about updating working directory, it is not related
to the functionnality discussed in this topic, wich is avoiding when it is
possible creation of an anonymous head when pulling from a remote
repository.

My remark "I don't know how to call this in Mercurial world ..." don't mean
I don't know what is Mercurial equivalent, I use both tools daily and there
is currently not.  I just wonder on vocabulary since both tools have not the
same.

@Matt I said hg pull --rebaseif equivalent is git merge (default command)
since it has fast forward merge activate by default.
Even if from the user point of view rebaseif and fast forward merge seems to
be quite the same, it may be not exactly the same.

Quoted from GIT documentation  :

"There is one special case not mentioned above, which is treated
differently. Normally, a merge results in a merge commit, with two parents,
one pointing at each of the two lines of development that were merged.
However, if the current branch is a descendant of the other—so every commit
present in the one 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."

Be carefull things are different, in Git they speak about branches, in
Mercurial this functionnality is more related to heads inside the same
branch.

Also, the sentence "every commit present in the one is already contained in
the other" is confusing and does not make sense in Mercurial. Git does not
create anonymous head when pull from a remote repo if you have local commit
not pushed. If someone know that know well both tools could explain that
better than me it could help ;)
In Mercurial, The fast forward merge could be done on "hg pull --ff" in case
we have local commit not pushed to the local repo. It would just update the
parent of the local commits to the freashly pulled one, avoiding an
unecessary anonymous head when we just pull to update the local repo.

On Sat, Jun 18, 2011 at 1:27 PM, Tony Mechelynck <
antoine.mechelynck at gmail.com> wrote:

> On 18/06/11 10:35, Sébastien Deleuze wrote:
>
>> I don't think so, fast forward merge after a pull is more about changes
>> already commited locally before the pull.
>>
>
> Well, hg update is about changing which changeset is reflected in the
> working directory.
>
> When there are no uncommitted changes, "hg update" always succeeds (IIUC)
> and it makes your current working directory reflect the contents of the
> requested changeset. No new commit happens in any case, and no merge is
> necessary, since with no uncommitted changes, what would there be to merge?
> If the requested changeset is a descendant of the previously current
> changeset, then IIUC you get the equivalent of what git calls a
> fast-forward.
>
> The way I see it, the only time a fast-forward would need to "merge"
> anything would be if there were uncommitted changes.
>
>
> Best regards,
> Tony.
> --
> Build a better mousetrap, the saying goes -- and with the brassiere,
> Yankee Ingenuity did exactly that.  But their true stroke of genius was
> the new bait.  The old fashioned mousetrap was loaded with cheese;
> nobody cares much about cheese, except mice.  But when American
> Know-How reloaded the brassiere with tits, every heterosexual male in
> the country was hopelessly trapped.
>                -- Alan Sherman, "The Rape of the A*P*E*"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110618/dbbd48b0/attachment.htm>