Permalink
Browse files

formatting fixes

  • Loading branch information...
sitaramc committed Feb 5, 2013
1 parent 6ae66fd commit bf76dc54f95995256426dfab1b11168d2f1af90d
Showing with 12 additions and 12 deletions.
  1. +1 −1 dev-status.mkd
  2. +4 −4 perf.mkd
  3. +6 −6 rules.mkd
  4. +1 −1 write-types.mkd
View
@@ -1,4 +1,4 @@
-## #dev-status g3 development status
+# #dev-status g3 development status
Not yet done (will be tackled in this order unless someone asks):
View
@@ -50,11 +50,11 @@ triggers as the previous section said.
Here's the big-O stuff:
- * N = number of normal repos, each with its own set of rules. In "repo r1
- r2 r3", N = 3. Add up all such lines.
- * G = number of groups or wild patterns. In "repo @g1 @g2 foo/[a-z]*", G =
+ * N = number of normal repos, each with its own set of rules. In `repo r1
+ r2 r3`, N = 3. Add up all such lines.
+ * G = number of groups or wild patterns. In `repo @g1 @g2 foo/[a-z]*`, G =
3.
- * M = number of members. In "@g1 = r1 r2 <nl> @g2 = r3 r4 r5", M = 5.
+ * M = number of members. In `@g1 = r1 r2 <nl> @g2 = r3 r4 r5`, M = 5.
* A = average number of rule lines in each "repo" block. Usually about 5,
maybe 10 sometimes. You may have more.
View
@@ -1,11 +1,11 @@
-## #rules access rules
+# #rules access rules
In the following description, "user" means "user or a [group][groups] that
he/she is a member of", and "repo" means "repo, or a group that it is a member
of, or a ([wild][] repo) pattern that matches it, or a group that contains a
pattern that matches it".
-### what do rules look like
+## what do rules look like
Here's an example ruleset.
@@ -40,12 +40,12 @@ checks and controls that you can't do with just the normal ref (like
refs/heads/master) being pushed. The most common example is restricting
pushes by dir/file name, but there are lots of other possibilities.</font>
-### how are the rules checked
+## how are the rules checked
Note that gitolite first [accumulates the rules][rule-accum] before checking
access.
-#### read access -- clone, fetch, archive
+### read access -- clone, fetch, archive
Read access is checked once, just before passing control to git-upload-pack or
git-archive-pack. At this point gitolite only knows the repo name, the user
@@ -64,7 +64,7 @@ line 3 does not prevent wally from cloning the repo, because line 4 permits
it. (This is the default behaviour. You can change that by using the
[deny-rules][] option).
-#### write access -- push
+### write access -- push
Write access is checked twice, once before passing control to
git-receive-pack, and once from within the update hook.
@@ -105,7 +105,7 @@ Here's how the actual rule matching happens:
Now all you need is to understand how [refex][] matching happens and how the
permissions match the various [types of write operations][write-types].
-### #permsum summary of permissions
+## #permsum summary of permissions
The full set of permissions, in regex syntax, is `-|R|RW+?C?D?M?`. This
expands to one of `-`, `R`, `RW`, `RW+`, `RWC`, `RW+C`, `RWD`, `RW+D`, `RWCD`,
View
@@ -1,4 +1,4 @@
-## #write-types different types of write operations
+# #write-types different types of write operations
Git supplies enough information to the update hook to be able to distinguish
several types of writes.

0 comments on commit bf76dc5

Please sign in to comment.