git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 00/26] Clean up update-refs --stdin and implement ref_transaction

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Mar 10, 2014, 21:46 UTC
Message-ID
<531E32CE.9040509@alum.mit.edu>
In-Reply-To
<531DF9FC.4070707@kitware.com>
On 03/10/2014 06:44 PM, Brad King wrote:
> [...]
Thanks for your kind words.
Show 18 quoted lines
> 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
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Previous: Brad King
Message 38 of 38 in “Clean up update-refs --stdin and implement ref_transaction”
  1. 00/26 Clean up update-refs --stdin and implement ref_transactionMichael Haggerty, Mar 10, 2014
  2. 01/26 t1400: Fix name and expected result of one testMichael Haggerty, Mar 10, 2014
  3. 02/26 t1400: Provide sensible input to the commandMichael Haggerty, Mar 10, 2014
  4. 03/26 t1400: Pass a legitimate <newvalue> to update commandMichael Haggerty, Mar 10, 2014
  5. Brad KingMar 10, 2014
  6. Michael HaggertyMar 10, 2014
  7. Brad KingMar 11, 2014
  8. Junio C HamanoMar 11, 2014
  9. Brad KingMar 11, 2014
  10. Michael HaggertyMar 20, 2014
  11. 04/26 parse_arg(): Really test that argument is properly terminatedMichael Haggerty, Mar 10, 2014
  12. 05/26 t1400: Add some more tests involving quoted argumentsMichael Haggerty, Mar 10, 2014
  13. Johan HerlandMar 10, 2014
  14. 06/26 refs.h: Rename the action_on_err constantsMichael Haggerty, Mar 10, 2014
  15. 07/26 update_refs(): Fix constnessMichael Haggerty, Mar 10, 2014
  16. 08/26 update-ref --stdin: Read the whole input at onceMichael Haggerty, Mar 10, 2014
  17. 09/26 parse_cmd_verify(): Copy old_sha1 instead of evaluating <oldvalue> twiceMichael Haggerty, Mar 10, 2014
  18. 10/26 update-ref.c: Extract a new function, parse_refname()Michael Haggerty, Mar 10, 2014
  19. 11/26 update-ref --stdin: Improve error messages for invalid valuesMichael Haggerty, Mar 10, 2014
  20. 12/26 update-ref --stdin: Make error messages more consistentMichael Haggerty, Mar 10, 2014
  21. 13/26 update-ref --stdin: Simplify error messages for missing oldvaluesMichael Haggerty, Mar 10, 2014
  22. Brad KingMar 10, 2014
  23. Brad KingMar 10, 2014
  24. 14/26 update-ref.c: Extract a new function, parse_next_sha1()Michael Haggerty, Mar 10, 2014
  25. 15/26 update-ref --stdin: Improve the error message for unexpected EOFMichael Haggerty, Mar 10, 2014
  26. 16/26 update-ref --stdin: Harmonize error messagesMichael Haggerty, Mar 10, 2014
  27. 17/26 refs: Add a concept of a reference transactionMichael Haggerty, Mar 10, 2014
  28. 18/26 update-ref --stdin: Reimplement using reference transactionsMichael Haggerty, Mar 10, 2014
  29. 19/26 refs: Remove API function update_refs()Michael Haggerty, Mar 10, 2014
  30. 20/26 struct ref_update: Rename field "ref_name" to "refname"Michael Haggerty, Mar 10, 2014
  31. 21/26 struct ref_update: Store refname as a FLEX_ARRAY.Michael Haggerty, Mar 10, 2014
  32. 22/26 commit_ref_transaction(): Introduce temporary variablesMichael Haggerty, Mar 10, 2014
  33. 23/26 struct ref_update: Add a lock memberMichael Haggerty, Mar 10, 2014
  34. 24/26 struct ref_update: Add type fieldMichael Haggerty, Mar 10, 2014
  35. 25/26 commit_ref_transaction(): Also free the ref_transactionMichael Haggerty, Mar 10, 2014
  36. 26/26 commit_ref_transaction(): Work with transaction->updates in placeMichael Haggerty, Mar 10, 2014
  37. Brad KingMar 10, 2014
  38. Michael HaggertyMar 10, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.