Junio C Hamano <gits...@pobox.com> writes:
>> + dirname = relative_path(xgetcwd(), one_up, &sb);
>
> So, the idea is we start at the root level of the current project's
> working tree, and we go up one level, then we know the last component
> of the path our submodule is bound at in the superproject.
>
>> + prepare_submodule_repo_env(&cp.env_array);
>> + argv_array_pop(&cp.env_array);
>> + argv_array_pushl(&cp.args, "--literal-pathspecs", "-C", "..",
>> + "ls-tree", "HEAD", "--", dirname, NULL);
>
> This would ask our superproject what is at the "dirname" in its
> HEAD. Two possible issues:
>
> - Shouldn't that be looking at its index instead? It would be more
> correct for unborn branch case, and new or moved submodule case.
>
> - If our submodule is bound at path sub/dir in the superproject,
> the relative-path thing above would get "dir" and this ls-tree
> ends up asking what is at "dir", but the question you really want
> to ask is what is at "sub/dir", isn't it?
IOW, the basic ontline of the idea may be OK, but I think you would
want to do something along this line:
- chdir to .. from the root of your submodule working tree;
- in that .. directory, ask what prefix it is (you'd get
"sub/dir", or "not a git" if you are not a submodule);
- in that .. directory, ask ls-files what sub/dir is;
- if it is 160000, you're happy.
