Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > add_submodule_odb() can be used to import objects from another > repository temporarily. After this point we don't know which objects > are ours, which are external. If we create an object that refers to an > external object, next time git runs, it may find a hole in the object > graph because the external repository may not be imported. The same > goes for pointing a ref to an external SHA-1. > > To protect ourselves, once add_submodule_odb() is used: > > - trees, tags and commits cannot be created > - refs cannot be updated > > In certain cases that submodule code knows that it's safe to write, it > can turn the readonly flag off. > > Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> > --- > I think this is a good safety check. Two step implementation to bring "read-only" support into a testable shape and then flip that bit in add_submdule_odb() would be a sensible approach. I however have this suspicion that this will become a losing battle and we would be better off getting rid of add_submodule_odb(); instead operations that work across repositories will be done as a subprocess, which will get us back closer to one of the original design goals of submodule support to have a clear separation between the superproject and its 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