{"thread":{"id":"63505","subject":"Bug Report: git show unnecessarily requires parent tree","startedAt":"2025-05-23T10:15:52Z","lastAt":"2025-05-23T21:56:11Z","messageCount":3,"participants":["Bell, Bob (ISG)","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"518759","messageId":"IA1PR19MB88859FF5C7E547010E555E7F8198A@IA1PR19MB8885.namprd19.prod.outlook.com","threadId":"63505","inReplyTo":null,"subject":"Bug Report: git show unnecessarily requires parent tree","fromName":"Bell, Bob (ISG)","fromEmail":"robert.bell@dell.com","sentAt":"2025-05-23T06:15:04Z","receivedAt":"2025-05-23T10:15:52Z","isPatch":false,"sender":{"key":"robert.bell@dell.com","avatar":null},"body":"What did you do before the bug happened? (Steps to reproduce your issue)\nTree-less git partial clone: git clone --filter=tree:0 https://...\nRemove the promisor to prevent retrieving more objects: git config --local --unset remote.origin.promisor\nGit show of a fetched commit with limited metadata fields requested: git show --no-patch --format=%ae abc123\n\nWhat did you expect to happen? (Expected behavior)\nI expect to get the metadata I requested from the commit, since it is available in the retrieved commit object\n\nWhat happened instead? (Actual behavior)\nI get an error attempting to read the tree for the parent of the commit specified:\nfatal: unable to read tree (abcdef1234567890)\n\nWhat's different between what you expected and what actually happened?\nI expected the command to output the requested metadata, since there is no need to read the parent commit, much less the parent's tree object, in order to provide the required data.\n\nAnything else you want to add:\nNote that the data is fully accessible without error using git cat-file or git log\ne.g., git log -n 1 --format=%ae abc123\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.47.2\ncpu: x86_64\nno commit associated with this build\n\n--\nBob Bell\nDistinguished Member of Technical Staff\nDell | ISG TechOps\nRobert.Bell@Dell.com\n\n\nInternal Use - Confidential\n"},{"id":"518781","messageId":"xmqqldqnxn3w.fsf@gitster.g","threadId":"63505","inReplyTo":"IA1PR19MB88859FF5C7E547010E555E7F8198A@IA1PR19MB8885.namprd19.prod.outlook.com","subject":"Re: Bug Report: git show unnecessarily requires parent tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-23T17:17:55Z","receivedAt":"2025-05-23T17:17:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Bell, Bob (ISG)\" <Robert.Bell@dell.com> writes:\n\n> What did you do before the bug happened? (Steps to reproduce your issue)\n> Tree-less git partial clone: git clone --filter=tree:0 https://...\n> Remove the promisor to prevent retrieving more objects: git config --local --unset remote.origin.promisor\n\nAt this point, your repository is officially corrupt, but it is a\nvery effective way to demonstrate the underlying issue that exists\neven if your repository weren't corrupt.\n\nI do agree with you that \"git show -s\", without any other options\nlike --diff-filter that affects the commit selection [*], should not\nhave to look into its tree.  Unlike \"git log -p\", it should not have\nto see the tree of the commit is the same or different from the tree\nof the parent commit in order to decide if the commit should be\nshown.\n\nThe fact that it gave an error \"attempting to read the tree\" is your\nown making by corrupting your repository ;-), but it is done as an\neasy way to demonstrate the underlying issue, which is that it is\nsuboptimal for it to try to access the tree of the commit in a case\nwhere it should not have to.\n\nIs this essentially the same issue as these?\n\nhttps://lore.kernel.org/git/YqEyh5opAaJxph2+@coredump.intra.peff.net/\nhttps://lore.kernel.org/git/20250504082715.GA6257@coredump.intra.peff.net/\n\n\n[Footnote]\n\n * \"git show -s --diff-filter=D\" on a commit that does not delete\n   any paths is silent.  \"-s\" merely says \"do not show the output\n   from the diff machinery\".  The same for pathspec, to wit:\n\n   $ git commit --allow-empty -m empty\n   $ git show -s .\n\n   It asks \"if there are any changes to paths that match the\n   pathspec, show the commit but do not show the diff output\".\n\n"},{"id":"518810","messageId":"IA1PR19MB8885A50B6FBCDB442E6BFD338198A@IA1PR19MB8885.namprd19.prod.outlook.com","threadId":"63505","inReplyTo":"xmqqldqnxn3w.fsf@gitster.g","subject":"RE: Bug Report: git show unnecessarily requires parent tree","fromName":"Bell, Bob (ISG)","fromEmail":"robert.bell@dell.com","sentAt":"2025-05-23T19:36:34Z","receivedAt":"2025-05-23T21:56:11Z","isPatch":false,"sender":{"key":"robert.bell@dell.com","avatar":null},"body":"> I do agree with you that \"git show -s\", without any other options like --diff-\n> filter that affects the commit selection [*], should not have to look into its tree.\n> Unlike \"git log -p\", it should not have to see the tree of the commit is the same\n> or different from the tree of the parent commit in order to decide if the\n> commit should be shown.\n\nAnd indeed, as noted, \"git log\" *without* \"-p\" functions fine, whereas \"git\nshow -s\" reads the tree object in regardless.  I suppose maybe that has\nsomething to do with their respective \"default states\".  I believe my current\nworkaround will involve using \"git log\" (or just downloading the trees and not\nthe blobs with \"blob:none\" instead).\n\n> The fact that it gave an error \"attempting to read the tree\" is your own making\n> by corrupting your repository ;-), but it is done as an easy way to demonstrate\n> the underlying issue, which is that it is suboptimal for it to try to access the\n> tree of the commit in a case where it should not have to.\n\nThanks.  I could have indeed kept the promisor and positioned it as \"git\nfetches objects it doesn't really need to fetch\", but I thought displaying an\nerror was clearer.  Thanks for seeing through it to the core issue.  Indeed,\nwhat I'm really wanting to do is optimize what is retrieved as much as\npossible, so that I can operate at scale with minimal overhead (both locally in\nexecution time, and load generated on our internal server).  This is really\njust part of the path getting there, and it seemed worth reporting for\nconsideration.  I'll push past it and lurk in the background in case you decide\nto implement any changes. :-)\n\n[ Apologies for any rough issues in email formatting -- I'm utilizing Outlook\nfrom a corporate setting that isn't regularly configured for mailing lists, and\ndoing the best with what I have right now ]\n\n-- Bob\n\nInternal Use - Confidential\n"}]}