Re: [PATCH] Teach "git add" and friends to be paranoid

[Zygo Blaxell <zblaxell@gibbs.hungrycats.org>]

On Wed, Feb 17, 2010 at 05:20:00PM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> With a small fix to the test program earlier in the thread, this seems to
> protect the repository; I didn't bother to assess the performance impact
> of the patch, though.
> 
> Here is the corrected test.

Depends on what you mean by "corrected" I suppose.

> # Thread 2:  loop until the repo is corrupted
> while git fsck; do
> 	# Note the implied 'git add' in 'commit -a'
> 	# It will do the same with explicit 'git add'
> 	git commit -a -m'Test' || break

This is at least partly wrong--it will terminate prematurely if Thread
1 gets stalled and fails to modify 'foo' during the loop (git commit
normally refuses to commit a tree with no changes).  This can cause
the test for the corruption bug to return false success results.

If you add '--allow-empty' to the git commit command you will fix that
case, but there might be others.  

If git commit runs out of disk space, for example, the commit should
fail, but the repository should still not be corrupt.  Future commits
(for example after freeing some disk space) should eventually succeed.
Really, the original loop was correct, and this new one isn't.

> else
> 	echo Repository is still healthy.  You are stupid.

If git is working, you should never reach this line, because git
fsck should not fail after executing any sequence of git porcelain
operations--and this particular sequence is nothing but 'git commit'
in a single thread.