Re: Proposal: adding --soft and --mixed options to git checkout

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Apr 24, 2023, 21:32 UTC
Message-ID: <6446f5824dd5d_cd6129459@chronos.notmuch>
In-Reply-To: <PA4PR09MB65161C38AEFBC07B3D7A1C62B0679@PA4PR09MB6516.eurprd09.prod.outlook.com>

i o wrote:

Show 6 quoted lines

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

Show 5 quoted lines

> 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