Junio C Hamano <gitster@xxxxxxxxx> writes: > Heiko Voigt <hvoigt@xxxxxxxxxx> writes: > ... >> I will have a look if I can come up with something that reads the >> submodules alternate config and uses it. Do you have other config >> related things in mind that might be missing? > > No, I do not, and that is exactly the point. > > Making the process that works in the top-level superproject to imitate > what would happen if the processing happened inside the submodule is what > invited a bug like this. Who knows what other discrepancies remain there. > > If we forked a separate process,... Having said all that, we seem to have come too far and it is probably too painful to revert the approach to contaminate the obj_hash (in object.c), the set of refs (in refs.c) and the like in the top-level superproject process with data borrowed from submodules repository [*1*]. So not only I do not mind seeing you try solving it inside the superproject process, I would appreciate and encourage the attempt. One thing to be careful about is relative paths stored in the objects/info/alternates; they are relative to the object database of the repository the "alternates" is specified, not relative to the superproject that happens to contain the submodule. Thanks. [Footnote] *1* This is a wrong approach not only because it will invite this kind of bug, but also because it will bloat the process working on the superproject. When taken alone, either of the superproject or the submodule repository may be of comfortably workable size, but a single process that is working on the superproject may ran out of a per-process resource limit if it is made to also slurp data for the submodules, especially when working on a project with dozens of submodules. -- 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