Git reset should be able to ignore file permissions

Question

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" & 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?

Answer 1

> echo "test" > myfile
> chmod 777 myfile
> git add myfile && git commit -m "Test" && git push
> chmod 775 myfile
> git reset --hard origin/master

This doesn't tell what the permissions are in origin/master.

If the last line was "git reset --hard HEAD", then it wouldn't touch myfile (it's executable in the worktree and in HEAD, so Git doesn't need to change it). Neither the x bit, nor the ctime or mtime.

If you reset the file to a point where it was not executable, then Git changes its executable bit, and I don't see why it would do otherwise:
Git tracks the executable bit, so when you say "reset the file to how it was in this revision", this includes the content and executability.

Reading your message, I don't understand why you need to be able to ignore the x bit.

Answer 2

Git does preserve file permissions, that is, git is aware of the permissions you can set with chmod.

I'm not trying to ignore the x bit, what I'm trying to do is make "git reset" checkout only the files that actually changed instead of checking out all the files with different permissions than the ones git thinks they should have.

Said with other word: when you run "git reset", git does a "status" and checkouts all the files that showed up from the "status". That's exactly what I'm trying to avoid, as "status" is aware of both content changes and permissions changes.