git-grep: clarification on parameters.
[gitweb.git] / Documentation / tutorial.txt
index 543afb84e50260599ce8ee804d283770c9e53f16..b8fa29992000f3caec5602a98fe74c9938c8f604 100644 (file)
@@ -968,8 +968,8 @@ $ git show-branch master mybranch
 * [master] Merge work in mybranch
  ! [mybranch] Some work.
 --
-+  [master] Merge work in mybranch
-++ [mybranch] Some work.
+-  [master] Merge work in mybranch
+*+ [mybranch] Some work.
 ------------------------------------------------
 
 The first two lines indicate that it is showing the two branches
@@ -979,7 +979,8 @@ top-of-the-tree commits, you are currently on `master` branch
 the later output lines is used to show commits contained in the
 `master` branch, and the second column for the `mybranch`
 branch. Three commits are shown along with their log messages.
-All of them have plus `+` characters in the first column, which
+All of them have non blank characters in the first column (`*`
+shows an ordinary commit on the current branch, `.` is a merge commit), which
 means they are now part of the `master` branch. Only the "Some
 work" commit has the plus `+` character in the second column,
 because `mybranch` has not been merged to incorporate these
@@ -1024,7 +1025,7 @@ $ git show-branch master mybranch
 ! [master] Merge work in mybranch
  * [mybranch] Merge work in mybranch
 --
-++ [master] Merge work in mybranch
+-- [master] Merge work in mybranch
 ------------------------------------------------
 
 
@@ -1091,9 +1092,10 @@ lacks and transfers (close to) minimum set of objects.
 HTTP(S)::
        `http://remote.machine/path/to/repo.git/`
 +
-HTTP and HTTPS transport are used only for downloading.  They
-first obtain the topmost commit object name from the remote site
-by looking at `repo.git/info/refs` file, tries to obtain the
+Downloader from http and https URL
+first obtains the topmost commit object name from the remote site
+by looking at the specified refname under `repo.git/refs/` directory,
+and then tries to obtain the
 commit object by downloading from `repo.git/objects/xx/xxx\...`
 using the object name of that commit object.  Then it reads the
 commit object to find out its parent commits and the associate
@@ -1104,7 +1106,9 @@ sometimes also called 'commit walkers'.
 The 'commit walkers' are sometimes also called 'dumb
 transports', because they do not require any git aware smart
 server like git Native transport does.  Any stock HTTP server
-would suffice.
+that does not even support directory index would suffice.  But
+you must prepare your repository with `git-update-server-info`
+to help dumb transport downloaders.
 +
 There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload`
 programs, which are 'commit walkers'; they outlived their
@@ -1196,9 +1200,9 @@ $ git show-branch --more=3 master mybranch
 ! [master] Merge work in mybranch
  * [mybranch] Merge work in mybranch
 --
-++ [master] Merge work in mybranch
-++ [master^2] Some work.
-++ [master^] Some fun.
+-- [master] Merge work in mybranch
++* [master^2] Some work.
++* [master^] Some fun.
 ------------
 
 Remember, before running `git merge`, our `master` head was at
@@ -1220,8 +1224,8 @@ $ git show-branch
  ! [mybranch] Some work.
 --
  + [mybranch] Some work.
-+  [master] Some fun.
-++ [mybranch^] New day.
+*  [master] Some fun.
+*+ [mybranch^] New day.
 ------------
 
 Now we are ready to experiment with the merge by hand.
@@ -1517,12 +1521,13 @@ A recommended workflow for a "project lead" goes like this:
 2. Prepare a public repository accessible to others.
 +
 If other people are pulling from your repository over dumb
-transport protocols, you need to keep this repository 'dumb
-transport friendly'.  After `git init-db`,
+transport protocols (HTTP), you need to keep this repository
+'dumb transport friendly'.  After `git init-db`,
 `$GIT_DIR/hooks/post-update` copied from the standard templates
 would contain a call to `git-update-server-info` but the
 `post-update` hook itself is disabled by default -- enable it
-with `chmod +x post-update`.
+with `chmod +x post-update`.  This makes sure `git-update-server-info`
+keeps the necessary files up-to-date.
 
 3. Push into the public repository from your primary
    repository.
@@ -1621,7 +1626,9 @@ cooperation you are probably more familiar with as well.
 For this, set up a public repository on a machine that is
 reachable via SSH by people with "commit privileges".  Put the
 committers in the same user group and make the repository
-writable by that group.
+writable by that group.  Make sure their umasks are set up to
+allow group members to write into directories other members
+have created.
 
 You, as an individual committer, then:
 
@@ -1689,6 +1696,24 @@ You still need to create UNIX user accounts for each developer,
 and put them in the same group.  Make sure that the repository
 shared among these developers is writable by that group.
 
+. Initializing the shared repository with `git-init-db --shared`
+helps somewhat.
+
+. Run the following in the shared repository:
++
+------------
+$ chgrp -R $group repo.git
+$ find repo.git -type d -print | xargs chmod ug+rwx,g+s
+$ GIT_DIR=repo.git git repo-config core.sharedrepository true
+------------
+
+The above measures make sure that directories lazily created in
+`$GIT_DIR` are writable by group members.  You, as the
+repository administrator, are still responsible to make sure
+your developers belong to that shared repository group and set
+their umask to a value no stricter than 027 (i.e. at least allow
+reading and searching by group members).
+
 You can implement finer grained branch policies using update
 hooks.  There is a document ("control access to branches") in
 Documentation/howto by Carl Baldwin and JC outlining how to (1)
@@ -1719,8 +1744,8 @@ $ git show-branch
  +  [diff-fix] Fix rename detection.
  +  [diff-fix~1] Better common substring algorithm.
 +   [commit-fix] Fix commit message normalization.
-  + [master] Release candidate #1
-+++ [diff-fix~2] Pretty-print messages.
+  * [master] Release candidate #1
+++* [diff-fix~2] Pretty-print messages.
 ------------
 
 Both fixes are tested well, and at this point, you want to merge
@@ -1740,13 +1765,13 @@ $ git show-branch
  ! [diff-fix] Fix rename detection.
   * [master] Merge fix in commit-fix
 ---
-  + [master] Merge fix in commit-fix
-+ + [commit-fix] Fix commit message normalization.
-  + [master~1] Merge fix in diff-fix
- ++ [diff-fix] Fix rename detection.
- ++ [diff-fix~1] Better common substring algorithm.
-  + [master~2] Release candidate #1
-+++ [master~3] Pretty-print messages.
+  - [master] Merge fix in commit-fix
++ * [commit-fix] Fix commit message normalization.
+  - [master~1] Merge fix in diff-fix
+ +* [diff-fix] Fix rename detection.
+ +* [diff-fix~1] Better common substring algorithm.
+  * [master~2] Release candidate #1
+++* [master~3] Pretty-print messages.
 ------------
 
 However, there is no particular reason to merge in one branch
@@ -1773,12 +1798,12 @@ $ git show-branch
  ! [diff-fix] Fix rename detection.
   * [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
 ---
-  + [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
-+ + [commit-fix] Fix commit message normalization.
- ++ [diff-fix] Fix rename detection.
- ++ [diff-fix~1] Better common substring algorithm.
-  + [master~1] Release candidate #1
-+++ [master~2] Pretty-print messages.
+  - [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
++ * [commit-fix] Fix commit message normalization.
+ +* [diff-fix] Fix rename detection.
+ +* [diff-fix~1] Better common substring algorithm.
+  * [master~1] Release candidate #1
+++* [master~2] Pretty-print messages.
 ------------
 
 Note that you should not do Octopus because you can.  An octopus