{"thread":{"id":"59641","subject":"Proposal: adding --soft and --mixed options to git checkout","startedAt":"2023-04-24T11:41:53Z","lastAt":"2023-04-27T21:10:45Z","messageCount":4,"participants":["i o","Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"475911","messageId":"PA4PR09MB65161C38AEFBC07B3D7A1C62B0679@PA4PR09MB6516.eurprd09.prod.outlook.com","threadId":"59641","inReplyTo":null,"subject":"Proposal: adding --soft and --mixed options to git checkout","fromName":"i o","fromEmail":"lvsil4@outlook.com","sentAt":"2023-04-24T11:41:47Z","receivedAt":"2023-04-24T11:41:53Z","isPatch":false,"sender":{"key":"lvsil4@outlook.com","avatar":null},"body":"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.\n\nThe 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>, whereas `git checkout [--soft|--mixed] <branch>` would move HEAD and switch from the current branch to <branch>.\n\nI'm aware work arounds exist for these, something like:\n\n    ```\n    git checkout --detach\n    git reset [--soft|--mixed] [<branch>|<commit>]\n    git checkout [<branch>|<commit>]\n    ```\n\nso the aim here is really one of convenience by having this feature contained in a native option.\n\nAnother option that might be worth adding to `git checkout` is `--keep-index` (like the option in `git stash`), to move the HEAD to <tree-ish> and update the working tree to match it without changing the index."},{"id":"475975","messageId":"6446f5824dd5d_cd6129459@chronos.notmuch","threadId":"59641","inReplyTo":"PA4PR09MB65161C38AEFBC07B3D7A1C62B0679@PA4PR09MB6516.eurprd09.prod.outlook.com","subject":"Re: Proposal: adding --soft and --mixed options to git checkout","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2023-04-24T21:32:50Z","receivedAt":"2023-04-24T21:32:55Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"i o wrote:\n> I suggest adding `--soft` and `--mixed` options to `git checkout`, that act\n> similarly to the corresponding options of `git reset`, i.e. `git checkout\n> --soft <tree-ish>` should move the HEAD to <tree-ish> without affecting the\n> working tree or index, and `git checkout --mixed <tree-ish>` should move the\n> HEAD to <tree-ish> and update the index to match it without changing the\n> working tree.\n\nIn my opinion it's pretty clear `--soft` and `--mixed` were terrible names and\nI suggested in the past to rename them to `--no-stage` and `--stage` [1]. We\nshould not repeat those mistakes with `git checkout`.\n\nIf the new options were:\n\n * git checkout --no-stage\n * git checkout --no-work-tree\n\nI think it would be pretty clear what is intended without explanation (as\nopposed to `--soft` and `--mixed`).\n\n> The difference between this and `git reset` of course would be that, unlike\n> the latter, this doesn't 'drag' the current branch along with HEAD; instead\n> the usual behaviour would apply depending on what exactly <tree-ish> is, i.e.\n> `git checkout [--soft|--mixed] <commit>` would detach HEAD and point it to\n> <commit>,\n\nIn my mind the whole point of `git checkout` is to update the work-tree, if the\ncommand is not going to do that, then I don't think it should be `git\ncheckout`.\n\nIn theory all these three would do the same, correct?\n\n * git checkout --no-stage --no-work-tree <commit>\n * git reset --no-stage --detach <commit>\n * git update-ref --no-deref HEAD <commit>\n\nMy preference would be `git reset --no-stage --detach <commit>`.\n\n> whereas `git checkout [--soft|--mixed] <branch>` would move HEAD\n> and switch from the current branch to <branch>.\n\nIf we are going to switch the current branch, then `git switch` makes more\nsense:\n\n * git switch --no-stage <branch>\n\nThen, for the case of a commit we could do:\n\n * git switch --no-stage --detach <commit>\n\nThe advantage of limiting ourselves to `git switch` is that it doesn't have the\nhistorical of `git checkout`/`git reset`.\n\nCheers.\n\n[1] https://lore.kernel.org/git/20130829180129.GA4880@nysa/\n\n-- \nFelipe Contreras\n"},{"id":"476017","messageId":"DB9PR09MB6506FD114211F3806C48954AB0649@DB9PR09MB6506.eurprd09.prod.outlook.com","threadId":"59641","inReplyTo":"6446f5824dd5d_cd6129459@chronos.notmuch","subject":"Re: Proposal: adding --soft and --mixed options to git checkout","fromName":"i o","fromEmail":"lvsil4@outlook.com","sentAt":"2023-04-25T09:28:13Z","receivedAt":"2023-04-25T09:28:24Z","isPatch":false,"sender":{"key":"lvsil4@outlook.com","avatar":null},"body":"Felipe Contreras wrote:\n> In my opinion it's pretty clear `--soft` and `--mixed` were terrible names and\n> I suggested in the past to rename them to `--no-stage` and `--stage` [1]. We\n> should not repeat those mistakes with `git checkout`.\n\nNo 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.\n\n> In my mind the whole point of `git checkout` is to update the work-tree, if the\n> command is not going to do that, then I don't think it should be `git\n> checkout`.\n\nI 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."},{"id":"476233","messageId":"644ae4b537ec2_7f4f2949@chronos.notmuch","threadId":"59641","inReplyTo":"DB9PR09MB6506FD114211F3806C48954AB0649@DB9PR09MB6506.eurprd09.prod.outlook.com","subject":"Re: Proposal: adding --soft and --mixed options to git checkout","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2023-04-27T21:10:13Z","receivedAt":"2023-04-27T21:10:45Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"i o wrote:\n> Felipe Contreras wrote:\n> > In my opinion it's pretty clear `--soft` and `--mixed` were terrible names and\n> > I suggested in the past to rename them to `--no-stage` and `--stage` [1]. We\n> > should not repeat those mistakes with `git checkout`.\n> \n> No problem with renaming, but this might also be an oppurtunity to reconsider\n> the meaning of the two options to incorporate `--keep-index`. Maybe\n> `--no-stage` should mean 'switch HEAD and the working tree but leave the\n> staging area' (i.e. the equivalent of `--keep-index`), and `--no-work` should\n> mean 'switch HEAD and the staging area but leave the working tree' (i.e. the\n> equivalent of `--mixed`). `--soft` could then be achieved by combining these\n> options: `--no-stage --no-work`, but it could be a worthwhile convenience to\n> add a separate option for that (just moving the HEAD), so maybe `--head` or\n> something like that.\n\nOf course, many options could be considered, but unfortunately the outcome will\nbe the same regardless of the consensus: no change will happen. As you can see\nthat's what happened in that previous thread, regardless of the overwhelming\nconsensus.\n \n> > In my mind the whole point of `git checkout` is to update the work-tree, if the\n> > command is not going to do that, then I don't think it should be `git\n> > checkout`.\n> \n> I suppose something similar could also be said about `git reset` though?\n\nI don't know. To me `git reset` is too vague. Resetting what? The \"HEAD\"? That\nto me has no meaning whatsoever, as \"HEAD\" is git-only semantic invention that\nroughly translates to \"the current branch\" (but not quite).\n\nSo with `git reset` we are \"resetting the current branch\"? That doesn't tell me\nmuch.\n\n> Maybe this would support the general move away from those legacy commands\n> towards the new set of commands, so putting these new options in `git switch`\n> instead seems reasonable.\n\nI would rather change the semantics of `git checkout` and `git reset` but that\nseems rather impossible.\n\nSo yeah, I would focus on what has a remote chance of actually get done.\n\nCheers.\n\n-- \nFelipe Contreras\n"}]}