Thread (1 message) 1 message, 1 author, 2021-05-10

Re: git switch/restore, still experimental?

From: Junio C Hamano <hidden>
Date: 2021-05-10 18:28:03

Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
quoted
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
[ref] 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...
cf. <xmqqzgx81x2q.fsf@gitster.g>

"Randall S. Becker" [off-list ref] writes:
quoted
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.
quoted
- 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.
Yeah, I tend to agree with you that the third-choice to improve
switch/restore before we can confidently say they are no longer
"experimental" would be much nicer than giving up on them too early.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help