DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:date:message-id:subject:from:to
	:content-type:content-transfer-encoding; q=dns; s=default; b=slQ
	4Z1JnY/Q/x34ChOuZrRv/ly5axGqLFJeVNcXaBH9mIFwIe1wdAPAi/lifBdeo6vx
	ej1GVE9YSgNifWLWu8Bn+783mwFNbzKv3aUmhbr9kQn1rnypvnrw7ncBXrqdy+ed
	1qqUXXeJ9KIOUf+7SjbCoQhP0hmmKlwYlQI7GEMg=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
MIME-Version: 1.0
Date: Mon, 16 May 2016 08:51:53 -0400
Message-ID: <CADMefsacKkUX1Sz-k+SOK4M4NkdGWoCnD5LpVszW2q9nchvwDQ@mail.gmail.com>
Subject: RE: Possible issue with newest version of git (v 2.8) under Cygwin
From: andrew stern <astern DOT fix8 DOT forum AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

>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 that we make changes to before
pushing up the changes.  The local drives when mounted using the
default setting for cygwin is much slower then when we add noacl to
the fstab files mount line.  The NFS drives isn't accessed directly
except though git commands because we store our common repository on a
shared drive instead of running a git server like github or gitblit.

>> Although the repository
>> is on a NFS drive the local file system is NTFS and I see it spending
>> lots of time doing the update on the merge even though it is just a
>> couple of files that have changed.  I'm still trying to figure out
>> what exactly is going on and how best to deal with the permissioning
>> issue that we are now experiencing.  After discussions we would rather
>> have it slow then have bad permission problems but I'd rather not have
>> either issue.

>Am I correct in understanding you have multiple users trying to access the same shared Git working repository?  I'm aware it's a workaround rather than an actual >solution, but I'd expect you'd have better luck with each having a separate working copy on your >local machine rather than sharing a common working copy.

We do have local copies but we have to push our changes somewhere
after we change our local tree.  In this case it is a shared NFS
drive.

>> 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 problem with the underlying cygwind1.dll rather than a problem with Git.  I believe the consensus from people on this list who
>know more about Windows permissions than me is that the warning is actually benign and can be ignored.

The warning isn't benign in this case as it messes up the permissions
so that all the other team members no longer have write permissions so
that they can't check in their changes.   Before the recent ACL
changes to cygwin we worked without any issues and have been using git
and cygwin for years before these changes.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple