Re: b4 v0.8.0 is available

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Wed, Sep 01, 2021 at 04:48:05PM +0200, Vlastimil Babka wrote:
> > https://lore.kernel.org/lkml/20210617101910.13228-1-song.bao.hua@hisilicon.com/T/#t
> > 
> > 	Link: https://lore.kernel.org/r/20210617101910.13228-1-song.bao.hua@hisilicon.com
> > 		   attempting to guess base-commit...
> > 	 Base: tags/v5.13-rc1-284-gc485f7e9863c (exact match)
> 
> I don't know how exactly it works, but looks like it could
> still try a bit harder?

It's better, but it's not perfect. :)

>  Base: tags/v5.14-rc1-55-g00c85b6576d3 (best guess, 3/8 blobs matched)
>        git checkout -b 20210819_hannes_cmpxchg_org tags/v5.14-rc1-55-g00c85b6576d3
>        git am ./20210819_hannes_mm_kconfig_move_swap_and_slab_config_options_to_the_mm_section.mbx
> 
> 3/8 blobs matched means "git am" fails
> 
> The earliest commit where it succeeds isn't that far away, actually:
> git describe 2a03085ce887^
> v5.13-257-gf356aeacf7bb

It may apply to that tree, but the patch series in question is showing
different index values for the files being modified.  E.g., from the patch:

    diff --git a/mm/vmstat.c b/mm/vmstat.c
    index cccee36b289c..31aada15c571 100644

If we look at the mm/vmstat.c blob hash at the commit you listed
(v5.13-257-gf356aeacf7bb), we'll see that the file has a different index
there:

    $ git ls-tree v5.13-257-gf356aeacf7bb mm/vmstat.c
    100644 blob b0534e068166c4d4df5995a2830fe548f48886b7    mm/vmstat.c

If we look for the object with index cccee36b289c, we'll find that it last
existed on June 28:

    $ git log --pretty=oneline --since 2021-06-01 --until 2021-09-01 --find-object cccee36b289c --all
    28f836b6777b6f42dce068a40d83a891deaaca37 mm/page_alloc: split per cpu page lists and zone stats

June 28th is over 2 months ago, while by default we only look within 2 weeks
of the patch's sending date (otherwise it could be really, really slow). And,
in fact, if we widen the search to 60 days (2 months before the patch was sent
makes it June 19), we indeed find the exact match for this series:

	$ b4 am -o/tmp 20210819195533.211756-1-hannes@cmpxchg.org --guess-base --guess-lookback 60
    [...]

	 Link: https://lore.kernel.org/r/20210819195533.211756-1-hannes@cmpxchg.org
		   attempting to guess base-commit...
	 Base: tags/v5.13-11-g296e421767f3 (exact match)
		   git checkout -b 20210819_hannes_cmpxchg_org tags/v5.13-11-g296e421767f3
		   git am /tmp/20210819_hannes_mm_kconfig_move_swap_and_slab_config_options_to_the_mm_section.mbx

So, the tree with the perfect blob match is v5.13-11-g296e421767f3, and "git
am" indeed applies cleanly there.

I think the real question is why is someone sending a patch series that is
based on a 2-month old tree? :)

-K