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 the abstraction level is wrong. In my opinion, consumers of the refs API should barely even have to *know* about reflogs, let alone implement reflog expiration themselves. Of course, reflog expiration *should* be done atomically. But that is the business of the refs module; callers shouldn't have to do all the complicated work of building the transaction themselves. I spent the day working on 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 file with the new one. The goal is to move this function into refs.c and make builtin/reflog.c much simpler--it will only have to implement the callbacks that determine the expiration policy. I'm almost done with the series but won't be able to finish it until tomorrow. For those who are impatient, here is my work in progress [2]. Michael [1] http://thread.gmane.org/gmane.comp.version-control.git/259712/focus=259770 [2] https://github.com/mhagger/git, branch "reflog-expire-api". -- Michael Haggerty mhagger@xxxxxxxxxxxx -- 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