YOU should be writing your commit messages, not an AI.

You can always generate a new commit message (or summary, alternative summary, etc) down the road with AI. You can never replace your mind being in the thick of a changeset.

▲

buu700 2 hours ago | parent | next [-]

The author of the commit doesn't matter per se. If someone is just having AI summarize their changes and using that as the commit message, I agree that they're doing it wrong.

These days, lots of my commit messages are drafted by AI after having chatted at length about the requirements. If the commit message is wrong or incomplete, I'll revise it by hand or maybe guide the AI in the right direction. That tends to be a much more useful and comprehensive description of the commit's intent than what I would naturally find worthwhile to write on my own.

OP's approach is interesting as well, at least in principle, and if it works well it might be the next best option in the absence of a chat log. It should just make sure to focus on extracting the "why" more than describing the "what".

▲

delusional 2 hours ago | parent [-]

> than what I would naturally find worthwhile to write on my own.

I take issue with that statement. There's nothing "natural" about documentation. You're not "naturally disposed" to writing a certain level of documentation. It's a skill and a discipline. If you don't think it's worthwhile to write documentation, that's not a "natural failing". You're making a judgment, and any missing documentation is an error in judgment.

	▲	buu700 2 hours ago \| parent [-]
		I meant "natural" in a context of having more urgent immediate priorities than extensively detailed documentation at the commit level — not an error in judgement, just a tradeoff. If a given project has time/budget to prioritize consistent rigorous documentation, of course it should consider doing so. AI's ability to reduce the cost of doing so is a good thing.

▲

crabmusket 9 hours ago | parent | prev | next [-]

If we assume, as many do, that we are going to delegate the work of "understanding the code" to AI in the coming years, this surely becomes even more important.

AI writing code and commit messages becomes a loop divorced from human reasoning. Future AIs will need to read the commit history to understand the evolution of the code, and if they're reading poor summaries from other AIs it's just polluting the context window.

Commit messages are documentation for humans and machines.

▲

ekropotin 10 hours ago | parent | prev [-]

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]