Request for rebaseif extension to be provided by default with rebase

[Sébastien Deleuze]

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

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

On Sat, Jun 18, 2011 at 12:29 AM, Matt Mackall <mpm at selenic.com> wrote:

> On Fri, 2011-06-17 at 17:08 -0500, Kevin Bullock wrote:
> > On 17 Jun 2011, at 9:59 AM, Sébastien Deleuze wrote:
> >
> > > Both Git and Mercurial allow to do disinct operation, it is just about
> naming :
> > >  - hg pull = git fetch
> > >  - hg pull --rebaseif = git pull (fast forward activated by default)
> >
> > No, `git pull` = `hg pull -u` (except that git pull will also change
> where the branch ref points). A `git pull` will never rebase AFAIK.
>
> To get any sort of rebasing on pull with git, you need to do:
>
> git pull --rebase
>
> ..which comes with the following sternly-worded caveat:
>
>               Note
>               This is a potentially dangerous mode of operation. It
> rewrites
>               history, which does not bode well when you published that
>               history already. Do not use this option unless you have read
>               git-rebase(1) carefully.
>
> And there's no sign of a rebase-if equivalent.
>
> If you went to the git folks and said "we would like to use rebasing as
> a default in our workflow", Linus himself would probably disabuse you of
> that notion in some way that I'm too polite for. You can find dozens of
> instances of him publically clue-batting various senior kernel
> developers for being foolish enough to automatically rebase.
>
> "But git does it!" simply ain't gonna fly.
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110618/bf6d75f4/attachment.htm>