This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Possible issue with newest version of git (v 2.8) under Cygwin


On Mon, May 09, 2016 at 03:59:39PM -0400, andrew stern wrote:
> If I change my fstab back so that it does not include the noacl option
> on the line the merge is much faster:
> 
> 15:51:22.288607 git.c:350               trace: built-in: git 'merge'
> 'FETCH_HEAD' Updating 154cf50..a0f35eb
> Fast-forward
> 15:55:18.347594 run-command.c:336       trace: 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.  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 drive.  When the push is done to the NFS
> > drive these permissions cause deny write access to the other users of
> > the repository so we couldnât update the sha1 of the head reference.
> > An example of the incorrect permissions are:
> >
> >
> > Allow     User                         Special            not
> > inherited      This folder only
> > Allow     dev                          Special            not
> > inherited     This folder only
> > Allow     Everyone                     Read & execute     not
> > inherited      This folder, subfolders and
> > Allow     Administators for machine    Special            not
> > inherited      This folder only
> > Allow     SYSTEM                       Special            not
> > inherited      This folder only
> > Allow     Users for machine            Special            not
> > inherited      This folder only
> > Allow     CREATOR OWNER                Special            not
> > inherited     Subfolders and files only
> > Allow     CREATOR GROUP                Special            not
> > inherited     Subfolders and files only
> >
> > But the Windows permissions should have been inherited only.  Also not
> > the group dev is not in the list.  The permissions after a push showed
> > dev on the shared NFS drive along with errors that the permissions
> > were out of order.
> >
> > Allow     Administators           Full Control       D:\  This folder,
> > subfolders and
> > Allow     SYSTEM                  Full Control       D:\  This folder,
> > subfolders and
> > Allow     User                    Special            D:\  This folder only
> > Allow     CREATOR OWNER           Special            D:\  Subfolders
> > and files only
> > Allow     User on Machine         Read & execute     D:\  This folder,
> > subfolders and
> > Allow     User on Machine         Special            D:\  This folder,
> > subfolders
> >
> >
> > After searching through new groups and the web it was decided to add
> > noacl to the fstab for the cygwin mount:
> >
> > none /cygdrive cygdrive binary,posix=0,user,noacl 0 0
> >
> > Now we are finding that the git merge onto our local drive after a
> > fetch from the NFS shared repository is taking a very long time.
> > (shown with >> in front on below line)
> >
> > $ git pull origin MCSTRATEGY_4_4
> > 13:01:16.587064 git.c:351               trace: built-in: git 'pull'
> > 'origin' 'MCSTRATEGY_4_4'
> > 13:01:16.752064 run-command.c:336       trace: run_command: 'fetch'
> > '--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
> > 13:01:16.790064 exec_cmd.c:120          trace: exec: 'git' 'fetch'
> > '--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
> > 13:01:16.821064 git.c:351               trace: built-in: git 'fetch'
> > '--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
> > 13:01:17.069064 run-command.c:336       trace: run_command:
> > 'git-upload-pack
> > '\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
> > 13:01:17.136064 run-command.c:195       trace: exec: '/bin/sh' '-c'
> > 'git-upload-pack
> > '\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
> > 'git-upload-pack
> > '\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
> > 13:01:18.084064 run-command.c:336       trace: run_command: 'rev-list'
> > '--objects' '--stdin' '--not' '--all' '--quiet'
> > 13:01:18.229064 run-command.c:336       trace: run_command: 'rev-list'
> > '--objects' '--stdin' '--not' '--all'
> > 13:01:18.284064 exec_cmd.c:120          trace: exec: 'git' 'rev-list'
> > '--objects' '--stdin' '--not' '--all'
> > 13:01:18.314064 git.c:351               trace: built-in: git
> > 'rev-list' '--objects' '--stdin' '--not' '--all'
> > From /cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.
> >  * branch            MCSTRATEGY_4_4 -> FETCH_HEAD
> > 13:01:18.367064 run-command.c:952       run_processes_parallel:
> > preparing to run up to 1 tasks
> > 13:01:18.373064 run-command.c:984       run_processes_parallel: done
> > 13:01:18.375064 run-command.c:336       trace: run_command: 'gc' '--auto'
> > 13:01:18.410064 exec_cmd.c:120          trace: exec: 'git' 'gc' '--auto'
> > 13:01:18.440064 git.c:351               trace: built-in: git 'gc' '--auto'
> > 13:01:18.454064 run-command.c:336       trace: run_command: 'merge' 'FETCH_HEAD'
> > 13:01:18.486064 exec_cmd.c:120          trace: exec: 'git' 'merge' 'FETCH_HEAD'
> >>> 13:01:18.517064 git.c:351               trace: built-in: git 'merge' 'FETCH_HEAD'
> > Updating 9c40e07..a0f35eb
> > Fast-forward
> > 13:18:39.432839 run-command.c:336       trace: run_command: 'gc' '--auto'
> > 13:18:43.559539 exec_cmd.c:120          trace: exec: 'git' 'gc' '--auto'
> > 13:18:43.623539 git.c:351               trace: built-in: git 'gc' '--auto'
> >  file.cpp | 5 +++--
> >
> > First question is could this very large delay on git merge be caused
> > by the noacl?  If noacl is causing this very large delay (which I
> > suspect to be the case since we didnât have this large delay till the
> > noacl was added) is there another way to fix the permission issue when
> > using an NFS drive as a shared repository?

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 at
something more like normal speed?  That disables Git's checks on file
permissions, so it should isolate whether the slow-down is specifically
Git checking permissions or if merely accessing files is the problem.

(With core.filemode disabled, you'll need to use `git update-index` to
add/remove the executable flag on files in the Git repository; see `git
help update-index` for details on how that works.  To undo the config
change, use `git config core.filemode true`.)

Adam

--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]