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

[PATCH 0/2] recursive submodules: paths are hard

From
Stefan Beller <sbeller@google.com>
Date
Feb 26, 2016, 20:51 UTC
Message-ID
<1456519912-10641-1-git-send-email-sbeller@google.com>

I thought getting rid of the extra `prefix` argument in submodule helper functions was easy up to the point of all but one test passing in the test suite.

It turned out the implementation of that prefix patch was wrong, only caught by tests, so we want to add tests for subtle details with submodule sync and update which have not been tests yet.

For the record, I thought the 'prefix' patch was as easy as:
-       git submodule--helper list --prefix "$wt_prefix" "$@" | {
+       git -C "$wt_prefix" submodule--helper list "$@" | {
for all occurrences of `submodule--helper list`.

This is not the case as by doing so the recursive functionality of submodules is broken in some edge cases.

Consider this sequence:
  mkdir untracked &&
  cd untracked &&
  git submodule <command> --recursive
  
The operation is run from within the work tree, so fro a normal submodule
operation (without --recursive) you expect the pathes to be adapted to be
prefixed by a `../` to make sense relative to the untracked directory.

In the case of recursive submodule operations, currently `git submodule` usually does

        if test -n "$recursive"
        then
        (
                prefix="$prefix$sm_path/"
                clear_local_git_env
                cd "$sm_path" &&
                eval cmd_update
        )
        
By having a change of directory followed by the recursive call to the operation
we need to make sure the displayed path is still correctly referenced to where
the operation started.

By passing the prefix separately to git submodule--helper, this works currently as the prefix is only used for calculating the displaypath. If it were passed by the standard Git machinery, there is going on more, which fails us at some point.

I think we may need to enable Git to pass in 'negative' pathes for the prefix,
i.e. 
  Although operating on this repository, your reference for displaying paths
  should be '../untracked' for the example above, when the submodule is in the
  root directory of the superproject.
This seems currently not possible with the standard way to pass down the prefix.

TL;DR: Most of the test is unrelated to the patch series, the patch series adds some tests, which I would have found useful to stop me going the wrong direction.

Thanks, Stefan

Stefan Beller (2):
  Check recursive submodule update to have correct path from
    subdirectory
  submodule sync: Test we can pass individual submodules
 t/t7403-submodule-sync.sh   | 13 +++++++++----
 t/t7406-submodule-update.sh | 12 ++++++++++++
 2 files changed, 21 insertions(+), 4 deletions(-)
-- 
2.7.2.368.g934fe14
Next: Stefan Beller
Message 1 of 4 in “recursive submodules: paths are hard”
  1. 0/2 recursive submodules: paths are hardStefan Beller, Feb 26, 2016
  2. 1/2 Check recursive submodule update to have correct path from subdirectoryStefan Beller, Feb 26, 2016
  3. 2/2 submodule sync: Test we can pass individual submodulesStefan Beller, Feb 26, 2016
  4. Duy NguyenFeb 27, 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.