Another option is to put this in a commit hook to catch at git commit time (again, unless explicitly disabled somehow).

Could Gerrit be configured so that it creates the CL but doesn't send the
email when something get pushed? Then one has the opportunity to check the
CL before sending it out.

That will also make it easier to experience and test the review command.
Right now I can't test the mail part because that will unnecessarily spam
golang-codereviews mailing list.

Or could we set up a dummy go repo for testing purposes (even on a separate
testing gerrit instance)? We can configure that to not send emails to the
mailing list and only to the author of the change. It will definitely help
people to get familiar with the tools and file feature requests and bug
reports.

I'd like to preserve the ability of git mail (or a later git upload) to push a branch with multiple commits. I'm fine with it being prohibited by default. Perhaps we could add a --series or --multiple flag to mail/upload which then permits more than 1?

mail already has a -f flag. Maybe it could be used to force this too. Or is
it better to have an explicit flag?

On 13 December 2014 at 07:46, Brad Fitzpatrick notifications@github.com
wrote:

I'd like to preserve the ability of git mail (or a later git upload) to
push a branch with multiple commits. I'm fine with it being prohibited by
default. Perhaps we could add a --series or --multiple flag to
mail/upload which then permits more than 1?

—
Reply to this email directly or view it on GitHub
#9291 (comment).

After c3e5818 "git mail" complains if there are multiple pending CLs, and the user needs to explicitly pass the change to mail. It seems to cover the original issue (mail would ask which change, and the user could notice there are two), and permits pushing multiple commits (just pass the tip of the branch).

Should we close this?

@rsc @adg ^