Re: git fsck exit code?

[Jeff King <peff@peff.net>]

On Mon, Sep 01, 2014 at 02:17:43PM -0400, David Turner wrote:

> > 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.

I think there's obviously some disagreement or room for interpretation
on the exit code. Perhaps a better path forward is to have a
machine-readable output from fsck in the first place, and then we can
annotate each warning/error with extra information that a caller can
use.

As it is now, you have to scrape fsck's stderr stream to figure out what
happened (which is a thing I have done, and it felt dirty and wrong).

-Peff