Re: [cygwin] Re: git fails to push

[Peter Rosin <peda at lysator dot liu dot se>]

On 2015-03-17 14:33, Jason Pyeron wrote:
> Pardon the direct reply, but my posts are blocked.

Perhaps your boilerplate footer with copyright claims, or the
raw email addresses? I took the liberty or forwarding it
to the list. I hope that was ok.

>                                                    See: 
> http://article.gmane.org/gmane.comp.version-control.git/260968
> 
> https://www.cygwin.com/ml/cygwin/2014-12/msg00096.html
> 
> and the forwarded message below.

Interesting. But the patch may not be needed. The easy thing to
do seems to be to either use core.createobject = rename
or to convince some git :-) that Cygwin also needs
	OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedTo
in its section in config.mak.uname.

Reading the explanation for the option in the git Makefile makes
me think that this is obviously needed on Cygwin too.

	"Define OBJECT_CREATION_USES_RENAMES if your operating
	system has problems when hardlinking a file to another
	name and unlinking the original file right away (some
	NTFS drivers seem to zero the contents in that scenario)." 

NTFS drivers ought to be the same on Windows and Cygwin, and
I imaging that Cygwin will have a hard time fixing it up...

>> -----Original Message-----
>> From: Peter Rosin
>> Sent: Tuesday, March 17, 2015 9:13
>>
>> On 2015-03-16 22:45, Warren Young wrote:
>>> On Mar 12, 2015, at 5:50 PM, Peter Rosin 
>> <elided> wrote:
>>>>
>>>> To file:///cygdrive/x/some path/with spaces/repo.git
>>>
>>> You shouldn't be doing anything shared-database-like to a 
>> network drive.  Network file sharing protocols typically 
>> either A) do not do locking correctly, or B) they run slow as 
>> molasses in order to provide proper locking semantics.  Since 
>> almost no one is willing to accept option B), you usually get 
>> option A).
>>
> 
> This seems like the race condition we encountered on __some__ SMB/CIFS servers.
>  
>> Even if you claim that I shouldn't do something and then list a couple
>> of reasons for that, you have no way of knowing if these reasons apply
>> or if the alternative is even worse.
>>
>> I am the only person who has ever pushed to the repo in question.
>> Speed is not an issue, I push fairly seldom. The code base is stable.
>>
>>> 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?
> 
> NFS is different from CIFS/SMB, but it is not the protocol, but the processing of the files on the remote server.

I was unclear, of course NFS is different from CIFS/SMB. I do not
use NFS but instead equated them in a broad terms (as in network
file systems).

>>
>> I realize that you are trying to help me work around the problem, but
>> finding a workaround isn't my motivation for posting here (I 
>> have a big
>> enough toolbox to find plenty myself). In fact, 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.
> 
> Can you compile git your self? You can comment out the check and test.
> 
> I will be happy to update the patch if needed.

[Above linked message snipped]

Cheers,
Peter


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