Taylor Blau <me@xxxxxxxxxxxx> 于2023年7月28日周五 01:46写道： > > On Wed, Jul 26, 2023 at 11:23:52AM -0700, Junio C Hamano wrote: > > ZheNing Hu <adlternative@xxxxxxxxx> writes: > > > > >> 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. > > > > If you do not even have an empty blob, you have no business > > comparing some other blobs you have with it, do you? > > > > If you do not have a file with a single line "hello, world\n" (that > > hashes to 4b5fa63702dd96796042e92787f464e28f09f17d if written in a > > blob), then you cannot do "git diff 4b5fa637" with anything and > > expect it to work. It is the same thing. > > > > Besides, if you _know_ you want to compare a blob X to emptyness, > > you are better of doing "git cat-file blob X" in the first place. > > Yeah, exactly. In 346245a1bb6 (hard-code the empty tree object, > 2008-02-13), the rationale was partly that having the empty tree object > is useful for showing some diffs, such as for the initial commit. > > But I can't think of a similar argument for the empty blob. Like Junio > said, if you're purposefully diff-ing against the empty blob, wouldn't > you simply want the entire contents anyway? If that's the case, cat-file > seems like a much more appropriate tool. > Here, it is necessary to compare multiple versions of blobs while also considering the situations of creation and deletion. Well, what I need is the "diff" content, with lines in the diff indicating '+' or '-' signs. This can be achieved by manually adding them, but it is not very compatible with the original logic. > Thanks, > Taylor
