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

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

 



On Mon, Feb 16, 2009 at 11:12 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> skillzero@xxxxxxxxx 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 :)
--
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]

  Powered by Linux