Live data from Hacker News

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

zura.wiki

41–50 of 106 posts

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

#41

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…

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…

I don't think the situation is comparable. The comment is redundant because typically you see the commented code right next to it, so reading the code is about as much effort as reading the comments.

In contrast, commit messages often stand alone: If you browse the history, you only see the messages, but now a large number of them; if a commit changes more than one file, the commit message has to sum up the changes from all files.

In all those contexts, a simple, high-level description of what has changed can be enormously helpful.

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

#42

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…

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…

If you don't know why you're making the change, you are not ready to commit the change.

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

#43
post #6
post #3

Neat concept, but this opens up a can of worms for corporate security. Pretty sure I won't get approval to submit proprietary code to a third party service just because I was too lazy to write a few lines of text. Might be helpful to open source projects?

Just add fully homomorphic encryption. I agree with you, but I'm assuming this could just send a diff and that context would be small enough to not leak. Then again, if GPT can keep track of all the diffs...

...and ask OpenAI to reimplement the entirety of ChatGPT to work with homomorphic encryption.

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

#44
The very last thing you should do is commit a GPT-3 generated commit message for a fairly simple reason: if GPT-3 can interpret and and explain the change as written, there is no reason to commit that message. You will always be able re-run the generator at any later date, over any range of changes, to get the same or (presumably, in future) improved results.

As pointed out by other comments, the commit message should be telling you facts about the change that are not evident from the change itself. GPT-3 can't tell readers why the change happened.

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

#45

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

> … and those who tag you as a reviewer on +8,298, -1,943 commits/PRs with the commit message "JIRA-PROJ-84138". At my workplaces, we've told people who do this to break up their larger commit into smaller ones before reviewing. If they haven't done that initially, well, their life is going to get harder for a few days.

Say hello to a long list of smallish commits full of random, unrelated changes and with commit messages "fixed various small issues", "continued implementing ", etc

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

#48
Did the OP use the tool to write his own commit messages?

A lot of the commit messages were typical and sort of redundant but this one stood out to me https://github.com/zurawiki/gptcommit/commit/82294555e7269e6...

"Add github token to address GH Workflow rate limits"

This is a good commit message, it describes a problem and a solution. I'd be very impressed if the GPTCommit tool wrote this and knew why the github token was being added.

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

#49

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

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 so CI that's part of review takes minutes, not hours.)

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

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

Post reply on HN