git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] remove/deprecate 'submodule init' and 'sync'

From
W. Trevor King <wking@tremily.us>
Date
Dec 2, 2012, 19:09 UTC
Message-ID
<20121202190929.GG9401@odin.tremily.us>
In-Reply-To
<7vy5hhmcwp.fsf@alter.siamese.dyndns.org>

Before I get into the details, I'd like to point out that I actually understand the purpose of `submodule init` now ;). To avoid further confusion, my current one-line command summaries would be:

  init:   mark a submodule as active for future submodule operation
  deinit: mark a submodule as inactive for future submodule operation
  sync:   update remote.<name>.origin in submodules to reflect changes
          in .gitmodules or the superproject's remote URL.

I don't think we disagree on that, we just don't agree on how to implement it.

Currently, Git uses submodule.<name>.url in the superproject's local configuration as a marker for submodule activation. This is not (as far as I know) discussed in the docs, which is why I initially missunderstood the purpose of `init` to be “setup the superproject's local configuration so we don't have to keep resolving the submodules URL relative to the superproject's upstream URL”. With the proposed `deinit` docs, this role for the submodule.<name>.url is mentioned, but not in a place where casual users will be able to easily connect it to the purpose of `init`.

I floated using submodule.<name>.update (with 'none' for inactive and anything else for active) as an alternative marker:

On Sat, Dec 01, 2012 at 01:16:43PM -0500, W. Trevor King wrote:
Show 17 quoted lines
> On Sat, Dec 01, 2012 at 07:04:05PM +0100, Jens Lehmann wrote:
> > Am 01.12.2012 18:49, schrieb W. Trevor King:
> > > I think removing `init` will cause some compatibility issues anyway,
> > > so I was re-imaging how you do it.  I don't think update='none' and
> > > "don't populate my submodule" are distinct ideas, while a locally
> > > configured url="somwhere" and "please populate my submodule" are (with
> > > the blank-url case defaulting to the superproject itself).
> > 
> > Why would we want to remove "init"? It still has to copy the "url"
> > setting (and it would be a compatibility nightmare if we would change
> > that, imagine different git versions used on the same work tree).
> 
> In my init-less rewrite, it doesn't have to copy the url setting.
> People using older versions of Git would need to run `init` using
> their old version.  Having the url defined in .git/config won't break
> my init-less submodule commands, it just means that the value in
> .gitmodules will be masked.

but that doesn't seem to be going over very well. Junio may have been weighing in obliquely with:

On Sat, Dec 01, 2012 at 06:00:06PM -0800, Junio C Hamano wrote:
Show 13 quoted lines
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> > [snip v1 deinit commit message]
> 
> I fully agree with your analysis on the reason why the "url" element
> is special and has to be copied to $GIT_DIR/config, but when you
> deinit (or uninit) a submodule to say you are no longer interested
> in it and do not want it populated in the context of the
> superproject, I am not sure if removing only submodule.$name.url (so
> that when you later decide to "init" it again, you will keep the
> values for submodule.$name.update and other things from the previous
> life) is the sane thing to do, or it is better to remove
> submodule.$name.* altogether as if an earlier "init" has never
> happened.  Would it be worth analyzing the pros-and-cons here?

Let me take another stab at presenting my argument in favor of a different activity marker.

Proposal:

Add a new boolean option, submodule.<name>.active, to explicitly mark submodules as active (with “active” defined as “to be returned by module_list()”). Strip down `init` (and the --init part of `update --init`) to just setting this option to true. `deinit` only sets this option to false (but a `deinit --clean` could remove the whole submodule.<name> section).

With this in place, extracting URLs for submodule operations be similar to the extraction of other variables (.gitmodules defaults with superproject-local .git/config overrides). This also makes it easier to track maintenance updates in .gitmodules-defined URLs, because you aren't forced to bake overrides into your local .git/config

The upgrade path from earlier versions of Git is easy: if submodule.<name>.active is unset, use the presence of submodule.<name>.url to determine its initial value.

In the case where you check out an earlier superproject commit which is missing a particular submodule (or remove a submodule without deinit-ing), the presense of an active setting in .git/config should not cause an error, which they currently seem to:

