On Thu, 2018-11-01 at 13:55 +0000, Lorenzo Pieralisi wrote: > On Wed, Oct 31, 2018 at 07:49:59PM +0000, Trent Piepho wrote: > > This fixes a regression introduced in merge 562df5c8521e. > > A merge being a commits collection, the regression was certainly > introduced by a specific commit in it, not the merge itself. In this case it really is merge commit. While the problem and fix are relatively obvious, finding how it came to be broken was a challenge. Most of the commit message is my proof that this is a bug and not something done intentionally, by tracking back the complicated route that caused the code to be in its current state. Basically there are two commits, on both branches of the merge, neither of which caused a problem nor were they incorrect in any way at the time they were committed. When that merge combined this collection of multiple commits, it did not do so correctly and that is the point a bug appeared. Or put another way, this problem was already fixed some time ago, but in the merge commit the fix was dropped. It seems like the proper way to attribute my fix is to the merge, as that is what caused the regression. There is no prior commit where one can observe the regression. > Also for the Fixes: tag and all references. Would it be ok to refer to the commit this way the first time, then use a shortened method for subsequent usages? Otherwise talking about two commits becomes very long. This it what I have mostly done, other than the "Fixes" line. I'm surprised checkpatch didn't catch that.
