Re: [PATCH 2/2] fsck: report errors if reflog entries point at invalid objects

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 8, 2015, 16:00 UTC
Message-ID: <c5720357601be135485ef546cae7ffdb@www.dscho.org>
In-Reply-To: <5575B03C.6040008@alum.mit.edu>

Hi Michael,

On 2015-06-08 17:09, Michael Haggerty wrote:

Show 12 quoted lines

> On 06/08/2015 04:27 PM, Johannes Schindelin wrote:
>> On 2015-06-08 08:40, Michael Haggerty wrote:
>>> Previously, if a reflog entry's old or new SHA-1 was not resolvable
>>> to an object, that SHA-1 was silently ignored. Instead, report such
>>> cases as errors.
>>
>> I like the idea, but I am a bit uncertain whether it would constitute
>> "too backwards-incompatible" a change to make this an error. I think
>> it could be argued both ways: it *is* an improvement, but it could
>> also possibly disrupt scripts that work pretty nicely at the moment.
> 
> What kind of script are you worried about?

I was concerned about scripts that work on repositories whose reflogs become inconsistent for whatever reason (that happened a lot to me in the past, IIRC it had something to do with bare repositories and/or shared object databases).

Now, if I was to run a script in, say, cron to verify that all of my repositories (possibly on a network drive, for shared team use), I could imagine that I actually want to error out if the reflogs become inconsistent. But then, I could also imagine that I care more about the script being quiet when everything is okay except for the reflogs.

> * This change only causes fsck to output an extra line (and exit with
>   a a non-zero retcode).

It is that non-zero exit status that would make my hypothetical cron script start to fail.

Show 5 quoted lines

> * Repair is only a
> 
>       git reflog expire --expire-unreachable=now --all
> 
>   away, I think.

True.

Plus, as I mentioned, it could be considered a bug fix that fsck now reports this problem.

The more I think about it, the more I think it is actually a bug fix.

Thanks, Dscho