From: Michael Haggerty <mhagger@alum.mit.edu>
To: "Torsten Bögershausen" <tboegi@web.de>,
"Junio C Hamano" <gitster@pobox.com>
Cc: Eric Wong <normalperson@yhbt.net>,
Karsten Blees <karsten.blees@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 1/2] create_default_files(): don't set u+x bit on $GIT_DIR/config
Date: Sun, 16 Nov 2014 06:23:57 +0100 [thread overview]
Message-ID: <546834ED.6050403@alum.mit.edu> (raw)
In-Reply-To: <546741AC.9030107@web.de>
On 11/15/2014 01:06 PM, Torsten Bögershausen wrote:
> On 2014-11-15 08.26, Michael Haggerty wrote:
> The whole thing looks good to me, some minor comments below
>> 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
> s/permissions/executable bit/ ?
>> $GIT_DIR/config after its test.
The code literally resets all of the permissions to their values before
the test, so I think the existing text is more accurate (even though
your version would have been fine, too).
>> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
>> ---
>> builtin/init-db.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/builtin/init-db.c b/builtin/init-db.c
>> index 56f85e2..95ca5e4 100644
>> --- a/builtin/init-db.c
>> +++ b/builtin/init-db.c
>> @@ -255,6 +255,7 @@ static int create_default_files(const char *template_path)
>> filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&
>> !lstat(path, &st2) &&
>> st1.st_mode != st2.st_mode);
>> + chmod(path, st1.st_mode);
> A "blind" chmod() is good, but I think checking the return code is better.
>
> filemode &= (!chmod(path, st1.st_mode));
I guess it is better to include this test, even though it is mostly
redundant with what was already determined by the previous line. I
suppose the only alternative would be to
die("Your chmod() support is bonkers")
I will change this in v2.
Thanks for your comments!
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
next prev parent reply other threads:[~2014-11-16 5:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-15 7:26 [PATCH 0/2] Don't make $GIT_DIR executable Michael Haggerty
2014-11-15 7:26 ` [PATCH 1/2] create_default_files(): don't set u+x bit on $GIT_DIR/config Michael Haggerty
2014-11-15 12:06 ` Torsten Bögershausen
2014-11-16 5:23 ` Michael Haggerty [this message]
2014-11-15 7:26 ` [PATCH 2/2] config: clear the executable bits (if any) " Michael Haggerty
2014-11-15 7:32 ` Stefan Beller
2014-11-15 7:42 ` Michael Haggerty
2014-11-16 18:49 ` Junio C Hamano
2014-11-17 8:26 ` Michael Haggerty
2014-11-17 15:33 ` Junio C Hamano
2014-11-17 16:00 ` Michael Haggerty
2014-11-15 7:50 ` [PATCH 0/2] Don't make $GIT_DIR executable Eric Wong
2014-11-16 6:14 ` Michael Haggerty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546834ED.6050403@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=karsten.blees@gmail.com \
--cc=normalperson@yhbt.net \
--cc=tboegi@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.