Merge branch 'master' of git://github.com/progit/progit

ar/NOTES

@@ -0,0 +1,18 @@
+ملاحظات حول الترجمة
+=======================
+
+فيما يلي قائمة بالمصطلحات الإنكليزية ومحاولتي لتعريبها، يمكنك المشاركة في تعديل هذه المصطلحات وإقتراح الأفضل إن أردت.
+
+* نظام إدارة الإصدارات = Version Control System.
+* نظم إدارة الإصدارات المحلية = Local Version Control Systems.
+* نظم إدارة الإصدارات المركزية = Centralized Version Control Systens.
+
+
+ملاحظة: ستجد الكلمة الإنكليزية الأصلية بعد ترجمتي المقترحة لها في سياق الكتاب أول مرة تظهر فيها الكلمة في كل فصل فقط (أو أكثر حسب الحاجة).
+
+يحتاج الى ترجمة
+=======================
+
+فيما يلي قائمة بالمصطلحات التي لم استطع العثور على ترجمة صحيحة لها، إذا كان لديك أي إقتراح أرجو التغيير أو المراسة beshrkayali at gmail dot com.
+
+* ش

ar/README

@@ -0,0 +1,14 @@
+محتويات كتاب احترف Git
+=======================
+هذا هو الكود المصدري لكتاب احترف Git. هذا الكتاب مرخص تحت Creative Commons Attribution-Non Commercial-Share Alike 3.0. أتمنى أن تجد فائدة في هذا الكتاب. يمكنك الحصول على نسخة مطبوعة من الكتاب من Apress (لدعم الكاتب) من متجر أمازون:
+
+http://tinyurl.com/amazonprogit
+
+عثرت على خطأ؟
+=======================
+إذا عثرت على أي خطأ تقني أو في الترجمة أرجو منك مراسلتي وإعلامي بالأمر على: schacon at gmail dot com.
+
+
+الترجمة
+=======================
+هذه هي الترجمة العربية لكتاب Pro Git (احترف Git). يمكنك المساعدة في ترجمة الكتاب عن طريق الذهاب الى صفحة المشروع على GitHub.

cs/07-customizing-git/01-chapter7.markdown

@@ -1,4 +1,4 @@
-# Customizing Git #
+# Prizpusobeni Git #
 
 So far, I’ve covered the basics of how Git works and how to use it, and I’ve introduced a number of tools that Git provides to help you use it easily and efficiently. In this chapter, I’ll go through some operations that you can use to make Git operate in a more customized fashion by introducing several important configuration settings and the hooks system. With these tools, it’s easy to get Git to work exactly the way you, your company, or your group needs it to.
 

en/04-git-server/01-chapter4.markdown

@@ -511,7 +511,7 @@ Gitolite allows you to specify permissions not just by repository (like Gitosis
 
 ### Installing ###
 
-Installing Gitolite is very easy, even if you don't read the extensive documentation that comes with it.  You need an account on a Unix server of some kind (various Linux flavours, and Solaris 10, have been tested), with git, perl, and an openssh compatible ssh server installed.  In the examples below, we will use the `gitolite` account on a host called `gitserver`.
+Installing Gitolite is very easy, even if you don't read the extensive documentation that comes with it.  You need an account on a Unix server of some kind; various Linux flavours, and Solaris 10, have been tested.  You do not need root access, assuming git, perl, and an openssh compatible ssh server are already installed.  In the examples below, we will use the `gitolite` account on a host called `gitserver`.
 
 Curiously, Gitolite is installed by running a script *on the workstation*, so your workstation must have a bash shell available.  Even the bash that comes with msysgit will do, in case you're wondering.
 
@@ -538,9 +538,7 @@ That last command does produce a fair amount of output, which might be interesti
 
 ### Customising the Install ###
 
-While the default, quick, install works for most people, there are some ways to customise the install if you need to.  Firstly, there are two other branches that you may be interested in installing, instead of "master".  The "wildrepos" branch allows you to specify repositories by wildcards (regular expressions) in the configuration file; an extremely powerful feature that we will not be covering in this article.  And if your server side git is older than 1.5.6 or so, you should use the "oldgits" branch.
-
-Finally, if you omit the `-q` argument, you get a "verbose" mode install -- detailed information on what the install is doing at each step.  The verbose mode also allows you to change certain server-side parameters, such as the location of the actual repositories, by editing an "rc" file that the server uses.  This "rc" file is liberally commented so you should be able to make any changes you need quite easily, save it, and continue.
+While the default, quick, install works for most people, there are some ways to customise the install if you need to.  If you omit the `-q` argument, you get a "verbose" mode install -- detailed information on what the install is doing at each step.  The verbose mode also allows you to change certain server-side parameters, such as the location of the actual repositories, by editing an "rc" file that the server uses.  This "rc" file is liberally commented so you should be able to make any changes you need quite easily, save it, and continue.  This file also contains various settings that you can change to enable or disable some of gitolite's advanced features.
 
 ### Config File and Access Control Rules ###
 
@@ -601,29 +599,54 @@ There are two levels of access control in gitolite.  The first is at the reposit
 
 The second level, applicable only to "write" access, is by branch or tag within a repository.  The username, the access being attempted (`W` or `+`), and the refname being updated are known.  The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched).  If a match is found, the push succeeds.  A fallthrough results in access being denied.
 
