On Wed, Jan 25, 2017 at 02:35:41PM -0500, Jeff King wrote: > On Wed, Jan 25, 2017 at 02:27:40PM -0500, Jeff King wrote: > > > > > 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. > > Hrm. So I thought it might be useful to write a patch that just tweaks > save_commit_buffer at the start of fetch_pack(). But looking it over, > we call everything_local() _before_ we walk over all the refs. So > save_commit_buffer should already be turned off for my case. > > I wonder if I made a mistake while measuring the peak RSS. Or if clone > parses some commits before it calls into fetch_pack() (but which > objects? It doesn't have any until it does the fetch). > > Perhaps we should just drop this patch (though I think it is logically > consistent and wouldn't hurt anything). OK, I just repeated my heap measurements with valgrind's massif tool, specifically checking builds of this patch and its parent. I couldn't find any improvement. So I must have screwed something up in my earlier measurements. Sorry for the noise. I think we should probably just drop this patch. -Peff