[REGRESSION FIX 0/2] Handling regression introduced by a62387b

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(-)