From: Jeff King Date: Thu, 20 Oct 2016 02:13:23 GMT Subject: Re: tools for easily "uncommitting" parts of a patch I just commited? Message-ID: <20161020021323.tav5glu7xy4u7mtj@sigill.intra.peff.net> In-Reply-To: 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 " 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 " "git commit " I suspect both of those would complain about legitimate workflows. I dunno. I do not ever use "git commit " 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 " are really two distinct workflows. Your pain comes from mix-and-matching them. -Peff