Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > This design is somewhat problematic for a few reasons: > > - When I want to stop paying attention to a particular submodule and > start paying attention to it again later, all my local settings are > gone. True; "[submodule "foo"] enabled = no" may also be a way to fix it without throwing the whole with bathwater, though. > - When upstream adds a new submodule, I have to do the same manual > work to change the options for that new submodule. Because a new module is not automatically "init"ed by default? Isn't "config only" vs "config with gitmodules fallback" orthogonal to that issue? > - When upstream changes submodule options (perhaps to fix a URL > typo), I don't get those updates. True. > A fix is to use settings from .git/config when present and fall back > to .gitmodules when not. How would that fix the "upstream updated"? I think an alternative suggested in an ancient time had a more elaborate scheme: * Use .git/config as the authoritative source, but record sufficient information to detect the case and cope with it when entry in .gitmodules changes (details below). * When seeing a new .gitmodules entry, either by "git pull" or even "git checkout other-branch", copy that to .git/config (just like what "git submodule init" does). It would be a policy decision to automatically enabling it or not. If the policy is "no autoinit", then "module.<name>.inited = no" may also have to be added to .git/config at this point. Record contents of the entry in .gitmodules to the corresponding .git/config entry as "seen". * When the entry in .gitmodules for a submodule known to .git/config is different from what has been "seen", offer the user a chance to update corresponding .git/config entry, and append to the "seen" set of variants in .gitmodules so that the user will not be bugged with "we see .gitmodules entry for module <foo> is different from anything you have ever seen; do you want to make corresponding changes to the module entry in your .git/config" again. which would handle all of the above, and without using anything from .gitmodules before the user has a chance to vet it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html