GITANO: Complete initial rename

9 files changed, 64 insertions, 64 deletions

diff --git a/notes/admin-layout b/notes/admin-layout
index c3a04cf..aa6a7de 100644
--- a/notes/admin-layout
+++ b/notes/admin-layout
@@ -1,8 +1,8 @@
-Layout of the legit-admin repo for an installation
---------------------------------------------------
+Layout of the gitano-admin repo for an installation
+---------------------------------------------------
 
 site.conf
-	Site configuration for legit, including the name of the site, etc.
+	Site configuration for gitano, including the name of the site, etc.
 
 core.rules
 	Core rules for administering the site.
@@ -38,7 +38,7 @@ groups/
 	may not form any loops.
 
 
-Note, you cannot have two users with the same name or legit will refuse to
+Note, you cannot have two users with the same name or gitano will refuse to
 compile the rules at the head and *will* walk back in history to find a
 compileable set of rules.  This applies to groups also.  Users and groups do
 not share the same namespace however.
diff --git a/notes/delegated-management b/notes/delegated-management
index 8865c29..faa5c28 100644
--- a/notes/delegated-management
+++ b/notes/delegated-management
@@ -1,8 +1,8 @@
-Delegated management in Legit
------------------------------
+Delegated management in Gitano
+------------------------------
 
-If you wish to delegate management in legit then the rules syntax can provide a
-very effective way to delegate access to the legit-admin repository.
+If you wish to delegate management in gitano then the rules syntax can provide a
+very effective way to delegate access to the gitano-admin repository.
 
 In particular, you could use a ruleset like:
 
@@ -26,7 +26,7 @@ if you want users to be able to alter their own.
 
 If you use either of the above rules to allow delegated administration, you
 probably want to pop a 'GrantClone(Group "some-admin-group")' and a
-'DenyClone(User "legit/any")' at the top of your legit-admin repository rules
+'DenyClone(User "gitano/any")' at the top of your gitano-admin repository rules
 file.
 
 If you're not worried about the security of the site should the admin repo be
@@ -34,16 +34,16 @@ cloned by a non-admin then don't worry about those.  It shouldn't be an issue
 unless you also store non-standard admin content which could be exploited, or
 unless your user list or users' keys are considered secret.  Later if we store
 email addresses etc in users' metadata files then it may be 'secret'.  As such,
-the *default* legit-admin repo-specific rules will contain:
+the *default* gitano-admin repo-specific rules will contain:
 
 ---8<----
 GrantClone(User "whatever")
-DenyClone(User "legit/any")
+DenyClone(User "gitano/any")
 ---8<----
 
-Where 'whatever' is the username you gave legit when it created your
+Where 'whatever' is the username you gave gitano when it created your
 fundamental admin repository commit.
 
-By default, when you set up legit, the legit-admin repository is created with
-the deny rules above and a group called legit-admin which contains the one user
+By default, when you set up gitano, the gitano-admin repository is created with
+the deny rules above and a group called gitano-admin which contains the one user
 created during setup.
diff --git a/notes/example-group.conf b/notes/example-group.conf
index f5bb3f2..4404085 100644
--- a/notes/example-group.conf
+++ b/notes/example-group.conf
@@ -1,5 +1,5 @@
 -- This is an example group config file (-*- Lua -*-)
--- Note that legit *can* rewrite these files, so don't expect the comments to
+-- Note that gitano *can* rewrite these files, so don't expect the comments to
 -- remain.
 
 -- Mandatory, string, may be empty
diff --git a/notes/example-site.conf b/notes/example-site.conf
index 581f4b4..445998d 100644
--- a/notes/example-site.conf
+++ b/notes/example-site.conf
@@ -1,8 +1,8 @@
 -- Example site.conf
 --
 
-site_name = "My example Legit repo server"
+site_name = "My example Gitano repo server"
 
-repository_root = "/home/legit/repositories"
+repository_root = "/home/gitano/repositories"
 
-bin_path = "/home/legit/bin"
+bin_path = "/home/gitano/bin"
diff --git a/notes/example-user.conf b/notes/example-user.conf
index 1d96563..a0bea07 100644
--- a/notes/example-user.conf
+++ b/notes/example-user.conf
@@ -1,5 +1,5 @@
 -- Example user.conf file for a user (-*- Lua -*-)
