CODEWITHSUNDEEP
git
Diemuzi
Diemuzi

Reputation: 3527

Windows Git to Linux Remote

I'm not certain what I am doing wrong. In the past I used to use Zend Studio and it handled everything Git related for me and still does as of this moment. But I'm dropping Zend Studio and doing things by hand now.

My current setup is Windows 8 and I've installed the Git Windows binaries on my machine. I am able to commit to the local repository without any problems.

On my Remote Linux machine I've got the repositories setup there and I am able to pull from the repository without any problems.

On the Linux machine I start Git like this: /usr/local/git/libexec/git-core/git-daemon --verbose --export-all --base-path=/usr/local/git/repository --base-path-relaxed --listen=git.sitegoodies.net --enable=receive-pack

and it returns [1619] Ready to rumble

On my Windows machine I've committed a few changes and now I want to push them to my remote repository and I do it like this: git push git://git.sitegoodies.net/test.git master

I can see the following:

$ git push git://git.sitegoodies.net/test.git master
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6)

But now it just sits there. So I look at my linux console from when I started Git and I can see this:

[1619] Ready to rumble
[1622] Connection from [fd35:4776:6804:1::1]:58695
[1622] Extended attributes (26 bytes) exist <host=git.sitegoodies.net>
[1622] Request receive-pack for '/test.git'

So to me it looks like everything should be working. Except everything just sits there until I Ctrl + C to cancel it from pushing to my remove repository. I really have no idea what is wrong, so I'm hoping someone here has an idea I can try.

I do not have any firewall.

My repositories are located in /usr/local/git/repository To create test.git:

Anyone have any ideas?

Upvotes: 0

Views: 302

Answers (1)

kostix
kostix

Reputation: 55443

Don't do that — pushing to git-daemon is broken in Git for Windows. All attempts made to this day to debug this problem have failed.

So your best bet is to use SSH transport, I suppose — this is not hard.

Upvotes: 1

Related Questions