[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