Re: [PATCH] Make the exit code of add_file_to_index actually useful

Alex Riesen [off-list ref] writes:

quoted

Why is this even needed to begin with?  I am aware of Dirk's original
issue discussed elsewhere, but we try fairly hard to be A-O-N when we can
afford to, and this option deliberately breaks it.  What is the real
reason why such an unreadable (either for privilege or for I/O error)
file should not live in .gitignore?

Another program keeps the file open. There is an exclusive mode for
opening files, which locks the files for everyone. I believe it is
even default mode, unless selected otherwise.

I would understand there can be some files that cannot be read.  But when
there is such a file, why is it Ok to ignore an error to update the
contents from that file if/when the user asks to index the current
contents, provided if the contents of that file is to be tracked?  Isn't
it the true cause of the problem that the file is being tracked but it
shouldn't?

quoted

Now when somebody either forgets to check the return value from this
function, or deliberately ignores it, the resulting index will not match
what the code is told to update it with.

I think I got them all in the current code...

Not checking the return code from this function that now diagnoses and
returns error code is a bug as you said, and the codebase after your patch
may not have that bug.

But mistakes happen.

That is why I am asking why it is Ok to sometimes ignore the error to
begin with.  If we do not need to ignore this condition, then new callers
have one less thing to worry about, and we would have one less cause of an
unnecessary bug.