Andreas Ericsson <ae@xxxxxx> writes: > Junio C Hamano wrote: >> The new configuration option apply.whitespace can take one of >> "warn", "error", "error-all", or "strip". When git-apply is run >> to apply the patch to the index, they are used as the default >> value if there is no command line --whitespace option. > > I would think "warn-all" would be the logical thing, since "error" > either breaks out early or prints all warnings before denying the > patch anyway. Actually there is some thinking behind why I did not do warn-all. I did consider it at first but rejected. * If you are a busy top echelon person but cares about tree cleanliness, --whitespace=error is good enough. The patch is rejected on WS basis whether it introduces one such trailing WS or hundreds. The patch is returned to the submitter and the tree remains clean. * --whitespace=warn-all, if existed, would apply the patch _anyway_, so if you notice you got warnings, and if that bothers you enough that you would want to do something about it, you will have to rewind the HEAD, fix up .dotest/patch and reapply. This means you are willing to clean up other peoples' patches. * But if you are that kind of person, --whitespace=error-all is a better choice for you. Your tree stays clean and you do not have to rewind. Instead, you get all the errors you can go through with your editor (e.g. Emacs users can use C-x `; I hope vim users have similar macros) and fix things. * --whitespace=warn would show some, but not all, so that you can continue while making a mental note to scold the patch submitter to be careful the next time. You chose "warn" to apply the patch anyway, so there is no point showing the full extent of damage -- the damage is already done to your tree. * --whitespace=strip is for people who care about cleanliness, who wants to be nice to the submitters, but not nice enough to educate them. They do not want to fix things by hand. Instead they have the tool to do the fixing for them. The last one is somewhat risky, and the output may need to be examined carefully depending on the contents (e.g. programming language) the project is dealing with. - : 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