This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: git fails to push
- From: Warren Young <wyml at etr-usa dot com>
- To: The Cygwin Mailing List <cygwin at cygwin dot com>
- Date: Wed, 18 Mar 2015 08:33:51 -0600
- Subject: Re: git fails to push
- Authentication-results: sourceware.org; auth=none
- References: <5502264B dot 3050803 at lysator dot liu dot se> <C31449BA-B14C-4047-981B-6980AB755309 at etr-usa dot com> <5508284B dot 1040304 at lysator dot liu dot se>
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