> $ hg status > abort: 00changelog.i@17fd16e2f47b: no node! Traceback attached. <mpm> jorendorff: Ok, so you've got a tag that points at non-existent revision. <marmoute_> +1 on localtag pointing on a missingf stuff <mpm> File an urgent bug against evolve, add "pierre-yves" to it. <jorendorff> mpm: wait, that implicates a custom extension i'm using, not evolve <jorendorff> this stupid mozillatree thing. sorry to bug you, i couldn't have figured it out without your help <mpm> No, it's pretty clearly evolve-related. <jorendorff> oh ok <jorendorff> well, i'll file against evolve then <mpm> I mean, you might have something adding the tags in question, but it's really important that anything touching tags needs to accept non-existent tags. * mpm ponders ways to make code that doesn't like bogus tags always break. <mpm> jorendorff: marmoute_: Probably fixed by something like this: https://pastebin.mozilla.org/5931092 > --- a/mercurial/repoview.py Mon Aug 11 11:24:05 2014 -0500 > +++ b/mercurial/repoview.py Mon Aug 11 13:56:54 2014 -0500 > @@ -41,7 +41,7 @@ > tags = {} > tagsmod.readlocaltags(repo.ui, repo, tags, {}) > if tags: > - blockers.extend(cl.rev(t[0]) for t in tags.values()) > + blockers.extend(cl.rev(t[0]) for t in tags.values() if t[0] in cl) > return blockers > > def computehidden(repo):
Jason is using one of my extensions (firefoxtree) that has added a custom post-pull step that transfers a subset of localtags to the client. See https://hg.mozilla.org/hgcustom/version-control-tools/file/79aa2bb4aed5/hgext/firefoxtree/__init__.py#l225 This bug manifests as a race condition between pulling these extra tags and someone else pushing to the repository: you can pull down a tag that references a node that was just pushed but was not pulled by your client just now. This will be fixed in bundle2. Also, as the linked to code demonstrates, either I'm completely misunderstanding one of the use cases of local tags (essentially remote refs) or the (local)tags API needs some work around preventing redundant entries.
If someone can tell me whether the suggested patch is the right thing, we can go ahead and patch this.
Sugguested patch look good. But I would do test membership directly on cl.nodemap to shave a few nanoseconds.
Fixed by http://selenic.com/repo/hg/rev/e5dfa8689cf0 Matt Mackall <mpm@selenic.com> repoview: filter tags to non-existent nodes from blockers (issue4328) (please test the fix)