>Do you agree that there is an inconsistency between how untracked content is >treated at the super-project level and at the submodule level? Yes, but I - and others included in that discussion some time ago - could not come up with a sane and simple solution to that problem. > Any thoughts >about how the behavior should be made to be consistent? The core of this issue is that for git a file is either untracked, modified or clean. But submodules can have every combination of all these states - as they consist of multiple files - and additionally their HEAD can differ from the commit recorded in the superproject. So basically I see two ways to handle that: a) add new states for an entry to represent all missing combinations of possible states for submodules and tell all porcelain to handle these. b) simplify this problem by having a submodule show up as modified when either of these three conditions are met (and enable the user to choose what conditions she wants to see and what not). Obviously a) will complicate all git by a large degree just for the sake of submodules. I am arguing for b), because submodules itself can be seen as a bunch of files which don't interest me as single entities until I want to take a closer look. I think the issue we are discussing here is the price we have to pay for this abstraction. I am very open to proposals how to better handle that but so far I haven't seen any. >Perhaps the default setting of submodule.<name>.ignore should be 'untracked'? I still vote for none. I think the default should be to not have untracked files in your projects (like you should not have warnings when compiling your project). If that is not wanted, just use the configuration options git provides to change 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