From: Brian Lyles <brianmlyles@gmail.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Junio C Hamano <gitster@pobox.com>,
Eric Sunshine <sunshine@sunshineco.com>,
git@vger.kernel.org, Sean Allred <allred.sean@gmail.com>
Subject: Re: [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly
Date: Mon, 8 Jul 2024 14:29:26 -0500 [thread overview]
Message-ID: <CAHPHrSfVLLn_djR1eo06fr5OPaz2RAChv8dBJ8eJKB6b6snWnA@mail.gmail.com> (raw)
In-Reply-To: <028ae5d6-b587-4ffe-b837-38f2c13992ae@kdbg.org>
Hi Johannes,
Johannes Sixt <j6t@kdbg.org> wrote:
> My take-away is:
>
> - The commit message that is entered in the edit box must appear in the
> commit unmodified. There is no such concept as "comment lines" in git
> gui's commit message edit box. The commit-msg hook can overrule
> nevertheless as a means to enforce message hygiene, but otherwise the
> user must have full authority.
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?
Johannes Sixt <j6t@kdbg.org> wrote:
> - A commit message template and the MERGE_MSG file are populated in a
> manner that is suitable for `git commit`, i.e. can (and do) contain
> comment lines. It is, therefore, necessary to remove them when their
> text is used to populate git gui's edit box.
> I suggest that removing comment lines ("message-washing") should not
> happen as a post-processing step, but as a preprocessing step when text
> is gathered from particular sources that are known to contain
> inessential cruft.
While I agree in theory that it would be ideal for git-gui to wash only
content from sources that are known to contain content meant to be
washed, but I don't think that's possible since git-gui can't possibly
know *why* a given line appears in the message, in particular when
running the prepare-commit-msg hook.
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.
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).
The former seems most intuitive to me, though I have admittedly little
context for git-gui. Hopefully the elaboration I requested further up in
this message will shed some light things if you still disagree with
washing the message.
I'm certainly open to other ideas as well so long as they allow the hook
author the ability to add comments when the message will be washed and
not add comments when it won't be washed, regardless of whether git-gui
is in use.
--
Thank you,
Brian Lyles
next prev parent reply other threads:[~2024-07-08 19:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-05 19:23 [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly brianmlyles
2024-07-05 19:57 ` Eric Sunshine
2024-07-05 20:56 ` Sean Allred
2024-07-05 21:47 ` Eric Sunshine
2024-07-06 14:03 ` Johannes Sixt
2024-07-06 18:15 ` Junio C Hamano
2024-07-07 13:25 ` Johannes Sixt
2024-07-08 19:29 ` Brian Lyles [this message]
2024-07-08 20:40 ` Johannes Sixt
2024-08-07 18:19 ` Oswald Buddenhagen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHPHrSfVLLn_djR1eo06fr5OPaz2RAChv8dBJ8eJKB6b6snWnA@mail.gmail.com \
--to=brianmlyles@gmail.com \
--cc=allred.sean@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).