Question: regarding restoreTree()

[iamjochem]

hi there,

Having encountered the "linting-unstaged-file-during-pre-commit" problem I went looking for a fix ... every solution I've found seems to tackle this the same, namely with git stash ... it's great to be able to look at your implementation (amongst others) and quickly make improvements to my own pre-commit script.

I'm left with a question, in addition to doing git stash pop, you also perform a git reset --hard, I was wondering why you perform this reset?

thanks!

[kazazor]

Hi @iamjochem, thanks for supporting my implementation :)

The reason I'm using the reset is to restore the tree of git. Most of the implementations I saw do not do that but then something happens in some cases that probably most of the people don't know about it.

Let's consider this case: You have a lint task that runs on pre-commit hook. You're modifying the file x.js and you git add it. Now you left to do something else and didn't commit yet. You then return to this file and perform more changes that should not be part of the commit on x.js. You're trying to commit the stagged changes you git add and your lint task fails the commit. If you haven't restored the tree what will happen is the stash pop command will try to auto merge x.js and then it will have the unstagged changes now be in the stagged changes - which is something you did not want.

So that is to take care of situations where you have the same files in the stagged and unstagged changes.

I hope this helps to better understand it. Let me know if it does so I could close the question.

P.S: You can use this package instead of creating your own 😄 I could use the help to close the issues I have here open haha

[kazazor]

And in any case your question now tells me that it is not clear from the code why this is happening, so I should add a comment there :)

[iamjochem]

@kazazor - thank you very much for the detailed explanation! ]

... I managed to reproduce the "broken state" that can occur without the git reset --hard that you do ... and I have seen that including the git reset --hard does indeed do the right thing (I admit to not really understanding why ... git reset is still scary if you ask me!)

I have a pre-existing git-hook thing going on, replacing that with another tool/project is not really feasable for me ATM.

regarding your open issues, I couldn't help with Windows issues even if I wanted to ;-) but I might have a hint for #18 ... I tackle this (in my bash pre-commit script) by checking the exit code of git diff e.g.:

if git diff --quiet --; then
    DO_STASH=0
else
    DO_STASH=1
fi

maybe you can use this ? rgds, Jochem

[kazazor]

Thanks for the tip :) Yes I was aiming on doing something similar with git status, but your tip is better. Thanks for that!