Question

I implemented a git-hook to scan my commits through pyflakes and jshint, and after reading Yipit’s commentary on why most pre-commit hooks are broken, I chose to implement his git stash and git stash pop suggestions.

Unfortunately, git stash pop marks the files as ‘modified’, which then causes my IDE to warn me whenever I go back to that page ” modified on disk. Reread from disk?” It then asks “Are you sure you want to edit this buffer?” and finally “Are you sure you want to save this buffer over a modified file?”

I appreciate everything it’s trying to do for me, but it’s asking me about functionally non-existent “changes”.

Short of playing weird guessing games with touch is there some way to prevent git stash pop from marking all of the files it touched as changed?

Answer 1

I don’t think so (timestamp is altered, as mentioned in “GIT: Adding Local Changes to Non-Current Branch” for instance).

The easiest way would be configure your IDE to refresh automatically.

For Eclipse for instance, this would be the setting “Refresh on Access”.

---

Another approach would be to keep another local repo (one where there is no local modification ever, so no need to stash).
Your pre-commit hook remains in your current repo.

Your hook would use your current index (what you have added), but the other work-tree repo.
For that, you would need to commit with:

git commit --work-tree=/path/to/other/local/repo -m "my commit message"

If the hook doesn’t fail, you can have a post-commit hook (still in your current repo) go to the other repo, and pull the current branch, updating its (pristine) working tree.

cd /path/to/other/local/repo 
git --work-tree=/path/to/other/local/repo --git-dir=/path/to/other/local/repo/.git pull

(Note how your hook, which lives in your first repo, needs to specify work-tree and git-dir of the second repo, in order to work properly).
That is a simplified proposal as it doesn’t take into account the current branch you are working on (it assumes only one branch ‘master’).
But you can detect the branch and adapt from there the hook (with the proper checkout and switch to the right branch).

After the second repo update of its working tree (by the post-commit hook of the first repo), that second repo is ready to serve as a pristine working tree against which your pre-commit hook (of your first and current repo) can safely operate.