Re: What's cooking in git.git (Apr 2014, #03; Fri, 11)
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Apr 13, 2014, 20:18 UTC
- Message-ID
- <534AF118.5040501@alum.mit.edu>
- In-Reply-To
- <xmqq1tx3qzel.fsf@gitster.dls.corp.google.com>
On 04/12/2014 12:22 AM, Junio C Hamano wrote:
Show 35 quoted lines
> [...] > * mh/ref-transaction (2014-04-07) 27 commits > - ref_transaction_commit(): work with transaction->updates in place > - struct ref_update: add a type field > - struct ref_update: add a lock field > - ref_transaction_commit(): simplify code using temporary variables > - struct ref_update: store refname as a FLEX_ARRAY > - struct ref_update: rename field "ref_name" to "refname" > - refs: remove API function update_refs() > - update-ref --stdin: reimplement using reference transactions > - refs: add a concept of a reference transaction > - update-ref --stdin: harmonize error messages > - update-ref --stdin: improve the error message for unexpected EOF > - t1400: test one mistake at a time > - update-ref --stdin -z: deprecate interpreting the empty string as zeros > - update-ref.c: extract a new function, parse_next_sha1() > - t1400: test that stdin -z update treats empty <newvalue> as zeros > - update-ref --stdin: simplify error messages for missing oldvalues > - update-ref --stdin: make error messages more consistent > - update-ref --stdin: improve error messages for invalid values > - update-ref.c: extract a new function, parse_refname() > - parse_cmd_verify(): copy old_sha1 instead of evaluating <oldvalue> twice > - update-ref --stdin: read the whole input at once > - update_refs(): fix constness > - refs.h: rename the action_on_err constants > - t1400: add some more tests involving quoted arguments > - parse_arg(): really test that argument is properly terminated > - t1400: provide more usual input to the command > - t1400: fix name and expected result of one test > (this branch is used by rs/ref-closer-to-atomic.) > > Update "update-ref --stdin [-z]" and then introduce a transactional > support for (multi-)reference updates. > > Is this ready to be merged to 'next' for wider exposure?
Yes, as far as I know there are no outstanding objections to this version (v3) of this series and it is ready for 'next'.
Michael
-- Michael Haggerty mhagger@alum.mit.edu http://softwareswirl.blogspot.com/