How to handle git object's struct in Mercury?

[Hou-Xiaoxuan]

continue the discussion here #756 (comment)

[Hou-Xiaoxuan]

          same for other objects containing a SHA1 hash for itself

well, visibility issue is quite common across the mercury codebase. It may be just about naming, but it's the first time that I see a rust library exposes its internal module to the outside.

Originally posted by @el-ev in #756 (comment)

Yes, the name ‘internal’ isn’t very accurate. In fact, Mercury was extracted as a shared dependency for other repositories, and it primarily contains basic data structures. For this reason, most structs in Mercury expose all their members as public.

[Hou-Xiaoxuan]

As for modifying the current struct, the current implementation of eq is somewhat ambiguous (as it only compares id). Additionally, based on #748 (comment), implementing eq for these structs seems unnecessary at this stage. Therefore, I tend to lean towards removing these redundant derive implementations.

[el-ev]

The real git compares objects in the same way.

static inline int oideq(const struct object_id *oid1, const struct object_id *oid2)
{
	return !memcmp(oid1->hash, oid2->hash, GIT_MAX_RAWSZ);
}

[Hou-Xiaoxuan]

Alright, I have no objections then.

I reviewed the usage, and if we change the members to non-pub, the impacted areas—taking Blob as an example—are primarily in Mercy and Libra, with some occurrences in Ceres. Specifically, id is used 28 times and hash 21 times. It doesn’t seem like a particularly large number. @MrBeanCpp

[MrBeanCpp]

It's not just the Blob; the changes will affect the usage of all fields in all git objects. @Hou-Xiaoxuan