* commit-msg hook possible bad behavior with -F <file>
@ 2017-12-18 16:43 Seth Raymond
2017-12-18 18:31 ` Eric Sunshine
0 siblings, 1 reply; 3+ messages in thread
From: Seth Raymond @ 2017-12-18 16:43 UTC (permalink / raw)
To: git
If a commit is invoked with -F <file>, indicating that the commit
message should be read from an existing file, the the
prepare-commit-msg and commit-msg hooks do not operate on <file>. The
first argument to the hook is always <git_repo>/COMMIT_EDITMSG, rather
than <file>.
Am I wrong in this line of thinking?
-Seth
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: commit-msg hook possible bad behavior with -F <file>
2017-12-18 16:43 commit-msg hook possible bad behavior with -F <file> Seth Raymond
@ 2017-12-18 18:31 ` Eric Sunshine
2017-12-18 21:34 ` Seth Raymond
0 siblings, 1 reply; 3+ messages in thread
From: Eric Sunshine @ 2017-12-18 18:31 UTC (permalink / raw)
To: Seth Raymond; +Cc: Git List
On Mon, Dec 18, 2017 at 11:43 AM, Seth Raymond <seth.c.raymond@gmail.com> wrote:
> If a commit is invoked with -F <file>, indicating that the commit
> message should be read from an existing file, the the
> prepare-commit-msg and commit-msg hooks do not operate on <file>. The
> first argument to the hook is always <git_repo>/COMMIT_EDITMSG, rather
> than <file>.
>
> Am I wrong in this line of thinking?
The content of <file> gets copied into COMMIT_EDITMSG, so the hook
does see the supplied message, as expected. Given that the hook is
allowed to edit the message, it makes sense that it works on
COMMIT_EDITMSG rather than on <file> directly.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: commit-msg hook possible bad behavior with -F <file>
2017-12-18 18:31 ` Eric Sunshine
@ 2017-12-18 21:34 ` Seth Raymond
0 siblings, 0 replies; 3+ messages in thread
From: Seth Raymond @ 2017-12-18 21:34 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Git List
I see that line of thinking, and agree that it makes sense. I'm having
problems with an IDE (Qt Creator) and I think I know where the problem
lies now. I believe Qt Creator doesn't actually call git commit until
after the user generates a message in the message box, meaning my
prepare-commit-msg hook is run after I've already written a message
out to <file>.
I don't think there's a fix to it due to the IDE's seemingly-poor
implementation of the git plugin. Thanks for the clarification!
On Mon, Dec 18, 2017 at 1:31 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Mon, Dec 18, 2017 at 11:43 AM, Seth Raymond <seth.c.raymond@gmail.com> wrote:
>> If a commit is invoked with -F <file>, indicating that the commit
>> message should be read from an existing file, the the
>> prepare-commit-msg and commit-msg hooks do not operate on <file>. The
>> first argument to the hook is always <git_repo>/COMMIT_EDITMSG, rather
>> than <file>.
>>
>> Am I wrong in this line of thinking?
>
> The content of <file> gets copied into COMMIT_EDITMSG, so the hook
> does see the supplied message, as expected. Given that the hook is
> allowed to edit the message, it makes sense that it works on
> COMMIT_EDITMSG rather than on <file> directly.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-12-18 21:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-18 16:43 commit-msg hook possible bad behavior with -F <file> Seth Raymond
2017-12-18 18:31 ` Eric Sunshine
2017-12-18 21:34 ` Seth Raymond
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).