From: Junio C Hamano <gitster@pobox.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
brianmlyles <brianmlyles@gmail.com>,
git@vger.kernel.org, Sean Allred <allred.sean@gmail.com>
Subject: Re: [BUG REPORT] git-gui invokes prepare-commit-msg hook incorrectly
Date: Sat, 06 Jul 2024 11:15:04 -0700 [thread overview]
Message-ID: <xmqqtth2petz.fsf@gitster.g> (raw)
In-Reply-To: <752d41f9-6ce3-4c31-a0a2-4960c7dc1b2b@kdbg.org> (Johannes Sixt's message of "Sat, 6 Jul 2024 16:03:51 +0200")
Johannes Sixt <j6t@kdbg.org> writes:
> 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.
>
> - 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.
I agree most of the things you said, but with one reservation.
There may be two classes of comments CLI "git commit" users would be
seeing, ones coming from the "git commit" itself that describe what
CLI "git commit" does (e.g., "lines starting with '#' are ignored",
"absolutely empty message buffer aborts the command"), and others
coming from project specific template and other mechanisms that
describe what the project expects (e.g., "please keep your lines
shorter than 72 columns").
I agree that it makes perfect sense not to show the former at all to
the end-user in git-gui UI, especially if git-gui does not ignore
lines starting with '#' or abort commit with an empty message.
I am not sure if it is safe to strip the latter out of user's view,
though.
next prev parent reply other threads:[~2024-07-06 18:15 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 [this message]
2024-07-07 13:25 ` Johannes Sixt
2024-07-08 19:29 ` Brian Lyles
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=xmqqtth2petz.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=allred.sean@gmail.com \
--cc=brianmlyles@gmail.com \
--cc=git@vger.kernel.org \
--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).