Jeff King <peff@xxxxxxxx> writes: > There may be also cases where the two diverge. Obviously having two > parsers isn't ideal. I think sharing the code may involve a lot of work, > though. The pretty-print parser is interested in pulling out more > information, and is less focused on performance. Parsing commits is > traditionally a hot path, as we historically had to parse every commit, > even if we weren't showing it (including non-log operations like > computing merge bases, reachability, and so forth). > > But that may not matter so much. One, we already inflate the whole > commit object, not just the header. So even if we spend a few extra > instructions on parsing, it may not be noticeable. And two, these days > we often cache commit metadata in the commit-graph files, which avoids > loading the commit message entirely (and thus this parsing) for most > operations. Makes readers wonder which parser is used to parse commit objects in order to populate the commit-graph files. If that step screws up, we'd record a broken timestamp there X-<.
