{"thread":{"id":"61741","subject":"[BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly","startedAt":"2024-07-05T19:23:05Z","lastAt":"2024-08-07T18:19:37Z","messageCount":10,"participants":["brianmlyles","Eric Sunshine","Sean Allred","Johannes Sixt","Junio C Hamano","Brian Lyles","Oswald Buddenhagen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"498117","messageId":"17df67804ef7a3c8.df629cdadcf4ea15.524a056283063601@EPIC94403","threadId":"61741","inReplyTo":null,"subject":"[BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly","fromName":"brianmlyles","fromEmail":"brianmlyles@gmail.com","sentAt":"2024-07-05T19:23:03Z","receivedAt":"2024-07-05T19:23:05Z","isPatch":false,"sender":{"key":"brianmlyles@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1123282?v=4"},"body":"I noticed that commits from certain users were ending up in our\nrepository with comment-like lines in the commit message. I traced the\ncause back to the combination of:\n\n- Those users are using git-gui to make their commits\n- A `prepare-commit-msg` hook is adding a dynamic commit message\n template using comment lines starting with `#`\n- git-gui creates the commit in a way that circumvents the message\n washing similar to if one used `git commit -F`, but invokes the\n `prepare-commit-msg` hook without any additional arguments like\n \"message\" [1] that would tell the hook that `-F` is being used\n\n[1]: https://git-scm.com/docs/githooks#_prepare_commit_msg\n\nThe result here is that even though the `prepare-commit-msg` hook is\nalready correctly short-circuiting when given the \"message\" parameter,\nit is providing these comment lines when called by git-gui, and thus the\ncommits have these comment lines in them.\n\nThis seems like a bug in git-gui. I see two fixes, but I'm not sure\nwhich is more correct:\n\n- Have git-gui pass \"message\" as an argument to the\n `prepare-commit-msg` hook so that the hook knows that `-F`-like\n behavior is being used\n- Have git-gui create the commit in a way that causes the message to be\n washed\n\nThe latter seems like it would be more consistent with other workflows\nwhere the user is seeing the message in an editor, so my instinct is\nthat it would be the better fix.\n\n-- \nThank you,\nBrian Lyles\n"},{"id":"498119","messageId":"CAPig+cRQPrtGBTxM49nUeHvsVr0qEOnKZ5W_4by=A9mXEsR3DA@mail.gmail.com","threadId":"61741","inReplyTo":"17df67804ef7a3c8.df629cdadcf4ea15.524a056283063601@EPIC94403","subject":"Re: [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-07-05T19:57:09Z","receivedAt":"2024-07-05T19:57:21Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"[cc: +j6t]\n\nOn Fri, Jul 5, 2024 at 3:23 PM brianmlyles wrote:\n> I noticed that commits from certain users were ending up in our\n> repository with comment-like lines in the commit message. [...]\n> [...]\n> This seems like a bug in git-gui. I see two fixes, but I'm not sure\n> which is more correct:\n> [...]\n> - Have git-gui create the commit in a way that causes the message to be\n> washed\n>\n> The latter seems like it would be more consistent with other workflows\n> where the user is seeing the message in an editor, so my instinct is\n> that it would be the better fix.\n\nA patch to make git-gui strip comment lines had been previously\napplied[1,2], however, it badly broke git-gui when running with old\nTcl versions, such as on macOS[3,4]. The breakage was not\ninsurmountable, and a patch[5,6] was submitted to resolve it.\nUnfortunately, the then-maintainer of git-gui lost interest in the\nproject about that point, thus left the issue hanging. Thus, to this\nday, git-gui still doesn't strip comment lines.\n\nResurrecting these patches would be one way forward, assuming the new\ngit-gui maintainer[7] (who is Cc:'d) would be interested.\n\n[1]: v2: https://lore.kernel.org/git/20210218181937.83419-1-me@yadavpratyush.com/\n[2]: v1: https://lore.kernel.org/git/20210202200301.44282-1-me@yadavpratyush.com/\n[3]: https://lore.kernel.org/git/CAPig+cT-sfgMDi9-6AEKF85NtOiXeqddJjk-pYuhDtTVAE-UEw@mail.gmail.com/\n[4]: https://lore.kernel.org/git/CAPig+cSC8uNfoAjDKdBNheod9_0-pCD-K_2kwt+J8USnoyQ7Aw@mail.gmail.com/\n[5]: https://lore.kernel.org/git/20210228231110.24076-1-sunshine@sunshineco.com/\n[6]: https://lore.kernel.org/git/CAPig+cRQN4PjfxEOZ8ZBA_uttsRPS8DPDgToM_JFvichDDh_HQ@mail.gmail.com/\n[7]: https://lore.kernel.org/git/0241021e-0b17-4031-ad9f-8abe8e0c0097@kdbg.org/\n"},{"id":"498123","messageId":"m034onpng4.fsf@epic96565.epic.com","threadId":"61741","inReplyTo":"CAPig+cRQPrtGBTxM49nUeHvsVr0qEOnKZ5W_4by=A9mXEsR3DA@mail.gmail.com","subject":"Re: [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly","fromName":"Sean Allred","fromEmail":"allred.sean@gmail.com","sentAt":"2024-07-05T20:56:43Z","receivedAt":"2024-07-05T20:56:46Z","isPatch":false,"sender":{"key":"allred.sean@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2082195?v=4"},"body":"Eric Sunshine writes:\n> On Fri, Jul 5, 2024 at 3:23 PM brianmlyles wrote:\n>> I noticed that commits from certain users were ending up in our\n>> repository with comment-like lines in the commit message. [...]\n>> [...]\n>> This seems like a bug in git-gui. I see two fixes, but I'm not sure\n>> which is more correct:\n>> [...]\n>> - Have git-gui create the commit in a way that causes the message to be\n>> washed\n>>\n>> The latter seems like it would be more consistent with other workflows\n>> where the user is seeing the message in an editor, so my instinct is\n>> that it would be the better fix.\n\nThere is a third option -- new plumbing in git (a la\ngit-interpret-trailers) to expose the logic of `cleanup_message`. This\ncomes with some nice flexibility, but introduces complexity around\ntransferring state (e.g. passed options to git-commit) that would\nprobably be best to avoid.\n\nThe second option above does seem simpler.\n\n> A patch to make git-gui strip comment lines had been previously\n> applied[1,2], however, it badly broke git-gui when running with old\n> Tcl versions, such as on macOS[3,4]. The breakage was not\n> insurmountable, and a patch[5,6] was submitted to resolve it.\n> Unfortunately, the then-maintainer of git-gui lost interest in the\n> project about that point, thus left the issue hanging. Thus, to this\n> day, git-gui still doesn't strip comment lines.\n>\n> Resurrecting these patches would be one way forward, assuming the new\n> git-gui maintainer[7] (who is Cc:'d) would be interested.\n>\n> [1]: v2: https://lore.kernel.org/git/20210218181937.83419-1-me@yadavpratyush.com/\n> [2]: v1: https://lore.kernel.org/git/20210202200301.44282-1-me@yadavpratyush.com/\n> [3]: https://lore.kernel.org/git/CAPig+cT-sfgMDi9-6AEKF85NtOiXeqddJjk-pYuhDtTVAE-UEw@mail.gmail.com/\n> [4]: https://lore.kernel.org/git/CAPig+cSC8uNfoAjDKdBNheod9_0-pCD-K_2kwt+J8USnoyQ7Aw@mail.gmail.com/\n> [5]: https://lore.kernel.org/git/20210228231110.24076-1-sunshine@sunshineco.com/\n> [6]: https://lore.kernel.org/git/CAPig+cRQN4PjfxEOZ8ZBA_uttsRPS8DPDgToM_JFvichDDh_HQ@mail.gmail.com/\n> [7]: https://lore.kernel.org/git/0241021e-0b17-4031-ad9f-8abe8e0c0097@kdbg.org/\n\nI haven't looked super closely at the patches you've linked, Eric, but\nit seems like those are specific to stripping comment characters. As\nI've noted elsewhere[1], there's potentially more to strip than just\ncomments (like patch scissors). I suspect the only paths forward to\nguarantee that message-washing happens would either be an option to\ngit-commit to explicitly enable it OR (probably preferred) have git-gui\ninvoke git-commit with an appropriate editor instead of using -F.\n\n[1]: https://lore.kernel.org/git/m0h6d3pphu.fsf@epic96565.epic.com/T/#u\n\n-Sean\n\n-- \nSean Allred\n"},{"id":"498128","messageId":"CAPig+cS2r-b22ikZZ6QHpzfneQ07n6s=E40Sb+QYmCnezVFAww@mail.gmail.com","threadId":"61741","inReplyTo":"m034onpng4.fsf@epic96565.epic.com","subject":"Re: [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-07-05T21:47:36Z","receivedAt":"2024-07-05T21:47:48Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Jul 5, 2024 at 4:56 PM Sean Allred wrote:\n> Eric Sunshine writes:\n> > On Fri, Jul 5, 2024 at 3:23 PM brianmlyles wrote:\n> >> - Have git-gui create the commit in a way that causes the message to be\n> >> washed\n>>\n> > A patch to make git-gui strip comment lines had been previously\n> > applied[1,2], however, it badly broke git-gui when running with old\n> > Tcl versions, such as on macOS[3,4]. The breakage was not\n> > insurmountable, and a patch[5,6] was submitted to resolve it.\n> > Unfortunately, the then-maintainer of git-gui lost interest in the\n> > project about that point, thus left the issue hanging. Thus, to this\n> > day, git-gui still doesn't strip comment lines.\n>\n> There is a third option -- new plumbing in git (a la\n> git-interpret-trailers) to expose the logic of `cleanup_message`. This\n> comes with some nice flexibility, but introduces complexity around\n> transferring state (e.g. passed options to git-commit) that would\n> probably be best to avoid.\n\nCould the cleanup_message() functionality be exposed as a new option\nof git-stripspace?\n\n> I haven't looked super closely at the patches you've linked, Eric, but\n> it seems like those are specific to stripping comment characters. As\n> I've noted elsewhere[1], there's potentially more to strip than just\n> comments (like patch scissors). I suspect the only paths forward to\n> guarantee that message-washing happens would either be an option to\n> git-commit to explicitly enable it OR (probably preferred) have git-gui\n> invoke git-commit with an appropriate editor instead of using -F.\n>\n> [1]: https://lore.kernel.org/git/m0h6d3pphu.fsf@epic96565.epic.com/T/#u\n\nYou're correct that my interest in the issue was strictly due to the\nannoyance of git-gui failing to strip comments (in particular, the\nlist of conflicted files automatically inserted into\n.git/MERGE_MSG)[*]. The subject of patch scissors did not come up in\nthe linked discussions, and it wasn't apparent from Brian's message\nwhich started this thread that he was also concerned about patch\nscissors (his message mentioned only comments).\n\nI responded separately to the message you cited above.\n\n[*]: https://lore.kernel.org/git/CAPig+cTQaPTNnGcd583B=xoVUR1qPb372Y_x9szROfMcA5h+tA@mail.gmail.com/\n"},{"id":"498165","messageId":"752d41f9-6ce3-4c31-a0a2-4960c7dc1b2b@kdbg.org","threadId":"61741","inReplyTo":"CAPig+cS2r-b22ikZZ6QHpzfneQ07n6s=E40Sb+QYmCnezVFAww@mail.gmail.com","subject":"Re: [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2024-07-06T14:03:51Z","receivedAt":"2024-07-06T14:04:07Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 05.07.24 um 23:47 schrieb Eric Sunshine:\n> On Fri, Jul 5, 2024 at 4:56 PM Sean Allred wrote:\n>> Eric Sunshine writes:\n>>> On Fri, Jul 5, 2024 at 3:23 PM brianmlyles wrote:\n>>>> - Have git-gui create the commit in a way that causes the message to be\n>>>> washed\n>>>\n>>> A patch to make git-gui strip comment lines had been previously\n>>> applied[1,2], however, it badly broke git-gui when running with old\n>>> Tcl versions, such as on macOS[3,4]. The breakage was not\n>>> insurmountable, and a patch[5,6] was submitted to resolve it.\n>>> Unfortunately, the then-maintainer of git-gui lost interest in the\n>>> project about that point, thus left the issue hanging. Thus, to this\n>>> day, git-gui still doesn't strip comment lines.\n>>\n>> There is a third option -- new plumbing in git (a la\n>> git-interpret-trailers) to expose the logic of `cleanup_message`. This\n>> comes with some nice flexibility, but introduces complexity around\n>> transferring state (e.g. passed options to git-commit) that would\n>> probably be best to avoid.\n> \n> Could the cleanup_message() functionality be exposed as a new option\n> of git-stripspace?\n> \n>> I haven't looked super closely at the patches you've linked, Eric, but\n>> it seems like those are specific to stripping comment characters. As\n>> I've noted elsewhere[1], there's potentially more to strip than just\n>> comments (like patch scissors). I suspect the only paths forward to\n>> guarantee that message-washing happens would either be an option to\n>> git-commit to explicitly enable it OR (probably preferred) have git-gui\n>> invoke git-commit with an appropriate editor instead of using -F.\n>>\n>> [1]: https://lore.kernel.org/git/m0h6d3pphu.fsf@epic96565.epic.com/T/#u\n> \n> You're correct that my interest in the issue was strictly due to the\n> annoyance of git-gui failing to strip comments (in particular, the\n> list of conflicted files automatically inserted into\n> .git/MERGE_MSG)[*]. The subject of patch scissors did not come up in\n> the linked discussions, and it wasn't apparent from Brian's message\n> which started this thread that he was also concerned about patch\n> scissors (his message mentioned only comments).\n> \n> I responded separately to the message you cited above.\n> \n> [*]: https://lore.kernel.org/git/CAPig+cTQaPTNnGcd583B=xoVUR1qPb372Y_x9szROfMcA5h+tA@mail.gmail.com/\n\nLet's take a step back and ask why is there cruft in a commit message\nthat needs to be cleaned in the first place? It is because with the\ncommand line `git commit` there is no side-channel that could\ncommunicate the circumstances that lead up to a commit. This is not the\ncase in git gui. There are many instruments that can be used at the same\ntime that the commit message is authored; there is no reason to have a\nlist of conflicted files or the commit's patch text in the commit message.\n\nMy take-away is:\n\n- The commit message that is entered in the edit box must appear in the\ncommit unmodified. There is no such concept as \"comment lines\" in git\ngui's commit message edit box. The commit-msg hook can overrule\nnevertheless as a means to enforce message hygiene, but otherwise the\nuser must have full authority.\n\n- A commit message template and the MERGE_MSG file are populated in a\nmanner that is suitable for `git commit`, i.e. can (and do) contain\ncomment lines. It is, therefore, necessary to remove them when their\ntext is used to populate git gui's edit box.\n\nI suggest that removing comment lines (\"message-washing\") should not\nhappen as a post-processing step, but as a preprocessing step when text\nis gathered from particular sources that are known to contain\ninessential cruft.\n\n-- Hannes\n\n"},{"id":"498171","messageId":"xmqqtth2petz.fsf@gitster.g","threadId":"61741","inReplyTo":"752d41f9-6ce3-4c31-a0a2-4960c7dc1b2b@kdbg.org","subject":"Re: [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-06T18:15:04Z","receivedAt":"2024-07-06T18:15:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> My take-away is:\n>\n> - The commit message that is entered in the edit box must appear in the\n> commit unmodified. There is no such concept as \"comment lines\" in git\n> gui's commit message edit box. The commit-msg hook can overrule\n> nevertheless as a means to enforce message hygiene, but otherwise the\n> user must have full authority.\n>\n> - A commit message template and the MERGE_MSG file are populated in a\n> manner that is suitable for `git commit`, i.e. can (and do) contain\n> comment lines. It is, therefore, necessary to remove them when their\n> text is used to populate git gui's edit box.\n>\n> I suggest that removing comment lines (\"message-washing\") should not\n> happen as a post-processing step, but as a preprocessing step when text\n> is gathered from particular sources that are known to contain\n> inessential cruft.\n\nI agree most of the things you said, but with one reservation.\n\nThere may be two classes of comments CLI \"git commit\" users would be\nseeing, ones coming from the \"git commit\" itself that describe what\nCLI \"git commit\" does (e.g., \"lines starting with '#' are ignored\",\n\"absolutely empty message buffer aborts the command\"), and others\ncoming from project specific template and other mechanisms that\ndescribe what the project expects (e.g., \"please keep your lines\nshorter than 72 columns\").\n\nI agree that it makes perfect sense not to show the former at all to\nthe end-user in git-gui UI, especially if git-gui does not ignore\nlines starting with '#' or abort commit with an empty message.\n\nI am not sure if it is safe to strip the latter out of user's view,\nthough.\n"},{"id":"498192","messageId":"028ae5d6-b587-4ffe-b837-38f2c13992ae@kdbg.org","threadId":"61741","inReplyTo":"xmqqtth2petz.fsf@gitster.g","subject":"Re: [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2024-07-07T13:25:25Z","receivedAt":"2024-07-07T13:26:03Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 06.07.24 um 20:15 schrieb Junio C Hamano:\n> There may be two classes of comments CLI \"git commit\" users would be\n> seeing, ones coming from the \"git commit\" itself that describe what\n> CLI \"git commit\" does (e.g., \"lines starting with '#' are ignored\",\n> \"absolutely empty message buffer aborts the command\"), and others\n> coming from project specific template and other mechanisms that\n> describe what the project expects (e.g., \"please keep your lines\n> shorter than 72 columns\").\n> \n> I agree that it makes perfect sense not to show the former at all to\n> the end-user in git-gui UI, especially if git-gui does not ignore\n> lines starting with '#' or abort commit with an empty message.\n> \n> I am not sure if it is safe to strip the latter out of user's view,\n> though.\n\nI see your point. These two kinds of comments have different topics\n(usage of the tool being used vs. project conventions concerning the\ncommit message itself).\n\nIt is easy to clean only MERGE_MSG to solve the annoyance caused by the\nlist of conflicted files. We could have this a first step, and then we\ncan consider later whether cleaning other sources is worth it. But it\nwould not help OP, where the comments come from the commit message template.\n\n-- Hannes\n\n"},{"id":"498308","messageId":"CAHPHrSfVLLn_djR1eo06fr5OPaz2RAChv8dBJ8eJKB6b6snWnA@mail.gmail.com","threadId":"61741","inReplyTo":"028ae5d6-b587-4ffe-b837-38f2c13992ae@kdbg.org","subject":"Re: [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly","fromName":"Brian Lyles","fromEmail":"brianmlyles@gmail.com","sentAt":"2024-07-08T19:29:26Z","receivedAt":"2024-07-08T19:30:05Z","isPatch":false,"sender":{"key":"brianmlyles@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1123282?v=4"},"body":"Hi Johannes,\n\nJohannes Sixt wrote:\n> My take-away is:\n>\n> - The commit message that is entered in the edit box must appear in the\n> commit unmodified. There is no such concept as \"comment lines\" in git\n> gui's commit message edit box. The commit-msg hook can overrule\n> nevertheless as a means to enforce message hygiene, but otherwise the\n> user must have full authority.\n\nCould you elaborate on why git-gui's commit message edit box should\nbehave differently than any other commit message editor? Why is there no\nconcept as \"comment lines\" in git-gui?\n\nJohannes Sixt wrote:\n> - A commit message template and the MERGE_MSG file are populated in a\n> manner that is suitable for `git commit`, i.e. can (and do) contain\n> comment lines. It is, therefore, necessary to remove them when their\n> text is used to populate git gui's edit box.\n\n> I suggest that removing comment lines (\"message-washing\") should not\n> happen as a post-processing step, but as a preprocessing step when text\n> is gathered from particular sources that are known to contain\n> inessential cruft.\n\nWhile I agree in theory that it would be ideal for git-gui to wash only\ncontent from sources that are known to contain content meant to be\nwashed, but I don't think that's possible since git-gui can't possibly\nknow *why* a given line appears in the message, in particular when\nrunning the prepare-commit-msg hook.\n\nI think that whatever path forward is taken, it needs to be predictable\nand consistent with normal `git commit` behaviors. I think that's the\nroot problem here in my mind: From the perspective of the\nprepare-commit-msg hook, it's impossible to do the right thing because\ngit-gui is invoking the hook consistent with normal `git commit`\nbehaviors, but then creating the commit with `git commit -F` behaviors.\nThis is an inconsistency with git-gui specifically.\n\nSo it still seems like we have two real options:\n\n- Start washing the message, allowing the prepare-commit-msg hook to\n provide template-like guidance to the user regardless of if they are\n using git-gui or some other editor, or\n- Pass the \"message\" argument along to the prepare-commit-msg hook so\n that it can at least avoid adding template-like content (but of course\n then lose the value added by that template).\n\nThe former seems most intuitive to me, though I have admittedly little\ncontext for git-gui. Hopefully the elaboration I requested further up in\nthis message will shed some light things if you still disagree with\nwashing the message.\n\nI'm certainly open to other ideas as well so long as they allow the hook\nauthor the ability to add comments when the message will be washed and\nnot add comments when it won't be washed, regardless of whether git-gui\nis in use.\n\n-- \nThank you,\nBrian Lyles\n"},{"id":"498318","messageId":"ab9824ee-65e1-4e4b-b739-205f2c5d24fe@kdbg.org","threadId":"61741","inReplyTo":"CAHPHrSfVLLn_djR1eo06fr5OPaz2RAChv8dBJ8eJKB6b6snWnA@mail.gmail.com","subject":"Re: [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2024-07-08T20:40:19Z","receivedAt":"2024-07-08T20:40:28Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 08.07.24 um 21:29 schrieb Brian Lyles:\n> Could you elaborate on why git-gui's commit message edit box should\n> behave differently than any other commit message editor? Why is there no\n> concept as \"comment lines\" in git-gui?\n\nFirst of all, Git GUI is not a commit message editor, not even in its\ngit citool incarnation. You cannot instruct git commit to use it as\nmessage editor.\n\nConsider the commit message that git commit presents in the editor. It\ncontains the message text, instructions about how to use the tool, a\nlist of files, and sometimes even patch text.\n\nGit GUI does that, too: There is the part where the message is entered,\nthere is a list or two of files, and there is patch text. (OK, there are\nno instructions.) What the user writes into the part for the message\ntext must go into the commit. Except that the git commit's message\neditor has a limitation: it can't tell the subsequent post processing\nwith absolute certainty which text is message text due to the possible\ncomment lines. Git GUI can offer this certainty because its\ncorresponding section is a dedicated text edit box.\n\n> I think that whatever path forward is taken, it needs to be predictable\n> and consistent with normal `git commit` behaviors. I think that's the\n> root problem here in my mind: From the perspective of the\n> prepare-commit-msg hook, it's impossible to do the right thing because\n> git-gui is invoking the hook consistent with normal `git commit`\n> behaviors, but then creating the commit with `git commit -F` behaviors.\n> This is an inconsistency with git-gui specifically.\n\nGood that you point that out. Git GUI does the wrong thing here. It\nshould really request the form corresponding to git commit -F. The\nsecond option that you suggest looks correct to me:\n\n> So it still seems like we have two real options:\n> \n> - Start washing the message, allowing the prepare-commit-msg hook to\n> provide template-like guidance to the user regardless of if they are\n> using git-gui or some other editor, or\n> - Pass the \"message\" argument along to the prepare-commit-msg hook so\n> that it can at least avoid adding template-like content (but of course\n> then lose the value added by that template).\n\n-- Hannes\n\n"},{"id":"500338","messageId":"ZrO6tM0fZLly1bPA@ugly","threadId":"61741","inReplyTo":"ab9824ee-65e1-4e4b-b739-205f2c5d24fe@kdbg.org","subject":"Re: [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2024-08-07T18:19:32Z","receivedAt":"2024-08-07T18:19:37Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Mon, Jul 08, 2024 at 10:40:19PM +0200, Johannes Sixt wrote:\n>Am 08.07.24 um 21:29 schrieb Brian Lyles:\n>> Could you elaborate on why git-gui's commit message edit box should\n>> behave differently than any other commit message editor? Why is there no\n>> concept as \"comment lines\" in git-gui?\n>\n>First of all, Git GUI is not a commit message editor, not even in its\n>git citool incarnation. You cannot instruct git commit to use it as\n>message editor.\n>\nnobody suggested that.\n\n>Consider the commit message that git commit presents in the editor. It\n>contains the message text, instructions about how to use the tool, a\n>list of files, and sometimes even patch text.\n>\n>Git GUI does that, too: There is the part where the message is entered,\n>there is a list or two of files, and there is patch text. (OK, there are\n>no instructions.) What the user writes into the part for the message\n>text must go into the commit. Except that the git commit's message\n>editor has a limitation: it can't tell the subsequent post processing\n>with absolute certainty which text is message text due to the possible\n>comment lines.\n>\n>Git GUI can offer this certainty because its\n>corresponding section is a dedicated text edit box.\n>\nno, it can't, as others already pointed out. the attempt to structure\nthe info is woefully incomplete, pretty much inherently. the text-based\nworkflow is just \"too core\" to have interactive frontends deviate from\nit. not presenting and interpreting the text as \"real\" git would will\nalways be a source of problems, regardless of how many workarounds are\nadded.\n\ni'll note that the qt creator ide as an example of a git frontend does\nstrip the message.\n\n>> I think that whatever path forward is taken, it needs to be predictable\n>> and consistent with normal `git commit` behaviors. I think that's the\n>> root problem here in my mind: From the perspective of the\n>> prepare-commit-msg hook, it's impossible to do the right thing because\n>> git-gui is invoking the hook consistent with normal `git commit`\n>> behaviors, but then creating the commit with `git commit -F` behaviors.\n>> This is an inconsistency with git-gui specifically.\n>\n>Good that you point that out. Git GUI does the wrong thing here. It\n>should really request the form corresponding to git commit -F. The\n>second option that you suggest looks correct to me:\n>\nfirstly, there is no parameter which would actually tell it whether the\nmessage will be stripped. the 'message' token is unreliable for this\npurpose, as -F merely imposes a default on [-no]-edit and thereby\n--cleanup.\n\nsecondly, it seems a bit optimistic to expect that the hook would\nactually implement different output modes.\n\n>> So it still seems like we have two real options:\n>>\n>> - Start washing the message, allowing the prepare-commit-msg hook to\n>> provide template-like guidance to the user regardless of if they are\n>> using git-gui or some other editor, or\n>> - Pass the \"message\" argument along to the prepare-commit-msg hook so\n>> that it can at least avoid adding template-like content (but of course\n>> then lose the value added by that template).\n>\ni'm strongly in favor of the first option.\nit also seems to be the much easier one to implement.\n\n"}]}