Jaime Soriano Pastor <jsorianopas...@gmail.com> 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).
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