Matt Draisey [off-list ref] writes:
Having thus been forced to read the mailing list, I see a slight problem
in .git/objects/info/alternates mechanism. Using the original
ALTERNATE_DB_ENVIRONMENT variable you assert to the git programmes that
you know all the repositories to search for objects. In
the .git/objects/info/alternates mechanism you implicitly defer to other
repositories, which might also implicitly defer to yet another
repository. To ensure an object is truly available you need to compute
a transitive closure on all .git/objects/info/alternates --- you can't
really rely on .git/objects/info/alternates being transitively closed
already.
No, "git clone -l -s" not copying the objects/info/alternates of
the repository being cloned was simply a bug; by doing so the
transitive closure can be set up "initially".
Both the environment variable and objects/info/alternates share
the same problem if the cloned/borrowed from repository suddenly
starts to borrow from another repository, losing objects it used
to have from itself. You just shouldn't do it.
With objects/info/alternates, you _could_ do the transitive
closure at runtime and do not have to worry about this issue
(but you now need to worry about cycles), which you cannot do
with the environment variable approach.
Thanks for committing my one-character patch. In the commit message you
said
Come to think of
it, maybe we should disallow symlink inside .git/refs hierarchy;
we update the files there by creat/rename pair, so having
symlinks would not work anyway when you do anything that would
update them.]
I agree, linking at the file level makes no sense --- create/rename
pairs will clobber symlinked files (as they would for hardlinked files).
If you accept their use at all, symlinked directories are the only way
to go.
The alternatives to symlinked directories are:
(1) adding a command line option to fsck that supplies a path to an
external refs directory
(1a) adding a subtool to create a commandline list of sha from a
supplied path to an external refs directory
(2) adding an environment variable to do the same
(3) adding a .git configuration file which contains a path --- this is
just a userspace symlink
(4) create a monster (refcounting objects?) (true cross-references?)
(conservative garbage collectors that scan your entire hard disk for
potential references)
(I believe the same arguments hold for the pulling code as for fsck)
Case (1) is easy to implement. (I whipped up a working patch yesterday)
The hardest part is thinking up a good name for the command line
argument. Case (1a) is too ugly. Both of these cases place a
considerable burden on the user, and require some Porcelain work. Case
(2) makes sense but is too intrusive for me to contemplate. I defer to
a core developer. Case (3) offers no advantages over a symlinked
directory under refs. Case (4) is probably patented by Microsoft.
I like symlinks for their simplicity, and that they work now. Otherwise
I am a really only submitting a feature request.
Matt