On 03/17, Junio C Hamano wrote:
> Brandon Williams <bmwill@xxxxxxxxxx> writes:
>
> > I don't think that prefix can ever have ".." in it. From what I
> > understand it is always a path from the root of the repository to the
> > cwd that the git command was invoked by. So in your example prefix
> > would be "src/".
>
> The prefix would be NULL or "", as you will be at the root-level of
> the working tree when you are running _IN_ the submodule (by
> recursing into it). Not src/, nor anything with ../ in it, I would
> think.
Yes, the prefix that is found during setup of a submodule process would
be NULL or "" as the command would be invoked from the root of that
repository. This series would sort of change that though.
If a command was invoked from 'src/' with a pathspec of '../dir/' and
there is a submodule at 'dir/sub', the process working on the submodule
will have the following:
super_prefix = 'dir/sub/'
prefix = 'src/' (Passed from the parent process via the
GIT_INTERNAL_TOPLEVEL_PREFIX env var)
pathspec = '../dir/'
With that information the child process will be able to properly resolve
the pathspec to be 'dir/' (using the prefix) and will be able to match
against it by pre-pending the super_prefix (e.g. dir/sub/some/file, where
some/file is a file in the submodule). It will also be able to generate
correct output relative to the directory the command was originally
invoked from by first pre-pending the super_prefix so we have
'dir/sub/some/file' and then calling relative_path() with the prefix
that was passed in such that the output for this file looks like
'../dir/sub/some/file'
That the gist of how I'm hoping to solve the problem. Hopefully that was
clear enough to get some feedback on.
--
Brandon Williams