-### Advanced Access Control -- "deny" rules ###
+### Advanced Access Control with "deny" rules ###
 
-As you can see, permissions can be one of `R`, `RW`, or `RW+`.  There is another permission available: `-`, standing for "deny".  This gives you a lot more power, at the expense of some complexity, because now fallthrough is not the *only* way for access to be denied, and so the *order of the rules now matters*!
+So far, we've only seen permissions to be one or `R`, `RW`, or `RW+`.  However, gitolite allows another permission: `-`, standing for "deny".  This gives you a lot more power, at the expense of some complexity, because now fallthrough is not the *only* way for access to be denied, so the *order of the rules now matters*!
 
-Let us say, in the situation above, we want engineers to be able to rewind any branch *except* master and integ.  Here's how:
+Let us say, in the situation above, we want engineers to be able to rewind any branch *except* master and integ.  Here's how to do that:
 
 	    RW  master integ    = @engineers
 	    -   master integ    = @engineers
 	    RW+                 = @engineers
 
-Again, you simply follow the rules top down until you hit a match for your access mode, *or* a deny.  Non-rewind push to master or integ is allowed by the first rule.  A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied.  Any push (rewind or non-rewind) to refs other than master or integ won't match the first two rules anyway, and the third rule allows it.
+Again, you simply follow the rules top down until you hit a match for your access mode, or a deny.  Non-rewind push to master or integ is allowed by the first rule.  A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied.  Any push (rewind or non-rewind) to refs other than master or integ won't match the first two rules anyway, and the third rule allows it.
+
+### Restricting pushes by files changed ###
+
+In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch.  For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*.  You can tell gitolite:
+
+    repo foo
+        RW                  =   @junior_devs @senior_devs
+
+        RW  NAME/           =   @senior_devs
+        -   NAME/Makefile   =   @junior_devs
+        RW  NAME/           =   @junior_devs
+
+This powerful feature is documented in `conf/example.conf`.
 
