Jens Lehmann <jens.lehm...@web.de> writes: > 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 see that as "easily circumvented and not an effective protection", though. In theory, adding a gitlink to the index, removing a gitlink to the index and modifying an existing gitlink in the index to another gitlink in the index and writing the resulting in-core index out to the on-disk index should be allowed, even after objects from the submodule object database have contaminated our in-core object pool, as long as you do not run cache_tree_update(). I am not sure if that single loophole would be sufficient, though. -- 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
