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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]