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

71–73 of 73 posts

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

#71

Post by silisili »

yreg wrote: post #46
silisili wrote: post #36

Earlier quoted context omitted.

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.

In my experience this works super well UNTIL you inevitably switch ticketing systems and lose it all. Happened to all of our stuff twice now :(.

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

#72

Post by yreg »

silisili wrote: post #71
yreg wrote: post #46

Earlier quoted context omitted.

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

In my experience this works super well UNTIL you inevitably switch ticketing systems and lose it all. Happened to all of our stuff twice now :(.

I doubt switching ticketing systems is inevitable, but even then we would definitely migrate all the data to the new system.

The spec is far too important.

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

#73

Post by peepee1982 »

KronisLV wrote: post #57
peepee1982 wrote: post #41

Earlier quoted context omitted.

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 origi…

That's how I/we do it. But I don't like long first lines in commit messages, so I'll put the WHY in the commit's message body.

And yes, workflow needs to fit the needs of the people working on the project.

Post reply on HN