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

On Sat, Oct 22, 2016 at 2:19 AM, 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?

Regards,
Lukas

This is (essentially) what I am asking for above. It's the same
overall problem of "muscle memory bites me" and I want the tool to
change to help avoiding because I don't think I can win the fight
against muscle memory every time. Being configurable would ensure that
only those that want the behavior opt in.

Thanks,
Jake