Request for rebaseif extension to be provided by default with rebase

[Sébastien Deleuze]

It is different since it would provide rebaseif extension (
http://mercurial.selenic.com/wiki/RebaseIfExtension) behaviour.

"hg pull --rebase" rebase as soon has "hg pull" create a new head

In my proposal, hg fetch would rebase only if no conflict.
An improvement proposed on this thread, compared to current rebaseif
behaviour,  is that it would use internal:fail as merge tool.
As a consequence, the rebase will be done only when remote and local changes
concern different files.
It can be seen as a safe rebase (or fast forward merge ;-)
If the rebase fail, rebase is aborted, so we rollback to a simple hg pull
state.
And then it runs hg merge + hg commit.

The only point that puzzle me is that I don't really like the auto commit
step. It could be ok for merge that succeed with the internal merge step,
but it is not great for complicated merge with external tool.

Does anybody know the current fetch behaviour on merge requiring external
tool ? auto commit or manual commit ?
Does this proposal on fetch side make sense for someone ?

Regards,
Sébastien Deleuze

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

> first thank for the time you spend explaining your issue.
>
> On Fri, Jun 17, 2011 at 04:59:58PM +0200, Sébastien Deleuze wrote:
>
> > Current behaviour of fetch is based on merge only :
> > hg fetch
> >
> > We could add a parameter like
> > hg fetch --rebase
> > or
> > hg fetch -r
>
> How this command is different from `hg pull --rebase` ?
>
> --
> Pierre-Yves David
>
> http://www.logilab.fr/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk37eyoACgkQElczi7p/bN85RACePmQMFcg4i95VooqYPTPblLvP
> u/sAnjTnY8XW68QIFHvFpTnsr6eSEDTE
> =0tXG
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110617/570e4905/attachment.htm>