From: Leo Razoumov Date: Fri, 21 May 2010 12:52:13 GMT Subject: Re: git-status and git-diff now very slow in project with a submodule Message-ID: In-Reply-To: <7vy6fe7ldo.fsf@alter.siamese.dyndns.org> On 2010-05-20, Junio C Hamano wrote: > Andy Parkins 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--