Re: [PATCH v3 00/14] ref-transactions-reflog

2014-11-20 Thread Michael Haggerty
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 API?

Re: [PATCH v3 00/14] ref-transactions-reflog

2014-11-20 Thread Junio C Hamano
Jonathan Nieder jrnie...@gmail.com 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

Re: [PATCH v3 00/14] ref-transactions-reflog

2014-11-20 Thread Jonathan Nieder
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 would be

Re: [PATCH v3 00/14] ref-transactions-reflog

2014-11-19 Thread Stefan Beller
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

Re: [PATCH v3 00/14] ref-transactions-reflog

2014-11-19 Thread Jonathan Nieder
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 worth, I

Re: [PATCH v3 00/14] ref-transactions-reflog

2014-11-18 Thread Michael Haggerty
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

Re: [PATCH v3 00/14] ref-transactions-reflog

2014-11-18 Thread Ronnie Sahlberg
On Tue, Nov 18, 2014 at 3:26 AM, Michael Haggerty mhag...@alum.mit.edu 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

Re: [PATCH v3 00/14] ref-transactions-reflog

2014-11-18 Thread Michael Haggerty
On 11/18/2014 07:36 PM, Ronnie Sahlberg wrote: On Tue, Nov 18, 2014 at 3:26 AM, Michael Haggerty mhag...@alum.mit.edu 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

Re: [PATCH v3 00/14] ref-transactions-reflog

2014-11-18 Thread Junio C Hamano
Michael Haggerty mhag...@alum.mit.edu 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

Re: [PATCH v3 00/14] ref-transactions-reflog

2014-11-18 Thread Michael Haggerty
On 11/18/2014 09:30 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu 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

Re: [PATCH v3 00/14] ref-transactions-reflog

2014-11-18 Thread Junio C Hamano
Michael Haggerty mhag...@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