> I do agree with you that "git show -s", without any other options like --diff- > filter that affects the commit selection [*], should not have to look into its tree. > Unlike "git log -p", it should not have to see the tree of the commit is the same > or different from the tree of the parent commit in order to decide if the > commit should be shown. And indeed, as noted, "git log" *without* "-p" functions fine, whereas "git show -s" reads the tree object in regardless. I suppose maybe that has something to do with their respective "default states". I believe my current workaround will involve using "git log" (or just downloading the trees and not the blobs with "blob:none" instead). > The fact that it gave an error "attempting to read the tree" is your own making > by corrupting your repository ;-), but it is done as an easy way to demonstrate > the underlying issue, which is that it is suboptimal for it to try to access the > tree of the commit in a case where it should not have to. Thanks. I could have indeed kept the promisor and positioned it as "git fetches objects it doesn't really need to fetch", but I thought displaying an error was clearer. Thanks for seeing through it to the core issue. Indeed, what I'm really wanting to do is optimize what is retrieved as much as possible, so that I can operate at scale with minimal overhead (both locally in execution time, and load generated on our internal server). This is really just part of the path getting there, and it seemed worth reporting for consideration. I'll push past it and lurk in the background in case you decide to implement any changes. :-) [ Apologies for any rough issues in email formatting -- I'm utilizing Outlook from a corporate setting that isn't regularly configured for mailing lists, and doing the best with what I have right now ] -- Bob Internal Use - Confidential
