4 ms·

Ah this again? Commit message is not just a quick summary of what, it's also a historical record of why. Can't generate the latter from the diff.

guitheengineer 2y ago
True, but you can infer the why from what changed for a lot of cases e.g. - Add types for X, Y Z if the PR goal is to make types more strict, that message is clear. I feel like the quality will be worse than if the engineer really put some thought into it, but the problem is, commits are annoying to write. A lot of people do “wip” or do a worse than average job. Having a summary of what changed is still better than that. Edit: if you feed more context about what you’re trying to develop it will probably be able to infer.
- judofyr 2y ago
  I’d rather have «wip» commit messages, and thus forced to open the diff, than worrying of the message being hallucinated. I’m totally cool with people using this as an initial draft and then manually tweaking it though.
- isaacremuant 2y ago
  Commits are annoying to write is in the same space as "variable names are annoying to write". Communicating intent should be trivial or, if it's not, put effort into it because communication with that future dev may be essential . Now, maybe some bullet points may suffice and quickly be reshaped by AI to make it more succinct and clear but you still should make the effort. The more you do it, the more it becomes an easy part. The problem is when you copy and paste the same info in slightly different ways in many places and I can appreciate some form of suggestion around "you missed explaining why you want to change this part". There's a space for AIb but it isn't "so that I don't need to think".
deleted 2y ago
[deleted]
crazygringo 2y ago
I've never worked that way. In my mind, commit messages should be a quick summary of what. The basic motivation should be clearly labeled as a feature, bugfix, etc., but that's all. Commit messages are for quick browsing and a summary of what changed, not extensive justification. The why is too important to be put in a commit message. The product why belongs in a linked issue that describes the bug or use case in full detail. Meanwhile, the technical why's (why this particular solution as opposed to alternatives) belong in the code itself as comments.
- paddez 2y ago
  The first line (or atleast, the first 80 characters) should be a quick summary - so you can quickly browse via git blame. But the actual commit message should consist of History/Motivation/Context - so that someone who's going through the blame can understand why a certain change was made, and what the context was. Linus had a good template for this, which makes a lot of sense: https://gist.github.com/finalfantasia/bd0070673ca27e5f7473 https://gist.github.com/finalfantasia/bd0070673ca27e5f7473
  - pydry 2y ago
    If I want history, motivation and context to actually be read at some point I put it in tests, code comments and README/docs. If I want my history, motivation and context to be ephemeral I put it in a commit message. It still perplexes me why people obsess over commit messages while the places where people are actually looking when they have these questions are neglected.
    - paddez 2y ago
      {Tests, Code Comments, Documentation} are 3 distinct places to trawl through when quickly going through git blame. The commit message is one place - and gives the author an opportunity to speak directly with a future developer over the place-in-time-context that this change was made.
      - 2y ago
TrainedMonkey 2y ago
Yes, when spelunking why something has changed having good rationality would be a godsend... however let's face reality: 1. Majority of commit messages are low quality and would benefit significantly from a good summary of what was done. 2. Margin of commit messages is often too small for documenting the rationale - this job is better left for tickets.
- davidbanham 2y ago
  If the content of the commit is too small to be meaningful, the commit is too small. Either wait until you’ve done more before committing, or rebase -i before pushing your branch and merge up any piecemeal commits into better sized ones that communicate a story. Keeping that metadata in tickets means that it can’t be read within ‘git blame’. It’s also all too easy for it to be lost entirely when changing ticketing systems, transferring codebases between teams or companies, etc.
