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

On Thu, Oct 20, 2016 at 9:30 AM, Junio C Hamano [off-list ref] wrote:

Jeff King [off-list ref] writes:

quoted

quoted

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.

...
I suspect both of those would complain about legitimate workflows.

I dunno.  I do not ever use "git commit <file>" myself.

Users are different.  I do use this all the time, and it is not
unusual at all to have changed contents on paths other than <file>
already added to the index when I do so, i.e. an unrelated small
typofix in <file> jumping ahead of the real changes I am working on
in other parts of the tree.

"Please don't do that" would break.  Jacob says "avoid the problem",
but I do not see a problem in allowing it (it could be that the
problem Jacob has is in other parts of his workflow, but I do not
know what it is offhand).

I still think we're misunderstanding. I want git commit to complain
*only* under the following circumstance:

I run "git add -p" and put a partial change into the index in <file>.
There are still other parts which were not added to the index yet.
Thus, the index version of the file and the actual file differ.

Then, I (accidentally) run "git commit <file>"

I want git commit to complain here that the index <file> and acutal
<file> being requested are different and it thinks there's an issue.

I do *NOT* want it to complain if I do "git add -p" and put parts of
<other-file> into the index, and then run

git commit <file>

Does that make sense?

Basically if the index and "git commit <file>" both say "add <file>"
but they conflict in what version of <file> I want it to go "hey..
uhhh.. that's a bad idea"

Thanks,
Jake