>>> If I leave off the noacl and do a clone followed by a push and pull
>>> we
>>> >end up with the following error in the Windows security tab:
>>> > The permissions on file.cpp are incorrectly ordered, which may
>>> >cause some entries to be ineffective.
>> Yes, I've seen that before; it's a pr
>To be absolutely clear: if you mount an NFS share with noacl set, you get a
>noticable speed increase versus not setting noacl?
Let me clear this up a bit. The group is working on local
repositories that happen to exist on local NTFS drives under Windows.
These drives are the same local drives t
>I'm not sure I understand what you're seeing: if your repository is already
>set up with core.filemode set to false, Git won't check the executable flag on
>the files. What leads you to think the speed slow-down is related to
>>checking whether the file is executable?
>If setting cygexec make
>I suspect this isn't a problem with the Git upgrade but with recent
>changes that have been being made to how the core Cygwin dll handles
>permissions.
>That being said, can you try running `git config core.filemode false` in
>the repository, re-enabling noacl, and see if that has things running
ce: run_command: 'gc' '--auto'
So it is clear that my fix for the Windows permissions is causing the
merge to take a very long time.
On 9 May 2016 at 14:34, andrew stern wrote:
> Recently I upgraded to version 2.8.0 of git on cygwin. I’m running
> under Windows 2008 R2
Recently I upgraded to version 2.8.0 of git on cygwin. I’m running
under Windows 2008 R2. Before this upgrade we were able to share a
NFS drive as a main repository. After the upgrade the permissions
were changed so that only a single person had write access to the
repository on a shared NFS dri
6 matches
Mail list logo
