Live data from Hacker News

Gptcommit: Never write a commit message again (with the help of GPT-3)

zura.wiki

101–106 of 106 posts

Re: Gptcommit: Never write a commit message again (with the help of GPT-3)

#101
post #80

Earlier quoted context omitted.

Right, and even if GPT-3 could summarize the thousand-line diff in a sensible way, without introducing any falsehoods, it would still be strictly worse than the developer writing a sentence explaining what they think they've accomplished with the commit. It's just the same thing as with comments and "self-documenting code". The code tells you what (and if written carefully, it may be even somewhat effective at it). I…

I dunno, I'd like to see if GPT agrees with the author's assessment of what their code does.

But that is neither the purpose of a commit message, nor is it the why a commit was made.

Re: Gptcommit: Never write a commit message again (with the help of GPT-3)

#102

To everyone hating on this...I think a GPT-3 summary of a diff is a great thing to have, because it's a summary of the change and thus can be quicker to grok than picking through a diff. Also this doesn't seem to preclude a developer adding their own text to the commit (the why, etc). Finally, if the summary looks weird/incoherent it could serve as a signal to the developer that the commit needs more work.

It is not about hate. If there is tool, perhaps GPT-3, that is really good a summarizing code diffs. It should be integrated in your IDE or other tooling to summarize diffs on the fly, when I need that summarization. Not when I commit a diff. Thereby, we could all profit from improvements of that tool over time, and everybody could use it in his or her own language. That is strictly better than running that tool once and integrating it hard with the source code.

Re: Gptcommit: Never write a commit message again (with the help of GPT-3)

#103

Earlier quoted context omitted.

There is a third type of coder: one doing commits with single, obvious, minimal purpose, that still sometimes end up being +8,298, -1,943 - but with a sensible, detailed message explaining what's being done and why. This happens in environments where it takes hours for CI to let your change pass, making small commits prohibitively expensive in terms of time and infrastructure. (And yes, I know the answer is: make it…

And then there are the cases where the diff is a single line, but the commit message over a hundred lines because the change (or more likely its justification ) is not obvious.

See for example commits by Jeff King on the Git project. :) It’s impossible to infer those messages from the diffs alone.

Re: Gptcommit: Never write a commit message again (with the help of GPT-3)

#104
post #50
post #22

This is horrible. Commit messages should contain the reason why this change has been made and not imprecise prose summaries of what the diff looks like.

The comments here are acting as if the messages can't be changed. As someone else mentioned, this should be used as a starting point to summarize the change, but the reason for the change obviously can, and should, be added by a human. This is far from horrible.

It adds 100% of what I would point out in code reviews to be removed from the commit message. It incentivizes an anti-pattern, so yes it's horrible.

Re: Gptcommit: Never write a commit message again (with the help of GPT-3)

#105

I can kind of understand getting help writing the description of a large PR. But a commit message? Whose commits are so long so often that they need the help of an AI assistant to come up with the contents?

Heh… there are really two types of coders. Those who things commits should have a single, obvious, minimal purpose, and who will split off unrelated changes into separate commits… … and those who tag you as a reviewer on +8,298, -1,943 commits/PRs with the commit message "JIRA-PROJ-84138".

Hey, at least they referenced the (hopefully appropriate) JIRA ticket!

Re: Gptcommit: Never write a commit message again (with the help of GPT-3)

#106
post #24

Earlier quoted context omitted.

this is just normal every day commit messages in most startups I've seen

Startups tend to be a "do a rush job so the business won't die, worry about fixing it later" kind of a deal. I don't envy those working on original codebase after the startup is no longer racing its own runway. I've experienced messages barely better than this in products that were under no immediate threat, and let me tell you this: having to figure out why some changes were made, three years earlier, in a bunch of…

yeah, it happens a lot in established projects as well. especially projects with very small teams.
Post reply on HN