--- Note that legit *can* rewrite these files, so don't expect the comments to
+-- Note that gitano *can* rewrite these files, so don't expect the comments to
 -- remain.
 
 -- real_name is mandatory (but can be empty)
diff --git a/notes/rules-evaluation b/notes/rules-evaluation
index 6235fbe..a063b8a 100644
--- a/notes/rules-evaluation
+++ b/notes/rules-evaluation
@@ -1,31 +1,31 @@
-Evaluation of rules in Legit
-----------------------------
+Evaluation of rules in Gitano
+-----------------------------
 
-Rules in legit are a "first match wins" mechanism of controlling access to a
+Rules in gitano are a "first match wins" mechanism of controlling access to a
 repository.  There are two sources of rules for a respository.  The first set
 of rules considered is the rules explicitly stated in the repository in
-question.  Those rules are stored in the refs/legit/site-admin branch of the
+question.  Those rules are stored in the refs/gitano/site-admin branch of the
 repository, access to which is being considered.  The second source of rules is
-the core.rules file in the legit-admin repository's master branch.
+the core.rules file in the gitano-admin repository's master branch.
 
-Legit defines a set of magical user/group names which always start 'legit/' and
-since the admin layout does not allow for users or groups to be created
+Gitano defines a set of magical user/group names which always start 'gitano/'
+and since the admin layout does not allow for users or groups to be created
 
 By default, the core.rules file (which is *never* automatically rewritten by
-the legit tools and thus can have commentary etc in it) defines a few useful
-rules which form the basis of a legit install.
+the gitano tools and thus can have commentary etc in it) defines a few useful
+rules which form the basis of a gitano install.
 
-The default set of core.rules legit will install in a fresh legit-admin
+The default set of core.rules gitano will install in a fresh gitano-admin
 repository are:
 
 ---8<----
-GrantClone(User "legit/any")
-GrantWrite(User "legit/owner")
+GrantClone(User "gitano/any")
+GrantWrite(User "gitano/owner")
 ---8<----
 
 This means that if the rule evaluator falls off the end of the
 repository-specific rules then as a last ditch effort we grant anonymous clone
 and full write/delete/etc access to the user marked as the owner of the
-repository.  If evaluation ever falls off the end of the core rules then Legit
-evaluates the built in stop-gap rule of 'Deny(User "legit/any")' which
+repository.  If evaluation ever falls off the end of the core rules then Gitano
+evaluates the built in stop-gap rule of 'Deny(User "gitano/any")' which
 effectively denies everything to everyone.
diff --git a/notes/rules-format b/notes/rules-format
index 223f216..2b5c7a2 100644
--- a/notes/rules-format
+++ b/notes/rules-format
@@ -1,20 +1,20 @@
-Format of rules files for Legit
--------------------------------
+Format of rules files for Gitano
+--------------------------------
 
-Legit adminsters rules at various levels.  For example they define what users
+Gitano adminsters rules at various levels.  For example they define what users
 and groups have access to each repository, what paths and what branches within
 that repository.
 
 Apart from the core rules file in the admin repository, whose purpose it is to
 provide a set of core rules in case everything else goes wrong, the rules files
-are always stored in the refs/legit/site-admin branch in the repositories in
+are always stored in the refs/gitano/site-admin branch in the repositories in
 question.
 
-The rules file for a repository will be rewritten by Legit on the server side
-(and possibly by Legit or users on the client side) and as such any comments or
-non-standard structures will end up elided during parse/rewrite.  Do not expect
-to store commentary in the rules files which are stored in the
-refs/legit/site-admin branch.
+The rules file for a repository will be rewritten by Gitano on the server side
+(and possibly by Gitano or users on the client side) and as such any comments
+or non-standard structures will end up elided during parse/rewrite.  Do not
+expect to store commentary in the rules files which are stored in the
+refs/gitano/site-admin branch.
 
 Rules files are essentially Lua scripts which a very tight syntax.  They have
 no access to any of the loaded modules, nor to any of the normal function such
@@ -30,7 +30,7 @@ Example rules file for myfrobbler:
 ---8<-----
 GrantFFWrite(Branch "master", User "myfrobbler-pqm")
 
-DenyWrite(Branch "master", User "legit/any")
+DenyWrite(Branch "master", User "gitano/any")
 
 GrantWrite(Branch "devs/$USER/**", Group "myfrobbler-devs")
 ---8<-----
