> Hehe, but you left an opening for your turn around to be turned around... Git does not actually track standard Unix file permissions. > It _only_ tracks the executable bit (and not a separate one for user & group & other, but just an overall is-executable or not). Of particular note for this discussion is that it does not track the writable bit. So, wouldn't it be in line with the way Git already behaves to not touch the writable permission? :-) Well, you got me there. In various places it will show file modes like 100644 or 100755 and it'll include permission changes in diffs, but it does seem to be faking it (in that it only ever shows 644 or 755 regardless of the actual permissions)! That furthermore implies that Git will always check out files with only one of two permissions (either 666 or 777, filtered through the umask), and that means I don't in fact have to worry about chmod -R u+w at the root of the repository messing up the permissions of tracked files. That being the case, my proposed feature is not really necessary - perhaps nice to have in some edge cases, but probably not worth the implementation effort. I wonder now why Git makes an effort of appearing to represent a full set of Unix file permissions. Perhaps the idea was to leave the door open to storing them in the future... > This is some good food for thought, especially the bit about "[if] you are going to delete the parent directory anwyay". Hmm... Well, personally I'd prefer it to do it regardless of whether the parent directory is going to be deleted, so it doesn't matter where the untracked file is, but again I withdraw the feature request given that Git doesn't actually store any writable permission bits so there's no problem if I forcibly rewrite them throughout the whole repository. And with that I apologize for anyone's time that I wasted. -- Adam
