[HN Gopher] GPT based tool that writes the commit message for you
___________________________________________________________________
GPT based tool that writes the commit message for you
Author : guytv
Score : 77 points
Date : 2022-12-11 20:24 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| soofgo wrote:
| I made an `npx` command to add this awesome tool to codebases:
|
| `npx add-gpt-summarizer@latest`
|
| The CLI will walk you through all the setup steps. source code:
| https://github.com/soof-golan/add-gpt-summarizer
| dub wrote:
| I'd be more excited to use GPT to draft a summary of release
| notes by scanning all the new PRs in a release, summarizing what
| they are, and dividing them up into categories (bug fix, feature,
| breaking changes, etc.)
| eddiequinn wrote:
| I've been using conventional commits for that, if there was
| equivalent of this that conformed to the CC standard then I
| would give it a try
| rdxm wrote:
| civopsec wrote:
| I wouldn't be at all surprised if this improved the level of
| commit messages overall.
| eCa wrote:
| In addition to the other issues (eg. it can only explain the
| what) I'm low-key disappointed that the repository isn't using
| itself. It would undoubtedly have lead to an increase in commit
| message quality here.
| greatpostman wrote:
| The crazy thing is chatgpt is still primitive. A decade more of
| working with these models will be stunning
| deegles wrote:
| Love the concept, but don't run this on company code without
| approval!
| fragmede wrote:
| While we're making tools for developers, make it so that I can
| yell at my computer, have it run voice recognition on it, and
| have ChatGPT interact with Jira for me.
| [deleted]
| baq wrote:
| Examples! Please!
| adamkl wrote:
| https://medium.com/@knaan.harpaz/leverage-openais-language-m...
| tablespoon wrote:
| > Are you a software engineer looking for ways to make your
| workflow more efficient, or tired of manually sifting through
| long commit logs to understand pull requests? Introducing the GPT
| summarizer GitHub action: a powerful tool that leverages OpenAI's
| latest and greatest large language model to generate concise and
| informative summaries of the entire pull request, as well as
| descriptions of the changes to individual files and individual
| commits.
|
| This kind of stupid.
|
| 1. _At best_ , all this can do is look at what you actually
| committed, but that's _not_ going to tell you the most useful
| stuff that should be included in a commit message, like why you
| 're making the change in the first place and what your intent was
| (which may deviate from what you actually did).
|
| 2. If you wrote the damn commits, you should be able to describe
| them yourself. If you can't, something's wrong.
|
| The only case where I can see a tool like this being useful,
| instead of a bad habit, is _summarizing old commits_ , where the
| committer didn't put _anything_ useful in the commit message.
| maximilianroos wrote:
| "Let GPT write the description, so you can focus on the
| explanation" would be better
| baq wrote:
| It isn't stupid if it works. If this allows an engineer to
| spend 15 mins less time while generating good enough PR
| descriptions, that's a huge win, especially if the developer
| isn't a native English speaker. IME people after getting
| whatever they're working on to pass tests don't feel like
| writing prose about their work. This would significantly reduce
| the burden of work which is perceived 'low value' and 'boring'
| by most (yes I do review code and yes I will reject a PR
| without a summary).
| tablespoon wrote:
| > It isn't stupid if it works. If this allows an engineer to
| spend 15 mins less time while generating good enough PR
| descriptions, that's a huge win...
|
| _It can 't work_, unless it's hooked up to a brain scanner
| and can read your thoughts.
|
| It seems more like dumb thing that people who don't know what
| they're doing will think is smart.
| baq wrote:
| You see a tool which doesn't do all you want it to do and
| say it's useless where it clearly can make the act of
| actually doing what you want simpler and faster. I don't
| understand why you think it'll do 100% if 80% is already
| good enough and very helpful to get the last 20% done.
| tablespoon wrote:
| It's a path to laziness and skipping the 20% that's
| actually helpful in favor of a useless 80%.
|
| I see a useful use case for using a tool like this
| _after_ the commit messages are written (e.g. auto-
| generate these summaries on the fly when browsing
| history), but using it to write commit messages
| themselves is a terrible idea.
| jefftk wrote:
| Information that can be automatically extracted from the delta is
| the least important part of a good commit message. I can figure
| that part out from looking at the commit later. Instead, what I
| really want to know is why you made the change. What is the
| context? What problem were you solving? Why this way and not
| other ways you might have solved the problem?
|
| A summary of what the change does is still useful, and I'm glad
| this can now be automated, but it's not the main benefit of a
| well written commit message.
| nunobrito wrote:
| Was looking at the examples (link posted at another comment)
| and this addon seems like a good starting point for an accurate
| commit message.
|
| Starting point. After that it should up to the committer to
| make modifications and upstream the message. For those cases,
| seems good enough for me.
| DogLover_ wrote:
| I think you would be surprised how PRs work in many companies.
| We are encouraged to write small PRs and many will have
| automated tools that points to a Jira ticket in the description
| or as a comment. For this reason many leave empty descriptions.
| In such cases this would still help.
| Karunamon wrote:
| What I have always been told for writing good commit messages
| is that the message should tell you what the commit does when
| applied to the code. The place for these what/why messages
| would appear to be in a ticketing system of some kind,
| referenced by ID in the commit message.
|
| What you're asking for would result in extremely bloated
| messages.
| singpolyma3 wrote:
| There's no meaningful limit on message length for a reason.
| Don't bury the context in some external system that may
| change or go offline, let it live in the commit where it is
| safe and easily accessible.
| baq wrote:
| On the contrary, git commit messages and checked in docs are
| the only places that are guaranteed not to be lost to
| history. Ticketing systems change, get migrated to with data
| loss or are access limited. Git is forever. The commit
| message is a much better place for explaining what was done
| why than some obscure Jira instance.
| tablespoon wrote:
| > The place for these what/why messages would appear to be in
| a ticketing system of some kind, referenced by ID in the
| commit message.
|
| No. It's best to assume that all information in your
| ticketing system will be _totally_ lost.
|
| The commit message should have the "what/why" directly in
| them, because that's where you'll first look when you want to
| find that out (why add an extra hop), and it would require
| extreme incompetence (which is not unknown) to lose
| information stored there.
| nazgul17 wrote:
| I agree at a gut level with this. Do you have a source that
| this is more widely believed? I would like to bring this to
| my tech lead.
| ycombobreaker wrote:
| Walk through a hypethetical ticketing system migration
| with your tech lead. Assume all external links are
| broken, and see how expensive it becomes to answer
| questions about your own codebase. "why did we add
| special case X? is it still applicable? It interferes
| with new feature request Y, can we remove it to reduce
| total risk/cost of implementing Y?"
|
| Integrating with another tool is fine, but not at the
| expense of your commit history!
| warpech wrote:
| Came here to make the same comment.
|
| There is a great blog post about it:
| https://dev.to/jacobherrington/how-to-write-useful-commit-me...
|
| It boils down to the following commit message template:
| <what you changed> because <why it was needed>
| fpoling wrote:
| From my experience people rarely read the commit message s,
| so it is better to put the why part into comments in the
| code, not git history. I mostly write the detailed why part
| in the commit only for refactoring changes.
| JBorrow wrote:
| depends, if you are bisecting the commit messages are very
| helpful
| ycombobreaker wrote:
| My experience is that many changes span several blocks of
| code in a repo, so there's not always one single location
| to put the comment. There's also a blessing in that git
| commits don't need to be maintained like comments. Comments
| can drift if not maintained. A commit is only observed in-
| context.
|
| Most developers seem to be poor "commit historians" by
| default, I'll admit. If you have the energy and consistency
| to enforce good history, it eventually becomes self-
| sustaining.
| phyzome wrote:
| If I'm adding something weird and funky that requires a
| long explanation of context, it goes in a comment (or even
| an ADR). If I'm removing it, it goes in the commit message.
|
| (Those are not the only situations, of course.)
| nazgul17 wrote:
| Well, sometimes, changes are "events" and only make sense
| to know in the context of the state of the codebase at the
| time.
| felipelalli wrote:
| On my tests the GPT3 is able to understand the whole context
| and give a very good commit message.
| nuclearnice3 wrote:
| Do you think it was able to answer jefftk's questions,
| especially
|
| * What problem were you solving?
|
| * Why this way and not other ways you might have solved the
| problem?
|
| Or do you think those aren't usually needed for a very good
| commit message?
| jnsie wrote:
| Haven't tried this solution but my first thought was of those
| (.NET) libraries that would generate comments using a functions
| signature (function name, parameter name, etc.). Remember some
| senior devs at the company I worked for at the time being
| mesmerize and overusing this. We ended up with comments that
| could easily be inferred from reading the signature...
| jimmaswell wrote:
| I like those in general because you can hover over a function
| call in visual studio to see a description.
| savolai wrote:
| A summary can still help you remember the parts of what you did
| and more accurately fill in the why.
___________________________________________________________________
(page generated 2022-12-11 23:00 UTC)