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

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Feb 14, 2008, 16:30 UTC
Message-ID: <47B46C8E.5030905@nrlssc.navy.mil>
In-Reply-To: <47B3EFC4.1020808@viscovery.net>

Johannes Sixt wrote:

Show 12 quoted lines

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

I was thinking that -M should print a message describing what it is going to do, and prompt the user for confirmation. A new option could be added to suppress this behavior like -q. Or we could reuse -f, but see below.

While I'm looking at git-branch, I think the capital forms are unnecessary. We have a -f (force) option, so I think it makes more sense to deprecate the captital forms(not remove them), and interpret -f along with -m or -d to provide the same functionality. Again, with the behavior described above for confirmation with something like -q.

Oh, and I wouldn't mind switching the arguments around after we have the confirmation implemented. :)

-brandon