Jan Durovec <[email protected]> writes: > On Tue, Apr 19, 2016 at 7:47 PM, Junio C Hamano <[email protected]> wrote: >> >> If you really want to know the preference, we prefer a preliminary >> clean-up patch to correct existing style issues, followed by a new >> feature patch that builds on the cleaned up codebase. > > Would it be acceptable the other way around? I.e. this patch followed > by the one that fixes code style (once this gets merged)?
The reason I said "preference" and not "requirement" is because the answer to that question is "It depends." When the primary change is something small and urgent (e.g. an important bugfix that needs to be merged down to 'maint' and older), we typically do not want to keep the fix waiting for preliminary clean-up patch to be reviewed. Instead, we'd say "let's fix it first on top of a known-to-be-crappy codebase, and postpone the clean-up until the dust settles". >From experience, we already know that sometimes clean-up happens, but often it does not, when we take this route, and it harms the long-term code health, but we just say an urgent fix is more important than piling a bit more cruft on the existing technical debt. And that experience is why we say "preference is to have preliminary clean-up first". > Reason being that I don't know how to use submitGit to generate a patch > against a state that is not already in git repo (ie. based on another > patch). Any submitGit users? I think it lets you throw multiple-patch series just fine. In this case, you'd prepare a two patch series on a branch, 1/2 being the clean-up and 2/2 being the new feature, and if you give that branch to submitGit as a whole it should do the right thing, I'd imagine. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
