Matt Draisey <[EMAIL PROTECTED]> writes:
> On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:
>> I would like to know
>> a use case or two to illustrate why there are symlinks pointing
>> at real files outside .git/refs/ hierarchy, and how that
>> arrangement is useful.
>...
> This email is a bit long-winded so I didn't CC it to the mailing list.
Thanks for a clear explanation. Your arrangement indeed is an
intriguing one, in that there are very similar issues in the
fsck/prune area even with arrangements quite different from
yours. I personally think your reasoning about this issue
deserves to be shared with the list. I'll CC _this_ message to
the list and leave it up to you to forward your words there as
well.
People are known to do something similar to what you are doing
without having any special commit tool. They just do this:
$ mkdir A B
$ cd A && git init-db
$ cd ../B && git init-db
$ rm -fr .git/objects && ln -s ../../A/.git/objects .git/objects
The repositories A and B share the same object database,
and they have independent sets of refs. For the exact same
reason as your arrangement, you cannot "git prune" in either
repository, because they do not know about objects reachable
only from the other side.
Further, one repository can borrow objects from another
repository via the .git/objects/info/alternates mechanism. This
is useful when a repository is a local clone of another. You
would do this:
$ git clone -l -s linux-2.6/.git/ my-linux
$ cd my-linux && cat .git/objects/info/alternates
/path/to/linux-2.6/.git/
The new repository my-linux has the .git/objects with 256
fan-out subdirectories, but starts out without any object files
in it. It literally borrows the existing objects from the
neighbouring repository, and its own .git/objects hierarchy is
only used to hold newly created objects in it. For the same
reason as your arrangement, you should not "git prune" the
linux-2.6 repository, either. However, my-linux repository can
be pruned as long as somebody else does not "borrow" from it.
So while I find your "do follow symlink" patch an improvement in
that it makes things a little bit safer, I think there should be
a more generalized way to say "this object database holds things
that are refered by these refs/ directories outside. fsck/prune
had better hold onto objects referenced by them, not just by the
refs directory that happens to be next to th objects directory".
That would be the inverse of .git/objects/info/alternates.
-jc
-
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
