Request for rebaseif extension to be provided by default with rebase

Sébastien Deleuze seb at deleuze.fr
Fri Jun 17 09:59:58 CDT 2011


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)
 - hg pull -u = git pull (with fast forward deactivated)

Please have a look to the first answer of this question on stackoverflow for
more details :
http://stackoverflow.com/questions/2850369/why-uses-git-fast-forward-merging-per-default

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.

Current behaviour of fetch is based on merge only :
hg fetch

We could add a parameter like
hg fetch --rebase
or
hg fetch -r

It would first try to a rebase  with internal:fail mode, abort rebase in
case of conflict, and then merge.
This could improve fetch extension as it would avoid creation of uncessary
merge.

The even better solution (from my POV again :) could be to add this feature
by default, this could fix the current "bad behaviour" of hg fetch, and add
a parameter like hg fetch --merge to retsore current behaviour.

Since fetch is already included in Mercurial (but not activated by default),
this could be a nice compromise :
 - No new behaviour activated by default
 - No new extension to include in Mercurial
 - We could add a new behaviour to fetch that coudl be considered as less
deprecated than current one

What do you think about this proposal ?

On Fri, Jun 17, 2011 at 3:58 PM, Pierre-Yves David <
pierre-yves.david at logilab.fr> wrote:

> 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
> better.
>
> --
> Pierre-Yves David
>
> http://www.logilab.fr/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk37XYEACgkQElczi7p/bN9oJwCeNZiAQ3OBmGuQ3J12KacnKFk8
> JJkAnip6Q+quP3WNFOC4fbJgV4pLlKn+
> =XR9K
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110617/9ca6920a/attachment.htm>


More information about the Mercurial mailing list