/cc @edolstra

Seconding, hope this is merged as soon as possible

Nice. One thing that I'm still wondering is how we would prevent flakes behaving differently depending on the version of nix they're run with.
Let's say for the next nix release git-submodules will be off by default, but opt-in using ?submodules=1.
My personal preference would be to have git-submodules be on by-default. (@edolstra also mentioned that git-submodules should be on by-default which received quite a few positive reactions)
It seems that we would break backwards compatibility by changing git-submodules to be on by default, but opt-out-able using submodules=0 in a potential nix-2.5.

(Of course nothing I mentioned above is really related to this PR as it leaves the default untouched.)

Off by default, but opt-in to use, seems to be the most ideal scenario (and the one implied by this PR), since both backwards-compatability, as well as the functionality if required, is maintained

Off by default, but opt-in to use, seems to be the most ideal scenario (and the one implied by this PR), since both backwards-compatability, as well as the functionality if required, is maintained

Well nix-2.4 has not been released yet, so one scenario could also be that before the 2.4 release git-submodules becomes the default with the option to opt-out. IMO disabling submodules is mostly a performance optimization which could be done in different ways. It does however severly impact the UX of the nix command. nix build "git+file://$(pwd)?submodules=1" is not exactly simple to remember.

In #5284 it doesn't seem that edolstra has fundamentally changed his view on submodules ideally being turned on by default, so I'm really uncertain what will be the outcome of all this.

... siphoning submodules stakeholders to #5497