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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 5, 2016, 19:39 UTC
Message-ID: <xmqq37ubke8q.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1601051342050.14434@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 15 quoted lines

> Hi Junio,
>
> On Mon, 4 Jan 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> >> I do not know fcreate_or_truncate() is a good name, though.
>> >
>> > So what would be a good name?
>> 
>> Have been thinking about it, but I did not come up with anything.  I
>> just know fcreate_or_truncate() is not a good name for multiple
>> reasons I already explained X-<.  sane_fopen_for_writing() perhaps?
>
> That implies that fopen() is insane, though ;-)

Well, sane_X() does not imply X() is "insane". The reason why we introduce sane_X() wrapper often is because X is inconvenient to use sanely as-is.

Look at sane_istest(), sane_case(), etc. We have one byte and want to see if that is space, digit, etc., but we have to cast (possibly signed) char to unsigned char and always doing so in the callers is inconvenient. Look at sane_grep. We have a string and want to see that appears in its input, but some implementations of "grep" can be configured in an inconvenient/unsuitable way to be used in scripts via environment variables, so we disable it not in the callers but in a wrapper.

All we want to do here is to get a writable filehandle FILE * for a path and store the contents we will generate without having to worry about the possibility that the path is already there and we may have to first unlink it to use fopen(3) to do so.

So in the sense, fopen(3) is inconvenient to use sanely as-is. You can call it insane, too ;-)

If we want to follow the X_or_Y() pattern, fopen_or_create() may describe what it does better. I do not have strong preference either way, but again I am not good at naming things (and I suspect you aren't either), so...