{"thread":{"id":"56754","subject":"Re: Unified workflow for `git add/checkout --patch`?","startedAt":"2021-10-21T22:19:51Z","lastAt":"2021-10-25T20:16:12Z","messageCount":3,"participants":["Timothy Eccleston","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"439291","messageId":"CACYzLDcO4OATYYZ6AtJnJTKS9EKUKNRJY5_Rb=y62gWFFwoDhg@mail.gmail.com","threadId":"56754","inReplyTo":"CACYzLDcFjwaJkgVUemD_KqkoGhV_5OYrECddDuxa-o5FpZ6XMA@mail.gmail.com","subject":"Re: Unified workflow for `git add/checkout --patch`?","fromName":"Timothy Eccleston","fromEmail":"timothy.perisho.eccleston@gmail.com","sentAt":"2021-10-21T22:19:38Z","receivedAt":"2021-10-21T22:19:51Z","isPatch":false,"sender":{"key":"timothy.perisho.eccleston@gmail.com","avatar":null},"body":"Hi,\nI really like both these features:\n- git add -p\n- git checkout -p\n\nMy typical workflow\nI like to use them after a long and complex coding sessions where I\nwant to double-check my work, making edits and adding sets of patches\ninto sequential commits to keep related changes together topically.\n\nIn the process of using git add -p to grab some patches, I may notice\nother patches I don't want (especially after I've used the \"e\" command\nin `git add -p` to edit a patch - I usually want to drop the\nremaining, unstaged version of the patch right then). But, instead, I\nhave to go through git add -p and then git checkout -p and likely back\nand forth several times, each time skipping through all the same\nundecided or postponed patches I am waiting on for later.\n\nNote: I recently discovered the \"j\" and \"J\" subcommands which are\nuseful to postpone decisions on certain patches, but only if I\nrestrict myself to just git add or git checkout. If I want to do both,\nI still have to cycle back through from the top each time. I suppose I\ncould use stash -p to really hide patches I'm saving for later, but I\nstill have to exit my workflow and start another command, requiring\nmultiple passes. OTOH, a unified git add/checkout/stash --patch would\nbe amazing!\n\nMy request\nIt would be really nice if there were a unified command workflow where\nI could add or checkout patches or even partial patches (after editing\na patch in git add), on a case by case basis in a single pass.\n\nDoes anyone know a way to do this or do you think it's worth making a\nnew feature in git to handle it?\n\nThanks!\nTim\n"},{"id":"439524","messageId":"47c45a9e-649d-89cc-3d7e-3dcea54bccb5@gmail.com","threadId":"56754","inReplyTo":"CACYzLDcO4OATYYZ6AtJnJTKS9EKUKNRJY5_Rb=y62gWFFwoDhg@mail.gmail.com","subject":"Re: Unified workflow for `git add/checkout --patch`?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2021-10-25T10:08:34Z","receivedAt":"2021-10-25T10:08:44Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Tim\n\nOn 21/10/2021 23:19, Timothy Eccleston wrote:\n> Hi,\n> I really like both these features:\n> - git add -p\n> - git checkout -p\n> \n> My typical workflow\n> I like to use them after a long and complex coding sessions where I\n> want to double-check my work, making edits and adding sets of patches\n> into sequential commits to keep related changes together topically.\n> \n> In the process of using git add -p to grab some patches, I may notice\n> other patches I don't want (especially after I've used the \"e\" command\n> in `git add -p` to edit a patch - I usually want to drop the\n> remaining, unstaged version of the patch right then). But, instead, I\n> have to go through git add -p and then git checkout -p and likely back\n> and forth several times, each time skipping through all the same\n> undecided or postponed patches I am waiting on for later.\n> \n> Note: I recently discovered the \"j\" and \"J\" subcommands which are\n> useful to postpone decisions on certain patches, but only if I\n> restrict myself to just git add or git checkout. If I want to do both,\n> I still have to cycle back through from the top each time. I suppose I\n> could use stash -p to really hide patches I'm saving for later, but I\n> still have to exit my workflow and start another command, requiring\n> multiple passes. OTOH, a unified git add/checkout/stash --patch would\n> be amazing!\n> \n> My request\n> It would be really nice if there were a unified command workflow where\n> I could add or checkout patches or even partial patches (after editing\n> a patch in git add), on a case by case basis in a single pass.\n\nI think I kind of see what you want but I'm a bit confused as how it \ncould be implemented. To clarify do you want to checkout the index to \ndiscard the changes in the worktree or checkout HEAD (the later would be \ndifficult as 'add -p' shows the differences between the index and the \nworktree)? Have you any thoughts on how the user would select whether to \nadd a change to the index or discard it from the worktree? It gets a bit \ntricky if you want to stage an edited version of a hunk and discard the \nunstaged portion from the worktree but I guess we could apply the \nreverse of the original hunk to discard all the changes and then apply \nthe staged version of the hunk to get just the changes the user wants. I \nthink the main challenge would be with the user interface.\n\nBest Wishes\n\nPhillip\n\n> Does anyone know a way to do this or do you think it's worth making a\n> new feature in git to handle it?\n> \n> Thanks!\n> Tim\n> \n\n"},{"id":"439585","messageId":"CACYzLDdx5Nd6PotGp7oNOzkD2qVriu=U1mXMG80yxO9x2+rz2w@mail.gmail.com","threadId":"56754","inReplyTo":"47c45a9e-649d-89cc-3d7e-3dcea54bccb5@gmail.com","subject":"Re: Unified workflow for `git add/checkout --patch`?","fromName":"Timothy Eccleston","fromEmail":"timothy.perisho.eccleston@gmail.com","sentAt":"2021-10-25T19:47:45Z","receivedAt":"2021-10-25T20:16:12Z","isPatch":false,"sender":{"key":"timothy.perisho.eccleston@gmail.com","avatar":null},"body":"Hi Phillip,\nThanks for taking an interest!\n\nIn the workflow I'm describing, I don't add any arguments - i.e. the\ndefaults work for me. But, I see your point about the mismatch between\nINDEX and HEAD. However, it looks like `git checkout -p` already uses\nINDEX as its default when you add the `--patch` argument:\nhttps://git-scm.com/docs/git-checkout#Documentation/git-checkout.txt--p.*\n\nEssentially, I'm sifting through the diffs between workspace and INDEX\nand deciding for each whether to:\n- leave it for later (just lying around in the workspace, or perhaps\neven `git stash`ed away)\n- add it to the INDEX,\n- undo it entirely,\n- edit it (add part and then leave or undo the rest).\n\nI was going to suggest that we just add a second layer of \"directing\"\nhotkeys for \"add\", \"checkout\", \"leave\", and \"stash\" to pair with the\nones (below) that already exist in the `git add -p` command:\n```\nStage this hunk [y,n,q,a,d,j,J,g,/,e,?]? ?\ny - stage this hunk\nn - do not stage this hunk\nq - quit; do not stage this hunk or any of the remaining ones\na - stage this hunk and all later hunks in the file\nd - do not stage this hunk or any of the later hunks in the file\ng - select a hunk to go to\n/ - search for a hunk matching the given regex\nj - leave this hunk undecided, see next undecided hunk\nJ - leave this hunk undecided, see next hunk\ne - manually edit the current hunk\n? - print help\n```\n\nSo, you'd chain 2 single letter commands, like \"sa\" to stash (\"s\") all\n\"a\" the hunks in this file, but my new \"directing\" hotkeys aren't\nquite orthogonal to the existing hotkeys. For example, \"n\" and \"j\" are\nboth sort of like \"leave\". I'm guessing we'd have to create a whole\nnew set of commands.\n\nBest,\nTim\n\nP.S. *Concerning the git checkout defaults. I also assumed that the\nplain git checkout command targets HEAD, but in the docs, all I can\nfind are side effects for the HEAD pointer when the command is run. It\nlooks like with no arguments it targets the current branch, but that's\na noop, since you're already on that branch. I feel like I'm missing\nsomething still, but it also doesn't appear relevant to this \"patch\"\nworkflow anyway.\n\nOn Mon, Oct 25, 2021 at 3:08 AM Phillip Wood <phillip.wood123@gmail.com> wrote:\n>\n> Hi Tim\n>\n> On 21/10/2021 23:19, Timothy Eccleston wrote:\n> > Hi,\n> > I really like both these features:\n> > - git add -p\n> > - git checkout -p\n> >\n> > My typical workflow\n> > I like to use them after a long and complex coding sessions where I\n> > want to double-check my work, making edits and adding sets of patches\n> > into sequential commits to keep related changes together topically.\n> >\n> > In the process of using git add -p to grab some patches, I may notice\n> > other patches I don't want (especially after I've used the \"e\" command\n> > in `git add -p` to edit a patch - I usually want to drop the\n> > remaining, unstaged version of the patch right then). But, instead, I\n> > have to go through git add -p and then git checkout -p and likely back\n> > and forth several times, each time skipping through all the same\n> > undecided or postponed patches I am waiting on for later.\n> >\n> > Note: I recently discovered the \"j\" and \"J\" subcommands which are\n> > useful to postpone decisions on certain patches, but only if I\n> > restrict myself to just git add or git checkout. If I want to do both,\n> > I still have to cycle back through from the top each time. I suppose I\n> > could use stash -p to really hide patches I'm saving for later, but I\n> > still have to exit my workflow and start another command, requiring\n> > multiple passes. OTOH, a unified git add/checkout/stash --patch would\n> > be amazing!\n> >\n> > My request\n> > It would be really nice if there were a unified command workflow where\n> > I could add or checkout patches or even partial patches (after editing\n> > a patch in git add), on a case by case basis in a single pass.\n>\n> I think I kind of see what you want but I'm a bit confused as how it\n> could be implemented. To clarify do you want to checkout the index to\n> discard the changes in the worktree or checkout HEAD (the later would be\n> difficult as 'add -p' shows the differences between the index and the\n> worktree)? Have you any thoughts on how the user would select whether to\n> add a change to the index or discard it from the worktree? It gets a bit\n> tricky if you want to stage an edited version of a hunk and discard the\n> unstaged portion from the worktree but I guess we could apply the\n> reverse of the original hunk to discard all the changes and then apply\n> the staged version of the hunk to get just the changes the user wants. I\n> think the main challenge would be with the user interface.\n>\n> Best Wishes\n>\n> Phillip\n>\n> > Does anyone know a way to do this or do you think it's worth making a\n> > new feature in git to handle it?\n> >\n> > Thanks!\n> > Tim\n> >\n>\n"}]}