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"
*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