Felipe Contreras [off-list ref] writes:
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.
git switch topic # here 'switch' is the verb
Yep.
Now, if you want to do both at the same time the logical options are:
git branch --switch topic # here '--switch' is an adverb
git switch --new topic # here '--new' is an adverb
Yes, we can (and do) shove it into the "git switch", but "git new" would
be better design.
The former reads like gibberish to me: "git, branch off in a 'switch'
way".
The latter makes perfect sense: "git, switch to a branch in a 'new' way".
quoted
Logically, there could be something like "git new" that does create a
branch and then switches there by default, or something like that, say:
git new feature3 --at origin/rc-2 --track
Here the the verb is clear, but not the direct object, a "new" what?
Couldn't it be a tag? Or a commit? Or a remote? Or a worktree? Or a
bisect? Or a submodule?
Yes, it could be anything. The above is written in an assumption that
default object for "git new" is branch.
It's too ambigous.
Yep. The explicit mode should have been:
git new branch feature3 --at origin/rc-2 --track
quoted
And while we are at it, do you guys notice how 2 concepts are mixed in
Git commands? I mean, the interface seems to mix object-oriented and
action-oriented commands, most of commands being action-oriented with
only a few unfortunate exceptions.
Let me try a short survey:
1. In
git branch ...
is "branch" a noun or a verb?
Both.
No, it's rather noun plus lacking subcommand, sometimes making it look
like verb :)
quoted
2. In
git merge ...
is "merge" a noun or a verb?
Verb.
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.e., I'm in favor of universal:
git <command> ...
syntax to Git commands where <command> specifies an action. [Why things
tend to drift to Lisp all the time, I wonder?]
From that POV, for the commands you mentioned, "git bisect" is probably
fine, whereas "git worktree", and "git remote" should better be split to
operations on them, e.g.:
git new remote
git new worktree
Once that is regularized, we may as well consider allowing for inverse
order of the first 2 arguments, by making
git new remote
git remote new
the synonyms.
It doesn't mean we need to rewrite everything. Having an end-goal
specified though, we may design new features accordingly, and add
commands in preferred syntax for existing features, so that they
eventually obsolete the current status quo.
Thanks,
--
Sergey Organov
On 11/07/2021 11:04, Sergey Organov wrote:
Felipe Contreras [off-list ref] writes:
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:
Well, it is easy to see it as a noun. But for "branching" creation of a
branch, it can be seen as verb.
Yet in
git branch --list
it definitely is a noun.
But then how would/should those work?
The action/verb is "list" or "show"
git show branches
git show tags
git show ...
That completely tears apart related topics.
Or is it enough if the subcommand is a verb?
git branch create
git branch list
That be ok for me.
quoted
quoted
is "branch" a noun or a verb?
Both.
No, it's rather noun plus lacking subcommand, sometimes making it look
like verb :)
As is
git stash
for
git stash push
And I should guess lots of people like the short form....
I.e., I'm in favor of universal:
git <command> ...
syntax to Git commands where <command> specifies an action. [Why things
tend to drift to Lisp all the time, I wonder?]
Because humans are more about the "things".
The way we interact is more ofter derived from the object, than the
object being purposefully made for an interaction?
From that POV, for the commands you mentioned, "git bisect" is probably
fine, whereas "git worktree", and "git remote" should better be split to
operations on them, e.g.:
git new remote
git new worktree
That also makes documentation harder. People who want a worktree, want
the documentation for it in one place.
So a manpage for "git new" is not desirable. It would have to be split
into the manpages for the objects. But that is not good either, or is it?
Once that is regularized, we may as well consider allowing for inverse
order of the first 2 arguments, by making
git new remote
git remote new
the synonyms.
Having even more ways to do one and the same thing....
Btw, missing from the discussion:
git log
"log" can be a verb, but not in the above.
Because "to log" is to write something into a log.
But "git log" is to show (i.e. read) the log.
Sergey Organov wrote:
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?
"branch" can be a verb, that's a fact.
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.
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.
Even standardizing `git branch` would be an almost-impossible task, even
if we manage to convince others. `git new branch` even more impossible.
--
Felipe Contreras
On 12/07/2021 18:24, Felipe Contreras wrote:
Sergey Organov wrote:
Even standardizing `git branch` would be an almost-impossible task, even
if we manage to convince others. `git new branch` even more impossible.
Not sure but from the glance at hg that I took, they seem to use the
plural for nouns.
So then we could have
git branch <new-branch-name>
git branches new // long version
git branches list
git branches delete
....
However, standardizing to a fixed verb/noun rule will still be more than
a challenge.
The above would as guildeline be
git verb
or
git plural-noun verb
Yet try to do that with
git status
git log
I don't see how a better alternative for those can be found. One that
actually is accepted because it's better, not just because it follows a
rule.
status, is not a verb
log is the wrong verb, or again a noun.
Martin wrote:
On 12/07/2021 18:24, Felipe Contreras wrote:
quoted
Sergey Organov wrote:
Even standardizing `git branch` would be an almost-impossible task, even
if we manage to convince others. `git new branch` even more impossible.
Not sure but from the glance at hg that I took, they seem to use the
plural for nouns.
So then we could have
git branch <new-branch-name>
git branches new // long version
git branches list
git branches delete
....
However, standardizing to a fixed verb/noun rule will still be more than
a challenge.
The above would as guildeline be
git verb
or
git plural-noun verb
I don't see what's wrong with considering the second form a subcommand:
git $subcommand $verb
Like `git bisect start`. That way you could consider `branches` to be a
subcommand, it doesn't need to be a plural noun.
Yet try to do that with
git status
git log
I don't see how a better alternative for those can be found. One that
actually is accepted because it's better, not just because it follows a
rule.
status, is not a verb
log is the wrong verb, or again a noun.
If `git branch` is a shorthand for `git branches new`, the you could
consider `git status` to be the a shortcut for `git status show`, but
since there's no other action to be done with the status subcommand,
then it's always implied.
--
Felipe Contreras