[PATCH 4 of 5 RFC] revset: add a predicate for finding rebased changesets

Matt Mackall mpm at selenic.com
Thu May 17 11:09:23 CDT 2012


On Wed, 2012-05-16 at 17:18 +0000, Matt Harbison wrote:
> Pierre-Yves David <pierre-yves.david <at> logilab.fr> writes:
> 
> > 
> > On Tue, May 15, 2012 at 06:56:40PM +0200, Sune Foldager wrote:
> > > 
> > > > Matt Harbison <matt_harbison <at> yahoo.com> writes:
> > > > 
> > > >> # HG changeset patch
> > > >> # User Matt Harbison <matt_harbison <at> yahoo.com>
> > > >> # Date 1336884852 14400
> > > >> # Node ID 5de639cd52e36c27b4c8bbbaa5fdb44803efee72
> > > >> # Parent  2612b6d41579adce0df8f6b744f2879868125b5b
> > > >> revset: add a predicate for finding rebased changesets
> > > >> 
> > > >> This selects changesets added because of rebases. If a revision is
> > > >> specified, the set will be empty if that revision is not the source of
> > > >> a rebase, or it will contain a destination changeset for each time the
> > > >> specified revision was rebased. This can be useful for figuring out
> > > >> where a particular changeset has been propagated.
> > > 
> > > Rebased changeset originals no longer exist, though, as opposed to grafted
> and locally transplanted
> > ones, so what would you use it for?
> > 
> > Various extras key are used:
> > 
> >     graft:'source',
> >     rebase: 'rebase_source',
> >     transplant: 'rebase_source',
> > 
> > A first step seems to unify all this to the common "source" extra.[1]
> > 
> > Then, a single revset predicate make sense.
> > 
> > (rebase --keep make a copy. It make sense to have the same behavior that graft
> there.)
> > 
> 
> That may be worth doing, but I'm not sure I agree it is a first step- the
> predicate would have to look at the old strings anyway, otherwise it wouldn't
> work for commits prior to whenever that change ships.  But this and the other
> comments gives me an idea:
> 
> {graft|transplant|rebase --keep} without a subsequent strip of the source csets
> are essentially copy based ops.  Plain rebase is a move, as are
> {graft|transplant} with a subsequent strip of the source.  It doesn't seem like
> it matters what particular operation was done, so a predicate for each is
> probably the wrong way to attack it.
> 
> How about a copied([set]), a moved([set]), the origin([set]) that Matt suggested
> above, and a destination([set]) which is the thing I was originally after?  For
> the sake of these examples, let there be a cset 2, and when
> {graft|transplant|rebase} is done to it, a cset 3 is added.

You can't use copied and moved as they're names we may end up using for
file ops.

> destination() would then be the opposite of origin().  e.g. destination(2) ->
> [3].

I think you misread my proposal. "origin(2)" meant "anything that has 2
as its origin" much like "branch(foo)" means "anything that has foo as
its branch". But you're right, we probably do want both operators.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list