# Proposal: adding --soft and --mixed options to git checkout 4 messages from 2023-04-24 to 2023-04-27. Participants: i o, Felipe Contreras. Thread: https://gitlist.dev/t/59641 ## i o, 2023-04-24 11:41 Subject: Proposal: adding --soft and --mixed options to git checkout Message-ID: URL: https://gitlist.dev/e/PA4PR09MB65161C38AEFBC07B3D7A1C62B0679%40PA4PR09MB6516.eurprd09.prod.outlook.com ``` 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 ` should move the HEAD to without affecting the working tree or index, and `git checkout --mixed ` should move the HEAD to and update the index to match it without changing the working tree. 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 is, i.e. `git checkout [--soft|--mixed] ` would detach HEAD and point it to , whereas `git checkout [--soft|--mixed] ` would move HEAD and switch from the current branch to . I'm aware work arounds exist for these, something like: ˋˋˋ git checkout --detach git reset [--soft|--mixed] [|] git checkout [|] ˋˋˋ so the aim here is really one of convenience by having this feature contained in a native option. Another option that might be worth adding to `git checkout` is `--keep-index` (like the option in `git stash`), to move the HEAD to and update the working tree to match it without changing the index. ``` ## Felipe Contreras, 2023-04-24 21:32 Subject: Re: Proposal: adding --soft and --mixed options to git checkout Message-ID: <6446f5824dd5d_cd6129459@chronos.notmuch> URL: https://gitlist.dev/e/6446f5824dd5d_cd6129459%40chronos.notmuch In-Reply-To: ``` 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 ` should move the HEAD to without affecting the > working tree or index, and `git checkout --mixed ` should move the > HEAD to 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 is, i.e. > `git checkout [--soft|--mixed] ` would detach HEAD and point it to > , 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 * git reset --no-stage --detach * git update-ref --no-deref HEAD My preference would be `git reset --no-stage --detach `. > whereas `git checkout [--soft|--mixed] ` would move HEAD > and switch from the current branch to . If we are going to switch the current branch, then `git switch` makes more sense: * git switch --no-stage Then, for the case of a commit we could do: * git switch --no-stage --detach 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 ``` ## i o, 2023-04-25 09:28 Subject: Re: Proposal: adding --soft and --mixed options to git checkout Message-ID: URL: https://gitlist.dev/e/DB9PR09MB6506FD114211F3806C48954AB0649%40DB9PR09MB6506.eurprd09.prod.outlook.com In-Reply-To: <6446f5824dd5d_cd6129459@chronos.notmuch> ``` 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. > 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? 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. ``` ## Felipe Contreras, 2023-04-27 21:10 Subject: Re: Proposal: adding --soft and --mixed options to git checkout Message-ID: <644ae4b537ec2_7f4f2949@chronos.notmuch> URL: https://gitlist.dev/e/644ae4b537ec2_7f4f2949%40chronos.notmuch In-Reply-To: ``` 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 ```