Kevin Bracey <kevin@xxxxxxxxx> writes: > On 25/04/2013 19:51, Junio C Hamano wrote: >> Kevin Bracey <kevin@xxxxxxxxx> writes: >> >>> Thanks for the test addition. Maybe we will be able to satisfy your >>> greed in this series. There could be more worth doing here, and I >>> think getting TREESAME precise is key. >> It is perfectly fine to do things one step at a time. Let's get >> the --full-history change into a good shape first and worry about >> the more complex case after we are done. > > So do you see the rerun of try_to_simplify_commit() as acceptable? I'm > really not happy with it - it was fine for an initial > proof-of-concept, but it's an obvious waste of CPU cycles to recompute > something we already figured out, and I'm uncomfortable with the fact > that the function potentially does more than just compute TREESAME; by > inspection it seems safe given the known context inside > simplify_merges(), but it feels like something waiting to trip us > up. True. > The latter could be dealt with by breaking > try_to_simplify_commit() up, but that feels like a diversion. I'd > rather just get on and make this first patch store and use the > per-parent-treesame flags if feasible. OK. We have survived with this corner case glitch for more than 6 years, so a fix is not ultra-urgent. Let's try to see if we can get it right. How many decorations are we talking about here? One for each merge commit in the entire history? Do we have a cue that can tell us when we are really done with a commit that lets us discard the associated data as we go on digging, keeping the size of our working set somewhat bounded, perhaps proportional to the number of commits in our rev_info->commits queue? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html