-If that sounds complicated, you may want to play with it to increase your understanding.  Also, most of the time you don't need "deny" rules anyway, so you can choose to just avoid them if you prefer.
+### Personal Branches ###
+
+Gitolite also has a feature called "personal branches" (or rather, "personal branch namespace") that can be very useful in a corporate environment.
+
+A lot of code exchange in the git world happens by "please pull" requests.  In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there.
+
+This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin.
+
+Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer (for example, `refs/personal/<devname>/*`), with full permissions for that dev only, and read access for everyone else.  Just choose a verbose install and set the `$PERSONAL` variable in the "rc" file to `refs/personal`.  That's all; it's pretty much fire and forget as far as the admin is concerned, even if there is constant churn in the project team composition.
+
+### "Wildcard" repositories ###
+
+Gitolite allows you to specify repositories with wildcards (actually perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example.  This is a *very* powerful feature, which has to be enabled by setting `$GL_WILDREPOS = 1;` in the rc file.  It allows you to assign a new permission mode ("C") which allows users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out R and RW permissions to other users to collaborate, etc.  This feature is documented in `doc/4-wildcard-repositories.mkd`.
 
 ### Other Features ###
 
 We'll round off this discussion with a bunch of other features, all of which are described in great detail in the "faqs, tips, etc" document.
 
-Gitolite logs all successful accesses.  If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away "master", the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed.
+**Logging**: Gitolite logs all successful accesses.  If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away "master", the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed.
 
-One extremely useful convenience feature in gitolite is support for git installed outside the normal `$PATH` (this is more common than you think; some corporate environments or even some hosting providers refuse to install things system-wide and you end up putting them in your own directories).  Normally, you are forced to make the *client-side* git aware of this non-standard location of the git binaries in some way.  With gitolite, just choose a verbose install and set `$GIT_PATH` in the "rc" files.  No client-side changes are required after that :-)
+**Git outside normal PATH**: One extremely useful convenience feature in gitolite is support for git installed outside the normal `$PATH` (this is more common than you think; some corporate environments or even some hosting providers refuse to install things system-wide and you end up putting them in your own directories).  Normally, you are forced to make the *client-side* git aware of this non-standard location of the git binaries in some way.  With gitolite, just choose a verbose install and set `$GIT_PATH` in the "rc" files.  No client-side changes are required after that :-)
 
-Another convenient feature is what happens when you try and just ssh to the server.  Older versions of gitolite used to complain about the `SSH_ORIGINAL_COMMAND` environment variable being empty (see the ssh documentation if interested).  Now Gitolite comes up with something like this:
+**Access rights reporting**: Another convenient feature is what happens when you try and just ssh to the server.  Older versions of gitolite used to complain about the `SSH_ORIGINAL_COMMAND` environment variable being empty (see the ssh documentation if interested).  Now Gitolite comes up with something like this:
 
 	hello sitaram, the gitolite version here is v0.90-9-g91e1e9f
 	you have the following permissions:
@@ -635,15 +658,9 @@ Another convenient feature is what happens when you try and just ssh to the serv
 	  R     indic_web_input
 	  R     shreelipi_converter
 
-For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently.  This reduces the load on the main admin, and makes him less of a bottleneck.  This feature has its own documentation file in the `doc/` directory.
-
-Finally, Gitolite also has a feature called "personal branches" (or rather, "personal branch namespace") that can be very useful in a corporate environment.
+**Delegation**: For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently.  This reduces the load on the main admin, and makes him less of a bottleneck.  This feature has its own documentation file in the `doc/` directory.
 
-A lot of code exchange in the git world happens by "please pull" requests.  In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there.
-
-This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin.
-
-Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer (for example, `refs/personal/<devname>/*`), with full permissions for that dev only, and read access for everyone else.  Just choose a verbose install and set the `$PERSONAL` variable in the "rc" file to `refs/personal`.  That's all; it's pretty much fire and forget as far as the admin is concerned, even if there is constant churn in the project team composition.
+**Gitweb support**: Gitolite supports gitweb in several ways.  You can specify which repos are visible via gitweb.  You can set the "owner" and "description" for gitweb from the gitolite config file.  Gitweb has a mechanism for you to implement access control based on HTTP authentication, so you can make it use the "compiled" config file that gitolite produces, which means the same access control rules (for read access) apply for gitweb and gitolite.
 
 ## Git Daemon ##
 

en/09-git-internals/01-chapter9.markdown

@@ -392,7 +392,7 @@ Notice that the object entry points to the commit SHA-1 value that you tagged. A
 
 	$ git cat-file blob junio-gpg-pub
 
-in the Git source code. The Linux kernel also has a non-commit-pointing tag object — the first tag created points to the initial tree of the import of the source code.
+in the Git source code repository. The Linux kernel repository also has a non-commit-pointing tag object — the first tag created points to the initial tree of the import of the source code.
 
 ### Remotes ###