DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; q=dns; s=default; b=AieNbWyI07N/HaKhlm1yvRdMNIxi
	wO8LpaLClA6yfyIEOHXJVoPdO84wTGKQ7Y9r40/DINio1bB9QXCCtYXbKvTi8nIL
	QbMR+LnwXeCyGLKQ1DixWtoOTkdrjMhKQmi4sVZSL8FB/Yc3kdvAOmDhAHDnZHdL
	FCBhlWckM9fsVQs=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Re: git fails to push
From: Warren Young <wyml@etr-usa.com>
In-Reply-To: <5508284B.1040304@lysator.liu.se>
Date: Wed, 18 Mar 2015 08:33:51 -0600
Message-Id: <A4547C34-7174-4F7E-A307-DA23F9768892@etr-usa.com>
References: <5502264B.3050803@lysator.liu.se> <C31449BA-B14C-4047-981B-6980AB755309@etr-usa.com> <5508284B.1040304@lysator.liu.se>
To: The Cygwin Mailing List <cygwin@cygwin.com>
Content-Transfer-Encoding: 8bit

On Mar 17, 2015, at 7:12 AM, Peter Rosin <peda@lysator.liu.se> wrote:
> 
> On 2015-03-16 22:45, Warren Young wrote:
> 
>> I think if you set Git up on the server using one of the supported server protocols [*] your problem will go away.
> 
> You almost make it sound like file:// isn't a supported server protocol.
> Isn't it? If not, why is it listed under "Git on the Server" and why
> is NFS mounts mentioned?

Are you trying to argue that all four options given on that page are equally good, or that the page is comprehensive in its assessment of pros and cons?  They aren’t, and it isn’t.

Do you believe the one who wrote it thought once about Cygwin while writing it? I don’t.  I don’t even see much evidence that the author was thinking about Windows at all.

As for defending the use of CIFS by mentioning NFS, they’re very different beasts.  NFS is actually worse, in that rpc.lockd is entirely optional.  Yet, there it is, a “recommended” option in that chapter.  What does that say about how much we should trust the information presented?

Meanwhile, locking in CIFS tends to swing the other way entirely: a single program that merely opens a file in certain naive ways creates a whole-file lock on it that even prevents read-only access, which annoys programs that assume POSIX file locking semantics.

> I don't think the real
> problem is in the git code base. It feels more like some generic file
> access race that manifests itself as freshly created files not being
> found, or something like that.

I think you’re not far off in that assessment.  What I think you’ve missed is that POSIX and Windows file locking semantics are almost diametrically opposed in their approach, and that programs that come from the POSIX world often get badly tripped up when you run them on Windows.

By putting the file I/O code entirely on the Git server, you decouple the two systems’ file locking, so that they no longer have to cooperate.
--
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