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: + ---------------- hfinkel wrote: > 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'? Should we put in a couple of pointers to "good" commit messages?
================ Comment at: docs/DeveloperPolicy.rst:285 @@ +284,3 @@ + +* Separate the commit message into title, body and the optional author. + ---------------- s/the optional author/optionally, the author/ ? ================ 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 ---------------- hfinkel wrote: > I'd remove this paragraph. I don't think we should commit to this. ;) > I do think it's worth mentioning some guideline on what to do about commits with the wrong message vs commits with messages that don't quite fit this style. I think there are cases where it does make sense to revert & re-apply, and others where it's not worth it. 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
