On Thu, May 06 2021, Felipe Contreras wrote: > Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> >> > I mean, I see why. You don't want a typo of "master" as "maaster" to >> > create a new "maaster" branch, so really that's out. But it really >> > should be: >> > >> > # -n or -N for --new / --new --force (the latter just in case of a >> > # race, and just for consistency) >> > git switch -n doesnotexist >> >> I do not see why --new is better than --create; > > I do. Different languages equal different minds. > > New in this context is an adjetive: it is a modifier of a noun, in this > case, a branch. > > Create is a verb; it's an action. > > Linguistically speaking they could not be more different. > > > You don't do two verbs at a time. Either you sleep, or you eat, but you > don't do both. Similarly you don't switch and create. Doesn't make > sense. > > If you use natural language: > > 1. Git, switch to a new branch > > 2. Git, switch, create, branch > > One of these simply flows, the other is complete gibberish. I think > anyone familiar with English can identify which is which. Well, there's "Git, create a new branch and switch to it" Also, there's the verb "make" in common use in git's command set e.g. git-mktag, git-mktree, as well as mkdir(1), mkfifo(1) etc. Perhaps we'd be better off with a git-mkbranch in this case & leave "git branch" as an interrogation/change command. In any case, unless we're talking about rewamping git's entire command set (e.g. having a git-newtree or whatever) I'd like to think that it's more productive to focus on making the commands/switches we have internally consistent when possible, which is what I'm advocating in the E-Mail that started this sub-thread.