diff --git a/notes/rules-magical b/notes/rules-magical
index 33b7dd7..39c6e8c 100644
--- a/notes/rules-magical
+++ b/notes/rules-magical
@@ -1,19 +1,19 @@
-Magical parts of Legit rules
-----------------------------
+Magical parts of Gitano rules
+-----------------------------
 
-In order to make your life easier, Legit defines a bunch of magical stuff to
+In order to make your life easier, Gitano defines a bunch of magical stuff to
 help your rules.
 
 For example, the following users and groups are magical:
 
 
-legit/owner                                                                USER
+gitano/owner                                                               USER
 	This evaluates to the user who is marked as owning a repository.
 
-legit/any                                                                  USER
+gitano/any                                                                 USER
 	This evaluates to 'true' regardless of the user calling in.
 	i.e. it is anonymous PLUS every registered user.
 
-legit/anonymous                                                            USER
+gitano/anonymous                                                           USER
 	This evaluates to the 'anonymous' access user (i.e. gitweb and git://)
 
diff --git a/notes/rules-nitty-gritty b/notes/rules-nitty-gritty
index cf12f0f..fe9b09f 100644
--- a/notes/rules-nitty-gritty
+++ b/notes/rules-nitty-gritty
@@ -13,19 +13,19 @@ In addition to the immutable data, rules can create, update and delete other
 tags associated with the request as the rules processing is underway.  This
 allows for potentially complex rulesets.
 
-The moment the 'legit/action' tag is created, that action is taken.  Thus a
-Grant operation actually ends up setting the 'legit/action' tag to 'allow'.
+The moment the 'gitano/action' tag is created, that action is taken.  Thus a
+Grant operation actually ends up setting the 'gitano/action' tag to 'allow'.
 
-The values the legit/action tag is allowed to take are:
+The values the gitano/action tag is allowed to take are:
 
     allow -- Allow the requested operation to take place.
     deny  -- Prevent the requested operation from happening.
 
 Any value other than 'allow' will be treated as 'deny'.  In addition, if the
-action is to deny the operation then if legit/reason is set, it will be
+action is to deny the operation then if gitano/reason is set, it will be
 provided to the user.
 
-If the legit/callout tag is created then the current rule processing is
+If the gitano/callout tag is created then the current rule processing is
 suspended and the referenced ruleset is called out to.  This allows more
 complex "subroutines" to be created by admins without having unpleasant huge
 rulesets.  If a callout ends up calling out to a ruleset already in the call
@@ -34,22 +34,22 @@ stack then rules processing immediately stops with a 'deny' whose reason is
 actually result from the callout.
 
 Each rule consists of a number of match operations and a number of tag
-manipulation operations.  For example a rule might match legit/operation
-against "write", legit/repository against "^myproject$" (note the .git is
-stripped during rule evaluation) and legit/groups against "/myproject-members/"
-and would then set legit/action to allow.
+manipulation operations.  For example a rule might match gitano/operation
+against "write", gitano/repository against "^myproject$" (note the .git is
+stripped during rule evaluation) and gitano/groups against
+"/myproject-members/" and would then set gitano/action to allow.
 
 Such a rule might be expressed as:
 
 GrantWrite(Group "myproject-members")
 
-and be present in the myproject legit/admin branch rules file.
+and be present in the myproject gitano/admin branch rules file.
 
 Rules extracted from the admin branch of a project automatically have a match
 against the project added to them.  (and since the rules will only be loaded if
 that project is referenced, it all makes sense)
 
-Tags in legit/ are all immutable except for the action and reason tags and the
+Tags in gitano/ are all immutable except for the action and reason tags and the
 callout tag.
 
 Tags in $projectname/ are mutable to rules which match the projectname exactly.
@@ -73,11 +73,11 @@ the function called Expand.
 
 So at its core, you add rules in the following way:
 
-Rule({ "match", "legit/groups", "/${legit/project}-members/" },
-     { "match", "legit/operation", "write" },
-     { "set", "legit/action", "allow" })
+Rule({ "match", "gitano/groups", "/${gitano/project}-members/" },
+     { "match", "gitano/operation", "write" },
+     { "set", "gitano/action", "allow" })
 
 The 'Rule' statement here, in a repository's administration branch, will
-implicitly add {"match", "legit/repository", "^thisrepositoryname$"} narrowing
+implicitly add {"match", "gitano/repository", "^thisrepositoryname$"} narrowing
 the ruleset so that no mistakes can be made.