Re: Is there a debug mode for git-clone https traffic?

Jeff King [off-list ref] 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.