Re: [PATCHv2] add: ignore only ignored files

[Michael J Gruber <git@drmicha.warpmail.net>]

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