All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.