karthik nayak <karthik.188@xxxxxxxxx> writes: > Patrick Steinhardt <ps@xxxxxx> writes: > >> On Fri, Dec 13, 2024 at 11:36:50AM +0100, Karthik Nayak wrote: >>> The `ref_transaction_add_update()` creates the `ref_update` struct. To >>> facilitate addition of reflogs in the next commit, the function needs to >>> accommodate setting the `committer_info` field in the struct. So modify >>> the function to also take `committer_info` as an argument and set it >>> accordingly. >> >> I was wondering a bit whether we could instead pull out a >> `add_update_internal()` function so that we don't need to modify all >> callers of `ref_transaction_add_update()`. Because ultimately, we don't >> use the field anywhere except from `ref_transaction_add_reflog_update()` >> as far as I can see. >> >> This is more of a thought than a strong opinion, so feel free to ignore. >> > > Yes, that is a possible change, but the number of code changes are > relatively low and I didn't think it made so much difference. Also > because we'd now have one more function. But I don't mind doing it > either, if anyone feels strongly about it, I'll happily make that > change. Yes, I agree the number of callsites isn't that large, but on the other hand, I see various calls to this function having four `NULL`s in a row as arguments. Personally, I think that starts to smell a bit. Now, before you change anything. I'm not sure what Patrick was suggesting? Would it mean we basically rename `ref_transaction_add_update()` to `add_update_internal()` and create a new wrapper function `ref_transaction_add_update()` that simply calls `add_update_internal(<ARGS>..., NULL, msg)`? I don't think that's a great solution either. Alternively, because ref_transaction_add_update() returns the `struct ref_update`, why not add a function `ref_update_set_committer` and call that where we need to set the committer? I see this also will help in a future commit where you call ref_transaction_add_update() differently depending on reflog updates. -- Toon
