severity 621090 wishlist tags 621090 + upstream retitle 621090 git read-tree -u: preserve owners and permissions quit
Hi Axel, Axel Beckert wrote: > Most git actions don't change permissions or file owners, but git stash > leaves changed files with permissions and owners as if they were newly > created. Hmm. "git stash save" uses "git reset --hard" internally. The usual behavior when "git checkout" or "git reset --hard" replaces a file is to remove the old file and write a new one. The result isn't so unusual for, say, a text editor --- it's the same as would happen with the usual write new file / fsync / rename dance, except faster and less robust against sudden OS failure. I'm not aware of any intention to change that. Git really _wasn't_ designed to track /etc (or other files where the detailed permissions are meaningful), and it shows. The current strategy means that in a shared repository (initialized with "git init --shared"), 1) alice can make a file and commit it; 2) bob can checkout a different version of that file. even if bob only has write permission on the directory and not the file. It makes matters simple. That said. If git were rewriting files in situations where it was just wasted effort, that would be important; for example, there was a bug of this kind fixed by commit b2c8c0a76 (merge-recursive: When we detect we can skip an update, actually skip it, 2011-02-28), which fixes a regression introduced by v1.7.4-rc0~101^2~9 (merge-recursive: Delay content merging for renames, 2010-09-20). So thanks for reporting and please feel free to report similar issues. > This can cause severe problems when configuration files are > maintained in git. Yikes. Running "git stash" or anything similar from within a git-managed /etc is very dangerous. Are you using etckeeper? (IIRC the usual practice with that tool is to manipulate a clone and then use the hooks inserted by etckeeper to ensure a later "git fetch" and "git checkout" work well.) Or are these configuration files of another kind? Thanks for writing. Jonathan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
