fix OSError on “git fat pull” with manually removed, tracked files in WC

If there is any manually removed, tracked file in the working copy, then
running “git fat pull” fails with an OSError without this fix.
return rsync's exit codes if non-zero in pull and push
Merge branch 'master' of github:nkovacs/git-fat (PR #31)

Support patterns like "git fat push && git push"

* 'master' of github:nkovacs/git-fat:
  return rsync's exit codes if non-zero in pull and push
Merge branch 'fix-OSError-on-removed-tracked-file' of github:cspurk/git-fat (PR #30)

* 'fix-OSError-on-removed-tracked-file' of github:cspurk/git-fat:
  fix OSError on “git fat pull” with manually removed, tracked files in WC
Fail with a clear error if 'git fat pull' is run on uninitialised repo.

This fixes issue #25 in the original project.
Make test-restrospective.sh test script compatible with OSX
Moved requirement for init to `checkout` operation.

Since `checkout` op is where the repo really needs to be init'ed for git-fat
I moved the requirement to there. This way it is still triggered by a `pull`
op, but only at the end after any files have been synced.
Add `verify` command to check git-fat object data matches hash filename.

While experimenting with using the --partial option with rsync I
managed to corrupt one of my git-fat objects by truncating it. This
caused some behaviour in git-fat which seemed odd until I worked out
what had happened: it would check out the truncated data but git would
see the file as modified and show the changed hash in a diff, while a
re-checkout did not reset the file to its original data/hash.

This commit adds a `verify` command that cross-checks git-fat object
file names (the original SHA1) against the SHA1 of the object's
actual data and prints any mismatches. So you can quickly find any
dubious objects and decide what to do about them.

A better solution might be to calcuate and verify objects' data hash
during filter-smudge/checkout though this would likely hurt performance.
Improve performance when looking up referenced objects.

Avoid a cat-file subprocess call per fat object blob by doing slightly
uglier parsing of "cat-file --batch" that includes object content,
instead of "cat-file --batch-check" that doesn't.

In my ad-hoc testing on a reasonable size repository
(50k rev-list -objects) this speeds up 'git fat status' by almost 40%.
Print fatal error message to stderr
Merge branch 'jmurty/ensure-init-before-pull' (PR #33)

* jmurty/ensure-init-before-pull:
  Print fatal error message to stderr
  Moved requirement for init to `checkout` operation.
  Fail with a clear error if 'git fat pull' is run on uninitialised repo.
Merge branch 'add_verify_command' of github:jmurty/git-fat (PR #36)

* 'add_verify_command' of github:jmurty/git-fat:
  Add `verify` command to check git-fat object data matches hash filename.

Conflicts:
	git-fat
Move init diagnostics out of cmd_* section
Replace heavyweight use of python with a simple 'pwd' call
Use custom fullpath() fn to avoid confusion with realpath vs alternative

* Define and use simple `pwd`-based fullpath() function
* Remove misleading comment

Confirmed to work on OSX.
Merge branch 'osx_test_compat_fixes' of github:jmurty/git-fat (PR #35)

* 'osx_test_compat_fixes' of github:jmurty/git-fat:
  Use custom fullpath() fn to avoid confusion with realpath vs alternative
  Replace heavyweight use of python with a simple 'pwd' call
  Make test-restrospective.sh test script compatible with OSX
More sophisticated use of cat-file bulk revision processing in two stages

This change takes better advantage of the relative strengths of
`cat-file --batch-check` and `cat-file --batch` and combines them.

* Uses `cat-file --batch-check` to filter the set of all git objects in
  bulk, leaving only those that are candidate git-fat object references,
  based on the object being of type "blob" and of magic size(s)
* Uses `cat-file --batch` to read the full contents of all the candidate
  objects in bulk, for fast processing of their data to find the actual
  git-fat references.
Avoid potential infinite loop if unexpected EOF received from cat-file

Use read() method more defensively to avoid any chance of an infinite
loop in the (very unlikely) event an EOF is received mid-way through
some `cat-file` data.
Merge branch 'upstream' into improve_referenced_objects_performance
referenced_objects: make comment more precise