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