On Sat, Oct 22, 2016 at 4:19 PM, Lukas Fleischer <lfleischer@xxxxxxx> 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 <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