Thomas Rast <tr...@inf.ethz.ch> writes:
> Hrm, you're right, that's a flaw in my logic. You could do the same in
> all other cases too, e.g. replace a tree so that an entry is of a
> different type and at the same time change the type of the object
> itself. You however have to carefully go through all objects that refer
> to the one that was replaced, and fix the type in all of them.
> It still seems an extremely unsafe thing to do with trees...
> Should we add a --force flag of some sort to allow the user to do this,
> while keeping the normal safety checks?
As long as we do not forbid such an unusual replacement on the
reading side, we won't break people who are more inventive than we
are (I am not convinced that we know people's workflow well enough
to definitively say that no sane workflow, which benefits from being
able to replace an object with another from a different type,
Preventing "git replace" wrapper from creating such a replacement by
default will make it harder to do and may reduce mistakes, without
breaking them too much, I think.
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