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

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Sep 15, 2014, 14:42 UTC
Message-ID: <5416FAD2.5020002@alum.mit.edu>
In-Reply-To: <CAPc5daXMMpqtH=DwLLXgHXVfHThN5MfHwn6dPK6OaZvAQGXT_Q@mail.gmail.com>

On 09/12/2014 06:58 AM, Junio C Hamano wrote:

Show 24 quoted lines

> 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