On Mon, Dec 20 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> I've got some patches locally to convert e.g. write_object_file() to use >> the enum, and it removes the need for some callers to convert enum to >> char *, only to have other things convert it back. >> >> So I think for any new APIs it makes sense to work towards sidelining >> the hash-object.c --literally caller. > > Your logic is backwards to argue "because I did something this way, > it makes sense to do it this way"? No, it's that if you look at the write_object_file() and hash_object_file() callers in-tree now many, including in object-file.c itself are taking an "enum object_type" only to convert it to a string, and then we'll in turn sometimes convert that to the "enum object_type" again at some lower level. That API inconsistency dates back to at least Linus's a733cb606fe (Change pack file format. Hopefully for the last time., 2005-06-28). I'm just pointing out that I have local patches that prove that a lot of back & forth is done for no good reason, and that this is one of the codepaths that's tangentally involved. So it makes sense in this case to make any new API take "enum object_type" as the primary interface.