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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Sep 21, 2021 at 04:25:26PM -0400, Konstantin Ryabitsev wrote:
> Hi, all:
> 
> The current master branch landed a new feature that implements a new
> subcommand "shazam". It is the functional equivalent of piping "b4 am" to "git
> am", with some extra safety padding.
> 
> See "b4 shazam --help" to see the available options. You will notice that many
> of them are exactly the same as for "b4 am".
> 
> The default operation still tries to be the safest possible:
> 
> - we'll create a temporary sparse worktree that will only contain the files
>   being modified
> - we'll use the base-commit sha, if we find it, or we'll try to guess the base
>   commit from git index info
> - we'll run "git am" against that temporary worktree
> - if successful, we'll fetch from the worktree into your current repo and
>   delete the temporary sparse checkout
> - you can then "git checkout -b foo FETCH_HEAD" or "git merge FETCH_HEAD"
>   or "git rebase" as necessary

Does it prep the merge message too? ie pull in the text from the cover
letter, make the ==== markers/etc? (ie look what davem does:
d1bf73387b5adbc12c6a59c1fbaa69e05ee265ed)

> Alternatively, if you run "git shazam -A", we'll just run "git am" on the
> current HEAD, which is the exact equivalent of "b4 am -o- | git am".

It might be interesting to detect which to do based on what the
submitter has done.. No useful base-commit = no merge?

I'm generally of the feeling that git is a VCS and it is completely
fine for a tool to do whatever to the tree because I can quickly undo
it. So I think b4 is possibly overly cautious here :)

> If the default operation with getting things ready in FETCH_HEAD is not
> useful, please let me know how you would prefer to see things work instead.

I would be nice to have some process guidance when maintainers should
be using merges and when am'd patches..

Jason