Hi Phillip, Thanks for taking an interest! In the workflow I'm describing, I don't add any arguments - i.e. the defaults work for me. But, I see your point about the mismatch between INDEX and HEAD. However, it looks like `git checkout -p` already uses INDEX as its default when you add the `--patch` argument: https://git-scm.com/docs/git-checkout#Documentation/git-checkout.txt--p.* Essentially, I'm sifting through the diffs between workspace and INDEX and deciding for each whether to: - leave it for later (just lying around in the workspace, or perhaps even `git stash`ed away) - add it to the INDEX, - undo it entirely, - edit it (add part and then leave or undo the rest). I was going to suggest that we just add a second layer of "directing" hotkeys for "add", "checkout", "leave", and "stash" to pair with the ones (below) that already exist in the `git add -p` command: ``` Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? ? y - stage this hunk n - do not stage this hunk q - quit; do not stage this hunk or any of the remaining ones a - stage this hunk and all later hunks in the file d - do not stage this hunk or any of the later hunks in the file g - select a hunk to go to / - search for a hunk matching the given regex j - leave this hunk undecided, see next undecided hunk J - leave this hunk undecided, see next hunk e - manually edit the current hunk ? - print help ``` So, you'd chain 2 single letter commands, like "sa" to stash ("s") all "a" the hunks in this file, but my new "directing" hotkeys aren't quite orthogonal to the existing hotkeys. For example, "n" and "j" are both sort of like "leave". I'm guessing we'd have to create a whole new set of commands. Best, Tim P.S. *Concerning the git checkout defaults. I also assumed that the plain git checkout command targets HEAD, but in the docs, all I can find are side effects for the HEAD pointer when the command is run. It looks like with no arguments it targets the current branch, but that's a noop, since you're already on that branch. I feel like I'm missing something still, but it also doesn't appear relevant to this "patch" workflow anyway. On Mon, Oct 25, 2021 at 3:08 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > > Hi Tim > > On 21/10/2021 23:19, Timothy Eccleston wrote: > > Hi, > > I really like both these features: > > - git add -p > > - git checkout -p > > > > My typical workflow > > I like to use them after a long and complex coding sessions where I > > want to double-check my work, making edits and adding sets of patches > > into sequential commits to keep related changes together topically. > > > > In the process of using git add -p to grab some patches, I may notice > > other patches I don't want (especially after I've used the "e" command > > in `git add -p` to edit a patch - I usually want to drop the > > remaining, unstaged version of the patch right then). But, instead, I > > have to go through git add -p and then git checkout -p and likely back > > and forth several times, each time skipping through all the same > > undecided or postponed patches I am waiting on for later. > > > > Note: I recently discovered the "j" and "J" subcommands which are > > useful to postpone decisions on certain patches, but only if I > > restrict myself to just git add or git checkout. If I want to do both, > > I still have to cycle back through from the top each time. I suppose I > > could use stash -p to really hide patches I'm saving for later, but I > > still have to exit my workflow and start another command, requiring > > multiple passes. OTOH, a unified git add/checkout/stash --patch would > > be amazing! > > > > My request > > It would be really nice if there were a unified command workflow where > > I could add or checkout patches or even partial patches (after editing > > a patch in git add), on a case by case basis in a single pass. > > I think I kind of see what you want but I'm a bit confused as how it > could be implemented. To clarify do you want to checkout the index to > discard the changes in the worktree or checkout HEAD (the later would be > difficult as 'add -p' shows the differences between the index and the > worktree)? Have you any thoughts on how the user would select whether to > add a change to the index or discard it from the worktree? It gets a bit > tricky if you want to stage an edited version of a hunk and discard the > unstaged portion from the worktree but I guess we could apply the > reverse of the original hunk to discard all the changes and then apply > the staged version of the hunk to get just the changes the user wants. I > think the main challenge would be with the user interface. > > Best Wishes > > Phillip > > > Does anyone know a way to do this or do you think it's worth making a > > new feature in git to handle it? > > > > Thanks! > > Tim > > >
