Hi Peff, On Fri, 8 Jan 2021, Jeff King wrote: > 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. We do have `git stash -p`, which I used sometimes to discard such unwanted pieces. However, `git stash -p` suffers from a couple implementation details (see e.g. https://lore.kernel.org/git/20200731165140.29197-1-alban.gruin@xxxxxxxxx/) More often than not, I am actually using `git add -p` to commit those changes instead, using the commit message `TO-DROP` and later using `rebase -i` to actually drop them. I could imagine that it should not be _too_ hard to implement an action in `git add -p` to allow stashing a given hunk. The biggest challenge there would be to make sure that potentially edited, to-be-stashed changes won't interfere with staging what was intended (because `git add -p` batches the changing per-file, and if the index changes while picking what to stage, things might conflict). Maybe an Outreachy project? Ciao, Dscho
