On 03/10/2014 06:44 PM, Brad King wrote:
> [...]

Thanks for your kind words.

> On 03/10/2014 08:46 AM, Michael Haggerty wrote:
>> The new API for dealing with reference transactions is
>>     ref_transaction *transaction = create_ref_transaction();
>>     queue_create_ref(transaction, refname, new_sha1, ...);
>>     queue_update_ref(transaction, refname, new_sha1, old_sha1, ...);
>>     queue_delete_ref(transaction, refname, old_sha1, ...);
>>     ...
>>     if (commit_ref_transaction(transaction, msg, ...))
>>         die(...);
> The layout of this API looks good.
> The name "queue" is not fully representative of the current behavior.
> It implies that the order is meaningful but we currently allow at most
> one update to a ref and sort them by refname.  Does your follow-up work
> define behavior for multiple updates to one ref?  Can it collapse them
> into a single update after checking internal consistency of the sequence?

I don't really like the word "queue" in these function names, but I
couldn't think of a better alternative.  I wanted a word that conveys
that the change is being collected for later application as opposed to
being applied immediately.  Other suggestions are welcome.

In the future I *do* want to define the behavior for multiple updates to
a single ref.  Even now, although order is not preserved when carrying
out the updates, the facts that (1) at most one update is allowed to
each reference and (2) the changes are made (approximately) atomically
together mean that the effect of committing a transaction is
(approximately) indistinguishable from the effect it would have if order
were preserved.

> [...]


Michael Haggerty
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to