{"thread":{"id":"66135","subject":"Can we do better than \"git checkout/add -p\"","startedAt":"2026-08-07T04:02:45Z","lastAt":"2026-08-12T22:35:26Z","messageCount":15,"participants":["Junio C Hamano","Christian Couder","D. Ben Knoble","Patrick Steinhardt","Stefan Haller","Johannes Schindelin","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"549923","messageId":"xmqq8q6ih924.fsf@gitster.g","threadId":"66135","inReplyTo":null,"subject":"Can we do better than \"git checkout/add -p\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-07T04:02:43Z","receivedAt":"2026-08-07T04:02:45Z","isPatch":false,"body":"I am doing more \"git checkout -p\" (selective revert of local changes\nout of the working tree files) these days, as well as \"git add -p\"\n(selective adding of local changes to the index), and what I often\nwish is to have _both_ as possible options in a single session.\nThat is, the local changes in my working tree often fall into three\ncategories. (1) One that is clearly good, (2) one that is good but\nnot yet ready, and (3) one that is bogus and should be discarded.\n\n\"git checkout -p\" is a way that is very suitable for (3), while \"git\nadd -p\" is a way to deal with (1). To (2), I say \"no\" in \"git add\n-p\", but there is no easy way from \"git add -p\" to say that the hunk\nis (3).\n\nMy current workaround is not to use \"git checkout -p\" and instead\n(e)dit an undesirable hunk into a no-op hunk. This is serviceable,\nbut with two caveats:\n\n - The underlying 'apply' machinery does not see a truly no-op,\n context-only hunk. You'd need to pretend removing an existing\n line and adding the same line back.\n\n - (e)dit applies the edited hunk right away without giving the user\n a chance to proofread and approve or reedit.\n\n"},{"id":"549948","messageId":"CAP8UFD0i3fr8sNu6wa8iqfdy3t=j0aVHVpjsvks43WVKogSdXg@mail.gmail.com","threadId":"66135","inReplyTo":"xmqq8q6ih924.fsf@gitster.g","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2026-08-07T07:38:58Z","receivedAt":"2026-08-07T07:39:10Z","isPatch":false,"body":"On Fri, Aug 7, 2026 at 6:02 AM Junio C Hamano wrote:\n>\n> I am doing more \"git checkout -p\" (selective revert of local changes\n> out of the working tree files) these days, as well as \"git add -p\"\n> (selective adding of local changes to the index), and what I often\n> wish is to have _both_ as possible options in a single session.\n> That is, the local changes in my working tree often fall into three\n> categories. (1) One that is clearly good, (2) one that is good but\n> not yet ready, and (3) one that is bogus and should be discarded.\n\nWhat if there is a hunk you want to squash to a previous commit like\nHEAD~2 or to a new commit in a separate branch?\n\nI think that if we add a new way to handle hunks, we should consider\nmore cases than just reverting, keeping or indexing. We could perhaps\ntake advantage of recent developments in `git history` to implement\nthe additional cases.\n\nOn the other hand, it seems to me that GitButler's `but rub` command\ncould do a lot of things like that, but it looks like they recently\nreplaced and split that command into more explicit, intent-based\ncommands (see https://github.com/gitbutlerapp/gitbutler/releases).\n\nSo I guess the main issue in designing such a feature is to make it do\nmany things, but not too many.\n"},{"id":"549983","messageId":"CALnO6CBu8ZBDk9YwLW2jVJtBUk1=pvai5QHiLN6XLOOL-3KA=g@mail.gmail.com","threadId":"66135","inReplyTo":"xmqq8q6ih924.fsf@gitster.g","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-08-07T11:24:45Z","receivedAt":"2026-08-07T11:24:58Z","isPatch":false,"body":"On Fri, Aug 7, 2026 at 12:03 AM Junio C Hamano wrote:\n>\n> I am doing more \"git checkout -p\" (selective revert of local changes\n> out of the working tree files) these days, as well as \"git add -p\"\n> (selective adding of local changes to the index), and what I often\n> wish is to have _both_ as possible options in a single session.\n> That is, the local changes in my working tree often fall into three\n> categories. (1) One that is clearly good, (2) one that is good but\n> not yet ready, and (3) one that is bogus and should be discarded.\n>\n> \"git checkout -p\" is a way that is very suitable for (3), while \"git\n> add -p\" is a way to deal with (1). To (2), I say \"no\" in \"git add\n> -p\", but there is no easy way from \"git add -p\" to say that the hunk\n> is (3).\n\nNot a core Git solution, but the interface provided by Fugitive [1]\n(inspired by Magit) makes it easy to browse all hunks, with options to\n(e.g.) stage, unstage, or revert.\n\n(The revert command even shows how to bring back the reverted content,\nin case you made a mistake.)\n\nIt's a bit hard to explain how this works over email. There's an old\nvideo [2] which doesn't reflect many newer enhancements to Fugitive\n(e.g., you no longer need to open a file to diff it; you can toggle\nthe \"git diff\" or \"git diff --cached\" view from within the status\nbuffer---from there, all the staging/unstaging/discard maps work on\nindividual hunks or ranges of lines), but still shows the general\nidea.\n\n[1]: https://github.com/tpope/vim-fugitive\n[2]: http://vimcasts.org/episodes/fugitive-vim-working-with-the-git-index/\n\nI raise this as the kind of interface we could learn from: emulating\nit might be a bit heavier (a full TUI?), but is certainly more\nconvenient to use than the prompt-loop over hunks.\n\nBest,\n-- \nD. Ben Knoble\n"},{"id":"550023","messageId":"xmqqfr0qexps.fsf@gitster.g","threadId":"66135","inReplyTo":"CALnO6CBu8ZBDk9YwLW2jVJtBUk1=pvai5QHiLN6XLOOL-3KA=g@mail.gmail.com","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-07T15:50:39Z","receivedAt":"2026-08-07T15:50:42Z","isPatch":false,"body":"\"D. Ben Knoble\" writes:\n\n> I raise this as the kind of interface we could learn from: emulating\n> it might be a bit heavier (a full TUI?), but is certainly more\n> convenient to use than the prompt-loop over hunks.\n\nYes, the 'one hunk at a time' model was easy to implement and start\nusing, but its limitations are apparent. Users want to be able to\njump around, starting in the middle and returning to the top later,\nfor example.\n\nIt is more or less orthogonal to the reason I started this\ndiscussion, though, which is that limiting the direction in which\nmodifications flow restricts the workflow, burdens the user, and\nmakes the process error-prone.\n\nWhen I see a hunk, I can immediately tell if it is one of three\nkinds (i.e., those we want to add, those we want to leave in the\nworking tree, and those we want to discard from the working tree).\nBut with 'git add -p' (especially with the original version of the\nfeature, before the 'e' (edit) command was introduced), the third\nkind must be treated the same way as the second. Then, after I am\ndone with 'git add -p', I must go through the remaining hunks, sift\nthem into two categories (those we want to keep in the working tree\nand those we want to discard), and run 'git checkout -p' to deal\nwith the latter.\n\nWe should be able to improve this workflow without deviating from\nthe 'one hunk at a time' model.\n"},{"id":"550048","messageId":"CALnO6CAEbiwRyJD+Uk_Aq0gKy-XB1=9PmOUwW6itOMCr+mBmwg@mail.gmail.com","threadId":"66135","inReplyTo":"xmqqfr0qexps.fsf@gitster.g","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-08-07T20:12:21Z","receivedAt":"2026-08-07T20:12:35Z","isPatch":false,"body":"On Fri, Aug 7, 2026 at 11:50 AM Junio C Hamano wrote:\n>\n> \"D. Ben Knoble\" writes:\n>\n> > I raise this as the kind of interface we could learn from: emulating\n> > it might be a bit heavier (a full TUI?), but is certainly more\n> > convenient to use than the prompt-loop over hunks.\n>\n> Yes, the 'one hunk at a time' model was easy to implement and start\n> using, but its limitations are apparent. Users want to be able to\n> jump around, starting in the middle and returning to the top later,\n> for example.\n>\n> It is more or less orthogonal to the reason I started this\n> discussion, though, which is that limiting the direction in which\n> modifications flow restricts the workflow, burdens the user, and\n> makes the process error-prone.\n>\n> When I see a hunk, I can immediately tell if it is one of three\n> kinds (i.e., those we want to add, those we want to leave in the\n> working tree, and those we want to discard from the working tree).\n> But with 'git add -p' (especially with the original version of the\n> feature, before the 'e' (edit) command was introduced), the third\n> kind must be treated the same way as the second. Then, after I am\n> done with 'git add -p', I must go through the remaining hunks, sift\n> them into two categories (those we want to keep in the working tree\n> and those we want to discard), and run 'git checkout -p' to deal\n> with the latter.\n>\n> We should be able to improve this workflow without deviating from\n> the 'one hunk at a time' model.\n\nPerhaps I emphasized the wrong attributes; what initially brought\nFugitive to mind is the fact that one set of commands move hunks\nbetween staged, unstaged, and reverted.\n\nWhether that's in a more complex interface or not, that seemed like\nthe thrust of what you were after.\n\n-- \nD. Ben Knoble\n"},{"id":"550049","messageId":"xmqqfr0pekxq.fsf@gitster.g","threadId":"66135","inReplyTo":"CALnO6CAEbiwRyJD+Uk_Aq0gKy-XB1=9PmOUwW6itOMCr+mBmwg@mail.gmail.com","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-07T20:26:41Z","receivedAt":"2026-08-07T20:26:43Z","isPatch":false,"body":"\"D. Ben Knoble\" writes:\n\n>> We should be able to improve this workflow without deviating from\n>> the 'one hunk at a time' model.\n> ...\n> Whether that's in a more complex interface or not, that seemed like\n> the thrust of what you were after.\n\nIt seems to me that we are saying the same thing ;-).\n"},{"id":"550156","messageId":"anlpmNSjBUJ8p9RL@pks.im","threadId":"66135","inReplyTo":"xmqqfr0qexps.fsf@gitster.g","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-08-10T06:03:04Z","receivedAt":"2026-08-10T06:03:11Z","isPatch":false,"body":"On Fri, Aug 07, 2026 at 08:50:39AM -0700, Junio C Hamano wrote:\n> \"D. Ben Knoble\" writes:\n> \n> > I raise this as the kind of interface we could learn from: emulating\n> > it might be a bit heavier (a full TUI?), but is certainly more\n> > convenient to use than the prompt-loop over hunks.\n> \n> Yes, the 'one hunk at a time' model was easy to implement and start\n> using, but its limitations are apparent. Users want to be able to\n> jump around, starting in the middle and returning to the top later,\n> for example.\n> \n> It is more or less orthogonal to the reason I started this\n> discussion, though, which is that limiting the direction in which\n> modifications flow restricts the workflow, burdens the user, and\n> makes the process error-prone.\n> \n> When I see a hunk, I can immediately tell if it is one of three\n> kinds (i.e., those we want to add, those we want to leave in the\n> working tree, and those we want to discard from the working tree).\n> But with 'git add -p' (especially with the original version of the\n> feature, before the 'e' (edit) command was introduced), the third\n> kind must be treated the same way as the second. Then, after I am\n> done with 'git add -p', I must go through the remaining hunks, sift\n> them into two categories (those we want to keep in the working tree\n> and those we want to discard), and run 'git checkout -p' to deal\n> with the latter.\n> \n> We should be able to improve this workflow without deviating from\n> the 'one hunk at a time' model.\n\nI wonder whether we can take JJ as inspiration. For commands like\njj-split(1) it has the ability to interactively select specific hunks\nvia `jj split --interactive`, too. But instead of looping through stuff,\nit uses a full TUI that:\n\n - Gives you a list of all files that have changed. On this level you\n can select/deselect the complete file.\n\n - Also allows you to expand files and then select/deselect individual\n hunks and lines.\n\nI found that model to be quite a bit superior to Git's own interactive\nmode.\n\nI've been playing around with the thought of introducing ncurses-based\ninterfaces into Git. I've been mostly thinking about git-history(1) here\nso that you can just move commits around, squash them together, drop\nthem and so on. But I think fancy stuff like TUIs can also be applied to\nother parts of Git, as well, to make things a bit more visual to our\nusers and, as a consequence, easier to use.\n\nPatrick\n"},{"id":"550159","messageId":"26c2f7e0-03ef-4c45-8175-adcc2e0395ac@haller-berlin.de","threadId":"66135","inReplyTo":"anlpmNSjBUJ8p9RL@pks.im","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2026-08-10T07:26:55Z","receivedAt":"2026-08-10T07:26:58Z","isPatch":false,"body":"On 10.08.26 08:03, Patrick Steinhardt wrote:\n> I've been playing around with the thought of introducing ncurses-based\n> interfaces into Git. I've been mostly thinking about git-history(1) here\n> so that you can just move commits around, squash them together, drop\n> them and so on. But I think fancy stuff like TUIs can also be applied to\n> other parts of Git, as well, to make things a bit more visual to our\n> users and, as a consequence, easier to use.\n\nThat sounds a whole lot like lazygit to me [1]; it does all those things\nin a rather intuitive way, including Junio's original use case of\nselecting a hunk and staging or discarding it.\n\nIs it really worth adding such functionality to core git? I like the\nidea of tools specializing on what they do well; core git on providing\nthe core functionality, GUI tools on presenting it in a UI.\n\n[1] https://github.com/jesseduffield/lazygit\n"},{"id":"550163","messageId":"anmPq_WN33chIEhL@pks.im","threadId":"66135","inReplyTo":"26c2f7e0-03ef-4c45-8175-adcc2e0395ac@haller-berlin.de","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-08-10T08:45:31Z","receivedAt":"2026-08-10T08:45:39Z","isPatch":false,"body":"On Mon, Aug 10, 2026 at 09:26:55AM +0200, Stefan Haller wrote:\n> On 10.08.26 08:03, Patrick Steinhardt wrote:\n> > I've been playing around with the thought of introducing ncurses-based\n> > interfaces into Git. I've been mostly thinking about git-history(1) here\n> > so that you can just move commits around, squash them together, drop\n> > them and so on. But I think fancy stuff like TUIs can also be applied to\n> > other parts of Git, as well, to make things a bit more visual to our\n> > users and, as a consequence, easier to use.\n> \n> That sounds a whole lot like lazygit to me [1]; it does all those things\n> in a rather intuitive way, including Junio's original use case of\n> selecting a hunk and staging or discarding it.\n> \n> Is it really worth adding such functionality to core git? I like the\n> idea of tools specializing on what they do well; core git on providing\n> the core functionality, GUI tools on presenting it in a UI.\n> \n> [1] https://github.com/jesseduffield/lazygit\n\nI think it depends. There are lots of users out there who use core Git,\nonly, and we often hear complaints from this class of users that Git\nmakes common workflows way too complex. I certainly think that we should\nup our game and try to make such common workflows easier to wield. Tools\nlike JJ demonstrate that there are a bunch of improvements that we can\ndo, and many of those aren't even that hard to implement.\n\nSo If we see that there are use cases where core Git itself is lacking\nand where the consequence is a bad user experience for common workflows\nthen I think that we should plug that gap in core Git itself.\n\nThat being said, I don't think we should get into the business of\nbuilding a full UI, as that feels like a can of worms indeed. Adding\nsomething like a user interface around hunk selection certainly feels\nlike core functionality that I think should be in scope for Git. Whether\na full history-editing user interface should be part of core Git may be\na different question though, as this is getting significantly closer to\na full UI.\n\nPatrick\n"},{"id":"550196","messageId":"xmqqldae6luz.fsf@gitster.g","threadId":"66135","inReplyTo":"26c2f7e0-03ef-4c45-8175-adcc2e0395ac@haller-berlin.de","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-10T15:23:00Z","receivedAt":"2026-08-10T15:23:02Z","isPatch":false,"body":"Stefan Haller writes:\n\n> On 10.08.26 08:03, Patrick Steinhardt wrote:\n>> I've been playing around with the thought of introducing ncurses-based\n>> interfaces into Git. I've been mostly thinking about git-history(1) here\n>> so that you can just move commits around, squash them together, drop\n>> them and so on. But I think fancy stuff like TUIs can also be applied to\n>> other parts of Git, as well, to make things a bit more visual to our\n>> users and, as a consequence, easier to use.\n>\n> That sounds a whole lot like lazygit to me [1]; it does all those things\n> in a rather intuitive way, including Junio's original use case of\n> selecting a hunk and staging or discarding it.\n>\n> Is it really worth adding such functionality to core git? I like the\n> idea of tools specializing on what they do well; core git on providing\n> the core functionality, GUI tools on presenting it in a UI.\n>\n> [1] https://github.com/jesseduffield/lazygit\n\nMy philosophy has always been \"do not compete with your customer\".\n\nIf we add an officially sanctioned XYZ to 'git-core', it would hold\nan undue advantage over tools built on 'git-core' that perform the\nsame task, not because ours is implemented better but merely\nbecause it comes bundled with 'git-core'. I do not want that.\n\nAn exception is when our XYZ is truly of \"we wish someone had\nwritten something better that offers functionality like this\"\nquality, serving as a \"usable but perhaps not pretty\" demonstration.\n\nThanks.\n"},{"id":"550239","messageId":"anqt4a7L49W3BmZQ@pks.im","threadId":"66135","inReplyTo":"xmqqldae6luz.fsf@gitster.g","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-08-11T05:06:41Z","receivedAt":"2026-08-11T05:06:48Z","isPatch":false,"body":"On Mon, Aug 10, 2026 at 08:23:00AM -0700, Junio C Hamano wrote:\n> Stefan Haller writes:\n> \n> > On 10.08.26 08:03, Patrick Steinhardt wrote:\n> >> I've been playing around with the thought of introducing ncurses-based\n> >> interfaces into Git. I've been mostly thinking about git-history(1) here\n> >> so that you can just move commits around, squash them together, drop\n> >> them and so on. But I think fancy stuff like TUIs can also be applied to\n> >> other parts of Git, as well, to make things a bit more visual to our\n> >> users and, as a consequence, easier to use.\n> >\n> > That sounds a whole lot like lazygit to me [1]; it does all those things\n> > in a rather intuitive way, including Junio's original use case of\n> > selecting a hunk and staging or discarding it.\n> >\n> > Is it really worth adding such functionality to core git? I like the\n> > idea of tools specializing on what they do well; core git on providing\n> > the core functionality, GUI tools on presenting it in a UI.\n> >\n> > [1] https://github.com/jesseduffield/lazygit\n> \n> My philosophy has always been \"do not compete with your customer\".\n> \n> If we add an officially sanctioned XYZ to 'git-core', it would hold\n> an undue advantage over tools built on 'git-core' that perform the\n> same task, not because ours is implemented better but merely\n> because it comes bundled with 'git-core'. I do not want that.\n> \n> An exception is when our XYZ is truly of \"we wish someone had\n> written something better that offers functionality like this\"\n> quality, serving as a \"usable but perhaps not pretty\" demonstration.\n\nI guess that's fair. As I said in my parallel reply to this message, I\ncould also see that having something like a git-history(1) UI might be\ntoo much. But I think having a TUI for selecting individual hunks in a\nbetter way compared to `git add -i` and friends might be sensible and\nnot significantly overlap with other projects.\n\nPatrick\n"},{"id":"550381","messageId":"21db84ba-3894-23e9-9f17-ceeafb1990c2@gmx.de","threadId":"66135","inReplyTo":"xmqq8q6ih924.fsf@gitster.g","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2026-08-12T08:40:08Z","receivedAt":"2026-08-12T08:40:14Z","isPatch":false,"body":"Hi Junio,\n\nOn Thu, 6 Aug 2026, Junio C Hamano wrote:\n\n> I am doing more \"git checkout -p\" (selective revert of local changes\n> out of the working tree files) these days, as well as \"git add -p\"\n> (selective adding of local changes to the index), and what I often\n> wish is to have _both_ as possible options in a single session.\n> That is, the local changes in my working tree often fall into three\n> categories. (1) One that is clearly good, (2) one that is good but\n> not yet ready, and (3) one that is bogus and should be discarded.\n> \n> \"git checkout -p\" is a way that is very suitable for (3), while \"git\n> add -p\" is a way to deal with (1). To (2), I say \"no\" in \"git add\n> -p\", but there is no easy way from \"git add -p\" to say that the hunk\n> is (3).\n> \n> My current workaround is not to use \"git checkout -p\" and instead\n> (e)dit an undesirable hunk into a no-op hunk. This is serviceable,\n> but with two caveats:\n> \n> - The underlying 'apply' machinery does not see a truly no-op,\n> context-only hunk. You'd need to pretend removing an existing\n> line and adding the same line back.\n> \n> - (e)dit applies the edited hunk right away without giving the user\n> a chance to proofread and approve or reedit.\n\nI, too, often find myself in exactly that kind of need. That's why I was\n*so* disappointed when\nhttps://lore.kernel.org/git/20260325075055.354709-1-luizedc1@gmail.com/\nwas shot down unceremoniously. I still think that would be a good\naddition. I even opened https://github.com/gitgitgadget/git/issues/1828\nand sketched\nhttps://github.com/git/git/compare/master...dscho:git:add-p-stash-mode to\nthe same extent.\n\nMaybe it is time to revisit that verdict, and see whether there is really\nno way to accept that clearly needed functionality.\n\nCiao,\nJohannes\n"},{"id":"550457","messageId":"20260812214403.GD152730@coredump.intra.peff.net","threadId":"66135","inReplyTo":"21db84ba-3894-23e9-9f17-ceeafb1990c2@gmx.de","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-08-12T21:44:03Z","receivedAt":"2026-08-12T21:44:05Z","isPatch":false,"body":"On Wed, Aug 12, 2026 at 10:40:08AM +0200, Johannes Schindelin wrote:\n\n> > My current workaround is not to use \"git checkout -p\" and instead\n> > (e)dit an undesirable hunk into a no-op hunk. This is serviceable,\n> > but with two caveats:\n> > \n> > - The underlying 'apply' machinery does not see a truly no-op,\n> > context-only hunk. You'd need to pretend removing an existing\n> > line and adding the same line back.\n> > \n> > - (e)dit applies the edited hunk right away without giving the user\n> > a chance to proofread and approve or reedit.\n> \n> I, too, often find myself in exactly that kind of need. That's why I was\n> *so* disappointed when\n> https://lore.kernel.org/git/20260325075055.354709-1-luizedc1@gmail.com/\n> was shot down unceremoniously. I still think that would be a good\n> addition. I even opened https://github.com/gitgitgadget/git/issues/1828\n> and sketched\n> https://github.com/git/git/compare/master...dscho:git:add-p-stash-mode to\n> the same extent.\n> \n> Maybe it is time to revisit that verdict, and see whether there is really\n> no way to accept that clearly needed functionality.\n\nThanks for digging up that link. After reading Junio's message that\nstarted this thread, I _thought_ we had discussed this a dozen times\nalready, but after searching the archive could only come up with this\nthread:\n\n https://lore.kernel.org/git/20161102223705.qycdo3j2bvndi7ev@sigill.intra.peff.net/\n\nBut the one you linked is another example, and nicely links back\nrecursively to at least two other instances. ;)\n\nI see I am quoted in one of them as \"it's a little weird for add -p to\nchange the working tree\", but I want to make clear that I _don't_ oppose\na feature like this. I think it would be super useful. We may find a way\nto avoid that \"weird\" property (e.g., by putting the \"combined\"\nstash/add mode under a different command's \"-p\"), or we may just accept\nit.\n\n-Peff\n"},{"id":"550459","messageId":"xmqqse4jug1e.fsf@gitster.g","threadId":"66135","inReplyTo":"21db84ba-3894-23e9-9f17-ceeafb1990c2@gmx.de","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-12T22:31:41Z","receivedAt":"2026-08-12T22:31:44Z","isPatch":false,"body":"Johannes Schindelin writes:\n\n>> My current workaround is not to use \"git checkout -p\" and instead\n>> (e)dit an undesirable hunk into a no-op hunk. This is serviceable,\n>> but with two caveats:\n>> \n>> - The underlying 'apply' machinery does not see a truly no-op,\n>> context-only hunk. You'd need to pretend removing an existing\n>> line and adding the same line back.\n>> \n>> - (e)dit applies the edited hunk right away without giving the user\n>> a chance to proofread and approve or reedit.\n>\n> I, too, often find myself in exactly that kind of need. That's why I was\n> *so* disappointed when\n> https://lore.kernel.org/git/20260325075055.354709-1-luizedc1@gmail.com/\n> was shot down unceremoniously. I still think that would be a good\n> addition. I even opened https://github.com/gitgitgadget/git/issues/1828\n> and sketched\n> https://github.com/git/git/compare/master...dscho:git:add-p-stash-mode to\n> the same extent.\n>\n> Maybe it is time to revisit that verdict, and see whether there is really\n> no way to accept that clearly needed functionality.\n\nI agree that functionality to cover the \"classify three kinds of\nchanges in the working tree files, update both index and working\ntree files\" is a good thing to have.\n\nI did not, and still do not, think \"git add -p\" is a good place to\nadd a feature to munge working tree files, though.\n\nIOW, what I am lamenting is that we have add/checkout each having\n\"-p\" options, and as separate commands, the user cannot handle three\nkinds of changes in the working tree files without switching between\nthese two commands.\n\n - changes that we want to add to the index for the next commit\n (you tell [y] to add -p)\n - changes that we want to leave in the working tree files\n (you tell [n] to add -p)\n - changes that we want to get rid of from the working tree files\n (you tell [y] to checkout -p)\n\nThe ancient patch deserved to be discarded, simply because \"if we\nare adding it to 'add -p', what about 'checkout p'?\" is a valid\nquestion.\n\nBut the need to have a single command that can deal with the three\nkinds without exiting does exist. It might be beneficial to widen\nour horizon to also consider if it would help us to include stash\ninto the mix. It may give two choices to handle the second class of\nchanges, making them into four categories, i.e.\n\n - changes that we want to add to the index for the next commit\n - changes that we want to stash away from the working tree files\n - changes that we want to leave in the working tree files\n - changes that we want to get rid of from the working tree files\n\n"},{"id":"550460","messageId":"xmqqo6f7ufv8.fsf@gitster.g","threadId":"66135","inReplyTo":"20260812214403.GD152730@coredump.intra.peff.net","subject":"Re: Can we do better than \"git checkout/add -p\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-12T22:35:23Z","receivedAt":"2026-08-12T22:35:26Z","isPatch":false,"body":"Jeff King writes:\n\n> I see I am quoted in one of them as \"it's a little weird for add -p to\n> change the working tree\", but I want to make clear that I _don't_ oppose\n> a feature like this. I think it would be super useful. We may find a way\n> to avoid that \"weird\" property (e.g., by putting the \"combined\"\n> stash/add mode under a different command's \"-p\"), or we may just accept\n> it.\n\nI guess our messages crossed ;-) I do agree that it would be very\nnice to have a feature like this.\n"}]}