Am 23.01.2013 18:01, schrieb Junio C Hamano: > 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 agree this is a worthwhile change so nobody accidentally screws things up. >> It catches at least a case in >> t7405.3. I did not investigate further though. This is a false positive. The merge algorithm picked a fast-forward in a submodule as a proper merge result and records that in a gitlink. But as Duy pointed out this could be easily fixed by turning the readonly flag off in that case. > 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. Please don't. While I agree with your goal, I'd be unhappy to do that because of the performance drop (especially on fork-challenged operating systems). -- 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