Git on windows, is it truly distributed?

I am just starting out with git on the Windows platform. I have mysygit installed and bar a few hiccups I am 'git'ing away nicely.

However, I must be missing something because I don't understand how two msysgit clients on different Windows machines can push and pull to each other directly?

I am a complete linux noob but I think I can see that the ssh thing allows distribution on linux. However, the msysgit client appears just to be additional commands in the windows cmd prompt and there is no windows service element.

If I try git clone 'MyMatesPc' who is going to be listening to this request at the other end?

I can see that if you have a 'central' server running git on linux (or cygwin), you can share commits by pushing them onto the 'central' repo from one machine, then pulling them down onto another.

This effectively means that you are having to use a central server.

I don't have a problem with this, but wanted to check that I am not missing anything!

You can use the local protocol: a simple shared path is enough for two Git repositories on two PC on the same LAN to push/pull from each other.
No need (in this case) for a "central" server.

As Noel Kennedy points out in the comments, he had to locally map a drive letter to the remote repo before executing: git clone file:///z.
That is the safest path, since UNC paths are not always supported with some versions of msysgit.

You can use UNC paths with recent msysgit versions though, like in a Git bash session:

$ cd /c/temp
$ git clone //remote-host/share/path/to/repo.git

(note the '/' instead of the Windows '\')

In a DOS session, after adding the mingw/bin path, it might work too (i.e. using an UNC path instead of a mapped drive)

C:\temp>set PATH=%PATH%;c:\msysgit\bin;c:\msysgit\mingw\bin
C:\temp>git clone \\\\remote-host\\share\\path\\to\\repo.git

Update August 2014 (4 years later), Git 2.1

Commit c2369bd by Eric Sunshine and Cezary Zawadka (czawadka) means a simpler UNC path now work:

Windows: allow using UNC path for git repository

Eric Sunshine fixed mingw_offset_1st_component() to return consistently "foo" for UNC "//machine/share/foo", cf this thread.

So this should now work:

git clone //mymachine/shared/repo.git

This is a pretty common misconception about (one of the many) development workflows using git, independent of the msysgit issue.

Git is distributed development in that no repository has any particular design or structure that makes it any more authoritative than any other - you can do anything you would do with a central repository on your local one, and from that perspective they are all on equal footing.

For example in the Linux kernel, there are hundreds of different, public repositories: generally Linus' is regarded as the authoritative one, and the releases on kernel.org are cut from his tree, but many people or projects use or maintain other trees ("forks", though that term has certain connotations), and because of git's support for this there is very little impedance mismatch or overhead in tracking the development that happens in Linus' tree (or any other tree - seeing the pattern now?).

Many projects use a central repository, since that's a well-understood model for collaboration, or because it fits in an existing continuous integration setup - and git is just as suited for this style of development - but this is a workflow decision, not one mandated (or even favored) by git itself.

As far as msysgit or Cygwin are concerned, you should have no problem using ssh through those, and there's also PuTTy as a native Windows client for using the SSH protocol - its by no means specific to UNIX hosts. It's also easy to use the native git protocol, or HTTP to pull as well (pushing is another issue). (As VonC said, you can pull from local repositories as well, so if you have a network/Samba share or whatever its all the same to git).

There are a lot of ways to handle cloning repositories, depending upon the connectivity between two machines. If you want to avoid the hassle of standing up a Git server on Windows, then you could store the Git repositories on a shared directory, and access them using the file: protocol. Depending upon the Git client you use, you may need to map that shared directory to a drive letter.

git server components are not yet well supported on win32, imho.

Nothing saying you can't take patches from people via email and apply them to your repository.

Also, the point of distributed version control is that while you MAY choose to sync with a remote repository, you don't have to. Nothing is stopping you from using git on your disconnected PC anywhere in the world (including the middle of the ocean or a remote desert).