Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > > Because there's this weird trick where you can amend the last commit > > using a dirty index and in the process maybe cause the last commit > > to have the same tree as his parent. In such a case you would want > > to discard the last commit instead of amending it. > > Please don't do this. If the user is doing something tricky, we > shouldn't override it. A safety valve to help users avoid > common mistakes is a good thing; a straightjacket to forbid a > clever trick is not. I agree with you completely Junio. I think you may have just misread my intention behind the comment. My point was just that if the user was amending a commit and did so in a way that caused the prior commit to now have absolutely no change at all relative to its parent this is not a situation we normally allow by way of git-commit, as it just isn't usually what the user wants to do. If the user causes this by falling through some bug in git-commit it is probably a mistake on our part, is generally not what the user wants to do, and probably shouldn't be done. The user may look at that and go "Huh, yea, right, that commit now has no point, I should reset it away". The error message that was originally proposed suggested using a mixed mode reset, which would have tossed the user's dirty index, thus allowing them to possibly lose some important state. > > But I have to also wonder, aside from the sick amend case I just > > talked about, how does one get to this part of git-commit.sh with > > nothing to commit? > > Yeah, I also have to wonder. Existing run_status call should > have taken care of things. By the next patch; the one that introduces the --fast flag and lets the user bypass the run_status call. Which then makes this new check the only safety valve the user has to prevent them from making an empty commit and not realize they have forgotten to add files. -- Shawn. - 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
