From: Michael Haggerty <mhagger@alum.mit.edu>
To: 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 2/2] config: clear the executable bits (if any) on $GIT_DIR/config
Date: Mon, 17 Nov 2014 17:00:18 +0100 [thread overview]
Message-ID: <546A1B92.90900@alum.mit.edu> (raw)
In-Reply-To: <xmqqfvdhzvsp.fsf@gitster.dls.corp.google.com>
On 11/17/2014 04:33 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> On 11/16/2014 07:49 PM, Junio C Hamano wrote:
>> ...
>>> So I would suggest not to spend any cycle or any code complexity to
>>> "repair" existing repositories. Having that bit on does not hurt
>>> anybody. Those who found it curious can flip that bit off and then
>>> Git with "preserve existing permissions" fix will keep that bit off
>>> from then on.
>>
>> I disagree. The point of "preserve existing permissions" was to allow
>> people to make their config files more readable/writable than the
>> default,...
>
> s/more/less/, I think, was the original motivation. Having to limit
> more tightly than usual was what made the "config" unusual among
> files under $GIT_DIR. If it were to loosen, Eric's change should
> not have been done in the first place. The sharedRepository setting
> to defeat the default umask is there for that kind of thing.
Oops, you are right. I actually meant to type "less or more", but I see
that "more" would be pretty useless.
>> That being said, I still believe that executable config files are not a
>> significant risk ...
>
> It is merely an annoyance, to the same degree of annoyance we find
> when we see all files appear executable on a FAT floppy mounted on
> Linux ;-) I do not think it is a risk at all, and I do not see a
> point in going into people's repository and actively "fixing" it.
> People who notice can fix, and people who do not care do not care
> and are not harmed.
OK, then, I'll send a new copy of patch 1/2 and drop 2/2.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
next prev parent reply other threads:[~2014-11-17 16:00 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
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 [this message]
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=546A1B92.90900@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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).