All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	stable@vger.kernel.org, Sasha Levin <sashal@kernel.org>,
	Bart Van Assche <bvanassche@acm.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: handling Fixes tags on rebased trees
Date: Thu, 6 May 2021 11:49:57 +0200	[thread overview]
Message-ID: <YJO7xTZ6GKsvY3X4@kroah.com> (raw)
In-Reply-To: <20210506083905.GB1922@kadam>

On Thu, May 06, 2021 at 12:39:41PM +0300, Dan Carpenter wrote:
> It turns that rebasing without updating the Fixes tag is sort of common.
> I wrote a script to find the invalid tags from the last month and have
> include the output below.  Two of the patches are in -mm and presumably
> Andrew is going fold the Fixes commit into the original commit when
> these are sent upstream so those aren't a real issue.
> 
> We could probably try catching rebased trees when they are merged in
> linux-next?  I'll play with this and see if it works.  But we're going
> to end up missing some.  Maybe we need a file with a mapping of rebased
> hashes which has something like:
> 
> 28252e08649f 0df68ce4c26a ("iscv: Prepare ptdump for vm layout dynamic addresses")
> 42ae341756da d338ae6ff2d8 ("userfaultfd: add minor fault registration mode")

I thought Stephen's scripts already catch the "this commit isn't in the
tree" issue?  I use them when I take patches, so that logic came from
somewhere :)

thanks,

greg k-h

  reply	other threads:[~2021-05-06  9:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-04 18:46 need to back port ("scsi: ufs: Unlock on a couple error paths") Dan Carpenter
2021-05-04 20:07 ` Martin K. Petersen
2021-05-06  9:39   ` handling Fixes tags on rebased trees Dan Carpenter
2021-05-06  9:49     ` Greg KH [this message]
2021-05-05  7:55 ` need to back port ("scsi: ufs: Unlock on a couple error paths") Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YJO7xTZ6GKsvY3X4@kroah.com \
    --to=greg@kroah.com \
    --cc=akpm@linux-foundation.org \
    --cc=bvanassche@acm.org \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=sashal@kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.