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

[Sune Foldager]

On 2012-05-16 11:10, Martin Geisler wrote:
>Matt Harbison <matt_harbison at yahoo.com> writes:
>
>(Sending this back to the list, please keep it in Cc.)
>
>> Martin Geisler 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.
>>>>
>>>> The source revision may be a local identifier, the short changeset
>>>> hash or the full hash. The revision does not have to exist, since
>>>> rebase may not --keep the source. In this case, the provided revision
>>>> is matched against the beginning of the full hashes that are stored on
>>>> rebased changesets.
>>>
>>> I just talked with Sune, and he gave a very sensible comment: rebased
>>> changesets will normally not exist any longer, so is this revset even
>>> relevant? Rebasing is done routinely when local changesets are brought
>>> up to date with the latest changesets -- it's not very interesting when
>>> it's done.
>>>
>>> This is unlike transplant and graft: it *is* interesting to know where
>>> the duplicate changeset is later. With transplant/graft you might very
>>> well be interested in seeing if a given changeset is already promoted to
>>> a stable branch.
>>>
>>> I see you are aware of all this since you mention --keep, but I think
>>> the revset is close to unneeded.
>>
>> I tend to agree.  OTOH, it looks like rebase will put a *.hg bundle in
>> strip-backup by default.  I know I never clean these out, mostly
>> because it isn't particularly convenient to see where the contained
>> changesets ended up

But this is a local directory, and other people won't have it, so it still a very local piece of information which I don't really see is interesting to keep for posterity. For many, rebase is part of a regular workflow with the only special case being that you lose the push-race on a particular upstream.

Anyway, we'll see what other people think once it's more concrete :)

-Sune