On Sun, 2014-08-31 at 20:54 +0200, Øyvind A. Holm wrote: > 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. We could have one exit code for errors which can be fixed without rewriting history, and another for errors that can't. Or different command-line arguments to suppress errors of this sort. In my case, I actually could fix the issue, because it was in a newly-created branch; I just rewrote the script that created the branch to be a little smarter. -- 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