From: Jacob Keller Date: Sun, 23 Oct 2016 01:07:16 GMT Subject: Re: tools for easily "uncommitting" parts of a patch I just commited? Message-ID: In-Reply-To: <147712794056.12237.1478296296628149440@typhoon.fritz.box> On Sat, Oct 22, 2016 at 2:19 AM, Lukas Fleischer wrote: > On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote: >> [...] >> 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 . >> 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 " >> [...] > > 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