git commit --verbose shows incorrect diff when pre-commit hook is used to modify files

Hi,

I am trying to use a pre-commit hook to modify files before they are
to be committed. The problem I am running into is that if I use "git
commit --verbose", which I often do so that I can see the diff, the
diff it displays in the editor is the diff before the pre-commit hook
was run rather than what the diff would be after the pre-commit was
run.

I would like to note, that the pre-commit hook is definitely running,
but when git grabs the diff seems to be in the wrong place.

I have set up a simple example on my github to show the problem.
https://github.com/fchorney/pre-commit-example

Is this intended behaviour, or perhaps an issue?

 Thanks,
 Fernando Chorney

At the time you see the diff the committing of changes has not yet been initiated. It's only after you type in the message that the ACTUAL committing starts and the hook runs.

You can print the diff of what your hook has changed by running "git diff" in it before adding changes.

12.02.2019, 00:28, "Fernando Chorney" [off-list ref]:

Hi,

I am trying to use a pre-commit hook to modify files before they are
to be committed. The problem I am running into is that if I use "git
commit --verbose", which I often do so that I can see the diff, the
diff it displays in the editor is the diff before the pre-commit hook
was run rather than what the diff would be after the pre-commit was
run.

I would like to note, that the pre-commit hook is definitely running,
but when git grabs the diff seems to be in the wrong place.

I have set up a simple example on my github to show the problem.
https://github.com/fchorney/pre-commit-example

Is this intended behaviour, or perhaps an issue?

 Thanks,
 Fernando Chorney

Hmm looks like I forgot to send my reply to this back to the mailing list.

"Hmm, so I currently have it set to run vim as my commit editor, and
enter the message in there most of the time. I can definitely see
output from the hook into the shell before my vim editor loads up that
shows me the diff and lets me add in the commit message. This leads me
to believe that the pre-commit hook is being run before the editor
(with the diff) pops up."

Does anybody else have any insight to this issue?

On Mon, Feb 11, 2019 at 4:04 PM Sergey Lukashev [off-list ref] wrote:

At the time you see the diff the committing of changes has not yet been initiated. It's only after you type in the message that the ACTUAL committing starts and the hook runs.

You can print the diff of what your hook has changed by running "git diff" in it before adding changes.

12.02.2019, 00:28, "Fernando Chorney" [off-list ref]:

quoted

Hi,

I am trying to use a pre-commit hook to modify files before they are
to be committed. The problem I am running into is that if I use "git
commit --verbose", which I often do so that I can see the diff, the
diff it displays in the editor is the diff before the pre-commit hook
was run rather than what the diff would be after the pre-commit was
run.

I would like to note, that the pre-commit hook is definitely running,
but when git grabs the diff seems to be in the wrong place.

I have set up a simple example on my github to show the problem.
https://github.com/fchorney/pre-commit-example

Is this intended behaviour, or perhaps an issue?

 Thanks,
 Fernando Chorney

Fernando Chorney [off-list ref] writes:

Hmm looks like I forgot to send my reply to this back to the mailing list.

"Hmm, so I currently have it set to run vim as my commit editor, and
enter the message in there most of the time. I can definitely see
output from the hook into the shell before my vim editor loads up that
shows me the diff and lets me add in the commit message. This leads me
to believe that the pre-commit hook is being run before the editor
(with the diff) pops up."

Does anybody else have any insight to this issue?

I do not know if it counts as an insight, but the pre-* hooks, not
limited to pre-commit, were invented for the purpose of validating
the input to an operation so that the hooks can _reject_ if the
outcome anticipated does not satisfy project's conventions; the
purpose they were invented was not because the operations wanted to
allow the input to them.  So attempting to modify the tree in
pre-commit hook, for example, is outside the scope of its design and
I wouldn't be surprised if you get an unexpected result.