Add minimal Gerrit support to 'git cl config' and 'git cl upload'

Add minimal Gerrit support to 'git cl config' and 'git cl upload'

This is the bare beginnings of Gerrit support for (non-repo) depot_tools.
The 'git cl config' and 'git cl upload' commands get a -g/--gerrit switch
to tell them to work in a Gerrity way rather than a Rietveldy way.

[M-A Ruel, 2011-12-07 19:21:26]

Are you sure it's the best path to follow?

I think it warrant another tool. The overlap between rietveld and gerrit is
really slim, e.g. shelling out presubmit scripts. I feel it's going to be
excessively confusing for people.

What's the use-case?

http://codereview.chromium.org/8826015/diff/1/git_cl.py
File git_cl.py (right):

http://codereview.chromium.org/8826015/diff/1/git_cl.py#newcode50
git_cl.py:50: GERRIT_FETCH_URL = 'http://git.chromium.org'
No, don't hard code them. If you look again, there is nothing chromium specific
in that file.

http://codereview.chromium.org/8826015/diff/1/git_cl.py#newcode755
git_cl.py:755: parser.add_option('-g', '--gerrit', action='store_true',
It should be automatic, no need for flags.

http://codereview.chromium.org/8826015/diff/1/git_cl.py#newcode891
git_cl.py:891: # It's probably not worthwhile to support different workflows.
It is.

[Roland McGrath, 2011-12-08 18:07:49]

I wasn't trying to make something wonderful.
I was trying to provide something rather than nothing, while not spending a lot
of time on it.  I'd be glad to let infrastructure folks decide what tools we
should have and how to implement them.

So far, we have nothing for people to use for non-repo gerrit cases except
direct "git push" and manual setup of .git/hooks/commit-msg.  This will be a bit
too arcane for all the members of our team who need to use gerrit to deal with. 
We are hosting a few git repositories on gerrit, and figured it made sense to
start using gerrit code review for the newer ones where people don't already
have well-established workflows.

[M-A Ruel, 2011-12-08 18:16:04]

I totally sympathise with you and I'm fine with the idea. It's just I feel
it will be confusing, and since git cl is full of rietveld assumptions, it
doesn't feel like a clean fit. So if you want a minimal tool, I'd prefer it
to have a new name. Otherwise you'll be summoned every time something
breaks in git cl, something you may not want? :) You can import git_cl.py
to reuse parts of it.
Le 8 déc. 2011 13:07, <mcgrathr@chromium.org> a écrit :

> I wasn't trying to make something wonderful.
> I was trying to provide something rather than nothing, while not spending
> a lot
> of time on it.  I'd be glad to let infrastructure folks decide what tools
> we
> should have and how to implement them.
>
> So far, we have nothing for people to use for non-repo gerrit cases except
> direct "git push" and manual setup of .git/hooks/commit-msg.  This will be
> a bit
> too arcane for all the members of our team who need to use gerrit to deal
> with.
> We are hosting a few git repositories on gerrit, and figured it made sense
> to
> start using gerrit code review for the newer ones where people don't
> already
> have well-established workflows.
>
>
http://codereview.chromium.**org/8826015/<http://codereview.chromium.org/8826...
>

[Evan Martin, 2012-01-30 15:51:33]

FWIW, concerns about which way Chrome should be going aside, I think it's fine
for git-cl to support gerrit.  A separate tool will lead to divergent behaviors
down the line (like different flag names) and keeping it as one script helps
avoid that.