From: karthik nayak Date: Fri, 20 Dec 2024 11:31:15 GMT Subject: Re: [PATCH v2 5/8] refs: add `committer_info` to `ref_transaction_add_update()` Message-ID: In-Reply-To: <875xnfh3kx.fsf@iotcl.com> Toon Claes writes: > karthik nayak writes: > >> Patrick Steinhardt 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. > I agree with your reasoning here.. > 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(..., NULL, msg)`? I don't think that's a > great solution either. > Yes, agreed with this too. > 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. > I think this seems like a nice way to go about it. Currently all the logic pertaining to creating an `ref_update` struct is contained within `ref_transaction_add_update()`. So having individual functions would make sense, but the con here is that this doesn't enforce fields to be set. But for `committer_info` it does make sense. I'm going to leave it for now since the series is merged to `next`. Maybe something to do in the future as part of #leftoverbits. > -- > Toon