Heiko Voigt <hvoigt@xxxxxxxxxx> writes: >> I have been suspecting that most of this should be done in a separate >> helper program that is run via run_command() interface, without >> contaminating the object pool the main merge process has with data from >> the submodule object store to begin with (i.e. add_submodule_odb() and >> everything below should go). Wouldn't it be a lot cleaner solution? > > Hmm, I would like to keep it in process. Since there are platforms where > spawning new processes is very slow. Adding submodule's odb into the main process _will_ also have performance penalties because it will make it more expensive to look up objects that belong to the superproject when the superproject wants its own look up. In case you haven't realized yet, walking revision graph multiple times while making sure that you do not affect other revision traversals in effect is hard to arrange right. But more importantly, correctness counts more than performing quickly and giving a bogus result with premature optimization that makes it harder to implement things correctly (and harder to verify the change is correct). -- 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