On Wed, Jul 21 2021, Han-Wen Nienhuys wrote: > On Wed, Jul 21, 2021 at 7:48 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > This obviously breaks the latest round of reftable topic, as it > > still wants this type to take const oid, and I do not think using > > on-filesystem lock as if we are using the files backend is not a > > good solution. > > Sorry for redundant negation. "I do not think it is a good solution > to have everybody pretend as if they are files backend when they > lock refs." was what I meant. > > Reftable could easily read the current OID for the reference, if necessary. (I'm replying to a mail of Han-Wen's that didn't make it on-list due to inline HTML, quoted here in its entirety sans signature, see https://lore.kernel.org/git/87eebptr7i.fsf@xxxxxxxxxxxxxxxxxxx/) Junio: I can change the const around if desired. I thought we weren't particularly concerned about it in general except to avoid the verbosity of frequent casting, and in this case the lock API doesn't have "const". But as for the reftable incompatibility it seems to me irrespective of backend that a reflog API that supports expiry is going to want to have a callback for "give me a lock to expire this branch" and give you a reply of "OK, you have the lock, you can expire the log, and it's at this OID". Why would it be file-backend specific?
