Re: [PATCH 00/11] Allow reference values to be checked in a transaction

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 9, 2015, 18:41 UTC
Message-ID: <xmqqtwyvapx7.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1423412045-15616-1-git-send-email-mhagger@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 22 quoted lines

> 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?

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?

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).