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

From: Jeff King <peff@peff.net>
Date: Mar 22, 2010, 00:39 UTC
Message-ID: <20100322003915.GA3212@coredump.intra.peff.net>
In-Reply-To: <45CD9D1B-6774-46F2-A444-654B1DEF7F69@wincent.com>

On Sun, Mar 21, 2010 at 09:52:56PM +0100, Wincent Colaiuta wrote:

> 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.

Thanks for following up.

Show 9 quoted lines

> 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, 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

I'm pretty sure the behavior that we want eventually is for both the diff family (including diff-files), and "git add" to learn about the globbing pathspecs that ls-files uses. That will make "git add" and "git add -i" consistent, and once diff-files understands it, we can drop the call to ls-files in add--interactive, which will solve your "argument list too long" problem.

And yes, I am being intentionally vague about the behavior beyond saying "do what ls-files does". Personally I am not too familiar with the globbing pathspecs, so I am not qualified to give an exhaustive list of their behavior. Junio could probably say more, or you will have to read the code.

-Peff