{"thread":{"id":"61744","subject":"Re: Should commit-msg hook receive the washed message?","startedAt":"2024-07-05T22:07:46Z","lastAt":"2024-07-05T22:07:46Z","messageCount":1,"participants":["brianmlyles"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"498129","messageId":"17df707d08b81dc4.df629cdadcf4ea15.524a056283063601@EPIC94403","threadId":"61744","inReplyTo":null,"subject":"Re: Should commit-msg hook receive the washed message?","fromName":"brianmlyles","fromEmail":"brianmlyles@gmail.com","sentAt":"2024-07-05T22:07:44Z","receivedAt":"2024-07-05T22:07:46Z","isPatch":false,"sender":{"key":"brianmlyles@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1123282?v=4"},"body":"> Eric Sunshine <sunshine@sunshineco.com> wrote:\n> \n> The idea you proposed in a different thread[2] of exposing\n> cleanup_message() functionality as a user-facing utility which a hook\n> can call on an as-needed basis may make more sense(?).\n> \n> [2]: https://lore.kernel.org/git/m034onpng4.fsf@epic96565.epic.com/\n\nI don't think that would suffice for our use case. Specifically, the\ncommit-msg hook has no way to know if it's looking at a message that\nwill be washed, or will not. For example, let's say a commit-msg hook\naims to enforce a 72-character hard-wrap policy. If a line starts with\n`#`, what is the hook supposed to do?\n\n- If the commit was created using `git commit` and the user's normal\n  editor is invoked, the hook should *not* evaluate any line starting\n  with `#` because that line will be removed prior to creating the\n  commit as part of the message washing process.\n- If the commit was created using `git commit -m`, the hook *should*\n  evaluate any line starting with `#` because that line will not be\n  removed by washing.\n\nThis challenge also exists for the patch scissors and any content\nfollowing it. That could have been added by git because the user called\n`git commit -v` (most likely), but it also could in theory have been\nadded by the user, in which case the patch (or patch-like content) ends\nup in the final commit message as well. The hook has no way to know\nwhether the commit was initiated via `git commit -v` or not. The\nreal-world use case here could be a commit-msg hook that adds a trailer:\nif the patch will be removed during washing, then using `git\ninterpret-trailers` to add the trailer (which places it *before* the\npatch) is fine. If the patch will not be removed during washing, then \n`git interpret-trailers` ends up putting the trailer in the middle of\nthe final message between the subject/body and the patch, then the patch\nisn't removed and thus it's not a valid trailer.\n\nUltimately, the hook doesn't know what will happen to the message after\nit runs, and thus doesn't know if a given line is guaranteed to be part\nof the final commit message. This presents these edge case challenges\nwhen attempting to implement the hook.\n\nIf the hook either were always called with the final proposed commit\nmessage, or if it knew that the message would be washed after being\nexecuted, then we'd have options for handling these edge cases.\n\n-- \nThanks,\nBrian Lyles\n"}]}