Am 21.05.2010 14:52, schrieb Leo Razoumov: > On 2010-05-20, Junio C Hamano <gitster@xxxxxxxxx> wrote: > I would be interested to know of any counter-example: that is, a > use-case where it makes logical sense to declare a repo dirty when it > gets an untracked file not mentioned in .gitignore. For submodules the presence of untracked files must be visible in the superproject. When new files are added to a submodule but the user forgot to commit them, the superproject might not even build at all when another developer clones the superproject. And yes, this is a real-life use case from my dayjob. The alternative to these broader definitions about when to declare a submodule dirty (new commits, modified content and untracked content) would have been to handle all eight combinations of these states. In all relevant parts of the toolchain. Which seems pretty insane. So the submodule shows up as modified; and all but the short outputs of diff and status also tell you /why/ it is considered modified. So the user can decide what to do about that. -- 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