On Sat, Dec 01, 2012 at 11:37:14AM -0500, W. Trevor King wrote:
Show 21 quoted lines
> On Sat, Dec 01, 2012 at 04:56:02PM +0100, Jens Lehmann wrote:
> > Am 01.12.2012 00:52, schrieb Phil Hord:
> > > If I never 'submodule init' a submodule, it does not get visited by
> > > 'git submodule foreach', among others.  I think some people use this
> > > behavior explicitly.
> > >
> > > On the other hand, I've also notice that a submodule which I have
> > > removed does not get de-inited later one.  It causes my 'git submodule
> > > foreach' to emit errors.  :-(
> >
> > I'm currently hacking on "git submodule deinit" which removes the 'url'
> > setting from git/config. This should do the trick for you, right?
> >
> > Just removing that submodule automagically would not work that well, as
> > it would deinitialize a submodule when you switch to a branch where it
> > isn't present and you'd have to reinitialize it when you come back.
>
> I think this is another case where we should be looping through
> submodules based on the revision-specific .gitmodules content, and
> querying the local config only to determine if the user wants to
> update them (to drop into them with foreach, etc.).
Thoughts?
Trevor
-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Previous: Junio C HamanoNext: Jens Lehmann
Message 18 of 67 in “Re: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes”
  1. W. Trevor KingNov 29, 2012
  2. Phil HordNov 30, 2012
  3. W. Trevor KingNov 30, 2012
  4. [RFC] remove/deprecate 'submodule init' and 'sync'W. Trevor King, Nov 30, 2012
  5. W. Trevor KingNov 30, 2012
  6. Phil HordNov 30, 2012
  7. W. Trevor KingDec 1, 2012
  8. Jens LehmannDec 1, 2012
  9. W. Trevor KingDec 1, 2012
  10. Jens LehmannDec 1, 2012
  11. W. Trevor KingDec 1, 2012
  12. Jens LehmannDec 1, 2012
  13. W. Trevor KingDec 1, 2012
  14. Jens LehmannDec 1, 2012
  15. W. Trevor KingDec 1, 2012
  16. submodule: add 'deinit' commandJens Lehmann, Dec 1, 2012
  17. Junio C HamanoDec 2, 2012
  18. W. Trevor KingDec 2, 2012
  19. Jens LehmannDec 2, 2012
  20. W. Trevor KingDec 2, 2012
  21. W. Trevor KingDec 3, 2012
  22. Jens LehmannDec 2, 2012
  23. Junio C HamanoDec 3, 2012
  24. submodule: add 'deinit' commandJens Lehmann, Dec 4, 2012
  25. Junio C HamanoDec 4, 2012
  26. Michael J GruberDec 12, 2012
  27. Jens LehmannDec 12, 2012
  28. Junio C HamanoDec 12, 2012
  29. Jens LehmannDec 12, 2012
  30. Junio C HamanoDec 12, 2012
  31. W. Trevor KingDec 12, 2012
  32. Junio C HamanoDec 12, 2012
  33. W. Trevor KingDec 13, 2012
  34. Marc BranchaudDec 13, 2012
  35. Jens LehmannDec 1, 2012
  36. W. Trevor KingDec 1, 2012
  37. 0/4 submodule update: add --remote for submodule's upstream changesW. Trevor King, Dec 2, 2012
  38. 1/4 submodule: add get_submodule_config helper funtionW. Trevor King, Dec 2, 2012
  39. Junio C HamanoDec 3, 2012
  40. 2/4 submodule update: add --remote for submodule's upstream changesW. Trevor King, Dec 2, 2012
  41. Junio C HamanoDec 3, 2012
  42. W. Trevor KingDec 3, 2012
  43. W. Trevor KingDec 3, 2012
  44. Junio C HamanoDec 3, 2012
  45. W. Trevor KingDec 4, 2012
  46. 0/3 submodule update: add --remote for submodule's upstream changesW. Trevor King, Dec 11, 2012
  47. 1/3 submodule: add get_submodule_config helper funtionW. Trevor King, Dec 11, 2012
  48. 2/3 submodule update: add --remote for submodule's upstream changesW. Trevor King, Dec 11, 2012
  49. Phil HordDec 12, 2012
  50. Junio C HamanoDec 12, 2012
  51. W. Trevor KingDec 12, 2012
  52. 0/3 submodule update: add --remote for submodule's upstream changeswking@tremily.us, Dec 19, 2012
  53. 1/3 submodule: add get_submodule_config helper funtionwking@tremily.us, Dec 19, 2012
  54. Heiko VoigtDec 21, 2012
  55. W. Trevor KingDec 21, 2012
  56. 2/3 submodule update: add --remote for submodule's upstream changeswking@tremily.us, Dec 19, 2012
  57. 3/3 submodule add: If --branch is given, record it in .gitmoduleswking@tremily.us, Dec 19, 2012
  58. Junio C HamanoDec 19, 2012
  59. Heiko VoigtDec 21, 2012
  60. 3/3 submodule add: If --branch is given, record it in .gitmodulesW. Trevor King, Dec 11, 2012
  61. Junio C HamanoDec 12, 2012
  62. W. Trevor KingDec 12, 2012
  63. Junio C HamanoDec 12, 2012
  64. W. Trevor KingDec 12, 2012
  65. 3/4 submodule add: If --branch is given, record it in .gitmodulesW. Trevor King, Dec 2, 2012
  66. 4/4 submodule update: add submodule.<name>.remote config optionW. Trevor King, Dec 2, 2012
  67. Jens LehmannDec 2, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.