Re: [PATCH v2 1/2] create_default_files(): don't set u+x bit on $GIT_DIR/config

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Nov 17, 2014, 09:46 UTC
Message-ID: <5469C40B.4080601@alum.mit.edu>
In-Reply-To: <CAPig+cQ6j-3_Ng8DVT3FYk8T6DippEbYDhQq5v3DTJhGgBhPDQ@mail.gmail.com>

On 11/17/2014 02:40 AM, Eric Sunshine wrote:

Show 27 quoted lines

> On Sun, Nov 16, 2014 at 2:21 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> Since time immemorial, the test of whether to set "core.filemode" has
>> been done by trying to toggle the u+x bit on $GIT_DIR/config and then
>> testing whether the change "took". It is somewhat odd to use the
>> config file for this test, but whatever.
>>
>> The test code didn't set the u+x bit back to its original state
>> itself, instead relying on the subsequent call to git_config_set() to
>> re-write the config file with correct permissions.
>>
>> But ever since
>>
>>     daa22c6f8d config: preserve config file permissions on edits (2014-05-06)
>>
>> git_config_set() copies the permissions from the old config file to
>> the new one. This is a good change in and of itself, but it interacts
>> badly with create_default_files()'s sloppiness, causing "git init" to
>> leave the executable bit set on $GIT_DIR/config.
>>
>> So change create_default_files() to reset the permissions on
>> $GIT_DIR/config after its test.
>>
>> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
>> ---
> 
> Should this patch include a test in t1300 to ensure that this bug does
> not resurface (and to prove that this patch indeed fixes it)?

This seems like a one-off bug caused by a specific instance of odd code. It could only recur if somebody were to remove the line that I added, which would be a *very* odd mistake to make given that its purpose is pretty obvious.

I tested manually that this patch fixes the problem. Admittedly, my manual testing was only on one particular version of Linux. But it seems to me that the function being used is sufficiently portable to be trusted, and the fact that the same function is being used a few lines earlier suggests that any portability problems would have wider ramifications anyway.

So in summary, I think the chance that such a test would ever catch a new problem is too small to justify the effort of writing and maintaining it.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu