Local history reports files changed by git pre-commit hook


I have a pre-commit hook in git that writes a 'last changed' date to the file headers.  When this hook fires, all the files it changes appear in the local history, but the diff reports that the file contents are identical.  The only way I've found to remove the files is to revert them, which makes no changes to the files themselves, but does clear them from local history.  Git diff shows no differences either before or after the local history reversion.

Can anyone tell me if I'm missing something or is this is a bug?



Local history is based on the File System changes. It is not related to git.

So when a hook changes file header, it is expected to show up in Local history.

It is not a content change, though, that is why diff says they are identical. Diff only work with text content.

BTW, reverting the file actually reverts the file header changes applied by the hook.


Sorry, by file header I mean a block of text at the top of the file with information in it.  the relevant bit looks like this:

# Last code modification:
__author__ = "$Author: TJ Ragan $"
__date__ = "$Date: 2017-03-21 15:38:37 +0000 (Tue, March 21, 2017) $"

# Start of code

where the __author__ and __date__ variables are changed by the hook.  Correct me if I'm wrong, but the local history seems to reset whenever there's a commit made, and what seems to be happening is that the local history sees a change in the file after the commit begins (but not finishes.)  This means than any files that have this block at the top show up in the local history but have identical contents (note that the diff I'm referring to is the pycharm>Local Changes>Show Diff.


So, the issue is that after you commit, all files changed by the hook are listed in the Local changes tab of the Version control toolwindow as modified (in blue)? There is a separate feature called Local history, so initially I though you refer to it.

Does it help if you execute Refresh from the Version control tool window?

Does it help if you invoke File - Syncronze?




That's correct, its listed in blue in the Local Changes tab.  Neither Refresh nor File - Synchronize makes it go away. 


Here's a screenshot of the Local Changes tab, and in front of it, the diff window for the file in blue, immediately after the commit.


Also, if I then rebase onto master (which shouldn't have any changes for the PluginModule.py file,) it disappears from the Local Changes.


What does git status executed in the command line show after the commit?


I have the exact same problem (CLion 2017.3).  "git status" in the terminal window lists the files twice, once under "Changes to be committed" and then again under "Changes not staged for commit".  That is quite unusual, is it not?

I reverted, modified another file in the editor and then committed using "git add" and "git commit" in the terminal window instead of using the IDE to commit.  That works fine, and the Local Changes list is empty afterwards.  Using "git commit -a" without a prior "git add" also works fine.

It seems like the CLion git integration does something different, that does not play well at all with commit hooks.  Any idea what?  How do I get this working properly?


@Helge Penne

You describe behavior unrelated to Local History.

As I understand, you have a pre-commit hook that modifies files you are committing. IDE uses git commit --only to commit files, and this way commits the changes from the working copy, ignoring stage. 

So the change staged by the hook stays in the stage after the commit, See https://youtrack.jetbrains.com/issue/IDEA-81139


Thanks for the link to the bug report.  It seems that perhaps adding "git --update-index -g" to the commit hook script might help, althoug it probably requires some research to verify that there are no bad side effects.

It seems to me that CLion uses git in a way that is incompatible with normal commit hooks, and that is something that you really should fix.


Why do you use the --only option to git commit?   That seems to be what causes this?



There were reasons, e.g. allow committing only selected files without modifying stage area.

This approach is compatible with hooks but requires special handling indeed.

See and related https://youtrack.jetbrains.com/issue/IDEA-83415



I don't actually see how the use of --only is compatible with commit hooks.  My experience so far is that it does not work in an acceptable way.  All commited files are left in the Local Changes list, but are unmodified and cannot be commited.  You have to drop out to the git command line after every commit.  That is not acceptable, and hardly "compatible"...

The idea in IDEA-83415 is good: Use --only only when actually necessary.  Additionally: When --only is used, do a "git --update-index -g" afterwards to clean up.


I added a comment to IDEA-83415.  I hope this can be fixed.


Until this issue addressed, I've added a post-commit script that runs "git update-index -g" as suggested. This appears to work.


Please sign in to leave a comment.