Re: git switch/restore, still experimental?

>>> It would have been a stronger argument to favor --new if we had "git
>>> branch --new <branchname>", but that is not the case.
>>
>> The argument is that switch's experimental design squats on 2x other
>> options, so changing -c to -n so we can make -c and -m do the same thing
>> is better.
>
> Whatever the merit of the argument I'm putting forward here, it would be
> useful to get some idea of whether you'd be categorically opposed to
> changing the interface of switch/restore in breaking ways even though
> they've been marked as "THIS COMMAND IS EXPERIMENTAL".
>
> Of course any series to implement what I suggested in
> <877dkdwgfe.fsf@evledraar.gmail.com> would need to stand on its own
> merits.
>
> I'm not planning on working on that since I expect the response will be
> at best "neat, but that ship has sailed", but if that's not the case...

>>Which leaves us with two hard choices regarding switch/restore, none of them
>>really being comfortable:
>>
>>- we scrap switch/restore because their usability is not really all that
>>  improved relative to `git checkout`.
>
> Please do not do that. Switch/restore is much easier to understand
> for new users. The semantics are also more consistent with what
> others have done with git over the years anyway (EGit as an
> example). I have users who have transitioned because the commands
> make sense. They have not hit any missing bits in their workflows.
>
>>- we leave switch/restore as-are (because by now, changing the options or
>>  the design would be almost certainly disruptive to users who already
>>  tried to adopt the new commands, I being one of those users).
>
> I think we should work on the commands to cover between them
> (well... and reset) to functionally cover what checkout
> does. Leaving them as-is, I think is not a viable option. People
> do know these are experimental and not to use in scripts - we can
> hope anyway.