On Saturday 2006, December 02 08:09, Junio C Hamano wrote: > Aside from the "working tree not matching index" safety valve I > asked for, there is a more important case that "when the index > matches HEAD" is not a safe enough check for this 'cleverness'. As I pointed out, that safety valve made the whole thing a no-op. > So that is _another_ exception you must handle. > > But I think the problem with this 'cleverer' commit runs > deeper. > > Notice that you needed to say "The main idea is this cleverness, > but foo pointed out this special case, and bar pointed out > another, and we fixed all of these known ones and now this is > good, let's apply it." in your proposed commit log message? You > should smell fishiness in that kind of reasoning. I don't believe so. In deep parts of a program cleverness is always a bad idea. It just obfuscates functionality. However, this "cleverness" is about making things easier for a human. Humans have a notoriously illogical set of requirements for doing the right thing. As an example I'd hold up git's clever date specification code; a computer would be perfectly happy to accept epoch time, but instead humans like to be able to say "three weeks ago this Thursday at five to four". This patch is merely to make git-commit do something sensible when it would normally do nothing. I was sure there would be more exceptions to when it should activate; as git-commit is already a mess of "useful" extra switches. To blame this patch for the fact that git-commit does a lot of things in slightly different ways hardly seems fair. As usual though: I don't mind, I'm not some huge proponent of this functionality - /I/ get along fine with git-commit > I really think the users would be much better off with > consistent behaviour that is easy and simple to describe than a > complex magic that does the right thing 99.9% of the time, > because you either understand the complex magic or constantly in > fear of the tool that can work against you 0.01% of the time. I suspect that this patch is the least of git-commit's problems in that department. "Easy to describe" is certainly not the case already, otherwise none of this discussion (or patch) would ever have started. Andy -- Dr Andrew Parkins, M Eng (Hons), AMIEE andyparkins@xxxxxxxxx - 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