summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJoel Dillon <joel.dillon@codethink.co.uk>2012-09-11 13:59:32 +0100
committerJoel Dillon <joel.dillon@codethink.co.uk>2012-09-11 13:59:32 +0100
commit9c9bf556dab8b07d1afd4fcf7bdedafffb2a381c (patch)
tree800fc950eef68569e06fb8a83235357cda4ec96c
parent2b5de6c9c4121f5842aacda166f38d05652b2cdf (diff)
downloaddocumentation-9c9bf556dab8b07d1afd4fcf7bdedafffb2a381c.tar.gz
Improve wording a bit
-rw-r--r--git.txt10
1 files changed, 7 insertions, 3 deletions
diff --git a/git.txt b/git.txt
index 97e5692..3960b72 100644
--- a/git.txt
+++ b/git.txt
@@ -22,14 +22,18 @@ a complete local copy of the whole codebase branches become very fast.
Consequently, git development revolves much more strongly than most
version control systems around a model of creating a temporary local
branch for a particular bugfix or feature, getting that branch to work
-correctly, and then merging it into the upstream repository.
+correctly, and then merging it into the upstream repository;
+therefore, as well as fast branching it also has very powerful support
+for merging.
-Baserock revolves very strongly around this model. The whole Baserock
+Baserock is designed to take full advantage of this. The whole Baserock
system is stored in git. Making changes to your system involves
branching your system as a whole, making changes to the components
of Baserock you want to modify in a local branch in your local
git repositories, and eventually merging those changes into your
-upstream repository.
+upstream repository. Part of Baserock's power is in its ability
+to automate the process of branching every component in
+your system as you work on them.
Apart from its suitability by design for such a development model,
and because of its scalability, we use git because it is by far the