diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/git-config.txt | 2 | ||||
| -rw-r--r-- | Documentation/git-cvsserver.txt | 28 | ||||
| -rw-r--r-- | Documentation/git-rm.txt | 52 | ||||
| -rw-r--r-- | Documentation/howto/setup-git-server-over-http.txt | 45 |
4 files changed, 84 insertions, 43 deletions
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index fa161718dd..5de5d051b7 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -144,6 +144,8 @@ See also <<FILES>>. "auto". If `stdout-is-tty` is missing, then checks the standard output of the command itself, and exits with status 0 if color is to be used, or exits with status 1 otherwise. + When the color setting for `name` is undefined, the command uses + `color.ui` as fallback. --get-color name default:: diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt index 9cec8021b8..b1106714b2 100644 --- a/Documentation/git-cvsserver.txt +++ b/Documentation/git-cvsserver.txt @@ -110,7 +110,9 @@ cvs -d ":ext;CVS_SERVER=git-cvsserver:user@server/path/repo.git" co <HEAD_name> ------ This has the advantage that it will be saved in your 'CVS/Root' files and you don't need to worry about always setting the correct environment -variable. +variable. SSH users restricted to git-shell don't need to override the default +with CVS_SERVER (and shouldn't) as git-shell understands `cvs` to mean +git-cvsserver and pretends that the other end runs the real cvs better. -- 2. For each repo that you want accessible from CVS you need to edit config in the repo and add the following section. @@ -141,25 +143,29 @@ allowing access over SSH. enabled=1 ------ -- -3. On the client machine you need to set the following variables. - CVSROOT should be set as per normal, but the directory should point at the - appropriate git repo. For example: +3. If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command, + automatically saving it in your 'CVS/Root' files, then you need to set them + explicitly in your environment. CVSROOT should be set as per normal, but the + directory should point at the appropriate git repo. As above, for SSH clients + _not_ restricted to git-shell, CVS_SERVER should be set to git-cvsserver. + -- -For SSH access, CVS_SERVER should be set to git-cvsserver - -Example: - ------ export CVSROOT=:ext:user@server:/var/git/project.git export CVS_SERVER=git-cvsserver ------ -- -4. For SSH clients that will make commits, make sure their .bashrc file - sets the GIT_AUTHOR and GIT_COMMITTER variables. +4. For SSH clients that will make commits, make sure their server-side + .ssh/environment files (or .bashrc, etc., according to their specific shell) + export appropriate values for GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, + GIT_COMMITTER_NAME, and GIT_COMMITTER_EMAIL. For SSH clients whose login + shell is bash, .bashrc may be a reasonable alternative. 5. Clients should now be able to check out the project. Use the CVS 'module' - name to indicate what GIT 'head' you want to check out. Example: + name to indicate what GIT 'head' you want to check out. This also sets the + name of your newly checked-out directory, unless you tell it otherwise with + `-d <dir_name>`. For example, this checks out 'master' branch to the + `project-master` directory: + ------ cvs co -d project-master master diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt index dc36c662ae..9c81b72dbe 100644 --- a/Documentation/git-rm.txt +++ b/Documentation/git-rm.txt @@ -11,28 +11,37 @@ SYNOPSIS DESCRIPTION ----------- -Remove files from the working tree and from the index. The -files have to be identical to the tip of the branch, and no -updates to its contents must have been placed in the staging -area (aka index). When --cached is given, the staged content has to -match either the tip of the branch *or* the file on disk. +Remove files from the index, or from the working tree and the index. +`git rm` will not remove a file from just your working directory. +(There is no option to remove a file only from the work tree +and yet keep it in the index; use `/bin/rm` if you want to do that.) +The files being removed have to be identical to the tip of the branch, +and no updates to their contents can be staged in the index, +though that default behavior can be overridden with the `-f` option. +When '--cached' is given, the staged content has to +match either the tip of the branch or the file on disk, +allowing the file to be removed from just the index. OPTIONS ------- <file>...:: Files to remove. Fileglobs (e.g. `*.c`) can be given to - remove all matching files. Also a leading directory name - (e.g. `dir` to add `dir/file1` and `dir/file2`) can be - given to remove all files in the directory, recursively, - but this requires `-r` option to be given for safety. + remove all matching files. If you want git to expand + file glob characters, you may need to shell-escape them. + A leading directory name + (e.g. `dir` to remove `dir/file1` and `dir/file2`) can be + given to remove all files in the directory, and recursively + all sub-directories, + but this requires the `-r` option to be explicitly given. -f:: Override the up-to-date check. -n, \--dry-run:: - Don't actually remove the file(s), just show if they exist in - the index. + Don't actually remove any file(s). Instead, just show + if they exist in the index and would otherwise be removed + by the command. -r:: Allow recursive removal when a leading directory name is @@ -44,9 +53,9 @@ OPTIONS for command-line options). \--cached:: - This option can be used to tell the command to remove - the paths only from the index, leaving working tree - files. + Use this option to unstage and remove paths only from the index. + Working tree files, whether modified or not, will be + left alone. \--ignore-unmatch:: Exit with a zero status even if no files matched. @@ -59,11 +68,15 @@ OPTIONS DISCUSSION ---------- -The list of <file> given to the command can be exact pathnames, -file glob patterns, or leading directory name. The command -removes only the paths that is known to git. Giving the name of +The <file> list given to the command can be exact pathnames, +file glob patterns, or leading directory names. The command +removes only the paths that are known to git. Giving the name of a file that you have not told git about does not remove that file. +File globbing matches across directory boundaries. Thus, given +two directories `d` and `d2`, there is a difference between +using `git rm \'d\*\'` and `git rm \'d/\*\'`, as the former will +also remove all of directory `d2`. EXAMPLES -------- @@ -72,11 +85,10 @@ git-rm Documentation/\\*.txt:: `Documentation` directory and any of its subdirectories. + Note that the asterisk `\*` is quoted from the shell in this -example; this lets the command include the files from -subdirectories of `Documentation/` directory. +example; this lets git, and not the shell, expand the pathnames +of files and subdirectories under the `Documentation/` directory. git-rm -f git-*.sh:: - Remove all git-*.sh scripts that are in the index. Because this example lets the shell expand the asterisk (i.e. you are listing the files explicitly), it does not remove `subdir/git-foo.sh`. diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt index 8eadc20494..b7d09c1ec6 100644 --- a/Documentation/howto/setup-git-server-over-http.txt +++ b/Documentation/howto/setup-git-server-over-http.txt @@ -1,5 +1,5 @@ From: Rutger Nijlunsing <rutger@nospam.com> -Subject: Setting up a git repository which can be pushed into and pulled from over HTTP. +Subject: Setting up a git repository which can be pushed into and pulled from over HTTP(S). Date: Thu, 10 Aug 2006 22:00:26 +0200 Since Apache is one of those packages people like to compile @@ -40,9 +40,13 @@ What's needed: - have permissions to chown a directory -- have git installed at the server _and_ client +- have git installed on the client, and -In effect, this probably means you're going to be root. +- either have git installed on the server or have a webdav client on + the client. + +In effect, this means you're going to be root, or that you're using a +preconfigured WebDAV server. Step 1: setup a bare GIT repository @@ -50,9 +54,9 @@ Step 1: setup a bare GIT repository At the time of writing, git-http-push cannot remotely create a GIT repository. So we have to do that at the server side with git. Another -option would be to generate an empty repository at the client and copy -it to the server with WebDAV. But then you're probably the first to -try that out :) +option is to generate an empty bare repository at the client and copy +it to the server with a WebDAV client (which is the only option if Git +is not installed on the server). Create the directory under the DocumentRoot of the directories served by Apache. As an example we take /usr/local/apache2, but try "grep @@ -169,7 +173,9 @@ On Debian: Most tests should pass. -A command line tool to test WebDAV is cadaver. +A command line tool to test WebDAV is cadaver. If you prefer GUIs, for +example, konqueror can open WebDAV URLs as "webdav://..." or +"webdavs://...". If you're into Windows, from XP onwards Internet Explorer supports WebDAV. For this, do Internet Explorer -> Open Location -> @@ -179,8 +185,9 @@ http://<servername>/my-new-repo.git [x] Open as webfolder -> login . Step 3: setup the client ------------------------ -Make sure that you have HTTP support, i.e. your git was built with curl. -The easiest way to check is to look for the executable 'git-http-push'. +Make sure that you have HTTP support, i.e. your git was built with +curl (version more recent than 7.10). The command 'git http-push' with +no argument should display a usage message. Then, add the following to your $HOME/.netrc (you can do without, but will be asked to input your password a _lot_ of times): @@ -197,10 +204,10 @@ instead of the server name. To check whether all is OK, do: - curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/ - -...this should give a directory listing in HTML of /var/www/my-new-repo.git . + curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/HEAD +...this should give something like 'ref: refs/heads/master', which is +the content of the file HEAD on the server. Now, add the remote in your existing repository which contains the project you want to export: @@ -225,6 +232,15 @@ want to export) to repository called 'upload', which we previously defined with git-config. +Using a proxy: +-------------- + +If you have to access the WebDAV server from behind an HTTP(S) proxy, +set the variable 'all_proxy' to 'http://proxy-host.com:port', or +'http://login-on-proxy:passwd-on-proxy@proxy-host.com:port'. See 'man +curl' for details. + + Troubleshooting: ---------------- @@ -248,9 +264,14 @@ Reading /usr/local/apache2/logs/error_log is often helpful. On Debian: Read /var/log/apache2/error.log instead. +If you access HTTPS locations, git may fail verifying the SSL +certificate (this is return code 60). Setting http.sslVerify=false can +help diagnosing the problem, but removes security checks. + Debian References: http://www.debian-administration.org/articles/285 Authors Johannes Schindelin <Johannes.Schindelin@gmx.de> Rutger Nijlunsing <git@wingding.demon.nl> + Matthieu Moy <Matthieu.Moy@imag.fr> |