On 09/07/2021 18:10, Felipe Contreras wrote:
Martin wrote:
As for "git switch -C"
This should IMHO change to (the 2nd arg, actually depends on the point
"1" above)
git switch (-c|-C) <branch-name> [<base-commit>]
I suggest to not call it "new-branch-name" because, it might be an
existing name.
I think the name is all wrong. As Ævar pointed out --new (-n) is much
better. Also it doesn't make much sense to use "create" or "new" for
something that already exists.
The n versus c issue is IMHO separate. Maybe tiny overlaps.
I see it mostly in the light of -c should be for "copy".
On "git checkout" it is "-b" for branch. That works, if you perceive
"branch" as a verb. "The action of branching creates a new branch".
If needs must, that would work as "git switch -b" to.
Actually, "new" or "create" would make sense in "git branch". But in git
switch, they actually raise the question "create what?" / "new what?".
I think you saw a correct issue: `git switch -C` might be used
incorrectly, but changing to the documentation would have limited value
(and only for the ones that read it).
I think if the branch already exists, the user has to be explicit to
what he wants to do and use `git switch --reset <branch> <commit>`
Well, that is the question as what the action is perceived.
I think the example is wrong, rather than the command.
-c / -C /-n / -N always *c*reate an *n*ew branch. (create and new really
are the same thing here)
But if the branch name Foo, is already used?
Well, it will still be a *new* branch being *created*.
To do that it has to remove the name from the old branch. (effectively
removing the old branch).
3)
newbbranch versus new-branch versus new_branch
That is something that just needs to be decided.
"new_branch" is in git checkout.
I'd rather have <branch>, but as I already said, the more ground you try
to cover the more impossible it will be to actually land the changes.
Well ok, if you shorten it to one word that solves it too.
But for anything that for some reason needs two words, IMHO there should
be one style. "one word", "-" or "_".
Currently different styles are mixed.
Look at
git checkout --force
--force
When switching branches, proceed even if the index or the working tree differs from HEAD. This is used to throw away local changes.
All these issues go away if we have:
git switch --reset <branch> <commit>
And instead of -C, we have:
git switch --new --reset <branch> <commit>
This creates a new branch if it doesn't exist, or if it exists resets
it.
Nope it does not go away.
All this has done, is that it no longer is a "force" command.
So the last bit of warning has just gone.
And it still needs to be documented inside the "git switch" doc, rather
than forwarding the user do yet another doc.
Also making the user read the "git reset" doc does not help, unless we
point out that this is a --hard reset, rather than "modifying the index".
I would on that account argue that "git reset --hard/mixed/soft" should
be "force" commands.
And the "git reset" documentation, as well as "git branch -f" / git
checkout -B", also miss the information why they are "force".
It is true, this information can be derived, if one
- knows the concepts (which one should do)
- and actually connects the dots (humans do have a tendency to overlook
things, especially if they are only indirectly referred to)
So, I still ask:
- If "--force" to overwrite the work tree can clearly state that change
to files will be "thrown away".
- Then why can "force" re-using an existing branch name not do the same?
And that is the same, never mind if we call it -C, -B or --reset.
