Re: Dealing with .gitmodules
On Thu, 5 Apr 2018 13:51:45 +0200 Antonio Ospite wrote: > On Fri, 24 Mar 2017 11:12:38 +0100 > martin f krafft 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: > https://github.com/lierdakil/vcsh-modules > > It basically "redirects" operations on $GIT_WORK_TREE/.gitmodules to > $GIT_WORK_TREE/.gitmodules.d/$VCSH_REPO_NAME > > 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. > Hi, the changes I proposed to git developers have been accepted: https://public-inbox.org/git/20181025161813.17252-1-...@ao2.it/ 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 here: https://git.ao2.it/config/vcsh.git/ I tried to recap the whole story behind vcsh and submodules here: https://git.ao2.it/config/vcsh.git/commitdiff/6eede8729318d0419b32c0d9424297889a8e57b0 What I forgot to tell in that commit message is that "vcsh enter " 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 " and per-repository hooks with submodules. If you have any questions, do not hesitate to ask. Ciao, Antonio -- 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? ___ vcs-home mailing list vcs-home@lists.madduck.net https://lists.madduck.net/listinfo/vcs-home
Re: Dealing with .gitmodules
On Fri, 24 Mar 2017 11:12:38 +0100 martin f krafft 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: https://github.com/lierdakil/vcsh-modules It basically "redirects" operations on $GIT_WORK_TREE/.gitmodules to $GIT_WORK_TREE/.gitmodules.d/$VCSH_REPO_NAME 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. Any comments? If anyone is interested I can CC them (or the list?) when I write to the git mailing list. Ciao, Antonio -- 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? ___ vcs-home mailing list vcs-home@lists.madduck.net https://lists.madduck.net/listinfo/vcs-home
Re: Dealing with .gitmodules
also sprach Kevin Lyda [2017-03-31 09:50 +0200]: > Personally I prefer git subtree over git submodules. And that > said, you're using vcsh which allows for multiple git repos. So > instead of git submodules, just use additional repos. I don't think vcsh/myrepos is a good solution, but git-subtree does seem to work much better. Thanks for the hint. -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ the united nations did a poll about food. the only question they asked was: "could you please give your honest opinion about a solution for the shortage of food in the rest of the world?" this poll failed because: - in africa they didn't know what food was - in eastern-europe they didn't know what honest was - in western-europe they didn't know what shortage was... - in china they didn't know what opinion was... - in the middle-east they didn't know what solution was... - in south-america they didn't know what please was... - and in the usa they didn't know what "the rest of the world" was... spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Dealing with .gitmodules
Personally I prefer git subtree over git submodules. And that said, you're using vcsh which allows for multiple git repos. So instead of git submodules, just use additional repos. On Fri, Mar 31, 2017 at 6:58 AM martin f krafft wrote: > also sprach Joshua Haase [2017-03-31 05:37 +0200]: > > > 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. > > > > Why do you need git modules? > > For instance, my awesome config relies on the lain plugin, and > I also use subprojects for e.g. pass, mutt, vim, and others. > > How else would you do it? Note that I consider a checkout as part of > a configuration, so I want to decide myself when I pull a new > version and commit that to config, along with possibly required > changes therein. Thus, using myrepos to just recursively pull > doesn't really do what I expect. git-submodules is exactly what > I want. > > -- > @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ > > "i can stand brute force, but brute reason is quite unbearable. there > is something unfair about its use. it is hitting below the > intellect." > -- oscar wilde > > spamtraps: madduck.bo...@madduck.net > ___ > vcs-home mailing list > vcs-home@lists.madduck.net > http://lists.madduck.net/listinfo/vcs-home ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Dealing with .gitmodules
also sprach Joshua Haase [2017-03-31 05:37 +0200]: > > 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. > > Why do you need git modules? For instance, my awesome config relies on the lain plugin, and I also use subprojects for e.g. pass, mutt, vim, and others. How else would you do it? Note that I consider a checkout as part of a configuration, so I want to decide myself when I pull a new version and commit that to config, along with possibly required changes therein. Thus, using myrepos to just recursively pull doesn't really do what I expect. git-submodules is exactly what I want. -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "i can stand brute force, but brute reason is quite unbearable. there is something unfair about its use. it is hitting below the intellect." -- oscar wilde spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Dealing with .gitmodules
martin f krafft writes: > 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. Why do you need git modules? ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Dealing with .gitmodules
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? Thanks, -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "william blake, you're a dead man!" -- nobody spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
