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

Re: [PATCH] submodule: mark submodules with update=none as inactive

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Jun 25, 2021, 23:02 UTC
Message-ID
<YNZgoS9R1qam+62C@camp.crustytoothpaste.net>
In-Reply-To
<56b5c722-8baf-9f9c-cc9f-5b5ed49d7fc3@gmail.com>
On 2021-06-22 at 03:45:45, Philippe Blain wrote:
Show 21 quoted lines
> > That will make us properly ignore the submodule
> > when performing recursive operations.
> > 
> > Note that we only do this when the --require-init option is passed,
> > which is only passed during clone.  That's because the update-clone
> > submodule helper is also invoked during a user-invoked git submodule
> > update, where we explicitly indicate that we override the configuration
> > setting, so we don't want to set such a configuration option then.
> 
> I'm not sure what you mean here by 'where we explicitely indicate that we
> override the configuration setting'. For me, as I wrote above,
> 'git clone --recurse-submodules' and 'git clone' followed by
> 'git submodule update --init' should lead to mostly [*] the same end result.
> 
> If you mean 'git submodule update --checkout', that indeed seems to sometimes override the 'update=none'
> configuration (a fact which is absent from the documentation), then it's true that we
> would not want to write 'active=false' at that invocation. As an aside, in my limited testing
> I could not always get 'git submodule update --checkout' to clone and checkout 'update=none' submdules;
> it would fail with "fatal: could not get a repository handle for submodule 'sub1'" because
> 'git checkout/reset --recurse-submodules' leaves a bad .git/modules/sub1/config file
> with the core.worktree setting when the command fails (this should not happen)...
Yes, that's what I meant.
> In any case, that leads me to think that maybe the right place to write the 'active' setting
> would be during 'git submodule init', thus builtin/submodule--helper.c::init_submodule ?
> This way it would lead to the same behaviour if the clone was recursive or not,
> and it would not interfere with 'git submodule update --checkout'.

Let me take a look at some other approaches and see if I can come up with something a little bit better.

My apologies for the delay in response; I'm in the process of moving at the moment and my attention has been directed elsewhere than the list.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Previous: Philippe BlainNext: Philippe Blain
Message 14 of 18 in “[BUG] `git reset --hard` fails with `update = none` submodules”
  1. Rose KunkelJun 16, 2021
  2. brian m. carlsonJun 16, 2021
  3. Rose KunkelJun 16, 2021
  4. Rose KunkelJun 16, 2021
  5. Rose KunkelJun 16, 2021
  6. brian m. carlsonJun 16, 2021
  7. Rose KunkelJun 16, 2021
  8. Rose KunkelJun 16, 2021
  9. Junio C HamanoJun 16, 2021
  10. Philippe BlainJun 16, 2021
  11. brian m. carlsonJun 17, 2021
  12. submodule: mark submodules with update=none as inactivebrian m. carlson, Jun 19, 2021
  13. Philippe BlainJun 22, 2021
  14. brian m. carlsonJun 25, 2021
  15. Philippe BlainJun 26, 2021
  16. submodule: mark submodules with update=none as inactivebrian m. carlson, Jul 1, 2021
  17. Philippe BlainJul 9, 2021
  18. brian m. carlsonJul 11, 2021

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.