Re: git-status and git-diff now very slow in project with a submodule

From: Leo Razoumov <slonik.az@gmail.com>
Date: May 21, 2010, 12:52 UTC
Message-ID: <AANLkTilctjct-a911H14XMnaBydYR1I6lPbEuFThTJ99@mail.gmail.com>
In-Reply-To: <7vy6fe7ldo.fsf@alter.siamese.dyndns.org>

On 2010-05-20, Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

> Andy Parkins <andyparkins@gmail.com> 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--