Hi Michael, On 2015-06-08 17:09, Michael Haggerty wrote: > 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. > * 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 -- 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