Re: git fsck exit code?

From: Øyvind A. Holm <sunny@sunbase.org>
Date: Sep 1, 2014, 11:54 UTC
Message-ID: <CAA787rmiiiWwz-n-PgP46_y6L2nhTZZgBtr2H2ZcCA7VA21KYg@mail.gmail.com>
In-Reply-To: <CAA787rmf7aNJ+ErXk6Lc_hLVDxMV8s2Lx_YmZud83yia4n0VKA@mail.gmail.com>

On 31 August 2014 20:54, Øyvind A. Holm <sunny@sunbase.org> wrote:

Show 16 quoted lines

> On 29 August 2014 22:18, David Turner wrote:
> > 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.

To elaborate on what I wrote: Of course, if the error is grave enough that Git isn't able to work around it and it severely limits the functionality of the repo, action needs to be taken regardless of whether the history has to be changed or not. In that case it's OK to return an error value too.

Øyvind