Re: .git/info/refs

"H. Peter Anvin" [off-list ref] 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.

Junio C Hamano wrote:

"H. Peter Anvin" [off-list ref] writes:

quoted

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

Jakub and Johannes seems to have been arguing that "info/refs is for 
dumb transports, therefore it cannot be used for any other purpose."  I 
find this argument utterly bizarre, since in general, in computer 
science, you try to be multipurpose whenever practical.

	-hpa

H. Peter Anvin wrote:

Junio C Hamano wrote:

quoted

"H. Peter Anvin" [off-list ref] writes:

quoted

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.

Please, for the future, mark irony if it might be mistaken...
 

quoted

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

Jakub and Johannes seems to have been arguing that "info/refs is for 
dumb transports, therefore it cannot be used for any other purpose."  I 
find this argument utterly bizarre, since in general, in computer 
science, you try to be multipurpose whenever practical.

First, changing info/refs format _might_ break fetch related scripts,
which rely on git-peek-remote / git-ls-remote / info/refs format.

Second, it is a bit impractical because info/refs contain (and must
contain) also _tags_ information (which is not needed for gitweb
"Last Change" field in projects list) and referenced object for
those tags. Tags need not to point to commits, nor dereference
to commits: for example in git.git tags v1.0rc1 to v1.0rc6 points
to other tags, and junio-gpg-pub point to out-of-tree blob (which
does not have any "commit time" associated). So what to write there
in the "commit time" field? What to write in "commit time" for tags?
-- 
Jakub Narebski
Poland

Hi,

On Fri, 26 Jan 2007, H. Peter Anvin wrote:

Junio C Hamano wrote:

quoted

"H. Peter Anvin" [off-list ref] writes:

quoted

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

Jakub and Johannes seems to have been arguing that "info/refs is for dumb
transports, therefore it cannot be used for any other purpose."  I find this
argument utterly bizarre, since in general, in computer science, you try to be
multipurpose whenever practical.

You keep on harping on that issue. I really get tired of it.

You seem to propose that we should stuff things into .git/info/refs, just 
because it is already there.

You seem to suggest that computer science is all about breaking things, to 
muddle waters by mixing things which are clearly different kinds of 
kettle, to "just" add a small thing here and there, all under the guise of 
multi-purposity or whatever.

You seem to reason that practicality is more important than good style.

You know, this reasoning brought to us that big crap sh*tpile called 
Windows. They also thought: it's not a big deal, let's introduce just a 
little thing here and there, and a direct call from this component to that 
component cannot hurt, cannit?

I am really, really getting tired of that kind of reasoning.

If you don't see how UNELEGANT it is to force dumb transports to download 
things MEANT FOR GITWEB, and how much NICER it would be to have a file 
WHICH IS ONLY MEANT FOR GITWEB TO BEGIN WITH, and which is easily 
EXTENSIBLE, since we don't have to CARE about DUMB TRANSPORTS, because 
gitweb data is a PURELY LOCAL thing, while dumb transports are NOT, I will 
just start to ignore you.

Ciao,
Dscho

Johannes Schindelin wrote:
[... stuff ...]

I really could care less, as long as a single invocation is used to 
update the cache information.

I disagree with your aesthetic argument, but it doesn't matter much to 
me either way.

	-hpa

By the way, let me be the first to apologize for the emotional 
escalation.  What matters to me is that the information is cached and 
updated by a common cached information entry point (the existing 
git-update-server-index would be preferred, obviously), not where the 
information ends up.

	-hpa