All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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

* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.