Dmitry Ivankov wrote: > The next step would be to replace sha1 with struct object_entry* in fast-import. > So it'll be in struct tree_entry (twice, for each of versions[2]), > branch, tag, hash_list (used to store merge from lists), last_object. > Then some fields will be deleted as they can be accessed from > object_entry: > last_object->depth > last_object->offset > tree_content->delta_depth > branch,tag->pack_id > > And it all even slightly decreased memory consumption (checked some > time ago, but think it's still true). Yes, that sounds interesting, so: [...] > In short, if there is nothing bad with this patchset, it'll be > absolutely natural one after switch to oe instead of sha1, but it's > put before to split the big series. And of course this part may have a > small speedup of it's own. If it's not too good to be accepted on it's > own, I'll just include it into future series depending on it. It would be indeed be more natural to review a single series that combines this preparation with the change it prepares for. (And the change descriptions should explain on their own why they are individually justified or what project they are contributing towards.) My question was actually about this last point you made in the second-to-last sentence: have you measured the speedup produced by the patches you already sent? I didn't think carefully about it, but my first thought was that it might slow things down as the internal hash tables (which still seem to be fixed-size in mainline git) start to fill up. -- 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