I am skeptical of adding anything but a brief description of the change, the reason for the change and possibly some explanation of non-obvious implementation choices to the commit message.

The reason is that the commit message log serves as an overview of the changes commited. That's what humans use it for, anyway: to get an idea of what happened since they last pulled, to help give an idea of where a regression might have been introduced and so on, at a glance. To that end, brevity is very useful.

My understanding is that chatbots used to perform such tasks will also benefit from brevity.

▲

xg15 10 hours ago | parent [-]

Well, at least in Git, the commit message already has two sections.

AFAIK, the first line is supposed to be the a very brief summary, while the other lines may contain additional information and can sometimes make up a pretty long text. Lots of tools make use of this convention and only show the first line if no detail information is needed.

Most tools that show the history only show the first line of each commit.

But I agree with you, this still assumes that long commit messages are rare and not that almost every commit has a huge message. Also, "long" doesn't mean you should put a novel in there.

	▲	boomlinde 6 hours ago \| parent [-]
		I think long is fine if that's necessary to get a rough idea of what the change is about across. Discerning in the choice of what information to include is perhaps a better way to put it. In those terms we should consider how likely it is for prompts to be immediately useful information when browsing the commit history, and whether it can't instead be reduced to an informative summary. As far as specifications for changes go, the diff itself is as good a spec as it gets. It unambiguously describes the exact change that was made. The prompt you give a chatbot to make that change is IMO something else. Maybe it's more fair to call that a specification of the work you wanted it to perform.