Re: Slow git add . performance in large repo

From: Yissachar Radcliffe <yissachar@block.xyz>
Date: Mar 18, 2025, 02:04 UTC
Message-ID: <CAOHNGAUWR0K4RtEMU7WjQUhw9=rNekKfQ-1_rLNniiLKRgVzaA@mail.gmail.com>
In-Reply-To: <Z9ipn_-J-ZKbnVQh@tapette.crustytoothpaste.net>

> When you pipe the results of `git status` to `git add`, you are
> effectively using the `-u` option, since that will only ever list files
> that are tracked.

I'm not sure what you mean by this; `git status` lists untracked files. For instance, if I `touch foo.txt` and `git add -u .` then foo.txt will not be staged. But if I pipe the changes from `git status` into `git add` then it will be added.

Show 5 quoted lines

> The untracked cache is not used when you specify
> a pathspec on the command line because in the general case, it doesn't
> have to be just `.` and it could be something like a match on an
> attribute or a glob pattern, which would make the code very complex in
> dealing with that case.

Is there a reason `git add .` couldn't use the untracked cache even if other pathspecs didn't? I have to imagine that `.` is by far the most common pathspec used and there would be value in speeding that up.

> You can, of course, continue to use it, but you
> can't expect them to perform identically.

I wouldn't expect them to perform identically, but given how much faster it runs when piping in the data from `git status` I think it's reasonable to expect it to run much faster than it does today.