On Thu, May 2, 2013 at 3:27 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy  <pclo...@gmail.com> 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..
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to