Re: Question about get_cached_commit_buffer()
From: Junio C Hamano <hidden>
Date: 2018-02-21 22:22:13
Jeff King [off-list ref] writes:
I think that repeating the oid is intentional; the point is to dump how the traversal code is hitting the endpoints, even if we do so multiple times. The --oneline behavior just looks like a bug. I think --format is broken with --show-all, too (it does not show anything!).
I do not know about the --format thing, but the part about --oneline being a bug is correct. I've known about the oneline that does not show anything other than the oid (not even end-of-line) for unparsed commits for a long time---I just didn't bother looking into fixing it exactly because this is only a debugging aid ;-)
Though I think it would be equally correct to have set_commit_buffer() just throw away the existing cache entry and replace it with this one. I don't think there's a real reason to prefer the old to the new. And that might be worth doing if it would let us drop get_cached_commit_buffer() as a public function. But... ... In my opinion it's not really worth trying to make it private. The confusion you're fixing in the first two calls is not due to a bad API, but due to some subtly confusing logic in that code's use of the API. ;)
Yup.
So I'd probably do this: ...
Makes sense to me.