Request for rebaseif extension to be provided by default with rebase

Sébastien Deleuze seb at deleuze.fr
Tue Jun 21 04:45:11 CDT 2011


Yes, my mistake, I had rebasing configured by default on my git
configuration ...

Anyway, I think that rebaseif (or "safe rebase, else merge") behaviour is a
lot better than current fetch behaviour that is distributed by default with
Mercurial, wich do stupid and automatic merge even when not needed. Rebaseif
do automatic rebase when there not any conflicts, and switch to manuel merge
if there are.

Is there a better way that could allow hg pull to print me if there is
conflicts or not between my local and the remote changes when pulling them ?

This could lead to a better workflow where hg would give me some
informations in order to decide if I can run hg rebase (no conflicts) or hg
merge (conflicts) instead of trying directly a rebase with internal:fail
merge behaviour ?

On Mon, Jun 20, 2011 at 6:04 PM, Kevin Bullock <
kbullock+mercurial at ringworld.org> wrote:

> On Jun 18, 2011, at 9:13 AM, Sébastien Deleuze wrote:
>
> > Thanks for this feedback, I think I understand my mistake now and the
> misconceptions there is on this subject.
> >
> > 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 !
>
> The only way to achieve what you want -in any DVCS-, Git included, is to
> use rebase.
>
> If you have local commits that aren't already present in the repo you're
> pulling from, -and- there's other commits in that repo not present in yours,
> then you don't have linear history. Git will not fast-forward merge in this
> case, for the same reason that Mercurial bails on the update portion of
> `pull -u` in this case.
>
> If history diverges, the only way to make it linear again is to rebase. And
> that's not a workflow to be recommended for regular use.
>
> pacem in terris / mir / shanti / salaam / heiwa
> Kevin R. Bullock
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110621/bed58fc9/attachment.htm>


More information about the Mercurial mailing list