b4 v0.8.0 is available

b4 v0.8.0 is available

[Konstantin Ryabitsev]

Hello, all:

A new version of b4 is available that adds functionality to better work with
newer public-inbox features available on lore.kernel.org. There aren't many
new features compared to version 0.7.y, but everyone is encouraged to upgrade.

If you installed from pypi, just do:

    pip install --upgrade b4

If you're using b4 straight from a checkout, you can switch to branch-0.8.y
and run "git submodule update" to pull in the latest patatt updates.

Other than lore.kernel.org compatibility changes, the only significant
difference with version 0.7.3 is the --guess-base code, which should be a lot
more useful with this release. E.g. this message back from June is
successfully resolved to match the commit without any conflicts (gc485f7e98):

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)
 
(The usual caveat here is that this kind of guessing is not a guarantee that
the patch actually belongs at this commit -- merely that it applies without
conflicts there. For example, a patch may depend on newer/older code changes
in the files not touched by this particular patch/series. This is why it is
really important to provide base-commit: information in your patches, if
possible.)

Please report any bugs and regressions, as usual.

Best regards,
Konstantin

Re: b4 v0.8.0 is available

[Vlastimil Babka]

On 9/1/21 16:16, Konstantin Ryabitsev wrote:
> Other than lore.kernel.org compatibility changes, the only significant
> difference with version 0.7.3 is the --guess-base code, which should be a lot
> more useful with this release. E.g. this message back from June is
> successfully resolved to match the commit without any conflicts (gc485f7e98):
> 
> 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?

b4 am --guess-base 20210819195533.211756-1-hannes@cmpxchg.org

...

Link: https://lore.kernel.org/r/20210819195533.211756-1-hannes@cmpxchg.org
       attempting to guess base-commit...
 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

Thanks,
Vlastimil

Re: b4 v0.8.0 is available

[Konstantin Ryabitsev]

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

Re: b4 v0.8.0 is available

[Vlastimil Babka]

On 9/1/21 8:02 PM, Konstantin Ryabitsev wrote:
> On Wed, Sep 01, 2021 at 04:48:05PM +0200, Vlastimil Babka wrote:
>> 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

Oh, so that's how it works, thanks.

> 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,

I see. Too bad the search isn't faster, as it seems to know exactly what
to look for, but I guess that's how git works and indexes things.

> 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

Thanks, will keep that --guess-lookback param in mind.

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

Right :) The age also caused other issues so the author already promised
to rebase for v2.

Thanks!