It's not so much "clean history" that's the desire. It's "don't leave
landmines for git bisect".

On Thu., Dec. 3, 2020, 08:58 James Bottomley, <
James.Bottomley@hansenpartnership.com> wrote:

> On Thu, 2020-12-03 at 00:43 +0100, Vlastimil Babka wrote:
> > Hi,
> >
> > there was a bit of debate on Twitter about this, so I thought I would
> > bring it here. Imagine a scenario where patch sits as a commit in
> > -next and there's a bug report or fix, possibly by a bot or with some
> > static analysis. The maintainer decides to fold it into the original
> > patch, which makes sense for e.g. bisectability. But there seem to be
> > no clear rules about attribution in this case, which looks like there
> > should be, probably in
> > Documentation/maintainer/modifying-patches.rst
> >
> > The original bug fix might include a From: $author, a Reported-by:
> > (e.g. syzbot), Fixes: $next-commit, some tag such as Addresses-
> > Coverity: to credit the static analysis tool, and an SoB. After
> > folding, all that's left might be a line as "include fix from
> > $author" in the SoB area. This is a loss of metadata/attribution just
> > due to folding, and might make contributors unhappy. Had they sent
> > the fix after the original commit was mainline and immutable, all
> > the info above would "survive" in the form of new commit.
>
> It has been the case since forever that discussion which improves an
> uncommitted patch is only captured in email (which now may be preserved
> in a link tag).  Patch updates that come in after the patch is
> committed get their own commit.  We've tried to move people away from
> counting commits as an indicator of upstream eminence, but it's still a
> fact of life that this is what matters to a lot of open source
> community managers.  The tension we have is between liking a clean
> commit in the tree as opposed to a sequence of commits tracking the
> evolution of the patch and this community manager desire to track
> patches.
>
> So there are two embedded questions here: firstly, should we be as
> wedded to clean history as we are, because showing the evolution would
> simply solve this?  Secondly, if we are agreed on clean history, how
> can we make engagement via email as important as engagement via commit
> for the community managers so the Link tag is enough?  I've got to say
> I think trying to add tags to recognize patch evolution is a mistake
> and we instead investigate one of the two proposals above.
>
> James
>
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>