Comment by Yokohiii

Comment by Yokohiii 3 hours ago

4 replies

https://github.com/arpxspace/smartcommit/commit/cc677f7bd210...

This is just a complete braindead commit. Without looking at the code I could probably take 5 minutes to make sense of the commit message, being intrigued something interesting or important is happening. The message is massively over the top, it has way more text then actual code changes. It wastes time.

I am not against AI as a helper in various places. But if possible it should be an opt-in tool if deemed useful. If someone wants to get a summary about a non trivial commit, that can be useful. Even better if the committer writes about the intentions and reasons for the commit, so an AI could match those with the actual code. Don't reiterate whats happening in a patch. Give the meta that isn't there or less obvious. Please.

OptionOfT 3 hours ago

You see the same with code and text generated by LLMs. Overly verbose, comments that repeat code, and commit messages that repeat what is done in code, but not WHY.

zahlman 2 hours ago

For that matter,

> The full path specification in `go build` was redundant given the context of how Go modules are structured. Simplifying the instructions improves clarity and reduces confusion for new users or contributors.

The explanation doesn't seem quite right. The module mentioned in that command was moved to the project root, in such a way that the command no longer needs to specify a path. So the full path specification wasn't redundant; the updated version of it, became redundant.

And all of this was done in a single commit. Better (disclaimer, I have no experience using Go. Actual Go developers probably don't even need to be told this much):

  Use github.com/arpxspace/smartcommit namespace

  `go.mod` is updated with an explicit package namespace, and import
  statements adjusted to match.
and then:

  Rename main module

  `cmd/smartcommit.go` is moved to `main.go`, and the README adjusted to
  match. (Using this name allows omitting the main module path from the
  build command.)
and then:

  Simplify prose in README.md
(No explanation required for the last one.)

There's no need to justify that your changes are "in accordance with best practices", tell a story about "ongoing efforts" (unless you actually have other recent commits that you want to group together like that conceptually), etc. Commit messages are for other developers. Another developer who reads, in effect, "this change was made in the hopes that YOU will have an easier time contributing to the project"... is going to feel patronized.

But making fine-grained commits with short messages will help in the long run. No amount of prose in commit messages can actually organize the commits. Meanwhile, the AI's summary completely ignored a change I would recommend splitting out into a separate (third) commit.

  • crabmusket an hour ago

    This is great advice.

    > There's no need to justify that your changes are "in accordance with best practices", tell a story about "ongoing efforts" (unless you actually have other recent commits that you want to group together like that conceptually), etc.

    LLMs are very prone to generalisation and marketing language like this. Despite being sycophants, they are also trained to speak as if they constantly have to justify and persuade.

    This is called out in the Wikipedia meta I linked to in another comment. They're great red flags to look out for in any writing; humans, myself included, often used this kind of lazy construction!