"git add -i" with path gives "Argument list too long"

Back in January I reported a wart in "git add -i" and discussion kind of petered out and I forgot about the bug until today when I ran into it again. Now I have a few more cycles to burn I have the time to sort it out.

Just to revise what was discussed back in January:

- my original report: http://lists-archives.org/git/708569-git-add-i-with-path-gives-argument-list-too-long.html

- quick and easy fix posted by Jeff King: http://lists-archives.org/git/708591-git-add-i-with-path-gives-argument-list-too-long.html

- notes on inconsistencies between "git add" and "git add -i" by Jeff king: http://lists-archives.org/git/708698-git-add-i-with-path-gives-argument-list-too-long.html

To summarize and expand a bit upon what Jeff noted in that last post:

  - given _tracked_ file "foo.c" and _untracked_ file "bar.c"
  - "git add '*.c'" ignores the tracked file and stages the untracked file
  - "git add -i '*.c'" ignores the untracked file and operates on the tracked file

So, I gather that we can agree that this behavior isn't right. Either we treat the arguments as pathspecs or we don't, but it doesn't seem right to do one thing for tracked files and another for untracked ones, and it seems especially wrong for the differential treatment to apply in one direction with "git add" and in the other with "git add -i".

So, as a first step I'd like to make some test cases to serve as a specification for what we want the desired behavior to be. I saw in one of the "what's cooking messages" in February that there was some changes cooking in the "cp/add-u-pathspec" topic, so I am not entirely clear on if there is consensus about the desired behaviour.

Before I run ahead and start writing test, do we have consensus?

(Will have to worry about the initial cause of my bug report -- the "argument list too long" error -- later on.)

Cheers, Wincent