Reece Dunn wrote:
> On 02/09/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
>> This gives us a significant speedup when adding, committing and stat'ing files.
>> (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)
>>
>> +               if (ext && (!_stricmp(ext, ".exe") ||
>> +                           !_stricmp(ext, ".com") ||
>> +                           !_stricmp(ext, ".bat") ||
>> +                           !_stricmp(ext, ".cmd")))
>> +                       fMode |= S_IEXEC;
>> +               }
> 
> This breaks executable mode reporting for things like configure 
> scripts and other shell scripts that may, or may not, be executable. 
> Also, you may want to turn off the executable state for some of these
> extensions (for example if com or cmd were not actually executable 
> files). This makes it impossible to manipulate git repositories 
> properly on the MinGW platform.

Actually, you don't really need the EXEC bit for Git to work. I just
added it for completeness. (We _could_ remove that too, since it's
slowing us down slightly ;-)

Remember that Git isn't using MSys for its builtins, so MinGW Git
doesn't understand the MSys notion of executable files anyways.
The MinGW port actually peeks at the beginning of a file (ignoring exe
files), and sees if there's an interpreter there. If there is, it will
expand
    git-foo args...
into
    sh git-foo args...
and execute the command. So, it's not really affected by this change.

I haven't had any problems with this patch on my system, so could you
explain what you mean with 'this makes it impossible to manipulate git
repositories'?

> Would it be possible to use the git tree to manage the executable 
> state? That way, all files would not have their executable state set 
> by default on Windows. The problem with this is how then to set the 
> executable state? Having a git version of chmod may not be a good 
> idea, but then how else are you going to reliably and efficiently 
> modify the files permissions on Windows?

The file-state-in-git-tree belongs in a different discussion. Have a
look at the '.gitignore, .gitattributes, .gitmodules, .gitprecious?,
.gitacls? etc.' and 'tracking perms/ownership [was: empty directories]'
threads. Permissions are not a trivial topic, since systems represent
them differently. This patch just tries to reflect the read, write and
execute permissions as normal Windows would; and it only cares about
file extensions (and the PE header, if it exists).

Also note that my patch totally ignores the Group & Others part of the
permission bits. Again, we're on Windows so we don't really care. We
_could_ make it reflect the ACLs in Windows, but then we'd have to make
it optional, since that's _really_ slow to 'stat'.

> The rest of the patch looks good on a brief initial scan.

Thanks

--
.marius