From: Jens Lehmann Date: Wed, 23 Jan 2013 20:38:15 GMT Subject: Re: [PATCH/RFC] Revoke write access to refs and odb after importing another repo's odb Message-ID: <51004A37.6040301@web.de> In-Reply-To: <7v1udbj0kt.fsf@alter.siamese.dyndns.org> Am 23.01.2013 18:01, schrieb Junio C Hamano: > Nguyễn Thái Ngọc Duy 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 >> --- >> 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).