Do not show any source or destination prefix.
For more detailed explanation on these common options, see also
-linkgit:gitdiffcore[7][diffcore documentation].
+linkgit:gitdiffcore[7].
The optional configuration variable 'core.excludesfile' indicates a path to a
file containing patterns of file names to exclude from git-add, similar to
$GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to
-those in info/exclude. See linkgit:gitrepository-layout[5][repository layout].
+those in info/exclude. See linkgit:gitrepository-layout[5].
EXAMPLES
-n::
--no-verify::
This option bypasses the pre-commit and commit-msg hooks.
- See also linkgit:githooks[5][hooks].
+ See also linkgit:githooks[5].
--allow-empty::
Usually recording a commit that has the exact same tree as its
HOOKS
-----
This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
-and `post-commit` hooks. See linkgit:githooks[5][hooks] for more
+and `post-commit` hooks. See linkgit:githooks[5] for more
information.
------
Currently the command updates the following files. Please see
-linkgit:gitrepository-layout[5][repository-layout] for description of
+linkgit:gitrepository-layout[5] for description of
what they are for:
* objects/info/packs
unusually rich command set that provides both high-level operations
and full access to internals.
-See this linkgit:gittutorial[7][tutorial] to get started, then see
+See linkgit:gittutorial[7] to get started, then see
link:everyday.html[Everyday Git] for a useful minimum set of commands, and
"man git-commandname" for documentation of each command. CVS users may
-also want to read linkgit:gitcvs-migration[7][CVS migration]. See
-link:user-manual.html[Git User's Manual] for a more in-depth
+also want to read linkgit:gitcvs-migration[7]. See
+the link:user-manual.html[Git User's Manual] for a more in-depth
introduction.
The COMMAND is either a name of a Git command (see below) or an alias
probably more detail than necessary for a first-time user.
The link:user-manual.html#git-concepts[git concepts chapter of the
-user-manual] and the linkgit:gitcore-tutorial[7][Core tutorial] both provide
+user-manual] and linkgit:gitcore-tutorial[7] both provide
introductions to the underlying git architecture.
See also the link:howto-index.html[howto] documents for some useful
examples.
-The internals are documented link:technical/api-index.html[here].
+The internals are documented in the
+link:technical/api-index.html[GIT API documentation].
GIT COMMANDS
------------
File/Directory Structure
------------------------
-Please see the linkgit:gitrepository-layout[5][repository layout]
-document.
+Please see the linkgit:gitrepository-layout[5] document.
-Read linkgit:githooks[5][hooks] for more details about each hook.
+Read linkgit:githooks[5] for more details about each hook.
Higher level SCMs may provide and manage additional information in the
`$GIT_DIR`.
Terminology
-----------
-Please see the linkgit:gitglossary[7][glossary] document.
+Please see linkgit:gitglossary[7].
Environment Variables
More detail on the following is available from the
link:user-manual.html#git-concepts[git concepts chapter of the
-user-manual] and the linkgit:gitcore-tutorial[7][Core tutorial].
+user-manual] and linkgit:gitcore-tutorial[7].
A git project normally consists of a working directory with a ".git"
subdirectory at the top level. The .git directory contains, among other
work with a git repository.
If you just need to use git as a revision control system you may prefer
-to start with linkgit:gittutorial[7][a tutorial introduction to git] or
-link:user-manual.html[the git user manual].
+to start with "A Tutorial Introduction to GIT" (linkgit:gittutorial[7]) or
+link:user-manual.html[the GIT User Manual].
However, an understanding of these low-level tools can be helpful if
you want to understand git's internals.
populating your tree.
[NOTE]
-An advanced user may want to take a look at the
-linkgit:gitrepository-layout[5][repository layout] document
+An advanced user may want to take a look at linkgit:gitrepository-layout[5]
after finishing this tutorial.
You have now created your first git repository. Of course, since it's
have to worry. git supports "shared public repository" style of
cooperation you are probably more familiar with as well.
-See linkgit:gitcvs-migration[7][git for CVS users] for the details.
+See linkgit:gitcvs-migration[7] for the details.
Bundling your work together
---------------------------
designating a single shared repository which people can synchronize with;
this document explains how to do that.
-Some basic familiarity with git is required. This
-linkgit:gittutorial[7][tutorial introduction to git] and the
-linkgit:gitglossary[7][git glossary] should be sufficient.
+Some basic familiarity with git is required. Having gone through
+linkgit:gittutorial[7] and
+linkgit:gitglossary[7] should be sufficient.
Developing against a shared repository
--------------------------------------
------------------------------
We assume you have already created a git repository for your project,
-possibly created from scratch or from a tarball (see the
-linkgit:gittutorial[7][tutorial]), or imported from an already existing CVS
+possibly created from scratch or from a tarball (see
+linkgit:gittutorial[7]), or imported from an already existing CVS
repository (see the next section).
Assume your existing repo is at /home/alice/myproject. Create a new "bare"
Git allows you to specify scripts called "hooks" to be run at certain
points. You can use these, for example, to send all commits to the shared
-repository to a mailing list. See linkgit:githooks[5][Hooks used by git].
+repository to a mailing list. See linkgit:githooks[5].
You can enforce finer grained permissions using update hooks. See
link:howto/update-hook-example.txt[Controlling access to branches using
commands. A handful of sample hooks are installed when
`git init` is run, but all of them are disabled by
default. To enable, they need to be made executable.
- Read linkgit:githooks[5][hooks] for more details about
+ Read linkgit:githooks[5] for more details about
each hook.
index::
DESCRIPTION
-----------
-You should work through linkgit:gittutorial[7][A tutorial introduction to
-git] before reading this tutorial.
+You should work through linkgit:gittutorial[7] before reading this tutorial.
The goal of this tutorial is to introduce two fundamental pieces of
git's architecture--the object database and the index file--and to
In addition to being the staging area for new commits, the index file
is also populated from the object database when checking out a
branch, and is used to hold the trees involved in a merge operation.
-See the linkgit:gitcore-tutorial[7][core tutorial] and the relevant man
+See linkgit:gitcore-tutorial[7] and the relevant man
pages for details.
What next?
At this point you should know everything necessary to read the man
pages for any of the git commands; one good place to start would be
with the commands mentioned in link:everyday.html[Everyday git]. You
-should be able to find any unknown jargon in the
-linkgit:gitglossary[7][Glossary].
+should be able to find any unknown jargon in linkgit:gitglossary[7].
The link:user-manual.html[Git User's Manual] provides a more
comprehensive introduction to git.
-The linkgit:gitcvs-migration[7][CVS migration] document explains how to
+linkgit:gitcvs-migration[7] explains how to
import a CVS repository into git, and shows how to use git in a
CVS-like way.
For some interesting examples of git use, see the
link:howto-index.html[howtos].
-For git developers, the linkgit:gitcore-tutorial[7][Core tutorial] goes
+For git developers, linkgit:gitcore-tutorial[7] goes
into detail on the lower-level git mechanisms involved in, for
example, creating a new commit.
Git can also be used in a CVS-like mode, with a central repository
that various users push changes to; see linkgit:git-push[1] and
-linkgit:gitcvs-migration[7][git for CVS users].
+linkgit:gitcvs-migration[7].
Exploring history
-----------------
used to create commits, check out working directories, and
hold the various trees involved in a merge.
-linkgit:gittutorial-2[7][Part two of this tutorial] explains the object
+Part two of this tutorial explains the object
database, the index file, and a few other odds and ends that you'll
-need to make the most of git.
+need to make the most of git. You can find it at linkgit:gittutorial-2[7].
If you don't want to continue with that right away, a few other
digressions that may be interesting at this point are:
* link:everyday.html[Everyday GIT with 20 Commands Or So]
- * linkgit:gitcvs-migration[7][git for CVS users].
+ * linkgit:gitcvs-migration[7]: Git for CVS users.
SEE ALSO
--------
-------------------------------------------------
(For an explanation of the last two lines, see
-linkgit:git-update-server-info[1], and the documentation
-linkgit:githooks[5][Hooks used by git].)
+linkgit:git-update-server-info[1] and linkgit:githooks[5].)
Advertise the URL of proj.git. Anybody else should then be able to
clone or pull from that URL, for example with a command line like:
solution is to retry the push after first updating your work by either a
pull or a fetch followed by a rebase; see the
<<setting-up-a-shared-repository,next section>> and
-linkgit:gitcvs-migration[7][git for CVS users] for more.
+linkgit:gitcvs-migration[7] for more.
[[setting-up-a-shared-repository]]
Setting up a shared repository
Another way to collaborate is by using a model similar to that
commonly used in CVS, where several developers with special rights
all push to and pull from a single shared repository. See
-linkgit:gitcvs-migration[7][git for CVS users] for instructions on how to
+linkgit:gitcvs-migration[7] for instructions on how to
set this up.
However, while there is nothing wrong with git's support for shared
projects / thirdparty / git.git / commitdiff
