Nguyễn Thái Ngọc Duy <pclo...@gmail.com> 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 <pclo...@gmail.com>
> 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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html