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

Show HN: Generate commit messages using GPT-3

github.com

Post reply on HN
Print view View original

51–60 of 73 posts

Re: Show HN: Generate commit messages using GPT-3

#51

Post by taink »

BadOakOx wrote: post #26
fxtentacle wrote: post #3

This creates precisely the kind of commit messages that I regularly scold junior developers for :)" In my opinion, commit messages should clarify the intent of WHY you changed things. I can already see WHAT you changed from the diffs. But of course, any tool can only work with the what, they cannot know that these lines are related to a bug report filed in a technically unrelated system.

I fully agree, this is my favorite write up on how a git commit messages should look like: https://cbea.ms/git-commit/

Very interesting read, thanks!

Would you happen to know the justification behind "capitalize every commit subject line"[1]? I can understand finding it more appealing, but talking about it being as important as limiting the subject to 50 chars and not ending it with a period (which has a sensible justification), not as much.

[1] https://cbea.ms/git-commit/#capitalize

Re: Show HN: Generate commit messages using GPT-3

#52

Post by OJFord »

fxtentacle wrote: post #3

This creates precisely the kind of commit messages that I regularly scold junior developers for :)" In my opinion, commit messages should clarify the intent of WHY you changed things. I can already see WHAT you changed from the diffs. But of course, any tool can only work with the what, they cannot know that these lines are related to a bug report filed in a technically unrelated system.

I fully agree that this is an (even) easy(ier) way to write crap commit messages.

> But of course, any tool can only work with the what

Well, it could be a lot better at least - imagine passing a Jira ticket, telling it it's a bug fix or feature (the script could determine from the API); then you could probably get it not only to neatly summarise 'why' for the subject line but also have a go at relating it to the diff for the body.

Re: Show HN: Generate commit messages using GPT-3

#53

Post by onion2k »

yummybear wrote: post #22
fxtentacle wrote: post #3

This creates precisely the kind of commit messages that I regularly scold junior developers for :)" In my opinion, commit messages should clarify the intent of WHY you changed things. I can already see WHAT you changed from the diffs. But of course, any tool can only work with the what, they cannot know that these lines are related to a bug report filed in a technically unrelated system.

"Fixed some bugs I was told to"

For the sake of your cherry-picking colleagues please don't bundle multiple fixes in a single commit.

Re: Show HN: Generate commit messages using GPT-3

#54

Post by suprfnk »

dkdbejwi383 wrote: post #18
naet wrote: post #14

Earlier quoted context omitted.

A bad commit (that one of my coworkers always does) is "update file.ext". Says nothing other than the name of the file that was updated, which ends up with tons of repeat commit messages for common files and provides zero info that wasn't already included in the commit itself. Another poor commit is a description like "adds padding". It's a little too vague and doesn't really tell you much that wasn't already apparen…

You forgot my least favourite commit message: “fix PR comments” for a commit that changes 5 unrelated things

But then, putting those 5 unrelated things in the 5 commits that they belong to is a PITA.

Re: Show HN: Generate commit messages using GPT-3

#56

Post by 20wenty »

theherk wrote: post #47
proto_lambda wrote: post #2

Some examples of commit messages it generates would be useful, especially compared to good commit messages like the ones usually found in the Linux kernel.

I changed the prompt to `Generate a short commit message, using the imperative mood, from this:` in accordance with https://git.kernel.org/pub/scm/git/git.git/tree/Documentatio... .

I believe the original comment was to show some of the sample commit messages in the repo README itself, no?

Re: Show HN: Generate commit messages using GPT-3

#57

Post by KronisLV »

peepee1982 wrote: post #41
fxtentacle wrote: post #3

This creates precisely the kind of commit messages that I regularly scold junior developers for :)" In my opinion, commit messages should clarify the intent of WHY you changed things. I can already see WHAT you changed from the diffs. But of course, any tool can only work with the what, they cannot know that these lines are related to a bug report filed in a technically unrelated system.

I disagree. I want the what. The change itself explains the how. If the why isn't obvious and there's no link to a tracking system that explains it, it's fine if it's in the message body. I do want the why in comments, though.

Personally, I think that the following is a good approach:

  PROJ-2354 add/modify/remove/... WHAT to implement/fix/... WHY
with the code showing the HOW.

Ideally, with the commit/merge request having a textual description and/or a list summary for the overall changes, alongside some diagrams/images/gifs/videos, as well as further discussion where applicable. Oh and an issue management system of some sort with the original (business) requirements, notes from requirements engineering, as well as information about testing. Something like architecture decision records (ADR), script snippets, Markdown Wiki documentation or install instructions can also live in the repo. Then, with a decent test coverage and CI setup, it can also be pretty safe to merge the changes, because most of the stuff concerning them will be known and understood.

But at the end of the day, there will be as many opinions as there are people.

For some, there is no need for longer commit messages (e.g. with multiple lines, like a separate subject/body with explanation) which is more or less my case because that information will be in the merge/pull request. Others will say that filling out merge/pull requests is unnecessary because the commits should have that information (I disagree, but I've heard that stance). Some other people won't even bother with commit messages because in their eyes working code at the end of the day is all that matters (once again disagreed, but we've all seen "code fixes" in the log before). And some will have way different workflows, like not using a web UI of some sort for discussion but instead relying on commit logs and mailing lists.

Use whatever workflow feels adequate for you and your colleagues.

Re: Show HN: Generate commit messages using GPT-3

#58

Post by lelandfe »

VadimPR wrote: post #12
fxtentacle wrote: post #3

This creates precisely the kind of commit messages that I regularly scold junior developers for :)" In my opinion, commit messages should clarify the intent of WHY you changed things. I can already see WHAT you changed from the diffs. But of course, any tool can only work with the what, they cannot know that these lines are related to a bug report filed in a technically unrelated system.

In my way of working, the 'why' can go into the overall PR and the 'what' into the individual commits. Both are important - the reason for changes and a concise summary if what you've done.

As I always say in these conversations, PR descriptions and comments are ephemeral. Your git history should be forever, but you’re not guaranteed to be in the same repo on the same host for eternity.

I have already worked on multiple projects that got handed to us as a .git/ folder. Commit messages referencing non-existent issues abound.

I now make my whole team ensure that nothing crucial is left to live in the PR alone.

Re: Show HN: Generate commit messages using GPT-3

#59

Post by almog »

VadimPR wrote: post #25
jiggywiggy wrote: post #21

Earlier quoted context omitted.

PRs are not easy to read in the commit history, a year later a commit message is mostly flat without context.

Depends on how you merge - I prefer squash (yes, controversial). If you do merge commits, then I agree individual 'why' needs to be within the commit.

I'm not against squash commits, yet assuming you're using it to squash an entire PR into a single commit (so that you get a linear history) and given that you also prefer that "the 'why' can go into the overall PR and the 'what' into the individual commits", then you might end up with a 'what' part that can be hard to understood, that's because squashed commits do not point to the exact code change that they originally referred (unless of course the entire PR is very small).

Re: Show HN: Generate commit messages using GPT-3

#60

Post by dkdbejwi383 »

suprfnk wrote: post #54
dkdbejwi383 wrote: post #18

Earlier quoted context omitted.

You forgot my least favourite commit message: “fix PR comments” for a commit that changes 5 unrelated things

But then, putting those 5 unrelated things in the 5 commits that they belong to is a PITA.

Sure, but I'd prefer 5 new commits that describe the change individually - at least that way I can review each commit individually
Post reply on HN