Christian Couder <chriscool@xxxxxxxxxxxxx> writes: > But I think that it can be usefull in case like: > > $ "hack something" > $ git commit ... > $ "hack something else" > $ git add "some of the files" > $ "find out previous commit was crap" > $ git reset --merge-safe HEAD^ > > Here using "--merge-safe" can be usefull because you don't want to lose > stuff in your current index and work tree. That depends on the reason why you are resetting away the "crap commit" and what your next move is. If you are going to run "git commit", perhaps after some further edit, in order to fix what the "crap commit" did not quite do right, what your new option does is actively a wrong thing to do. "Some of the files" you added after that "crap commit" are about "hack something else", i.e. not part of the work to fix the "crap commit", and their changes should not be included in the amended commit, no? In general, "reset" should be about matching the index entries to the named commit, so that you can start from the clean, known slate to redo the commit you wanted to make on top of it. You would need a very good use case to deviate from it and leave the index entry different from that of the commit you are switching to; otherwise you would greatly confuse the end users. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html