On 02/17/2015 05:55 PM, Jeff King wrote: > On Tue, Feb 17, 2015 at 05:39:27PM +0100, Michael Haggerty wrote: > >>> 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. Yes, this makes sense too. But my point was that sticking symlinks to random files in your refs hierarchy is pretty questionable even *before* the symlink gets broken. If we would warn the user as soon as we saw such a thing, then the user's problem would never have advanced as far as it did. Do you think that emitting warnings on *intact* symlinks is too draconian? > [...] Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx -- 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