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
Michael Haggerty <mhagger@alum.mit.edu>
Date
Dec 12, 2014, 16:17 UTC
Message-ID
<548B150C.2090606@alum.mit.edu>
In-Reply-To
<1417833995-25687-1-git-send-email-sbeller@google.com>
On 12/06/2014 03:46 AM, Stefan Beller wrote:
Show 7 quoted lines
> 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?
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: Jonathan NiederNext: Stefan Beller
Message 15 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.