I have completely opposite opinion on this.

Writing commit messages is one of these mundane chores I’d gladly delegate to LLMs which are very very good at this kind of thing.

I mean, if you really know you code, you know it, there is no much value in reinforcing it in your head one more time via writing comprehensive commit messages - it’s a waste of time, imho.

▲

kace91 9 hours ago | parent | next [-]

Neither the code nor the AI know WHY a commit it being made.

This context should at the very least be linked.

▲

salomonk_mur 9 hours ago | parent [-]

Man, 99% of non-bug-fix commits don't have a why other than "advance the current task".

Almost all commits live in tandem with some large feature or change being made. The reason for absolutely all of them is the same - build the thing .

	▲	kace91 9 hours ago \| parent \| next [-]
		>other than "advance the current task" How do you expect someone to know what “the current task” was when they’re tracking down a bug 2 years down the line?
	▲	crabmusket 9 hours ago \| parent \| prev \| next [-]
		Then write that and link to the current task. That's the why. You don't need an LLM for that.
	▲	merelysounds 4 hours ago \| parent \| prev [-]
		Perhaps this is about commit granularity. If keeping the history about advancing the task is not useful, then I’d merge these commits together before merging the PR; in some workflows this is set up to happen automatically too.

▲

hobofan 3 hours ago | parent | prev | next [-]

I agree in principle, but in practice, it's horrible right now.

Most AI generate commit messages and PR descriptions are much too verbose and contain 0 additional informational value that couldn't be parsed from the code directly. Most of the time I'd rather read 2 sentences written by a human than a wall of text with redundant information.

▲

lelandbatey 10 hours ago | parent | prev | next [-]

Sounds like you haven't been working long enough to forget your decisions, which you WILL do eventually. In such cases, where you're looking at code you wrote 10 years ago and you find a weird line, when you view the git blame and read the commit message, you'll be very thankful that you explain not just "what" you did, but "why" you did this, something an AI will have a very hard time doing.

You don't have to if you don't want to, but if you think "this commit message is just a summary of the changes made", you'll never write a useful commit message.

▲

ekropotin 9 hours ago | parent | next [-]

I’ve been working in the industry for two decades, and I think commit messages is not the best place for storing decisions and associated context. I personally prefer ADRs.

	▲	g-b-r 6 hours ago \| parent [-]
		Two decades and you don't see any value in writing down what's currently in your head? Anyhow, ADRs are good, but they stand for Architectural decisions, not every decision is at that level. In general, if there's a better place to store explanations, do use it, but often, in many projects, commit messages are the least bad place; and it's enormously better to write there than nowhere at all.

▲

sroussey 9 hours ago | parent | prev [-]

That’s why you put the comment in the code

	▲	lexicality 3 minutes ago \| parent [-]
		comments rot as the code changes around them

▲

10 hours ago | parent | prev [-]

[deleted]