"Philip Oakley" <philipoak...@iee.org> writes:
> From: "Christian Couder" <chrisc...@tuxfamily.org>
> Sent: Wednesday, August 07, 2013 5:42 AM
>> Users replacing an object with one of a different type were not
>> prevented to do so, even if it was obvious, and stated in the doc,
>> that bad things would result from doing that.
>>
>> To avoid mistakes, it is better to just forbid that though.
>>
>> The doc will be updated in a later patch.
>>
>> Signed-off-by: Christian Couder <chrisc...@tuxfamily.org>
>> ---
>> If this patch is considered useful, I will update the doc and
>> maybe add tests.
>
> Acked-by: Philip Oakley <philipoak...@iee.org>
> Improved documentation would always be useful.
Will wait for a reroll with tests and doc updates, then.
>> @@ -100,6 +101,14 @@ static int replace_object(const char *object_ref,
>> const char *replace_ref,
>> if (check_refname_format(ref, 0))
>> die("'%s' is not a valid ref name.", ref);
>>
>> + obj_type = sha1_object_info(object, NULL);
>> + repl_type = sha1_object_info(repl, NULL);
>
> Do (very) large blobs have any issues here? As I understand it, such
> blobs, as with other smaller objects, need to be expanded to determine
> the type.
sha1_object_info() is coded to peek into only the early part of a
loose object or the object header part of a packed object. Loose
ones we do mmap(), but we only inflate a tiny bit (the first 32
bytes).
>> + if (obj_type != repl_type)
>> + die("Object ref '%s' is of type '%s'\n"
>> + "while replace ref '%s' is of type '%s'.",
>> + object_ref, typename(obj_type),
>> + replace_ref, typename(repl_type));
>
> Perhaps start with "Objects must be of the same type.\n"
Yes.
--
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
