From: "H. Peter Anvin" <hpa@zytor•com>
To: Johannes Schindelin <Johannes.Schindelin@gmx•de>
Cc: Jakub Narebski <jnareb@gmail•com>, git@vger•kernel.org
Subject: Re: .git/info/refs
Date: Wed, 24 Jan 2007 09:06:16 -0800 [thread overview]
Message-ID: <45B79208.2080502@zytor.com> (raw)
In-Reply-To: <Pine.LNX.4.63.0701241746390.22628@wbgn013.biozentrum.uni-wuerzburg.de>
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
next prev parent reply other threads:[~2007-01-24 17:06 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-24 7:38 .git/info/refs H. Peter Anvin
2007-01-24 9:28 ` .git/info/refs Jakub Narebski
2007-01-24 15:55 ` .git/info/refs H. Peter Anvin
2007-01-24 16:02 ` .git/info/refs Johannes Schindelin
2007-01-24 16:24 ` .git/info/refs H. Peter Anvin
2007-01-24 16:38 ` .git/info/refs Johannes Schindelin
2007-01-24 16:41 ` .git/info/refs H. Peter Anvin
2007-01-24 16:52 ` .git/info/refs Johannes Schindelin
2007-01-24 17:06 ` H. Peter Anvin [this message]
2007-01-24 17:25 ` .git/info/refs Jakub Narebski
2007-01-24 17:10 ` .git/info/refs Jakub Narebski
2007-01-24 17:20 ` .git/info/refs Johannes Schindelin
2007-01-25 17:13 ` .git/info/refs H. Peter Anvin
2007-01-26 11:22 ` .git/info/refs Jakub Narebski
2007-01-26 11:41 ` .git/info/refs Junio C Hamano
2007-01-26 16:39 ` .git/info/refs H. Peter Anvin
2007-01-26 17:06 ` .git/info/refs Jakub Narebski
2007-01-26 21:09 ` .git/info/refs Johannes Schindelin
2007-01-26 21:32 ` .git/info/refs H. Peter Anvin
2007-01-26 21:54 ` .git/info/refs H. Peter Anvin
2007-01-24 20:40 ` .git/info/refs Jakub Narebski
2007-01-24 20:44 ` .git/info/refs hpa
2007-01-25 8:14 ` .git/info/refs Johannes Schindelin
2007-01-25 16:12 ` .git/info/refs H. Peter Anvin
2007-01-25 16:50 ` .git/info/refs Johannes Schindelin
2007-01-24 20:45 ` .git/info/refs hpa
2007-01-25 21:28 ` .git/info/refs Junio C Hamano
2007-01-25 21:37 ` .git/info/refs H. Peter Anvin
2007-01-25 21:51 ` .git/info/refs Junio C Hamano
2007-01-25 22:01 ` .git/info/refs H. Peter Anvin
2007-01-25 23:33 ` .git/info/refs Johannes Schindelin
2007-01-27 22:07 ` .git/info/refs H. Peter Anvin
2007-01-31 15:38 ` .git/info/refs Santi Béjar
2007-02-01 14:03 ` .git/info/refs Johannes Schindelin
2007-02-01 16:16 ` .git/info/refs H. Peter Anvin
2007-02-01 16:52 ` .git/info/refs Johannes Schindelin
2007-02-01 16:56 ` .git/info/refs H. Peter Anvin
2007-02-01 17:32 ` .git/info/refs Matthias Lederhofer
2007-02-01 17:51 ` .git/info/refs H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45B79208.2080502@zytor.com \
--to=hpa@zytor$(echo .)com \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=jnareb@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox