On 11/07/2021 01:18, Felipe Contreras wrote:
That's OK, and in fact I can see how '--reset --new' is clunky, I'm just
saying it is a possibility. But the main point is that something like
`git switch --reset` is missing, although `git switch --move` would
probably do the trick.
How would "git switch --reset" be different from "git switch -N" ?
"--move" is problematic.
- it reminds me of moving the commits. I.e. rebase.
- it actually stands for "rename" (in git branch -m).
The apparent idea: "move the branch under a new name"
But the branch (base..head) itself stays where it is.
"rename" would be so much more intuitive to me.
At least I can say, if I use "-N", I want a *new* branch. I don't care
about any old branch under that name.
Right, I would as well, but in fact I would expect the same from -n
(although I can see how a newbie might not).
That's why we have to keep in mind that -N is really --force-new.
A non-force option should not lead to data loss.
Or if something can be lost, then "force" needs to be used.
If the branch-name already points to a branch then of that branch, you
stand to loose:
- the branch boundaries (base..head)
- in some cases, (some of) the commits hold by it.
So by convention a simple "-n" is protecting me from that.
IMHO that should be expected.
Also "--reset" does not have the same alerting properties to me, as
"force" or "discard" have.
This may be my English, but to me "reset" does not have the same
alerting property.
OK, maybe it's a language issue. I'm not a native English speaker, my
mother tongue is Spanish, but I'm pretty sure my understanding of
"reset" is what most people understand: set again.
I am German. And yes "set again" (sometimes "restart", but that does not
matter here)
If a branch is set, as base and head. Then "reset" means to set those
two again.
"set again" => They will still be there.
(changed indeed, but there)
The commits hold by that branch, are not "set again".
They may become unreachable.
The word "reset" gives no indication on knock on effects.
However, I prefer if those effects are made clear.
> meriam webster
Quite some of the examples are "put back into working order"
(broken leg / circuit breaker => reset does not loose anything)
Others are restart (at zero) "reset an odometer".
To me personally the emphasis is the "start again", the loss of the
previous value is a side effect.
Maybe others will take see "loss" part as more prominent.
The question then is, how many might not be that wary of the potential loss?
So *if* --force was not an alias for --discard-changes, then this would
make sense:
git switch --new --force topic
It would _force_ the creation of a _new_ branch called "topic".
Is this close to what you are thinking?
No, again no. I said "I want them to be separate force flags"
As long as we have the unspecific "--force" this must be limited to
event *not* triggered by added options.
That is
git switch foo
is not forceful, therefore not allowed to destroy data.
Hence it can not overwrite local changes.
So --force applies to that.
Now if you were currently detached, and made new commits while detached,
then
git switch foo
would loose those commits.
Hypothetical, that could require force.
And like the first example it is part of the default behaviour. No
options are given.
But then using the same --force to force something else would be bad.
So then we need --force-discard-local-changed and
--force-unlink-detached-commit
git -n newbranch commit
is not default behaviour. It is triggered by the -n option.
If this endangers any data (other than what is covered by default
cases), then this always needs its own force.
And it has --force-new
It is possible, but I dislike it very much to define that
--force affects the next option that follows.
So that, thin is -N
git switch --force --new
But those are not
git switch --new --force
git switch --force - --new // the single dash separates the force
I do not like that idea...
