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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html