Re: b4 submit ready for beta testing

[Mattijs Korpershoek <mkorpershoek@baylibre.com>]

Hi Konstantin,

First of all, thank you for this.
As an occasional kernel contributor I struggle with the current workflow.
I've never properly spend time automating any of this so I appreciate
the "b4 submit" initiative.

I think I've found a bug in the patch ordering result from
'b4 submit --send -o' or 'b4 submit --send --dry-run'.

The patch order is reverted when comparing with a classic "git format
patch" result.

Please find details below.

On Sat, Jul 16, 2022 at 10:29, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

> Hello, all:
>
> I've committed the initial b4-submit features to the master branch, and I
> need some volunteers to test it. If you routinely send patches to the Linux
> kernel mailing lists, then I hope that volunteer is you. :)
>
> ## What it does
>
> The goal behind "b4 submit" is simplifying the submitter's workflow by
> automating away a lot of menial tasks, such as creating cover letters,
> collecting trailers, rerolling new revisions, remembering all the flags to
> git-format-patch and git-send-email, etc. The main workflow can be described
> like this:
>
> 1. b4 submit --new my-new-feature [-f v5.19-rc6]
>
> This will create a new branch called "b4/my-new-feature". If -f is not
> specified, the branch will be created from the current HEAD (but this is
> rarely what you want, so you'll want to pick a tag to work from).
>
> After the branch is created, b4 will create an empty commit that will serve to
> store the cover letter contents and some tracking information. You can view
> the raw commit with "git log" just like any other commit, and you can even
> edit it with "git rebase" but it's not recommended. It's much better to use
> "b4 submit --edit-cover".
>
> 2. b4 submit --edit-cover
>
> This allows you to work on the cover letter using $EDITOR or core.editor
> as defined in git-config. Once the editing is complete, the empty commit will
> be updated and the entire branch rebased using git-filter-repo.
>
> 3. use regular git operations for the rest of your work
>
> You can apply, rebase, edit, squash, etc -- just avoid touching the cover
> letter commit. You can also push the b4/my-new-feature branch to any remote
> and pull it from anywhere else if you want to switch computers.
>
> 4. b4 submit --send
>
> When you are ready to send off your series, you can review the resulting
> patches by running:
>
>   b4 submit --send --dry-run
>
> or
>
>   b4 submit --send -o /tmp/somedir

revision of b4:
 41cded9122f2 ("submit: store tracking info in the cover letter header")

git submodule status:
 0eb41be65707a1e156a59fd25ea9824c1a9e95ce patatt (v0.5.0-1-g0eb41be65707)


Steps to reproduce:

## prepare branch/work
$ b4 submit --new patch-ordering -f next-20220718
$ b4 submit --edit-cover # to remove EDITME and be able to use --dry-run/-o
$ touch oldest_file && git add oldest_file && git commit -s -m "oldest commit"
$ touch new_file && git add new_file && git commit -s -m "newer commit"
$ touch newest_file && git add newest_file && git commit -s -m "newest commit"

## this gives the following git log:
$ git log --oneline --no-decorate next-20220718..HEAD
d229ef49d3e9 newest commit
5eca0029017f newer commit
3e53e24f818e oldest commit
c48ebb144244 cover title for patch-ordering

## and is ordered as following with git format-patch:
$ mkdir format-patch
$ git format-patch -o format-patch next-20220718..HEAD
format-patch/0001-cover-title-for-patch-ordering.patch
format-patch/0002-oldest-commit.patch
format-patch/0003-newer-commit.patch
format-patch/0004-newest-commit.patch

## using b4 submit -o, we see that the order is not the same:
$ mkdir b4-submit
$ b4 submit --send --no-sign -o b4-submit 
Converted the branch to 3 patches
Populating the To: and Cc: fields with automatically collected addresses
  0000-cover-title-for-patch-ordering.patch
  0001-newest-commit.patch
  0002-newer-commit.patch
  0003-oldest-commit.patch

Is this the expected behaviour ?
To me, it seems that git format-patch gives the right order.

Thanks,
Mattijs

>
> The first will print out the patches to send on stdout, exactly as they would
> be fed to the SMTP server, and the second will output the patches into the
> specified directory a-la git-format-patch -- useful for running "checkpatch"
> or any other checks, as necessary.
>
> When you are satisfied that the patches are looking sane, you can fire off the
> actual --send command.
>
> NOTE: when we find a scripts/get_maintainer.pl in the repo toplevel, we will
> automatically run the most-recommended (that I could find) combination of
> flags to automatically populate the To: and Cc: list in addition to whatever
> we get out of the cover letter and commit trailers. You can turn this off with
> --no-auto-to-cc.
>
> NOTE: at this time, a working SMTP server and a valid [sendemail] section are
> required for sending patches. The web submission endpoint work is not yet
> completed.
>
> 5. b4 submit --reroll
>
> After you send your series and when you're ready to start working on a new
> revision, you'll want to --reroll to increment your tracked version. This will
> automatically update the cover letter commit to add a "Changes in v[N]"
> section that will also contain a link to the v[N-1] series, creating a
> historical breadcrumb of revisions.
>
> 6. b4 submit --update-trailers [--signoff]
>
> As you receive feedback on your patches, you can retrieve any received
> trailers from lore.kernel.org and apply them directly to your branch. This is
> accomplished by retrieving any threads matching the unique "change-id"
> submitted as part of the cover letter.
>
> One thing to keep in mind here is that actual trailer matching is done by
> comparing the patch-id (see git-patch-id for details). This has the following
> important bonuses and caveats:
>
>   - You can rearrange patches or modify summaries without it affecting the
>     match.
>   - If you modify actual code (even as much as fixing a typo in a string), any
>     received trailers will no longer match. This is as designed, because if
>     you change the code, it's no longer reviewed (but we won't remove any
>     existing trailers that were already applied).
>   - when you use --signoff, this will move your own "Signed-off-by" trailer
>     below any other trailers in all series commits, which is commonly
>     recommended for the chain-of-custody purposes.
>
> 7. b4 submit --send
>
> GOTO 4.
>
> In addition to the above, please see "b4 submit --help" for other flags you
> can use with these operations.
>
> ### Editing the cover letter commit manually
>
> If you ever need to edit the cover letter commit manually (e.g. to fix
> something about the tracking section json), you can use regular "git rebase
> -i" with the "reword" action. When rebase bails complaining about the empty
> commit, just run "git commit --amend --allow-empty" to edit the cover letter
> and then "git rebase --continue".
>
> Again, this is not recommended and it's best to always use "b4 submit
> --edit-cover".
>
> ## Getting the b4 dev version
>
> To install the b4 development version, you will need to run it from the git
> checkout:
>
>   git clone https://git.kernel.org/pub/scm/utils/b4/b4.git
>   cd b4
>   git submodule update --init
>   alias b4="$PWD/b4.sh"
>
> You can find out more details in the README file. You will also want to make
> sure that git-filter-repo is installed (either from your distro packages or
> from pip).
>
> If you're already running b4 from the git checkout, make sure you run "git
> submodule update" to pull in the latest unreleased patatt version.
>
> ## Feedback
>
> I hope you have a positive experience using b4 submit. I will be happy to
> receive any feedback, as I have to make a lot of assumptions and they aren't
> always the right ones. :) The best place for this feedback is on the
> tools@linux.kernel.org list.
>
> Best regards,
> Konstantin