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


It's running a copy of gerrit code review

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

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

'?' 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.

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

Reply via email to