On Thu, May 2, 2013 at 3:27 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> index-pack --strict looks up and follows parent commits. If shallow >> information is not ready by the time index-pack is run, index-pack may >> be lead to non-existent objects. Make fetch-pack save shallow file to >> disk before invoking index-pack. >> >> A new environment variable GIT_SHALLOW_FILE is used to inform >> index-pack to use an alternate shallow file. This variable is for >> internal use and thus not advertised in git.txt. > > The idea to tell the index-pack to use a different shallow file is > sound, but is the environment variable the best way to go? I am > mostly worried about it being an implicit "apply everywhere" > mechanism and while I do not particularly like the idea of doing > everything in the same process as the top-level while dealing with > submodules, I am reasonably sure people would want to "clone" > recursively inside the same top-level process in the future, and > this new environment variable adds one more thing to be cleansed > when crossing a repository boundary. First of all, fetch does check that GIT_SHALLOW_FILE must not be set before it updates shallow file, so if fetch is run recursively, the inner one will get caught. And GIT_SHALLOW_FILE is only set for a period of time when pack is received. Unless somebody launches fetch inside index-pack, we should be safe. That said, passing this info via a --shallow-file is not hard to do (so I will likely do it). But I wonder how submodule code handles the case where the user set GIT_OBJECT_DIRECTORY or similar variables. GIT_WORK_TREE for example could be set internally by git and propagated down to submodule subprocesses.. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html