One thing I forgot to mention: there’s now an inconsistency between commit_time and other functions taking commit: Either as a parameter as commit_time borrows it as opposed to taking ownership.

Thanks a lot, and sorry for the long wait!

One thing I forgot to mention: there’s now an inconsistency between commit_time and other functions taking commit: Either as a parameter as commit_time borrows it as opposed to taking ownership.

I don't think I follow, but if you think this is something that could be fixed, I encourage doing so in a follow-up. To me it sounds like copy-types shouldn't be borrowed by default.
I did try to look up the types you mentioned, but didn't find anything unusual.

Sorry, my question was lacking a lot of context! :-) I was referring to these functions:

fn commit_time(commit: &gix_traverse::commit::Either<'_, '_>)

fn collect_parents(commit: gix_traverse::commit::Either<'_, '_>, ...)

fn tree_id(commit: gix_traverse::commit::Either<'_, '_>)

All of them take an Either, but commit_time is the only function that takes commit by reference. I was wondering whether there were any reasons to remove this inconsistency.

Yes, I think it would make sense to make it consistent. If you wanted to tackle it, it's a tough choice to go for one or the other. Either it's Copy, which means it shouldn't be passed as reference. If you'd choose to make it a reference, maybe because std::mem::sizeof shows it's a bit large, then Copy could be removed so & is naturally enforced.

Yes, I think it would make sense to make it consistent. If you wanted to tackle it, it's a tough choice to go for one or the other. Either it's Copy, which means it shouldn't be passed as reference. If you'd choose to make it a reference, maybe because std::mem::sizeof shows it's a bit large, then Copy could be removed so & is naturally enforced.

I‘ll weigh the options and create a follow-up PR!