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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andy Parkins <andyparkins@xxxxxxxxx> writes:

> Also, I don't want *.log, or *.ps -- neither of them is guaranteed to be an 
> ignore pattern.  These throw away files have all sorts of names, made up on 
> the spot as I'm working, adding them to an ignore file is overkill from my 
> point of view.

I've learned to give them names that begin with an unusual letter (in my
case, a colon or a plus sign), way before I started working on git, so the
above is not a very convincing argument at least to me.

In any case, I am a bit torn about this whole issue.

On one hand, scanning for untracked files are not about these *.log cruft,
but to catch mistakes that are caused by new paths that you forgot to add,
and in that sense, uncommitted modifications to a path that happens to be
tracked and a new path that you forgot to add have (semantically) similar
chance of being a mistake that you might want to catch by running "git
status".

On the other hand, adding new paths to an existing project is a rare
event, compared to modifications to existing paths (e.g. even for a
project as small and young as git.git, we have 10x as many revisions as we
have paths), so by definition the chance that you might break others'
builds by forgetting to commit a new file is much smaller than forgetting
to commit necessary changes to existing files.

But ideally you would want your tool to catch mistakes that are rarer, as
you would learn to avoid common mistakes on your own without help from
your tool over time.

At least we should be able to let the users say, with "git status -uno",
"I don't care about untracked and unignored paths; I don't make such a
mistake to forget adding new paths", and optimize the scanning of
submodule directories taking advantage of that statement.  Is there a
fundamental reason why things shouldn't work that way, or is it just a
bug in the current code?

--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]