Re: Git gc removes all packs

From: Jeff King <peff@peff.net>
Date: Feb 17, 2015, 16:55 UTC
Message-ID: <20150217165514.GA12176@peff.net>
In-Reply-To: <54E36EBF.2070600@alum.mit.edu>

On Tue, Feb 17, 2015 at 05:39:27PM +0100, Michael Haggerty wrote:

Show 13 quoted lines

> > You can't symlink refs like this. The loose refs in the filesystem may
> > be migrated into the "packed-refs" file, at which point your symlink
> > will be broken. That is a likely reason why git would not find any refs.
> > 
> > So your setup will not ever work reliably.  But IMHO, it is a bug that
> > git does not notice the broken symlink and abort an operation which is
> > computing reachability in order to drop objects. As you noticed, it
> > means a misconfiguration or filesystem error results in data loss.
> 
> There's a bunch of code in refs.c that is there explicitly for reading
> loose references that are symlinks. If the link contents literally start
> with "refs/", then they are read and treated as a symbolic ref.
> Otherwise, the symlink is just followed.

Right, but we should be able to notice that:

  1. We found a symlink.

  2. We couldn't read it its ref value (because it's a broken link).

I think we _do_ notice that at the lowest level, and set REF_ISBROKEN. But the problem is that the reachability code in prune and in pack-objects (triggered by "repack -ad") uses for_each_ref, and not for_each_rawref. So they ignore "broken" refs rather than complaining, even though failing to read a ref may mean we could drop objects which were only mentioned by that ref.

Show 5 quoted lines

> It is still possible to write symbolic refs that are represented as
> symlinks (see core.preferSymlinkRefs), but that backwards-compatibility
> code was added in 2006(!) Maybe it's time to deprecate it. And maybe we
> should start working towards a future where any symlinks under "refs"
> cause git to complain.

I wouldn't mind seeing all of the symlink code go away, but I think it is orthogonal to the problem I mentioned.

-Peff