On Thu, Jan 07, 2021 at 11:43:45AM -0500, Jon Sagotsky wrote: > I frequently make changes to a number of files. I use `git add -p` to > select a number of changes and wrap them up in a commit. Then I run > it again to build another commit. Wash, rinse, repeat. > > Sometimes I make a change I don't intend to keep. Maybe it's a typo, > or some debug code, or my linter does something naughty. As > described, I have to skip that hunk once per commit I'm building. > Usually this is merely inconvenient, but each pass through `git add > -p` runs the risk of me mistakenly adding unintended changes to my > commit. I do something similar and have run into the same problem. There's an old discussion here going into some ideas: https://lore.kernel.org/git/EE89F0A1-1C07-4597-B654-035F657AD09F@xxxxxx/ The interesting bits are I think: - some tools let you do this already (magit was mentioned there, and I'd expect vim plugins like fugitive can probably do the same; tig can also do so from its "stage" interface) - it probably wouldn't be _too_ hard to implement, because we already drive those actions from the same code that is invoked by "add -p" and "git checkout -p"; the difference is just which program we feed the hunks to. - in the most general form of the tool, it would let you take a pass through the hunks and annotating them. The simple common form is two annotations: stage these ones, discard those ones. There may be room for a more generalized tool, or it may just be over-complicating things. The generalized form probably shouldn't be "add -p". The simplified one (just adding "discard this hunk from the worktree") could perhaps be, though it does feel a little weird for "git add" to modify working tree files. -Peff
