> > I might wish that your merge commit messages were a bit more
> > consistent about the merge details ("why and what"), but you are most
> > definitely not the only one with that, and a number of them are quite
> > nice (ie the merge of the large extent counters has a nice informative
> > commit message, as does the rmap speedup one).
>
> Those one came from pull requests with informative signed
> tags. We're trying to move more of our development processes to
> using signed pull reqs when eveything is done, so this hopefully
> will happen more often.
>
> > And then some of them are the uninformative one-lines that just say
> > "Merge branch X"
>
> Yeah, those are merges from local topic branches where I pulled in
> individual patches or entire series from the mailing list via 'b4 am
> -o - <msg_id> | git am -s'. AFAICT there is no way to have this
> retain the patch series cover letter, which generally contains what
> I would want to be putting into the merge commit message.
>
> I'll keep that in mind for future composes, though I do wish there
> was an easy way to just have b4/git manage cover letters as part of
> the topic branch so they can feed into local merge commits just as
> easily remote pulls do....
>
There is.
I have been hacking on b4 and found many hidden features :)
b4 am 20220510202800.40339-1-catherine.hoang@xxxxxxxxxx -n
xfs-5.19-quota-warn-remove.mbx
git am -s xfs-5.19-quota-warn-remove.mbx
git tag -F xfs-5.19-quota-warn-remove.cover xfs-5.19-quota-warn-remove
Konstantine has added the "b4 shazam" combo recently for
'b4 am -o - <msg_id> | git am -s'
The shazam command is not well documented, so most info can be found in
the git log, but that seems like it might be a good place to add an auto tagging
feature. It will also help to include a link to lore in the "topic
tag" to make it
easier for people to get to the developer discussions on the topic.
My dream is that all linux pull requests will have links to lore patch series.
Below is an example output of a gadget I created [1] to help maintainers
and git archaeologists to generate those links automatically from PRs
(pre or post merge).
The gadget is far from perfect, it still has some rough edges, but it fits my
needs so far.
If folks are interested, you are welcome to try it out and provide me
feedback so I can get it in shape for upstream b4.
But the tool won't be needed for maintainers that work with topic
branches if each internal topic merge contains a link to the lore thread
the topic was applied from.
Thanks,
Amir.
[1] https://github.com/amir73il/b4/commits/release-notes
This example analyses a range of commits that did not originate
from a single patch series to demonstrate how an analysis of
PR topics looks like:
$ git show 1499b8a3a37b
commit 1499b8a3a37baf5a78ee8044e9a8fa0471268d74
Merge: 9a5280b312e2 2d9ac4319b99
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu Apr 21 11:40:17 2022 +1000
Merge branch 'guilt/5.19-miscellaneous' into xfs-5.19-for-next
$ git format-patch 1499b8a3a37b^..1499b8a3a37b^2 --stdout | b4 rn -m - 2>rn.log
---
- [PATH ?/?] xfs: Simplify XFS logging methods.
- [PATCHSET v2 0/3] xfs: fix corruption of free rt extent count
[https://lore.kernel.org/r/164961485474.70555.18228016043917319266.stgit@magnolia]
Tests: xfs/141
- [PATH ?/?] xfs: Add XFS messages to printk index
- [PATCH] xfs: Use generic_file_open()
[https://lore.kernel.org/r/20220409155220.2573777-1-willy@xxxxxxxxxxxxx]
- [PATH ?/?] xfs: simplify local variable assignment in file write code
---
