On Thu, 2020-06-04 at 12:33 +0200, Julia Lawall wrote: > > On Thu, 4 Jun 2020, Joe Perches wrote: > > > On Thu, 2020-06-04 at 11:52 +0200, Julia Lawall wrote: > > > Should Fixes also be used when the change will make it hard to port other > > > fixes over it? > > > > If it's a logic defect or regression that's being fixed, > > shouldn't the logic defect or regression be fixed as > > reasonably soon as possible? > > Sure, but I recall seeing some patches that mentioned that the problem had > existed since the beginning of git. Of course, it should be rare.
git history goes back 15 years already. There are scant few bugs that old. There is a tree with even older history that Rob Landley still has here: https://landley.net/kdocs/fullhist/ It does make git blame research a bit easier for those rare and extremely old defects. > > The nature of the fix should ideally be optimal for > > backporting, but I believe that should not stop any > > consideration for the standalone fix itself. > > I'm not sure to follow this. I think it comes down to defects in current need to be fixed. Describing the base commit that is being fixed is useful for backporting. I believe it's not reasonable to ask the author of a fix to research how it could or should be backported. > Sometimes non-bug fixes that block > backporting a bug fix have to be backported as well. So the fixes would > again highlight the range of versions affected by the issue. Sure, but the non-bug fixes that may also need backporting to enable easy backports of the actual fix should not be described in the Fixes: <commit> as those are generally easily researched from a command like: $ git log <commit>.. <files in fix> by whoever needs to backport.
