Reece Dunn wrote:
> On 02/09/07, Marius Storm-Olsen <marius@xxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
