On Wed, Jan 25, 2017 at 11:11:01AM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > Normally git caches the raw commit object contents in > > "struct commit". This makes it fast to run parse_commit() > > followed by a pretty-print operation. > > > > For commands which don't actually pretty-print the commits, > > the caching is wasteful (and may use quite a lot of memory > > if git accesses a large number of commits). > > > > For fetching operations like clone, we already disable > > s/clone/fetch/ you meant? Well, no, because this patch deals with clone. It's likely that builtin/fetch.c would want the same treatment. It didn't come up for me because I've disabled the alternates check for that case (but you can't do that with stock git), and I didn't dig further. Possibly this should just go into fetch-pack.c, right before we walk over all of the refs and call parse_object() and deref_tag() on all of them. It feels a little funny to tweak the global save_commit_buffer flag there, but it already do so in everything_local(), so I don't think we're really losing much. > > In one real-world case with a large number of tags, this > > cut about 10MB off of clone's heap usage. Not spectacular, > > but there's really no downside. > > "There is no downside" is especially true in the modern world post > v2.1, where get_commit_buffer() is what everybody has to go through > to access this information. I would have been very hesitant to > accept a patch like this one if we didn't do that clean-up, as a > stray codepath could have just done "commit->buffer" and segfaulted > or said "ah, there is no message", neither of which is satisfactory. Yep, I had a similar thought while writing it. I would have been very hesitant to propose it back then, too. :) -Peff