Hi, Ronnie Sahlberg wrote: > List, please see here an overview and ordering of the ref transaction > patch series. Thanks much for this. [...] > rs/ref-transaction-0 [...] > Has been merged into next. This is even part of "master" now, so if people have review comments then they can make them most easily by submitting new patches on top. > ref-transaction-1 (2014-07-16) 20 commits > ------------------------------------------------------------- > Second batch of ref transactions > > - refs.c: make delete_ref use a transaction > - refs.c: make prune_ref use a transaction to delete the ref > - refs.c: remove lock_ref_sha1 > - refs.c: remove the update_ref_write function > - refs.c: remove the update_ref_lock function > - refs.c: make lock_ref_sha1 static > - walker.c: use ref transaction for ref updates > - fast-import.c: use a ref transaction when dumping tags > - receive-pack.c: use a reference transaction for updating the refs > - refs.c: change update_ref to use a transaction > - branch.c: use ref transaction for all ref updates > - fast-import.c: change update_branch to use ref transactions > - sequencer.c: use ref transactions for all ref updates > - commit.c: use ref transactions for updates > - replace.c: use the ref transaction functions for updates > - tag.c: use ref transactions when doing updates > - refs.c: add transaction.status and track OPEN/CLOSED/ERROR > - refs.c: make ref_transaction_begin take an err argument > - refs.c: update ref_transaction_delete to check for error and return status > - refs.c: change ref_transaction_create to do error checking and return status > (this branch is used by rs/ref-transaction, rs/ref-transaction-multi, > rs/ref-transaction-reflog and rs/ref-transaction-rename.) > > The second batch of the transactional ref update series. > > Has been merged into pu Last reviewed at http://thread.gmane.org/gmane.comp.version-control.git/252226, if I am using gmane search correctly. Are there any pending questions for this part? I've having trouble keeping track of how patches change, which patches have been reviewed and which haven't, unaddressed comments, and so on, so as an experiment I've pushed this part of the series to the Gerrit server at https://code-review.googlesource.com/#/q/topic:ref-transaction-1 It's running a copy of gerrit code review (https://code.google.com/p/gerrit). Maybe this can be useful as a way of keeping track of the state of long and long-lived series like this one. It works something like this: Preparation ----------- Get a password from https://code-review.googlesource.com/new-password and put it in netrc. Install the hook from https://code-review.googlesource.com/tools/hooks/commit-msg to .git/hooks/commit-msg. This automatically populates a Change-Id line in the commit message if none is present so gerrit can tell when you are uploading a new version of an existing patch. (The commit-msg hook can be annoying when not working with gerrit code review. To turn it off, use 'git config gerrit.createChangeId false'.) Uploading patches ----------------- Write a patch series against 'maint' or 'master' as usual, then push: git push https://code.googlesource.com/git \ HEAD:refs/for/master; # or refs/for/maint There can be a parameter '%topic=<name>' after the refs/for/<branch> (e.g., refs/for/master%topic=ref-transaction-1) if the series should be labelled with a topic name, or that can be set in the web UI or using the HTTP API after the fact. Commenting on patches --------------------- Visit https://code-review.googlesource.com. Patches can be found under "All" -> "Open". Patches you're involved with somehow are at "My" -> "Changes". To prepare inline comments, choose a file, highlight the text to comment on or click a line number, and comment. To publish comments, go back up to the change overview screen (using the up arrow button or by pressing "u"), click "Reply", and say something. '?' brings up keyboard shortcuts. Downloading patches ------------------- In the change overview screen, there's a 'Download' menu in the top-right corner with commands to download the patch. Revising patches ---------------- After modifying a patch locally using the usual tools such as rebase --interactive, push again: git push https://code.googlesource.com/git \ HEAD:refs/for/master; # or refs/for/maint When a patch seems polished --------------------------- Get rid of the Change-Id lines --- they shouldn't be needed any more. Send the patches or a request to pull from a public git repository, as usual. A link (in the top-left corner where it says 'Change 1000', the "1000" is a link to the change) can be helpful for letting people on-list see how the patch got into the form it's in today. Maybe it can be useful. Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html