Re: [PATCH v6 2/5] reflog-walk: expose read_complete_reflog

From: Junio C Hamano <gitster@pobox.com>
Date: May 29, 2025, 21:59 UTC
Message-ID: <xmqqo6vbhydw.fsf@gitster.g>
In-Reply-To: <3d0697a6-e337-4b58-98d3-304e0f17ae66@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 9 quoted lines

> On 22/05/2025 19:55, brian m. carlson wrote:
>> In a future commit, we'll use this function and the corresponding free
>> function to read the entire reflog.  Expose it in the header so we can
>> do so.
>
> We already have refs_for_each_reflog_entry() and
> refs_for_each_reflog_entry_reverse() for traversing the reflog entries
> so I'm a bit confused as to why we need to make the internal details
> public.

The suggestion for using this function is largely fault of mine, who did not think of using the for-each helpers.

Looking at the function signature of for-each-reflog-ent callback

        typedef int each_reflog_ent_fn(
                        struct object_id *old_oid, struct object_id *new_oid,
                        const char *committer, timestamp_t timestamp,
                        int tz, const char *msg, void *cb_data);

I think it gives us the same piece of information, and is preferrable.

Thanks for a dose of sanity.