Re: [PATCH 3/4] submodule--helper list: lose the extra prefix option

[Stefan Beller <sbeller@google.com>]

On Fri, Mar 25, 2016 at 10:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> The way all the subcommand written in C works is
>>
>>  - The start-up sequence does the repository discovery, which
>>    involves crawling up to the top-level of the working tree, and
>>    compute "prefix", where the end-user was when the command was
>>    invoked;
>>
>>  - The subcommand implementation is called with this "prefix";
>>
>>  - When the subcommand implementation interprets the command line
>>    arguments and option arguments, it prefixes the "prefix" as
>>    needed.  If, for example, "git grep -f patterns" is invoked
>>    inside "sub/" subdirectory, when the command line and option
>>    arguments are processed, the process is already at the top level
>>    of the working tree, so it needs to read the patterns from
>>    "sub/patterns" file.  "git ls-files 'Makefil*'" invoked inside
>>    "sub/" subdirectory needs to limit the output to those that match
>>    not "Makefile", but "sub/Makefil*".
>>
>> The hope of doing an incremental rewrite of the whole thing by
>> enriching submodule--helper is that the bulk of the code there will
>> be reusable when the entirety of "git submodule" is rewritten in C,
>> so they need to take the "prefix" the same way, whether the caller
>> is calling from "git-submodule.sh" script via submodule--helper, or
>> the eventual C implementation of "git submodule" is making direct
>> calls to them.  As long as the correct "prefix" is passed to the
>> routines that are driven via submodule--helper, it does not matter
>> and I do not care how it is done.
>>
>> The current code of "git submodule" whose higher parts are still in
>> shell would would:
>>
>>  - The start-up sequence in shell does the cd_to_toplevel and finds
>>    the prefix;
>>
>>  - "git submodule--helper list --prefix=$prefix $other_args" is
>>    called; as this is called from the top-level of the working tree,
>>    internally its "prefix" is empty, but $other_args must be
>>    interpreted relative to the $prefix passed with --prefix option.
>>
>> If we instead call "git -C "$prefix" submodule--helper list $other_args",
>> then
>>
>>  - This command first does another chdir(2) back to $prefix;
>>
>>  - The start-up sequence of "submodule--helper" does the usual
>>    repository discovery again, which involves crawling up to the
>>    top-level of the working tree, and compute "prefix".  This
>>    happens to match what -C "$prefix" gave the command.
>>
>> Making calls to submodule--helper via "git -C" feels a little bit
>> roundabout because of this "caller tells to chdir, and then it has
>> to again chdir back up" only to rediscover the same information.
>
> Just to make sure that the discussion is complete.
>
> Another way a script can use the "prefix" information is to use the
> "prefix" as such.  Knowing that the cd_to_toplevel() took you to the
> root level of the working tree, instead of "git -C $prefix" or
> "--prefix $prefix", it could do "git $cmd $prefix$filename".
>
> One consideration when choosing among the approaches is how the
> $filename is reported back to the user (e.g. as part of an error
> message).  "git $cmd $prefix$filename" invocation would complain
> about the full "$prefix$filename" path, but what the user gave it
> may only be $filename part.

Right. Using either "git -C $prefix" or "git --prefix $prefix" would report
the $filename only, because both cases assume $prefix was cut
using cd_to_toplevel and the user expects $filename only.