Felipe Contreras [off-list ref] writes:
Sergey Organov wrote:
quoted
Felipe Contreras [off-list ref] writes:
quoted
Sergey Organov wrote:
quoted
Martin [off-list ref] writes:
quoted
On 10/07/2021 12:24, Sergey Organov wrote:
quoted
Martin [off-list ref] writes:
quoted
Actually, "new" or "create" would make sense in "git branch". But in
git switch, they actually raise the question "create what?" / "new
what?".
I believe that's because "git switch" tries to do too much.
"git switch"
should rather switch between existing branches, and do nothing else. As
I said once in this discussion already: trouble writing good
documentation is often indication of some flaws in the design.
Creating (a branch) is fundamentally different operation than switching
to (a branch), and that's why the former doesn't fit into "git switch".
Right, yes. But creating a branch is often followed by switching to it.
Yep, but here the creation is the primary operation, not switching, so
putting this into "git switch" looks like design flaw. These 2 actions
are fine to co-exist in "git branch" = "whatever you want to do to
branches", but not in "git switch" == "wherever you want to switch".
I don't see the logic in here.
git branch topic # here 'branch' is the verb
Not to me. I assumed the "branch" is always a noun in "git branch", and
the actual meaning of this command is:
git branch [create|new] topic
I.e., creation just being the default action taken on the branch.
The question is not what you assumed, the question is can other people
assume otherwise?
Sure they can, and that's part of the problem. I described how *I* see
it, as I try to interpret things as coherently as possible, and I don't
like to interpret "branch" in "git branch" as either noun or verb
depending on options when universal interpretation as noun is
sufficient.
"branch" can be a verb, that's a fact.
Yep, who argues?
My argument is that specifically in "git branch" it could be universally
interpreted as noun, but can't universally be interpreted as verb, so
/for me/ it's noun there.
quoted
quoted
quoted
To me, while the latter is obvious, it's verb and specifies the action
to be performed, the former looks more like "whatever you want to do
with branches", and thus the "branch" is a noun there and the command
thus is object-oriented.
I agree, and I did have indeed noticed the inconsistency. But there's
another category of commands that receive subcommands, like:
git remote $subcommand
git worktree $subcommand
git bisect $subcommand
In my opinion `git branch` fits more these subcommand commands, and it
was a mistake to make the subcommands options, it should be:
git branch list
git branch new
git branch set-upstream
git branch move
...
Now the verb is crystal-clear.
Yes, lacking (assumed) subcommands is yet another dimension of
inconsistencies.
I mean what I'm after is inconsistency of the first argument to "git".
It's being the verb more often is where we currently are, at least when
considering "primary" commands that "git help" outputs.
I mean, consider:
git branch new nice-feature
vs
git new branch nice-feature
It should have been the latter, when in fact it's currently the
[reduced] former.
I disagree. I prefer the former.
git create branch "nice-feature"
Almost plain human language. Isn't it nice? I mean I fail to see why
you prefer the former, but I don't care that much either.
Either way this is way too far from the original point. I don't think
you can convince me that `git new branch` makese sense, but there's no
need for that.
To move forward we need to find consensus, and if you and me agree that
`git branch new` makes sense, that's where we should focus on.
It does make sense, in isolation.
No, I don't think it's an option, as unfortunately for your preferences,
git branch new
looks impossible to introduce in a backward compatible manner, nor there
is significant need to, as
git branch
already does the job, even if by introducing syntax irregularity.
Even standardizing `git branch` would be an almost-impossible task, even
if we manage to convince others. `git new branch` even more
impossible.
Quite an opposite. In fact it's easier to add new ways of doing things
that, provided they prove being useful, eventually obsolete and replace
old ways. "git switch" and "git restore" are recent examples of that.
That's why I started to discuss "git new" that does not yet exist. No, I
don't think it will be there any time soon, as there are more important
things to improve in Git, and then overall consistency of Git command
interfaces is not recognized by the community as a valuable design goal
anyway.
Thus, for foreseeable future we will likely continue to witness hot
discussions of what "looks reasonable" and what not, contenders lacking
common ground that some basic principles of design agreed upon would
have provided.
Thanks,
--
Sergey Organov
Sergey Organov wrote:
Felipe Contreras [off-list ref] writes:
quoted
Sergey Organov wrote:
quoted
Felipe Contreras [off-list ref] writes:
quoted
quoted
quoted
I don't see the logic in here.
git branch topic # here 'branch' is the verb
Not to me. I assumed the "branch" is always a noun in "git branch", and
the actual meaning of this command is:
git branch [create|new] topic
I.e., creation just being the default action taken on the branch.
The question is not what you assumed, the question is can other people
assume otherwise?
Sure they can, and that's part of the problem. I described how *I* see
it, as I try to interpret things as coherently as possible, and I don't
like to interpret "branch" in "git branch" as either noun or verb
depending on options when universal interpretation as noun is
sufficient.
quoted
"branch" can be a verb, that's a fact.
Yep, who argues?
My argument is that specifically in "git branch" it could be universally
interpreted as noun, but can't universally be interpreted as verb, so
/for me/ it's noun there.
Yeah, but universal interpretation is not part of human language.
Context is always relevant.
Sometimes it can be a verb.
quoted
quoted
quoted
I agree, and I did have indeed noticed the inconsistency. But there's
another category of commands that receive subcommands, like:
git remote $subcommand
git worktree $subcommand
git bisect $subcommand
In my opinion `git branch` fits more these subcommand commands, and it
was a mistake to make the subcommands options, it should be:
git branch list
git branch new
git branch set-upstream
git branch move
...
Now the verb is crystal-clear.
Yes, lacking (assumed) subcommands is yet another dimension of
inconsistencies.
I mean what I'm after is inconsistency of the first argument to "git".
It's being the verb more often is where we currently are, at least when
considering "primary" commands that "git help" outputs.
I mean, consider:
git branch new nice-feature
vs
git new branch nice-feature
It should have been the latter, when in fact it's currently the
[reduced] former.
I disagree. I prefer the former.
git create branch "nice-feature"
Almost plain human language. Isn't it nice?
But I'm not talking to a human. If I wast talking to a human I would say
"create a branch called X", and "with git" would be implied.
But there's no "create" binary on my system. Why would there be? I've
been using Linux systems for more than 20 years, I know that if I want
to do something with vim, I have to start the command with 'vim'.
quoted
Even standardizing `git branch` would be an almost-impossible task, even
if we manage to convince others. `git new branch` even more
impossible.
Quite an opposite. In fact it's easier to add new ways of doing things
that, provided they prove being useful, eventually obsolete and replace
old ways. "git switch" and "git restore" are recent examples of that.
That's what *should* be the case, but this discussion proves that even
experimental commands (which are clearly demarcated as experimental) are
hard to change.
Moreover, keep in mind that the person who managed to introduce both
`git switch` and `git resotre` already left the project. That should
give you a pretty good idea of how much faith he has on these commands
eventually being useful.
Sure, at this point in time introducing `git branch new` might be
impossible, however, `git branch --new` isn't. And if we agree on what
should have been the case for `git branch`, then what should be the case
for `git switch` is more attainable.
Cheers.
--
Felipe Contreras
On 13/07/2021 00:58, Sergey Organov wrote:
Felipe Contreras [off-list ref] writes:
quoted
I disagree. I prefer the former.
git create branch "nice-feature"
Almost plain human language. Isn't it nice? I mean I fail to see why
you prefer the former, but I don't care that much either.
But human language is not always the best to express something to a
computer (sometimes not even to a human). Human language for starters is
often very ambiguous. (Not in this particular example, but in general).
So even if it looks like human language, its not (not a "duck" either;) ).
It still needs each token (each word is a token) to be documented.
The "create" vs "new" is a good example.
- "creating" still happens when you add commits into the branch (human
language "branch"). Because that's what the branch wants to be, a series
of commits. You keep creating it, until its done, then you merge it.
- "new" of course is not a verb...
git prepare branch
would probably be more accurate.
But I am sure it has flaws too.
No, I don't think it's an option, as unfortunately for your preferences,
git branch new
looks impossible to introduce in a backward compatible manner, nor there
is significant need to, as
git branch
already does the job, even if by introducing syntax irregularity.
It is not that it already does the job ("git stash push" and "git stash"
both do the job)
But in
git branch new
"new" would be the name of a branch. :(
But at some point, it was indicated that this is about finding
guidelines for future additions.
So not all old commands need to be "fixed".
Not that they are broken. They are fine. We do not need to break them by
adding a rule like that.
And
git noun verb <opts>
git verb <opts>
works as guideline for new additions.
Of course you want to add
git verb noun
which I personally to not favour.