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

[Martin Geisler]

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 (or if they ended up anywhere- it may have been
> junk I stripped).  Maybe something like
>
> 	hg -R .hg/strip-backup/xxx.hg log -r "not rebased(incoming())"
>
> would tell you if there's anything left in the bundle that isnt in the
> repo (maybe you rebased and then stripped some or all of the dest
> csets later).  Of course, incoming() doesn't exist and I don't know
> enough about overlays to know if it even *could* in that case.  ('hg
> -R <.hg> log' shows local ids for the incoming csets, so there may be
> some way.)

But you can run 'hg incoming .hg/strip-backup/xxx.hg' directly and then
the revset begins to make sense.

I don't feel too strongly about it myself, but now the issue has at
least been mentioned and maybe someone else feels strongly for or
against it now.

> This is probably a pretty obscure use case, and I'm not sure I could
> even contrive another usage.  I reworked transplant to take a revset
> last night, and I suspect graft will take almost exactly the same
> form. So if the other stuff goes well and supporting a revset for
> rebase isn't much different, I might take a swipe at it and throw it
> out for comments.  I'm still learning, so even if it isn't accepted,
> it won't be a complete waste for me.

That's good to hear -- even though we are rather picky about accepting
patches, we don't like contributors to waste their time :)

-- 
Martin Geisler

aragost Trifork
Commercial Mercurial support
http://aragost.com/mercurial/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120516/204447b7/attachment.pgp>