On Thu, Apr 25, 2013 at 5:01 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Having said that, I am more worried about wasting everybody's time > (and this includes your time) with the impedance mismatch between > you and the rest of us. > > Our standard for explaining the change (either in the log or in the > comment) is to err on the descriptive side to be helpful even to > people new to the codebase. We do not require or encourage to state > the obvious. The issue is the definition of "obviousness" varies > even among the rest of us and even for a single person depending on > how familiar that person is with the area of the code in question. > But the divide between you (alone) and the rest of us seems to be > far more vast than differences among the people other than you. You are missing my point, this is *ONE INSTANCE*. Show me another instance where a reviewer complained about the lack of a descriptive commit messages on *remote-helpers*. > Especially the criteria I used in the above example for "bmarks" > need to be used carefully. If a reviewer needs to follow a very > deep callchain to convince himself why a change does not break > things, it is no longer obvious and deserves to be explained. So if I'm not willing to describe every little trivial cleanup change I do, what should I do then? Avoid those trivial changes? If your true purpose of having descriptive commit messages is to improve maintainability, then actually doing these cleanups should have priority over a descriptive commit message, because doing the cleanups improves the maintainability even without a detailed description. Clearly, your reasoning is incomplete. > So I dunno. If you are not willing to change your ways and try to > be more descriptive to help others to understand what you are doing, > there is nothing I can do to help you. I'm willing to change my ways when there's reason to change my ways, and so far, nobody has provided any evidence that my commit messages are indeed lacking, only *opinions*. Other people are perfectly fine with them: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=felipe.contreras And the only reason we are wasting time, is that *you* make us waste time. Any sensible reviewer would be context aware, notice that this is a contrib patch, and focus on behavioral changes, notice the mistake I made, and point that *one* of the changes was changing the behavior, at which point I would agree and reroll either without that change, or with the change in a separate commit (which I don't want to do right now). The maintainer (you), wouldn't even have to reply at all. But the reviewer failed to do so, and other contributors went even further, so the ball is in now in your court. IMO a sensible maintainer would simply say "Guys, stay on topic, what do we do with this patch?", but no, you allow people to suggest that not only the whole series, but the whole sub-project be dropped, and to do so with totally unrelated facts, and generalizing from *ONE INSTANCE* in the actual sub-project, and generally from ad hominem arguments. This doesn't help anybody. Show me a systemic problem with the commit messages *in remote-helpers*, and then perhaps it would be worth to start *a new thread* to discuss them, but nobody has done so. We are still talking about a *single patch*. And if you really really don't like the patch, say "do X, or I drop the patch", or the series, and there would be no need for other reviewers to waste their time (if their comments were truly valid and correct, which they are not). There's no need to say anything more. And even if the reviewers were correct in their comments, allowing suggestions such as that the whole sub-project should be dropped because of one patch is going to waste people's times, no matter what. Cheers. -- Felipe Contreras -- 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