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

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Feb 14, 2008, 17:17 UTC
Message-ID: <47B477B8.5030209@nrlssc.navy.mil>
In-Reply-To: <alpine.LSU.1.00.0802141648120.30505@racer.site>

Johannes Schindelin wrote:

Show 24 quoted lines

> Hi,
> 
> On Thu, 14 Feb 2008, Brandon Casey wrote:
> 
>> Johannes Sixt wrote:
>>> Brandon Casey schrieb:
>>>> 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?
>>> Funny, I fell into this trap just yesterday and accidentally renamed
>>> my master branch to something else. IMO git-branch -m should take two
>>> arguments. Full stop.
>> Actually, I think the single argument case is unambiguous and I would
>> rather not give it up.
>>
>> It's the two argument case that both expects its arguments in a 
>> different order than other commands _and_ is dangerous in the case of 
>> -M.
> 
> The order was specifically requested, as "mv" also has that order.

Did you even read the original message? You point this out like it hasn't already been mentioned.

The _point_ is that the order is _different_ than the order that other _git_ commands use. I give more weight to the relationship with other git commands than to the relationship between the '-M' option and the 'mv' command. A subcommand named 'mv' could have been used if a strong relationship was supposed to be implied, something like 'git-branch mv <src> <dst>'. I'm not sure the single argument case would have retained its intuitiveness in this case.

> And "-M" is always dangerous.

>Don't use it, if you don't know what you're
> doing.

Gee, thanks for the advice.

-brandon