Hi, On Wed, May 04, 2016 at 02:13:47PM -0700, Junio C Hamano wrote: > 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. IMO we already have this. With git config submodule.<name>.update none rm -rf <path> mkdir <path> We remove a submodule from the working copy and disable any updates with 'git submodule update ...'. Maybe we should add this 'light' operation as an option to 'git submodule deinit' in the long run? > > - 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? What do you mean with "orthogonal to that issue"? AFAICS a gitmodule fallback does not have that issue. Actually I would see it more like: .gitmodule is the default and .git/config a possibility to override. When viewing it like this and using .gitmodule directly is the default a user does not have any issues when upstream changes submodule configurations. Or are we talking about subsequent forks from upstreams? Like C forked from B and B from A... Then forget what I said. > > - When upstream changes submodule options (perhaps to fix a URL > > typo), I don't get those updates. > > True. I would say it depends on what is your default view. See above. > > 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"? When .gitmodules is the default source "upstream updated" is automatically read. > 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. I can see that for some users it might be important not to pull every submodule that upstream decides they should have. On the other hand: Is it really a decision a user can/should make during a pull or a checkout. I would be annoyed by it, since it interrupts me from the thing I really want to do and would mostly just choose some default (like always yes or always no) depending on what is important to me (e.g. faster checkout or complete repository). So IMO it is more sensible if we just give the user some default to configure and then use that instead of asking questions in a situation where the user is not ready to answer them. And when the user has his defaults we can actually try to deduct such decisions directly from .gitmodules and do not need to store anything in .git/config as long as the user goes with the defaults. Cheers Heiko -- 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