git-branch -m interprets first argument differently when two are supplied

If 'git-branch -m' is supplied one argument, it changes the name of the current branch to the name of the argument.

If two arguments are supplied, then the first argument is interpreted as the branch whose name is to be changed, and the second argument is the name to change it to.

The first non-option argument is interpreted differently depending on whether one argument or two arguments have been supplied.

	git-branch -m [<oldbranch>] <newbranch>

Has anyone considered whether this is inconsistent with how other commands operate?

For example, these commands always interpret the first argument consistently. If a second argument is supplied, it modifies the base or the reference from which to run the command.

	git-rebase <upstream> [<branch>]
	git-cherry <upstream> [<head>] [<limit.]
	git-tag <name> [<head>]
	git-update-ref <ref> <newvalue> [<oldvalue>]

or even

	git-branch <branchname> [<start-point>]

It's hard to describe, but I have learned to think about the ordering of arguments (especially for rebase and cherry), by thinking about how the single argument case would operate. For rebase, if only one argument is supplied, you know that the thing you are rebasing is the current branch, that's the only way it makes sense.

If I am _not_ on the branch I want to rebase, it may be tempting to think that rebase works like:

	rebase <this> <on_to_this>

So if I am not on the branch, I think about how arguments would be supplied if I _were_ on the branch I wanted to rebase. Then it is clear how to specify the branch I want to rebase, namely that <this> should be the second argument.

For 'git-branch -m', this relationship is broken. So I can't think "How would this operate if I were on the branch whose name I'd like to change", and then append the name, since when two arguments are supplied the new branch name is the _second_ argument.

I guess maybe

	git-branch -m <oldname> <newname>

is supposed to work like

	mv <oldname> <newname>

but then the same could be said about the others too.

	rebase <this> <on_top_of_this>
	cherry <whats_in_here> <but_not_in_here>
	...

I'm not suggesting we change the 'branch -m' behavior, just pointing out that it seems inconsistent and broke my git intuition. Maybe someone can point out a thinko on my part.

-brandon