threads / discuss / 47459
Subject: commit-msg hook possible bad behavior with -F <file>
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
Eric SunshineRe: commit-msg hook possible bad behavior with -F <file>
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.
Re: commit-msg hook possible bad behavior with -F <file>
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.