Am 14.09.2010 01:14, schrieb Junio C Hamano: > What makes untracked paths in the superproject different from the ones in > a submodule? That you can have a different state for each path inside the superproject (modified, untracked etc.) while you can't have that for the paths in the submodule (when looked at from the superproject): There is only a single state available for the whole submodule, it's either modified or it isn't. So IMO a modified submodule should tell the user: "There is a change in this submodule so that when you commit/push your superproject now, others might run into problems when fetching it; you want to be sure this is not the case before doing that". And this is just the same thing you could say about a file in the superproject when it shows up as modified, no? And for submodules this definition must also include new yet untracked files, as they are very likely to be missing in every but your work tree. > "git diff" cannot be it as it does not show untracked paths > in the superproject, so you are talking about "the user cannot tell from > the 'git status' output", right? Nope, it's "git diff" too. The thing that got me started working on this topic was that "git gui" and "gitk" were quiet about submodules which had modified tracked files and/or new untracked files, which lead to real world problems where I work. And both use diff-index and diff-files to get the paths they should display *and* to display the actual changes. (And as "git diff" uses the same machinery under the hood as "git status" does, everything fell into place pretty easily) And I argue that this is sane behavior, as I'm sure other tools rely on "git diff" or "git status" too to check if there are modifications to the work tree (or they call run_diff_files() or run_diff_index() directly to do that). So all of these should agree on what they are saying about the state of a submodule, or things will get interesting. (Same goes for describe, it should append the "-dirty" when "git status" or "git diff" say a submodule is modified) And this approach works really well at my dayjob. Since we are using it, me and my colleagues are really happy with it, because we can't forget to commit changes inside a submodule anymore. So judging from this real life experience "ignore=none" is a very sane default. But I admit that this change in behavior can be strange for long time submodule users when they first encounter it. And if they still don't like the new behavior after some consideration, they can disable it easily using the new configuration options. But one of the advantages I really liked when I started using git was that is was not able to forget to commit new files anymore. So I suspect ignore=none is especially useful for new users of submodules, because it is on the safe side, and therefore should be the default setting. You can later turn the 'noise' down if you want (just like some users do when using the "-uno" option to "git status" if they don't want to be told about untracked files in the superproject or its submodules). -- 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