This is an archive of the discontinued Mercurial Phabricator instance.

histedit: look up partial nodeid as partial nodeid
ClosedPublic

Authored by martinvonz on Apr 6 2018, 12:54 PM.

Details

Summary

I'm about to remove support for repo[<partial hex nodeid>]. In the
verify() method, we know that self.node is always a partial or full
binary nodeid, so the most correct way to look up the revision is by
using changelog._partialmatch(), so let's do that. (It's closer to the
current code to do scmutil.revsymbol(), but that's less correct
because it will match a bookmark or tag that happens to have the same
prefix as the node.)

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

martinvonz created this revision.Apr 6 2018, 12:54 PM
indygreg accepted this revision.Apr 6 2018, 2:57 PM
indygreg added a subscriber: indygreg.

This is a layering violation. But I don't care because we don't yet have an interface for changelog. Once we do, we'll likely promote _partialmatch to a public method.

This revision is now accepted and ready to land.Apr 6 2018, 2:57 PM
indygreg requested changes to this revision.Apr 6 2018, 3:01 PM
indygreg added inline comments.
hgext/histedit.py
446–448

Err wait. Why is repo.unfiltered() being used here? If the previous code worked on on the filtered repo, shouldn't this code?

The side effect of this change is that a histedit rule could reference a hidden changeset. That feels wrong.

This revision now requires changes to proceed.Apr 6 2018, 3:01 PM
martinvonz added inline comments.Apr 6 2018, 3:13 PM
hgext/histedit.py
446–448

If the previous code worked on on the filtered repo, shouldn't this code?

The previous code just *looked like* it worked on the filtered repo :) This is copied from changectx.init(), which is where this would end up getting resolved before.

I don't remember what the reason is for *that* code to use the unfiltered repo (I think it had something to do with making {shortest(node)} length match what's actually unambiguous. Either way, this patch should not be changing any behavior, I think.

yuja added a subscriber: yuja.Apr 7 2018, 3:36 AM
yuja added inline comments.
hgext/histedit.py
446–448

Nah. It's for performance reason on ambiguous case, radix tree lookup vs linear search. I've sent a patch to fix the inconsistency,
but it was rejected because of that.

Maybe we'll need a scmutil function to document that. We shouldn't
spill around the weird implementation detail.

yuja added inline comments.Apr 7 2018, 3:45 AM
hgext/histedit.py
446–448

BTW, it's probably wrong to rely only on _partialmatch() of unfiltered repo.
In changectx.init, we verify the result with repo.changelog.rev().

+1 to having a new function to handle cases for things like partial match.

+1 to having a new function to handle cases for things like partial match.

I agree, that seems much better.

martinvonz updated this revision to Diff 7879.Apr 8 2018, 12:03 PM
This revision was automatically updated to reflect the committed changes.