Re: [PATCH] Make the exit code of add_file_to_index actually useful
- From
Alex Riesen <raa.lkml@gmail.com>
- Date
- May 13, 2008, 06:00 UTC
- Message-ID
- <20080513060013.GA3622@steel.home>
- In-Reply-To
- <7vve1jw130.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Tue, May 13, 2008 01:32:19 +0200:
Show 21 quoted lines
> 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.