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

Hi Michael,

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

On 06/08/2015 04:27 PM, Johannes Schindelin wrote:

quoted

On 2015-06-08 08:40, Michael Haggerty wrote:

quoted

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.

* 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