On 02/05/2015 09:03 PM, Jeff King wrote: > On Thu, Feb 05, 2015 at 04:13:03PM +0100, Dmitry Neverov wrote: >> [...] >> One more thing about my setup: since git p4 promotes a use of a linear >> history I use a separate repository for another branch in perforce. In >> order to be able to cherry-pick between repositories I added this >> another repo objects dir as an alternate and also added a ref which is a >> symbolic link to a branch in another repo (so I don't have to do any >> fetches). > > 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. 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. 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