Re: b4: encouraging using the cover letter in merge commits?

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

> On Fri, Dec 18, 2020 at 10:32:11PM +0100, Toke Høiland-Jørgensen wrote:
>> I notice b4 will already save the cover letter along with the patch mbox
>> file, but maybe it would be possible to automate the workflow some more?
>> A 'b4 merge' command that wraps 'git merge' and pre-populates the commit
>> message with the text from the cover letter? Or some other trick? WDYT?
>
> I've been careful to operate on the "principle of least surprise," which is
> why I try not to make any changes to the git repository directly. B4 will use
> git commands, but in a way that don't modify the tree (only prepopulate
> objects behind the scenes, etc). For this reason, I'm wary of wrapping any
> git commands directly with b4.

Fair enough :)

> One way I can think of is to save the payload of the cover letter into the
> .cover file, if we recognize that we're in a git repository. Then, when
> performing the merge, you would run:
>
> git merge -F .cover --edit --log branchname
>
> This will preload the cover letter into the merge message and let you edit it
> before performing the merge.
>
> What do you think?

I think the above would work - just putting the text of the cover letter
(without the email headers and diffstat) into a file for easy inclusion
like you suggested would likely be helpful. I'd probably name it for the
branch, though (e.g., .cover.$BRANCH ?) so that it's possible to create
multiple branches, flip around between them, and still have the cover
file be there when merging later.

I played around with creating an alias for the merge command itself, and
while having to include the branch name in the filename rules out a
simple alias, just dropping a script like this into $PATH and naming it
"git-mergedesc":

#!/bin/bash
exec git merge -F .cover.$1 --edit "$@"

makes it possible to just run 'git mergedesc branch' and get the right
behaviour (although obviously a real script should be a bit smarter
about argument parsing and validation!).

-Toke