[PATCH 2 of 2] rebase: preserve working directory parent (BC)

[Augie Fackler]

On Wed, Oct 16, 2013 at 02:03:02AM +0200, Angel Ezquerra wrote:
> El 15/10/2013 21:54, "Matt Mackall" <mpm at selenic.com> escribió:
> >
> > On Tue, 2013-10-15 at 21:32 +0200, Angel Ezquerra wrote:
> > > El 14/10/2013 17:00, <pierre-yves.david at ens-lyon.org> escribió:
> > > >
> > > > # HG changeset patch
> > > > # User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
> > > > # Date 1381759949 -7200
> > > > #      Mon Oct 14 16:12:29 2013 +0200
> > > > # Node ID b94e088ccbedbdcf407658f2e41305027ba58464
> > > > # Parent  b24448b7d0e6e0b0d871871ddb40b68f95eee7c7
> > > > rebase: preserve working directory parent (BC)
> > > >
> > > > Prior to this changeset, rebase always left the working directory as a
> > > parent of
> > > > the last rebased changeset. The is dubious when, before the rebase,
> the
> > > working
> > > > directory was not a parent of the tip most rebased changeset.
> > > >
> > > > With this changeset, we move the working directory back to its
> original
> > > parent.
> > > > If the original parent was rebased, we use it's successors.
> > >
> > > I'm not necessarily against this change, but isn't this a backwards
> > > incompatible change?
> >
> > That's why it's marked "(BC)". It has nothing to do with any rumored
> > secret base in British Columbia.
>
> LOL! I had not noticed it but I don't think I would have understood what BC
> meant even if I had.
>
> > I'm on the fence on this one, but I'm leaning towards accepting it. In
> > the distant future, we may end up doing many rebases entirely in memory,
> > so this side-effect of the current implementation would also disappear.
> > If someone has a scenario or workflow where it matters, let's hear about
> > it.
>
> Actually now that I think about this a bit more, I think it does make a lot
> of sense.

I'm in favor of the change, for what it's worth. Having used evolve
for a while now, I actually find myself occasionally surprised when
rebase /doesn't/ work this way.

>
> When I teach other people about mercurial I always tell them that most
> mercurial commands modify either the working copy out the repository
> history, but not both. This helps explain the difference between update and
> revert and that merge does not create a new revision, for example.
>
> Rebase is (was?) one of the few exceptions to this rule. It'd be nice if
> this particular exception was gone.
>
> Cheers,
>
> Angel

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel