git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 25, 2016, 16:02 UTC
Message-ID
<xmqqegay5yw0.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<xmqqmvpn5awo.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 25 quoted lines
> Stefan Beller <sbeller@google.com> writes:
>
>> The usual early machinery of Git is to change the directory to
>> the top level of the working tree and pass the actual path inside
>> the working tree as `prefix` to the command being run.
>>
>> This is the case both for commands written in C (where the
>> prefix is passed into the command in a function parameter) as
>> well as in git-submodule.sh where the setup code runs...
>>
>> Adhere to Gits standard of passing the relative path inside the
>> working tree by passing it via -C.
>
> While -C _also_ works, I do not think it is "standard" in any sense.
> What made you think so?  -C is a way to tell Git to chdir there
> before doing anything else, without even adjusting the command line
> arguments that might be paths, and "chdir there to go to top" may
> (or may not--I haven't thought things thru) have the same effect as
> passing the prefix into functions, that is merely true as a side
> effect, I would think.
>
> So this change may not be wrong per-se, but if the lossage of prefix
> is the final goal (as opposed to an approach to gain other benefits,
> e.g. "now we do not have to use prefix, we can simplify these other
> things"), I do not know if it is worth it.

I actually do not care too deeply either way, as I understand that the long term goal is to have "git submodule" itself rewritten in C, so that places that currently call submodule--helper would become an internal call.

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.

Again, I actually do not care too deeply either way, though, as long as the correct "prefix" is passed to the routines that are driven via submodule--helper, which would assure that the C code you write today will be reusable when "git submodule" as a whole is redone in C.

Thanks.
Previous: Junio C HamanoNext: Junio C Hamano
Message 14 of 23 in “[PATCHv2 0/4] submodule helper: cleanup prefix passing”
  1. Stefan BellerMar 24, 2016
  2. 1/4 submodule: fix recursive path printing from non root directoryStefan Beller, Mar 24, 2016
  3. Jacob KellerMar 24, 2016
  4. Stefan BellerMar 24, 2016
  5. Junio C HamanoMar 25, 2016
  6. Stefan BellerMar 25, 2016
  7. 2/4 submodule: fix recursive execution from non root directoryStefan Beller, Mar 24, 2016
  8. Jacob KellerMar 24, 2016
  9. Junio C HamanoMar 25, 2016
  10. Stefan BellerMar 25, 2016
  11. 3/4 submodule--helper list: lose the extra prefix optionStefan Beller, Mar 24, 2016
  12. Jacob KellerMar 24, 2016
  13. Junio C HamanoMar 25, 2016
  14. Junio C HamanoMar 25, 2016
  15. Junio C HamanoMar 25, 2016
  16. Stefan BellerMar 25, 2016
  17. Stefan BellerMar 25, 2016
  18. Junio C HamanoMar 25, 2016
  19. Stefan BellerMar 25, 2016
  20. Junio C HamanoMar 25, 2016
  21. 4/4 submodule: add more tests for recursive submodule behaviorStefan Beller, Mar 24, 2016
  22. Eric SunshineMar 25, 2016
  23. Stefan BellerMar 25, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.