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
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?
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.
