git\-add git\-*\&.sh
Adds all git\-*\&.sh scripts that are not in the index\&. Because this example lets shell expand the asterisk (i\&.e\&. you are listing the files explicitly), it does not add subdir/git\-foo\&.sh to the index\&.
+.SH "SEE ALSO"
+
+
+\fBgit\-rm\fR(1)
+
.SH "AUTHOR"
.SH "SYNOPSIS"
.nf
-git\-archimport [\-h] [\-v] [\-o] [\-a] [\-f] [\-T] [\-D depth] [\-t tempdir]
+\fIgit\-archimport\fR [\-h] [\-v] [\-o] [\-a] [\-f] [\-T] [\-D depth] [\-t tempdir]
<archive/branch> [ <archive/branch> ]
.fi
Imports a project from one or more Arch repositories\&. It will follow branches and repositories within the namespaces defined by the <archive/branch> parameters supplied\&. If it cannot find the remote branch a merge comes from it will just import it as a regular commit\&. If it can find it, it will mark it as a merge whenever possible (see discussion below)\&.
-The script expects you to provide the key roots where it can start the import from an initial import or tag type of Arch commit\&. It will follow and import new branches within the provided roots\&.
+The script expects you to provide the key roots where it can start the import from an \fIinitial import\fR or \fItag\fR type of Arch commit\&. It will follow and import new branches within the provided roots\&.
It expects to be dealing with one project only\&. If it sees branches that have different roots, it will refuse to run\&. In that case, edit your <archive/branch> parameters to define clearly the scope of the import\&.
.SH "SYNOPSIS"
-git\-fetch\-pack [\-q] [\-k] [\-\-exec=<git\-upload\-pack>] [<host>:]<directory> [<refs>...]
+\fIgit\-fetch\-pack\fR [\-q] [\-k] [\-\-exec=<git\-upload\-pack>] [<host>:]<directory> [<refs>...]
.SH "DESCRIPTION"
-Invokes git\-upload\-pack on a potentially remote repository, and asks it to send objects missing from this repository, to update the named heads\&. The list of commits available locally is found out by scanning local $GIT_DIR/refs/ and sent to git\-upload\-pack running on the other end\&.
+Invokes \fIgit\-upload\-pack\fR on a potentially remote repository, and asks it to send objects missing from this repository, to update the named heads\&. The list of commits available locally is found out by scanning local $GIT_DIR/refs/ and sent to \fIgit\-upload\-pack\fR running on the other end\&.
This command degenerates to download everything to complete the asked refs from the remote side when the local side does not have a common ancestor commit\&.
.TP
\-q
-Pass \-q flag to git\-unpack\-objects; this makes the cloning process less verbose\&.
+Pass \fI\-q\fR flag to \fIgit\-unpack\-objects\fR; this makes the cloning process less verbose\&.
.TP
\-k
-Do not invoke git\-unpack\-objects on received data, but create a single packfile out of it instead, and store it in the object database\&.
+Do not invoke \fIgit\-unpack\-objects\fR on received data, but create a single packfile out of it instead, and store it in the object database\&.
.TP
\-\-exec=<git\-upload\-pack>
-Use this to specify the path to git\-upload\-pack on the remote side, if is not found on your $PATH\&. Installations of sshd ignores the user's environment setup scripts for login shells (e\&.g\&. \&.bash_profile) and your privately installed git may not be found on the system default $PATH\&. Another workaround suggested is to set up your $PATH in "\&.bashrc", but this flag is for people who do not want to pay the overhead for non\-interactive shells by having a lean \&.bashrc file (they set most of the things up in \&.bash_profile)\&.
+Use this to specify the path to \fIgit\-upload\-pack\fR on the remote side, if is not found on your $PATH\&. Installations of sshd ignores the user's environment setup scripts for login shells (e\&.g\&. \&.bash_profile) and your privately installed git may not be found on the system default $PATH\&. Another workaround suggested is to set up your $PATH in "\&.bashrc", but this flag is for people who do not want to pay the overhead for non\-interactive shells by having a lean \&.bashrc file (they set most of the things up in \&.bash_profile)\&.
.TP
<host>
-A remote host that houses the repository\&. When this part is specified, git\-upload\-pack is invoked via ssh\&.
+A remote host that houses the repository\&. When this part is specified, \fIgit\-upload\-pack\fR is invoked via ssh\&.
.TP
<directory>
.SH "SYNOPSIS"
-\fIgit\-pack\-redundant [ \-\-verbose ] [ \-\-alt\-odb ] < \-\-all | \&.pack filename ... >\fR
+\fIgit\-pack\-redundant\fR [ \-\-verbose ] [ \-\-alt\-odb ] < \-\-all | \&.pack filename ... >
.SH "DESCRIPTION"
git\-rm \-f git\-*\&.sh
Remove all git\-*\&.sh scripts that are in the index\&. The files are removed from the index, and (because of the \-f option), from the working tree as well\&. 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\&.
+.SH "SEE ALSO"
+
+
+\fBgit\-add\fR(1)
+
.SH "AUTHOR"
.SH "SYNOPSIS"
-
git\-shell \-c <command> <argument>
+
\fIgit\-shell\fR \-c <command> <argument>
.SH "DESCRIPTION"
-This is meant to be used as a login shell for SSH accounts you want to restrict to GIT pull/push access only\&. It permits execution only of server\-side GIT commands implementing the pull/push functionality\&. The commands can be executed only by the \-c option; the shell is not interactive\&.
+This is meant to be used as a login shell for SSH accounts you want to restrict to GIT pull/push access only\&. It permits execution only of server\-side GIT commands implementing the pull/push functionality\&. The commands can be executed only by the \fI\-c\fR option; the shell is not interactive\&.
Currently, only the git\-receive\-pack and git\-upload\-pack commands are permitted to be called, with a single required argument\&.
.SH "SYNOPSIS"
-git\-log \-\-pretty=short | git shortlog
+git\-log \-\-pretty=short | \fIgit\-shortlog\fR
.SH "DESCRIPTION"
-Summarizes git log output in a format suitable for inclusion in release announcements\&.
+Summarizes \fIgit log\fR output in a format suitable for inclusion in release announcements\&.
.SH "AUTHOR"
.SH "SYNOPSIS"
.nf
-git\-show\-branch [\-\-all] [\-\-heads] [\-\-tags] [\-\-topo\-order] [\-\-current]
- [\-\-more=<n> | \-\-list | \-\-independent | \-\-merge\-base]
- [\-\-no\-name | \-\-sha1\-name] [<rev> | <glob>]...
+\fIgit\-show\-branch\fR [\-\-all] [\-\-heads] [\-\-tags] [\-\-topo\-order] [\-\-current]
+ [\-\-more=<n> | \-\-list | \-\-independent | \-\-merge\-base]
+ [\-\-no\-name | \-\-sha1\-name] [<rev> | <glob>]...
.fi
.SH "DESCRIPTION"
.TP
\-\-merge\-base
-Instead of showing the commit list, just act like the git\-merge\-base \-a command, except that it can accept more than two heads\&.
+Instead of showing the commit list, just act like the \fIgit\-merge\-base \-a\fR command, except that it can accept more than two heads\&.
.TP
\-\-independent
+ [mhf~8] Start adding the $GIT_DIR/remotes/ support\&.
*++ [master] Add 'git show\-branch'\&.
-These three branches all forked from a common commit, [master], whose commit message is "Add git show\-branch\&. "fixes" branch adds one commit Introduce "reset type"\&. "mhf" branch has many other commits\&. The current branch is "master"\&.
+These three branches all forked from a common commit, [master], whose commit message is "Add \fIgit show\-branch\fR\&. "fixes" branch adds one commit \fIIntroduce "reset type"\fR\&. "mhf" branch has many other commits\&. The current branch is "master"\&.
.SH "EXAMPLE"
.SH "SYNOPSIS"
-
git\-update\-ref <ref> <newvalue> [<oldvalue>]
+
\fIgit\-update\-ref\fR <ref> <newvalue> [<oldvalue>]
.SH "DESCRIPTION"
It also allows a "ref" file to be a symbolic pointer to another ref file by starting with the four\-byte header sequence of "ref:"\&.
-More importantly, it allows the update of a ref file to follow these symbolic pointers, whether they are symlinks or these "regular file symbolic refs"\&. It follows real symlinks only if they start with "refs/": otherwise it will just try to read them and update them as a regular file (i\&.e\&. it will allow the filesystem to follow them, but will overwrite such a symlink to somewhere else with a regular filename)\&.
+More importantly, it allows the update of a ref file to follow these symbolic pointers, whether they are symlinks or these "regular file symbolic refs"\&. It follows \fIreal\fR symlinks only if they start with "refs/": otherwise it will just try to read them and update them as a regular file (i\&.e\&. it will allow the filesystem to follow them, but will overwrite such a symlink to somewhere else with a regular filename)\&.
In general, using
.fi
-both from a symlink following standpoint and an error checking standpoint\&. The "refs/" rule for symlinks means that symlinks that point to "outside" the tree are safe: they'll be followed for reading but not for writing (so we'll never write through a ref symlink to some other tree, if you have copied a whole archive by creating a symlink tree)\&.
+both from a symlink following standpoint \fIand\fR an error checking standpoint\&. The "refs/" rule for symlinks means that symlinks that point to "outside" the tree are safe: they'll be followed for reading but not for writing (so we'll never write through a ref symlink to some other tree, if you have copied a whole archive by creating a symlink tree)\&.
.SH "AUTHOR"
.SH "SYNOPSIS"
-git\-var [ \-l | <variable> ]
+\fIgit\-var\fR [ \-l | <variable> ]
.SH "DESCRIPTION"
projects / git.git / commitdiff