Michael Haggerty wrote:
> On 11/20/2014 12:22 AM, Stefan Beller wrote:
>> 3. Delete the reflog when the corresponding reference is deleted [1].
>>
>> also as one transaction?
>
> It would be a side-effect of committing a transaction that contains a
> reference deletion. The deletion of the reflog
Jonathan Nieder writes:
> I also have some thoughts about how those operations can be
> implemented without such a performance hit (reading the whole
> reflog into memory as part of the transaction seems problematic to
> me), but that should probably wait for a separate message (and
> I've talked
On 11/20/2014 12:22 AM, Stefan Beller wrote:
> 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 AP
Hi,
Stefan Beller wrote:
> 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?
For what it's w
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 respo
Michael Haggerty 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 librar
On 11/18/2014 09:30 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I'm still not convinced. For me, "reflog_expire()" is an unusual outlier
>> operation, much like "git gc" or "git pack-refs" or "git fsck". None of
>> these are part of the beautiful Git data model; they are messy
>> ma
Michael Haggerty writes:
> I'm still not convinced. For me, "reflog_expire()" is an unusual outlier
> operation, much like "git gc" or "git pack-refs" or "git fsck". None of
> these are part of the beautiful Git data model; they are messy
> maintenance operations. Forcing reference transactions t
On 11/18/2014 07:36 PM, Ronnie Sahlberg wrote:
> On Tue, Nov 18, 2014 at 3:26 AM, Michael Haggerty
> wrote:
>> On 11/18/2014 02:35 AM, Stefan Beller wrote:
>>> The following patch series updates the reflog handling to use transactions.
>>> This patch series has previously been sent to the list[1]
On Tue, Nov 18, 2014 at 3:26 AM, Michael Haggerty wrote:
> On 11/18/2014 02:35 AM, Stefan Beller wrote:
>> The following patch series updates the reflog handling to use transactions.
>> This patch series has previously been sent to the list[1].
>> [...]
>
> I was reviewing this patch series (I lef
On 11/18/2014 02:35 AM, Stefan Beller wrote:
> The following patch series updates the reflog handling to use transactions.
> This patch series has previously been sent to the list[1].
> [...]
I was reviewing this patch series (I left some comments in Gerrit about
the first few patches) when I real
Hi,
The following patch series updates the reflog handling to use transactions.
This patch series has previously been sent to the list[1].
This series converts the reflog handling and builtin/reflog.c to use
a transaction for both the ref as well as the reflog updates.
As a side effect of this it
These patches can also be found at:
https://github.com/rsahlberg/git/tree/ref-transactions-reflog
This series is based on, and applies ontop of, the previous 48 patch long
ref-transaction series that is now in origin/pu.
This series introduces support for reflog updates to the transaction framew
13 matches
Mail list logo
