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