On Thursday 13 August 2009 02:38:57 pm Junio C Hamano wrote: > Luke Dashjr <luke-jr+git@xxxxxxxxxxx> writes: > > Unmatched files are errors, and should be ignored with the rest of them. > > Why is this a "fix"? > > I would understand if it were "Make --ignore-errors imply --ignore-unmatch > unconditionally". But then I do not think I would necessarily agree it is > a good change. > > The user may know that some files in the work tree are unreadable and > cannot be indexed (hence he gives --ignore-errors) but he still may want > to catch a typo on the command line. > > I do not think it is wise to make --ignore-errors imply --ignore-unmatch > unconditionally like this patch does without any escape hatch. Are unmatched files not errors? Perhaps the old flag should be renamed to --ignore-read-errors and a new --ignore-errors that implies both added. Or maybe just a documentation change to preserve compatibility with anything that might assume that... -- 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