Re: [RFC/PATCH] Add test case for dealing with a tracked file in an ignored directory

quoted

+     mkdir ignored-dir &&
+     echo ignored-dir >> .gitignore &&
+     touch ignored-dir/file &&

I think >ignored-dir/file is more portable than touch, and is
recommanded in the testsuite. But a quick grep shows that touch is
already used.

Ok, sure.  I'll switch over to >ignored-dir/file.

quoted

+     test_must_fail git add ignored-dir/file >actual 2>&1 &&
+     test_cmp actual expect &&
+     git add -f ignored-dir/file &&
+     git add ignored-dir/file &&

(so, this is the first thing you're fixing, shouldn't be
controversial)

Hopefully not :).

quoted

+test_expect_success 'git add with ignored directory using git globs' "
+     mkdir ignored-dir2 && echo ignored-dir2 >> .gitignore && touch ignored-dir2/file &&
+     git add 'ignored-dir2/*' >actual 2>&1 &&
+     echo \"fatal: pathspec 'ignored-dir2/*' did not match any files\" | test_cmp - actual

Currently, "git add 'dir/*'" will add the files under dir/ if dir/
isn't ignored, and require -f if dir is ignored.

I don't think you want to complain with "did not match any files"
here.

Well, I copied the behavior of 'git add "*"' here, where every file in
. is ignored.  E.g.
"""
$ echo >ignore-file
$ echo .gitignore >>.gitignore
$ echo ignore-file >>.gitignore
$ git add '*'
fatal: pathspec '*' did not match any files
"""
One could reasonably choose to instead say "The following paths are
ignored by one of your .gitignore files: ...".  When I chose the "did
not match any files", I had been assuming that globbing works roughly
analogously to shell globbing, meaning the error one gets from a '*'
should be the same as that one gets from a 'dir/*' or '*/*'.  I
realized today that git globbing seems to act differently depending on
where the wildcard appears.  E.g.:
"""
$ mkdir a && echo >a/b
$ git add '*/*' # complains, doesn't stage any files
fatal: pathspec '*/*' did not match any files
$ git add 'a/*'
$ echo change >a/b
$ git add '*/*' # doesn't complain, but doesn't stage changes
$ git ls-files -m
a/b
"""
Is this a bug?  I looked for some docs on the globbing functionality,
but I didn't come across anything that specified it in detail.
Anyway, either way I still think consistency is ideal, and hence would
still vote for "did not match any files".  Thoughts?

quoted

+     git add -f ignored-dir2/file && echo change > ignored-dir2/file &&
+     git add 'ignored-dir2/*' >actual 2>&1 &&

Just making sure I'm reading correctly: this is the second thing that
should be fixed, and that your earlier patch didn't.

Yes, that's correct.  (Again, just trying to match functionality with
ignored files.)

You're not testing the case

 git add ignored-dir/

which gives another case where Git tries to add files not explicitely
given on the command-line. But the correct behavior of this case may
be more controversial, so maybe it's indeed better to focus on the
other cases.

A fair point.  I would have thought the behavior here should be
unchanged, namely that 'git add ignored-dir/' should spit out a "The
following paths are ignored by one of your .gitignore files: ..."
error, regardless of the directory's contents.  Does anyone believe
this should be different/would it be useful for me to draw up a test
case for it now?  In any case, I'll certainly put a test case for this
into the final patch.

Greg