Junio C Hamano <gitster@xxxxxxxxx> 于2023年7月20日周四 00:15写道： > > ZheNing Hu <adlternative@xxxxxxxxx> writes: > > > I want to diff two blobs right now, and one of them > > may be empty, so I tried using > > 0000000000000000000000000000000000000000 or > > e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 (empty blobID) > > to test its effect, and the result I found was: > > > > git diff 00750edc07d6415dcc07ae0351e9397b0222b7ba > > 0000000000000000000000000000000000000000 > > fatal: bad object 0000000000000000000000000000000000000000 > > As the object name for an empty blob is not all-0, this is expected. > > > git diff 00750edc07d6415dcc07ae0351e9397b0222b7ba > > e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 > > fatal: bad object e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 > > > > Since the "empty object" has not been created, the > > git diff operation fails. > > If you haven't created one, of course it would fail. It should help > to do > > $ git hash-object -w --stdin </dev/null > > before running > > $ git diff 00750edc e69de29bb > This is a viable solution, but it's a bit ugly since a read-only "diff" requires ”write“ an empty blob. > Long time ago, with 346245a1 (hard-code the empty tree object, > 2008-02-13) we taught git what an empty-tree looks like, but it > seems that we never did the same for an empty blob, perhaps? > It would be great to have that capability. > Interesting. I am not sure if it is a good idea to teach empty_blob > to find_cached_object() and leaning negative but I haven't thought > things through on this. > I currently don't have time to delve into implementation details, so I went with the approach that requires writing an empty blob, but I'll take a closer look at it later. > > Thanks, ZheNing Hu
