What "op" exactly? git push/pull? git push/pull are bandwidth efficient and atomic. A failed pull/push wont destroy your local/remote copy.

It tends to drop your connection on large packs.

Thats more a server configuration thing, many git hosts disconnect slow clients.

I was in Botswana for a few weeks in November and I can relate to that sentiment: git was unusable down there.

Yuck, BTDTBTTS. Satellite latency is eye-stabbing, almost as bad as the utterly worthless Mountain View's Google Wi-Fi. Local internet elsewhere, in random countries, GFL... bring your own or start a service (yeah, a friend made some serious cash putting up a service on some Greek island).

Anyone on OSX can feel some pain just by enabling Network Link Conditioner prefpane by creating a profile as follows:

  Download Bandwidth: 256 Kbps
  Downlink Packets Dropped: 90%
  Downlink Delay: 1000 ms

  Uplink Bandwidth: 256 Kbps
  Uplink Packets Dropped: 90%
  Uplink Delay: 1000 ms

  DNS Delay: 2000 ms

Setup instructions:

http://mattgemmell.com/network-link-conditioner-in-lion/

The issue is never being able to complete the fetch or push because of a spotty network.

It goes without saying that source control should not screw up my local or remote copies.

Given that 90% of operations don't touch the network at all, I'm not sure how that counts as absolute fail. With the exception of doing an initial clone on a connection that's so slow and unreliable that "clone --depth 1" doesn't work, I can't think how git would stop a remote developer from working, only how it would help them...

I tend to get around large network operations on slow connections by rsyncing the repository from the remote mirror, doing a git clone of the now local mirror with no hard links to a local version, and finally setting the remote origin of the local version to the original remote mirror.

I agree that these sorts of mental acrobatics would be unnecessary if git had proper resume support, but for me at least it's not a total showstopper.