Ruediger Pluem wrote on Mon, Feb 21, 2022 at 08:49:08 +0100: > On 2/19/22 5:07 PM, Daniel Shahaf wrote: > > I can't reproduce this. Using unpatched trunk: > > I checked again and I was able to reproduce it with 1.10. > With 1.13 though it shows the behavior you describe for trunk below. ⋮ > > How do other patch tools behave in this case? > > I tried GNU patch 2.7.6 and it kept the permissions of the file to be > patched. No matter what umask was set. > git 2.27.0 on the other side behaves like svn trunk: The file permissons are > affected by the umask.
And «svn update» creates the new file with umask permissions too. E.g., «chmod 0644 README; umask 077; svn up -r PREV README; stat README» gives 0600 (with current trunk). I'm not sure what behaviour I would expect. On the one hand, umask only kicks in because of an implementation detail of atomic renames; there's no business logic reason to use the "default permissions for new files" value when changing an existing file. On the other hand, there's an argument that «svn patch» and «svn up» should be consistent with each other, and changing the latter is more likely to break people's proverbial spacebar heating. Even if we don't consense on what the behaviour should be, we could at least add a test that expects the current behaviour, in order to ensure we don't change it unintentionally. Cheers, Daniel
