SubmittingPatches: document how and why to submit regression fixes

[phil-blain]

See: https://lore.kernel.org/git/37DD13D4-FBE4-4DB7-85F5-824E850BA9AE@gmail.com/

Hi Junio,

> Le 9 nov. 2020 à 12:52, Junio C Hamano <***> a écrit :
> 
> Peter Kaestle <***> writes:
> 
>> This test case triggers a regression, which was introduced by
>> a62387b3fc9f5aeeb04a2db278121d33a9caafa7 in following setup:
> 
> Also, it probably is a better arrangement, after explaining how the
> current system does not work in the log message, to have the code
> fix in the same patch and add test to ensure the bug will stay
> fixed, in a single patch.  That way, you do not have to start with
> expect_failure and then flip the polarity to expect_success, which
> is a horrible style for reviewers to understand the code fix because
> the second "fix" step does not actually show the effect of what got
> fixed in the patch (the test change shows the flip of the polarity
> of the test plus only a few context lines and does not show what
> behaviour change the "fix" causes).

I had learned by browsing the list that this was the preferred way to
submit patches for bug fixes and regressions for this project, but I had
not yet read a good justification as to *why* it was preferred. 

Thanks for spelling it out; I think a quick paragraph about this somewhere
in SubmittingPatches would be a good addition for new contributors.

From: Junio C Hamano <***>

Philippe Blain <***> writes:

> Thanks for spelling it out; I think a quick paragraph about this somewhere
> in SubmittingPatches would be a good addition for new contributors.

Patches welcome ;-)