Re: git fsck exit code?

["Øyvind A. Holm" <sunny@sunbase.org>]

On 29 August 2014 22:18, David Turner <dturner@twopensource.com> wrote:
> On Fri, 2014-08-29 at 12:21 -0700, Junio C Hamano wrote:
> > Jeff King <peff@peff.net> 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