From: Felipe Contreras <email@example.com> To: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org>, "Felipe Contreras" <email@example.com> Cc: "Junio C Hamano" <firstname.lastname@example.org>, "Elijah Newren" <email@example.com>, "Gábor Farkas" <firstname.lastname@example.org>, "Git Mailing List" <email@example.com> Subject: Re: git switch/restore, still experimental? Date: Tue, 11 May 2021 02:15:24 -0500 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Ævar Arnfjörð Bjarmason wrote: > On Thu, May 06 2021, Felipe Contreras wrote: > > First of all, I think we're in rather violent agreement about the real > matter at hand here, and are at best talking about the design of the > keychain for the bikeshed... Indeed. The design of the hypothetical keychain for future bikesheds. > > Which command is that? > > > > git create branch --checkout? > > > > I'm following the order of the words from left to right. > > I'm just pointing out that git in general and certainly not the *nix > tradition it follows tries to make commands readable in anything like > English sentence order. If you attempt to read "log", "status", "rebase" > etc. commands like that you'll at best end up sounding somewhat like > Yoda. Right, but git is infamous for having a UI that leaves a lot to be desired. I'm less concerned about the status quo of git's UI than I am of what could be. Inertia is something that just can't be ignored on commands that people have been using for 15 years. My point is that new commands should not follow the inertia of old commands, especially when we know that historically the UI is the thing that needs more improvements. In fact, we should do the *opposite*. It's the less-than-stellar UI that created the need for switch/restore in the first place. > > In this case however we have a rare occasion in which both consistency and > > natural language meet, we should not squander it. > > > > In fact, to be even more consistent we could add a -n option to git > > branch, which would be reduntant but more explicit, like --list. > > Indeed, I agree with all of that. I.e. we should move to "switch" to > "-n" instead of "-c" etc., and add a "-n" to "branch" for > consistency. After all that's my upthread proposal... > > I just don't think it's worth trying to make the argv readable as a > sentence, even if we had no backwards compatibility to worry about. Well, we would need to look at particular examples to see if the counter-examples make more sene or not. Either way my contention is that it doesn't hurt. I will take a look at switch/restore and see if a linguist approach gives more low-hanging fruit. Fortunately none of that matters for your particular proposal which is just good. Cheers. -- Felipe Contreras
next prev parent reply other threads:[~2021-05-11 7:15 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-04 10:32 Gábor Farkas 2021-05-04 19:54 ` Felipe Contreras 2021-05-05 3:46 ` Elijah Newren 2021-05-05 4:01 ` Eric Sunshine 2021-05-05 11:09 ` Ævar Arnfjörð Bjarmason 2021-05-05 17:46 ` Felipe Contreras 2021-05-05 19:26 ` Sergey Organov 2021-05-05 19:48 ` Sergey Organov 2021-05-06 1:39 ` Junio C Hamano 2021-05-06 15:19 ` Sergey Organov 2021-05-06 10:05 ` Ævar Arnfjörð Bjarmason 2021-05-06 14:29 ` Sergey Organov 2021-05-06 2:16 ` Junio C Hamano 2021-05-06 10:02 ` Ævar Arnfjörð Bjarmason 2021-05-10 11:04 ` Ævar Arnfjörð Bjarmason 2021-05-10 18:27 ` Junio C Hamano 2021-05-06 11:00 ` Felipe Contreras 2021-05-06 15:26 ` Ævar Arnfjörð Bjarmason 2021-05-06 21:55 ` Felipe Contreras 2021-05-10 10:58 ` Ævar Arnfjörð Bjarmason 2021-05-11 7:15 ` Felipe Contreras [this message] 2021-05-05 14:18 ` Johannes Schindelin 2021-05-05 14:26 ` Randall S. Becker 2021-05-06 1:15 ` Junio C Hamano 2021-05-05 17:52 ` Felipe Contreras
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: git switch/restore, still experimental?' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).