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.
