Re: Revision resolution for remote-helpers?

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Aug 18, 2017, 22:06 UTC
Message-ID: <20170818220637.GN13924@aiede.mtv.corp.google.com>
In-Reply-To: <20170818064208.plkppke7efpucuwm@glandium.org>

Hi,

Mike Hommey wrote:

> 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.

I like this idea.

Show 11 quoted lines

> 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.

Hm --- is there a bug already open about this (e.g. in the Git for Windows project or in msys) where I can read more?

> 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.

I see. My naive assumption would be that a string like r12345 would be the most natural way for a user to want to specify a Subversion revision, but you're right that those only have meaning scoped to a particular server. That makes the svn/ prefix more tolerable.

Show 9 quoted lines

> 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.

One additional thought: unlike refs, these are not necessarily enumerable (and I wouldn't expect "git show-ref" to show them) and they do not affect "git prune"'s reachability computation.

So internally I don't think refs is the right concept to map these to. I think the right layer is revision syntax handling (revision.c).

Thanks, Jonathan