Re: mm/gup: track FOLL_PIN squash-candidate patches are not squashed (yet?)

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 20 Mar 2020 10:49:53 -0700 John Hubbard <jhubbard@nvidia.com> wrote:

> On 3/20/20 10:22 AM, Vlastimil Babka wrote:
> > On 3/19/20 7:04 PM, John Hubbard wrote:
> >> Hi Andrew,
> >>
> >> I see the following commits in linux-next. I'm wondering if all is well, because
> >> I understood that these were all going to be squashed into the first commit
> >> (3d37f4aceb31), yes?
> >>
> >> (This is the first time I've participated in the "squash" aspect of linux-mm workflow,
> >> as you can probably tell.)
> > 
> > AFAIK Andrew (or his scripts) does the squashing only at the last moment before
> > sending patches to Linus. The mmotm import to -next could do it as well I guess,
> > but do you expect a benefit e.g. for bisects?
> 
> 
> Squashing would only help very slightly in this case, for bisects. That's because
> 08baf249e844 fixes a build warning. And I don't think it's necessary to do it any
> sooner than usual. I just thought it was accidentally overlooked, because I didn't
> know that the squashing is done at the last minute.
> 
> All is well, then.
> 

Yes, I like to have the whole history there for my final review before
sending upstream.

The bisection issue could be a hassle, but the various buildbots seem to
have figured out that if foo.patch is immediately followed by foo-fix.patch
then do the obvious thing.