From: Emily Shaffer <nasamuffin@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Benji Fisher <benji@fisherfam.org>, git@vger.kernel.org
Subject: Re: [PATCH] MyFirstContribution: use switch for changing branches
Date: Tue, 9 Apr 2024 09:36:27 -0700 [thread overview]
Message-ID: <CAJoAoZmBvkVzP2i=BEgZ9fEcQFHtPkh4pPHm4hj_U5AUqKQFFw@mail.gmail.com> (raw)
In-Reply-To: <xmqqwmp61poj.fsf@gitster.g>
On Tue, Apr 9, 2024 at 9:11 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Benji Fisher <benji@fisherfam.org> writes:
>
> > I was under the impression that the new "git switch" and "git restore"
> > commands were recommended in most cases instead of "git checkout".
>
> These two were added so that eventually we have something we can
> recommend to new users, but as a pair of experimental commands, we
> reserve the rights to update their UI in backward incompatible ways
> (meaning: those who use them may need to retrain their fingers and
> update their scripts if they used them---not that using these
> Porcelain commands in scripts is a good idea to begin with).
>
> So your justification could be
>
> We want to evantually be able to recommend restore/switch to new
> users, and want to take advantage of every opportunity to polish
> them.
>
> Because this document is not exactly for totally new users, and
> the readers are expected to be knowledgeable enough and highly
> motivated in improving git, let's have them use these
> experimental commands and report newbie-issues they found using
> them, so that we can gain more experience and chances to polish
> the command and eventually make them recommendable to new users.
>
> Note that the "WHY?" in my response was not "I see no reason to do
> this", but "You need to say why you think this is a good idea here
> in the proposed commit log message". Without your version of
> reasoning, my conclusion was "I do not see a point", but with a
> justification like this (there could be others---it is contributor's
> job to explain why a proposed change is a good idea, not mine), I
> can understand the reasoning why this change may be a good one.
For what it's worth, when I wrote this doc I was new enough to hacking
Git that I did not know about the new experimental commands ;) or else
I would have used them. I am not opposed to pointing them out in this
doc as part of general evangelism towards a nice UX improvement (and
that could be good justification for the commit message, if you agree,
Benji).
- Emily
prev parent reply other threads:[~2024-04-09 16:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-07 21:21 [PATCH] MyFirstContribution: use switch for changing branches Benji Fisher
2024-04-08 17:42 ` Junio C Hamano
2024-04-09 12:26 ` Benji Fisher
2024-04-09 13:47 ` Kipras Melnikovas
2024-04-09 16:11 ` [PATCH] MyFirstContribution: use switch for changing branches Junio C Hamano
2024-04-09 16:36 ` Emily Shaffer [this message]
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='CAJoAoZmBvkVzP2i=BEgZ9fEcQFHtPkh4pPHm4hj_U5AUqKQFFw@mail.gmail.com' \
--to=nasamuffin@google.com \
--cc=benji@fisherfam.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 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).