Johannes Schindelin wrote:
Hi,
On Wed, 24 Jan 2007, H. Peter Anvin wrote:
Johannes Schindelin wrote:
Granted, for some things this might work. However, I would not wreak
havoc by changing the format of .git/info/refs, rather put the details
you wanted into .git/info/refs-details.
It's not clear to me if it would be wrecking havoc. After all, if a
format can't be expanded *at all*, there is something wrong, and adding
things to the end of a line is a common structured way of expansion.
Hence the original query
The idea of .git/info/refs is to enable dumb transports to fetch something
akin to intelligently. They don't need that information, and frankly, I
don't think they should need to understand it.
I don't think adding 10 digits to each line is going to be a sizable
impact on anything.
I also expect that they interpret everything after the sha1 as refname,
what with our having become quite liberal with refnames (they can contain
spaces, tabs, and even a small amount of special K). So I don't see a way
to upgrade the file format.
They can also contain newlines, probably, so escaping is obligatory anyway.
But as should be clear by now, I'd prefer additional information -- that
is of no interest to dumb transports anyway -- to be put in an own file.
Yes, but the argument seems to be philosophical.
That also opens the possibility of, say .git/info/perl/, which contains
_only_ serialized perl objects! I imagine this could be a performance
booster.
For certain things, I'm sure.
However, for other things (like showing a certain number of commits),
it _might_ make sense to cache them (e.g. when literally thousands of
people look at the 100 last commits of linux-2.6.git), but not for
others (e.g. the 100th last to the 200th last commit of
git-tools.git).
Any query that's within a repository is fairly easily cachable
post-generation. The front page (and its RSS variant) is a bit of an
exception, because it involves all repositories at once.
... and here we have a problem, right? No single update hook can update
the _whole_ information.
I don't see a problem.
-hpa
-
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