Live data from Hacker News

Show HN: Generate commit messages using GPT-3

github.com

21–30 of 73 posts

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

#21
post #12

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.

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

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

#22

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"

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

#24

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 opinion, commit messages should clarify the intent of WHY you changed things. I can already see WHAT you changed from the diffs.

And I'd scold you for doing that if I were your superior. The WHY should be in the pull request, not in the commit message. a commit message should succinctly explain WHAT was changed from an architecture/organisation perspective.

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

#25
post #12

Earlier quoted context omitted.

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.

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.

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

#26

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/

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

#27

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.

As a rule of thumb: the WHY in the PR, the WHAT in the commits.

[deleted]

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

#28

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.

As a rule of thumb: the WHY in the PR, the WHAT in the commits.

I would say the opposite. The manager who receives the PR (merge request in gitlab) needs to know what has changed (if it is not obvious from the diff) to assess the change before accepting it. He has to know what has changed, for example to decide which non regression tests to performe.

The final user of the software will receive a changelog (a list of commit messages) that shall identify the bugs that have been fixed and the new user requirements that have been added. He needs to know why the code has changed to know what he has to do.

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

#30
post #14
post #5

Earlier quoted context omitted.

Can you give some examples of good commit messages?

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…

The 'update thing.xyz' one is the default commit message made when editing files using the GitHub web interface.

If it's a developer actually typing that in I'd be disappointed.

Post reply on HN