Ævar Arnfjörð Bjarmason [off-list ref] 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"?
On Mon, Dec 20 2021, Junio C Hamano wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
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.