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. 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
