Oh, I meant to include the following screen output which results from the double upload:

WARNING: Manually specified base of this CL `wjmMoveManager` doesn't seem to belong to target remote branch `refs/remotes/origin/master`.

If you proceed with upload, more than 1 CL may be created by Gerrit as a result, in turn confusing or crashing git cl.

If you are certain that specified base `wjmMoveManager` has already been uploaded to Gerrit as another CL, you may proceed.

Do you take responsibility for cleaning up potential mess resulting from proceeding with upload? Press Enter to upload, or Ctrl+C to abort

remote: Processing changes: new: 2, done
remote: (W) 751f873: commit subject >50 characters; use shorter first paragraph
remote: (W) 1e5a110: commit subject >50 characters; use shorter first paragraph
remote:
remote: New Changes:
remote:   https://chromium-review.googlesource.com/552579 Move TouchSelectionControllerClientManager interface to content/public
remote:   https://chromium-review.googlesource.com/552580 Expose TouchSelectionControllerClientManager* on RenderWidgetHostView
remote:
To https://chromium.googlesource.com/chromium/src.git
 * [new branch]                1e5a1108b2297fac9a87dd4f22d24f12fe252031 -> refs/for/refs/heads/master%m=Initial_upload,notify=NONE

Error after CL description prompt -- saving description to /usr/local/google/home/wjmaclean/.git_cl_description_backup

If you have your tracking information set up correctly (which you do), specifying "branchA" when uploading branchB is not necessary, and is in fact "dangerous", as you discovered.

The fundamental difference between Rietveld and Gerrit is that Rietveld acts upon textual diffs, while Gerrit acts upon actual git commit objects. When using Rietveld, passing that last argument to "git cl upload" meant "instead of uploading whatever you would upload by default, instead upload the diff between this argument and HEAD". It was literally passed verbatim into "git diff" to produce the patchfile that would be uploaded to Rietveld. Gerrit interprets the argument the same way: you want to upload a change containing just the diff between that argument and your current HEAD. However, since Gerrit deals in git commit objects, that means that it needs the entire history from origin/master to the commit you're uploading. branchA is part of that history, so it must be uploaded. And because you've told it to ignore its normal diff and branch dependency calculations, it just uploads it verbatim. (For example, if branchA consisted of two commits A1 and A2, you could have run "git cl upload --gerrit A1", thereby uploading something totally disconnected from your branch structure.)

This is clearly confusing, and something should be improved. I'm not sure what.

But in the mean time, just don't pass git-diff arguments to git-cl-upload, and it will behave the way you expect.

Ahhh, ok ... thanks for explaining! I didn't realize the second argument would cause these problems (and were in fact unnecessary).

I suppose a possible improvement, since there may be others who arrive at the same problem through remembering the Reitveld days: have git-cl upload warn about this behaviour whenever the extra branch name parameter is included, so the user can decide if this is what they truly want. Just a thought anyways.

git-cl upload does warn about this behavior, it's in the output in your second comment:

"""
WARNING: Manually specified base of this CL `wjmMoveManager` doesn't seem to belong to target remote branch `refs/remotes/origin/master`.

If you proceed with upload, more than 1 CL may be created by Gerrit as a result
"""

Yes, I *did* see that.

I guess my point was, based on my understanding of how git-cl *used* to work, I wasn't expecting this behaviour (a.k.a. I didn't understand the importance of the comment).

I'll go read the manual.