Jaime Soriano Pastor <jsorianopastor@xxxxxxxxx> writes: > Wrong implementations of tools that modify the index can left > some files as merged and unmerged at the same time. Avoid undesiderable > behaviours by handling this situation. It is understandable that the way _you_ decided to "handle the situation" is so obvious to be spelled out to _you_, but that is the most important design decision that needs to be described here. Do you silently remove higher-stage entries when an entry at stage 0 exists? Do you silently remove stage 0 entry when higher-stage entries exist? Do you error out without doing neither? Silently removing these at runtime may not be something we would want to do; after all, we do not know if the broken tool actually wanted to have the higher stage entries, or the merged entry. Ideally, I think we should error out and let the users figure out how to proceed (we may of course need to make sure they have the necessary tools to do so, e.g. "git cat-file blob 0:$path" to resurrect the contents and "git update-index --cacheinfo" to stuff the contents into the stages). Thanks. -- 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