git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/8] Making reflog modifications part of the transactions API

From
RSronnie sahlberg <ronniesahlberg@gmail.com>
Date
Dec 12, 2014, 21:16 UTC
Message-ID
<CAN05THRiMiQCqO1VZX7zQeWLBZMPG_sx1aVvdGirAoEh2Hd9Dw@mail.gmail.com>
In-Reply-To
<548B150C.2090606@alum.mit.edu>
On Fri, Dec 12, 2014 at 11:17 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
Show 32 quoted lines
> On 12/06/2014 03:46 AM, Stefan Beller wrote:
>> This goes on top of Michaels series. The idea of this series is make the
>> reflogs being part of the transaction API, so it will be part of the contract
>> of transaction_commit to either commit all the changes or none at all.
>>
>> Currently when using the transaction API to change refs, also reflogs are changed.
>> But the changes to the reflogs just happen as a side effect and not as part of
>> the atomic part of changes we want to commit altogether.
>
> Would you please explain why this patch series is still needed if my
> "reflog_expire()" series is accepted?
>
> reflog_expire() already has its own little transaction. Reflog
> expiration never needs to be combined with other reference changes, so
> there is no need for reflog expiration to be done via a ref_transaction.
>
> ref_transaction_commit() already updates the reflog if necessary when a
> reference is updated. That update is part of the containing
> ref_transaction, because it is locked by the lock on the reference
> itself at the beginning of the transaction and unlocked at the end of
> the transaction [1]. It can't fail in normal circumstances because the
> preconditions for the transaction have already been checked.
>
> As far as I can tell, the only thing left to do is provide a substitute
> for log_ref_setup() a.k.a. create_reflog() that can be triggered within
> a transaction. In my opinion the easiest way to do that is to give
> ref_transaction_update()'s flag parameter an additional option,
> REF_CREATE_REFLOG, which forces the reference's reflog to be created if
> it does not already exist.
>
> What am I missing?
>

My original idea was to clean up a bit of the reflog handling API and have one single transaction API for all ref and reflog operations.

Think future use cases where you have a database backend for both refs and reflogs. It would be very nice to have a single atomic transaction that would either commit or fail atomically any update to refs and/or reflogs. Otherwise you would have all consumers of the API have to invent their own transaction and rewind support : 'oh the ref transaction failed and I have already done the reflog commit, have to manually uncommit ...". And this quickly becomes quite burdensome for consumers.

I think a transaction API should remove this burden from consumers and make it as easy as possible to use the API.

Conditional of if it is desireable to have transactions for reflogs at all.

About the cleanup part. The current API, and I think also the current direction of both my old patches (which I think did not go far enough in the transactifications) or this current patchseries is that they all have a very confusing and inconsistent API for reflog updates. With this I mean, sometimes reflog updates happen within a transaction as a side effect of a ref_transaction_update(). Other times reflog updates happens ooutside of transactions by calling a special reflog API.

I.e. reflogs sometimes update as part of a transaction and sometimes not. A follow up question then on this API is what should happen if you have a transaction open, but not committed, and while the transaction is open you call the non-transactional reflog API for a reflog for the same ref that is already beeing/or going to be/ updated as the ref-update-side-effect ?

I think an api where "sometimes you operate on foo from within a transaction and sometimes you do not, and if you do the latter when a transaction is open, it is unclear what should happen" is not great. IMHO, refs and reflog updates are related and I think:

* a transaction should be the ONLY way to mutate either a ref or a
reflog or both.
* if you update both a ref and a reflog then that should happen as
part of one single transaction.
* (later) it would probably make the API better if the code was
refactored so write_ref_sha1() will NOT call log_ref_write() anymore
and instead make the reflog update that happens explicit perhaps by
calling something like a ref_transaction_update_reflog() as part of
the ref_transaction_update() call.
Show 13 quoted lines
> Michael
>
> [1] The reflog updates are not atomic in the face of disk errors and
> power outages and stuff, but neither are reference updates. In other
> words, I think reflog updates in ref_transaction_commit() are done as
> safely as reference updates, which is surely good enough for this
> reference backend. Other reference backends can do a better job with
> both while staying within the existing API.
>
> --
> Michael Haggerty
> mhagger@alum.mit.edu
>
Previous: Stefan BellerNext: Michael Haggerty
Message 17 of 18 in “Making reflog modifications part of the transactions API”
  1. 0/8 Making reflog modifications part of the transactions APIStefan Beller, Dec 6, 2014
  2. 1/8 refs.c: let fprintf handle the formattingStefan Beller, Dec 6, 2014
  3. 2/8 refs.c: rename the transaction functionsStefan Beller, Dec 6, 2014
  4. Junio C HamanoDec 11, 2014
  5. Stefan BellerDec 11, 2014
  6. 3/8 refs.c: rename transaction.updates to transaction.ref_updatesStefan Beller, Dec 6, 2014
  7. 4/8 refs.c: add transaction function to append to the reflogStefan Beller, Dec 6, 2014
  8. Junio C HamanoDec 11, 2014
  9. 5/8 refs.c: add transaction function to delete the reflogStefan Beller, Dec 6, 2014
  10. 6/8 refs.c: use a reflog transaction when writing during expireStefan Beller, Dec 6, 2014
  11. 7/8 refs.c: rename log_ref_setup to create_reflogStefan Beller, Dec 6, 2014
  12. 8/8 refs.c: allow deleting refs with a broken sha1Stefan Beller, Dec 6, 2014
  13. Stefan BellerDec 8, 2014
  14. Jonathan NiederDec 8, 2014
  15. Michael HaggertyDec 12, 2014
  16. Stefan BellerDec 12, 2014
  17. ronnie sahlbergDec 12, 2014
  18. Michael HaggertyDec 14, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.