Re: [PATCH 1/9] remote-bzr: trivial cleanups

[Junio C Hamano <gitster@pobox.com>]

Felipe Contreras <felipe.contreras@gmail.com> writes:

>> Three random points.
>>
>>  * For this particular patch [1/9], especially because this would
>>    land close to the corresponding remote-hg fixes (e.g. "has_key is
>>    deprecated"), I think it is sufficient to say "port fixes from
>>    corresponding remote-hg patches" (you said it in 0/9 and didn't
>>    say it in 1/9, though) without going into individual details.
>>    Anybody who wonders what these changes were about will have a
>>    clue to check contemporary patches to remote-hg that way.
>
> If there's any issues with that, just drop the patch,...
> ...
> 1) Drop this patch
> 2) Drop the whole series
> 3) I reroll without the change that was not described

Just in case you missed it, the first in the three-random-points was
"I personally think 1/9 that does not say anything about the minute
and irrelevant details Ram kibitzed about is fine".  So "Drop this
patch" is not something on the table in the first place.

 * After seeing that this change is a copy from recent remote-hg
   changes, a revier who did a little homework would easily find a
   change around has_key in recent patches.

 * A reviewer who did a little homework would know by reading a bit
   beyond the patch context to see that nobody uses "bmarks".

 * A reviewer who wondered how the two lines are different can stop
   staring at the screen, take a walk and come back with refreshed
   eyes to spot the difference between blog and blob very easily.

For these reasons, I personally do not think it is unreasonable to
throw comments like the ones on "has_key", "global bmarks", and
"blog vs blob" into "too obvious, not even deserve to be responded"
bin.

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.

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 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.