[RFC 00/10] Make .the gitmodules file path configurable
- Date: Fri, 13 Apr 2018 00:20:37 +0200
- From: Antonio Ospite <ao2@xxxxxx>
- Subject: [RFC 00/10] Make .the gitmodules file path configurable
vcsh 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) 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.
Antonio Ospite (10):
submodule: add 'core.submodulesFile' to override the '.gitmodules'
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
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
XXX: submodule: fix t1300-repo-config.sh to take into account the new
XXX: submodule: pass custom gitmodules file to 'test-tool
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
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?