Live data from Hacker News

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

zura.wiki

51–60 of 106 posts

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

#51

Because what we need is more of the what was done, with no regard to the why. Why provide any context as to why the change was made when you can fill it with an AI description of what one could accurately tell by looking at the code? I kinda can't believe this isn't a joke. Just squash it to the emoji that best captures the sentiment! Why use the tool to enhance you and your peers lives, when you can use AI to make i…

[deleted]

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

#52
post #40

Earlier quoted context omitted.

A ChatGPT-generated message, pasted without editing, is purely functional transformation of the code, adding zero information. This means I could just as well run it on your diff myself , if I thought it would be useful. More than that, when I do it a year or two after you made your commit, the then-current ChatGPT will likely do a much better job at summarizing the change. So perhaps it's best to leave auto-summariz…

> purely functional transformation of the code, adding zero information I mean, a human brain is arguably also a purely functional transformation adding zero information.

Though in this case, it has more and better quality context (i.e. input), like requirements or anything else that isn't in the model's training set.

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

#53
Writing commit messages (or comments in general) is like practicing vocabulary, but for your mental understanding of the current problem.

Taking a step back and thinking about what I have actually done often helps me to find misconceptions, the worst bugs of them all.

Automating this away would be like learning a foreign language by pasting book exercises into a translation app... you may get good grades, but does it help your understanding if you didn't put in the effort yourself?

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

#55
post #40

Earlier quoted context omitted.

A ChatGPT-generated message, pasted without editing, is purely functional transformation of the code, adding zero information. This means I could just as well run it on your diff myself , if I thought it would be useful. More than that, when I do it a year or two after you made your commit, the then-current ChatGPT will likely do a much better job at summarizing the change. So perhaps it's best to leave auto-summariz…

> purely functional transformation of the code, adding zero information I mean, a human brain is arguably also a purely functional transformation adding zero information.

It's not. The diff, which is the sole input to GPT-3 here, does not carry the causal context - that is, why the change was made. Nor does it carry the broader understanding necessary to summarize the what succinctly and accurately - things like high-level design terms that mostly exist on diagrams or in issue trackers, but not in the code itself. By adding those details in a commit message, the author can add extra information.

And yes, technically they could do it in comments, which would allow GPT-3 to process it. Except, I think it's highly unlikely for a coder using ChatGPT to write commit messages for them to actually author useful comments on their own. If they write any at all, they'll probably use ChatGPT (or Copilot) for that too.

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

#56

Earlier quoted context omitted.

For me the point of this demo is that even a good commit message is often redundant information. As programmers we learn that adding a comment like: // The limit is 16 to const SOME_LIMIT = 16 is bad because is redundant information that serves no purpose to the reader and can easily misalign in the future. So what's a good commit message for changing this limit? Ideally we want to describe why we've changed it but t…

> Ideally we want to describe why we've changed it but this information isn't always available I struggle to imagine situation in which this is the case. Surely, even in the worst case of you being told to make a particular change with no explanation given, you can at least drop a "increased from 5 at a request of ${name of your boss}", or "increased from 5, see ticket #${ticket number}" in a comment, and/or a commit…

Something that's standard at the company I work for is commit messages always having the ticket number at the start, and it helps figure out why something was changed so much more than a commit message.

Ex of a recent change I saw, but anonymized a bit.

PROJ-12345: Added preview flag to video player

PROJ-12345 in Jira:

When a preview of a video is playing in the persistent player, preroll ads will display on app launch.

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

#57

Earlier quoted context omitted.

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".

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.

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

#58

Writing commit messages (or comments in general) is like practicing vocabulary, but for your mental understanding of the current problem. Taking a step back and thinking about what I have actually done often helps me to find misconceptions, the worst bugs of them all. Automating this away would be like learning a foreign language by pasting book exercises into a translation app... you may get good grades, but does it…

Yep. More than a few times I’ve finished a piece of work, and in writing the commit message explaining the whys and wherefores, realised my solution was actually flawed, or that a better solution was possible, and so thrown the entire thing away and started again. I love writing commit messages.

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

#59
post #20

I don't really ever want to read answers from GPT to questions that I didn't knowingly myself ask GPT. If GPT can write a commit message from you, don't write it at all and let me ask it that if that's what I want. It may be a positive to you to spend a few seconds less on commit messages but it's a net negative for the world for it to become polluted with vast amounts of flatly incorrect text with no knowledge as to…

Except for startups when commit messages are more like "asdf", "aoeu", "quick fix", or "demo" because some investor barged in and demanded a demo before they would wire funds. If ChatGPT could change that to something like "disable current limits" or "disable safety checks" or whatever that might be marginally better.

Haaaaaaaaands

https://xkcd.com/1296/

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

#60
post #24
post #20

Earlier quoted context omitted.

Except for startups when commit messages are more like "asdf", "aoeu", "quick fix", or "demo" because some investor barged in and demanded a demo before they would wire funds. If ChatGPT could change that to something like "disable current limits" or "disable safety checks" or whatever that might be marginally better.

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 badly-described commits whose author already left for another job, with no old documentation hinting at the purpose of the changes - this is one of the few things in this job that make me want to shout someone's ear off.

Post reply on HN