Matt Draisey <[EMAIL PROTECTED]> 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. - 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
