Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > - git apply, when writing rejected hunks Today I may try to apply and leave hello.c.rej; tomorrow you may try to apply a different patch and get rejection for the same file. And you would not be able to if my umask is 077. I do not know "intended to be shared" is a good criteria, unless it is a synomym to "what is under $GIT_DIR". core.sharedRepository is about the shared-ness of $GIT_DIR and never about the working tree, so I consider it is correct that not adjusting the permission is the right thing to do when 'git apply' writes .rej files, though. > - git fsck, when writing lost&found blobs So this _is_ conceptually a problem, but writing anything indexed with the object name is an idempotent operation, so this will not matter in practice, I think. > - git merge-file, when writing merged files (when Git itself calls > merge-file, the file in question was already there, with shared > permissions). Again, this is not a problem (i.e. not touching it in this patch is the right thing to do) as this is about files in the working tree. > - git fast-import, when writing a crash report I am not sure about this one. Is the crash report designed to get unique filename every time you run? Otherwise, the fixed name inside $GIT_DIR/ is a shared resource, so I suspect it would want to overwrite. "Not overwriting the crash report is safer, because the existence of it is a sign that the earlier crash hasn't been dealt with" is also a valid position to take, but then it shouldn't even overwrite my own crash report from an earlier run. So I am inclined to say that this should be changed (either consistently overwrite using fopen_harder(), or consistently fail when my earlier crash report is already there). I however do not think that change belongs to this topic. > - mailinfo() in mailinfo.c, because the output is clearly not intended to > be shared between the users of the current repository This is more because "not intended to be run multiple simultaneously using the same filename" plus "the callers clean up after they are done" (similar to what you wrote for "git am"), I think. > - git rerere, when writing resolved files, because the files in question > were already written with the correct permissions This again is more because the result goes to the working tree, not $GIT_DIR. -- 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