On Jan 11, 2008 7:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
quoted text
> In this case, a failure while closing that small .keep file is
> highly unlikely, and if we ever mange to trigger such a highly
> unlikely failure, I think we would rather want to *know* about
> it, as it is likely there is something more seriously wrong
> going on.

On a slightly related note: I've got a patch that handles the issue
that I reported a couple of months back that tmp pack/index objects
where a write fails partway through are not deleted by any git
processing, ie, when for example during git gc --prune we get

fatal: sha1 file '/media/usbdiskc/v.git/objects/tmp_pack_QCYYAi' write
error (No space left on device)
error: failed to run repack

but the tmp_pack_* isn't deleted. I put my patch on the back burner
when Junio declared a moratorium on new behaviours until after 1.5.4
gets released, but will post once things open up again.

As it relates to this discussion: one of the awkward things is that
the die stuff doesn't leave any programatic indication (ie, not just a
message to stderr) that a file is malformed due to a writing failure.
Per Nicolas Pitre's suggestion to delete failed tmp_ files during a
"git gc --prune", I just delete ALL tmp_ files at that time. This
approach seems a bit risky -- can something like a git-svn fetch which
generated tmp_ files by a different route be going on at the same time
as a git gc? -- but I couldn't think of another way to do it.

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html