From: Felipe Contreras <felipe.contreras@gmail.com>
To: i o <lvsil4@outlook.com>,
Felipe Contreras <felipe.contreras@gmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Proposal: adding --soft and --mixed options to git checkout
Date: Thu, 27 Apr 2023 15:10:13 -0600 [thread overview]
Message-ID: <644ae4b537ec2_7f4f2949@chronos.notmuch> (raw)
In-Reply-To: <DB9PR09MB6506FD114211F3806C48954AB0649@DB9PR09MB6506.eurprd09.prod.outlook.com>
i o wrote:
> Felipe Contreras wrote:
> > In my opinion it's pretty clear `--soft` and `--mixed` were terrible names and
> > I suggested in the past to rename them to `--no-stage` and `--stage` [1]. We
> > should not repeat those mistakes with `git checkout`.
>
> No problem with renaming, but this might also be an oppurtunity to reconsider
> the meaning of the two options to incorporate `--keep-index`. Maybe
> `--no-stage` should mean 'switch HEAD and the working tree but leave the
> staging area' (i.e. the equivalent of `--keep-index`), and `--no-work` should
> mean 'switch HEAD and the staging area but leave the working tree' (i.e. the
> equivalent of `--mixed`). `--soft` could then be achieved by combining these
> options: `--no-stage --no-work`, but it could be a worthwhile convenience to
> add a separate option for that (just moving the HEAD), so maybe `--head` or
> something like that.
Of course, many options could be considered, but unfortunately the outcome will
be the same regardless of the consensus: no change will happen. As you can see
that's what happened in that previous thread, regardless of the overwhelming
consensus.
> > In my mind the whole point of `git checkout` is to update the work-tree, if the
> > command is not going to do that, then I don't think it should be `git
> > checkout`.
>
> I suppose something similar could also be said about `git reset` though?
I don't know. To me `git reset` is too vague. Resetting what? The "HEAD"? That
to me has no meaning whatsoever, as "HEAD" is git-only semantic invention that
roughly translates to "the current branch" (but not quite).
So with `git reset` we are "resetting the current branch"? That doesn't tell me
much.
> Maybe this would support the general move away from those legacy commands
> towards the new set of commands, so putting these new options in `git switch`
> instead seems reasonable.
I would rather change the semantics of `git checkout` and `git reset` but that
seems rather impossible.
So yeah, I would focus on what has a remote chance of actually get done.
Cheers.
--
Felipe Contreras
prev parent reply other threads:[~2023-04-27 21:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 11:41 Proposal: adding --soft and --mixed options to git checkout i o
2023-04-24 21:32 ` Felipe Contreras
2023-04-25 9:28 ` i o
2023-04-27 21:10 ` Felipe Contreras [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=644ae4b537ec2_7f4f2949@chronos.notmuch \
--to=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=lvsil4@outlook.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.