I wrote: > 1b) 'stash save -p' defaults to --keep-index (which can be disabled > with a new option --no-keep-index). In --keep-index mode, it only > offers hunks from the worktree. I ended up implementing the even more restricted form, it always stashes the index as-is and only offers hunks from the worktree. This is because it finally dawned on me that 'git stash apply' does not merge the changesets base..index and index..worktree, but in fact (in one go) base..worktree, into the new HEAD. That way the rules are much simpler as to what goes where. The downside of course is that the state of the worktree (with all stashed hunks discarded) compared to the index (still as before) can be a bit confusing if you stash areas of files that already have staged changes. I also finally found some round tuits, and wrote tests. Which then of course immediately showed that neither 'git reset -p HEAD^' nor 'git checkout -p HEAD^' ever worked as advertised, so I had to fix that. Patches 1/5 and 2/5 are unaffected and still the same. Last but not least, I rather like Dscho's patch http://article.gmane.org/gmane.comp.version-control.git/124182 so I added a small patch to do the same DWIM logic for -p/--patch that goes on top of a merge of 1-5 and his patch. I suspect it's more work to do the merge than to just edit either 5/5 or Dscho's patch, however. Thomas Rast (6): git-apply--interactive: Refactor patch mode code builtin-add: refactor the meat of interactive_add() Implement 'git reset --patch' Implement 'git checkout --patch' Implement 'git stash save --patch' DWIM 'git stash save -p' for 'git stash -p' -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html