Jeff King <peff@xxxxxxxx> writes: > Others have mentioned ways to dump data from clone. But you can more or > less see what's going on with "git ls-remote <remote>". The sha1 for > "HEAD" will try to match with the sha1 for some other ref. If it > doesn't, then we give up. One thing noticed by somebody at $work is that we perform poorly when fetching from or pushing to a remote, which has an alternate, and when that alternate has a dangling HEAD that does not point at a valid commit. I don't recall the exact details, but the story goes like... The remote in the middle would want to mark the objects that are available from the alternate by internally running ls-remote against its alternate, which returns with a failure status, and then the entire serving process is aborted, and the original client does not get what it wanted from the remote. ... or something like that. As the internal discovery of what additional objects are available to the remote from its alternate is primarily for improving network performance by avoiding to transfer unnecessary objects, it is tempting to argue that the remote could ignore the failure in ls-remote against the alternate. The remote however _is_ relying on the alternate for some (and possibly large part of) objects it _thinks_ it has via its own refs, and an alternate that fails ls-remote because it has its refs messed up is a bad sign that does not give us confidence that the remote itself is healthy, so from that point of view, we might be doing the right thing by refusing to serve the original requestor to prevent the damage from spreading. -- 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