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.)
Details
- Reviewers
durin42 indygreg - Group Reviewers
hg-reviewers - Commits
- rHGc4131138eadb: histedit: look up partial nodeid as partial nodeid
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
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.
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. |
hgext/histedit.py | ||
---|---|---|
446–448 |
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. |
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, Maybe we'll need a scmutil function to document that. We shouldn't |
hgext/histedit.py | ||
---|---|---|
446–448 | BTW, it's probably wrong to rely only on _partialmatch() of unfiltered repo. |
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.