On 2020-01-28 at 19:06:01, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > In the setup steps for the promisor remote tests, we clone a repository
> > and filter out all trees with depth greater than or equal to zero, which
> > also filters out all blobs.
> >
> > With SHA-1, this test passes because the object we happen to request
> > from the server is the blob that the promisor remote has.  However, due
> > to a different ordering with SHA-256, we request the tree containing
> > that blob, which the promisor remote does not have.  As a consequence,
> > we fail with a "not our ref" error.
> 
> Sorry, but I do not understand this part.
> 
> The object name of the original blob (which is the only thing
> "promisor-remote" is given) may sort earlier or later than other
> objects that are missing in the "client" repository, but it is not
> clear how it makes difference in the final outcome---even if the
> blob is asked first (in the SHA-1 version), wouldn't we need to
> fetch the tree after that, and wouldn't that fail?  If the SHA-256
> version that happens to ask for the tree first and fails, wouldn't
> that mean we need to fetch both anyway?
> 
> Is it that the current test with SHA-1 is broken in that it lets the
> lazy fetch fail (due to missing tree) but because the failure happens
> after the blob gets feteched, and it ignores the failure of the lazy
> fetch, and only checks if the blob got fetched, it happens to "pass"?

I think Jonathan Tan figured out that my analysis was wrong, and that
the issue is that the larger object ID length causes deltification to
happen.  The test assumes that the tree is sent as a non-delta object,
and when it's sent as a deltaed object instead, we fail.  He explains
this quite well in <20200113202823.228062-1-jonathantanmy@google.com>,
which you seem to have picked up.

Since my analysis was wrong here and he's provided a patch which fixes
the issue in a much more robust way, I'm dropping this patch in v3.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204