On Fri, Jun 28, 2019 at 03:25:48PM -0700, Darrick J. Wong wrote:
> On Fri, Jun 28, 2019 at 10:23:10PM +0000, Luis Chamberlain wrote:
> > On Fri, Jun 28, 2019 at 03:19:14PM -0700, Darrick J. Wong wrote:
> > > On Fri, Jun 28, 2019 at 10:02:53PM +0000, Luis Chamberlain wrote:
> > > > On Thu, Jun 27, 2019 at 04:39:50PM +0200, Christoph Hellwig wrote:
> > > > > Properly allocate the space for the bio_vecs instead of just one byte
> > > > > per bio_vec.
> > > > >
> > > > > Fixes: 991fc1d2e65e ("xfs: use bios directly to write log buffers")
> > > >
> > > > I cannot find 991fc1d2e65e on Linus' tree, nor can I find the subject
> > > > name patch on Linus' tree. I'm probably missing some context here?
> > >
> > > This patch fixes a bug in for-next. :)
> >
> > I figured as much but the commit in question is not even on linux-next
> > for today, so I take it that line would be removed from the commit log?
>
> It looks like it is to me...
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20190628&id=991fc1d2e65e381fe8db9038d9a139d45c948f4f
Yes but commits on linux-next make no sense for Linus' tree, as they change
day to day, is my point. So if merged eventually as-is on Linus' tree,
someone looking at the git history would not find 991fc1d2e65e, and
could also throw errors on scripts which scrape for these tags. Yes,
they exist, and distros do use them to evaluate possible fixes.
In this case I think just referring to the subject would do it.
Unless it just so happens to be that what is on for-next *does* always
maintain the same commit IDs one it goes to Linus' tree? Does that
actually happen?
Luis
