Ronnie Sahlberg <sahlb...@google.com> writes:
> List, please see here an overview and ordering of the ref transaction
> patch series.
> These series build on each other and needs to be applied in the order
> listed below.
> This is an update.
> Early part of the "ref transaction" topic.
> * rs/ref-transaction-0:
> refs.c: change ref_transaction_update() to do error checking and
> return status
> refs.c: remove the onerr argument to ref_transaction_commit
> update-ref: use err argument to get error from ref_transaction_commit
> refs.c: make update_ref_write update a strbuf on failure
> refs.c: make ref_update_reject_duplicates take a strbuf argument
> for errors
> refs.c: log_ref_write should try to return meaningful errno
> refs.c: make resolve_ref_unsafe set errno to something meaningful on
> refs.c: commit_packed_refs to return a meaningful errno on failure
> refs.c: make remove_empty_directories always set errno to something sane
> refs.c: verify_lock should set errno to something meaningful
> refs.c: make sure log_ref_setup returns a meaningful errno
> refs.c: add an err argument to repack_without_refs
> lockfile.c: make lock_file return a meaningful errno on failurei
> lockfile.c: add a new public function unable_to_lock_message
> refs.c: add a strbuf argument to ref_transaction_commit for error
> refs.c: allow passing NULL to ref_transaction_free
> refs.c: constify the sha arguments for
> refs.c: ref_transaction_commit should not free the transaction
> refs.c: remove ref_transaction_rollback
> Has been merged into next.
I gave a quick re-read-thru on this and did not find anything
questionable, nor recall any issue pending. Unless somebody
objects in the coming few days, let's move it to 'master' as part of
the first batch for 2.2.
> ref-transaction-1 (2014-07-16) 20 commits
> The second batch of the transactional ref update series.
> Has been merged into pu
> rs/ref-transaction (2014-07-17) 12 commits
> The third and final part of the basic ref-transaction work.
> Has been merged into pu.
I'll re-read these two before deciding to merge them to 'next'. Any
pending issues from the previous discussions?
> This series is for once the previous transaction changes are in and
> this series will add
> a new backend for refs: refs-be-db.c which offloads all refs access to
> an external database daemon.
> An example reference implementation for an external daemon is also
> provided and can be used as basis for
> creating a daemon to plug into, say, a SQL database or similar.
A filesystem based backend/external daemon that is compatible with
the traditional on-disk format might be another fun demonstration.
Looking forward to shepherding the whole thing ahead ;-) The most
fun part awaits us but there is a long way.
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