Re: GSoC - Some questions on the idea of

On Sat, Apr 14, 2012 at 09:33:37PM -0500, Neal Kreitzinger wrote:

We use git to transfer database files from the dev server to
qa-servers.  Sometimes these barf for some reason and I get called to
remediate.  I assumed the user closed their session prematurely
because it was "taking too long".  However, now I'm wondering if the
git-pull --ff-only is dying on its own due to the big-files.  It
could be that on a qa-server that hasn't updated database files in
awhile they are pulling way more than another qa-server that does
their git-pull more requently.  How would I go about troubleshooting
this?  Is there some log files I would look at?  (I'm using git 1.7.1
compiled with git makefile on rhel6.)

No, git doesn't keep logfiles. Errors go to stderr. So look wherever the
stderr for your git sessions is going (if you are doing this via cron
job or something, then that is outside the scope of git).

When I go to remediate do git-reset --hard to clear out the barfed
worktree/index and then run git-pull --ff-only manually and it always
works.  I'm not sure if that proves it wasn't git that barfed the
first time.  Maybe the first time git brought some stuff over and
barfed because it bit off more than it could chew, but the second time
its really having to chew less food because it already chewed some of
it the first time and therefore works the second time.

Try "git pull --no-progress" and see if it still works. If the server
has a very long delta-compression phase, there will be no output
generated for a while, which could cause intermediate servers to hang up
(git won't do this, but if, for example, you are pulling over
git-over-http and there is a reverse proxy in the middle, it may hit a
timeout). If the automated pulls are happening from a cron job, then
they won't have a terminal and progress-reporting will be off by
default.

-Peff