Re: file permissions in Git repo

["Torsten Bögershausen" <tboegi@web.de>]

(Please no top posting next time)
On 2014-01-17 20.20, SH wrote:
> On Friday, January 17, 2014 10:08 AM, Torsten Bögershausen <tboegi@web.de> wrote:
> On 01/17/2014 03:26 AM, Jeff King wrote:
> 
>> On Thu, Jan 16, 2014 at 03:58:57PM -0800, SH wrote:
>>
>>> We have a repository which holds lots of shell and perl scripts. We add the
>>> files to repository (from windows client) with executable permissions (using
>>> cygwin) but when we pull that repository on another machine (windows or linux),
>>> files dont have executable permission. Can you please provide a solutions for
>>> this?
>>
>> Git does not preserve file permissions _except_ for the executable bit.
>> So this should be working.
>>
>> However, I suspect that `core.fileMode` is set to `false` in your
>> repository, which causes git to ignore the executable bit. When a
>> repository is initialized, we check whether the filesystem simply
>> creates everything with the executable bit. If so, we turn off
>> core.fileMode for the repository (since otherwise every file would have
>> it set).
>>
>> -Peff
> Cygwin has been a little bit special (and mingw still is).
> Until this commit:
> Author: Junio C Hamano <gitster@pobox.com>
> Date:   Wed Jul 24 19:22:49 2013 -0700
> 
>     Merge branch 'ml/cygwin-updates'
> 
>     The tip one does _not_ revert c869753e (Force core.filemode to
>     false on Cygwin., 2006-12-30) on purpose, so that people can
>     still retain the old behaviour if they wanted to.
> 
>     * ml/cygwin-updates:
>       cygwin: stop forcing core.filemode=false
>       Cygwin 1.7 supports mmap
>       Cygwin 1.7 has thread-safe pread
>       Cygwin 1.7 needs compat/regex
> the repositories created by cygwin had always core.filemode=false.
> 
> You can easily check your configuration by running
> git config -l
> on the cygwin machine, as Peff suggested.
> 
> The next step is to check how the files had been recored in git, using
> git ls-files -s | less
> on any machine.
> 
> If I do this on git.git, we find lines like this, where
> 100755 means an executable file,
> 100644 means non-executable file.
> 
> 100755 9c3f4131b8586408acd81d1e60912b51688575ed 0 
> Documentation/technical/api-index.sh
> 100644 dd894043ae8b04269b3aa2108f96cb935217181d 0 
> Documentation/technical/api-lockfile.txt
> 
> 
> The 3rd step is to check how file are shown in cygwin, run
> ls -l
> (Do they have the executable bit set ?)
> 
> Side note:
> And I think the way the auto-probing of the file system works is
> like this:
> When a git repo is initialized, the .git/config file is created.
> After that, we try to toggle the executable bit, and if lstat reports
> it as toggled, we set core.filemode=true.
> (See builtin/init-db.c, search for core.filemode)
> 
> I tested to create a repo on a network share exported by SAMBA.
> The Server was configured so that all new created files had the
> executable bit set by default.
> Git detected that the executable bit could be switched off,
> and configured core.filemode=true
> Nice.
> 
> /Torsten
> Thanks guys.  Sorry but one more question, like I mentioned we have hosted repositories so how do I make some configuration changes are server based so whether the client have those changes or not, it wouldn't matter. Also I have one client on linux and another one on windows (for my testing purpose) and I see that .git/config on both machines are little different. Is that normal?
> 
> Thanks Again.
That a config file has small differences could be normal:
the server has typically core.bare true.

About other differences, please don't heasitate to consult
http://git-htmldocs.googlecode.com/git/git-config.html

And if there are still questions, they are there to be answered here.
/Torsten