>> + 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. >> + 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 :). >> +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? >> + 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 -- 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