On Thu, Jan 24, 2013 at 4:06 AM, Junio C Hamano <gits...@pobox.com> wrote: > 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.
The problem is we don't know which entries are updated in index. We don't keep track of them. And I think in the unpack-trees case, we scape the whole index then copy over, making it look like the whole index is updated (even with the same content). One way to check this is verify the source of all non-gitlink entries in index before writing to disk (only when readonly flag is on, of course). sha1_object_info_extended() should help (or be extended to do the job). Hmm.. if we do this, we could also verify if new sha-1 objects do not refer to an external source, if so allow them to be created. -- Duy -- 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
