{"thread":{"id":"37638","subject":"[PATCH] init - Honour the global core.filemode setting","startedAt":"2014-09-28T00:37:34Z","lastAt":"2014-10-03T17:07:16Z","messageCount":8,"participants":["Hilco Wijbenga","Torsten Bögershausen","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"249926","messageId":"CAE1pOi0zhnUNNdHsrq+4H_6LiFnr-qoY-owrcJquy6dyG+Mk4g@mail.gmail.com","threadId":"37638","inReplyTo":null,"subject":"[PATCH] init - Honour the global core.filemode setting","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2014-09-28T00:37:34Z","receivedAt":"2014-09-28T00:37:34Z","isPatch":true,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"If \"~/.gitconfig\" contains a \"core.filemode\" entry then \"git init\"\nshould honour that setting.\n\nSigned-off-by: Hilco Wijbenga <hilco.wijbenga@gmail.com>\n---\nThis bit me at work where I have to work with Windows. Git on Cygwin\nand the Eclipse Git plugin do not agree on file attributes so I had\nset \"filemode = false\" in ~/.gitconfig.\n\nA few weeks later, I did a \"git init\" and, some time later yet, I\nnoticed the strange behaviour of Cygwin/Eclipse again. This was very\nsurprising because things had been working well until then. It took\nquite a bit of research before I realized that \"git init\" always sets\n\"filemode\". I think \"filemode\" should only be set if not set already\nin the global config (similar to log_all_ref_updates).\n\nThe usual caveat applies: this is my first patch. Having said that,\nplease feel free to be pedantic and strict. It's a small patch so I\nwould imagine that fixing any problems should not take long (assuming\nit is acceptable at all, of course). I'd like to know I did it right.\n:-)\n\nAFAICT, all tests passed. Should a separate test be added for this change?\n\n(I used \"git format-patch\" and \"git imap-send\" to send this patch to\nthe ML but looking below I still do not see tabs? In fact, I do not\nsee any indentation.)\n builtin/init-db.c | 19 +++++++++++--------\n environment.c     |  2 +-\n 2 files changed, 12 insertions(+), 9 deletions(-)\n\ndiff --git a/builtin/init-db.c b/builtin/init-db.c\nindex 56f85e2..19cdc58 100644\n--- a/builtin/init-db.c\n+++ b/builtin/init-db.c\n@@ -248,15 +248,18 @@ static int create_default_files(const char *template_path)\n  path[len] = 0;\n  strcpy(path + len, \"config\");\n\n- /* Check filemode trustability */\n- filemode = TEST_FILEMODE;\n- if (TEST_FILEMODE && !lstat(path, &st1)) {\n- struct stat st2;\n- filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&\n- !lstat(path, &st2) &&\n- st1.st_mode != st2.st_mode);\n+ /* Do not override the global filemode setting. */\n+ if (trust_executable_bit == -1) {\n+ /* Check filemode trustability */\n+ filemode = TEST_FILEMODE;\n+ if (TEST_FILEMODE && !lstat(path, &st1)) {\n+ struct stat st2;\n+ filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&\n+ !lstat(path, &st2) &&\n+ st1.st_mode != st2.st_mode);\n+ }\n+ git_config_set(\"core.filemode\", filemode ? \"true\" : \"false\");\n  }\n- git_config_set(\"core.filemode\", filemode ? \"true\" : \"false\");\n\n  if (is_bare_repository())\n  git_config_set(\"core.bare\", \"true\");\ndiff --git a/environment.c b/environment.c\nindex 565f652..875a498 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -12,7 +12,7 @@\n #include \"fmt-merge-msg.h\"\n #include \"commit.h\"\n\n-int trust_executable_bit = 1;\n+int trust_executable_bit = -1;\n int trust_ctime = 1;\n int check_stat = 1;\n int has_symlinks = 1;\n-- \n2.1.1.dirty\n"},{"id":"249964","messageId":"5427F68E.5030003@web.de","threadId":"37638","inReplyTo":"CAE1pOi0zhnUNNdHsrq+4H_6LiFnr-qoY-owrcJquy6dyG+Mk4g@mail.gmail.com","subject":"Re: [PATCH] init - Honour the global core.filemode setting","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2014-09-28T11:52:46Z","receivedAt":"2014-09-28T11:52:46Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2014-09-28 02.37, Hilco Wijbenga wrote:\n> If \"~/.gitconfig\" contains a \"core.filemode\" entry then \"git init\"\n> should honour that setting.\n> \n> Signed-off-by: Hilco Wijbenga <hilco.wijbenga@gmail.com>\n> ---\n> This bit me at work where I have to work with Windows. Git on Cygwin\n> and the Eclipse Git plugin do not agree on file attributes so I had\n> set \"filemode = false\" in ~/.gitconfig.\nThis feels strange.\nEach and every repo has a core.filemode setting.\nOr should have.\n\nDid you manage to create a repo without core.filemode in repo/.git/config ?\nAnd if yes, how?\n\n> \n> A few weeks later, I did a \"git init\" and, some time later yet, I\n> noticed the strange behaviour of Cygwin/Eclipse again.\nI do not fully understand which \"strange behaviour\" you experied,\nso I need to guess.\n\n This was very\n> surprising because things had been working well until then. It took\n> quite a bit of research before I realized that \"git init\" always sets\n> \"filemode\". I think \"filemode\" should only be set if not set already\n> in the global config (similar to log_all_ref_updates).\n\nThat is part of the whole story:\nIn general, \"git init\" probes the file system, if the executable bit\nis working as expected.\nSo if you  create a Git repository under VFAT, the executable bit is not supported.\n\nGit will notice that, and set core.filemode = false.\n\nNTFS is a different story:\nCygwin has support for the executable bit under NTFS, but Msysit does not.\nSo if you \"share\" a Git repository between Msysgit and cygwin, it may be better\nto set core.filemode to false.\n\n\nThere is however a problem with your patch, or 2:\n\nWhen you set core.filemode = false in your ~/.gitconfig,\nanother developer may have core.filemode = true in his config.\nIf you manage to share the repo using a network, git will behave different\nfor the 2 users.\nSolution:\nSet core.filemode for this repo alwways in the repo. (as we do today in git.git)\n\nWhen you run \"git init\" with ~/.gitconfig = true, you should\nanyway probe the file system, as it may not support file mode, and core.filemode may be false.\n\n\nSo the solution that I can see is:\n(Some pseudo-code:)\n\nif (git config (global config ) == false) ||\n   (git config (~/.config ) == false) then\n  git_config_set(\"core.filemode\", \"false\");\nelse\n  probe the file system and set core.filemode as we do today\nfi\n\n\n> \n> The usual caveat applies: this is my first patch. Having said that,\n> please feel free to be pedantic and strict. It's a small patch so I\n> would imagine that fixing any problems should not take long (assuming\n> it is acceptable at all, of course). I'd like to know I did it right.\n> :-)\n> \n> AFAICT, all tests passed. Should a separate test be added for this change?\nI think yes.\n\nUnder which system did you test ?\n\nWindows?\nCYWGIN ?\nMingWW/Msysgit ?\nLinux ?\n\n\n> - /* Check filemode trustability */\n> - filemode = TEST_FILEMODE;\n> - if (TEST_FILEMODE && !lstat(path, &st1)) {\n> - struct stat st2;\n> - filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&\n> - !lstat(path, &st2) &&\n> - st1.st_mode != st2.st_mode);\n> + /* Do not override the global filemode setting. */\n> + if (trust_executable_bit == -1) {\n> + /* Check filemode trustability */\n> + filemode = TEST_FILEMODE;\n> + if (TEST_FILEMODE && !lstat(path, &st1)) {\n> + struct stat st2;\n> + filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&\n> + !lstat(path, &st2) &&\n> + st1.st_mode != st2.st_mode);\n> + }\n> + git_config_set(\"core.filemode\", filemode ? \"true\" : \"false\");\nThe indentation seems to be broken ?\n(We use one TAB, for better info please see Documentation/CodingGuidelines)\n[snip]\n"},{"id":"250054","messageId":"CAE1pOi1dAO7XFZtrgZyNm-eLVKQx=KpeejbGmF8khCofAppDLg@mail.gmail.com","threadId":"37638","inReplyTo":"5427F68E.5030003@web.de","subject":"Re: [PATCH] init - Honour the global core.filemode setting","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2014-10-01T01:55:16Z","receivedAt":"2014-10-01T01:55:16Z","isPatch":true,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"Hi Torsten,\n\nThank you for taking the time to review my patch.\n\nOn 28 September 2014 04:52, Torsten Bögershausen <tboegi@web.de> wrote:\n> On 2014-09-28 02.37, Hilco Wijbenga wrote:\n>> If \"~/.gitconfig\" contains a \"core.filemode\" entry then \"git init\"\n>> should honour that setting.\n>>\n>> Signed-off-by: Hilco Wijbenga <hilco.wijbenga@gmail.com>\n>> ---\n>> This bit me at work where I have to work with Windows. Git on Cygwin\n>> and the Eclipse Git plugin do not agree on file attributes so I had\n>> set \"filemode = false\" in ~/.gitconfig.\n> This feels strange.\n> Each and every repo has a core.filemode setting.\n> Or should have.\n>\n> Did you manage to create a repo without core.filemode in repo/.git/config ?\n> And if yes, how?\n\nPerhaps I completely misunderstand the meaning of core.filemode but I\nthought it determined whether Git cared about changes in file\nproperties? So this is client OS related and independent of the repo?\n\n>> A few weeks later, I did a \"git init\" and, some time later yet, I\n>> noticed the strange behaviour of Cygwin/Eclipse again.\n> I do not fully understand which \"strange behaviour\" you experied,\n> so I need to guess.\n\nThe problem is simply that Eclipse's Git sees changes that Cygwin's\nGit does not. It's some sort of unfortunate consequence of trying to\npretend to be Linux on Windows, I guess. The only way to get them to\nagree was to set core.filemode to false. Now you might rightly argue\nthat Eclipse and/or Windows and/or Cygwin should be fixed but that's a\nmuch bigger undertaking than simply setting an existing Git property.\n:-)\n\n>  This was very\n>> surprising because things had been working well until then. It took\n>> quite a bit of research before I realized that \"git init\" always sets\n>> \"filemode\". I think \"filemode\" should only be set if not set already\n>> in the global config (similar to log_all_ref_updates).\n>\n> That is part of the whole story:\n> In general, \"git init\" probes the file system, if the executable bit\n> is working as expected.\n> So if you  create a Git repository under VFAT, the executable bit is not supported.\n>\n> Git will notice that, and set core.filemode = false.\n>\n> NTFS is a different story:\n> Cygwin has support for the executable bit under NTFS, but Msysit does not.\n\nAgreed. That is what I concluded from the code.\n\n> So if you \"share\" a Git repository between Msysgit and cygwin, it may be better\n> to set core.filemode to false.\n\nPossibly. I would argue that that is up to the individual developer.\n\n> There is however a problem with your patch, or 2:\n>\n> When you set core.filemode = false in your ~/.gitconfig,\n> another developer may have core.filemode = true in his config.\n> If you manage to share the repo using a network, git will behave different\n> for the 2 users.\n\nIsn't that what everything in ~/gitconfig is for? So that I can set\nattributes appropriate to my working environment? Besides, that is\nalready the case if developer A uses a VFAT system and developer B\nuses NTFS or JFS or EXTn or ..., right? (As you also indicated above.)\n\n> Solution:\n> Set core.filemode for this repo alwways in the repo. (as we do today in git.git)\n\nI suppose you could set it to false, yes. But then it affects\neverybody, that seems like going for the lowest common denominator?\n\n> When you run \"git init\" with ~/.gitconfig = true, you should\n> anyway probe the file system, as it may not support file mode, and core.filemode may be false.\n>\n>\n> So the solution that I can see is:\n> (Some pseudo-code:)\n>\n> if (git config (global config ) == false) ||\n>    (git config (~/.config ) == false) then\n>   git_config_set(\"core.filemode\", \"false\");\n> else\n>   probe the file system and set core.filemode as we do today\n> fi\n\nYeah, I actually considered that (well, something less complete,\nactually :-) ) but decided to go for the simpler approach that I\nshowed. My assumption is that the developer working with the repo\nknows what he is doing. It seems wrong for Git to override that\ndecision. Then again, I don't really see any advantage in setting\ncore.filemode to true when working with, say, a VFAT filesystem, so\nignoring it in that case might be okay. Would such a setup do active\ndamage, though?\n\n>> The usual caveat applies: this is my first patch. Having said that,\n>> please feel free to be pedantic and strict. It's a small patch so I\n>> would imagine that fixing any problems should not take long (assuming\n>> it is acceptable at all, of course). I'd like to know I did it right.\n>> :-)\n>>\n>> AFAICT, all tests passed. Should a separate test be added for this change?\n> I think yes.\n\nOkay, I'll have to figure out how to do that.\n\n> Under which system did you test ?\n>\n> Windows?\n> CYWGIN ?\n> MingWW/Msysgit ?\n> Linux ?\n\nOnly Linux. I don't really run Windows at home.\n\n>> - /* Check filemode trustability */\n>> - filemode = TEST_FILEMODE;\n>> - if (TEST_FILEMODE && !lstat(path, &st1)) {\n>> - struct stat st2;\n>> - filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&\n>> - !lstat(path, &st2) &&\n>> - st1.st_mode != st2.st_mode);\n>> + /* Do not override the global filemode setting. */\n>> + if (trust_executable_bit == -1) {\n>> + /* Check filemode trustability */\n>> + filemode = TEST_FILEMODE;\n>> + if (TEST_FILEMODE && !lstat(path, &st1)) {\n>> + struct stat st2;\n>> + filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&\n>> + !lstat(path, &st2) &&\n>> + st1.st_mode != st2.st_mode);\n>> + }\n>> + git_config_set(\"core.filemode\", filemode ? \"true\" : \"false\");\n> The indentation seems to be broken ?\n> (We use one TAB, for better info please see Documentation/CodingGuidelines)\n> [snip]\n\nI did. :-) I followed an online tutorial geared to Google mail to\nbasically run git format-patch | git imap-send but the end result did\nnot have the tabs that I have in the code. I'll have to research it a\nbit more then.\n\nCheers,\nHilco\n"},{"id":"250124","messageId":"xmqqy4szpvfv.fsf@gitster.dls.corp.google.com","threadId":"37638","inReplyTo":"CAE1pOi1dAO7XFZtrgZyNm-eLVKQx=KpeejbGmF8khCofAppDLg@mail.gmail.com","subject":"Re: [PATCH] init - Honour the global core.filemode setting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-01T17:10:44Z","receivedAt":"2014-10-01T17:10:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:\n\n> Perhaps I completely misunderstand the meaning of core.filemode but I\n> thought it determined whether Git cared about changes in file\n> properties?\n\nBy setting it to \"false\", you tell Git that the filesystem you\nplaced the repository does not correctly represent the filemode\n(especially the executable bit).\n\n\"core.fileMode\" in \"git config --help\" reads:\n\n       core.fileMode\n           If false, the executable bit differences between the\n           index and the working tree are ignored; useful on broken\n           filesystems like FAT. See git-update- index(1).\n\n           The default is true, except git-clone(1) or git-init(1)\n           will probe and set core.fileMode false if appropriate\n           when the repository is created.\n\nMaybe our documentation is not clear enough.  A contribution from\nsomebody new to Git we would appreciate would be to point out which\npart of these sentences are unclear; that way, people can work on\nimproving its phrasing.\n\nThanks.\n"},{"id":"250160","messageId":"542D33E1.6080709@web.de","threadId":"37638","inReplyTo":"xmqqy4szpvfv.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] init - Honour the global core.filemode setting","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2014-10-02T11:15:45Z","receivedAt":"2014-10-02T11:15:45Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2014-10-01 19.10, Junio C Hamano wrote:\n> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:\n> \n>> Perhaps I completely misunderstand the meaning of core.filemode but I\n>> thought it determined whether Git cared about changes in file\n>> properties?\n> \n> By setting it to \"false\", you tell Git that the filesystem you\n> placed the repository does not correctly represent the filemode\n> (especially the executable bit).\n> \n> \"core.fileMode\" in \"git config --help\" reads:\n> \n>        core.fileMode\n>            If false, the executable bit differences between the\n>            index and the working tree are ignored; useful on broken\n>            filesystems like FAT. See git-update- index(1).\n\nOut of my head: Could the following be a starting point:\n\n        core.fileMode\n            If false, the executable bit differences between the\n            index and the working tree are ignored.\n            This may be usefull when visiting a cygwin repo with a non-cygwin\n            Git client. (should we mention msysgit ? should we mention JGit/EGit ?)\n\t    This may even be useful for a repo on a SAMBA network mount,\n            which may show all file permissions as 0755.\n            See git-update-index(1) for changing the executable bit in the index. \n\n            The default is true, except git-clone(1) or git-init(1)\n            will probe and set core.fileMode false if appropriate\n            when the repository is created.\n> \n> Maybe our documentation is not clear enough.  A contribution from\n> somebody new to Git we would appreciate would be to point out which\n> part of these sentences are unclear; that way, people can work on\n> improving its phrasing.\n> \n> Thanks.\n"},{"id":"250174","messageId":"xmqqzjdeo16d.fsf@gitster.dls.corp.google.com","threadId":"37638","inReplyTo":"542D33E1.6080709@web.de","subject":"Re: [PATCH] init - Honour the global core.filemode setting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-02T17:02:02Z","receivedAt":"2014-10-02T17:02:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen <tboegi@web.de> writes:\n\n> On 2014-10-01 19.10, Junio C Hamano wrote:\n>> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:\n>> \n>>> Perhaps I completely misunderstand the meaning of core.filemode but I\n>>> thought it determined whether Git cared about changes in file\n>>> properties?\n>> \n>> By setting it to \"false\", you tell Git that the filesystem you\n>> placed the repository does not correctly represent the filemode\n>> (especially the executable bit).\n>> \n>> \"core.fileMode\" in \"git config --help\" reads:\n>> \n>>        core.fileMode\n>>            If false, the executable bit differences between the\n>>            index and the working tree are ignored; useful on broken\n>>            filesystems like FAT. See git-update- index(1).\n>\n> Out of my head: Could the following be a starting point:\n>\n>         core.fileMode\n>             If false, the executable bit differences between the\n>             index and the working tree are ignored.\n>             This may be usefull when visiting a cygwin repo with a non-cygwin\n>             Git client. (should we mention msysgit ? should we mention JGit/EGit ?)\n\nBetween these two sentences, there may still be the same cognitive\ngap that may have lead to the original confusion.\n\nThe first sentence says what happens, as it should.\n\nBut it is not directly clear what makes the executable bit differ\nand when it is a useful thing to ignore the differences, so the\nsecond sentence that says \"This may be useful\" does not give the\nreader very much.\n\nHere is my attempt.\n\n\tTells Git if the executable bit of files in the working tree\n\tis to be honored.\n\n\tSome filesystems lose the executable bit when a file that is\n\tmarked as executable is checked out, or checks out an\n\tnon-executable file with executable bit on.  \"git init\" and\n\t\"git clone\" probe the filesystem to see if it records\n\texecutable bit correctly when they create a new repository\n\tand this variable is automatically set as necessary.\n\n        A repository, however, may be on a filesystem that records\n        the filemode correctly, and this variable is set to 'true'\n        when created, but later may be made accessible from another\n        environment that loses the filemode (e.g. exporting ext4 via\n        CIFS mount, visiting a Cygwin managed repository with\n        MsysGit).  In such a case, it may be necessary to set this\n        to 'false'.\n"},{"id":"250200","messageId":"542ED4B8.40603@web.de","threadId":"37638","inReplyTo":"xmqqzjdeo16d.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] init - Honour the global core.filemode setting","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2014-10-03T16:54:16Z","receivedAt":"2014-10-03T16:54:16Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2014-10-02 19.02, Junio C Hamano wrote:\n> Torsten Bögershausen <tboegi@web.de> writes:\n> \n>> On 2014-10-01 19.10, Junio C Hamano wrote:\n>>> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:\n>>>\n>>>> Perhaps I completely misunderstand the meaning of core.filemode but I\n>>>> thought it determined whether Git cared about changes in file\n>>>> properties?\n>>>\n>>> By setting it to \"false\", you tell Git that the filesystem you\n>>> placed the repository does not correctly represent the filemode\n>>> (especially the executable bit).\n>>>\n>>> \"core.fileMode\" in \"git config --help\" reads:\n>>>\n>>>        core.fileMode\n>>>            If false, the executable bit differences between the\n>>>            index and the working tree are ignored; useful on broken\n>>>            filesystems like FAT. See git-update- index(1).\n>>\n>> Out of my head: Could the following be a starting point:\n>>\n>>         core.fileMode\n>>             If false, the executable bit differences between the\n>>             index and the working tree are ignored.\n>>             This may be usefull when visiting a cygwin repo with a non-cygwin\n>>             Git client. (should we mention msysgit ? should we mention JGit/EGit ?)\n> \n> Between these two sentences, there may still be the same cognitive\n> gap that may have lead to the original confusion.\n> \n> The first sentence says what happens, as it should.\n> \n> But it is not directly clear what makes the executable bit differ\n> and when it is a useful thing to ignore the differences, so the\n> second sentence that says \"This may be useful\" does not give the\n> reader very much.\n> \nClearly a major improvement.\n\nDoes this (still) include the original line\n\"See linkgit:git-update-index[1]\"\n\nwhich helps the user to add *.sh files \"executable\" to the index, even if\ncore.filemode is false ?\nOne minor improvement below.\n\n> Here is my attempt.\n> \n> \tTells Git if the executable bit of files in the working tree\n> \tis to be honored.\n> \n> \tSome filesystems lose the executable bit when a file that is\n> \tmarked as executable is checked out, or checks out an\n> \tnon-executable file with executable bit on.  \"git init\" and\n> \t\"git clone\" probe the filesystem to see if it records\n> \texecutable bit correctly when they create a new repository\n> \tand this variable is automatically set as necessary.\n> \n>         A repository, however, may be on a filesystem that records\n>         the filemode correctly, and this variable is set to 'true'\n>         when created, but later may be made accessible from another\n>         environment that loses the filemode (e.g. exporting ext4 via\n>         CIFS mount, visiting a Cygwin managed repository with\n>         MsysGit).  In such a case, it may be necessary to set this\n>         variable to 'false'.\n          ^^^^^^^^ \n"},{"id":"250201","messageId":"xmqqegupm69n.fsf@gitster.dls.corp.google.com","threadId":"37638","inReplyTo":"542ED4B8.40603@web.de","subject":"Re: [PATCH] init - Honour the global core.filemode setting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-03T17:07:16Z","receivedAt":"2014-10-03T17:07:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen <tboegi@web.de> writes:\n\n>> The first sentence says what happens, as it should.\n>> \n>> But it is not directly clear what makes the executable bit differ\n>> and when it is a useful thing to ignore the differences, so the\n>> second sentence that says \"This may be useful\" does not give the\n>> reader very much.\n>> \n> Clearly a major improvement.\n>\n> Does this (still) include the original line\n> \"See linkgit:git-update-index[1]\"\n>\n> which helps the user to add *.sh files \"executable\" to the index, even if\n> core.filemode is false ?\n\nThanks for catching; I omitted the reference by accident.\n\nPerhaps end that sentence like this instead?\n\n\t... may be necessary to set this variable to `false`, and\n\tmaintain the executable bit with `git update-index --chmod`\n\t(see linkgit:git-update-index[1]).\n"}]}