Dealing with .gitmodules
ao2 at ao2.it
Mon Dec 17 11:15:35 CET 2018
On Thu, 5 Apr 2018 13:51:45 +0200
Antonio Ospite <ao2 at ao2.it> wrote:
> On Fri, 24 Mar 2017 11:12:38 +0100
> martin f krafft <madduck at madduck.net> wrote:
> > Hey,
> > The file .gitmodules (man 5 gitmodules, for use with git-submodule)
> > is hardcoded to reside in $GIT_WORK_DIR/.gitmodules. As vcsh
> > repositories all share the same work dir, there's a conflict.
> > Has anyone come up with a smart way to handle this?
> I am picking up this old discussion, as submodules are indeed the most
> "natural" way to deal with extensions or plugins. and this is IMHO the
> main pain-point of using detached working trees.
> An interesting approach to overcome the limitation of the
> hardcoded .gitmodules path is vcsh-modules:
> It basically "redirects" operations on $GIT_WORK_TREE/.gitmodules to
> A more robust solution could be to teach git how to set a custom path
> for the gitmodules file.
> I have an experimental patch for that I am thinking about proposing it
> to git developers. My idea is to have a core.submodulesFile config
> setting in git, which vcsh could set when operating on a repo.
the changes I proposed to git developers have been accepted:
And since version 2.20.0 git is able to use .gitmodules even when the
file is not in the working tree.
Combining this with the sparse-checkout functionality it is now
possible to use submodules with "vcsh run" with a setup like the one
I tried to recap the whole story behind vcsh and submodules here:
What I forgot to tell in that commit message is that "vcsh enter <repo>"
was already working even with older git version as long as .gitmodules
was ignored in the sparse-checkout config.
The new git version enables the use of "vcsh run <repo> <command>" and
per-repository hooks with submodules.
If you have any questions, do not hesitate to ask.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
More information about the vcs-home