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

[Jeff King <peff@peff.net>]

On Tue, Jan 05, 2010 at 01:34:32PM +0100, Wincent Colaiuta wrote:

> >but note that the pathspecs given to ls-files and the path limiters
> >given to diff are not quite the same. So "git add -i '*.c'" will
> >currently find "subdir/foo.c", but would not with the above patch. Is
> >that what you meant when you said "recurse into directories"?
> 
> In my relative ignorance of the finer details here, I meant that I
> would want "diff-index" to give us the exact same set of blobs as we
> get from "ls-files", so as to fix the error without modifying the
> user visible behavior.
> 
> As I said, I personally wouldn't be impacted by the change in
> behavior that your patch produces, but maybe others might.

I also don't care about the globbing feature, though I suppose some
people do. However, I'm not sure add's behavior is all that sensible
now. Interactive add respects the globs, but regular add does not.
Worse, it seems that it notes that the pathspec is a wildcard and does
not even flag an error for failing to find any files. For example:

  $ git init
  $ echo content >foo.c
  $ mkdir subdir && echo content >subdir/bar.c
  $ git add .
  $ echo change >foo.c && echo change >subdir/bar.c
  $ git diff --name-only
  foo.c
  subdir/bar.c
  $ git add foobar ;# should barf, and does
  fatal: pathspec 'foobar' did not match any files
  $ git add '*.c' ;# does not barf, but does not respect wildcard
  $ git diff --name-only
  foo.c
  subdir/bar.c
  $ yes | git add -p '*.c' ;# respects glob
  $ git diff --name-only ;# empty

So it's an consistency that should probably be fixed. And of course it
is tempting to fix it by disabling the globs for the interactive case,
which would not involve writing any new code. ;) But I don't think it is
a good idea to punish people by taking away their feature in the name of
consistency.

-Peff