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.


[1] https://github.com/RichiH/vcsh
[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'
  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

Antonio Ospite

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?

Reply via email to