Request for rebaseif extension to be provided by default with rebase

Pierre-Yves David pierre-yves.david at
Fri Jun 17 08:58:25 CDT 2011

On Fri, Jun 17, 2011 at 03:45:55PM +0200, Sébastien Deleuze wrote:
> I talk about the use case I see in 95% of cases in our company and open
> source projects : when you pull, changes are already commited, so pulling
> create a new head. In this case hg update don't do the job, you have to
> merge, that's why fetch extension exist, but I think this is a bad answser
> to this need.
> Having a "fast forward merge" in Mercurial by default make no sense, that's
> not what I ask.
> I think this email fit in the current topic because I would like to emphasis
> the fact that, even at first time rebaseif seems just a tiny exception with
> a strange name, it is a major need for most users. I am currently
> introducing Mercurial in my company (thousands of developers) and this is a
> strong feedback from our developers, even after many months of use, some
> traning about DVCS, etc.
> From my point of view, there is a gap between hg fetch who is too stupid and
> hg pull --rebase who is too smart. The simple behaviour known by Svn or Git
> users is not available.
> One of the best quality of Mercurial against Git is its simplicity, I think
> this missing part make it more complicated to use than it should be for
> simple pull + update cases.

I'm sorry but I still don't get your point and have trouble understanding what
you are complaining about.

You can do `hg pull; hg merge` to get the equivalent of `git pull`.

Do you wish a `hg pull --merge` flag ? to do it in a single operation ?

Note: I still think that having both operation distinct by default is much

Pierre-Yves David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <>

More information about the Mercurial mailing list