![]() (2) Whenever you actively maintain a piece of software for a long time, you'll find that the max number of consequtive lines in a source file that originate from any given single patch gets smaller and smaller. Basically the commit message should explain the rationale that can be understood after reading the whole issue tracker ticket from start to end. (1) You can link to the issue tracker from the commit message but nobody wants to read the whole discussion in the issue tracker to understand the commit. ![]() Sure, not all commits need equally long descriptions but I've written a lot of patches for our in-house system where the commit message is longer than the full diff.Īnd the rationale for having this information in the commit: Or does it describe why that commit is needed in the first place? Let's take a commit from the git/git repo:ĭo you think that commit message describes the contents of the diff? Commit messages are just a form of interpersonal communication. AI will destroy interpersonal communication in all forms not by being bad but by being good enough and people being cheap or lazy. It is an expression of desperation at the precipice of the Eternal September we are on. Note that this is not an attempt to dismiss this project. Unless you are writing unit tests specifically with the goal of refactoring an old code base piece by piece, AI written tests are worse than no tests because tests are meant to test the intended behavior not that the implementation does what the implementation says it does.Īnd people will use AI for commit messages thereby duplicating the information in the diff instead of explaining why a change was made in the first place. There will be countless repositories that will be infected by AI in various forms because who has time when KPIs must go up?Įventually people will skip analyzing that what the AI spits out is actually the intended code as long as it compiles and appears to work.Įventually people will use AI to generate unit tests even if that is missing the point of unit tests. The sad truth is that this will in fact get used. But such microcommits should be squashed before merging and the commit message should state why the change was made. With microcommits you are essentially using version control as a more powerful undo button. If you are doing microcommits to your local repository and there is no individual "why" than this may be useful. When the AI will have that context it will just pick up tasks, make the changes and commit by itself without human intervention.Ĭommit messages that describe the what are of course still better than "First commit" "Second commit". This requires a lot of context which the AI is never fed. ![]() ![]() It should probably be something like "Fixing overflow bug CVE-xxxxx" thereby explaining why the change was needed. The commit message probably shouldn't be "Adding bounds check". Say you are adding a bounds check to some operation. Don\'t start it with "This commit", just describe the changes.". Your prompt for the description is "Add a short description of **what **commit is about after the commit message. Was there a business need? Was there a bug? The changes are already obvious from the diff. You are meant to state WHY they were made in the first place. You are not supposed to summarize the changes. Through your comment, you demonstrate that you are missing the point of the commit message.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |