From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Johannes Schindelin'" <Johannes.Schindelin@gmx.de>,
"'Elijah Newren'" <newren@gmail.com>
Cc: "'Gábor Farkas'" <gabor.farkas@gmail.com>,
"'Git Mailing List'" <git@vger.kernel.org>
Subject: RE: git switch/restore, still experimental?
Date: Wed, 5 May 2021 10:26:59 -0400 [thread overview]
Message-ID: <00af01d741ba$b916a330$2b43e990$@nexbridge.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2105051554250.50@tvgsbejvaqbjf.bet>
On May 5, 2021 10:18 AM, Johannes Schindelin wrote:
>On Tue, 4 May 2021, Elijah Newren wrote:
>> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@gmail.com>
>wrote:
>> >
>> > the "git switch" and "git restore" commands were released two years
>> > ago, but the manpage still says "THIS COMMAND IS EXPERIMENTAL. THE
>> > BEHAVIOR MAY CHANGE.".
>> >
>> > i'd love to use them, but this warning gives me pause, perhaps i
>> > should wait until it stops being experimental, i worry that it might
>> > change in behavior unexpectedly and cause problems for me.
>> >
>> > considering that they were released two years ago, could the
>> > experimental-warning be removed now?
>>
>> This probably makes sense. The author of switch and restore isn't
>> involved in the git project anymore. He decided to work on other
>> things, which was and is a big loss for us. I think others (myself
>> included) didn't know all the things that might have been in Duy's
>> head that he wanted to verify were working well before marking this as
>> good, but these two commands have generally been very well received
>> and it has been a few years. Personally, I'm not aware of anything
>> that we'd need or want to change with these commands.
>
>I think that part of the intention to mark this as experimental was to gather
>feedback about the commands. After all, the goal was to improve the user
>experience of Git (because `git checkout` does too many things, and its major
>accomplishment is to confuse literally every single new Git user).
>
>However, that hope never was fulfilled if I may say so, we simply did not attract
>the best-suited experts to this mailing list, not if what we set out was to improve
>usability.
>
>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.
>I say that neither of them is a really splendid choice because the original goal is
>not only not accomplished, but I would say it is even harder now than it was
>when we accepted switch/restore into an official release, because of that
>experience with switch/restore. We simply do not have the right expertise on
>this list, and therefore anything we do will always have that "UX designed by an
>engineer" feel.
My thoughts anyway.
-Randall
next prev parent reply other threads:[~2021-05-05 14:27 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-04 10:32 git switch/restore, still experimental? Gábor Farkas
2021-05-04 19:54 ` Felipe Contreras
2021-05-05 3:46 ` Elijah Newren
2021-05-05 4:01 ` Eric Sunshine
2021-05-05 11:09 ` Ævar Arnfjörð Bjarmason
2021-05-05 17:46 ` Felipe Contreras
2021-05-05 19:26 ` Sergey Organov
2021-05-05 19:48 ` Sergey Organov
2021-05-06 1:39 ` Junio C Hamano
2021-05-06 15:19 ` Sergey Organov
2021-05-06 10:05 ` Ævar Arnfjörð Bjarmason
2021-05-06 14:29 ` Sergey Organov
2021-05-06 2:16 ` Junio C Hamano
2021-05-06 10:02 ` Ævar Arnfjörð Bjarmason
2021-05-10 11:04 ` Ævar Arnfjörð Bjarmason
2021-05-10 18:27 ` Junio C Hamano
2021-05-06 11:00 ` Felipe Contreras
2021-05-06 15:26 ` Ævar Arnfjörð Bjarmason
2021-05-06 21:55 ` Felipe Contreras
2021-05-10 10:58 ` Ævar Arnfjörð Bjarmason
2021-05-11 7:15 ` Felipe Contreras
2021-05-05 14:18 ` Johannes Schindelin
2021-05-05 14:26 ` Randall S. Becker [this message]
2021-05-06 1:15 ` Junio C Hamano
2021-05-05 17:52 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00af01d741ba$b916a330$2b43e990$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=gabor.farkas@gmail.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).