On Mon, Jan 11, 2016 at 01:22:07PM -0800, Junio C Hamano wrote: > - git fsck, when writing lost&found blobs (they are written in the > file under its object name, so an existing file with tighter > permission that you cannot write into is OK, because what you are > failing to write is the same contents that the file already has > anyway). I'm not sure I buy this argument. Yes, you should not be writing anything else, but that does not change the fact that "fsck" will unceremoniously abort: $ git init $ echo foo | git hash-object -w --stdin $ git fsck --lost-found notice: HEAD points to an unborn branch (master) Checking object directories: 100% (256/256), done. notice: No default references dangling blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 $ chmod -w .git/lost-found/other/257cc5642cb1a054f08cc83f2d943e56fd3ebe99 $ $ git fsck --lost-found notice: HEAD points to an unborn branch (master) Checking object directories: 100% (256/256), done. notice: No default references dangling blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 fatal: Could not open '.git/lost-found/other/257cc5642cb1a054f08cc83f2d943e56fd3ebe99': Permission denied So I think this would be a reasonable candidate (or alternatively, to treat EPERM on an existing file as a soft error). I am totally fine not to address it as part of this series, though. -Peff -- 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