Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

zura.wiki

Post reply on HN
Print view View original

81–90 of 106 posts

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

#81

Post by issa »

tomtomtom777 wrote: post #31
ketralnis wrote: post #18

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…

usually the more important information in a comment is WHY the code does what it does.

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

#82

Post by D13Fd »

xg15 wrote: post #41
tomtomtom777 wrote: post #31

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…

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 f…

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

Sure, but you are leaving out the point of the original reply -- the GPT-written commit messages are not trustworthy. They will look convincing, but they are likely to have errors.

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

#83

Post by tjpnz »

If you're unable to write your own commit messages that's a strong signal to me that either your commits are too large or that you're unable to explain in simple words what you just did. While the first can be remedied I would find it hard working with someone who consistently displayed the second.

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

#85

Post by UncleMeat »

xrd wrote: post #6
NBJack wrote: 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...

FHE is slow as shit. Good luck running models at any reasonable pace. Somewhat Homomorphic Encryption is not useful since you've got way too many multiplies on floating point numbers.

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

#87

Post by deathanatos »

erik_seaberg wrote: post #66
satvikpendem wrote: post #15

Earlier quoted context omitted.

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

You can break a car into small pieces, but you won’t learn anything from a test drive if it doesn’t run.

Yes … it should run at every stage.

There are times new work does result in larger commits, like, a few hundred lines. But I've had some 20k delta PRs dropped on me and it's like, let's be honest, the review will be shallow, at best.

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

#88

Post by deathanatos »

xg15 wrote: post #45
satvikpendem wrote: post #15

Earlier quoted context omitted.

> … 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

I'm good with that! It's faster, and easier, to review many smaller PRs, than one large one, IME. (Although also IME, in actual time, larger PRs get "reviewed" faster by not getting reviewed at all.)

(I'd want a better commit message than those, though. But they might just be examples for the sake of discussion.)

I tried to start getting people to follow a rule of "if it's a cosmetic/stylistic change, so long as it passes CI, +1". (Nowadays I work in a language what has a decent auto-formatter, and CI just runs & enforces that…) There's a whole slew of similar changes that fall under that umbrella, if you can have the test for it. (I.e., if I can encode my review into a program that CI runs … then yay! For PRs that meet that, if CI is happy I'm happy.)

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

#89

Post by Hextinium »

D13Fd wrote: post #82
xg15 wrote: post #41

Earlier quoted context omitted.

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 f…

> In all those contexts, a simple, high-level description of what has changed can be enormously helpful. Sure, but you are leaving out the point of the original reply -- the GPT-written commit messages are not trustworthy . They will look convincing, but they are likely to have errors.

I find editing text is easier than writing from blank, this would (if it works) give me a starting condition to them edit from which is helpful.

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

#90

Post by chrismorgan »

TeMPOraL wrote: post #65
chrismorgan wrote: post #57

Earlier quoted context omitted.

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.

That too. I've never seen a 1:100 code to commit message lines ratio so far, but I've seen a few 2-3 line changes with a paragraph or two long explanations. I cherish those. Same if the explanation is in a comment. In fact, if I spot something like this, I tend to praise it publicly on the team chat. I had one case where a single weird line added much earlier messed up a seemingly unrelated piece of code I've been de…

I’ve done 150 lines on what I think was a two-line diff before, and >50 on a one-line diff a few times. But I am known for my verbose commit messages. (After two years working on a twenty-odd-year-old commercial code base that had had a dozen or so people working on it constantly, I had around two thirds of the longest commit messages. My longest was something like 400 lines, but most of that was a list of affected class names or similar, on a diff of tens of thousands of lines from a mostly-automated refactoring.)

I’ve definitely also added multiple paragraphs of in-code comments to an otherwise-single-character change, where it’s an ongoing consideration rather than something that can reasonably be left in a commit message alone. Then my commit messages gets to be brief, directing you to read the added comment instead.

Post reply on HN