Why don’t git tree objects encode SHA-1 hashes the same way as commits and tags?

Question

Given a simple repository

$ touch empty ; git add empty ; git commit -m 'My commit'
[master (root-commit) e9cc922] My commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 empty

$ git tag -a -m 'My tag' mytag

we notice that one of these things is not like the others, emphasis added below. Why do tree objects encode SHA-1 hashes directly as sequences of twenty unsigned bytes whereas commits and tags encode them as forty ASCII hex digits?

I noticed the discrepancy while investigating the answer to a related question about git internal storage.

$ for f in .git/objects/??/* ; do echo $f ; openssl zlib -d < "$f" | xxd ; echo ; done
.git/objects/41/7c01c8795a35b8e835113a85a5c0c1c77f67fb
00000000: 7472 6565 2033 3300 3130 3036 3434 2065  tree 33.100644 e
00000010: 6d70 7479 00e6 9de2 9bb2 d1d6 434b 8b29  mpty........CK.)
00000020: ae77 5ad8 c2e4 8c53 91                   .wZ....S.

.git/objects/da/867754dac38858c708292f49de41b7eff6f5d7
00000000: 7461 6720 3133 3400 6f62 6a65 6374 2065  tag 134.object e
00000010: 3963 6339 3232 3632 6561 3734 3138 3864  9cc92262ea74188d
00000020: 6530 3436 6563 6166 3265 3363 3063 3061  e046ecaf2e3c0c0a
00000030: 3436 3966 3734 320a 7479 7065 2063 6f6d  469f742.type com
00000040: 6d69 740a 7461 6720 6d79 7461 670a 7461  mit.tag mytag.ta
00000050: 6767 6572 2047 7265 6720 4261 636f 6e20  gger Greg Bacon
00000060: 3c67 6261 636f 6e40 666f 6f2e 696e 7661  <[email protected]
00000070: 6c69 643e 2031 3435 3737 3035 3338 3820  lid> 1457705388
00000080: 2d30 3630 300a 0a4d 7920 7461 670a       -0600..My tag.

.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
00000000: 626c 6f62 2030 00                        blob 0.

.git/objects/e9/cc92262ea74188de046ecaf2e3c0c0a469f742
00000000: 636f 6d6d 6974 2031 3732 0074 7265 6520  commit 172.tree
00000010: 3431 3763 3031 6338 3739 3561 3335 6238  417c01c8795a35b8
00000020: 6538 3335 3131 3361 3835 6135 6330 6331  e835113a85a5c0c1
00000030: 6337 3766 3637 6662 0a61 7574 686f 7220  c77f67fb.author
00000040: 4772 6567 2042 6163 6f6e 203c 6762 6163  Greg Bacon <gbac
00000050: 6f6e 4066 6f6f 2e69 6e76 616c 6964 3e20  [email protected]>
00000060: 3134 3537 3730 3531 3736 202d 3036 3030  1457705176 -0600
00000070: 0a63 6f6d 6d69 7474 6572 2047 7265 6720  .committer Greg
00000080: 4261 636f 6e20 3c67 6261 636f 6e40 666f  Bacon <gbacon@fo
00000090: 6f2e 696e 7661 6c69 643e 2031 3435 3737  o.invalid> 14577
000000a0: 3035 3137 3620 2d30 3630 300a 0a4d 7920  05176 -0600..My
000000b0: 636f 6d6d 6974 0a                        commit.

Answer 1

In the comment to your question Philip Oakley mentioned finding something in the git mailing list but unfortunately did not further elaborate.

All I found skimming the mailing list is these two threads where Jakub Narębski also asks (2011)

What was Linus thinking?!?

and tells (2013) he

[...] always wondered why this is the sole object format where SHA-1 is in 20- byte binary format and not 40-chars hexadecimal string format

but doesn't get any reaction/response.

I'd also love to know if there's any other post on the mailing list and if there actually is a sort of explanation or if Philip Oakley also only had one of those threads (or another one without explanation) in mind.

As the first thread I mentioned (from 2011) actually originally was about "git cat-file -p inconsistency" and Philip Oakley also mentioned the thread he saw being "related to the git cat-* commands" I guess that probably was the one he remembered. :/

(That doesn't really answer the question but at least shows that this inconsistency even leaves git core devs puzzled. As I'm a new user I can't post it as a comment)