hi git

2016-10-01 Thread SH
hey git

http://owcomunicacao.com.br/swimming.php?henry=b2z10tymag0bzt5ut


Best Wishes
SH


Re: file permissions in Git repo

2014-01-17 Thread SH
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.





On Friday, January 17, 2014 10:08 AM, Torsten Bögershausen tbo...@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 gits...@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

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: file permissions in Git repo

2014-01-17 Thread SH
Thanks again.





On Friday, January 17, 2014 11:55 AM, Torsten Bögershausen tbo...@web.de 
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 tbo...@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 gits...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


file permissions in Git repo

2014-01-16 Thread SH


Hi


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?

We also tried post-commit and post-receive hooks to set the permission but
it didnt seem to work either.


Thanks
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html