git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Alternate object pool mechanism updates.

From
Junio C Hamano <junkio@cox.net>
Date
Aug 16, 2005, 20:38 UTC
Message-ID
<7vacjhaa7y.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<Pine.LNX.4.58.0508161156430.3553@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Btw, looking at the code, it strikes me that using ":" to separate the 
> alternate object directories in the file is rather strange.

Yes, I admit it one was done in a quick and dirty way. Patches welcome [*1*] ;-)

> Anyway, I don't think "alternates" is necessarily sensible as a "object"  
> information. Sure, it's about alternate objects, but the thing is, object 
> directories can be shared across many projects, but "alternates" to me 
> makes more sense as a per-project thing.

Well, I have to think about this a bit more, but I have to say there were some thinking behind the way things are right now.

$GIT_DIR/info describes properties of the repository. That's why refs, graft and rev-cache go there.

$GIT_OBJECT_DIRECTORY/info describes the properties of the object pool (I am inventing words as I speak, but an object pool is a directory that can be combined with other object pools to make an object database). So object/info/packs talks about the packs in it, but not about packs it borrows from its alternates. The alternates file in question talks about what other object pools you need to consult to obtain the objects it refers to but it lacks itself. If two repositories share a particular object pool as its .git/objects directory, by symlinking .git/objects or by using GIT_OBJECT_DIRECTORY environment, it does not matter from which repository you look at this object pool. The set of objects it refers to but lacks itself, and from which other pools these objects can be obtained, do not depend on from which repository you are looking at it. While I agree with everything you said about "maybe logical but confusing", I have to disagree with you about this one.

> What this all is leading up to is that I think we'd be better off with a 
> totally new "git config" file, in ".git/config", and we'd have all the 
> startup configuration there.

I think what _is_ lacking is an easy way to have per repository configuration that can be shared among "opt-in" developers. The graft file naturally falls into this category, and probably the Porcelain standard .git/info/exclude file as well. Although we ended up doing .git/hooks, it is a per repository thing and logically it _could_ be moved to .git/info/hooks [*2*]. And that might also be a nice thing to share among "opt-in" developers.

[Footnote]
*1* Sorry I could not resist --- I always wanted to say this.
*2* I do not think we _should_ move it under .git/info, though.
Previous: Daniel BarkalowNext: Junio C Hamano
Message 9 of 12 in “Alternate object pool mechanism updates.”
  1. Alternate object pool mechanism updates.Junio C Hamano, Aug 13, 2005
  2. Petr BaudisAug 13, 2005
  3. Junio C HamanoAug 13, 2005
  4. Junio C HamanoAug 14, 2005
  5. Linus TorvaldsAug 15, 2005
  6. Junio C HamanoAug 15, 2005
  7. Linus TorvaldsAug 16, 2005
  8. Daniel BarkalowAug 16, 2005
  9. Junio C HamanoAug 16, 2005
  10. Use LF and allow comments in objects/info/alternates file.Junio C Hamano, Aug 17, 2005
  11. Junio C HamanoAug 16, 2005
  12. Linus TorvaldsAug 16, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.