Re: GSoC - Some questions on the idea of

[Jeff King <peff@peff.net>]

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