Request for rebaseif extension to be provided by default with rebase

[Sébastien Deleuze]

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.

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

> On Fri, Jun 17, 2011 at 02:20:49PM +0200, Sébastien Deleuze wrote:
> > Ok feedbacks about patch are right there is an issue with it.
> > But I think the question about resbaseif like functionnality is still
> here.
> >
> > This functionnality is not only for begginers coming from SVN asking for
> a
> > command like svn update, GIT users are not less hardcore DVCS users than
> > Mercurial ones and have fast forward merge when they do a git pull. This
> > functionnality is used every day by thousands and thousands of very
> > experienced DVCS users.
> >
> > I think that having nothing  (even as an option) to have a similar
> behaviour
> > than Git fast forward merges is a real issue if we want Mercurual to be
> more
> > widely use I think.
> >
> > hg fetch is a bad way to acheive this, this one is a lot cleaner ...
>
> I don't understand how your email fit in the current topic,
>
> People can already to "pull" and "update" in the same operation with `hg
> pull
> -u` (and hg pull --rebase). The topic was about: provide a way to use
> rebase if
> there are no conflict and explicit merge when there are conflict.
>
> About joining both operations:
>
> Splitting the "pull" and the "update" operations is good practice in my
> opinion. A kiln guy once referred to a distinction between "exchanging"
> changes
> and "inflicting" changes.
>
> I believe git does both operation together by default as they were more
> restricted by they "everything should be a labeled head". Having clean
> definition of remotes head allow git to also have a "fetch" command that
> result
> with several heads with the same name (distinct thanks remotes/heads)
>
> As you can see `hg rebase` as an advanced version of `hg update` with
> uncommitted change. I used "update" for both `hg update` and `hg rebase`.
>
>
> --
> Pierre-Yves David
>
> http://www.logilab.fr
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk37TxkACgkQElczi7p/bN+lAQCgoAqX385Hwboejc+h11S/DFFJ
> cSkAn07TOn16rmesor7tZTrmrgJOoNSs
> =fCbH
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20110617/da97f2b1/attachment.html>