All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: Junio C Hamano <gitster@pobox.com>,
	Hilco Wijbenga <hilco.wijbenga@gmail.com>
Cc: "Torsten Bögershausen" <tboegi@web.de>,
	"Git Users" <git@vger.kernel.org>
Subject: Re: [PATCH] init - Honour the global core.filemode setting
Date: Thu, 02 Oct 2014 13:15:45 +0200	[thread overview]
Message-ID: <542D33E1.6080709@web.de> (raw)
In-Reply-To: <xmqqy4szpvfv.fsf@gitster.dls.corp.google.com>

On 2014-10-01 19.10, Junio C Hamano wrote:
> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
> 
>> Perhaps I completely misunderstand the meaning of core.filemode but I
>> thought it determined whether Git cared about changes in file
>> properties?
> 
> By setting it to "false", you tell Git that the filesystem you
> placed the repository does not correctly represent the filemode
> (especially the executable bit).
> 
> "core.fileMode" in "git config --help" reads:
> 
>        core.fileMode
>            If false, the executable bit differences between the
>            index and the working tree are ignored; useful on broken
>            filesystems like FAT. See git-update- index(1).

Out of my head: Could the following be a starting point:

        core.fileMode
            If false, the executable bit differences between the
            index and the working tree are ignored.
            This may be usefull when visiting a cygwin repo with a non-cygwin
            Git client. (should we mention msysgit ? should we mention JGit/EGit ?)
	    This may even be useful for a repo on a SAMBA network mount,
            which may show all file permissions as 0755.
            See git-update-index(1) for changing the executable bit in the index. 

            The default is true, except git-clone(1) or git-init(1)
            will probe and set core.fileMode false if appropriate
            when the repository is created.
> 
> Maybe our documentation is not clear enough.  A contribution from
> somebody new to Git we would appreciate would be to point out which
> part of these sentences are unclear; that way, people can work on
> improving its phrasing.
> 
> Thanks.

  reply	other threads:[~2014-10-02 11:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-28  0:37 [PATCH] init - Honour the global core.filemode setting Hilco Wijbenga
2014-09-28 11:52 ` Torsten Bögershausen
2014-10-01  1:55   ` Hilco Wijbenga
2014-10-01 17:10     ` Junio C Hamano
2014-10-02 11:15       ` Torsten Bögershausen [this message]
2014-10-02 17:02         ` Junio C Hamano
2014-10-03 16:54           ` Torsten Bögershausen
2014-10-03 17:07             ` Junio C Hamano

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=542D33E1.6080709@web.de \
    --to=tboegi@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hilco.wijbenga@gmail.com \
    /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.