All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: ZheNing Hu <adlternative@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [QUESTION] how to diff one blob with nothing
Date: Wed, 19 Jul 2023 09:15:03 -0700	[thread overview]
Message-ID: <xmqqo7k7c1yw.fsf@gitster.g> (raw)
In-Reply-To: <CAOLTT8TVGna+C9nYy9nj3h5bT7AdAT0SKtUM3YVz6h=KZhGHHg@mail.gmail.com> (ZheNing Hu's message of "Wed, 19 Jul 2023 17:59:15 +0800")

ZheNing Hu <adlternative@gmail.com> 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.




  reply	other threads:[~2023-07-19 16:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19  9:59 [QUESTION] how to diff one blob with nothing ZheNing Hu
2023-07-19 16:15 ` Junio C Hamano [this message]
2023-07-26 18:00   ` ZheNing Hu
2023-07-26 18:23     ` Junio C Hamano
2023-07-27 17:46       ` Taylor Blau
2023-07-28  3:40         ` ZheNing Hu
2023-08-03  5:16           ` ZheNing Hu
2023-08-03 15:24             ` Taylor Blau
2023-08-04  2:28               ` ZheNing Hu
2023-08-04  8:28                 ` Christian Couder
2023-08-04 18:34                   ` Taylor Blau
2023-08-04 19:00                     ` Junio C Hamano
2023-08-05  8:27                       ` ZheNing Hu
2023-07-27 17:13     ` Konstantin Khomoutov
2023-07-28  3:35       ` ZheNing Hu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqo7k7c1yw.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=adlternative@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.