Just ran "git add -i <path>" with "<path>" pointing to a subdirectory
which happens to have a bunch of files in it (about 7k) and it barfed
thusly:
Can't exec "git": Argument list too long at /usr/local/libexec/git-
core/git-add--interactive line 158.
Died at /usr/local/libexec/git-core/git-add--interactive line 158.
I see that what it's trying to do under the hood is:
git diff-index --cached --numstat --summary HEAD -- <7,000+ paths...>
Sure, we could divide the paths into smaller groups, run multiple
invocations of "git diff-index", and concatenate the results. But it
would be nicer if there was some other way that we could get at the
same information without having to pass 7,000 paths explicitly on the
command line; is there any which I am overlooking?
The enormous file list is the result of passing <path> into "git ls-
files -- <path>". Would it be worth:
- either, modifying "git diff-index" to accept a list of paths over
stdin so that we could at least pipe the output from "git ls-files"
into "git diff-index"
- or, preferably, teach "git diff index" to recurse into directories
rather than expect a list of paths-of-blobs (possibly with a command
line switch to activate the behaviour if it were deemed a dangerous
default)
This is one piece of plumbing that I've never dabbled with, so forgive
me if my questions are a little dumb.
Cheers,
Wincent
--
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