On 2010-05-20, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Andy Parkins <andyparkins@xxxxxxxxx> writes: > > > One additional small point: why do untracked files in a submodule make the > > module dirty? I've often got a few "temp.ps" or "debug.log" or > > "backtrace.log" files lying around -- inappropriate to add to an ignore > > file, but they don't make my working directory dirty. > > > "They don't make my working directory dirty" is something only you can > decide, until you tell git about that fact, isn't it? > > The way to tell git about them is to use the ignore/exclude mechanism. > Why are they "inappropriate to add to an ignore file"? At least you could > have "*.log" in your personal exclude $GIT_DIR/info/exclude, no? Please, correct me if I am wrong, but I always thought that repo's dirty designation has to do with changed files _in_ the repo. Untracked files are _not_ in the repo and, as such, are irrelevant for repo's clean/dirty status. Speaking of .gitignore and untracked files. Explicitly mentioning all such untracked files in .gitignore is often unpractical. For example, during build process some large projects autogenerate many temporary *.c *.h *.cpp files. Hunting all of them down and adding to .gitignore is a waste of time and one cannot use globs *.c *.h for obvious reasons. I think that it is consistent and logical to drop untracked files from repo's dirty/clean decision process. 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. --Leo-- -- 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