Re: [PATCH] commit: ensure correct permissions of the commit message

[Jeff King <peff@peff.net>]

On Sun, Dec 20, 2015 at 05:31:48PM -0800, Junio C Hamano wrote:

> Actually, we do not even _need_ a sharedness for this ephemeral
> file.  The additional "adjust-shared-perm" is merely a workaround
> for the fact the next person cannot write into it when it is left
> behind, and because we do not want to remove it when we are done.
> 
> That does not measn that the next person cannot remove it when she
> finds there is a file there left behind.  So alternatively, we could
> do something like this, perhaps?
> 
>         FILE *fopen_forcibly(const char *path, const char *mode)
>         {
>                 FILE *ret = fopen(path, mode);
> 
>                 if (!ret && errno == EPERM) {
>                         if (!unlink(path))
>                                 ret = fopen(path, mode);
>                         else
>                                 errno = EPERM;
>                 }
>                 return ret;
>         }

Yeah, I think that is a much nicer solution for this case. It should
work even in a shared repo, since we set the permissions for the
surrounding $GIT_DIR appropriately[1].

I guess it would not apply to any files that do not want to truncate the
existing contents. Probably it should drop the "mode" parameter at all,
since anything but "w" would be crazy?

-Peff

[1] Assuming you use something like "git init --shared=true". I would
    not be surprised if there are many repos where somebody just set
    "core.sharedrepository" after the fact, but there is not much we can
    do. They _have_ to fix up the permissions in that case.