On Wed, Feb 17, 2010 at 05:20:00PM -0800, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html