Re: [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly

[Oswald Buddenhagen <oswald.buddenhagen@gmx.de>]

On Mon, Jul 08, 2024 at 10:40:19PM +0200, Johannes Sixt wrote:
>Am 08.07.24 um 21:29 schrieb Brian Lyles:
>> Could you elaborate on why git-gui's commit message edit box should
>> behave differently than any other commit message editor? Why is there no
>> concept as "comment lines" in git-gui?
>
>First of all, Git GUI is not a commit message editor, not even in its
>git citool incarnation. You cannot instruct git commit to use it as
>message editor.
>
nobody suggested that.

>Consider the commit message that git commit presents in the editor. It
>contains the message text, instructions about how to use the tool, a
>list of files, and sometimes even patch text.
>
>Git GUI does that, too: There is the part where the message is entered,
>there is a list or two of files, and there is patch text. (OK, there are
>no instructions.) What the user writes into the part for the message
>text must go into the commit. Except that the git commit's message
>editor has a limitation: it can't tell the subsequent post processing
>with absolute certainty which text is message text due to the possible
>comment lines.
>
>Git GUI can offer this certainty because its
>corresponding section is a dedicated text edit box.
>
no, it can't, as others already pointed out. the attempt to structure
the info is woefully incomplete, pretty much inherently. the text-based
workflow is just "too core" to have interactive frontends deviate from
it. not presenting and interpreting the text as "real" git would will
always be a source of problems, regardless of how many workarounds are
added.

i'll note that the qt creator ide as an example of a git frontend does
strip the message.

>> I think that whatever path forward is taken, it needs to be predictable
>> and consistent with normal `git commit` behaviors. I think that's the
>> root problem here in my mind: From the perspective of the
>> prepare-commit-msg hook, it's impossible to do the right thing because
>> git-gui is invoking the hook consistent with normal `git commit`
>> behaviors, but then creating the commit with `git commit -F` behaviors.
>> This is an inconsistency with git-gui specifically.
>
>Good that you point that out. Git GUI does the wrong thing here. It
>should really request the form corresponding to git commit -F. The
>second option that you suggest looks correct to me:
>
firstly, there is no parameter which would actually tell it whether the
message will be stripped. the 'message' token is unreliable for this
purpose, as -F merely imposes a default on [-no]-edit and thereby
--cleanup.

secondly, it seems a bit optimistic to expect that the hook would
actually implement different output modes.

>> So it still seems like we have two real options:
>>
>> - Start washing the message, allowing the prepare-commit-msg hook to
>>   provide template-like guidance to the user regardless of if they are
>>   using git-gui or some other editor, or
>> - Pass the "message" argument along to the prepare-commit-msg hook so
>>   that it can at least avoid adding template-like content (but of course
>>   then lose the value added by that template).
>
i'm strongly in favor of the first option.
it also seems to be the much easier one to implement.