* mm/gup: track FOLL_PIN squash-candidate patches are not squashed (yet?)
@ 2020-03-19 18:04 John Hubbard
2020-03-20 17:22 ` Vlastimil Babka
0 siblings, 1 reply; 4+ messages in thread
From: John Hubbard @ 2020-03-19 18:04 UTC (permalink / raw)
To: Andrew Morton; +Cc: Claudio Imbrenda, Linux MM
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.)
08baf249e844 mm-gup-track-foll_pin-pages-fix-2-fix <Andrew Morton>
10a9eb3afdf1 mm/gup: fixup for 9947ea2c1e608e32 "mm/gup: track FOLL_PIN pages" <Claudio Imbrenda>
b982245014e1 mm/gup: fixup for ce35133be382 mm/gup: track FOLL_PIN pages <John Hubbard>
3d37f4aceb31 mm/gup: track FOLL_PIN pages <John Hubbard>
thanks,
--
John Hubbard
NVIDIA
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: mm/gup: track FOLL_PIN squash-candidate patches are not squashed (yet?)
2020-03-19 18:04 mm/gup: track FOLL_PIN squash-candidate patches are not squashed (yet?) John Hubbard
@ 2020-03-20 17:22 ` Vlastimil Babka
2020-03-20 17:49 ` John Hubbard
0 siblings, 1 reply; 4+ messages in thread
From: Vlastimil Babka @ 2020-03-20 17:22 UTC (permalink / raw)
To: John Hubbard, Andrew Morton; +Cc: Claudio Imbrenda, Linux MM, Randy Dunlap
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?
> 08baf249e844 mm-gup-track-foll_pin-pages-fix-2-fix <Andrew Morton>
> 10a9eb3afdf1 mm/gup: fixup for 9947ea2c1e608e32 "mm/gup: track FOLL_PIN pages" <Claudio Imbrenda>
> b982245014e1 mm/gup: fixup for ce35133be382 mm/gup: track FOLL_PIN pages <John Hubbard>
> 3d37f4aceb31 mm/gup: track FOLL_PIN pages <John Hubbard>
>
>
>
> thanks,
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: mm/gup: track FOLL_PIN squash-candidate patches are not squashed (yet?)
2020-03-20 17:22 ` Vlastimil Babka
@ 2020-03-20 17:49 ` John Hubbard
2020-03-21 0:43 ` Andrew Morton
0 siblings, 1 reply; 4+ messages in thread
From: John Hubbard @ 2020-03-20 17:49 UTC (permalink / raw)
To: Vlastimil Babka, Andrew Morton; +Cc: Claudio Imbrenda, Linux MM, Randy Dunlap
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.
thanks,
--
John Hubbard
NVIDIA
>
>> 08baf249e844 mm-gup-track-foll_pin-pages-fix-2-fix <Andrew Morton>
>> 10a9eb3afdf1 mm/gup: fixup for 9947ea2c1e608e32 "mm/gup: track FOLL_PIN pages" <Claudio Imbrenda>
>> b982245014e1 mm/gup: fixup for ce35133be382 mm/gup: track FOLL_PIN pages <John Hubbard>
>> 3d37f4aceb31 mm/gup: track FOLL_PIN pages <John Hubbard>
>>
>>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: mm/gup: track FOLL_PIN squash-candidate patches are not squashed (yet?)
2020-03-20 17:49 ` John Hubbard
@ 2020-03-21 0:43 ` Andrew Morton
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Morton @ 2020-03-21 0:43 UTC (permalink / raw)
To: John Hubbard; +Cc: Vlastimil Babka, Claudio Imbrenda, Linux MM, Randy Dunlap
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-03-21 0:43 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-19 18:04 mm/gup: track FOLL_PIN squash-candidate patches are not squashed (yet?) John Hubbard
2020-03-20 17:22 ` Vlastimil Babka
2020-03-20 17:49 ` John Hubbard
2020-03-21 0:43 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).