2011/2/7 Junio C Hamano <gitster@xxxxxxxxx>:
>> diff --git a/cache-tree.c b/cache-tree.c
>> index f755590..03732ad 100644
>> --- a/cache-tree.c
>> +++ b/cache-tree.c
>> @@ -621,9 +621,18 @@ static void prime_cache_tree_rec(struct cache_tree *it, struct tree *tree)
>> Â Â Â Â Â Â Â Â Â Â Â struct tree *subtree = lookup_tree(entry.sha1);
>> Â Â Â Â Â Â Â Â Â Â Â if (!subtree->object.parsed)
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â parse_tree(subtree);
>> + Â Â Â Â Â Â Â Â Â Â if (!hashcmp(entry.sha1, (unsigned char *)EMPTY_TREE_SHA1_BIN)) {
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â warning("empty tree detected! Will be removed in new commits");
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â cnt = -1;
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â break;
>> + Â Â Â Â Â Â Â Â Â Â }
>
> You shouldn't need the cast (if you did, then hashcmp() macro should be
> fixed so that you don't need to).
Or perhaps EMPTY_TREE_SHA1_BIN should be casted to const unsigned char
*. That would eliminate 4 typecastings elsewhere.
> I don't think warning() is warranted for an operation you introduced to
> keep the internal data structure consistent.
Worse. I don't think users know an empty tree is added or removed.
diff-tree does not show it (or should not, I haven't tested).
> Should this comparison done after we parsed the subtree, or should we be
> doing that before it?
>
> If you are adding this new check to a point where we have already parsed
> the subtree object, don't you have a better and cheaper way to detect if
> the subtree is empty than the 20-byte comparision, namely, perhaps by
> looking at subtree->size?
OK before is better.
--
Duy
--
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