Re: [PATCH v2 2/2] Handle more file writes correctly in shared repos

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <johannes.schindelin@gmx.de> 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.