5

I'm trying to git reset --hard origin/master but make git somehow checkout the files only if the actual content of each file changed, instead of checking them even if only the permissions changed.

Is there some parameter I can pass to git reset or that's a thing that can be solved only with a script?

alexandernst
  • 14,352
  • 22
  • 97
  • 197
  • Maybe just commit only the permission changes, and then work from that point forward? – jmruc Jun 10 '13 at 10:28
  • 1
    @KirilRaychev thing is that I do not want to commit the permission changes. – alexandernst Jun 10 '13 at 10:29
  • You could try committing to a detached head then rolling back to your branch to see if that solves it? But sounds like a bug worth filing against git if the latest version is still broken. – Rup Jun 10 '13 at 11:55
  • Is there a good use case for this? (what's the reason) - It maybe that an update to git could be proposed. – Philip Oakley Jun 10 '13 at 13:02
  • Maybe you need --assume-unchanged for the file, though you'll have to check the manual for all the implications of that assumption to are giving to git. – Philip Oakley Jun 10 '13 at 13:56
  • @PhilipOakley I'm deploying the git repo to a NGINX server and I'm then chmod-ing everything to read-only (for security, thou the NGINX user already can't write to the path where I deploy). – alexandernst Jun 10 '13 at 14:02
  • @alexandernst: Ah, so you are using git as a deployment tool. This is often not a good idea, as git is not meant as a deployment tool; you might consider some other solution. Still, if you get it to work, why not. – sleske Jun 19 '13 at 10:37

2 Answers2

5

Try setting core.fileMode to false as described here (docs) (git config core.fileMode false should do the trick). This seems to make Git ignore any permission changes when hard resetting. Now, I did find that if Git couldn't read the file (e.g., I'd set the permissions to 000), a hard reset would restore the original permissions it was committed with.

Another thought, which might be of interest, would be to write a hook which would set the permissions of all files in the repo to whatever you wanted. That might also give you some assurance that you weren't accidentally leaving a new file with dangerous permissions.

Community
  • 1
  • 1
andyg0808
  • 1,367
  • 8
  • 18
  • This worked for me, unlike the accepted answer. And it's a bit counter intuitive - I thoughtI should set it to `true` but even for my case `false` is what I needed. – Sridhar Sarnobat Dec 06 '20 at 05:12
4

I was able to solve the issue via Git's ML.

So basically:

git update-index --refresh

before: git reset did the trick :)

kenorb
  • 155,785
  • 88
  • 678
  • 743
alexandernst
  • 14,352
  • 22
  • 97
  • 197
  • Glad to hear it - can you edit the answer from the ML into this answer too please? – Rup Jun 19 '13 at 10:33