From: Felipe Contreras <felipe.contreras@gmail.com>
To: i o <lvsil4@outlook.com>, "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Proposal: adding --soft and --mixed options to git checkout
Date: Mon, 24 Apr 2023 15:32:50 -0600 [thread overview]
Message-ID: <6446f5824dd5d_cd6129459@chronos.notmuch> (raw)
In-Reply-To: <PA4PR09MB65161C38AEFBC07B3D7A1C62B0679@PA4PR09MB6516.eurprd09.prod.outlook.com>
i o wrote:
> I suggest adding `--soft` and `--mixed` options to `git checkout`, that act
> similarly to the corresponding options of `git reset`, i.e. `git checkout
> --soft <tree-ish>` should move the HEAD to <tree-ish> without affecting the
> working tree or index, and `git checkout --mixed <tree-ish>` should move the
> HEAD to <tree-ish> and update the index to match it without changing the
> working tree.
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`.
If the new options were:
* git checkout --no-stage
* git checkout --no-work-tree
I think it would be pretty clear what is intended without explanation (as
opposed to `--soft` and `--mixed`).
> The difference between this and `git reset` of course would be that, unlike
> the latter, this doesn't 'drag' the current branch along with HEAD; instead
> the usual behaviour would apply depending on what exactly <tree-ish> is, i.e.
> `git checkout [--soft|--mixed] <commit>` would detach HEAD and point it to
> <commit>,
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`.
In theory all these three would do the same, correct?
* git checkout --no-stage --no-work-tree <commit>
* git reset --no-stage --detach <commit>
* git update-ref --no-deref HEAD <commit>
My preference would be `git reset --no-stage --detach <commit>`.
> whereas `git checkout [--soft|--mixed] <branch>` would move HEAD
> and switch from the current branch to <branch>.
If we are going to switch the current branch, then `git switch` makes more
sense:
* git switch --no-stage <branch>
Then, for the case of a commit we could do:
* git switch --no-stage --detach <commit>
The advantage of limiting ourselves to `git switch` is that it doesn't have the
historical of `git checkout`/`git reset`.
Cheers.
[1] https://lore.kernel.org/git/20130829180129.GA4880@nysa/
--
Felipe Contreras
next prev parent reply other threads:[~2023-04-24 21:32 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 [this message]
2023-04-25 9:28 ` i o
2023-04-27 21:10 ` 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=6446f5824dd5d_cd6129459@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 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).