Re: git commit <path> scanning entire working tree?

[skillzero@gmail.com]

On Mon, Feb 16, 2009 at 11:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> skillzero@gmail.com writes:

> People do rely on that information.  Why else we would spend cycles to show
> them?

My guess was that most people didn't work with very large trees. For
example, the Linux kernel tree stat's pretty quickly (.7 seconds when
hot on my machine), but my tree contains the code for an entire OS
distribution so even on a fast machine and OS, it takes many seconds.

My thinking was that in the case when a path was specified, people
might be less interested in changes/untracked files outside that path
(although I may be totally wrong). If a path wasn't specified, I can
see why it would be useful to show everything. I tend to do a 'git
status' then a bunch of 'git commit <path>' commands.

> There is a precedence to allow a configuration variable to skip various
> computation to help slow systems, e.g. 6c2ce04 (Add argument 'no'
> commit/status option -u|--untracked-files, 2008-06-05).

Thanks, I'll check it out. If that doesn't do what I need, maybe I can
trying changing git to add support for automatically skipping files
outside the specifies path and submit a patch for you guys to rip to
shreds :)