git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Johannes Sixt <j6t@kdbg.org>
Date
Jul 8, 2024, 20:40 UTC
Message-ID
<ab9824ee-65e1-4e4b-b739-205f2c5d24fe@kdbg.org>
In-Reply-To
<CAHPHrSfVLLn_djR1eo06fr5OPaz2RAChv8dBJ8eJKB6b6snWnA@mail.gmail.com>
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.

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.

Show 7 quoted lines
> 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:

Show 8 quoted lines
> 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).
-- Hannes
Previous: Brian LylesNext: Oswald Buddenhagen
Message 9 of 10 in “[BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly”
  1. brianmlylesJul 5, 2024
  2. Eric SunshineJul 5, 2024
  3. Sean AllredJul 5, 2024
  4. Eric SunshineJul 5, 2024
  5. Johannes SixtJul 6, 2024
  6. Junio C HamanoJul 6, 2024
  7. Johannes SixtJul 7, 2024
  8. Brian LylesJul 8, 2024
  9. Johannes SixtJul 8, 2024
  10. Oswald BuddenhagenAug 7, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.