Linus Torvalds <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
