Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > Junio C Hamano wrote: >> In other words, I knew that you are capable enough to track down a >> bug in the code you wrote recently that made it violate the >> expectation you defined in your own tests. > > Wrong. The code in question was not recent, it was introdued in 1.8.3, > more than one year ago. > > And wrong, it didn't violate the expectation of my own tests. > > The code was simply not exercised in the tests. > >> There was no room for differences of opinions to come into play, as it >> was just between you and your own code. OK, I misread the blame output---sorry about that. But that does not change the fact that your tests caught a bug in your own code, and the issue was solely between you and your own code without involving criticism from anybody, does it? Unless you count a barf from a rather old version of Mercurial as a criticism, that is. >> Why would I expect otherwise? >> > Because most people take attacks on their code as personal attacks, and > they don't fix bugs in their code if they don't like the person > reporting it. > > But you know I don't take attacks on my code and ideas personally, which > is more that can be said of most people on the list. Just to make sure new people who may be watching with popcorns in their hand from sidelines do not get a wrong impression, I do not share your "most people take attacks ..." observation. In reviews I have seen over the years around here (and also reviews at $DAYJOB), I rarely saw such a reaction by the person whose change is reviewed. I view this list as very cooperative and productive environment most of the time. In any case, there was not even any attack---it was merely your code not passing your own test on a platform you did not have access to, which is not something to be upset about. > I don't want to do anything for a "contrib" tool. > > It's already broken in v2.0 anyway. Yes, this is not even an old regression. If you no longer want to have it in contrib/, I can drop it in future releases (but not in v2.0), so that people can find the latest and greatest directly from you. Otherwise, queuing a fix on 'pu' and then to 'next' in preparation for an early graduation for the release after v2.0 (and as a fix, it may want to go to older maintenance releases) is also fine by me. -- 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