Thomas Guyot <tguyot@xxxxxxxxx> writes: > Hi Junio, > > On 2020-09-24 02:40, Junio C Hamano wrote: >> Thomas Guyot <tguyot@xxxxxxxxx> writes: >> >> It is not "both ways", I think. The idea is that when this variable >> is true, we know with certainty that these two are the same, but >> even when the variable is false, they still can be the same. So >> true does mean there will not be diff. False indeed is fuzzy. > > I meant to say the old behavior "lied" in both directions. It depends on the perspective ;-) The old one didn't expect/realize fill_oid_info() can leave the oid field to "unknown". It was OK because is_stdin happens to be the only such case [*1*] and we never saw both one->oid and two->oid being the null_oid at the same time, so it wasn't an issue that their validity weren't checked there. As long as one side was valid, when the comparison said they were equal, they indeed were equal. So in that sense, the true side did not lie. If you add new case where the oid of both sides can legitimately be null_oid, that will of course break the code. I think that is the reason why we are having this discussion to prepare for such a future (that happens in 2/2???). [Footnote] *1* The missing side of addition and deletion will also get null_oid, but we don't compare that with stdin in such a case.
