Junio C Hamano, Tue, May 13, 2008 01:32:19 +0200: > Alex Riesen <raa.lkml@xxxxxxxxx> 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. -- 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
