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

[Alex Riesen <raa.lkml@gmail.com>]

Junio C Hamano, Tue, May 13, 2008 01:32:19 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
> 
> > Junio C Hamano, Tue, May 13, 2008 00:19:42 +0200:
> > ...
> >> 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?
> >
> > No, I don't think so. Consider "git add dir/". It is _not_ 1 (one)
> > operation. It is many operations (add every file in the "dir/"). Why
> > should all of them be considered failed just because the third file
> > from the bottom could not be read (and the user may have not even seen
> > it, because it wasn't there before, like a temporary file from Excel).
> > And for a user (for me, at least) "git add" is an intermediate
> > operation anyway...
> 
> Ah, Ok, I was overly cautious, and the worry is unfounded, as long as you
> do not trigger this "ignore" thing upon "git commit -a".

Yes, builtin-commit.c explicitely keeps its behaviour: the 0 in flags
argument makes sure die() is called. "Ignore errors" must be requested
with ADD_FILES_IGNORE_ERRORS.