"H. Peter Anvin" <hpa@zytor.com> writes:

quoted text
> For heaven's sake, in computer science we can *NEVER* use the same
> feature for *MORE THAN ONE THING*.  If it doesn't work format-wise
> that's fine, but "it's only supposed to be used by dumb transports" is
> ridiculous.

Hmmmm... I am lost here....

quoted text
> Right
> now, git-update-server-index is the command to update cached
> information, and for usability reasons there should be a single entry
> point.

Modulo s/-index/-info/, I agree that would be a very sensible
position, as long as the cost to generate additional cached
information necessary to help gitweb is reasonably small, I am
not opposed to have it generate another file [*1*].


[*1*]

I've been looking for backward-compatible holes in ls-remote and
its users, hoping we somehow could shoehorn this information in
info/refs, as I do not think its file format is sacred, nor the
file is there _only_ to help dumb transports.  As long as the
published way to access that information stays consistent, the
underlying file format is a fair game.  However, I do not think
the ls-remote command implementations in the wild has such a
hole I can exploit.



-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html