On Mon, Feb 9, 2015 at 10:41 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > >> The main purpose of this series is to simplify the interface to >> reference transactions as follows: >> >> * Remove the need to supply an explicit have_old parameter to >> ref_transaction_update() and ref_transaction_delete(). Instead, >> check the old_sha1 if and only if it is non-NULL. >> >> * Allow NULL to be supplied to ref_transaction_update() as new_sha1, >> in which case old_sha1 will be verified under lock, but the >> reference's value will not be altered. >> >> * Add a function ref_transaction_verify(), which verifies the current >> value of a reference without changing it. >> >> * Make the similarity between ref_transaction_update() and >> update_ref() more obvious. >> >> Along the way, it fixes a race that could happen if two processes try >> to create an orphan commit at the same time. >> >> This patch series applies on top of master merged together with >> sb/atomic-push, which in turn depends on mh/reflog-expire. > > I am a bit puzzled by your intentions, so help me out. > > I see that your understanding is that Stefan will be rerolling the > push atomicity thing; wouldn't we then want to have a "fix and > clean" topic like this one first and build the push atomicity thing > on top instead? My understanding is to not reroll origin/sb/atomic-push, but origin/sb/atomic-push-fix (which is worded misleading. It is not about atomic pushes, but about enabling large transactions in my understanding) > > In other words, would it make sense to extend mh/reflog-expire (in > 'next') topic with commits from "Fix some problems with reflog > expiration (8 patches)" series and this series to fix and clean it? I am not sure what advantages this would bring. A better history for bisection? I cannot speak for Michael, but my understanding was to have mh/reflog-expire and sb/atomic-push-fix merged now that 2.3 is out and everything else on top is unclear/rerolled/discussed as needed. > > We may even want to rebase/reroll mh/reflog-expire on top of v2.3 > while doing so to adjust to the transaction stuff, if that makes > some of the changes in the two new series unnecessary (if these "fix > and clean up" changes made in mh/reflog-expire in 'next', that is). > -- 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