Re: [PATCH v6 1/4] last-modified: new subcommand to show when files were last modified

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

Christian Couder <christian.couder@gmail.com> writes:

> Sorry for the noise.

When 6d0618a8 (Add Documentation/CodingGuidelines, 2007-11-08)
started a written guideline, the project already had two-year's
worth of accumulated code.  It was more like "we have been operating
without any written guideline, and so far it has been OK because
most of our contributors and reviewers were competent and
interaction among them amicable.  But now we are having more new
faces.  It is a good time to codify the rules that we have been
trying to adhere to.  It is possible we may have missed some
violations during our reviews and have already took bad apples in
the code base, but they are tolerated-but-undesirable exceptions.
These are the rules we have been trying to follow."  It is expected
that there are some corner cases that violate the writings without
meaning to.

Anybody reading the document should take it as an aspirational
guide, where existing violations (1) are not excuses to introduce
more deviations, (2) are "once written, it is often not worth the
code churn to go and fix them only for the sake of fixing them", and
(3) are very welcome to be rewritten if you are rewriting the code
that covers (not merely overlaps) the area.

And we writing or updating the document should try to make sure that
the aspirational nature is clear to readers.

So your intention to improve the wording of one single item was
surely appreciated, but I think the effort is better spent to make
sure that readers are aware that not just that single item, but
everything in the guideline, may have existing violations in the
code base, and they understand how they should treat these existing
violations, perhaps by polishing the preamble to the whole guideline
document somehow.

Thanks.