From b14b90655ca9912ab3770974f55b3f3056af05b8 Mon Sep 17 00:00:00 2001 From: Matthias Felleisen Date: Tue, 26 Jul 2011 19:56:19 -0400 Subject: [PATCH] [Style] added branch --- .../scribblings/style/branch-and-commit.scrbl | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 collects/scribblings/style/branch-and-commit.scrbl diff --git a/collects/scribblings/style/branch-and-commit.scrbl b/collects/scribblings/style/branch-and-commit.scrbl new file mode 100644 index 0000000000..4e80902504 --- /dev/null +++ b/collects/scribblings/style/branch-and-commit.scrbl @@ -0,0 +1,27 @@ +#lang scribble/base + +@(require "shared.rkt") + +@title{Branch and Commit} + +@section{Commit} + +So what is the major lesson of this section? When you fix a bug, make sure + to commit (1) the code delta, (2) the new test case, and (3) the revised + docs (if applicable) in one batch. If the creation of a single commit is + too complex of if you wish to factor out one of the commits, please push + all pieces at once. That way the code base is always in a state where + code, tests, and documentation are in sync, and readers of commit messages + can evaluate changes completely. + +@section{No Commit ``Bombs'' Please} + +On occasion, you will find that you are spending a significant amount of + time working with someone else's code. To avoid potentially painful + merges, please (1) inform the author when you create the branch and (2) + set the mail hook @margin-note*{See Eli's write-up on using git in PLT for + information on the mechanics.} so that git sends a commit message to both + you and the original author. Furthermore, you should test your changes on + the actual code base. In some cases it is acceptable to delay such tests, + e.g., when you will not know for a long time whether the performance + implication allow a commit to the PLT repository.