Default commit-message for merge commits?

[BatmanAoD]

By default, when creating a merge commit, no description is created. This is somewhat unhelpful when that commit needs to be pushed to an upstream git repo, since commits without descriptions can't be pushed. Is there a way to configure a default message, preferably imitating Git's "merged branch [foo] into [bar]"?

[thoughtpolice]

Maybe we could have a single on/off configuration flag that means "do we automatically generate a message when we create commits with multiple parents." core.auto-merge-message = true or something?

Note that for the immediate moment, you should be able to do something like jj new -m 'merge commit: foo + bar' r1 r2 r3... to create a multi-parent merge and set the resulting message immediately.

[BatmanAoD]

Yes, an on/off config flag would be ideal. Thanks for the pointer about the positional args for new being parent commits; I haven't made any aliases yet but that would be a good one.

[amiryal]

This article on LWN.net is a good read on the subject of merge commit messages. Select quotes:

[…] Torvalds insists that each merge be properly explained. Merges are commits too, and their changelog should say why the merge is being done. It is easy to just accept the default message that Git creates when adding a merge commit, but the resulting commit will have no useful explanation, which is the equivalent of waving a large red flag for Torvalds to see. Unexplained merges thus have a high likelihood of generating one of those unwanted replies.

One way to determine whether a merge is needed is to explain the need for it; if the maintainer cannot write a changelog making the need for the merge clear, then perhaps the merge should not be done at all.

Take the time to write an actual commit message explaining why the merge was done. But, before that, take a moment to think about whether there actually is a reason to do the merge.

Whenever my teammates merge the trunk into their topic branch, I keep asking them why and quoting that last bit from the article.

So, going back on topic here, my point is that JJ has a better default than Git, since the automatic message in Git means more people neglect to think about the message and replace it with a better one, thus making it almost pure noise. If the default is empty, then every non-empty message must signal something.

[amiryal]

A bad choice of placeholder rev name A, looks like -A. It is meant to insert a new rev before A, to replace it as the merge junction between topicX, topicY and the rest of the line of work.

[amiryal]

It's important that the code being reviewed and tested matches what will actually be in the trunk once a pull request is merged

Reviewed — sure, reviewers may checkout the code with jj new featureBranch 'trunk()' in their own working copy and abandon it afterwards. Tested — yes, that is a good cause, but…

that alone is sufficient reason to keep branches up to date.

No, that is the job of the CI pipeline, and there is no reason to keep that merge commit in the feature branch forever. At this point, I feel I am tilting at windmills (not the first time I am having this argument this week), so maybe I shouldn’t have said anything.

[BatmanAoD]

I'm sympathetic to what you're saying, I just don't think it applies to every project or every team. In any of these situations, I'd agree that merge commits should have a specific reason to exist:

• in a large, well-structured project with minimal improper coupling and a very good CI setup
• on a team that almost exclusively uses rebases rather than merges to update feature branches
• on a project like the Linux kernel where every maintainer's fork is long-lived and they are not necessarily kept in sync by default (i.e. when pulls are truly intentional "pulls" and not just the expected outcome of every unit of work)

....but in my professional career, I haven't worked on any projects like that, and I can't think of a single time when writing a specific commit message to explain why a merge is happening at all (as opposed to how conflicts were resolved or whether any related changes had to be made to fix build or test issues caused by the merge) would have been beneficial to me or anyone else.

[joyously]

(as opposed to how conflicts were resolved or whether any related changes had to be made to fix build or test issues caused by the merge)

I don't know that much about Git, but with Breezy, a merge is not a commit. That means you can resolve conflicts and test before doing the normal commit with a normal message about what is in it. I'm not sure how that applies to jj where everything is committed.

[BatmanAoD]

In git and jj, merges are commits.