On Wed, Oct 19, 2016 at 04:36:36PM -0700, Jacob Keller wrote: > > # undo selectively > > git reset -p HEAD^ > > git commit --amend > > AHA! I knew about git reset -p but I didn't know about git reset -p > allowed passing a treeish. Does this reset modify my local files at > all? I think it doesn't, right? Correct. If you wanted to modify the working tree, too, use "git checkout -p HEAD^". > I still think it's worth while to add a check for git-commit which > does something like check when we say "git commit <files>" and if the > index already has those files marked as being changed, compare them > with the current contents of the file as in the checkout and quick > saying "please don't do that" so as to avoid the problem in the first > place. > > A naive approach would just be "if index already has staged > differences dont allow path selection" but that doesn't let me do > something like "git add -p <files>" "git commit <other files>" I suspect both of those would complain about legitimate workflows. I dunno. I do not ever use "git commit <file>" myself. I almost invariably use one of "git add -p" (to review changes as I add them) or "git add -u" (when I know everything is in good shape, such as after merge resolution; I'll sometimes just "git commit -a", too). But it sounds like you want a third mode besides "--include" and "--only". Basically "commit what has been staged already, but restrict the commit to the paths I mentioned". Something like "--only-staged" or something. I do not think we would want to change the default from --only, but I could see a config option or something to select that behavior. I suspect nobody has really asked for such a thing before because separate staging and "git commit <file>" are really two distinct workflows. Your pain comes from mix-and-matching them. -Peff