Re: Naming the --forec option [[Re: PATCH: improve git switch documentation]]

From: Martin <git@mfriebe.de>
Date: Jul 11, 2021, 00:39 UTC
Message-ID: <e9c2b9cd-edfb-cbed-9638-382a6b0da59b@mfriebe.de>
In-Reply-To: <60ea2ad64878_2a692084e@natae.notmuch>

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.

Show 6 quoted lines

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

Show 8 quoted lines

>> 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?

Show 9 quoted lines

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