Johannes Schindelin <johannes.schinde...@gmx.de> writes: > On Mon, 13 Mar 2017, Junio C Hamano wrote: > >> When a patch series is refactoring an existing function to be used >> in different codepaths, an existing issue inherited from the >> original code (e.g. perhaps an existing error checking that is >> looser than ideal) may have been OK in the original context (e.g. >> perhaps it died and refused to run until the user corrected the >> repository), and it still is OK in the codepath that uses the >> refactored building blocks to replace the original code, but it may >> not be acceptable to leave the issue in the original code when a new >> caller calls the refactored building block (e.g. perhaps the >> refactoring made it possible for a caller to ask the function not to >> die and instead act on different kinds of errors in different ways). > > In this case, ...
It becomes somewhat irritating when you get combative and defensive unnecessarily. We already established this case is OK two messages ago, I think. The above is only to make sure that people cannot take the "issues in the original is OK to leave outside the scope of a new series" in my message out of context and treat it as a general rule to justify their sloppy patches in the future. We need to see if issues inherited from the original is necessary to fix before refactoring even begins on case-by-case basis, seeing what the requirement of the new code that uses the refactored code. And the case-by-case thing we already did for _this_ case.
