Hi,
I am new to git source and internal development. Recently I've been
looking at a problem where issuing "git status" in a corrupted
workspace handed over to me by a user, forks several thousand child
processes recursively.
The symptoms of the corrupted workspace to reproduce this problem are
as follows:
there needs to be an entry in the index file that looks something like this....
0 groc 160000 0 0.000000000
Also, there's a subdirectory under the source dir with the name in the
index file above (i.e 'groc') that has a partially populated .git sub
directory within it, not a .git file with the contents providing a
link to the module subdirectory.
The "git submodule status" command returns "No submodule mapping found
in .gitmodules for path 'groc'"
Doing a "git read-tree HEAD" will regenerate the index file and make
the problem go away. Basically the line entry above relating to 'groc'
goes away as it is not a submodule in the source repo.
This problem can be reproduced with all current versions of GIT
including 2.4, 2.8 and the latest version v2.10.0-rc1.
In looking into the git source code for is_submodule_modified() which
forks off the new child process, I see the following lines in
submodule.c:
git_dir = read_gitfile(buf.buf);
if (!git_dir)
git_dir = buf.buf;
Can anyone explain to me why we are replacing a failed reading of a
git file with the original sub directory name? When can we expect a
.git directory under a submodule?
Thanks,
Uma
--
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
