Hi, vcsh[1] uses bare git repositories and detached work-trees to manage *distinct* sets of configuration files directly into $HOME. In general, submodules have worked perfectly fine with detached work-trees for some time[2,3,4]. However when multiple repositories take turns using the same directory as their work-tree, and more than one of them want to use submodules, there could still be conflicts about the '.gitmodules' file because git hardcodes this path. For comparison, in case of '.gitignore' a similar conflict might arise, but git has alternative ways to specify exclude files, so vcsh solves this by setting core.excludesFile for each repository and track ignored files somewhere else (in ~/.gitignore.d/$VCSH_REPO_NAME). This is currently not possible with submodules configuration. So this series proposes a mechanism to set an alternative path for the submodules configuration file (from now on "gitmodules file"). Patches are based on fe0a9eaf31dd0c349ae4308498c33a5c3794b293. In commit 4c0eeafe4755 (cache.h: add GITMODULES_FILE macro)[5] the gitmodules file path definition was centralized, AFAIU this was done mainly to prevent typos, as checking a symbolic constant is something the compiler will do for us. Expanding on that change the first patch in the series makes the path customizable exposing a 'core.submodulesFile' configuration setting. The new configuration setting can be used to set an *alternative* location for the gitmodules file; IMHO there is no need to provide *additional* locations like in the case of exclude files. For instance vcsh could set the location to '~/.gitmodules.d/$VCSH_REPO_NAME' to avoid conflicts. Since the gitmodules file is meant to be checked in into the repository, the overridden file path should be relative to the work-tree; is there a way to enforce this constraint at run time (i.e. validate the config value), or is it enough to have it documented? The last patch adds a hacky 'test-custom-gitmodules-file.sh' script which patches the test suite to fix all the hardcoded occurrences of '.gitmodules' and runs it twice: once with the default value and once with a custom path, passed via an environmental variable. I guess in the final version just testing for a custom path (e.g. '.gitmodules_custom') could be enough, as the default value can be seen as a particular case. The last thing I noticed is that git does not create config files automatically if they are under a subdirectory which does not exist already; for instance the following command would fail: git config -f newsubdir/test-config user.name Antonio This means that if the user wanted to use something like: git -c core.submodulesFile=.gitmodules.d/repo_submodules ... the subdirectory would have to be created beforehand. This is not a big deal of course, but I was wondering if this is mentioned anywhere. Fixing the current behavior to create the leading directories does not seem hard, but I am not sure it is worth it. Thanks, Antonio [1] https://github.com/RichiH/vcsh [2] http://git.661346.n2.nabble.com/git-submodule-vs-GIT-WORK-TREE-td7562165.html [3] http://git.661346.n2.nabble.com/PATCH-Solve-git-submodule-issues-with-detached-work-trees-td7563377.html [4] https://github.com/git/git/commit/be8779f7ac9a3be9aa783df008d59082f4054f67 [5] https://github.com/git/git/commit/4c0eeafe4755345b0f4636bf09904cf689703e11 Antonio Ospite (10): submodule: add 'core.submodulesFile' to override the '.gitmodules' path submodule: fix getting custom gitmodule file in fetch command submodule: use the 'submodules_file' variable in output messages submodule: document 'core.submodulesFile' and fix references to '.gitmodules' submodule: adjust references to '.gitmodules' in comments completion: add 'core.submodulesfile' to the git-completion.bash file XXX: wrap-for-bin.sh: set 'core.submodulesFile' for each git invocation XXX: submodule: fix t1300-repo-config.sh to take into account the new config XXX: submodule: pass custom gitmodules file to 'test-tool submodule-config' XXX: add a hacky script to test the changes with a patched test suite Documentation/config.txt | 18 +++-- Documentation/git-add.txt | 4 +- Documentation/git-submodule.txt | 45 +++++------ Documentation/gitmodules.txt | 15 ++-- Documentation/gitsubmodules.txt | 18 ++--- .../technical/api-submodule-config.txt | 6 +- Makefile | 3 +- builtin/fetch.c | 2 +- builtin/mv.c | 3 +- builtin/rm.c | 3 +- builtin/submodule--helper.c | 20 ++--- cache.h | 1 + config.c | 13 ++-- config.h | 7 +- contrib/completion/git-completion.bash | 1 + contrib/subtree/git-subtree.txt | 2 +- environment.c | 1 + git-submodule.sh | 24 +++--- repository.h | 2 +- submodule-config.c | 16 ++-- submodule-config.h | 2 +- submodule.c | 54 ++++++------- t/helper/test-submodule-config.c | 7 ++ t/t0001-init.sh | 1 + t/t1300-repo-config.sh | 26 ++++++- test-custom-gitmodules-file.sh | 75 +++++++++++++++++++ unpack-trees.c | 2 +- wrap-for-bin.sh | 2 + 28 files changed, 250 insertions(+), 123 deletions(-) create mode 100755 test-custom-gitmodules-file.sh mode change 100644 => 100755 wrap-for-bin.sh -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?