REPOSITORY rL LLVM ================ Comment at: docs/DeveloperPolicy.rst:283 @@ +282,3 @@ +guidelines that will help review, search in logs, email formatting and so on. +Mostly, the rules that apply are similar to other git repositories, such as: + ---------------- Good commit messages help in reconstructing the rationale for the state of the code, that's their most important purpose.
Saying 'git repositories' is a bit confusing, since we still primarily use svn. Maybe say 'giv/svn'? ================ Comment at: docs/DeveloperPolicy.rst:294 @@ +293,3 @@ +* The body should be aligned to 80 columns and have as many paragraphs as + necessary, but not more than that. Meaning you should be concise, but + explanatory, including a complete reasoning, but leaving examples, code ---------------- Please don't say this. IMHO, we don't have a problem with commit messages being too long; and small code examples explaining what the commit is addressing can be really informative after the fact. We could say that, if the commit message is long, to please provide a summary paragraph at the top. ================ Comment at: docs/DeveloperPolicy.rst:300 @@ +299,3 @@ + the body, as simple as "Patch by John Doe.". This is how we officially + handle attribution, and there are automated processes that use that, so + please keep this pattern. ---------------- use that -> rely on this format ================ Comment at: docs/DeveloperPolicy.rst:306 @@ +305,3 @@ + +While these rules match most of the cases, we're aware that some cases are not +covered, and that's why we don't think reverting patches with "bad" commit ---------------- I'd remove this paragraph. I don't think we should commit to this. ;) http://reviews.llvm.org/D8197 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
