Re: tools for easily "uncommitting" parts of a patch I just commited?

[Jeff King <peff@peff.net>]

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