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
