Thanks for this feedback, I think I understand my mistake now and the misconceptions there is on this subject.<br><br>That woudl mean that the only way to acheive the "pull + push with a linear history when I have local commits" is only possible in Mercurial with a "safe rebase". Sad news for me !<br>
<br>The fast forward functionnality is more related to the other issues I reported with bookmarks in the Mercurial workflow thread ...<br><br><div class="gmail_quote">On Sat, Jun 18, 2011 at 3:38 PM, Benoit Boissinot <span dir="ltr"><<a href="mailto:bboissin@gmail.com">bboissin@gmail.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 Sat, Jun 18, 2011 at 3:25 PM, Sébastien Deleuze <<a href="mailto:seb@deleuze.fr">seb@deleuze.fr</a>> wrote:<br>
><br>
> In Mercurial, The fast forward merge could be done on "hg pull --ff" in case<br>
> we have local commit not pushed to the local repo. It would just update the<br>
> parent of the local commits to the freashly pulled one, avoiding an<br>
> unecessary anonymous head when we just pull to update the local repo.<br>
<br>
</div>fast-forward is only meaningful for git or hg with bookmarks (it's a<br>
"pointers/bookmarks" operation, not an operation on the history).<br>
The case you describe would *not* be a fast-forward with git, if you<br>
have divergent commits you cannot fast forward.<br>
<br>
I really wish people would not say fast-forward merge (since it's not<br>
a merge), but fast-forward update.<br>
<font color="#888888"><br>
Benoit<br>
</font></blockquote></div><br>