Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

formatting fixes

  • Loading branch information...
commit bf76dc54f95995256426dfab1b11168d2f1af90d 1 parent 6ae66fd
Sitaram Chamarty authored February 05, 2013
2  dev-status.mkd
Source Rendered
... ...
@@ -1,4 +1,4 @@
1  
-## #dev-status g3 development status
  1
+# #dev-status g3 development status
2 2
 
3 3
 Not yet done (will be tackled in this order unless someone asks):
4 4
 
8  perf.mkd
Source Rendered
@@ -50,11 +50,11 @@ triggers as the previous section said.
50 50
 
51 51
 Here's the big-O stuff:
52 52
 
53  
-  * N = number of normal repos, each with its own set of rules.  In "repo r1
54  
-    r2 r3", N = 3.  Add up all such lines.
55  
-  * G = number of groups or wild patterns.  In "repo @g1 @g2 foo/[a-z]*", G =
  53
+  * N = number of normal repos, each with its own set of rules.  In `repo r1
  54
+    r2 r3`, N = 3.  Add up all such lines.
  55
+  * G = number of groups or wild patterns.  In `repo @g1 @g2 foo/[a-z]*`, G =
56 56
     3.
57  
-  * M = number of members.  In "@g1 = r1 r2 <nl> @g2 = r3 r4 r5", M = 5.
  57
+  * M = number of members.  In `@g1 = r1 r2 <nl> @g2 = r3 r4 r5`, M = 5.
58 58
   * A = average number of rule lines in each "repo" block.  Usually about 5,
59 59
     maybe 10 sometimes.  You may have more.
60 60
 
12  rules.mkd
Source Rendered
... ...
@@ -1,11 +1,11 @@
1  
-## #rules access rules
  1
+# #rules access rules
2 2
 
3 3
 In the following description, "user" means "user or a [group][groups] that
4 4
 he/she is a member of", and "repo" means "repo, or a group that it is a member
5 5
 of, or a ([wild][] repo) pattern that matches it, or a group that contains a
6 6
 pattern that matches it".
7 7
 
8  
-### what do rules look like
  8
+## what do rules look like
9 9
 
10 10
 Here's an example ruleset.
11 11
 
@@ -40,12 +40,12 @@ checks and controls that you can't do with just the normal ref (like
40 40
 refs/heads/master) being pushed.  The most common example is restricting
41 41
 pushes by dir/file name, but there are lots of other possibilities.</font>
42 42
 
43  
-### how are the rules checked
  43
+## how are the rules checked
44 44
 
45 45
 Note that gitolite first [accumulates the rules][rule-accum] before checking
46 46
 access.
47 47
 
48  
-#### read access -- clone, fetch, archive
  48
+### read access -- clone, fetch, archive
49 49
 
50 50
 Read access is checked once, just before passing control to git-upload-pack or
51 51
 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
64 64
 it.  (This is the default behaviour.  You can change that by using the
65 65
 [deny-rules][] option).
66 66
 
67  
-#### write access -- push
  67
+### write access -- push
68 68
 
69 69
 Write access is checked twice, once before passing control to
70 70
 git-receive-pack, and once from within the update hook.
@@ -105,7 +105,7 @@ Here's how the actual rule matching happens:
105 105
 Now all you need is to understand how [refex][] matching happens and how the
106 106
 permissions match the various [types of write operations][write-types].
107 107
 
108  
-### #permsum summary of permissions
  108
+## #permsum summary of permissions
109 109
 
110 110
 The full set of permissions, in regex syntax, is `-|R|RW+?C?D?M?`.  This
111 111
 expands to one of `-`, `R`, `RW`, `RW+`, `RWC`, `RW+C`, `RWD`, `RW+D`, `RWCD`,
2  write-types.mkd
Source Rendered
... ...
@@ -1,4 +1,4 @@
1  
-## #write-types different types of write operations
  1
+# #write-types different types of write operations
2 2
 
3 3
 Git supplies enough information to the update hook to be able to distinguish
4 4
 several types of writes.

0 notes on commit bf76dc5

Please sign in to comment.
Something went wrong with that request. Please try again.