Jeff King <peff@xxxxxxxx> writes: > Oops, thanks, I had forgotten that the marks needed to be addressed. > Should I be introducing new flags? We have 27 flag bits, but I would > hate to waste 2 of them. In the longer term it would be not just nice but necessary for us to come up with a scheme where different codepaths can "allocate bits from object flags", without having to fear stepping on each other's toes. Some possible approaches off the top of my head are: - Extend "struct object" by another uint64_t to give it 64 more bits? That would make the minimum object size from 24 bytes to 32 bytes and during a pack-object session we would keep a lot of objects (not just commits but trees and blobs) in core, so we probably would not want to do this. - Extend "struct commit" by another uint32_t? Currently a "struct commit" is 72 bytes on x86_64 (there is an unfortunate 4-byte padding gap between indegree and date), and 48 bytes on i386 and this would enlarge the latter to 52 bytes (this comes free on 64-bit archs). As we need a lot more bits on commits than on other objects (e.g. left-right do not need to be placed on trees or blobs), this approach might be more space efficient. - Use one bit in the current flags section to signal "extended flag bits present on this object", and have a separate hashtable for minority objects that have that bit set? This would work only for flag bits that are rarely used (otherwise the secondary hashtable will be full of objects and per-object overhead will kill us). - Migrate some users of flag bits that only mark small miniroty of commits to use dedicated hashtable to free their bits [*1*]. I don't know if there are candidates for doing this offhand. Just uttering it as an idea. Independent of this issue, I suspect that we might want to fold object.used into the general set of flags---it is only used by fsck as far as I remember. [Footnote] *1* Also we would want to do something similar to the commit.util field so that more than one utility libraries can attach their own stuff to each commit. It _might_ make sense to instead get rid of commit.util and migrate the users to a separate "one object hash per one type of info", though. In any case it is a separate topic. -- 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