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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 14, 2008, 16:49 UTC
Message-ID: <alpine.LSU.1.00.0802141648120.30505@racer.site>
In-Reply-To: <47B46C8E.5030905@nrlssc.navy.mil>

Hi,

On Thu, 14 Feb 2008, Brandon Casey wrote:

Show 20 quoted lines

> 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.

And "-M" is always dangerous. Don't use it, if you don't know what you're doing.

AFAIR -M is even _marked_ as a dangerous command.

Ciao, Dscho