Live data from Hacker News

Show HN: Generate commit messages using GPT-3

github.com

41–50 of 73 posts

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

#41

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.

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

#43
post #25

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.

Not to make this a merge strategy debate, but this is most of the reason why I’ve opted for squash merging for my team. I’ve been happy for quite some time.

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

#44

Why put the commit message there then? You could just use a git-client that adds this text as description for commits. There is generally little use to store automatically generated content in databases, the input for generation should be enough.

I hate this idea, but generating it at commit time is better, because the author can verify/edit the generated message.

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

#45

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"

Fixed the bug fix issue

I must have seen these commit messages so many times if I had a penny each time, I would be rich by now.

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

#46
post #34

Earlier quoted context omitted.

Big disagree on that. I think the commit message should tell me what the change does, not why.

Ideally, both. 'Change rounding to thousandths' isn't overly helpful, and probably apparent. 'Fix overspending bug' is vague. 'Fix overspending issue by rounding to thousandths instead of hundredths' is the ideal commit msg here, as it gives a brief what and why. Possibly even with a ticket number, though I see how after years and switching systems that becomes less useful. More useful is briefly describing the why a…

Depends on the workflow. You can e.g. start every commit with a ticket number and explain the Why in the ticket.

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

#47

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

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

#48
post #9

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.

Why should the commit message explain why? I thought the point was to give a summary of the changes so that you don’t have to read the full diff.

The subject line should be 'why':

    Fix 500 due to syntax error accessing /users
the body can summarise and expand on (..if you know what I mean) the diff as well as explaining why:

    Due to  in this case  was
    interpreted as a baz, when clearly the author in 
    intended foo, which would return the response with bars here
    as expected.

    This commit fixes the issue by adding an explicit semicolon,
    thus forcing the foo interpretation.
That's probably overkill for a simple syntax error (unless it really is that arcane in which case it might be a bit of a teaching moment/object lesson).

Compare:

    Add semicolon

    [no body]
Post reply on HN