Hi Junio, Junio C Hamano writes: > Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > > I'm very sorry to have caused so much pain. Yes, I can imagine how > > terrible it must be to review several iterations of a simple > > documentation patch. Thank you for being so patient with me so far- I > > understand if you don't want to do this anymore. > > > > I do spend time proofreading patches before sending them out, but I'm > > clearly not very good at it. In future, I'll either try rewriting > > entire paragraphs or simply refrain from writing documentation patches. > > I do not think that is the lesson you should learn from this exchange. A > major part of Michael's complaint (which I think was justified) was that > he even made a suggestion that is ready to be cut-and-pasted, but your > reroll does not use the suggested phrasing _without_ explaining why it > doesn't. > > It is not limited to "documentation patches". If you get a "how about > doing it this way---isn't it cleaner?" suggestion to your code patch, you > at least owe either "yeah, that looks better---thanks, I've used it in > this reroll" or "no, because...; I've used the original" to the person who > tried to help you, no? I completely agree -- all of Michael's suggestions were excellent, and I'd definitely owe him an explanation for not using something. In this particular case, it was an honest mistake though- I meant to include Michael's version, but I'd rolled out the wrong commit after rebasing. -- Ram -- 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