From: Junio C Hamano <gitster@xxxxxxxxx>
>
> Thomas Rast <trast@xxxxxxxxxxx> 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,
> exists).
>
> 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.
I agree. It is always possible to create replacement refs using "git
update-ref" if one really wants to.
What about using the following in the commit message or in the
documentation:
------------------------------------------
DISCUSSION
If one object is replaced with one of a different type, the only way
to keep the history valid is to also replace all the other objects
that point to the replaced object. That's because:
* Annotated tags contain the type of the tagged object.
* The tree/parent lines in commits must be a tree and commits, resp.
* The object types referred to by trees are specified in the 'mode'
field:
100644 and 100755 blob
160000 commit
040000 tree
(these are the only valid modes)
* Blobs don't point at anything.
But if all the objects that point to an object, called O, are to be
replaced, then in most cases object O probably doesn't need to be
replaced. It's probably sufficient to create the new object, called
O2, that would replace object O and to replace all the objects
pointing to object O with objects pointing to O2.
The only case where someone might really want to replace object 0,
with an object O2 of a different type, and all the objects pointing to
it, is if it's really important, perhaps for external reasons, to have
object O's SHA1 point to O2.
And anyway, if one really wants to do that, it can still be done using
"git update-ref".
------------------------------------------
Thanks,
Christian.
--
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