These two patches introduce a test case which triggers a regression
introduced by a62387b3fc9f5aeeb04a2db278121d33a9caafa7 and a revert of
the commit introducing the issue.


The test case reproduces following scenario:

Repository setup:
superproject/middle_repo/inner_repo

Person A and B have both a clone of it, while Person B is not working
with the inner_repo and thus does not have it initialized in his working
copy.

Now person A does a change to the inner_repo and propagates it through
the middle_repo and the superproject.
Once person A pushed the changes, a "git fetch" on superproject level of
person B will return with error saying:

Could not access submodule 'inner_repo'
Errors during submodule fetch:
        middle_repo


The revert was my quick approach to fix it.  However as I'm not fully
aware of what the idea was behind handling the submodules inside
.git/modules instead of the worktree, I don't know whether this is the
best solution.  Maybe rethinking the whole get_next_submodule()
algorithm or simply fixing the is_empty_dir() to use the worktree path
will be a better solution.

best regards,
--peter;

Peter Kaestle (2):
  submodules: test for fetch of non-init subsub-repo
  Revert "submodule.c: fetch in submodules git directory instead of in
    worktree"

 submodule.c                 | 14 ++++----------
 t/t5526-fetch-submodules.sh | 38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 42 insertions(+), 10 deletions(-)

-- 
2.6.2