Hmmph.  Almost makes sense.

Commits that pass this test are the branch heads the client wants, and which are at depth 0.  I'm a little concerned there may be a corner case here though.  What happens if the client only wants a new branch and that new branch is pointing at a commit that has UNSHALLOW set?  We'll wind up up with an  empty pending queue and process nothing at all.  Which means the client WON'T get the commit it asked us for, and it'll crash out, because it doesn't have that yet (that's why it asked to unshallow it).

We may just have to make this test:

  if ((c.flags & RevWalk.UNINTERESTING) == 0)

to work around that corner condition.  However we would then be pushing in UNSHALLOW commits that aren't actually start points.  This is a bug in DepthWalk.ObjectWalk's markUnshallow method.  It shouldn't call markStart().

However we do also need uninteresting commits to be iterated.  The client may have given us a commit in common that we both have and that wasn't wanted by the client (because he already has it).

And, uh, this is all far harder than I thought.  I might try poking at it more tomorrow to see if I can better distill down the conditions involved and how we can express them internally.