Re: .git/info/refs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, 24 Jan 2007, Jakub Narebski wrote:

> 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
> 
> I don't think it can be easily expanded. .git/info/refs is meant for
> http-fetch, and it mimics git-ls-remote / git-peek-remote output.

Exactly.

> BTW. putting the info of git-for-each-ref into .git/info/refs-details
> would mean that instead of "24175 calls to git" one would need to
> read 24175 files. Perhaps the whole info needed to generate projects
> index page should be pre-generated on push (update), instead of per
> project (per repository) .git/info/refs-details

You completely lost me there. A push (update) is done as a specific user, 
who should not be able to write to a _global_ file!

Nevertheless, "24175 calls to git" is sure as hell more expensive than 
"reading 24175 files".

Plus, if we integrate the functionality to write .git/info/refs-details 
into update-server-info, you can reduce that further: it is no longer 
per-branch, but per-repo.

Ciao,
Dscho

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]