From: Antonio Ospite <email@example.com> To: firstname.lastname@example.org Cc: Brandon Williams <email@example.com>, git <firstname.lastname@example.org>, Richard Hartmann <email@example.com> Subject: Re: [RFC 00/10] Make .the gitmodules file path configurable Date: Mon, 16 Apr 2018 13:33:12 +0200 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CAGZ79kZbZ03D7ysaVXYkV3v0jO6K7kEOc9sT2zA+Xc6mqLNL9Q@mail.gmail.com> On Thu, 12 Apr 2018 16:36:32 -0700 Stefan Beller <email@example.com> wrote: > Hi Antonio, > Hi Stefan, > On Thu, Apr 12, 2018 at 3:20 PM, Antonio Ospite <firstname.lastname@example.org> wrote: > > Hi, > > > > 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. > > [...] > > > So this series proposes a mechanism to set an alternative path for the > > submodules configuration file (from now on "gitmodules file"). > [...] > > Expanding on that change the first patch in the series makes the path > > customizable exposing a 'core.submodulesFile' configuration setting. > > I guess the similarity to core.ignoreFile is desired here. Although these > mechanisms are very different. > The option name is similar to 'core.excludesFile' also because, when I started, I first looked at how multiple ignore files were used, so I may have been influenced by that. I acknowledge that the two mechanisms are different, in particular because git *writes* the gitmodules file itself. I am not opposed to change the name, something like 'core.submodulesConfigFile' might highlight that the syntax of the file is the one of git config, but I think it's too long. > > 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. > > I think there *may* be a need for additional files. > Currently there is only the .gitmodules file and the configuration > in .git/config overriding settings from .gitmodules. > > There was some discussion on the mailing list in the past, which > presented a intermediate layer in between these two places, in > a special ref, such that: > base is in .gitmodules > overwritten via refs/meta/submodules:.gitmodules > overwritten via the .git/config > > The intermediate would be a config file that is tracked on another > ref. This (a) decouples main project history from submodule history > and (b) makes it easier to distribute as it is part of the repository. > > For example (a) is desired if you dig up an old project and the > submodules have all moved from one git hosting provider to another. > Another example would be when you fork a project with submodules > and don't want to mess with the main history but you just want to > adjust the submodule URLs. That is possible with such an intermediate > additional place. > > For (b) you can imagine the fork that you want to distribute in your > community and you don't want to tell everyone to change the > submodule URLs, but instead you can provide them with a prepared > .gitmodules file, that they have to place into that special ref (which > can be done via fetching). > > I digress as these ideas seem to be orthogonal to your patch series, > just FYI. prior discussion starting at: > https://email@example.com/ > I recall there was a better discussion even prior to that, but have no > link handy. > Just to understand, is that 'refs/meta/submodules:.gitmodules' file meant to be managed manually? Or do you imagine some options to instruct "git submodule" to *write* to that file instead of .gitmodules? In the latter case your idea could cover my use case too, couldn't it? But most importantly, is this realistically going to be added? Currently I am not that familiar with the git code base to do it myself, and I've never explicitly dealt with special refs in git. The approach of this patch series is a lot simpler, and something I can work on in my spare time. Presumably (b) could even be partially supported with my changes, by having both '.gitmodules' and some custom '.gitmodules-alternative' files in the repository and tell users to clone with: git clone --config core.submodulesFile=.gitmodules-alternative URL Not as clean as your idea but doable. [...] > > 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? > > I think we'd want to check at run time, if we need this constraint. > I'll look into it once we decide which the way to go. Thank you. 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?
next prev parent reply index Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-12 22:20 Antonio Ospite 2018-04-12 22:20 ` [RFC 01/10] submodule: add 'core.submodulesFile' to override the '.gitmodules' path Antonio Ospite 2018-04-12 23:50 ` Stefan Beller 2018-04-16 16:37 ` Antonio Ospite 2018-04-16 21:22 ` Stefan Beller 2018-04-18 11:43 ` Antonio Ospite 2018-04-18 18:44 ` Stefan Beller 2018-04-12 22:20 ` [RFC 02/10] submodule: fix getting custom gitmodule file in fetch command Antonio Ospite 2018-04-12 23:55 ` Stefan Beller 2018-04-16 16:18 ` Antonio Ospite 2018-04-16 19:23 ` Stefan Beller 2018-04-16 20:46 ` Antonio Ospite 2018-04-12 22:20 ` [RFC 03/10] submodule: use the 'submodules_file' variable in output messages Antonio Ospite 2018-04-12 22:20 ` [RFC 04/10] submodule: document 'core.submodulesFile' and fix references to '.gitmodules' Antonio Ospite 2018-04-12 22:20 ` [RFC 05/10] submodule: adjust references to '.gitmodules' in comments Antonio Ospite 2018-04-12 22:20 ` [RFC 06/10] completion: add 'core.submodulesfile' to the git-completion.bash file Antonio Ospite 2018-04-12 23:36 ` [RFC 00/10] Make .the gitmodules file path configurable Stefan Beller 2018-04-16 11:33 ` Antonio Ospite [this message] 2018-04-16 19:22 ` Stefan Beller 2018-04-13 8:07 ` Antonio Ospite 2018-04-13 8:07 ` [RFC 07/10] FIXME: wrap-for-bin.sh: set 'core.submodulesFile' for each git invocation Antonio Ospite 2018-04-13 8:07 ` [RFC 08/10] FIXME: submodule: fix t1300-repo-config.sh to take into account the new config Antonio Ospite 2018-04-13 8:07 ` [RFC 09/10] FIXME: submodule: pass custom gitmodules file to 'test-tool submodule-config' Antonio Ospite 2018-04-13 8:07 ` [RFC 10/10] FIXME: add a hacky script to test the changes with a patched test suite Antonio Ospite 2018-04-13 20:05 ` [RFC 07/10] FIXME: wrap-for-bin.sh: set 'core.submodulesFile' for each git invocation Stefan Beller 2018-04-16 11:36 ` Antonio Ospite 2018-04-23 17:47 ` [RFC 00/10] Make .the gitmodules file path configurable Jonathan Nieder 2018-04-30 12:51 ` Antonio Ospite
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
email@example.com mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox