This might or might not be helpful, but the rough model here is that "hardpoints" are an open slot that some particular data may be loaded into. The physical analogy is a "hardpoint" on fighter aircraft where a particular missile or bomb may be attached.

A similar concept is common in Phabricator today, where data is "attachable". For example, a Commit has methods like attachRepository() and getRepository() (which throws if a Repository is not attached), and some Query classes have methods like needSuchAndSuch(true), meaning the query should also load and attach some "SuchAndSuch" related object as it queries the database. Hardpoints are partly a more generalized formalization of "attachment" points.

In this case, the object is a CommitSymbolRef, which represents a symbol in the sense of "string of characters we got from somewhere", like "HEAD^" or "1234" or "ab3fern4" or ".", and has a "hardpoint" for a CommitRef.

The CommitRef has some actual details about the commit, e.g., its full identity hash in the underlying VCS. So, fully attached, the object tree might look like this:

- `CommitSymbolRef` (The symbol "HEAD".)
  - `CommitRef` (An object with a property like `fullVCSHash = abcd1234`).

So you build a list of CommitSymbolRef objects ("HEAD", "master") and hand the list to HardpointEngine, telling it to load in the data on the "COMMIT" hardpoint. This is just 35 layers of abstraction on top of this:

foreach ($symbols as $symbol) {
  $hash = `hg log --rev $symbol`;
}

The justification for the 35 layers of abstraction is:

• HardpointEngine has a significant ability to do what might generally be called "query planning" and may be able to get you the information many times faster than the bare loop by building a graph of Futures and using yield, caching, and executing all possible parallel operations in parallel; and
• HardpointEngine can load hardpoints in a completely modular way, so extensions can replace or supplement query behavior very flexibly.
• Hardpoints have 175 extra layers of abstraction and are themselves introspect-able, mutable, extensible, etc.

Today, this is a lot of complexity for little real effect. In theory, it can solve some hard problems elsewhere in Arcanist and eventually generalize to Phabricator, although it's a bit difficult to imagine that ever actually happening.

Not yet handling the case where an invalid symbol results in failing to lookup any symbols

I didn't see any obvious way of doing this through revsets but I'll try some more experiments. An extension that adds a template keyword, or just a new command for this, might also be an option

Hmm could maybe do something like hg log --rev 'bookmark() or tag() or .' to just get every commit that has a potential symbol and then process those. It would end up getting more results than necessary in every case. The query runs relatively quickly (~230ms) on our ~128k commit repository but it only has ~550 tags which I'm guessing is low -- if we tagged every build we'd have ~15k.

Ooh actually it looks like this will work

$ hg log --revset "bookmark('re:^symbol$') or tag('re:^symbol$')"

Doing that doesn't fail if the symbol doesn't exist

The "symbol" here could, in the absolute-most-general case, be a short commit hash (abcd1234) or symbolic commit (tip^^^) -- not just a bookmark or tag name -- so I think this trick (though quite clever) may run into trouble some day.

Oh yea... hmm I think it's possible to include support for commit hashes (or prefixes) as well as revision ID -- I'll try out a change real quick to see if it's simple to include support for those symbols at least. Any relativity modifiers ^^ I think are effectively impossible to handle without resorting to individual hg log commands or an extension

I played around with this some more and this feels pretty solid for resolving most common symbols. I'll poke around some of the mercurial source a bit later this week and see if I can find an easy way for resolving revset/symbols easily though a custom extension.