Jeff King schrieb am 21.11.2014 um 19:01: > On Fri, Nov 21, 2014 at 05:08:19PM +0100, Michael J Gruber wrote: > >> "git add foo bar" adds neither foo nor bar when bar is ignored, but dies >> to let the user recheck their command invocation. This becomes less >> helpful when "git add foo.*" is subject to shell expansion and some of >> the expanded files are ignored. >> >> "git add --ignore-errors" is supposed to ignore errors when indexing >> some files and adds the others. It does ignore errors from actual >> indexing attempts, but does not ignore the error "file is ignored" as >> outlined above. This is unexpected. >> >> Change "git add foo bar" to add foo when bar is ignored, but issue >> a warning and return a failure code as before the change. >> >> That is, in the case of trying to add ignored files we now act the same >> way (with or without "--ignore-errors") in which we act for more >> severe indexing errors when "--ignore-errors" is specified. > > Thanks, this looks pretty good to me. I agree with Junio's sense that we > should cook it extra long to give people time to react. > >> My sincere thanks go out to Jeff without whom I could not possibly >> have come up with a patch like this :) > > :) Sorry if I was being obnoxious before. Sometimes contributors need a > gentle push to keep going, but I should know by now that you are not > such a person. We were just having fun with each other ;) >> diff --git a/t/t3700-add.sh b/t/t3700-add.sh >> index fe274e2..f7ff1f5 100755 >> --- a/t/t3700-add.sh >> +++ b/t/t3700-add.sh >> @@ -91,6 +91,13 @@ test_expect_success 'error out when attempting to add ignored ones without -f' ' >> ! (git ls-files | grep "\\.ig") >> ' >> >> +test_expect_success 'error out when attempting to add ignored ones but add others' ' >> + touch a.if && >> + test_must_fail git add a.?? && >> + ! (git ls-files | grep "\\.ig") && >> + (git ls-files | grep a.if) >> +' > > I am somewhat allergic to pipes in our test suite, because they can mask > errors (especially with a negated grep, because we do not know if they > correctly produced any output at all). But I guess this is matching the > surrounding code, and it is quite unlikely for `ls-files` to fail in any > meaningful way here. So I think it's fine. > > -Peff > I do prefer test_cmp myself, also because it tells you much more in case of a broken test - a failed boolean chain doesn't even tell you where it broke. In this specific case, many more tests would need to be rewriten, though, so I preferred to keep the style of the surrounding code. Michael -- 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