Re: [PATCH v3 00/14] ref-transactions-reflog
- From
Stefan Beller <sbeller@google.com>
- Date
- Nov 19, 2014, 23:22 UTC
- Message-ID
- <CAGZ79kb3DOrL_txW-qxzd0=4sKrOiPTdSg-17_0+__wuj0TBaQ@mail.gmail.com>
- In-Reply-To
- <xmqqsihgtcyx.fsf@gitster.dls.corp.google.com>
Sorry for the long delay. Thanks for the explanation and discussion.
So do I understand it right, that you are not opposing the introduction of "everything should go through transactions" but rather the detail and abstraction level of the API?
So starting from Michaels proposal in the first response:
1. Add a reflog entry when a reference is updated in a transaction.
ok
2. Rename a reflog file when the corresponding reference is renamed.
This should happen within the same transaction as the reference is renamed, right? So we don't have a multistep process here, which may abort in between having the reference updated and a broken reflog or vice versa. We want to either have both the ref and the reflog updated or neither.
3. Delete the reflog when the corresponding reference is deleted [1].
also as one transaction?
4. Configure a reference to be reflogged. 5. Configure a reference to not be reflogged anymore and delete any existing reflog.
Why do we need 4 and 5 here? Wouldn't all refs be reflog by default and why do I want to exclude some?
6. Selectively expire old reflog entries, e.g., based on their age.
This is the maintenance operation, which you were talking about. In my vision, this also should go into one transaction. So you have the business logic figuring out all the changes ("drop reflog entry a b and d") and within one transaction we can perform all of the changes.
Thanks, Stefan
On Tue, Nov 18, 2014 at 1:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 20 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes: > >>> Sorry, but I lost track---which one is inside and which one is >>> outside? >> >> By "inside" I mean the code that would be within the reference-handling >> library if we had such a thing; i.e., implemented in refs.c. By >> "outside" I mean in the code that calls the library; in this case the >> "outside" code would live in builtin/reflog.c. >> >> In other words, I'd prefer the "outside" code in builtin/reflog.c to >> look vaguely like >> >> expire_reflogs_for_me_please(refname, >> should_expire_cb, cbdata, flags) >> >> rather than >> ... (written as a client of the ref API) ... > > OK, I very much agree with that.