[HN Gopher] AI Commits - a CLI that writes your commit messages ...
___________________________________________________________________
AI Commits - a CLI that writes your commit messages for you
Author : feross
Score : 45 points
Date : 2023-02-14 15:32 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bdg wrote:
| Something I learnt about good commit messages over my career was
| that the more useful messages don't summarize what is in a
| change, but why the change was needed. Usually everyone can
| quickly figure out what changed if the commit is of some kind of
| reasonable size, but why it was changed is lost forever.
|
| That said, a lot of my personal projects that will never get
| published are just "foo" messages.
| altf4 wrote:
| The best advice that I got was to write commit messages as a
| letter to your future self.
| Narushia wrote:
| I personally try to always include at least a short explanation
| on why the change was done, unless it's self-explanatory. But
| I'm under the assumption that most people don't do this because
| they already have that info in a relevant issue or merge/pull
| request. Which I think is a fine approach, especially if you
| leave the relevant link or identifier to the commit message.
| gerad wrote:
| In my experience ticketing systems come and go, but the
| commit history remains forever (yay dvcs), so it's a good
| idea to summarize the why in the commit message - even if
| it's already also somewhere else.
| Narushia wrote:
| Agreed. I usually end up writing the thing in at least one
| place besides the commit. Takes more time, but should be
| more future-proof as well. :)
| cristoperb wrote:
| But if it can be mechanized then why inlcude it in the commit log
| at all? Just run the tool post hoc if you're interested in what
| it has to say about a commit.
| tomxor wrote:
| It could be interesting to see the differences between author
| and generated messages as per a sibling comment. But for the
| purpose of trustworthiness I think you would want the commit
| author to pull the trigger on the comment (It's pretty clear
| from recent examples in the wild that it's a bad idea to trust
| language models for correctness beyond the language itself).
| [deleted]
| larsonnn wrote:
| Code will be send to OpenAI.
|
| Nope.
| mattnewton wrote:
| This is super cool, but I also really hope people I work with
| don't use it much since I rely on commit messages to tell me the
| "why" and other high level questions on the whole diff that don't
| fit into local comments above a single line. If it is simple
| enough to be self evident it's simple enough to include 1-2 words
| and not risk hallucinating a red herring IMO
| nicolaslem wrote:
| This, the "what" in a commit message is close to useless, the
| "why" is what matters. Unfortunately developers really don't
| need another excuse to skip the "why" so I hope this tool
| doesn't get any traction.
| whoomp12342 wrote:
| "I needed to build a screen for my models" gets old
| LorenDB wrote:
| Hey, at least it doesn't put "feat:" or "<bug emoji>" at the
| front of the commit message!
| rhacker wrote:
| Oh man that was a horrible time, when you get a project where
| dotting each file with a different emoji in github was some
| kind of work of art more important than the project itself.
| LorenDB wrote:
| It still happens today:
| https://github.com/carloscuesta/gitmoji
| [deleted]
| bilater wrote:
| Honest question - do people actually look at commit messages
| seriously? For me it would be a nightmare to review by
| commit...Instead if you think of the smallest unit of work as the
| PR, you can just view all the changes and be done with it.
|
| Not saying a commit message should be drivel but it can just be a
| simple one liner (it does help with Git Lens as you navigate code
| but that's about it).
| [deleted]
| teeray wrote:
| You should be answering the question "why does this commit
| exist?" when you write your commit messages. You'll be asking
| yourself that same question when you come across the commit via
| git blame or bisect later. Summarizing the content of the commit
| usually isn't enough to provide that context.
| indeyets wrote:
| I prefer to have both. First line -- a short summary of
| changes, further lines telling reasons and relevant comments
| curun1r wrote:
| I think it really depends on the type of project. An open
| source project is going to have different goals for commit
| messages than an internal corp project or a private personal
| project. I'm a big fan of conventional commits, but only in the
| context of a project that needs to generate a changelog so that
| users can quickly decide if they'd like to update. In that
| context, the why is totally inappropriate and should be part of
| a linked issue, not the commit message. But in a corp
| environment, it's really much more about preserving context so
| that future developers can figure out why something happened,
| so the why is super important. Corporate teams will have
| turnover and, when someone leaves, they're not going to be
| available to answer questions. And a private personal project
| is often just about using git as a checkpoint saving tool so
| that I can preserve known-working states. In that context, I'm
| really only interested in describing the state I'm preserving
| rather than describing what changed or why. If I ever decide to
| release it publicly, I'll rebase to hide the mess of my initial
| explorations anyways.
|
| Not being able to adapt your commit message style to the
| purpose it's serving is overly dogmatic. I wouldn't use the
| same language or tools for every project, so why would I use
| the same commit message style?
| imoverclocked wrote:
| So, instead of writing "git commit -a -m 'oops'" I can simply
| make another alias called "aicommit" to do it for me?
| vinaypai wrote:
| Is it time of the weekly thread for yet another tool that writes
| useless commit messages that completely miss the point of a
| commit message?
| gaogao wrote:
| The semantic difference between an auto-generated CLI commit
| message and the one the author writes would actually be a pretty
| good lint.
|
| I've seen bad rebases where unintended stuff slips in that
| probably could be caught by this sort of thing.
| 6gvONxR4sf7o wrote:
| There's a lot of room for AI in the commit process. In
| particular, I'd love a CI check that docs haven't gone stale. A
| big issue with investing in thorough docs is that the systems
| they document can easily drift away from them.
| colordrops wrote:
| Need to take this all the way. Should be a dynamic service that
| annotates your already existing commit log whenever it's queried.
| Your "commit messages" would get better over time as the AI
| improved. Leave the statically persisted commit messages to the
| humans.
| avgcorrection wrote:
| Last time I was negative to the idea. This time I'm conditionally
| positive: if I find myself in a project that mandates a
| structured style that I don't like, like "conventional commits",
| then it would be nice if a program could at least deal with the
| structured part on my behalf.
| bspammer wrote:
| Probably stating the obvious here, but do not use this at work.
| At least if you work for the 99% of companies that would be
| unhappy to find out you've been uploading all their code to
| third-party servers.
| wantsanagent wrote:
| I used to think commit messages were important. Now I don't, or
| more specifically I believe the importance should be shifted to
| ticket titles.
|
| In the workflow I was introduced to all commits backing a PR get
| squashed and merged with the commit message for _that_ merge
| being the ticket number and title of the ticket the PR resolves.
|
| This creates an incredibly clean commit history that is easy to
| trace back to tickets and their associated work items (like
| product docs). It also frees coders from any burden of writing
| good messages as they progress.
| brightball wrote:
| Sounds like the approach that Gitlab advocates.
| avgcorrection wrote:
| Something-something indirection.
|
| You're just saying that messages (or: what and why things
| happened to the code) should be moved out of the repository and
| into the issue tracker.
|
| This is like me saying that wiki articles aren't important...
| because we don't use a wiki for documentation and just commit
| the docs in the repository. Yeah, sure. But most of your
| interlocutors were probably more concerned with the fact that
| things needed to be documented, somehow.
| ElijahLynn wrote:
| Yup, squash and merge is THE way to go. I've tasted the good
| life. I always tie a commit back to a ticket and go to the
| ticket/issue for context with squash and merge. There is so
| much rich discussion in it that commit messages don't compare.
| flerchin wrote:
| I prefer this workflow too. Only issue is if we move to a
| different ticket tracking software.
| stinos wrote:
| Well, and finding out what the message #345 really means. I
| use file/line history a lot, it gets really useless with
| ticket numbers only. Yes, one could automate that to fetch
| the ticket description and display it. But the ticket
| description doesn't match the commit. It might for a simple
| bug report, but it doesnt at all for a bunch fine grained
| commits which together build up towards implementing a new
| feature. Might depend on the line of work, but having been
| there and done that: nevermore.
| ElijahLynn wrote:
| Yup, squash and merge is THE way to go. I've tasted the good
| life. I always tie a commit back to a ticket and go to the
| ticket/issue for context with squash and merge. There is so
| much rich discussion in it that commit messages don't compare.
|
| This approach when merging in the GH UI, puts the ticket number
| in the merged commit (not a merge commit though). And the
| biggest advantage of this approach is there is NEVER a "revert
| the revert" situation when dealing with reverting. So easy and
| clean to revert because you aren't reverting a merge commit.
|
| I get that "we can't change issue tracking software" but that
| is just something you gotta live with, and the advantages of
| squash and merge far outweigh this "possibility".
| programmarchy wrote:
| Both are important, imo. Writing good commits is useful for
| "showing your work" and breaking things down into steps. For
| example if I need to refactor a component when building a new
| feature, then I do it in a separate commit. Makes it easy to
| spin out a separate PR if necessary, and helps a reader
| understand why the refactor was necessary by looking at the
| next commit diff.
|
| You can still write "fix" and "wip" commits locally, as long as
| you rebase them before you push your branch.
| avgcorrection wrote:
| I also think that more commits when doing refactors help with
| history tracing once file renames get involved. It can be
| real head-scratcher to try to trace a function back through
| some commit that introduces a new feature + a whole module
| refactor. Even with "follow".
| nicolaslem wrote:
| There are a few issues with this approach:
|
| - It becomes harder to change the issue tracking software. I
| used to work for a company that went through a few bug
| trackers, resulting in tons of older commits referencing an
| inaccessible bug tracker.
|
| - It forces developers to switch from their IDE or git blame to
| another tool when doing code archeology. The last thing I
| personally want when trying to understand some code is more
| context switch.
|
| - Not all commits have an associated issue. I sometimes stumble
| upon problems in the code that I fix straight away. Writing a
| good commit message explaining the reason is important because
| otherwise the context is lost.
| Izkata wrote:
| Yep, mine is on its third bug tracker since I started (maybe
| more from before then), and third version control system. All
| the old cases are lost, but the repositories get imported to
| the next one and retain all their old commit messages.
| sillysaurusx wrote:
| For what it's worth, I hate squashed commits. I can't count the
| number of times that I wanted to know the source of one
| specific change, only to be redirected at a git diff with
| thousands of lines of changes.
|
| Ridiculous. That defeats the point of source control, which is
| partly to aid future readers, not merely track changes.
|
| I'm happy your workflow works nicely for you, but I hope the
| mindset goes away.
|
| Personally, I think it's important to force push over your "bad
| commit" when it happens. That way you don't generate dozens of
| WIP commits, and there's no need to squash. But sometimes WIP
| commits are fine to let through. They inform other devs about
| what you're experimenting with.
| philote wrote:
| I feel that if you have thousands of lines of changes in one
| squashed commit, you're not breaking down work enough. IMO,
| each feature or bugfix should be on its own branch, and then
| all the commits from that branch get squashed during the
| merge to a develop/release branch or to the main branch. If
| merging to a develop/release branch first, then merges from
| there to main do not get squashed.
| ZPVIP wrote:
| I used chatGPT to convert it from TS to Ruby:
| https://github.com/ZPVIP/commitgpt
|
| Special thanks to Nutlope.
| programmarchy wrote:
| I made something similar here:
|
| https://github.com/programmarchy/git-gpt
|
| Hardest part is writing the correct prompt. Your prompt looks
| better!
| tomxor wrote:
| I'm usually pretty sceptical of this tech being capable of a net
| positive, but this seems like a pretty safe and suitable premise
| (as a writing aid)... Since you are only relying on the model for
| the language rather than a source of truth, instead the author
| can validate the correctness and adjust before pulling the
| trigger on the commit message.
|
| The only place this falls down are for commits where the
| reasoning cannot be inferred and summarised from the code alone,
| or for reasons not apparent in the immediate code that require
| deeper understanding of the relationship between disparate code.
| The kind of information which is only in your brain, intent,
| these are the most important types of commit messages, and no
| language model is going to be able to help there... but for the
| rest, why not.
| raydiatian wrote:
| What we need is a CLI that does it the other way around: I write
| a commit message describing changes I want to make to my
| codebase. A CLI that is offline and familiar with my codebase
| cooks up:
|
| (1) tests (2) features and or fixes (3) perhaps supporting
| documentation (4) perhaps even applicable build changes
___________________________________________________________________
(page generated 2023-02-14 23:01 UTC)