Revision resolution for remote-helpers?

Hi,

As you might remember, I'm maintaining a remote helper that allows to talk directly to mercurial servers with git: git-cinnabar.

When dealing with "foreign (non-git) repositories", it is often necessary to refer to revisions with their native name. With mercurial, that's a sha1, with svn it's a revision number, etc.

Git-cinnabar does provide a helper command that gives back the git commit from the mercurial revision (and vice versa), but that's cumbersome to use in commands.

I was thinking it could be useful to have a special syntax for revisions that would query a helper program. The helper program could use a similar protocol to that of the remote helpers.

My thought is that a string like <helper>::<revision> could be used wherever a committish is expected. That would call some helper and request to resolve revision, and the helper would provide a git commit as a response.

The reason for the <helper>:: prefix is that it matches the <helper>:: prefix used for remote helpers.

Now, there are a few caveats:
- <revision>, for e.g. svn, pretty much would depend on the remote.
  OTOH, in mercurial, it doesn't. I think it would be fair for the
  helper to have to deal with making what appears after :: relevant
  to find the right revision, by possibly including a remote name.
- msys likes to completely fuck up command lines when they contain ::.
  For remote helpers, the alternative that works is
  <helper>://<host>/etc.

Which leads me to think some "virtual" ref namespace could be a solution to the problem. So instead of <helper>::, the prefix would be <helper>/. For e.g. svn, svn/$remote/$rev would be a natural way to specify the revision for a given remote. For mercurial, hg/$sha1.

Potentially, this could be a sort of pluggable ref stores, which could be used for extensions such as the currently discussed reftable.

On the opposite end of the problem, I'm also thinking about git log --decorate=<helper> displaying the mercurial revisions where branch decorations would normally go.

I have no patch to show for it. Those are ideas that I first want to discuss before implementing anything.

Thoughts?

Mike