Re: [PATCH] init - Honour the global core.filemode setting

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] init - Honour the global core.filemode setting

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:02:38

Torsten Bögershausen [off-list ref] writes:
On 2014-10-01 19.10, Junio C Hamano wrote:
quoted
Hilco Wijbenga [off-list ref] writes:
quoted
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 ?)
Between these two sentences, there may still be the same cognitive
gap that may have lead to the original confusion.

The first sentence says what happens, as it should.

But it is not directly clear what makes the executable bit differ
and when it is a useful thing to ignore the differences, so the
second sentence that says "This may be useful" does not give the
reader very much.

Here is my attempt.

	Tells Git if the executable bit of files in the working tree
	is to be honored.

	Some filesystems lose the executable bit when a file that is
	marked as executable is checked out, or checks out an
	non-executable file with executable bit on.  "git init" and
	"git clone" probe the filesystem to see if it records
	executable bit correctly when they create a new repository
	and this variable is automatically set as necessary.

        A repository, however, may be on a filesystem that records
        the filemode correctly, and this variable is set to 'true'
        when created, but later may be made accessible from another
        environment that loses the filemode (e.g. exporting ext4 via
        CIFS mount, visiting a Cygwin managed repository with
        MsysGit).  In such a case, it may be necessary to set this
        to 'false'.

Re: [PATCH] init - Honour the global core.filemode setting

From: Torsten Bögershausen <hidden>
Date: 2016-06-15 23:02:38

On 2014-10-02 19.02, Junio C Hamano wrote:
Torsten Bögershausen [off-list ref] writes:
quoted
On 2014-10-01 19.10, Junio C Hamano wrote:
quoted
Hilco Wijbenga [off-list ref] writes:
quoted
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 ?)
Between these two sentences, there may still be the same cognitive
gap that may have lead to the original confusion.

The first sentence says what happens, as it should.

But it is not directly clear what makes the executable bit differ
and when it is a useful thing to ignore the differences, so the
second sentence that says "This may be useful" does not give the
reader very much.
Clearly a major improvement.

Does this (still) include the original line
"See linkgit:git-update-index[1]"

which helps the user to add *.sh files "executable" to the index, even if
core.filemode is false ?
One minor improvement below.
Here is my attempt.

	Tells Git if the executable bit of files in the working tree
	is to be honored.

	Some filesystems lose the executable bit when a file that is
	marked as executable is checked out, or checks out an
	non-executable file with executable bit on.  "git init" and
	"git clone" probe the filesystem to see if it records
	executable bit correctly when they create a new repository
	and this variable is automatically set as necessary.

        A repository, however, may be on a filesystem that records
        the filemode correctly, and this variable is set to 'true'
        when created, but later may be made accessible from another
        environment that loses the filemode (e.g. exporting ext4 via
        CIFS mount, visiting a Cygwin managed repository with
        MsysGit).  In such a case, it may be necessary to set this
        variable to 'false'.
          ^^^^^^^^ 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help