delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
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:in-reply-to:references:date | |
:message-id:subject:from:to:content-type | |
:content-transfer-encoding; q=dns; s=default; b=YlN+/Ruce3+uhx9N | |
JwPVeibdaavYDFjkXCPkwIa07lJl4XxO/B846V0rGm3VpLzAvkS3V+Fn86w+Ub3X | |
6ZltcwK6Gxu/YwHNYL1j8XBw5L/H3aNcV1tJqLkYTP4cDtnoWInNEclmEPwZnObN | |
l7oJjO752cD/UDEVgSP3xGjTNPo= | |
DKIM-Signature: | v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:mime-version:in-reply-to:references:date | |
:message-id:subject:from:to:content-type | |
:content-transfer-encoding; s=default; bh=K1J/Xl8xsMRIkNHPzR3oZs | |
i4XNo=; b=ViRHi6OgNB0SWj+PBC1Q9skM8L9MDYVYSqStSC15ToVrQhSdPZdhjf | |
a2wKskRKM7Ooru7X/Zab/R8ukTbSSSPiiKoi78YNSlRaudiFP0qV2ckf2PhesbPN | |
dnBYhHA1BgeHO2t3Ilv3bEcI9Qma5/RXjPIeTU6/z4K5TyFTNWs/k= | |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
Sender: | cygwin-owner AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
Delivered-To: | mailing list cygwin AT cygwin DOT com |
Authentication-Results: | sourceware.org; auth=none |
X-Virus-Found: | No |
X-Spam-SWARE-Status: | No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=sk:astern, asternfix8forumgmailcom, U*astern.fix8.forum, astern DOT fix8 DOT forum AT gmail DOT com |
X-HELO: | mail-wm0-f45.google.com |
X-Google-DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-transfer-encoding; bh=+vvkDq2udI9OfGYY60tLzGDa5RoXGGarVf0jH6BdsuE=; b=aGyUczcy7h3XuYzg6iI8P/8l7ySTPY73t9OCdlj5SzC6RkggP7pW0aGLzZNIBwtFoP fNerDOvvKkAve5yKKMRIUa82GZg7s6ira/WF3wVKl5cHrMMPA6Z21MdtWTcj40hrE//V hgOEq+MgCRhLN5VcPPMYjxRoCYUbOCJ/axiz0Ov0b7CyTQSknNqcPhGiA5ahNcb9RBli EpufXiNSKJWAOqbbNbCMEAu5eww9YZIOICbL+IiLaWP/24yufo49ZpXz5wvREP5ST75n ySuYoINvDsSYkIiDRR31QrSx38Gh3guh9HQbgom14Vrbbjzr+29pQOk7AdLD+UAJV686 TaVg== |
X-Gm-Message-State: | AOPr4FV7/UW856nx5WK1qVZkRBbyUlGPJuMBAYx2DGb1lCs2zpO1LGvBbouL4caC9d4I0CiPWy+KmF2Eg+PcMQ== |
MIME-Version: | 1.0 |
X-Received: | by 10.28.105.67 with SMTP id e64mr13064904wmc.80.1462823979752; Mon, 09 May 2016 12:59:39 -0700 (PDT) |
In-Reply-To: | <CADMefsZZ0MbUhWGfvUdiSTf4UPrCbvTwrmjP84q5TvWcPv10dg@mail.gmail.com> |
References: | <CADMefsZZ0MbUhWGfvUdiSTf4UPrCbvTwrmjP84q5TvWcPv10dg AT mail DOT gmail DOT com> |
Date: | Mon, 9 May 2016 15:59:39 -0400 |
Message-ID: | <CADMefsZfsH=+Ci3v04n7QH6UqFjgbAZ6j9BbUO-X2rJgHRgBqQ@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 |
X-MIME-Autoconverted: | from quoted-printable to 8bit by delorie.com id u49Jxwff018009 |
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 <astern DOT fix8 DOT forum AT gmail DOT com> 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? -- 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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |