On Wed, Jun 3, 2020 at 2:27 PM Patrick Steinhardt <ps@xxxxxx> wrote: > The low-level reference transactions used to update references are > currently completely opaque to the user. While certainly desirable in > most usecases, there are some which might want to hook into the > transaction to observe all queued reference updates as well as observing > the abortion or commit of a prepared transaction. I have an alternate suggestion, but it would depend on having reftable. In reftable, the transaction is 0) create tables.list.lock 1) write out new reftable(s), 2) renaming tables.list.lock to tables.list. If you insert a hook between 1) and 2), the hook would not need to be supplied with any data, so it would have minimal performance impact. If the hook runs, it can compare tables.list and tables.list.lock, read out the new reftables, and make decisions based on that. Or alternatively, the transaction could be passed a list of reftables, that the hook could then process at its leisure. > +For each reference update that was added to the transaction, the hook > +receives on standard input a line of the format: > + > + <old-value> SP <new-value> SP <ref-name> LF Does this work for symrefs as well? Should it? -- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
