This is the whole refs-transactions-reflog series[1],
which was in discussion for a bit already. It applies to origin/master.
The idea is to have the reflog being part of the transactions, which
the refs are already using, so the we're moving towards a database
like API in the long run. This
On 12/04/2014 09:29 AM, Stefan Beller wrote:
This is the whole refs-transactions-reflog series[1],
which was in discussion for a bit already. It applies to origin/master.
I am still unhappy with the approach of this series, for the reasons
that I explained earlier [1]. In short, I think that
Hi,
Michael Haggerty wrote:
On 12/04/2014 09:29 AM, Stefan Beller wrote:
This is the whole refs-transactions-reflog series[1],
which was in discussion for a bit already. It applies to origin/master.
I am still unhappy with the approach of this series, for the reasons
that I explained
Michael Haggerty wrote:
I am still unhappy with the approach of this series, for the reasons
that I explained earlier [1]. In short, I think that the abstraction
level is wrong. In my opinion, consumers of the refs API should barely
even have to *know* about reflogs, let alone implement
On Thu, Dec 04, 2014 at 10:14:04AM -0800, Jonathan Nieder wrote:
Michael Haggerty wrote:
I am still unhappy with the approach of this series, for the reasons
that I explained earlier [1]. In short, I think that the abstraction
level is wrong. In my opinion, consumers of the refs API
Michael Haggerty mhag...@alum.mit.edu writes:
... an alternate proposal, to convert
expire_reflogs() to take callback functions that decide *what* to
expire, but which itself does the work of acquiring locks, iterating
through the reflog entries, rewriting the file, and overwriting the old
Stefan Beller sbel...@google.com writes:
This is the whole refs-transactions-reflog series[1],
which was in discussion for a bit already. It applies to origin/master.
The idea is to have the reflog being part of the transactions, which
the refs are already using, so the we're moving towards
On Thu, Dec 4, 2014 at 10:41 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
This is the whole refs-transactions-reflog series[1],
which was in discussion for a bit already. It applies to origin/master.
The idea is to have the reflog being part of the
Stefan Beller wrote:
Ok, let's see how Michaels series evolves and if I can base the
transactions series
on that
That sounds good to me, too, FWIW. That way we don't have to fuss
with conflicts in refs.c. :)
Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
On 12/04/2014 07:32 PM, Stefan Beller wrote:
On Thu, Dec 04, 2014 at 10:14:04AM -0800, Jonathan Nieder wrote:
Michael Haggerty wrote:
I am still unhappy with the approach of this series, for the reasons
that I explained earlier [1]. In short, I think that the abstraction
level is wrong. In
10 matches
Mail list logo
