Re: [PATCH] fsck: return non-zero status on missing ref tips

[Michael Haggerty <mhagger@alum.mit.edu>]

On 09/12/2014 06:58 AM, Junio C Hamano wrote:
> On Thu, Sep 11, 2014 at 9:29 PM, Jeff King <peff@peff.net> wrote:
>> [+cc mhagger for packed-refs wisdom]
>>
>> If we only have a packed copy of "refs/heads/master" and it is broken,
>> then deleting any _other_ unrelated ref will cause refs/heads/master to
>> be dropped from the packed-refs file entirely. We get an error message,
>> but that's easy to miss, and the pointer to master's sha1 is lost
>> forever.
> 
> Hmph, and the significance of losing a random 20-byte object name that
> is useless in your repository is? You could of course ask around other
> repositories (i.e. your origin, others that fork from the same origin,
> etc.), and having the name might make it easier to locate the exact
> object.
> 
> But in such a case, either they have it at the tip (in which case you
> can just fetch the branch you lost), or they have it reachable from
> one of their tips of branches you had shown interest in (that is why
> you had that lost object in the first place). Either way, you would be
> running "git fetch" or asking them to send "git bundle" output to be
> unbundled at your end, and the way you ask would be by refname, not
> the object name, so I am not sure if the loss is that grave.
> 
> Perhaps I am missing something, of course, though.

I don't understand your argument.

First, you would not just lose the SHA-1 of the object. You would also
lose the name of the reference that was previously pointing at it.

Second, the discarded information *is* useful. The more information you
have, the more likely you can restore it and/or diagnose the original
cause of the corruption.

Third, even if the discarded information were not useful, the fact that
*information has gone missing* is of overwhelming importance, and that
fact would be forgotten as soon as the warning message scrolls off of
your terminal. The reference deletion that triggered the warning might
even have been done in the background by some other process (e.g., a
GUI) and the output discarded or shunted into some "debug" window that
the user would have no reason to look at.

So I agree with Peff that it would be prudent to preserve the corrupt
reference at least until the next "git fsck", which (a) is run by the
user specifically to look for corruption, and (b) can return an error
result to make the failure obvious.

The only thing that is unclear to me is whether the user would be able
to get rid of the broken reference once it is discovered (short of
opening packed-refs in an editor).

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu