Re: .git/info/refs

From: Junio C Hamano <junkio@cox.net>
Date: Jan 26, 2007, 11:41 UTC
Message-ID: <7vireuxbel.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <45B8E551.9020808@zytor.com>

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

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

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