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

[Sune Foldager]

I guess this mail made it anyway, I tried sending it from my phone the other day and it seemed not to work. Anyway...

On 2012-05-16 13:50, Pierre-Yves David wrote:
>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',

Except maybe for --keep, I still don't see why we would want to track rebase sources. It's more confusing (since the cset doesn't exist) than good.

>A first step seems to unify all this to the common "source" extra.[1]
>
>Then, a single revset predicate make sense.

Sure. We shouldn't store it for rebase, though, I think.

>(rebase --keep make a copy. It make sense to have the same behavior that graft there.)

What is actually the difference between rebase --keep and graft, then?

-Sune