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@xxxxxxxxx> wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html