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> - hg pull -u = git pull (with fast forward deactivated)<br>
<br>Please have a look to the first answer of this question on stackoverflow for more details :<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>I had another idea after discussing with a colleague. Since current behaviour of fetch extension seems not really loved, perhaps it makes sense to add this feature as a parameter of hg fetch command.<br><br>Current behaviour of fetch is based on merge only :<br>
hg fetch<br><br>We could add a parameter like <br>hg fetch --rebase<br>or<br>hg fetch -r<br><br>It would first try to a rebase  with internal:fail mode, abort rebase in case of conflict, and then merge.<br>This could improve fetch extension as it would avoid creation of uncessary merge.<br>
<br>The even better solution (from my POV again :) could be to add this feature by default, this could fix the current &quot;bad behaviour&quot; of hg fetch, and add a parameter like hg fetch --merge to retsore current behaviour.<br>
<br>Since fetch is already included in Mercurial (but not activated by default), this could be a nice compromise :<br> - No new behaviour activated by default<br> - No new extension to include in Mercurial<br> - We could add a new behaviour to fetch that coudl be considered as less deprecated than current one<br>
<br>What do you think about this proposal ?<br><br><div class="gmail_quote">On Fri, Jun 17, 2011 at 3:58 PM, Pierre-Yves David <span dir="ltr">&lt;<a href="mailto:pierre-yves.david@logilab.fr">pierre-yves.david@logilab.fr</a>&gt;</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, Jun 17, 2011 at 03:45:55PM +0200, Sébastien Deleuze wrote:<br>
&gt; I talk about the use case I see in 95% of cases in our company and open<br>
&gt; source projects : when you pull, changes are already commited, so pulling<br>
&gt; create a new head. In this case hg update don&#39;t do the job, you have to<br>
&gt; merge, that&#39;s why fetch extension exist, but I think this is a bad answser<br>
&gt; to this need.<br>
&gt;<br>
&gt; Having a &quot;fast forward merge&quot; in Mercurial by default make no sense, that&#39;s<br>
&gt; not what I ask.<br>
&gt;<br>
&gt; I think this email fit in the current topic because I would like to emphasis<br>
&gt; the fact that, even at first time rebaseif seems just a tiny exception with<br>
&gt; a strange name, it is a major need for most users. I am currently<br>
&gt; introducing Mercurial in my company (thousands of developers) and this is a<br>
&gt; strong feedback from our developers, even after many months of use, some<br>
&gt; traning about DVCS, etc.<br>
&gt;<br>
&gt; From my point of view, there is a gap between hg fetch who is too stupid and<br>
&gt; hg pull --rebase who is too smart. The simple behaviour known by Svn or Git<br>
&gt; users is not available.<br>
&gt;<br>
&gt; One of the best quality of Mercurial against Git is its simplicity, I think<br>
&gt; this missing part make it more complicated to use than it should be for<br>
&gt; simple pull + update cases.<br>
<br>
<br>
</div>I&#39;m sorry but I still don&#39;t get your point and have trouble understanding what<br>
you are complaining about.<br>
<br>
You can do `hg pull; hg merge` to get the equivalent of `git pull`.<br>
<br>
Do you wish a `hg pull --merge` flag ? to do it in a single operation ?<br>
<br>
Note: I still think that having both operation distinct by default is much<br>
better.<br>
<font color="#888888"><br>
--<br>
Pierre-Yves David<br>
<br>
<a href="http://www.logilab.fr/" target="_blank">http://www.logilab.fr/</a><br>
<br>
</font><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
iEYEARECAAYFAk37XYEACgkQElczi7p/bN9oJwCeNZiAQ3OBmGuQ3J12KacnKFk8<br>
JJkAnip6Q+quP3WNFOC4fbJgV4pLlKn+<br>
=XR9K<br>
-----END PGP SIGNATURE-----<br>
<br></blockquote></div><br>