Re: [PATCH v3 06/12] refs API: pass the "lock OID" to reflog "prepare"

On Wed, Jul 21 2021, Han-Wen Nienhuys wrote:

On Wed, Jul 21, 2021 at 7:48 PM Junio C Hamano [off-list ref] wrote:

 Junio C Hamano [off-list ref] 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@evledraar.gmail.com/ (local))

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?