On Thu, Apr 25, 2013 at 5:01 PM, Junio C Hamano <gits...@pobox.com> 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

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:

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

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.


Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to