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. > [...] Cheers, Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
