Thanks again. On Friday, January 17, 2014 11:55 AM, Torsten Bögershausen <tboegi@xxxxxx> wrote: (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@xxxxxx> 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@xxxxxxxxx> > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html