3

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?

Elf Sternberg
  • 16,129
  • 6
  • 60
  • 68

2 Answers2

0

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Note to self: And that was my **7000th answer** on Stack Overflow (in 52 months), 6 months after the [6000th answer](http://stackoverflow.com/a/11644343/6309). Before that [5000th answer](http://stackoverflow.com/a/7917396/6309), [4000th answer](http://stackoverflow.com/a/4953561/6309), [3000th answer](http://stackoverflow.com/a/3074849/6309), [2000th answer](http://stackoverflow.com/a/2027976/6309), and [1000th answer](http://stackoverflow.com/a/665252/6309). – VonC Jan 11 '13 at 16:02
0

Are you sure the changes are non-existant? If the file is showing as modified, something has changed, even if it's whitespace or the permission (executable state) of a file. You can use git diff to see the changes. You can also review the changes by using the git commit -av command (the -v flag will display the diff of the commit).

Your IDE is going to keep a current "buffer" state of a file. If that file changes on the disk (which git stash pop|apply will do), the IDE will recognize this and unless you have it set to automatically refresh the file (usually in your IDE settings/preferences), it may prompt you if you want to save the current buffer as a new file -- which is not typically necessary when using git -- or to re-load the buffer with the changed state of the file.

Highway of Life
  • 22,803
  • 16
  • 52
  • 80