Re: git fsck exit code?

[David Turner <dturner@twopensource.com>]

On Sun, 2014-08-31 at 20:54 +0200, Øyvind A. Holm wrote:
> 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.

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.