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

On Sat, Oct 22, 2016 at 4:19 PM, Lukas Fleischer [off-list ref] wrote:

On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:

quoted

[...]
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>"
[...]

This reminded me of something that bothered me for a while. It's not
100% on-topic but still quite related so I thought I'd bring it up.

When working on a feature, I usually try to make atomic changes from the
beginning and use `git commit -a` to commit them one after another. This
works fine most of the time. Sometimes I notice only after making some
changes that it might be better to split the working tree changes into
several commits.

In that case, I git-add the relevant hunks and then, unfortunately, I
often run `git commit -a` instead of `git commit` (muscle memory bites
me), so I need to do all the splitting work again.

It's not much of an issue but would it be worthwhile to add an optional
feature (configurable) that warns you when using --all with staged
changes (which are not new files)? Are there others having the same
issue? Do you think this should be implemented as part of an alias
instead?

I hit the same problem sometimes, but in my case sometimes I
accidentally do "git add" after "git add -p" and a configuration in
"git commit -a" won't help me. I'd prefer we could undo changes in
index instead. Something like reflog but for index.
-- 
Duy