Recently I had to write some automation scripts and I found
that git reset --hard actually restores each file's permissions.
That is causing both the created and the last-modified dates
of the file to get changed to the time of the git reset.
This behavior is easy to demonstrate:
echo "test" > myfile
chmod 777 myfile
git add myfile && git commit -m "Test" && git push
chmod 775 myfile
git reset --hard origin/master
After the git reset --hard command, the entire file was
checkout-ed. Instead, git should be able to check if the
content of the file changed and only if it did, check it out.
I do realize that checking the content of each file in a big
repo could result in a slow operation, but there should be a
switch/argument/option to make git reset actually check the
content of each file instead of blindly replacing it.
After reading man a few times I didn't saw any option
that'd let me do this; the only solution I'm able to think about
is actually restoring the permissions of each file to the ones
git thinks they should have before doing the git reset.
Maybe I'm wrong and there is a way for doing what I want, if
so, please correct me.
But if there isn't, should this be implemented? Are there any
reasons for not doing it?
Thank you for your attention
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html