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.
Show HN: Generate commit messages using GPT-3
21–30 of 73 posts
Re: Show HN: Generate commit messages using GPT-3
#22This 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.
Re: Show HN: Generate commit messages using GPT-3
#23Re: Show HN: Generate commit messages using GPT-3
#24This 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.
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
#25Earlier 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.
Re: Show HN: Generate commit messages using GPT-3
#26This 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.
Re: Show HN: Generate commit messages using GPT-3
#27This 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.
Re: Show HN: Generate commit messages using GPT-3
#28This 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.
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
#29Re: Show HN: Generate commit messages using GPT-3
#30Earlier 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…
If it's a developer actually typing that in I'd be disappointed.