On 29 August 2014 22:18, David Turner <dturner@xxxxxxxxxxxxxxxx> wrote: > On Fri, 2014-08-29 at 12:21 -0700, Junio C Hamano wrote: > > Jeff King <peff@xxxxxxxx> writes: > > > On Wed, Aug 27, 2014 at 06:10:12PM -0400, David Turner wrote: > > > > It looks like git fsck exits with 0 status even if there are > > > > some errors. The only case where there's a non-zero exit code is > > > > if verify_pack reports errors -- but not e.g. fsck_object_dir. > > > > > > It will also bail non-zero with _certain_ tree errors that cause > > > git to die() rather than fscking more completely. > > > > Even if git does not die, whenever it says broken link, missing > > object, or object corrupt, we set errors_found and that variable > > affects the exit status of fsck. What does "some errors" exactly > > mean in the original report? Dangling objects are *not* errors and > > should not cause fsck to report an error with its exit status. > > error in tree 9f50addba2b4e9e928d9c6a7056bdf71b36fba90: contains > duplicate file entries I don't think git fsck should return !0 in this case. Yes, it's an inconsistency in the repo, but it's sometimes due to erroneous conversions from another SCM or some other (non-standard) implementation of the git client. I've seen things like this (and other inconsistencies in repos, like wrong date formats, non-standard Author fields, unsorted trees, zero-padded file modes and so on), and the thing is, owners of public repos with these errors tend to avoid fixing it because it changes the commit SHAs. If git fsck starts to return !0 on these errors, it will always return error on that repo, which in practise means that the error code is rendered useless. IMHO git fsck should only return !0 on errors that can be fixed without changing the commit history, for example missing or invalid objects. Øyvind -- 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