- factotvm 2y ago
  > 2. Margin of commit messages is often too small for documenting the rationale - this job is better left for tickets. The commit message lives with the code. The number of times in my career that a company has migrated, changed, consolidated, or otherwise made all those links in commit messages obsolete, well I don't quite yet need two hands. But I see a lot of dead ends to context in code bases.
  - cdcarter 2y ago
    Nothing stopping someone from deciding to migrate VCSs (or even just repos) and all of a sudden end up in the place that 15 years of codebase history is squashed down to a single new starting commit. :(
    - factotvm 2y ago
      Don’t forget that most modern version control systems are distributed. The same can not be said for ticketing systems.
- 2y ago
teeray 2y ago
Yep. You should stop and answer “why does this commit exist?” since that is the question you will be asking yourself when you discover it with `git blame` or `git bisect`. It amazes me how many devs are just willing to slap a -m on `git commit` and just say “fix bug” or “pr feedback”.
hadat 2y ago
Thank you for the response, My target is people that are bad at writing commits, barely or don't even write commits. Also from what you arguing I've worked on alot of projects including opensource and the majority just provide a quick summary so this would be of great use. Here are some commits the bot wrote feat: Enhance Auto-Commit Bot with new features and improvements - Reworked the description to provide a more detailed overview of the tool's capabilities. - Added badges for license and Python version. - Updated the installation instructions to include environment variable setup for the Google Gemini API key. - Implemented logging for all actions to facilitate debugging and provide a comprehensive record of events. - Included a usage example to demonstrate the workflow of the tool. - Improved the commit message generation using the Google Gemini API for increased accuracy and context. And feat: integrate Gemini API for commit message generation This commit introduces integration with the Gemini API to enhance the automated commit message generation process. The following changes were made: - Added a `CommitMessageGenerator` class to generate commit messages using the Gemini API. - Modified the `ChangeDetector` to handle the generation and staging of commit messages. - Updated the CLI to accept an API key for Gemini API access. - Added error handling for missing API keys. - Implemented tests for the `CommitMessageGenerator`.
rcarmo 2y ago
Well, that is exactly what the code does right now: https://github.com/suwi-lanji/auto-commit/blob/40c1fc34adce51ed8a26dd989a9d6e4e3e6f060f/auto_commit/commit_message_generator.py#L15 https://github.com/suwi-lanji/auto-commit/blob/40c1fc34adce5.... I would probably have it look at the files and try to generate a nice summary of “why”, but for those minor things where you add a parameter or fix whitespace I think this is OKish.

guitheengineer 2y ago

True, but you can infer the why from what changed for a lot of cases e.g. - Add types for X, Y Z if the PR goal is to make types more strict, that message is clear. I feel like the quality will be worse than if the engineer really put some thought into it, but the problem is, commits are annoying to write. A lot of people do “wip” or do a worse than average job. Having a summary of what changed is still better than that. Edit: if you feed more context about what you’re trying to develop it will probably be able to infer.

judofyr 2y ago
I’d rather have «wip» commit messages, and thus forced to open the diff, than worrying of the message being hallucinated. I’m totally cool with people using this as an initial draft and then manually tweaking it though.
isaacremuant 2y ago
Commits are annoying to write is in the same space as "variable names are annoying to write". Communicating intent should be trivial or, if it's not, put effort into it because communication with that future dev may be essential . Now, maybe some bullet points may suffice and quickly be reshaped by AI to make it more succinct and clear but you still should make the effort. The more you do it, the more it becomes an easy part. The problem is when you copy and paste the same info in slightly different ways in many places and I can appreciate some form of suggestion around "you missed explaining why you want to change this part". There's a space for AIb but it isn't "so that I don't need to think".

deleted 2y ago

[deleted]

crazygringo 2y ago

I've never worked that way. In my mind, commit messages should be a quick summary of what. The basic motivation should be clearly labeled as a feature, bugfix, etc., but that's all. Commit messages are for quick browsing and a summary of what changed, not extensive justification. The why is too important to be put in a commit message. The product why belongs in a linked issue that describes the bug or use case in full detail. Meanwhile, the technical why's (why this particular solution as opposed to alternatives) belong in the code itself as comments.

paddez 2y ago
The first line (or atleast, the first 80 characters) should be a quick summary - so you can quickly browse via git blame. But the actual commit message should consist of History/Motivation/Context - so that someone who's going through the blame can understand why a certain change was made, and what the context was. Linus had a good template for this, which makes a lot of sense: https://gist.github.com/finalfantasia/bd0070673ca27e5f7473 https://gist.github.com/finalfantasia/bd0070673ca27e5f7473
- pydry 2y ago
  If I want history, motivation and context to actually be read at some point I put it in tests, code comments and README/docs. If I want my history, motivation and context to be ephemeral I put it in a commit message. It still perplexes me why people obsess over commit messages while the places where people are actually looking when they have these questions are neglected.
  - paddez 2y ago
    {Tests, Code Comments, Documentation} are 3 distinct places to trawl through when quickly going through git blame. The commit message is one place - and gives the author an opportunity to speak directly with a future developer over the place-in-time-context that this change was made.
    - 2y ago

TrainedMonkey 2y ago

Yes, when spelunking why something has changed having good rationality would be a godsend... however let's face reality: 1. Majority of commit messages are low quality and would benefit significantly from a good summary of what was done. 2. Margin of commit messages is often too small for documenting the rationale - this job is better left for tickets.

davidbanham 2y ago
If the content of the commit is too small to be meaningful, the commit is too small. Either wait until you’ve done more before committing, or rebase -i before pushing your branch and merge up any piecemeal commits into better sized ones that communicate a story. Keeping that metadata in tickets means that it can’t be read within ‘git blame’. It’s also all too easy for it to be lost entirely when changing ticketing systems, transferring codebases between teams or companies, etc.
factotvm 2y ago
> 2. Margin of commit messages is often too small for documenting the rationale - this job is better left for tickets. The commit message lives with the code. The number of times in my career that a company has migrated, changed, consolidated, or otherwise made all those links in commit messages obsolete, well I don't quite yet need two hands. But I see a lot of dead ends to context in code bases.
- cdcarter 2y ago
  Nothing stopping someone from deciding to migrate VCSs (or even just repos) and all of a sudden end up in the place that 15 years of codebase history is squashed down to a single new starting commit. :(
  - factotvm 2y ago
    Don’t forget that most modern version control systems are distributed. The same can not be said for ticketing systems.
2y ago

teeray 2y ago

Yep. You should stop and answer “why does this commit exist?” since that is the question you will be asking yourself when you discover it with `git blame` or `git bisect`. It amazes me how many devs are just willing to slap a -m on `git commit` and just say “fix bug” or “pr feedback”.

hadat 2y ago

Thank you for the response, My target is people that are bad at writing commits, barely or don't even write commits. Also from what you arguing I've worked on alot of projects including opensource and the majority just provide a quick summary so this would be of great use. Here are some commits the bot wrote feat: Enhance Auto-Commit Bot with new features and improvements - Reworked the description to provide a more detailed overview of the tool's capabilities. - Added badges for license and Python version. - Updated the installation instructions to include environment variable setup for the Google Gemini API key. - Implemented logging for all actions to facilitate debugging and provide a comprehensive record of events. - Included a usage example to demonstrate the workflow of the tool. - Improved the commit message generation using the Google Gemini API for increased accuracy and context. And feat: integrate Gemini API for commit message generation This commit introduces integration with the Gemini API to enhance the automated commit message generation process. The following changes were made: - Added a `CommitMessageGenerator` class to generate commit messages using the Gemini API. - Modified the `ChangeDetector` to handle the generation and staging of commit messages. - Updated the CLI to accept an API key for Gemini API access. - Added error handling for missing API keys. - Implemented tests for the `CommitMessageGenerator`.

rcarmo 2y ago

Well, that is exactly what the code does right now: https://github.com/suwi-lanji/auto-commit/blob/40c1fc34adce51ed8a26dd989a9d6e4e3e6f060f/auto_commit/commit_message_generator.py#L15 https://github.com/suwi-lanji/auto-commit/blob/40c1fc34adce5.... I would probably have it look at the files and try to generate a nice summary of “why”, but for those minor things where you add a parameter or fix whitespace I think this is OKish.