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

Re: [PATCH 0/2] Add an update=none option for 'loose' submodules

From
Jens Lehmann <jens.lehmann@web.de>
Date
Aug 23, 2011, 20:18 UTC
Message-ID
<4E540B03.2030909@web.de>
In-Reply-To
<20110823194350.GA57187@book.hvoigt.net>
Am 23.08.2011 21:43, schrieb Heiko Voigt:
Show 14 quoted lines
> On Mon, Aug 22, 2011 at 03:42:55PM -0700, Junio C Hamano wrote:
>>> It is somewhat worrying that some parts of the system may still be using
>>> that old criteria "do we have it in .git/config of the superproject?" to
>>> decide if the user is interested in the submodule. If so they need to be
>>> updated to take this new semantics "do we have it in .git/config without
>>> its submodule.$name.update set to none" into account. We would probably
>>> need to have a paragraph in the release notes to warn about the semantics
>>> change (which I tend to agree with you that it is a good one).
> 
> Sorry that I forgot to answer to this. I am not sure what you mean by
> "the semantics change". This patch does not change any existing
> behavior. I rather see this as an extra way to specify the default
> behavior of what happens on submodule update. If people do not use it
> there will be no expectations broken.

It might surprise people. E.g. when their old scripts don't work anymore as they did before because a submodule won't be populated or updated in the work tree even though it is present in .git/config. So I agree that this should be documented in the release notes so people can check if their expectations are still met.

> Another change I am thinking of (which would definitely need an entry in
> the release notes) is to change submodule foreach to iterate over all
> gitmodule entries in the index/HEAD/worktree (not sure yet) instead of
> "just entries that are in .git/config".

When changing the default I think we'll surprise a lot of users (imagine someone running a "git submodule foreach pwd" when some submodules aren't populated). But adding an option to "git submodule foreach" (and maybe others) to get the list of submodules from the index or HEAD might make sense (while I'm not sure parsing the work tree does, as you'll basically have to pick up any .git you find. AFAICS a submodule is defined either by an entry in the .gitmodules file, in .git/config or through a gitlink entry in a commit or the index. So maybe the third alternative to index and HEAD is to use those found in .gitmodules?).

Could you describe a use case for that?
Previous: Heiko VoigtNext: Junio C Hamano
Message 10 of 15 in “Add an update=none option for 'loose' submodules”
  1. 0/2 Add an update=none option for 'loose' submodulesHeiko Voigt, Aug 11, 2011
  2. 1/2 submodule: move update configuration variable further upHeiko Voigt, Aug 11, 2011
  3. 2/2 add update 'none' flag to disable update of submodule by defaultHeiko Voigt, Aug 11, 2011
  4. Junio C HamanoAug 11, 2011
  5. Heiko VoigtAug 11, 2011
  6. Junio C HamanoAug 15, 2011
  7. Heiko VoigtAug 22, 2011
  8. Junio C HamanoAug 22, 2011
  9. Heiko VoigtAug 23, 2011
  10. Jens LehmannAug 23, 2011
  11. Junio C HamanoAug 23, 2011
  12. Heiko VoigtAug 24, 2011
  13. Junio C HamanoAug 26, 2011
  14. Jens LehmannAug 26, 2011
  15. Heiko VoigtAug 24, 2011

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.