Ævar Arnfjörð Bjarmason wrote: > The CodingGuidelines is what we're asking people to read when they've > e.g. found some data-eating bug in git and are about to send us a patch, > but before that we're asking them to go through a fuzzy checklist of > items checklist. It's already 20 pages in my browser if I were to try to > print it. Exactly. Moreover, the point a guideline is on the name: guide. After reading it developers should feel they are heading in the right direction, but they won't know everything there is to know about git.git development, that requires many years of practice, and mistakes. More importantly than what it is, is what it's not: by-laws. A developer that misses a point in the guidelines should not be reprimended and sent to the brig. Instead she should merely be directed to it. Another thing it shouldn't be is a tool to win arguments. If two developers argue about sentence spacing (one space vs. two spaces), even if the whole community agrees two spaces is preferable--and thus one developer "won" the argument--that still doesn't merit writing it down to further rub it in. Not everything belongs in the guideline; only the most salient tips that guide newcomers in the right direction. Cheers. -- Felipe Contreras
