The functionnality I talk about is not real rebase (I would be dangerous) but fast foward merge done automatically after a git pull.<br><a href="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</a><br>
<br>It seems to me that what is closer of git fast forward merge is Mercurial is rebaseif, but this may be not technically right.<br><br>A fast forward merge is less powerfull than a rebase (even than a rebaseif) but much more secure.<br>
In GIt SCM book, it is described as the following :<br><h3>Fast-forward merges</h3>
<p>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.</p>
<p>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.</p>I don't know how to call this in Mercurial world ...<br><br><div class="gmail_quote">On Sat, Jun 18, 2011 at 12:29 AM, Matt Mackall <span dir="ltr"><<a href="mailto:mpm@selenic.com">mpm@selenic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Fri, 2011-06-17 at 17:08 -0500, Kevin Bullock wrote:<br>
> On 17 Jun 2011, at 9:59 AM, Sébastien Deleuze wrote:<br>
><br>
> > Both Git and Mercurial allow to do disinct operation, it is just about naming :<br>
> > - hg pull = git fetch<br>
> > - hg pull --rebaseif = git pull (fast forward activated by default)<br>
><br>
> 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.<br>
<br>
</div>To get any sort of rebasing on pull with git, you need to do:<br>
<br>
git pull --rebase<br>
<br>
..which comes with the following sternly-worded caveat:<br>
<br>
Note<br>
This is a potentially dangerous mode of operation. It rewrites<br>
history, which does not bode well when you published that<br>
history already. Do not use this option unless you have read<br>
git-rebase(1) carefully.<br>
<br>
And there's no sign of a rebase-if equivalent.<br>
<br>
If you went to the git folks and said "we would like to use rebasing as<br>
a default in our workflow", Linus himself would probably disabuse you of<br>
that notion in some way that I'm too polite for. You can find dozens of<br>
instances of him publically clue-batting various senior kernel<br>
developers for being foolish enough to automatically rebase.<br>
<br>
"But git does it!" simply ain't gonna fly.<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Mathematics is the supreme nostalgia of our time.<br>
<br>
<br>
</div></div></blockquote></div><br>