Re: b4: introducing b4 shazam (like b4 am -o- | git am)

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Tue, Sep 28, 2021 at 02:46:53PM -0300, Jason Gunthorpe wrote:
> > We could, theoretically, do that, but you'd have to remember to pass the -F
> > much free-form and there isn't a sane approach we can take to automatically
> > generate good merge commit messages from them, short of quoting them fully,
> > which will be overkill 9 times out of 10.
> 
> Since the user would be expected to revise it, I think that is
> fine. Just make the template and push in the raw text and let people
> edit. It would still save a bunch of time

Okay, I implemented something that should be handy. When we find a cover
letter, we will prepare it as a template merge message in .git/b4-cover, so
you can do stuff like:

git merge -F .git/b4-cover --edit FETCH_HEAD

I will eventually make the template configurable, but for now it's hardcoded
to the following format (using a sample I've been working with):

    Merge patches from https://lore.kernel.org/r/20210929143600.49379-1-david@redhat.com

    Accept 6 patches from David Hildenbrand <david@redhat.com>

    mm/memory_hotplug: Kconfig and 32 bit cleanups
    ==============================================
    Some cleanups around CONFIG_MEMORY_HOTPLUG, including removing 32 bit
    leftovers of memory hotplug support.

    Compile-tested on various architectures, quickly tested memory hotplug
    on x86-64.
    ==============================================
    Link: https://lore.kernel.org/r/20210929143600.49379-1-david@redhat.com

Note, that this is after deleting a bunch of stuff during the --edit stage, as
we reuse everything that's not a signature.

This change is in the latest master.

> Linus has been repeatedly against working on random git history
> points, so I think the unreliable auto-base is not something people
> should be using.

I see. But if they do send a base-commit: line from some place random, is that
okay to accept it?

> It should only check a set of safe commits (like rc releases and the
> maintainer's work-in-progress) and everything else should be a
> failure..

I'll see if I can have a --tags-only mode for guessing base.

-K