On Wed, 2008-10-15 at 08:13 +0200, Johannes Sixt wrote: > Junio C Hamano schrieb: > > Makes me wonder why this is _not_ inside test-lib.sh where it creates the > > test (trash) directory. That way, you would cover future tests that wants > > to see a saner/simpler POSIX permission behaviour, wouldn't you? > > But that would also paper over unanticipated bad interactions with strange > ACLs that people might set, wouldn't it? By not placing this into > test-lib.sh there is a higher chance that such an interaction is revealed, > and we can react on it (educate users or fix the code). A default ACL on the working tree does not interfere with git's operation. If the repository is shared, git will explicitly set the permissions of every file as configured; otherwise, new files will simply take their permissions from the default ACL instead of the creating process's umask. This is exactly the behavior that a user who sets a default ACL would expect. There is no need to modify adjust_shared_perm or to warn users not to use default ACLs. The only problem here is that a default ACL prevents t1301-shared-repo.sh from testing the interaction between the umask and the sharedRepository setting, since the test case expects new files to be created according to the umask it set but the default ACL is overriding the umask. Removing the trash directory's default ACL is a perfectly legitimate way for t1301-shared-repo.sh to test what it wants to test. Another option would be to modify the trash directory's default ACL instead of modifying the umask. Other tests will not care whether test-lib.sh clears a default ACL for them because they are not specifically testing file permissions. Therefore, I thought it best to leave the default ACL alone so that the trash directories get the permissions the user has specified in the default ACL in case he/she cares about sharing the trash directories with others. Matt -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
