"Nigel Magnay" <nigel.magnay@xxxxxxxxx> writes: >> I do not understand. We are talking about three different things here: >> >> 1) the committed state of the submodule >> 2) the local state of the submodule >> 3) the state of the "tracks" branch >> >> We always have 1) and we have 2) _iff_ the submodule was checked out. We >> only will have 3) if "tracks" is set in .git/config (for consistency's >> sake, we should not read that information directly from the .gitmodules >> file, but let the user override it in .git/config after "submodule init". > > I think the implication is that .gitconfig states "I'm expecting that > submodule X will always be tracking branch name 'Y'" and that you > wouldn't ever override it in .git/config. If you then switched > submodule X to branch Z, then committed the superproject, that commit > would contain a change to .gitconfig also (to say I'm expecting to > track Z rather than X') ? You are right. I think letting the user override with .git/config is a good idea, but it shouldn't be ".gitmodules may say X or whatever, but I want to use Y". Instead, it should be more like "On branches where .gitmodules says X, I want to use Y." This comment actually applies to the existing override of .gitmodules item with .git/config (I think I've been saying it since the design phase). -- 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
