Request for rebaseif extension to be provided by default with rebase
antoine.mechelynck at gmail.com
Sat Jun 18 03:21:17 CDT 2011
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.
> 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
> 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.
Sorry. I forget what I was going to say.
More information about the Mercurial