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

  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 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.