Re: Supporting a few more usecases with remote helpers

> Hi,
> 
> As you may or may not know, I'm working on a remote-helper to interact
> with mercurial servers, with the main focus being to make it work with
> developer workflows at Mozilla.
> 
> I think remote-helpers, in the context of non-git remotes, can be
> leveraged to improve git user experience with non-git remotes.
> 
> - While git doesn't support this[1], mercurial allows to pull a specific
>   commit. That's quite commonly used at Mozilla. It makes it desirable
>   to be able to `git fetch origin sha1`, where sha1 could actually be
>   considered as fake head name. But that currently can't work because
>   only refs returned by the `list` command of the remote-helper are
>   considered, and we can't realistically list all the remote changesets
>   there.
> - A lot of places (bug logs, CI, etc.) will list mercurial changesets
>   or, more commonly, their abbreviated form. It is quite common to look
>   at those locally. When using a git clone of a mercurial repository,
>   it adds a level of indirection where the user first needs a command to
>   resolve that mercurial changeset to the corresponding git commit, then
>   run whatever command they wanted to run with that git commit. This
>   could be worked around by adding e.g. tags for both abbreviated and
>   long form of the changesets, but we'd be looking at more than 400k
>   refs for a typical Mozilla repository. That doesn't quite scale.
> - On the opposite side of the above, it can be necessary to find out
>   what mercurial changeset a git commit corresponds to, and while, like
>   the above, there can be a command to resolve those, that's a level
>   of indirection that is not very nice for users.
> 
> Here's my thoughts on how I think this could be done, but before I dive
> in the code to actually implement it, I'd like to get feedback whether
> it makes sense.
> 
> - I think the first and second use cases could both use the same 
>   "feature". We could add a new `list` option to the remote-helpers
>   that would make it list a limited set of refs, and giving it the
>   opportunity to reply with heads it wouldn't give normally. For
>   example, this would look like this:
>     git fetch origin 7b33ee7fd162d784f382250d3fa811e86a1b7348

>       > list ref refs/heads/7b33ee7fd162d784f382250d3fa811e86a1b7348
>       ? refs/heads/7b33ee7fd162d784f382250d3fa811e86a1b7348
>     git show ba0dc109a8f8
>       > list ref refs/heads/ba0dc109a8f8
>       1d1c70ecefa26e5fa859366ac989497843a3f8ff refs/heads/ba0dc109a8f8
> - For the latter, I was thinking the decorate code (for git log
>   --decorate) could request ref names to the remote-helper, like this:
>       > ref short 1d1c70ecefa26e5fa859366ac989497843a3f8ff
>       1d1c70ecefa26e5fa859366ac989497843a3f8ff ba0dc109a8f8
>       > ref full 1d1c70ecefa26e5fa859366ac989497843a3f8ff
>       1d1c70ecefa26e5fa859366ac989497843a3f8ff ba0dc109a8f86ca831866a5933cf863d379434cd
>   Then the decorate code would display helper-prefix::ba0dc109a8f8 or
>   helper-prefix::ba0dc109a8f86ca831866a5933cf863d379434cd depending on
>   the --decorate value.
> 
> Calling remote-helpers for the above would be triggered by the presence
> of one or more remotes with helper:: prefixed urls.
> 
> Thoughts?
> 
> Mike
> 
> 1. I think it should, as long as the given sha1 is reachable from the
> public heads, but that's offtopic here.