Add support for Gerrit review system

[Spredzy]

This commits add supports gerrit system and will submit a review
everytime a change is made on the same branch.

The modulesync.yml file looks like

---                                                                                                                                                              
namespace: stackforge
git_base:  ssh://jdoe@review.openstack.org:29418/
branch: msync_foo
branch_prefix: HEAD:refs/publish/master/
pre_commit_script: openstack-commit-msg-hook.sh

When a user receive a -1, the user can simply re-run msync update --amend and a new patchset will be submited

[claytono]

Thanks for working on this! Other than a few long lines, it looks ok to me, but I'll defer to others with more experience on modulesync internals.

[Spredzy]

@cmurphy would you agree that I pass the options hash instead of passing each items separately? cc @Dvorak

[cmurphy]

These two lines are extremely problematic and unnecessary. They cause the script to amend the latest commit rather than making a new commit, when the previous commit is likely to be a change already in master and not owned by the committer.

[cmurphy]

I'm a little frustrated that gerrit must be treated so differently...but looking at your changes and playing with git-review a bit, I think perhaps it doesn't have to be treated so differently.

I propose that instead of a 'git_provider' parameter, we instead just need a 'pre_commit_script' parameter. We can maybe have a 'contrib/' or 'scripts/' directory that contains something to check for the existence of and install the commit-msg hook. Right before repo.commit, we can run the script to install the hook. The user can supply a gerrit-style git_base parameter already, as well as supply 'refs/publish/master/branchname' as the branch name. We can add documentation to make this easier. There isn't any need, as far as I can see, to explicitly amend commits, as the pre-commit hook will do that automatically.

What do you think?

[Spredzy]

@cmurphy this PR has been reworked with the following changes :

• Unification of parameter: Only the git_base parameter is now used, default being git@github.com: (no more git_user, git_provider_address)
• Creation of the contrib/ folder: As suggested using a contrib/ folder for pre_commit_script. In the case of review.openstack.org, it will bring the commit-msg hook directly from review.openstack.org (ie. openstack-commit-msg-hook.sh)
• New command available --amend and --amend --force : In a system of review (like gerrit) msync update --amend will be enough to create a new patchset, in a system like github, the user will have to explicitly specify --amend --force

I hope all the point abode have been addressed

[claytono]

Would it make sense to just remove the --amend option entirely and have the pre-commit script check if the change already includes a Change-ID and add it (amend) if it's not there? If someone is using Gerrit, then that's very likely the behavior they want, and they can modify the pre-commit script if not.

[cmurphy]

Instead of branch and branch_prefix could we have branch (which would be the local branch) and remote_branch (which would default to the value of branch)? That way the push looks like git push origin localbranchname:remotebranchname, so they could potentially have different names and we don't need to refer to HEAD:.

[cmurphy]

@Spredzy looking good! A couple more notes.

@Dvorak I'd prefer not to have --amend be implicit, as it has the potential to be destructive. Moreover, as much as possible, I'd like to not have to treat gerrit or any other git providers as special. Adding the --amend and --force options make them available to github/gitlab/gitolite users. In any case, if you were doing it by hand you would use --amend anyway, so I don't think it's a big deal to require it here.

[cmurphy]

Do we need to set this to nil? I've had a lot of cases where amending the commit also means changing the commit message.