development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-08-25 02:35:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into sp/fast-import

Browse source 
I'm bringing master in early so that the OBJ_OFS_DELTA implementation
is available as part of the topic.  This way git-fast-import can
learn about this new slightly smaller and faster packfile format,
and can generate them directly rather than needing to have them be
repacked with git-pack-objects.

Due to the API changes in master during the period of development
of git-fast-import, a few minor tweaks to fast-import.c are needed
to produce a working merge.  I've done them here as part of the
merge to ensure bisection always works.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This commit is contained in:
Shawn O. Pearce 2007-01-14 02:44:18 -05:00
parent 9938ffc53a 696b1b507f
commit 1fcdd62adf
404 changed files with 36675 additions and 15229 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
.gitignore vendored
View file

@ -2,13 +2,16 @@ GIT-CFLAGS
GIT-VERSION-FILE
git
git-add
git-add--interactive
git-am
git-annotate
git-apply
git-applymbox
git-applypatch
git-archimport
git-archive
git-bisect
git-blame
git-branch
git-cat-file
git-check-ref-format
@ -37,8 +40,10 @@ git-fetch
git-fetch-pack
git-findtags
git-fmt-merge-msg
git-for-each-ref
git-format-patch
git-fsck-objects
git-gc
git-get-tar-commit-id
git-grep
git-hash-object
@ -46,6 +51,7 @@ git-http-fetch
git-http-push
git-imap-send
git-index-pack
git-init
git-init-db
git-instaweb
git-local-fetch
@ -59,10 +65,12 @@ git-mailsplit
git-merge
git-merge-base
git-merge-index
git-merge-file
git-merge-tree
git-merge-octopus
git-merge-one-file
git-merge-ours
git-merge-recur
git-merge-recursive
git-merge-resolve
git-merge-stupid
@ -72,6 +80,7 @@ git-name-rev
git-mv
git-pack-redundant
git-pack-objects
git-pack-refs
git-parse-remote
git-patch-id
git-peek-remote
@ -83,7 +92,9 @@ git-quiltimport
git-read-tree
git-rebase
git-receive-pack
git-reflog
git-relink
git-remote
git-repack
git-repo-config
git-request-pull
@ -94,6 +105,7 @@ git-rev-list
git-rev-parse
git-revert
git-rm
git-runstatus
git-send-email
git-send-pack
git-sh-setup
@ -102,6 +114,7 @@ git-shortlog
git-show
git-show-branch
git-show-index
git-show-ref
git-ssh-fetch
git-ssh-pull
git-ssh-push
@ -118,8 +131,8 @@ git-unpack-objects
git-update-index
git-update-ref
git-update-server-info
git-upload-archive
git-upload-pack
git-upload-tar
git-var
git-verify-pack
git-verify-tag
@ -140,9 +153,9 @@ git-core.spec
*.py[co]
config.mak
autom4te.cache
config.cache
config.log
config.status
config.mak.autogen
config.mak.append
configure
git-blame

37
.mailmap Normal file
View file

@ -0,0 +1,37 @@
#
# This list is used by git-shortlog to fix a few botched name translations
# in the git archive, either because the author's full name was messed up
# and/or not always written the same way, making contributions from the
# same person appearing not to be so.
#
Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Chris Shoemaker <c.shoemaker@cox.net>
Daniel Barkalow <barkalow@iabervon.org>
David Kågedal <davidk@lysator.liu.se>
Fredrik Kuivinen <freku045@student.liu.se>
H. Peter Anvin <hpa@bonde.sc.orionmulti.com>
H. Peter Anvin <hpa@tazenda.sc.orionmulti.com>
H. Peter Anvin <hpa@trantor.hos.anvin.org>
Horst H. von Brand <vonbrand@inf.utfsm.cl>
Joachim Berdal Haga <cjhaga@fys.uio.no>
Jon Loeliger <jdl@freescale.com>
Jon Seymour <jon@blackcubes.dyndns.org>
Karl Hasselström <kha@treskal.com>
Kent Engstrom <kent@lysator.liu.se>
Lars Doelle <lars.doelle@on-line.de>
Lars Doelle <lars.doelle@on-line ! de>
Lukas Sandström <lukass@etek.chalmers.se>
Martin Langhoff <martin@catalyst.net.nz>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
René Scharfe <rene.scharfe@lsrfire.ath.cx>
Robert Fitzsimons <robfitz@273k.net>
Santi Béjar <sbejar@gmail.com>
Sean Estabrooks <seanlkml@sympatico.ca>
Shawn O. Pearce <spearce@spearce.org>
Tony Luck <tony.luck@intel.com>
Ville Skyttä <scop@xemacs.org>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
anonymous <linux@horizon.com>
anonymous <linux@horizon.net>

12
Documentation/Makefile
View file

@ -32,6 +32,9 @@ man7dir=$(mandir)/man7
# DESTDIR=
INSTALL?=install
DOC_REF = origin/man
-include ../config.mak.autogen
#
# Please note that there is a minor bug in asciidoc.
@ -54,8 +57,8 @@ man7: $(DOC_MAN7)
install: man
$(INSTALL) -d -m755 $(DESTDIR)$(man1dir) $(DESTDIR)$(man7dir)
$(INSTALL) $(DOC_MAN1) $(DESTDIR)$(man1dir)
$(INSTALL) $(DOC_MAN7) $(DESTDIR)$(man7dir)
$(INSTALL) -m644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
$(INSTALL) -m644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
#
@ -105,8 +108,11 @@ WEBDOC_DEST = /pub/software/scm/git/docs
$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
rm -f $@+ $@
sed -e '1,/^$$/d' $? | asciidoc -b xhtml11 - >$@+
sed -e '1,/^$$/d' $< | asciidoc -b xhtml11 - >$@+
mv $@+ $@
install-webdoc : html
sh ./install-webdoc.sh $(WEBDOC_DEST)
quick-install:
sh ./install-doc-quick.sh $(DOC_REF) $(mandir)

10
Documentation/SubmittingPatches
View file

@ -101,8 +101,13 @@ send it "To:" the mailing list, and optionally "cc:" him. If it
is trivially correct or after the list reached a consensus, send
it "To:" the maintainer and optionally "cc:" the list.
Also note that your maintainer does not actively involve himself in
maintaining what are in contrib/ hierarchy. When you send fixes and
enhancements to them, do not forget to "cc: " the person who primarily
worked on that hierarchy in contrib/.
(6) Sign your work
(4) Sign your work
To improve tracking of who did what, we've borrowed the
"sign-off" procedure from the Linux kernel project on patches
@ -144,6 +149,9 @@ then you just add a line saying
Signed-off-by: Random J Developer <random@developer.example.org>
This line can be automatically added by git if you run the git-commit
command with the -s option.
Some people also put extra tags at the end. They'll just be ignored for
now, but you can do this to mark internal company procedures or just
point out some special detail about the sign-off.

1
Documentation/asciidoc.conf
View file

@ -11,6 +11,7 @@
caret=^
startsb=&#91;
endsb=&#93;
tilde=&#126;
ifdef::backend-docbook[]
[gitlink-inlinemacro]

14
Documentation/callouts.xsl
View file

@ -13,4 +13,18 @@
<xsl:apply-templates/>
<xsl:text>.br&#10;</xsl:text>
</xsl:template>
<!-- sorry, this is not about callouts, but attempts to work around
spurious .sp at the tail of the line docbook stylesheets seem to add -->
<xsl:template match="simpara">
<xsl:variable name="content">
<xsl:apply-templates/>
</xsl:variable>
<xsl:value-of select="normalize-space($content)"/>
<xsl:if test="not(ancestor::authorblurb) and
not(ancestor::personblurb)">
<xsl:text>&#10;&#10;</xsl:text>
</xsl:if>
</xsl:template>
</xsl:stylesheet>

181
Documentation/config.txt
View file

@ -31,6 +31,11 @@ Example
external = "/usr/local/bin/gnu-diff -u"
renames = true
[branch "devel"]
remote = origin
merge = refs/heads/devel
Variables
~~~~~~~~~
@ -71,12 +76,19 @@ core.preferSymlinkRefs::
expect HEAD to be a symbolic link.
core.logAllRefUpdates::
If true, `git-update-ref` will append a line to
"$GIT_DIR/logs/<ref>" listing the new SHA1 and the date/time
of the update. If the file does not exist it will be
created automatically. This information can be used to
determine what commit was the tip of a branch "2 days ago".
This value is false by default (no logging).
Updates to a ref <ref> is logged to the file
"$GIT_DIR/logs/<ref>", by appending the new and old
SHA1, the date/time and the reason of the update, but
only when the file exists. If this configuration
variable is set to true, missing "$GIT_DIR/logs/<ref>"
file is automatically created for branch heads.
+
This information can be used to determine what commit
was the tip of a branch "2 days ago".
+
This value is true by default in a repository that has
a working directory associated with it, and false by
default in a bare repository.
core.repositoryFormatVersion::
Internal variable identifying the repository format and layout
@ -88,7 +100,7 @@ core.sharedRepository::
group-writable). When 'all' (or 'world' or 'everybody'), the
repository will be readable by all users, additionally to being
group-shareable. When 'umask' (or 'false'), git will use permissions
reported by umask(2). See gitlink:git-init-db[1]. False by default.
reported by umask(2). See gitlink:git-init[1]. False by default.
core.warnAmbiguousRefs::
If true, git will warn you if the ref name you passed it is ambiguous
@ -106,6 +118,34 @@ core.legacyheaders::
database directly (where the "http://" and "rsync://" protocols
count as direct access).
core.packedGitWindowSize::
Number of bytes of a pack file to map into memory in a
single mapping operation. Larger window sizes may allow
your system to process a smaller number of large pack files
more quickly. Smaller window sizes will negatively affect
performance due to increased calls to the operating system's
memory manager, but may improve performance when accessing
a large number of large pack files.
+
Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32
MiB on 32 bit platforms and 1 GiB on 64 bit platforms. This should
be reasonable for all users/operating systems. You probably do
not need to adjust this value.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.
core.packedGitLimit::
Maximum number of bytes to map simultaneously into memory
from pack files. If Git needs to access more than this many
bytes at once to complete an operation it will unmap existing
regions to reclaim virtual address space within the process.
+
Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.
This should be reasonable for all users/operating systems, except on
the largest projects. You probably do not need to adjust this value.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.
alias.*::
Command aliases for the gitlink:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
@ -119,25 +159,65 @@ apply.whitespace::
Tells `git-apply` how to handle whitespaces, in the same way
as the '--whitespace' option. See gitlink:git-apply[1].
pager.color::
A boolean to enable/disable colored output when the pager is in
use (default is true).
branch.<name>.remote::
When in branch <name>, it tells `git fetch` which remote to fetch.
If this option is not given, `git fetch` defaults to remote "origin".
diff.color::
branch.<name>.merge::
When in branch <name>, it tells `git fetch` the default refspec to
be marked for merging in FETCH_HEAD. The value has exactly to match
a remote part of one of the refspecs which are fetched from the remote
given by "branch.<name>.remote".
The merge information is used by `git pull` (which at first calls
`git fetch`) to lookup the default branch for merging. Without
this option, `git pull` defaults to merge the first refspec fetched.
Specify multiple values to get an octopus merge.
color.branch::
A boolean to enable/disable color in the output of
gitlink:git-branch[1]. May be set to `true` (or `always`),
`false` (or `never`) or `auto`, in which case colors are used
only when the output is to a terminal. Defaults to false.
color.branch.<slot>::
Use customized color for branch coloration. `<slot>` is one of
`current` (the current branch), `local` (a local branch),
`remote` (a tracking branch in refs/remotes/), `plain` (other
refs), or `reset` (the normal terminal color). The value for
these configuration variables can be one of: `normal`, `bold`,
`dim`, `ul`, `blink`, `reverse`, `reset`, `black`, `red`,
`green`, `yellow`, `blue`, `magenta`, `cyan`, or `white`.
color.diff::
When true (or `always`), always use colors in patch.
When false (or `never`), never. When set to `auto`, use
colors only when the output is to the terminal.
diff.color.<slot>::
color.diff.<slot>::
Use customized color for diff colorization. `<slot>`
specifies which part of the patch to use the specified
color, and is one of `plain` (context text), `meta`
(metainformation), `frag` (hunk header), `old` (removed
lines), or `new` (added lines). The value for these
configuration variables can be one of: `normal`, `bold`,
`dim`, `ul`, `blink`, `reverse`, `reset`, `black`,
`red`, `green`, `yellow`, `blue`, `magenta`, `cyan`, or
`white`.
lines), or `new` (added lines). The values of these
variables may be specified as in color.branch.<slot>.
color.pager::
A boolean to enable/disable colored output when the pager is in
use (default is true).
color.status::
A boolean to enable/disable color in the output of
gitlink:git-status[1]. May be set to `true` (or `always`),
`false` (or `never`) or `auto`, in which case colors are used
only when the output is to a terminal. Defaults to false.
color.status.<slot>::
Use customized color for status colorization. `<slot>` is
one of `header` (the header text of the status message),
`added` or `updated` (files which are added but not committed),
`changed` (files which are changed but not added in the index),
or `untracked` (files which are not tracked by git). The values of
these variables may be specified as in color.branch.<slot>.
diff.renameLimit::
The number of files to consider when performing the copy/rename
@ -152,6 +232,25 @@ format.headers::
Additional email headers to include in a patch to be submitted
by mail. See gitlink:git-format-patch[1].
gc.reflogexpire::
`git reflog expire` removes reflog entries older than
this time; defaults to 90 days.
gc.reflogexpireunreachable::
`git reflog expire` removes reflog entries older than
this time and are not reachable from the current tip;
defaults to 30 days.
gc.rerereresolved::
Records of conflicted merge you resolved earlier are
kept for this many days when `git rerere gc` is run.
The default is 60 days. See gitlink:git-rerere[1].
gc.rerereunresolved::
Records of conflicted merge you have not resolved are
kept for this many days when `git rerere gc` is run.
The default is 15 days. See gitlink:git-rerere[1].
gitcvs.enabled::
Whether the cvs pserver interface is enabled for this repository.
See gitlink:git-cvsserver[1].
@ -195,6 +294,12 @@ http.lowSpeedLimit, http.lowSpeedTime::
Can be overridden by the 'GIT_HTTP_LOW_SPEED_LIMIT' and
'GIT_HTTP_LOW_SPEED_TIME' environment variables.
http.noEPSV::
A boolean which disables using of EPSV ftp command by curl.
This can helpful with some "poor" ftp servers which doesn't
support EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV'
environment variable. Default is false (curl will use EPSV).
i18n.commitEncoding::
Character encoding the commit messages are stored in; git itself
does not care per se, but this information is necessary e.g. when
@ -202,6 +307,16 @@ i18n.commitEncoding::
browser (and possibly at other places in the future or in other
porcelains). See e.g. gitlink:git-mailinfo[1]. Defaults to 'utf-8'.
i18n.logOutputEncoding::
Character encoding the commit messages are converted to when
running `git-log` and friends.
log.showroot::
If true, the initial commit will be shown as a big creation event.
This is equivalent to a diff against an empty tree.
Tools like gitlink:git-log[1] or gitlink:git-whatchanged[1], which
normally hide the root commit will now show it. True by default.
merge.summary::
Whether to include summaries of merged commits in newly created
merge commit messages. False by default.
@ -217,6 +332,22 @@ pull.octopus::
pull.twohead::
The default merge strategy to use when pulling a single branch.
remote.<name>.url::
The URL of a remote repository. See gitlink:git-fetch[1] or
gitlink:git-push[1].
remote.<name>.fetch::
The default set of "refspec" for gitlink:git-fetch[1]. See
gitlink:git-fetch[1].
remote.<name>.push::
The default set of "refspec" for gitlink:git-push[1]. See
gitlink:git-push[1].
repack.usedeltabaseoffset::
Allow gitlink:git-repack[1] to create packs that uses
delta-base offset. Defaults to false.
show.difftree::
The default gitlink:git-diff-tree[1] arguments to be used
for gitlink:git-show[1].
@ -253,3 +384,19 @@ whatchanged.difftree::
imap::
The configuration variables in the 'imap' section are described
in gitlink:git-imap-send[1].
receive.unpackLimit::
If the number of objects received in a push is below this
limit then the objects will be unpacked into loose object
files. However if the number of received objects equals or
exceeds this limit then the received pack will be stored as
a pack, after adding any missing delta bases. Storing the
pack from a push can make the push operation complete faster,
especially on slow filesystems.
receive.denyNonFastForwards::
If set to true, git-receive-pack will deny a ref update which is
not a fast forward. Use this to prevent such an update via a push,
even if that push is forced. This configuration variable is
set when initializing a shared repository.

28
Documentation/core-tutorial.txt
View file

@ -46,18 +46,18 @@ to import into git.
For our first example, we're going to start a totally new repository from
scratch, with no pre-existing files, and we'll call it `git-tutorial`.
To start up, create a subdirectory for it, change into that
subdirectory, and initialize the git infrastructure with `git-init-db`:
subdirectory, and initialize the git infrastructure with `git-init`:
------------------------------------------------
$ mkdir git-tutorial
$ cd git-tutorial
$ git-init-db
$ git-init
------------------------------------------------
to which git will reply
----------------
defaulting to local storage area
Initialized empty Git repository in .git/
----------------
which is just git's way of saying that you haven't been doing anything
@ -336,17 +336,9 @@ $ commit=$(echo 'Initial commit' | git-commit-tree $tree)
$ git-update-ref HEAD $commit
------------------------------------------------
which will say:
----------------
Committing initial tree 8988da15d077d4829fc51d8544c097def6644dbb
----------------
just to warn you about the fact that it created a totally new commit
that is not related to anything else. Normally you do this only *once*
for a project ever, and all later commits will be parented on top of an
earlier commit, and you'll never see this "Committing initial tree"
message ever again.
In this case this creates a totally new commit that is not related to
anything else. Normally you do this only *once* for a project ever, and
all later commits will be parented on top of an earlier commit.
Again, normally you'd never actually do this by hand. There is a
helpful script called `git commit` that will do all of this for you. So
@ -1379,11 +1371,11 @@ $ mkdir my-git.git
------------
Then, make that directory into a git repository by running
`git init-db`, but this time, since its name is not the usual
`git init`, but this time, since its name is not the usual
`.git`, we do things slightly differently:
------------
$ GIT_DIR=my-git.git git-init-db
$ GIT_DIR=my-git.git git-init
------------
Make sure this directory is available for others you want your
@ -1519,7 +1511,7 @@ A recommended workflow for a "project lead" goes like this:
+
If other people are pulling from your repository over dumb
transport protocols (HTTP), you need to keep this repository
'dumb transport friendly'. After `git init-db`,
'dumb transport friendly'. After `git init`,
`$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
@ -1620,7 +1612,7 @@ suggested in the previous section may be new to you. You do not
have to worry. git supports "shared public repository" style of
cooperation you are probably more familiar with as well.
See link:cvs-migration.txt[git for CVS users] for the details.
See link:cvs-migration.html[git for CVS users] for the details.
Bundling your work together
---------------------------

369
Documentation/cvs-migration.txt
View file

@ -1,43 +1,119 @@
git for CVS users
=================
So you're a CVS user. That's OK, it's a treatable condition. The job of
this document is to put you on the road to recovery, by helping you
convert an existing cvs repository to git, and by showing you how to use a
git repository in a cvs-like fashion.
Git differs from CVS in that every working tree contains a repository with
a full copy of the project history, and no repository is inherently more
important than any other. However, you can emulate the CVS model by
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
link:tutorial.html[tutorial introduction to git] should be sufficient.
First, note some ways that git differs from CVS:
Developing against a shared repository
--------------------------------------
* Commits are atomic and project-wide, not per-file as in CVS.
Suppose a shared repository is set up in /pub/repo.git on the host
foo.com. Then as an individual committer you can clone the shared
repository over ssh with:
* Offline work is supported: you can make multiple commits locally,
then submit them when you're ready.
------------------------------------------------
$ git clone foo.com:/pub/repo.git/ my-project
$ cd my-project
------------------------------------------------
* Branching is fast and easy.
and hack away. The equivalent of `cvs update` is
* Every working tree contains a repository with a full copy of the
project history, and no repository is inherently more important than
any other. However, you can emulate the CVS model by designating a
single shared repository which people can synchronize with; see below
for details.
------------------------------------------------
$ git pull origin
------------------------------------------------
which merges in any work that others might have done since the clone
operation. If there are uncommitted changes in your working tree, commit
them first before running git pull.
[NOTE]
================================
The `pull` command knows where to get updates from because of certain
configuration variables that were set by the first `git clone`
command; see `git repo-config -l` and the gitlink:git-repo-config[1] man
page for details.
================================
You can update the shared repository with your changes by first committing
your changes, and then using the gitlink:git-push[1] command:
------------------------------------------------
$ git push origin master
------------------------------------------------
to "push" those commits to the shared repository. If someone else has
updated the repository more recently, `git push`, like `cvs commit`, will
complain, in which case you must pull any changes before attempting the
push again.
In the `git push` command above we specify the name of the remote branch
to update (`master`). If we leave that out, `git push` tries to update
any branches in the remote repository that have the same name as a branch
in the local repository. So the last `push` can be done with either of:
------------
$ git push origin
$ git push foo.com:/pub/project.git/
------------
as long as the shared repository does not have any branches
other than `master`.
Setting Up 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
link:tutorial.html[tutorial]), 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"
repository (a repository without a working tree) and fetch your project into
it:
------------------------------------------------
$ mkdir /pub/my-repo.git
$ cd /pub/my-repo.git
$ git --bare init --shared
$ git --bare fetch /home/alice/myproject master:master
------------------------------------------------
Next, give every team member read/write access to this repository. One
easy way to do this is to give all the team members ssh access to the
machine where the repository is hosted. If you don't want to give them a
full shell on the machine, there is a restricted shell which only allows
users to do git pushes and pulls; see gitlink:git-shell[1].
Put all the committers in the same group, and make the repository
writable by that group:
------------------------------------------------
$ chgrp -R $group /pub/my-repo.git
------------------------------------------------
Make sure committers have a umask of at most 027, so that the directories
they create are writable and searchable by other group members.
Importing a CVS archive
-----------------------
First, install version 2.1 or higher of cvsps from
link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
sure it is in your path. The magic command line is then
sure it is in your path. Then cd to a checked out CVS working directory
of the project you are interested in and run gitlink:git-cvsimport[1]:
-------------------------------------------
$ git cvsimport -v -d <cvsroot> -C <destination> <module>
$ git cvsimport -C <destination>
-------------------------------------------
This puts a git archive of the named CVS module in the directory
<destination>, which will be created if necessary. The -v option makes
the conversion script very chatty.
<destination>, which will be created if necessary.
The import checks out from CVS every revision of every file. Reportedly
cvsimport can average some twenty revisions per second, so for a
@ -55,14 +131,32 @@ work, you must not modify the imported branches; instead, create new
branches for your own changes, and merge in the imported branches as
necessary.
Development Models
------------------
Advanced Shared Repository Management
-------------------------------------
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 link:hooks.html[Hooks used by git].
You can enforce finer grained permissions using update hooks. See
link:howto/update-hook-example.txt[Controlling access to branches using
update hooks].
Providing CVS Access to a git Repository
----------------------------------------
It is also possible to provide true CVS access to a git repository, so
that developers can still use CVS; see gitlink:git-cvsserver[1] for
details.
Alternative Development Models
------------------------------
CVS users are accustomed to giving a group of developers commit access to
a common repository. In the next section we'll explain how to do this
with git. However, the distributed nature of git allows other development
models, and you may want to first consider whether one of them might be a
better fit for your project.
a common repository. As we've seen, this is also possible with git.
However, the distributed nature of git allows other development models,
and you may want to first consider whether one of them might be a better
fit for your project.
For example, you can choose a single person to maintain the project's
primary public repository. Other developers then clone this repository
@ -75,230 +169,3 @@ variants of this model.
With a small group, developers may just pull changes from each other's
repositories without the need for a central maintainer.
Emulating the CVS Development Model
-----------------------------------
Start with an ordinary git working directory containing the project, and
remove the checked-out files, keeping just the bare .git directory:
------------------------------------------------
$ mv project/.git /pub/repo.git
$ rm -r project/
------------------------------------------------
Next, give every team member read/write access to this repository. One
easy way to do this is to give all the team members ssh access to the
machine where the repository is hosted. If you don't want to give them a
full shell on the machine, there is a restricted shell which only allows
users to do git pushes and pulls; see gitlink:git-shell[1].
Put all the committers in the same group, and make the repository
writable by that group:
------------------------------------------------
$ chgrp -R $group repo.git
$ find repo.git -mindepth 1 -type d |xargs chmod ug+rwx,g+s
$ GIT_DIR=repo.git git repo-config core.sharedrepository true
------------------------------------------------
Make sure committers have a umask of at most 027, so that the directories
they create are writable and searchable by other group members.
Suppose this repository is now set up in /pub/repo.git on the host
foo.com. Then as an individual committer you can clone the shared
repository:
------------------------------------------------
$ git clone foo.com:/pub/repo.git/ my-project
$ cd my-project
------------------------------------------------
and hack away. The equivalent of `cvs update` is
------------------------------------------------
$ git pull origin
------------------------------------------------
which merges in any work that others might have done since the clone
operation.
[NOTE]
================================
The first `git clone` places the following in the
`my-project/.git/remotes/origin` file, and that's why the previous step
and the next step both work.
------------
URL: foo.com:/pub/project.git/ my-project
Pull: master:origin
------------
================================
You can update the shared repository with your changes using:
------------------------------------------------
$ git push origin master
------------------------------------------------
If someone else has updated the repository more recently, `git push`, like
`cvs commit`, will complain, in which case you must pull any changes
before attempting the push again.
In the `git push` command above we specify the name of the remote branch
to update (`master`). If we leave that out, `git push` tries to update
any branches in the remote repository that have the same name as a branch
in the local repository. So the last `push` can be done with either of:
------------
$ git push origin
$ git push repo.shared.xz:/pub/scm/project.git/
------------
as long as the shared repository does not have any branches
other than `master`.
[NOTE]
============
Because of this behavior, if the shared repository and the developer's
repository both have branches named `origin`, then a push like the above
attempts to update the `origin` branch in the shared repository from the
developer's `origin` branch. The results may be unexpected, so it's
usually best to remove any branch named `origin` from the shared
repository.
============
Advanced Shared Repository Management
-------------------------------------
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 link:hooks.txt[Hooks used by git].
You can enforce finer grained permissions using update hooks. See
link:howto/update-hook-example.txt[Controlling access to branches using
update hooks].
CVS annotate
------------
So, something has gone wrong, and you don't know whom to blame, and
you're an ex-CVS user and used to do "cvs annotate" to see who caused
the breakage. You're looking for the "git annotate", and it's just
claiming not to find such a script. You're annoyed.
Yes, that's right. Core git doesn't do "annotate", although it's
technically possible, and there are at least two specialized scripts out
there that can be used to get equivalent information (see the git
mailing list archives for details).
git has a couple of alternatives, though, that you may find sufficient
or even superior depending on your use. One is called "git-whatchanged"
(for obvious reasons) and the other one is called "pickaxe" ("a tool for
the software archaeologist").
The "git-whatchanged" script is a truly trivial script that can give you
a good overview of what has changed in a file or a directory (or an
arbitrary list of files or directories). The "pickaxe" support is an
additional layer that can be used to further specify exactly what you're
looking for, if you already know the specific area that changed.
Let's step back a bit and think about the reason why you would
want to do "cvs annotate a-file.c" to begin with.
You would use "cvs annotate" on a file when you have trouble
with a function (or even a single "if" statement in a function)
that happens to be defined in the file, which does not do what
you want it to do. And you would want to find out why it was
written that way, because you are about to modify it to suit
your needs, and at the same time you do not want to break its
current callers. For that, you are trying to find out why the
original author did things that way in the original context.
Many times, it may be enough to see the commit log messages of
commits that touch the file in question, possibly along with the
patches themselves, like this:
$ git-whatchanged -p a-file.c
This will show log messages and patches for each commit that
touches a-file.
This, however, may not be very useful when this file has many
modifications that are not related to the piece of code you are
interested in. You would see many log messages and patches that
do not have anything to do with the piece of code you are
interested in. As an example, assuming that you have this piece
of code that you are interested in in the HEAD version:
if (frotz) {
nitfol();
}
you would use git-rev-list and git-diff-tree like this:
$ git-rev-list HEAD |
git-diff-tree --stdin -v -p -S'if (frotz) {
nitfol();
}'
We have already talked about the "\--stdin" form of git-diff-tree
command that reads the list of commits and compares each commit
with its parents (otherwise you should go back and read the tutorial).
The git-whatchanged command internally runs
the equivalent of the above command, and can be used like this:
$ git-whatchanged -p -S'if (frotz) {
nitfol();
}'
When the -S option is used, git-diff-tree command outputs
differences between two commits only if one tree has the
specified string in a file and the corresponding file in the
other tree does not. The above example looks for a commit that
has the "if" statement in it in a file, but its parent commit
does not have it in the same shape in the corresponding file (or
the other way around, where the parent has it and the commit
does not), and the differences between them are shown, along
with the commit message (thanks to the -v flag). It does not
show anything for commits that do not touch this "if" statement.
Also, in the original context, the same statement might have
appeared at first in a different file and later the file was
renamed to "a-file.c". CVS annotate would not help you to go
back across such a rename, but git would still help you in such
a situation. For that, you can give the -C flag to
git-diff-tree, like this:
$ git-whatchanged -p -C -S'if (frotz) {
nitfol();
}'
When the -C flag is used, file renames and copies are followed.
So if the "if" statement in question happens to be in "a-file.c"
in the current HEAD commit, even if the file was originally
called "o-file.c" and then renamed in an earlier commit, or if
the file was created by copying an existing "o-file.c" in an
earlier commit, you will not lose track. If the "if" statement
did not change across such a rename or copy, then the commit that
does rename or copy would not show in the output, and if the
"if" statement was modified while the file was still called
"o-file.c", it would find the commit that changed the statement
when it was in "o-file.c".
NOTE: The current version of "git-diff-tree -C" is not eager
enough to find copies, and it will miss the fact that a-file.c
was created by copying o-file.c unless o-file.c was somehow
changed in the same commit.
You can use the --pickaxe-all flag in addition to the -S flag.
This causes the differences from all the files contained in
those two commits, not just the differences between the files
that contain this changed "if" statement:
$ git-whatchanged -p -C -S'if (frotz) {
nitfol();
}' --pickaxe-all
NOTE: This option is called "--pickaxe-all" because -S
option is internally called "pickaxe", a tool for software
archaeologists.

139
Documentation/diff-format.txt
View file

@ -65,62 +65,17 @@ Generating patches with -p
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
with a '-p' option, they do not produce the output described above;
instead they produce a patch file.
instead they produce a patch file. You can customize the creation
of such patches via the GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS
environment variables.
The patch generation can be customized at two levels.
1. When the environment variable 'GIT_EXTERNAL_DIFF' is not set,
these commands internally invoke "diff" like this:
diff -L a/<path> -L b/<path> -pu <old> <new>
+
For added files, `/dev/null` is used for <old>. For removed
files, `/dev/null` is used for <new>
+
The "diff" formatting options can be customized via the
environment variable 'GIT_DIFF_OPTS'. For example, if you
prefer context diff:
GIT_DIFF_OPTS=-c git-diff-index -p HEAD
2. When the environment variable 'GIT_EXTERNAL_DIFF' is set, the
program named by it is called, instead of the diff invocation
described above.
+
For a path that is added, removed, or modified,
'GIT_EXTERNAL_DIFF' is called with 7 parameters:
path old-file old-hex old-mode new-file new-hex new-mode
+
where:
<old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the
contents of <old|new>,
<old|new>-hex:: are the 40-hexdigit SHA1 hashes,
<old|new>-mode:: are the octal representation of the file modes.
+
The file parameters can point at the user's working file
(e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file`
when a new file is added), or a temporary file (e.g. `old-file` in the
index). 'GIT_EXTERNAL_DIFF' should not worry about unlinking the
temporary file --- it is removed when 'GIT_EXTERNAL_DIFF' exits.
For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1
parameter, <path>.
git specific extension to diff format
-------------------------------------
What -p option produces is slightly different from the
traditional diff format.
What the -p option produces is slightly different from the traditional
diff format.
1. It is preceded with a "git diff" header, that looks like
this:
diff --git a/file1 b/file2
diff --git a/file1 b/file2
+
The `a/` and `b/` filenames are the same unless rename/copy is
involved. Especially, even for a creation or a deletion,
@ -144,8 +99,10 @@ the file that rename/copy produces, respectively.
dissimilarity index <number>
index <hash>..<hash> <mode>
3. TAB, LF, and backslash characters in pathnames are
represented as `\t`, `\n`, and `\\`, respectively.
3. TAB, LF, double quote and backslash characters in pathnames
are represented as `\t`, `\n`, `\"` and `\\`, respectively.
If there is need for such substitution then the whole
pathname is put in double quotes.
combined diff format
@ -156,31 +113,91 @@ to produce 'combined diff', which looks like this:
------------
diff --combined describe.c
@@@ +98,7 @@@
return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
}
- static void describe(char *arg)
-static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
{
+ unsigned char sha1[20];
+ struct commit *cmit;
+ unsigned char sha1[20];
+ struct commit *cmit;
struct commit_list *list;
static int initialized = 0;
struct commit_name *n;
+ if (get_sha1(arg, sha1) < 0)
+ usage(describe_usage);
+ cmit = lookup_commit_reference(sha1);
+ if (!cmit)
+ usage(describe_usage);
+
if (!initialized) {
initialized = 1;
for_each_ref(get_name);
------------
1. It is preceded with a "git diff" header, that looks like
this (when '-c' option is used):
diff --combined file
+
or like this (when '--cc' option is used):
diff --c file
2. It is followed by one or more extended header lines
(this example shows a merge with two parents):
index <hash>,<hash>..<hash>
mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>
+
The `mode <mode>,<mode>..<mode>` line appears only if at least one of
the <mode> is diferent from the rest. Extended headers with
information about detected contents movement (renames and
copying detection) are designed to work with diff of two
<tree-ish> and are not used by combined diff format.
3. It is followed by two-line from-file/to-file header
--- a/file
+++ b/file
+
Similar to two-line header for traditional 'unified' diff
format, `/dev/null` is used to signal created or deleted
files.
4. Chunk header format is modified to prevent people from
accidentally feeding it to `patch -p1`. Combined diff format
was created for review of merge commit changes, and was not
meant for apply. The change is similar to the change in the
extended 'index' header:
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
+
There are (number of parents + 1) `@` characters in the chunk
header for combined diff format.
Unlike the traditional 'unified' diff format, which shows two
files A and B with a single column that has `-` (minus --
appears in A but removed in B), `+` (plus -- missing in A but
added to B), or ` ` (space -- unchanged) prefix, this format
added to B), or `" "` (space -- unchanged) prefix, this format
compares two or more files file1, file2,... with one file X, and
shows how X differs from each of fileN. One column for each of
fileN is prepended to the output line to note how X's line is
different from it.
A `-` character in the column N means that the line appears in
fileN but it does not appear in the last file. A `+` character
fileN but it does not appear in the result. A `+` character
in the column N means that the line appears in the last file,
and fileN does not have that line.
and fileN does not have that line (in other words, the line was
added, from the point of view of that parent).
In the above example output, the function signature was changed
from both files (hence two `-` removals from both file1 and

35
Documentation/diff-options.txt
View file

@ -10,8 +10,23 @@
--patch-with-raw::
Synonym for "-p --raw".
--stat::
Generate a diffstat.
--stat[=width[,name-width]]::
Generate a diffstat. You can override the default
output width for 80-column terminal by "--stat=width".
The width of the filename part can be controlled by
giving another width to it separated by a comma.
--numstat::
Similar to \--stat, but shows number of added and
deleted lines in decimal notation and pathname without
abbreviation, to make it more machine friendly. For
binary files, outputs two `-` instead of saying
`0 0`.
--shortstat::
Output only the last line of the --stat format containing total
number of modified files, as well as number of added and deleted
lines.
--summary::
Output a condensed summary of extended header information
@ -121,5 +136,21 @@
-a::
Shorthand for "--text".
--ignore-space-change::
Ignore changes in amount of white space. This ignores white
space at line end, and consider all other sequences of one or
more white space characters to be equivalent.
-b::
Shorthand for "--ignore-space-change".
--ignore-all-space::
Ignore white space when comparing lines. This ignores
difference even if one line has white space where the other
line has none.
-w::
Shorthand for "--ignore-all-space".
For more detailed explanation on these common options, see also
link:diffcore.html[diffcore documentation].

154
Documentation/everyday.txt
View file

@ -1,22 +1,7 @@
Everyday GIT With 20 Commands Or So
===================================
GIT suite has over 100 commands, and the manual page for each of
them discusses what the command does and how it is used in
detail, but until you know what command should be used in order
to achieve what you want to do, you cannot tell which manual
page to look at, and if you know that already you do not need
the manual.
Does that mean you need to know all of them before you can use
git? Not at all. Depending on the role you play, the set of
commands you need to know is slightly different, but in any case
what you need to learn is far smaller than the full set of
commands to carry out your day-to-day work. This document is to
serve as a cheat-sheet and a set of pointers for people playing
various roles.
<<Basic Repository>> commands are needed by people who has a
<<Basic Repository>> commands are needed by people who have a
repository --- that is everybody, because every working tree of
git is a repository.
@ -25,31 +10,33 @@ essential for anybody who makes a commit, even for somebody who
works alone.
If you work with other people, you will need commands listed in
<<Individual Developer (Participant)>> section as well.
the <<Individual Developer (Participant)>> section as well.
People who play <<Integrator>> role need to learn some more
People who play the <<Integrator>> role need to learn some more
commands in addition to the above.
<<Repository Administration>> commands are for system
administrators who are responsible to care and feed git
repositories to support developers.
administrators who are responsible for the care and feeding
of git repositories.
Basic Repository[[Basic Repository]]
------------------------------------
Everybody uses these commands to feed and care git repositories.
Everybody uses these commands to maintain git repositories.
* gitlink:git-init-db[1] or gitlink:git-clone[1] to create a
* gitlink:git-init[1] or gitlink:git-clone[1] to create a
new repository.
* gitlink:git-fsck-objects[1] to validate the repository.
* gitlink:git-fsck-objects[1] to check the repository for errors.
* gitlink:git-prune[1] to garbage collect cruft in the
repository.
* gitlink:git-prune[1] to remove unused objects in the repository.
* gitlink:git-repack[1] to pack loose objects for efficiency.
* gitlink:git-gc[1] to do common housekeeping tasks such as
repack and prune.
Examples
~~~~~~~~
@ -57,19 +44,19 @@ Check health and remove cruft.::
+
------------
$ git fsck-objects <1>
$ git prune
$ git count-objects <2>
$ git repack <3>
$ git prune <4>
$ git gc <4>
------------
+
<1> running without "--full" is usually cheap and assures the
<1> running without `\--full` is usually cheap and assures the
repository health reasonably well.
<2> check how many loose objects there are and how much
disk space is wasted by not repacking.
<3> without "-a" repacks incrementally. repacking every 4-5MB
<3> without `-a` repacks incrementally. repacking every 4-5MB
of loose objects accumulation may be a good rule of thumb.
<4> after repack, prune removes the duplicate loose objects.
<4> it is easier to use `git gc` than individual housekeeping commands
such as `prune` and `repack`. This runs `repack -a -d`.
Repack a small project into single pack.::
+
@ -78,8 +65,8 @@ $ git repack -a -d <1>
$ git prune
------------
+
<1> pack all the objects reachable from the refs into one pack
and remove unneeded other packs
<1> pack all the objects reachable from the refs into one pack,
then remove the other packs.
Individual Developer (Standalone)[[Individual Developer (Standalone)]]
@ -93,14 +80,10 @@ following commands.
* gitlink:git-log[1] to see what happened.
* gitlink:git-whatchanged[1] to find out where things have
come from.
* gitlink:git-checkout[1] and gitlink:git-branch[1] to switch
branches.
* gitlink:git-add[1] and gitlink:git-update-index[1] to manage
the index file.
* gitlink:git-add[1] to manage the index file.
* gitlink:git-diff[1] and gitlink:git-status[1] to see what
you are in the middle of doing.
@ -110,8 +93,7 @@ following commands.
* gitlink:git-reset[1] and gitlink:git-checkout[1] (with
pathname parameters) to undo changes.
* gitlink:git-pull[1] with "." as the remote to merge between
local branches.
* gitlink:git-merge[1] to merge between local branches.
* gitlink:git-rebase[1] to maintain topic branches.
@ -120,12 +102,12 @@ following commands.
Examples
~~~~~~~~
Extract a tarball and create a working tree and a new repository to keep track of it.::
Use a tarball as a starting point for a new repository.::
+
------------
$ tar zxf frotz.tar.gz
$ cd frotz
$ git-init-db
$ git-init
$ git add . <1>
$ git commit -m 'import of frotz source tree.'
$ git tag v2.43 <2>
@ -142,7 +124,7 @@ $ edit/compile/test
$ git checkout -- curses/ux_audio_oss.c <2>
$ git add curses/ux_audio_alsa.c <3>
$ edit/compile/test
$ git diff <4>
$ git diff HEAD <4>
$ git commit -a -s <5>
$ edit/compile/test
$ git reset --soft HEAD^ <6>
@ -150,15 +132,15 @@ $ edit/compile/test
$ git diff ORIG_HEAD <7>
$ git commit -a -c ORIG_HEAD <8>
$ git checkout master <9>
$ git pull . alsa-audio <10>
$ git merge alsa-audio <10>
$ git log --since='3 days ago' <11>
$ git log v2.43.. curses/ <12>
------------
+
<1> create a new topic branch.
<2> revert your botched changes in "curses/ux_audio_oss.c".
<2> revert your botched changes in `curses/ux_audio_oss.c`.
<3> you need to tell git if you added a new file; removal and
modification will be caught if you do "commit -a" later.
modification will be caught if you do `git commit -a` later.
<4> to see what changes you are committing.
<5> commit everything as you have tested, with your sign-off.
<6> take the last commit back, keeping what is in the working tree.
@ -166,11 +148,13 @@ modification will be caught if you do "commit -a" later.
<8> redo the commit undone in the previous step, using the message
you originally wrote.
<9> switch to the master branch.
<10> merge a topic branch into your master branch
<10> merge a topic branch into your master branch. You can also use
`git pull . alsa-audio`, i.e. pull from the local repository.
<11> review commit logs; other forms to limit output can be
combined and include --max-count=10 (show 10 commits), --until='2005-12-10'.
<12> view only the changes that touch what's in curses/
directory, since v2.43 tag.
combined and include `\--max-count=10` (show 10 commits),
`\--until=2005-12-10`, etc.
<12> view only the changes that touch what's in `curses/`
directory, since `v2.43` tag.
Individual Developer (Participant)[[Individual Developer (Participant)]]
@ -203,7 +187,7 @@ $ cd my2.6
$ edit/compile/test; git commit -a -s <1>
$ git format-patch origin <2>
$ git pull <3>
$ git whatchanged -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
$ git reset --hard ORIG_HEAD <6>
$ git prune <7>
@ -212,7 +196,7 @@ $ git fetch --tags <8>
+
<1> repeat as needed.
<2> extract patches from your branch for e-mail submission.
<3> "pull" fetches from "origin" by default and merges into the
<3> `git pull` fetches from `origin` by default and merges into the
current branch.
<4> immediately after pulling, look at the changes done upstream
since last time we checked, only in the
@ -220,37 +204,41 @@ area we are interested in.
<5> fetch from a specific branch from a specific repository and merge.
<6> revert the pull.
<7> garbage collect leftover objects from reverted pull.
<8> from time to time, obtain official tags from the "origin"
and store them under .git/refs/tags/.
<8> from time to time, obtain official tags from the `origin`
and store them under `.git/refs/tags/`.
Push into another repository.::
+
------------
satellite$ git clone mothership:frotz/.git frotz <1>
satellite$ git clone mothership:frotz frotz <1>
satellite$ cd frotz
satellite$ cat .git/remotes/origin <2>
URL: mothership:frotz/.git
Pull: master:origin
satellite$ echo 'Push: master:satellite' >>.git/remotes/origin <3>
satellite$ git repo-config --get-regexp '^(remote|branch)\.' <2>
remote.origin.url mothership:frotz
remote.origin.fetch refs/heads/*:refs/remotes/origin/*
branch.master.remote origin
branch.master.merge refs/heads/master
satellite$ git repo-config remote.origin.push \
master:refs/remotes/satellite/master <3>
satellite$ edit/compile/test/commit
satellite$ git push origin <4>
mothership$ cd frotz
mothership$ git checkout master
mothership$ git pull . satellite <5>
mothership$ git merge satellite/master <5>
------------
+
<1> mothership machine has a frotz repository under your home
directory; clone from it to start a repository on the satellite
machine.
<2> clone creates this file by default. It arranges "git pull"
to fetch and store the master branch head of mothership machine
to local "origin" branch.
<3> arrange "git push" to push local "master" branch to
"satellite" branch of the mothership machine.
<4> push will stash our work away on "satellite" branch on the
mothership machine. You could use this as a back-up method.
<2> clone sets these configuration variables by default.
It arranges `git pull` to fetch and store the branches of mothership
machine to local `remotes/origin/*` tracking branches.
<3> arrange `git push` to push local `master` branch to
`remotes/satellite/master` branch of the mothership machine.
<4> push will stash our work away on `remotes/satellite/master`
tracking branch on the mothership machine. You could use this as
a back-up method.
<5> on mothership machine, merge the work done on the satellite
machine into the master branch.
@ -266,7 +254,7 @@ $ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
+
<1> create a private branch based on a well known (but somewhat behind)
tag.
<2> forward port all changes in private2.6.14 branch to master branch
<2> forward port all changes in `private2.6.14` branch to `master` branch
without a formal "merging".
@ -303,13 +291,13 @@ $ mailx <3>
& s 2 3 4 5 ./+to-apply
& s 7 8 ./+hold-linus
& q
$ git checkout master
$ git checkout -b topic/one master
$ git am -3 -i -s -u ./+to-apply <4>
$ compile/test
$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>
$ git checkout topic/one && git rebase master <6>
$ git checkout pu && git reset --hard master <7>
$ git pull . topic/one topic/two && git pull . hold/linus <8>
$ git checkout pu && git reset --hard next <7>
$ git merge topic/one topic/two && git merge hold/linus <8>
$ git checkout maint
$ git cherry-pick master~4 <9>
$ compile/test
@ -326,29 +314,32 @@ they are.
that are not quite ready.
<4> apply them, interactively, with my sign-offs.
<5> create topic branch as needed and apply, again with my
sign-offs.
sign-offs.
<6> rebase internal topic branch that has not been merged to the
master, nor exposed as a part of a stable branch.
<7> restart "pu" every time from the master.
<7> restart `pu` every time from the next.
<8> and bundle topic branches still cooking.
<9> backport a critical fix.
<10> create a signed tag.
<11> make sure I did not accidentally rewind master beyond what I
already pushed out. "ko" shorthand points at the repository I have
already pushed out. `ko` shorthand points at the repository I have
at kernel.org, and looks like this:
+
------------
$ cat .git/remotes/ko
URL: kernel.org:/pub/scm/git/git.git
Pull: master:refs/tags/ko-master
Pull: next:refs/tags/ko-next
Pull: maint:refs/tags/ko-maint
Push: master
Push: next
Push: +pu
Push: maint
------------
+
In the output from "git show-branch", "master" should have
everything "ko-master" has.
In the output from `git show-branch`, `master` should have
everything `ko-master` has, and `next` should have
everything `ko-next` has.
<12> push out the bleeding edge.
<13> push the tag out, too.
@ -372,12 +363,19 @@ example of managing a shared central repository.
Examples
~~~~~~~~
We assume the following in /etc/services::
+
------------
$ grep 9418 /etc/services
git 9418/tcp # Git Version Control System
------------
Run git-daemon to serve /pub/scm from inetd.::
+
------------
$ grep git /etc/inetd.conf
git stream tcp nowait nobody \
/usr/bin/git-daemon git-daemon --inetd --syslog --export-all /pub/scm
/usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
------------
+
The actual configuration line should be on one line.
@ -397,7 +395,7 @@ service git
wait = no
user = nobody
server = /usr/bin/git-daemon
server_args = --inetd --syslog --export-all --base-path=/pub/scm
server_args = --inetd --export-all --base-path=/pub/scm
log_on_failure += USERID
}
------------
@ -418,7 +416,7 @@ $ grep git /etc/shells <2>
------------
+
<1> log-in shell is set to /usr/bin/git-shell, which does not
allow anything but "git push" and "git pull". The users should
allow anything but `git push` and `git pull`. The users should
get an ssh access to the machine.
<2> in many distributions /etc/shells needs to list what is used
as the login shell.

11
Documentation/fetch-options.txt
View file

@ -36,6 +36,13 @@
-u, \--update-head-ok::
By default `git-fetch` refuses to update the head which
corresponds to the current branch. This flag disables the
check. Note that fetching into the current branch will not
update the index and working directory, so use it with care.
check. This is purely for the internal use for `git-pull`
to communicate with `git-fetch`, and unless you are
implementing your own Porcelain you are not supposed to
use it.
\--depth=<depth>::
Deepen the history of a 'shallow' repository created by
`git clone` with `--depth=<depth>` option (see gitlink:git-clone[1])
by the specified number of commits.

183
Documentation/git-add.txt
View file

@ -3,24 +3,45 @@ git-add(1)
NAME
----
git-add - Add files to the index file
git-add - Add file contents to the changeset to be committed next
SYNOPSIS
--------
'git-add' [-n] [-v] [--] <file>...
'git-add' [-n] [-v] [-f] [--interactive] [--] <file>...
DESCRIPTION
-----------
A simple wrapper for git-update-index to add files to the index,
for people used to do "cvs add".
All the changed file contents to be committed together in a single set
of changes must be "added" with the 'add' command before using the
'commit' command. This is not only for adding new files. Even modified
files must be added to the set of changes about to be committed.
This command can be performed multiple times before a commit. The added
content corresponds to the state of specified file(s) at the time the
'add' command is used. This means the 'commit' command will not consider
subsequent changes to already added content if it is not added again before
the commit.
The 'git status' command can be used to obtain a summary of what is included
for the next commit.
This command can be used to add ignored files with `-f` (force)
option, but they have to be
explicitly and exactly specified from the command line. File globbing
and recursive behaviour do not add ignored files.
Please see gitlink:git-commit[1] for alternative ways to add content to a
commit.
It only adds non-ignored files, to add ignored files use
"git update-index --add".
OPTIONS
-------
<file>...::
Files to add to the index (see gitlink:git-ls-files[1]).
Files to add content from. Fileglobs (e.g. `*.c`) can
be given to add all matching files. Also a
leading directory name (e.g. `dir` to add `dir/file1`
and `dir/file2`) can be given to add all files in the
directory, recursively.
-n::
Don't actually add the file(s), just show if they exist.
@ -28,33 +49,25 @@ OPTIONS
-v::
Be verbose.
-f::
Allow adding otherwise ignored files.
\--interactive::
Add modified contents in the working tree interactively to
the index.
\--::
This option can be used to separate command-line options from
the list of files, (useful when filenames might be mistaken
for command-line options).
DISCUSSION
----------
The list of <file> given to the command is fed to `git-ls-files`
command to list files that are not registered in the index and
are not ignored/excluded by `$GIT_DIR/info/exclude` file or
`.gitignore` file in each directory. This means two things:
. You can put the name of a directory on the command line, and
the command will add all files in it and its subdirectories;
. Giving the name of a file that is already in index does not
run `git-update-index` on that path.
EXAMPLES
--------
git-add Documentation/\\*.txt::
Adds all `\*.txt` files that are not in the index under
`Documentation` directory and its subdirectories.
Adds content from all `\*.txt` files under `Documentation`
directory and its subdirectories.
+
Note that the asterisk `\*` is quoted from the shell in this
example; this lets the command to include the files from
@ -62,15 +75,131 @@ subdirectories of `Documentation/` directory.
git-add git-*.sh::
Adds all git-*.sh scripts that are not in the index.
Considers adding content from all git-*.sh scripts.
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.
consider `subdir/git-foo.sh`.
Interactive mode
----------------
When the command enters the interactive mode, it shows the
output of the 'status' subcommand, and then goes into ints
interactive command loop.
The command loop shows the list of subcommands available, and
gives a prompt "What now> ". In general, when the prompt ends
with a single '>', you can pick only one of the choices given
and type return, like this:
------------
*** Commands ***
1: status 2: update 3: revert 4: add untracked
5: patch 6: diff 7: quit 8: help
What now> 1
------------
You also could say "s" or "sta" or "status" above as long as the
choice is unique.
The main command loop has 6 subcommands (plus help and quit).
status::
This shows the change between HEAD and index (i.e. what will be
committed if you say "git commit"), and between index and
working tree files (i.e. what you could stage further before
"git commit" using "git-add") for each path. A sample output
looks like this:
+
------------
staged unstaged path
1: binary nothing foo.png
2: +403/-35 +1/-1 git-add--interactive.perl
------------
+
It shows that foo.png has differences from HEAD (but that is
binary so line count cannot be shown) and there is no
difference between indexed copy and the working tree
version (if the working tree version were also different,
'binary' would have been shown in place of 'nothing'). The
other file, git-add--interactive.perl, has 403 lines added
and 35 lines deleted if you commit what is in the index, but
working tree file has further modifications (one addition and
one deletion).
update::
This shows the status information and gives prompt
"Update>>". When the prompt ends with double '>>', you can
make more than one selection, concatenated with whitespace or
comma. Also you can say ranges. E.g. "2-5 7,9" to choose
2,3,4,5,7,9 from the list. You can say '*' to choose
everything.
+
What you chose are then highlighted with '*',
like this:
+
------------
staged unstaged path
1: binary nothing foo.png
* 2: +403/-35 +1/-1 git-add--interactive.perl
------------
+
To remove selection, prefix the input with `-`
like this:
+
------------
Update>> -2
------------
+
After making the selection, answer with an empty line to stage the
contents of working tree files for selected paths in the index.
revert::
This has a very similar UI to 'update', and the staged
information for selected paths are reverted to that of the
HEAD version. Reverting new paths makes them untracked.
add untracked::
This has a very similar UI to 'update' and
'revert', and lets you add untracked paths to the index.
patch::
This lets you choose one path out of 'status' like selection.
After choosing the path, it presents diff between the index
and the working tree file and asks you if you want to stage
the change of each hunk. You can say:
y - add the change from that hunk to index
n - do not add the change from that hunk to index
a - add the change from that hunk and all the rest to index
d - do not the change from that hunk nor any of the rest to index
j - do not decide on this hunk now, and view the next
undecided hunk
J - do not decide on this hunk now, and view the next hunk
k - do not decide on this hunk now, and view the previous
undecided hunk
K - do not decide on this hunk now, and view the previous hunk
+
After deciding the fate for all hunks, if there is any hunk
that was chosen, the index is updated with the selected hunks.
diff::
This lets you review what will be committed (i.e. between
HEAD and index).
See Also
--------
gitlink:git-status[1]
gitlink:git-rm[1]
gitlink:git-ls-files[1]
gitlink:git-mv[1]
gitlink:git-commit[1]
gitlink:git-update-index[1]
Author
------

19
Documentation/git-am.txt
View file

@ -9,7 +9,7 @@ git-am - Apply a series of patches in a mailbox
SYNOPSIS
--------
[verse]
'git-am' [--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way]
'git-am' [--signoff] [--dotest=<dir>] [--utf8 | --no-utf8] [--binary] [--3way]
[--interactive] [--whitespace=<option>] <mbox>...
'git-am' [--skip | --resolved]
@ -29,8 +29,21 @@ OPTIONS
Instead of `.dotest` directory, use <dir> as a working
area to store extracted patches.
--utf8, --keep::
Pass `-u` and `-k` flags to `git-mailinfo` (see
--keep::
Pass `-k` flag to `git-mailinfo` (see gitlink:git-mailinfo[1]).
--utf8::
Pass `-u` flag to `git-mailinfo` (see gitlink:git-mailinfo[1]).
The proposed commit log message taken from the e-mail
are re-coded into UTF-8 encoding (configuration variable
`i18n.commitencoding` can be used to specify project's
preferred encoding if it is not UTF-8).
+
This was optional in prior versions of git, but now it is the
default. You could use `--no-utf8` to override this.
--no-utf8::
Do not pass `-u` flag to `git-mailinfo` (see
gitlink:git-mailinfo[1]).
--binary::

74
Documentation/git-apply.txt
View file

@ -10,9 +10,10 @@ SYNOPSIS
--------
[verse]
'git-apply' [--stat] [--numstat] [--summary] [--check] [--index] [--apply]
[--no-add] [--index-info] [--allow-binary-replacement] [-z] [-pNUM]
[-CNUM] [--whitespace=<nowarn|warn|error|error-all|strip>]
[<patch>...]
[--no-add] [--index-info] [--allow-binary-replacement | --binary]
[-R | --reverse] [--reject] [-z] [-pNUM] [-CNUM] [--inaccurate-eof]
[--whitespace=<nowarn|warn|error|error-all|strip>] [--exclude=PATH]
[--cached] [--verbose] [<patch>...]
DESCRIPTION
-----------
@ -32,8 +33,9 @@ OPTIONS
--numstat::
Similar to \--stat, but shows number of added and
deleted lines in decimal notation and pathname without
abbreviation, to make it more machine friendly. Turns
off "apply".
abbreviation, to make it more machine friendly. For
binary files, outputs two `-` instead of saying
`0 0`. Turns off "apply".
--summary::
Instead of applying the patch, output a condensed
@ -55,6 +57,11 @@ OPTIONS
up-to-date, it is flagged as an error. This flag also
causes the index file to be updated.
--cached::
Apply a patch without touching the working tree. Instead, take the
cached data, apply the patch, and store the result in the index,
without using the working tree. This implies '--index'.
--index-info::
Newer git-diff output has embedded 'index information'
for each blob to help identify the original version that
@ -62,6 +69,16 @@ OPTIONS
the original version of the blob is available locally,
outputs information about them to the standard output.
-R, --reverse::
Apply the patch in reverse.
--reject::
For atomicity, gitlink:git-apply[1] by default fails the whole patch and
does not touch the working tree when some of the hunks
do not apply. This option makes it apply
the parts of the patch that are applicable, and leave the
rejected hunks in corresponding *.rej files.
-z::
When showing the index information, do not munge paths,
but use NUL terminated machine readable format. Without
@ -79,9 +96,19 @@ OPTIONS
context exist they all must match. By default no context is
ever ignored.
--unidiff-zero::
By default, gitlink:git-apply[1] expects that the patch being
applied is a unified diff with at least one line of context.
This provides good safety measures, but breaks down when
applying a diff generated with --unified=0. To bypass these
checks use '--unidiff-zero'.
+
Note, for the reasons stated above usage of context-free patches are
discouraged.
--apply::
If you use any of the options marked ``Turns off
"apply"'' above, git-apply reads and outputs the
If you use any of the options marked "Turns off
'apply'" above, gitlink:git-apply[1] reads and outputs the
information you asked without actually applying the
patch. Give this flag after those flags to also apply
the patch.
@ -93,16 +120,16 @@ OPTIONS
the result with this option, which would apply the
deletion part but not addition part.
--allow-binary-replacement::
When applying a patch, which is a git-enhanced patch
that was prepared to record the pre- and post-image object
name in full, and the path being patched exactly matches
the object the patch applies to (i.e. "index" line's
pre-image object name is what is in the working tree),
and the post-image object is available in the object
database, use the post-image object as the patch
result. This allows binary files to be patched in a
very limited way.
--allow-binary-replacement, --binary::
Historically we did not allow binary patch applied
without an explicit permission from the user, and this
flag was the way to do so. Currently we always allow binary
patch application, so this is a no-op.
--exclude=<path-pattern>::
Don't apply changes to files matching the given path pattern. This can
be useful when importing patchsets, where you want to exclude certain
files or directories.
--whitespace=<option>::
When applying a patch, detect a new or modified line
@ -110,7 +137,7 @@ OPTIONS
line that solely consists of whitespaces). By default,
the command outputs warning messages and applies the
patch.
When `git-apply` is used for statistics and not applying a
When gitlink:git-apply[1] is used for statistics and not applying a
patch, it defaults to `nowarn`.
You can use different `<option>` to control this
behavior:
@ -124,6 +151,17 @@ OPTIONS
* `strip` outputs warnings for a few such errors, strips out the
trailing whitespaces and applies the patch.
--inaccurate-eof::
Under certain circumstances, some versions of diff do not correctly
detect a missing new-line at the end of the file. As a result, patches
created by such diff programs do not record incomplete lines
correctly. This option adds support for applying such patches by
working around this bug.
--verbose::
Report progress to stderr. By default, only a message about the
current patch being applied will be printed. This option will cause
additional information to be reported.
Configuration
-------------

14
Documentation/git-applymbox.txt
View file

@ -42,13 +42,13 @@ OPTIONS
and the current tree.
-u::
By default, the commit log message, author name and
author email are taken from the e-mail without any
charset conversion, after minimally decoding MIME
transfer encoding. This flag causes the resulting
commit to be encoded in utf-8 by transliterating them.
Note that the patch is always used as is without charset
conversion, even with this flag.
The commit log message, author name and author email are
taken from the e-mail, and after minimally decoding MIME
transfer encoding, re-coded in UTF-8 by transliterating
them. This used to be optional but now it is the default.
+
Note that the patch is always used as-is without charset
conversion, even with this flag.
-c .dotest/<num>::
When the patch contained in an e-mail does not cleanly

113
Documentation/git-archive.txt Normal file
View file

@ -0,0 +1,113 @@
git-archive(1)
==============
NAME
----
git-archive - Creates a archive of the files in the named tree
SYNOPSIS
--------
'git-archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
[--remote=<repo>] <tree-ish> [path...]
DESCRIPTION
-----------
Creates an archive of the specified format containing the tree
structure for the named tree. If <prefix> is specified it is
prepended to the filenames in the archive.
'git-archive' behaves differently when given a tree ID versus when
given a commit ID or tag ID. In the first case the current time is
used as modification time of each file in the archive. In the latter
case the commit time as recorded in the referenced commit object is
used instead. Additionally the commit ID is stored in a global
extended pax header if the tar format is used; it can be extracted
using 'git-get-tar-commit-id'. In ZIP files it is stored as a file
comment.
OPTIONS
-------
--format=<fmt>::
Format of the resulting archive: 'tar', 'zip'...
--list::
Show all available formats.
--prefix=<prefix>/::
Prepend <prefix>/ to each filename in the archive.
<extra>::
This can be any options that the archiver backend understand.
See next section.
--remote=<repo>::
Instead of making a tar archive from local repository,
retrieve a tar archive from a remote repository.
<tree-ish>::
The tree or commit to produce an archive for.
path::
If one or more paths are specified, include only these in the
archive, otherwise include all files and subdirectories.
BACKEND EXTRA OPTIONS
---------------------
zip
~~~
-0::
Store the files instead of deflating them.
-9::
Highest and slowest compression level. You can specify any
number from 1 to 9 to adjust compression speed and ratio.
CONFIGURATION
-------------
By default, file and directories modes are set to 0666 or 0777 in tar
archives. It is possible to change this by setting the "umask" variable
in the repository configuration as follows :
[tar]
umask = 002 ;# group friendly
The special umask value "user" indicates that the user's current umask
will be used instead. The default value remains 0, which means world
readable/writable files and directories.
EXAMPLES
--------
git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)::
Create a tar archive that contains the contents of the
latest commit on the current branch, and extracts it in
`/var/tmp/junk` directory.
git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz::
Create a compressed tarball for v1.4.0 release.
git archive --format=tar --prefix=git-1.4.0/ v1.4.0{caret}\{tree\} | gzip >git-1.4.0.tar.gz::
Create a compressed tarball for v1.4.0 release, but without a
global extended pax header.
git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip::
Put everything in the current head's Documentation/ directory
into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'.
Author
------
Written by Franck Bui-Huu and Rene Scharfe.
Documentation
--------------
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite

137
Documentation/git-blame.txt
View file

@ -3,21 +3,45 @@ git-blame(1)
NAME
----
git-blame - Blame file lines on commits
git-blame - Show what revision and author last modified each line of a file
SYNOPSIS
--------
git-blame file [options] file [revision]
[verse]
'git-blame' [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>]
[-M] [-C] [-C] [--since=<date>] [<rev>] [--] <file>
DESCRIPTION
-----------
Annotates each line in the given file with information from the commit
which introduced the line. Start annotation from the given revision.
Annotates each line in the given file with information from the revision which
last modified the line. Optionally, start annotating from the given revision.
Also it can limit the range of lines annotated.
This report doesn't tell you anything about lines which have been deleted or
replaced; you need to use a tool such as gitlink:git-diff[1] or the "pickaxe"
interface briefly mentioned in the following paragraph.
Apart from supporting file annotation, git also supports searching the
development history for when a code snippet occured in a change. This makes it
possible to track when a code snippet was added to a file, moved or copied
between files, and eventually deleted or replaced. It works by searching for
a text string in the diff. A small example:
-----------------------------------------------------------------------------
$ git log --pretty=oneline -S'blame_usage'
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
-----------------------------------------------------------------------------
OPTIONS
-------
-c, --compatibility::
Use the same output mode as git-annotate (Default: off).
Use the same output mode as gitlink:git-annotate[1] (Default: off).
-L n,m::
Annotate only the specified line range (lines count from 1).
-l, --long::
Show long rev (Default: off).
@ -26,19 +50,118 @@ OPTIONS
Show raw timestamp (Default: off).
-S, --rev-file <revs-file>::
Use revs from revs-file instead of calling git-rev-list.
Use revs from revs-file instead of calling gitlink:git-rev-list[1].
-f, --show-name::
Show filename in the original commit. By default
filename is shown if there is any line that came from a
file with different name, due to rename detection.
-n, --show-number::
Show line number in the original commit (Default: off).
-p, --porcelain::
Show in a format designed for machine consumption.
-M::
Detect moving lines in the file as well. When a commit
moves a block of lines in a file (e.g. the original file
has A and then B, and the commit changes it to B and
then A), traditional 'blame' algorithm typically blames
the lines that were moved up (i.e. B) to the parent and
assigns blame to the lines that were moved down (i.e. A)
to the child commit. With this option, both groups of
lines are blamed on the parent.
-C::
In addition to `-M`, detect lines copied from other
files that were modified in the same commit. This is
useful when you reorganize your program and move code
around across files. When this option is given twice,
the command looks for copies from all other files in the
parent for the commit that creates the file in addition.
-h, --help::
Show help message.
THE PORCELAIN FORMAT
--------------------
In this format, each line is output after a header; the
header at the minumum has the first line which has:
- 40-byte SHA-1 of the commit the line is attributed to;
- the line number of the line in the original file;
- the line number of the line in the final file;
- on a line that starts a group of line from a different
commit than the previous one, the number of lines in this
group. On subsequent lines this field is absent.
This header line is followed by the following information
at least once for each commit:
- author name ("author"), email ("author-mail"), time
("author-time"), and timezone ("author-tz"); similarly
for committer.
- filename in the commit the line is attributed to.
- the first line of the commit log message ("summary").
The contents of the actual line is output after the above
header, prefixed by a TAB. This is to allow adding more
header elements later.
SPECIFIYING RANGES
------------------
Unlike `git-blame` and `git-annotate` in older git, the extent
of annotation can be limited to both line ranges and revision
ranges. When you are interested in finding the origin for
ll. 40-60 for file `foo`, you can use `-L` option like this:
git blame -L 40,60 foo
Also you can use regular expression to specify the line range.
git blame -L '/^sub hello {/,/^}$/' foo
would limit the annotation to the body of `hello` subroutine.
When you are not interested in changes older than the version
v2.6.18, or changes older than 3 weeks, you can use revision
range specifiers similar to `git-rev-list`:
git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo
When revision range specifiers are used to limit the annotation,
lines that have not changed since the range boundary (either the
commit v2.6.18 or the most recent commit that is more than 3
weeks old in the above example) are blamed for that range
boundary commit.
A particularly useful way is to see if an added file have lines
created by copy-and-paste from existing files. Sometimes this
indicates that the developer was being sloppy and did not
refactor the code properly. You can first find the commit that
introduced the file with:
git log --diff-filter=A --pretty=short -- foo
and then annotate the change between the commit and its
parents, using `commit{caret}!` notation:
git blame -C -C -f $commit^! -- foo
SEE ALSO
--------
gitlink:git-annotate[1]
AUTHOR
------
Written by Fredrik Kuivinen <freku045@student.liu.se>.
Written by Junio C Hamano <junkio@cox.net>
GIT
---

55
Documentation/git-branch.txt
View file

@ -8,23 +8,33 @@ git-branch - List, create, or delete branches.
SYNOPSIS
--------
[verse]
'git-branch' [-r]
'git-branch' [--color | --no-color] [-r | -a] [-v [--abbrev=<length>]]
'git-branch' [-l] [-f] <branchname> [<start-point>]
'git-branch' (-d | -D) <branchname>...
'git-branch' (-m | -M) [<oldbranch>] <newbranch>
'git-branch' (-d | -D) [-r] <branchname>...
DESCRIPTION
-----------
With no arguments given (or just `-r`) a list of available branches
With no arguments given a list of existing branches
will be shown, the current branch will be highlighted with an asterisk.
Option `-r` causes the remote-tracking branches to be listed,
and option `-a` shows both.
In its second form, a new branch named <branchname> will be created.
It will start out with a head equal to the one given as <start-point>.
If no <start-point> is given, the branch will be created with a head
equal to that of the currently checked out branch.
With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.
If <oldbranch> had a corresponding reflog, it is renamed to match
<newbranch>, and a reflog entry is created to remember the branch
renaming. If <newbranch> exists, -M must be used to force the rename
to happen.
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
has a ref log then the ref log will also be deleted.
has a ref log then the ref log will also be deleted. Use -r together with -d
to delete remote-tracking branches.
OPTIONS
@ -44,8 +54,31 @@ OPTIONS
Force the creation of a new branch even if it means deleting
a branch that already exists with the same name.
-m::
Move/rename a branch and the corresponding reflog.
-M::
Move/rename a branch even if the new branchname already exists.
--color::
Color branches to highlight current, local, and remote branches.
--no-color::
Turn off branch colors, even when the configuration file gives the
default to color output.
-r::
List only the "remote" branches.
List or delete (if used with -d) the remote-tracking branches.
-a::
List both remote-tracking branches and local branches.
-v::
Show sha1 and commit subjectline for each head.
--abbrev=<length>::
Alter minimum display length for sha1 in output listing,
default value is 7.
<branchname>::
The name of the branch to create or delete.
@ -58,6 +91,12 @@ OPTIONS
be given as a branch name, a commit-id, or a tag. If this option
is omitted, the current branch is assumed.
<oldbranch>::
The name of an existing branch to rename.
<newbranch>::
The new name for an existing branch. The same restrictions as for
<branchname> applies.
Examples
@ -80,10 +119,12 @@ Delete unneeded branch::
------------
$ git clone git://git.kernel.org/.../git.git my.git
$ cd my.git
$ git branch -D todo <1>
$ git branch -d -r todo html man <1>
$ git branch -D test <2>
------------
+
<1> delete todo branch even if the "master" branch does not have all
<1> delete remote-tracking branches "todo", "html", "man"
<2> delete "test" branch even if the "master" branch does not have all
commits from todo branch.

23
Documentation/git-cherry-pick.txt
View file

@ -7,7 +7,7 @@ git-cherry-pick - Apply the change introduced by an existing commit
SYNOPSIS
--------
'git-cherry-pick' [--edit] [-n] [-r] <commit>
'git-cherry-pick' [--edit] [-n] [-x] <commit>
DESCRIPTION
-----------
@ -24,13 +24,22 @@ OPTIONS
With this option, `git-cherry-pick` will let you edit the commit
message prior committing.
-r|--replay::
Usually the command appends which commit was
-x::
Cause the command to append which commit was
cherry-picked after the original commit message when
making a commit. This option, '--replay', causes it to
use the original commit message intact. This is useful
when you are reordering the patches in your private tree
before publishing.
making a commit. Do not use this option if you are
cherry-picking from your private branch because the
information is useless to the recipient. If on the
other hand you are cherry-picking between two publicly
visible branches (e.g. backporting a fix to a
maintenance branch for an older release from a
development branch), adding this information can be
useful.
-r|--replay::
It used to be that the command defaulted to do `-x`
described above, and `-r` was to disable it. Now the
default is not to do `-x` so this option is a no-op.
-n|--no-commit::
Usually the command automatically creates a commit with

24
Documentation/git-cherry.txt
View file

@ -7,17 +7,33 @@ git-cherry - Find commits not merged upstream
SYNOPSIS
--------
'git-cherry' [-v] <upstream> [<head>]
'git-cherry' [-v] <upstream> [<head>] [<limit>]
DESCRIPTION
-----------
The changeset (or "diff") of each commit between the fork-point and <head>
is compared against each commit between the fork-point and <upstream>.
Every commit with a changeset that doesn't exist in the other branch
has its id (sha1) reported, prefixed by a symbol. Those existing only
Every commit that doesn't exist in the <upstream> branch
has its id (sha1) reported, prefixed by a symbol. The ones that have
equivalent change already
in the <upstream> branch are prefixed with a minus (-) sign, and those
that only exist in the <head> branch are prefixed with a plus (+) symbol.
that only exist in the <head> branch are prefixed with a plus (+) symbol:
__*__*__*__*__> <upstream>
/
fork-point
\__+__+__-__+__+__-__+__> <head>
If a <limit> has been given then the commits along the <head> branch up
to and including <limit> are not reported:
__*__*__*__*__> <upstream>
/
fork-point
\__*__*__<limit>__-__+__> <head>
Because git-cherry compares the changeset rather than the commit id
(sha1), you can use git-cherry to find out if a commit you made locally

56
Documentation/git-clone.txt
View file

@ -11,25 +11,25 @@ SYNOPSIS
[verse]
'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
[--use-separate-remote] <repository> [<directory>]
[--depth=<depth>] <repository> [<directory>]
DESCRIPTION
-----------
Clones a repository into a newly created directory. All remote
branch heads are copied under `$GIT_DIR/refs/heads/`, except
that the remote `master` is also copied to `origin` branch.
In addition, `$GIT_DIR/remotes/origin` file is set up to have
this line:
Clones a repository into a newly created directory, creates
remote-tracking branches for each branch in the cloned repository
(visible using `git branch -r`), and creates and checks out an initial
branch equal to the cloned repository's currently active branch.
Pull: master:origin
After the clone, a plain `git fetch` without arguments will update
all the remote-tracking branches, and a `git pull` without
arguments will in addition merge the remote master branch into the
current master branch, if any.
This is to help the typical workflow of working off of the
remote `master` branch. Every time `git pull` without argument
is run, the progress on the remote `master` branch is tracked by
copying it into the local `origin` branch, and merged into the
branch you are currently working on. Remote branches other than
`master` are also added there to be tracked.
This default configuration is achieved by creating references to
the remote branch heads under `$GIT_DIR/refs/remotes/origin` and
by initializing `remote.origin.url` and `remote.origin.fetch`
configuration variables.
OPTIONS
@ -71,16 +71,18 @@ OPTIONS
Make a 'bare' GIT repository. That is, instead of
creating `<directory>` and placing the administrative
files in `<directory>/.git`, make the `<directory>`
itself the `$GIT_DIR`. This implies `-n` option. When
this option is used, neither the `origin` branch nor the
default `remotes/origin` file is created.
itself the `$GIT_DIR`. This obviously implies the `-n`
because there is nowhere to check out the working tree.
Also the branch heads at the remote are copied directly
to corresponding local branch heads, without mapping
them to `refs/remotes/origin/`. When this option is
used, neither remote-tracking branches nor the related
configuration variables are created.
--origin <name>::
-o <name>::
Instead of using the branch name 'origin' to keep track
of the upstream repository, use <name> instead. Note
that the shorthand name stored in `remotes/origin` is
not affected, but the local branch name to pull the
remote `master` branch into is.
Instead of using the remote name 'origin' to keep track
of the upstream repository, use <name> instead.
--upload-pack <upload-pack>::
-u <upload-pack>::
@ -94,10 +96,14 @@ OPTIONS
if unset the templates are taken from the installation
defined default, typically `/usr/share/git-core/templates`.
--use-separate-remote::
Save remotes heads under `$GIT_DIR/remotes/origin/` instead
of `$GIT_DIR/refs/heads/`. Only the master branch is saved
in the latter.
--depth=<depth>::
Create a 'shallow' clone with a history truncated to the
specified number of revs. A shallow repository has
number of limitations (you cannot clone or fetch from
it, nor push from nor into it), but is adequate if you
want to only look at near the tip of a large project
with a long history, and would want to send in a fixes
as patches.
<repository>::
The (possibly remote) repository to clone from. It can

5
Documentation/git-commit-tree.txt
View file

@ -81,6 +81,11 @@ Your parents must have hated you!::
Your sysadmin must hate you!::
The password(5) name field is longer than a giant static buffer.
Discussion
----------
include::i18n.txt[]
See Also
--------
gitlink:git-write-tree[1]

228
Documentation/git-commit.txt
View file

@ -14,25 +14,42 @@ SYNOPSIS
DESCRIPTION
-----------
Updates the index file for given paths, or all modified files if
'-a' is specified, and makes a commit object. The command specified
by either the VISUAL or EDITOR environment variables are used to edit
the commit log message.
Use 'git commit' when you want to record your changes into the repository
along with a log message describing what the commit is about. All changes
to be committed must be explicitly identified using one of the following
methods:
Several environment variable are used during commits. They are
documented in gitlink:git-commit-tree[1].
1. by using gitlink:git-add[1] to incrementally "add" changes to the
next commit before using the 'commit' command (Note: even modified
files must be "added");
2. by using gitlink:git-rm[1] to identify content removal for the next
commit, again before using the 'commit' command;
3. by directly listing files containing changes to be committed as arguments
to the 'commit' command, in which cases only those files alone will be
considered for the commit;
4. by using the -a switch with the 'commit' command to automatically "add"
changes from all known files i.e. files that have already been committed
before, and to automatically "rm" files that have been
removed from the working tree, and perform the actual commit.
The gitlink:git-status[1] command can be used to obtain a
summary of what is included by any of the above for the next
commit by giving the same set of parameters you would give to
this command.
If you make a commit and then found a mistake immediately after
that, you can recover from it with gitlink:git-reset[1].
This command can run `commit-msg`, `pre-commit`, and
`post-commit` hooks. See link:hooks.html[hooks] for more
information.
OPTIONS
-------
-a|--all::
Update all paths in the index file. This flag notices
files that have been modified and deleted, but new files
you have not told git about are not affected.
Tell the command to automatically stage files that have
been modified and deleted, but new files you have not
told git about are not affected.
-c or -C <commit>::
Take existing commit object, and reuse the log message
@ -55,16 +72,9 @@ OPTIONS
-s|--signoff::
Add Signed-off-by line at the end of the commit message.
-v|--verify::
Look for suspicious lines the commit introduces, and
abort committing if there is one. The definition of
'suspicious lines' is currently the lines that has
trailing whitespaces, and the lines whose indentation
has a SP character immediately followed by a TAB
character. This is the default.
-n|--no-verify::
The opposite of `--verify`.
--no-verify::
This option bypasses the pre-commit hook.
See also link:hooks.html[hooks].
-e|--edit::
The message taken from file with `-F`, command line with
@ -95,69 +105,145 @@ but can be used to amend a merge commit.
--
-i|--include::
Instead of committing only the files specified on the
command line, update them in the index file and then
commit the whole index. This is the traditional
behavior.
Before making a commit out of staged contents so far,
stage the contents of paths given on the command line
as well. This is usually not what you want unless you
are concluding a conflicted merge.
-o|--only::
Commit only the files specified on the command line.
This format cannot be used during a merge, nor when the
index and the latest commit does not match on the
specified paths to avoid confusion.
-q|--quiet::
Supress commit summary message.
\--::
Do not interpret any more arguments as options.
<file>...::
Files to be committed. The meaning of these is
different between `--include` and `--only`. Without
either, it defaults `--only` semantics.
If you make a commit and then found a mistake immediately after
that, you can recover from it with gitlink:git-reset[1].
When files are given on the command line, the command
commits the contents of the named files, without
recording the changes already staged. The contents of
these files are also staged for the next commit on top
of what have been staged before.
Discussion
EXAMPLES
--------
When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
called the "index" with gitlink:git-add[1]. Removal
of a file is staged with gitlink:git-rm[1]. After building the
state to be committed incrementally with these commands, `git
commit` (without any pathname parameter) is used to record what
has been staged so far. This is the most basic form of the
command. An example:
------------
$ edit hello.c
$ git rm goodbye.c
$ git add hello.c
$ git commit
------------
////////////
We should fix 'git rm' to remove goodbye.c from both index and
working tree for the above example.
////////////
Instead of staging files after each individual change, you can
tell `git commit` to notice the changes to the files whose
contents are tracked in
your working tree and do corresponding `git add` and `git rm`
for you. That is, this example does the same as the earlier
example if there is no other change in your working tree:
------------
$ edit hello.c
$ rm goodbye.c
$ git commit -a
------------
The command `git commit -a` first looks at your working tree,
notices that you have modified hello.c and removed goodbye.c,
and performs necessary `git add` and `git rm` for you.
After staging changes to many files, you can alter the order the
changes are recorded in, by giving pathnames to `git commit`.
When pathnames are given, the command makes a commit that
only records the changes made to the named paths:
------------
$ edit hello.c hello.h
$ git add hello.c hello.h
$ edit Makefile
$ git commit Makefile
------------
This makes a commit that records the modification to `Makefile`.
The changes staged for `hello.c` and `hello.h` are not included
in the resulting commit. However, their changes are not lost --
they are still staged and merely held back. After the above
sequence, if you do:
------------
$ git commit
------------
this second commit would record the changes to `hello.c` and
`hello.h` as expected.
After a merge (initiated by either gitlink:git-merge[1] or
gitlink:git-pull[1]) stops because of conflicts, cleanly merged
paths are already staged to be committed for you, and paths that
conflicted are left in unmerged state. You would have to first
check which paths are conflicting with gitlink:git-status[1]
and after fixing them manually in your working tree, you would
stage the result as usual with gitlink:git-add[1]:
------------
$ git status | grep unmerged
unmerged: hello.c
$ edit hello.c
$ git add hello.c
------------
After resolving conflicts and staging the result, `git ls-files -u`
would stop mentioning the conflicted path. When you are done,
run `git commit` to finally record the merge:
------------
$ git commit
------------
As with the case to record your own changes, you can use `-a`
option to save typing. One difference is that during a merge
resolution, you cannot use `git commit` with pathnames to
alter the order the changes are committed, because the merge
should be recorded as a single commit. In fact, the command
refuses to run when given pathnames (but see `-i` option).
DISCUSSION
----------
`git commit` without _any_ parameter commits the tree structure
recorded by the current index file. This is a whole-tree commit
even the command is invoked from a subdirectory.
include::i18n.txt[]
`git commit --include paths...` is equivalent to
ENVIRONMENT VARIABLES
---------------------
The command specified by either the VISUAL or EDITOR environment
variables is used to edit the commit log message.
git update-index --remove paths...
git commit
HOOKS
-----
This command can run `commit-msg`, `pre-commit`, and
`post-commit` hooks. See link:hooks.html[hooks] for more
information.
That is, update the specified paths to the index and then commit
the whole tree.
`git commit paths...` largely bypasses the index file and
commits only the changes made to the specified paths. It has
however several safety valves to prevent confusion.
. It refuses to run during a merge (i.e. when
`$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users
that the traditional semantics now needs -i flag.
. It refuses to run if named `paths...` are different in HEAD
and the index (ditto about reminding). Added paths are OK.
This is because an earlier `git diff` (not `git diff HEAD`)
would have shown the differences since the last `git
update-index paths...` to the user, and an inexperienced user
may mistakenly think that the changes between the index and
the HEAD (i.e. earlier changes made before the last `git
update-index paths...` was done) are not being committed.
. It reads HEAD commit into a temporary index file, updates the
specified `paths...` and makes a commit. At the same time,
the real index file is also updated with the same `paths...`.
`git commit --all` updates the index file with _all_ changes to
the working tree, and makes a whole-tree commit, regardless of
which subdirectory the command is invoked in.
SEE ALSO
--------
gitlink:git-add[1],
gitlink:git-rm[1],
gitlink:git-mv[1],
gitlink:git-merge[1],
gitlink:git-commit-tree[1]
Author
------

4
Documentation/git-count-objects.txt
View file

@ -20,8 +20,8 @@ OPTIONS
-v::
In addition to the number of loose objects and disk
space consumed, it reports the number of in-pack
objects, and number of objects that can be removed by
running `git-prune-packed`.
objects, number of packs, and number of objects that can be
removed by running `git-prune-packed`.
Author

15
Documentation/git-cvsimport.txt
View file

@ -90,7 +90,8 @@ If you need to pass multiple options, separate them with a comma.
Print a short usage message and exit.
-z <fuzz>::
Pass the timestamp fuzz factor to cvsps.
Pass the timestamp fuzz factor to cvsps, in seconds. If unset,
cvsps defaults to 300s.
-s <subst>::
Substitute the character "/" in branch names with <subst>
@ -99,6 +100,18 @@ If you need to pass multiple options, separate them with a comma.
CVS by default uses the unix username when writing its
commit logs. Using this option and an author-conv-file
in this format
-a::
Import all commits, including recent ones. cvsimport by default
skips commits that have a timestamp less than 10 minutes ago.
-S <regex>::
Skip paths matching the regex.
-L <limit>::
Limit the number of commits imported. Workaround for cases where
cvsimport leaks memory.
+
---------
exon=Andreas Ericsson <ae@op5.se>

145
Documentation/git-daemon.txt
View file

@ -8,19 +8,21 @@ git-daemon - A really simple server for git repositories
SYNOPSIS
--------
[verse]
'git-daemon' [--verbose] [--syslog] [--inetd | --port=n] [--export-all]
'git-daemon' [--verbose] [--syslog] [--export-all]
[--timeout=n] [--init-timeout=n] [--strict-paths]
[--base-path=path] [--user-path | --user-path=path]
[--reuseaddr] [--detach] [--pid-file=file] [directory...]
[--interpolated-path=pathtemplate]
[--reuseaddr] [--detach] [--pid-file=file]
[--enable=service] [--disable=service]
[--allow-override=service] [--forbid-override=service]
[--inetd | [--listen=host_or_ipaddr] [--port=n] [--user=user [--group=group]]
[directory...]
DESCRIPTION
-----------
A really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT"
aka 9418. It waits for a connection, and will just execute "git-upload-pack"
when it gets one.
It's careful in that there's a magic request-line that gives the command and
what directory to upload, and it verifies that the directory is OK.
aka 9418. It waits for a connection asking for a service, and will serve
that service if it is enabled.
It verifies that the directory has the magic file "git-daemon-export-ok", and
it will refuse to export any git directory that hasn't explicitly been marked
@ -28,7 +30,14 @@ for export this way (unless the '--export-all' parameter is specified). If you
pass some directory paths as 'git-daemon' arguments, you can further restrict
the offers to a whitelist comprising of those.
This is ideally suited for read-only updates, i.e., pulling from git repositories.
By default, only `upload-pack` service is enabled, which serves
`git-fetch-pack` and `git-peek-remote` clients that are invoked
from `git-fetch`, `git-ls-remote`, and `git-clone`.
This is ideally suited for read-only updates, i.e., pulling from
git repositories.
An `upload-archive` also exists to serve `git-archive`.
OPTIONS
-------
@ -45,6 +54,16 @@ OPTIONS
'git://example.com/hello.git', `git-daemon` will interpret the path
as '/srv/git/hello.git'.
--interpolated-path=pathtemplate::
To support virtual hosting, an interpolated path template can be
used to dynamically construct alternate paths. The template
supports %H for the target hostname as supplied by the client but
converted to all lowercase, %CH for the canonical hostname,
%IP for the server's IP address, %P for the port number,
and %D for the absolute path of the named repository.
After interpolation, the path is validated against the directory
whitelist.
--export-all::
Allow pulling from all directories that look like GIT repositories
(have the 'objects' and 'refs' subdirectories), even if they
@ -52,9 +71,17 @@ OPTIONS
--inetd::
Have the server run as an inetd service. Implies --syslog.
Incompatible with --port, --listen, --user and --group options.
--port::
Listen on an alternative port.
--listen=host_or_ipaddr::
Listen on an a specific IP address or hostname. IP addresses can
be either an IPv4 address or an IPV6 address if supported. If IPv6
is not supported, then --listen=hostname is also not supported and
--listen must be given an IPv4 address.
Incompatible with '--inetd' option.
--port=n::
Listen on an alternative port. Incompatible with '--inetd' option.
--init-timeout::
Timeout between the moment the connection is established and the
@ -93,11 +120,109 @@ OPTIONS
--pid-file=file::
Save the process id in 'file'.
--user=user, --group=group::
Change daemon's uid and gid before entering the service loop.
When only `--user` is given without `--group`, the
primary group ID for the user is used. The values of
the option are given to `getpwnam(3)` and `getgrnam(3)`
and numeric IDs are not supported.
+
Giving these options is an error when used with `--inetd`; use
the facility of inet daemon to achieve the same before spawning
`git-daemon` if needed.
--enable-service, --disable-service::
Enable/disable the service site-wide per default. Note
that a service disabled site-wide can still be enabled
per repository if it is marked overridable and the
repository enables the service with an configuration
item.
--allow-override, --forbid-override::
Allow/forbid overriding the site-wide default with per
repository configuration. By default, all the services
are overridable.
<directory>::
A directory to add to the whitelist of allowed directories. Unless
--strict-paths is specified this will also include subdirectories
of each named directory.
SERVICES
--------
upload-pack::
This serves `git-fetch-pack` and `git-peek-remote`
clients. It is enabled by default, but a repository can
disable it by setting `daemon.uploadpack` configuration
item to `false`.
upload-archive::
This serves `git-archive --remote`.
EXAMPLES
--------
We assume the following in /etc/services::
+
------------
$ grep 9418 /etc/services
git 9418/tcp # Git Version Control System
------------
git-daemon as inetd server::
To set up `git-daemon` as an inetd service that handles any
repository under the whitelisted set of directories, /pub/foo
and /pub/bar, place an entry like the following into
/etc/inetd all on one line:
+
------------------------------------------------
git stream tcp nowait nobody /usr/bin/git-daemon
git-daemon --inetd --verbose --export-all
/pub/foo /pub/bar
------------------------------------------------
git-daemon as inetd server for virtual hosts::
To set up `git-daemon` as an inetd service that handles
repositories for different virtual hosts, `www.example.com`
and `www.example.org`, place an entry like the following into
`/etc/inetd` all on one line:
+
------------------------------------------------
git stream tcp nowait nobody /usr/bin/git-daemon
git-daemon --inetd --verbose --export-all
--interpolated-path=/pub/%H%D
/pub/www.example.org/software
/pub/www.example.com/software
/software
------------------------------------------------
+
In this example, the root-level directory `/pub` will contain
a subdirectory for each virtual host name supported.
Further, both hosts advertise repositories simply as
`git://www.example.com/software/repo.git`. For pre-1.4.0
clients, a symlink from `/software` into the appropriate
default repository could be made as well.
git-daemon as regular daemon for virtual hosts::
To set up `git-daemon` as a regular, non-inetd service that
handles repositories for multiple virtual hosts based on
their IP addresses, start the daemon like this:
+
------------------------------------------------
git-daemon --verbose --export-all
--interpolated-path=/pub/%IP/%D
/pub/192.168.1.200/software
/pub/10.10.220.23/software
------------------------------------------------
+
In this example, the root-level directory `/pub` will contain
a subdirectory for each virtual host IP address supported.
Repositories can still be accessed by hostname though, assuming
they correspond to these IP addresses.
Author
------
Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki

4
Documentation/git-diff-index.txt
View file

@ -54,7 +54,7 @@ If '--cached' is specified, it allows you to ask:
For example, let's say that you have worked on your working directory, updated
some files in the index and are ready to commit. You want to see exactly
*what* you are going to commit is without having to write a new tree
*what* you are going to commit, without having to write a new tree
object and compare it that way, and to do that, you just do
git-diff-index --cached HEAD
@ -68,7 +68,7 @@ matches my working directory. But doing a "git-diff-index" does:
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
You can trivially see that the above is a rename.
You can see easily that the above is a rename.
In fact, "git-diff-index --cached" *should* always be entirely equivalent to
actually doing a "git-write-tree" and comparing that. Except this one is much

5
Documentation/git-diff-tree.txt
View file

@ -73,10 +73,7 @@ separated with a single space are given.
This flag causes "git-diff-tree --stdin" to also show
the commit message before the differences.
--pretty[=(raw|medium|short)]::
This is used to control "pretty printing" format of the
commit message. Without "=<style>", it defaults to
medium.
include::pretty-formats.txt[]
--no-commit-id::
git-diff-tree outputs a line with the commit ID when

54
Documentation/git-diff.txt
View file

@ -8,36 +8,54 @@ git-diff - Show changes between commits, commit and working tree, etc
SYNOPSIS
--------
'git-diff' [ --diff-options ] <tree-ish>{0,2} [<path>...]
'git-diff' [ --diff-options ] <commit>{0,2} [--] [<path>...]
DESCRIPTION
-----------
Show changes between two trees, a tree and the working tree, a
tree and the index file, or the index file and the working tree.
The combination of what is compared with what is determined by
the number of trees given to the command.
* When no <tree-ish> is given, the working tree and the index
file are compared, using `git-diff-files`.
'git-diff' [--options] [--] [<path>...]::
* When one <tree-ish> is given, the working tree and the named
tree are compared, using `git-diff-index`. The option
`--cached` can be given to compare the index file and
the named tree.
This form is to view the changes you made relative to
the index (staging area for the next commit). In other
words, the differences are what you _could_ tell git to
further add to the index but you still haven't. You can
stage these changes by using gitlink:git-add[1].
'git-diff' [--options] --cached [<commit>] [--] [<path>...]::
This form is to view the changes you staged for the next
commit relative to the named <commit>. Typically you
would want comparison with the latest commit, so if you
do not give <commit>, it defaults to HEAD.
'git-diff' [--options] <commit> [--] [<path>...]::
This form is to view the changes you have in your
working tree relative to the named <commit>. You can
use HEAD to compare it with the latest commit, or a
branch name to compare with the tip of a different
branch.
'git-diff' [--options] <commit> <commit> [--] [<path>...]::
This form is to view the changes between two <commit>,
for example, tips of two branches.
Just in case if you are doing something exotic, it should be
noted that all of the <commit> in the above description can be
any <tree-ish>.
* When two <tree-ish>s are given, these two trees are compared
using `git-diff-tree`.
OPTIONS
-------
--diff-options::
'--diff-options' are passed to the `git-diff-files`,
`git-diff-index`, and `git-diff-tree` commands. See the
documentation for these commands for description.
include::diff-options.txt[]
<path>...::
The <path> arguments are also passed to `git-diff-\*`
commands.
The <paths> parameters, when given, are used to limit
the diff to the named paths (you can give directory
names and get diff for all files under them).
EXAMPLES
@ -51,7 +69,7 @@ $ git diff --cached <2>
$ git diff HEAD <3>
------------
+
<1> changes in the working tree since your last git-update-index.
<1> changes in the working tree not yet staged for the next commit.
<2> changes between the index and your last commit; what you
would be committing if you run "git commit" without "-a" option.
<3> changes in the working tree since your last commit; what you

3
Documentation/git-fetch-pack.txt
View file

@ -32,7 +32,8 @@ OPTIONS
-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.
in the object database. If provided twice then the pack is
locked against repacking.
--exec=<git-upload-pack>::
Use this to specify the path to 'git-upload-pack' on the

185
Documentation/git-for-each-ref.txt Normal file
View file

@ -0,0 +1,185 @@
git-for-each-ref(1)
===================
NAME
----
git-for-each-ref - Output information on each ref
SYNOPSIS
--------
'git-for-each-ref' [--count=<count>]\* [--shell|--perl|--python] [--sort=<key>]\* [--format=<format>] [<pattern>]
DESCRIPTION
-----------
Iterate over all refs that match `<pattern>` and show them
according to the given `<format>`, after sorting them according
to the given set of `<key>`. If `<max>` is given, stop after
showing that many refs. The interporated values in `<format>`
can optionally be quoted as string literals in the specified
host language allowing their direct evaluation in that language.
OPTIONS
-------
<count>::
By default the command shows all refs that match
`<pattern>`. This option makes it stop after showing
that many refs.
<key>::
A field name to sort on. Prefix `-` to sort in
descending order of the value. When unspecified,
`refname` is used. More than one sort keys can be
given.
<format>::
A string that interpolates `%(fieldname)` from the
object pointed at by a ref being shown. If `fieldname`
is prefixed with an asterisk (`*`) and the ref points
at a tag object, the value for the field in the object
tag refers is used. When unspecified, defaults to
`%(objectname) SPC %(objecttype) TAB %(refname)`.
It also interpolates `%%` to `%`, and `%xx` where `xx`
are hex digits interpolates to character with hex code
`xx`; for example `%00` interpolates to `\0` (NUL),
`%09` to `\t` (TAB) and `%0a` to `\n` (LF).
<pattern>::
If given, the name of the ref is matched against this
using fnmatch(3). Refs that do not match the pattern
are not shown.
--shell, --perl, --python::
If given, strings that substitute `%(fieldname)`
placeholders are quoted as string literals suitable for
the specified host language. This is meant to produce
a scriptlet that can directly be `eval`ed.
FIELD NAMES
-----------
Various values from structured fields in referenced objects can
be used to interpolate into the resulting output, or as sort
keys.
For all objects, the following names can be used:
refname::
The name of the ref (the part after $GIT_DIR/refs/).
objecttype::
The type of the object (`blob`, `tree`, `commit`, `tag`).
objectsize::
The size of the object (the same as `git-cat-file -s` reports).
objectname::
The object name (aka SHA-1).
In addition to the above, for commit and tag objects, the header
field names (`tree`, `parent`, `object`, `type`, and `tag`) can
be used to specify the value in the header field.
Fields that have name-email-date tuple as its value (`author`,
`committer`, and `tagger`) can be suffixed with `name`, `email`,
and `date` to extract the named component.
The first line of the message in a commit and tag object is
`subject`, the remaining lines are `body`. The whole message
is `contents`.
For sorting purposes, fields with numeric values sort in numeric
order (`objectsize`, `authordate`, `committerdate`, `taggerdate`).
All other fields are used to sort in their byte-value order.
In any case, a field name that refers to a field inapplicable to
the object referred by the ref does not cause an error. It
returns an empty string instead.
EXAMPLES
--------
An example directly producing formatted text. Show the most recent
3 tagged commits::
------------
#!/bin/sh
git-for-each-ref --count=3 --sort='-*authordate' \
--format='From: %(*authorname) %(*authoremail)
Subject: %(*subject)
Date: %(*authordate)
Ref: %(*refname)
%(*body)
' 'refs/tags'
------------
A simple example showing the use of shell eval on the output,
demonstrating the use of --shell. List the prefixes of all heads::
------------
#!/bin/sh
git-for-each-ref --shell --format="ref=%(refname)" refs/heads | \
while read entry
do
eval "$entry"
echo `dirname $ref`
done
------------
A bit more elaborate report on tags, demonstrating that the format
may be an entire script::
------------
#!/bin/sh
fmt='
r=%(refname)
t=%(*objecttype)
T=${r#refs/tags/}
o=%(*objectname)
n=%(*authorname)
e=%(*authoremail)
s=%(*subject)
d=%(*authordate)
b=%(*body)
kind=Tag
if test "z$t" = z
then
# could be a lightweight tag
t=%(objecttype)
kind="Lightweight tag"
o=%(objectname)
n=%(authorname)
e=%(authoremail)
s=%(subject)
d=%(authordate)
b=%(body)
fi
echo "$kind $T points at a $t object $o"
if test "z$t" = zcommit
then
echo "The commit was authored by $n $e
at $d, and titled
$s
Its message reads as:
"
echo "$b" | sed -e "s/^/ /"
echo
fi
'
eval=`git-for-each-ref --shell --format="$fmt" \
--sort='*objecttype' \
--sort=-taggerdate \
refs/tags`
eval "$eval"
------------

64
Documentation/git-gc.txt Normal file
View file

@ -0,0 +1,64 @@
git-gc(1)
=========
NAME
----
git-gc - Cleanup unnecessary files and optimize the local repository
SYNOPSIS
--------
'git-gc'
DESCRIPTION
-----------
Runs a number of housekeeping tasks within the current repository,
such as compressing file revisions (to reduce disk space and increase
performance) and removing unreachable objects which may have been
created from prior invocations of gitlink:git-add[1].
Users are encouraged to run this task on a regular basis within
each repository to maintain good disk space utilization and good
operating performance.
Configuration
-------------
The optional configuration variable 'gc.reflogExpire' can be
set to indicate how long historical entries within each branch's
reflog should remain available in this repository. The setting is
expressed as a length of time, for example '90 days' or '3 months'.
It defaults to '90 days'.
The optional configuration variable 'gc.reflogExpireUnreachable'
can be set to indicate how long historical reflog entries which
are not part of the current branch should remain available in
this repository. These types of entries are generally created as
a result of using `git commit \--amend` or `git rebase` and are the
commits prior to the amend or rebase occuring. Since these changes
are not part of the current project most users will want to expire
them sooner. This option defaults to '30 days'.
The optional configuration variable 'gc.rerereresolved' indicates
how long records of conflicted merge you resolved earlier are
kept. This defaults to 60 days.
The optional configuration variable 'gc.rerereunresolved' indicates
how long records of conflicted merge you have not resolved are
kept. This defaults to 15 days.
See Also
--------
gitlink:git-prune[1]
gitlink:git-reflog[1]
gitlink:git-repack[1]
gitlink:git-rerere[1]
Author
------
Written by Shawn O. Pearce <spearce@spearce.org>
GIT
---
Part of the gitlink:git[7] suite

20
Documentation/git-grep.txt
View file

@ -11,10 +11,10 @@ SYNOPSIS
[verse]
'git-grep' [--cached]
[-a | --text] [-I] [-i | --ignore-case] [-w | --word-regexp]
[-v | --invert-match] [--full-name]
[-v | --invert-match] [-h|-H] [--full-name]
[-E | --extended-regexp] [-G | --basic-regexp] [-F | --fixed-strings]
[-n] [-l | --files-with-matches] [-L | --files-without-match]
[-c | --count]
[-c | --count] [--all-match]
[-A <post-context>] [-B <pre-context>] [-C <context>]
[-f <file>] [-e] <pattern> [--and|--or|--not|(|)|-e <pattern>...]
[<tree>...]
@ -47,6 +47,13 @@ OPTIONS
-v | --invert-match::
Select non-matching lines.
-h | -H::
By default, the command shows the filename for each
match. `-h` option is used to suppress this output.
`-H` is there for completeness and does not do anything
except it overrides `-h` given earlier on the command
line.
--full-name::
When run from a subdirectory, the command usually
outputs paths relative to the current directory. This
@ -89,6 +96,11 @@ OPTIONS
higher precedence than `--or`. `-e` has to be used for all
patterns.
--all-match::
When giving multiple pattern expressions combined with `--or`,
this flag is specified to limit the match to files that
have lines to match all of them.
`<tree>...`::
Search blobs in the trees for specified patterns.
@ -104,6 +116,10 @@ git grep -e \'#define\' --and \( -e MAX_PATH -e PATH_MAX \)::
Looks for a line that has `#define` and either `MAX_PATH` or
`PATH_MAX`.
git grep --all-match -e NODE -e Unexpected::
Looks for a line that has `NODE` or `Unexpected` in
files that have lines that match both.
Author
------
Originally written by Linus Torvalds <torvalds@osdl.org>, later

2
Documentation/git-http-push.txt
View file

@ -34,7 +34,7 @@ OPTIONS
Report the list of objects being walked locally and the
list of objects successfully sent to the remote repository.
<ref>...:
<ref>...::
The remote refs to update.

52
Documentation/git-index-pack.txt
View file

@ -8,7 +8,8 @@ git-index-pack - Build pack index file for an existing packed archive
SYNOPSIS
--------
'git-index-pack' [-o <index-file>] <pack-file>
'git-index-pack' [-v] [-o <index-file>] <pack-file>
'git-index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>] [<pack-file>]
DESCRIPTION
@ -21,6 +22,9 @@ objects/pack/ directory of a git repository.
OPTIONS
-------
-v::
Be verbose about what is going on, including progress status.
-o <index-file>::
Write the generated pack index into the specified
file. Without this option the name of pack index
@ -29,6 +33,52 @@ OPTIONS
fails if the name of packed archive does not end
with .pack).
--stdin::
When this flag is provided, the pack is read from stdin
instead and a copy is then written to <pack-file>. If
<pack-file> is not specified, the pack is written to
objects/pack/ directory of the current git repository with
a default name determined from the pack content. If
<pack-file> is not specified consider using --keep to
prevent a race condition between this process and
gitlink::git-repack[1] .
--fix-thin::
It is possible for gitlink:git-pack-objects[1] to build
"thin" pack, which records objects in deltified form based on
objects not included in the pack to reduce network traffic.
Those objects are expected to be present on the receiving end
and they must be included in the pack for that pack to be self
contained and indexable. Without this option any attempt to
index a thin pack will fail. This option only makes sense in
conjunction with --stdin.
--keep::
Before moving the index into its final destination
create an empty .keep file for the associated pack file.
This option is usually necessary with --stdin to prevent a
simultaneous gitlink:git-repack[1] process from deleting
the newly constructed pack and index before refs can be
updated to use objects contained in the pack.
--keep='why'::
Like --keep create a .keep file before moving the index into
its final destination, but rather than creating an empty file
place 'why' followed by an LF into the .keep file. The 'why'
message can later be searched for within all .keep files to
locate any which have outlived their usefulness.
Note
----
Once the index has been created, the list of object names is sorted
and the SHA1 hash of that list is printed to stdout. If --stdin was
also used then this is prefixed by either "pack\t", or "keep\t" if a
new .keep file was successfully created. This is useful to remove a
.keep file used as a lock to prevent the race with gitlink:git-repack[1]
mentioned above.
Author
------

86
Documentation/git-init-db.txt
View file

@ -11,91 +11,9 @@ SYNOPSIS
'git-init-db' [--template=<template_directory>] [--shared[=<permissions>]]
OPTIONS
-------
--
--template=<template_directory>::
Provide the directory from which templates will be used. The default template
directory is `/usr/share/git-core/templates`.
When specified, `<template_directory>` is used as the source of the template
files rather than the default. The template files include some directory
structure, some suggested "exclude patterns", and copies of non-executing
"hook" files. The suggested patterns and hook files are all modifiable and
extensible.
--shared[={false|true|umask|group|all|world|everybody}]::
Specify that the git repository is to be shared amongst several users. This
allows users belonging to the same group to push into that
repository. When specified, the config variable "core.sharedRepository" is
set so that files and directories under `$GIT_DIR` are created with the
requested permissions. When not specified, git will use permissions reported
by umask(2).
The option can have the following values, defaulting to 'group' if no value
is given:
- 'umask' (or 'false'): Use permissions reported by umask(2). The default,
when `--shared` is not specified.
- 'group' (or 'true'): Make the repository group-writable, (and g+sx, since
the git group may be not the primary group of all users).
- 'all' (or 'world' or 'everybody'): Same as 'group', but make the repository
readable by all users.
--
DESCRIPTION
-----------
This command creates an empty git repository - basically a `.git` directory
with subdirectories for `objects`, `refs/heads`, `refs/tags`, and
template files.
An initial `HEAD` file that references the HEAD of the master branch
is also created.
If the `$GIT_DIR` environment variable is set then it specifies a path
to use instead of `./.git` for the base of the repository.
If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY`
environment variable then the sha1 directories are created underneath -
otherwise the default `$GIT_DIR/objects` directory is used.
Running `git-init-db` in an existing repository is safe. It will not overwrite
things that are already there. The primary reason for rerunning `git-init-db`
is to pick up newly added templates.
EXAMPLES
--------
Start a new git repository for an existing code base::
+
----------------
$ cd /path/to/my/codebase
$ git-init-db <1>
$ git-add . <2>
----------------
+
<1> prepare /path/to/my/codebase/.git directory
<2> add all existing file to the index
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
Documentation
--------------
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
This is a synonym for gitlink:git-init[1]. Please refer to the
documentation of that command.

111
Documentation/git-init.txt Normal file
View file

@ -0,0 +1,111 @@
git-init(1)
===========
NAME
----
git-init - Creates an empty git repository
SYNOPSIS
--------
'git-init' [--template=<template_directory>] [--shared[=<permissions>]]
OPTIONS
-------
--
--template=<template_directory>::
Provide the directory from which templates will be used. The default template
directory is `/usr/share/git-core/templates`.
When specified, `<template_directory>` is used as the source of the template
files rather than the default. The template files include some directory
structure, some suggested "exclude patterns", and copies of non-executing
"hook" files. The suggested patterns and hook files are all modifiable and
extensible.
--shared[={false|true|umask|group|all|world|everybody}]::
Specify that the git repository is to be shared amongst several users. This
allows users belonging to the same group to push into that
repository. When specified, the config variable "core.sharedRepository" is
set so that files and directories under `$GIT_DIR` are created with the
requested permissions. When not specified, git will use permissions reported
by umask(2).
The option can have the following values, defaulting to 'group' if no value
is given:
- 'umask' (or 'false'): Use permissions reported by umask(2). The default,
when `--shared` is not specified.
- 'group' (or 'true'): Make the repository group-writable, (and g+sx, since
the git group may be not the primary group of all users).
- 'all' (or 'world' or 'everybody'): Same as 'group', but make the repository
readable by all users.
By default, the configuration flag receive.denyNonFastforward is enabled
in shared repositories, so that you cannot force a non fast-forwarding push
into it.
--
DESCRIPTION
-----------
This command creates an empty git repository - basically a `.git` directory
with subdirectories for `objects`, `refs/heads`, `refs/tags`, and
template files.
An initial `HEAD` file that references the HEAD of the master branch
is also created.
If the `$GIT_DIR` environment variable is set then it specifies a path
to use instead of `./.git` for the base of the repository.
If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY`
environment variable then the sha1 directories are created underneath -
otherwise the default `$GIT_DIR/objects` directory is used.
Running `git-init` in an existing repository is safe. It will not overwrite
things that are already there. The primary reason for rerunning `git-init`
is to pick up newly added templates.
Note that `git-init` is the same as `git-init-db`. The command
was primarily meant to initialize the object database, but over
time it has become responsible for setting up the other aspects
of the repository, such as installing the default hooks and
setting the configuration variables. The old name is retained
for backward compatibility reasons.
EXAMPLES
--------
Start a new git repository for an existing code base::
+
----------------
$ cd /path/to/my/codebase
$ git-init <1>
$ git-add . <2>
----------------
+
<1> prepare /path/to/my/codebase/.git directory
<2> add all existing file to the index
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
Documentation
--------------
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite

14
Documentation/git-log.txt
View file

@ -24,14 +24,16 @@ This manual page describes only the most frequently used options.
OPTIONS
-------
--pretty=<format>::
Controls the way the commit log is formatted.
include::pretty-formats.txt[]
--max-count=<n>::
Limits the number of commits to show.
<since>..<until>::
Show only commits between the named two commits.
Show only commits between the named two commits. When
either <since> or <until> is omitted, it defaults to
`HEAD`, i.e. the tip of the current branch.
-p::
Show the change the commit introduces in a patch form.
@ -63,6 +65,12 @@ git log -r --name-status release..test::
in the "release" branch, along with the list of paths
each commit modifies.
Discussion
----------
include::i18n.txt[]
Author
------
Written by Linus Torvalds <torvalds@osdl.org>

18
Documentation/git-ls-remote.txt
View file

@ -3,16 +3,19 @@ git-ls-remote(1)
NAME
----
git-ls-remote - Look at references other repository has
git-ls-remote - List references in a remote repository
SYNOPSIS
--------
'git-ls-remote' [--heads] [--tags] <repository> <refs>...
[verse]
'git-ls-remote' [--heads] [--tags] [-u <exec> | --upload-pack <exec>]
<repository> <refs>...
DESCRIPTION
-----------
Displays the references other repository has.
Displays references available in a remote repository along with the associated
commit IDs.
OPTIONS
@ -23,9 +26,16 @@ OPTIONS
both, references stored in refs/heads and refs/tags are
displayed.
-u <exec>, --upload-pack=<exec>::
Specify the full path of gitlink:git-upload-pack[1] on the remote
host. This allows listing references from repositories accessed via
SSH and where the SSH deamon does not use the PATH configured by the
user. Also see the '--exec' option for gitlink:git-peek-remote[1].
<repository>::
Location of the repository. The shorthand defined in
$GIT_DIR/branches/ can be used.
$GIT_DIR/branches/ can be used. Use "." (dot) to list references in
the local repository.
<refs>...::
When unspecified, all references, after filtering done

16
Documentation/git-mailinfo.txt
View file

@ -33,15 +33,13 @@ OPTIONS
format-patch --mbox' output.
-u::
By default, the commit log message, author name and
author email are taken from the e-mail without any
charset conversion, after minimally decoding MIME
transfer encoding. This flag causes the resulting
commit to be encoded in the encoding specified by
i18n.commitencoding configuration (defaults to utf-8) by
transliterating them.
Note that the patch is always used as is without charset
conversion, even with this flag.
The commit log message, author name and author email are
taken from the e-mail, and after minimally decoding MIME
transfer encoding, re-coded in UTF-8 by transliterating
them. This used to be optional but now it is the default.
+
Note that the patch is always used as-is without charset
conversion, even with this flag.
--encoding=<encoding>::
Similar to -u but if the local convention is different

92
Documentation/git-merge-file.txt Normal file
View file

@ -0,0 +1,92 @@
git-merge-file(1)
=================
NAME
----
git-merge-file - three-way file merge
SYNOPSIS
--------
[verse]
'git-merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
[-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file>
DESCRIPTION
-----------
git-file-merge incorporates all changes that lead from the `<base-file>`
to `<other-file>` into `<current-file>`. The result ordinarily goes into
`<current-file>`. git-merge-file is useful for combining separate changes
to an original. Suppose `<base-file>` is the original, and both
`<current-file>` and `<other-file>` are modifications of `<base-file>`.
Then git-merge-file combines both changes.
A conflict occurs if both `<current-file>` and `<other-file>` have changes
in a common segment of lines. If a conflict is found, git-merge-file
normally outputs a warning and brackets the conflict with <<<<<<< and
>>>>>>> lines. A typical conflict will look like this:
<<<<<<< A
lines in file A
=======
lines in file B
>>>>>>> B
If there are conflicts, the user should edit the result and delete one of
the alternatives.
The exit value of this program is negative on error, and the number of
conflicts otherwise. If the merge was clean, the exit value is 0.
git-merge-file is designed to be a minimal clone of RCS merge, that is, it
implements all of RCS merge's functionality which is needed by
gitlink:git[1].
OPTIONS
-------
-L <label>::
This option may be given up to three times, and
specifies labels to be used in place of the
corresponding file names in conflict reports. That is,
`git-merge-file -L x -L y -L z a b c` generates output that
looks like it came from files x, y and z instead of
from files a, b and c.
-p::
Send results to standard output instead of overwriting
`<current-file>`.
-q::
Quiet; do not warn about conflicts.
EXAMPLES
--------
git merge-file README.my README README.upstream::
combines the changes of README.my and README.upstream since README,
tries to merge them and writes the result into README.my.
git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345::
merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels
`a` and `c` instead of `tmp/a123` and `tmp/c345`.
Author
------
Written by Johannes Schindelin <johannes.schindelin@gmx.de>
Documentation
--------------
Documentation by Johannes Schindelin and the git-list <git@vger.kernel.org>,
with parts copied from the original documentation of RCS merge.
GIT
---
Part of the gitlink:git[7] suite

4
Documentation/git-merge-index.txt
View file

@ -40,8 +40,8 @@ If "git-merge-index" is called with multiple <file>s (or -a) then it
processes them in turn only stopping if merge returns a non-zero exit
code.
Typically this is run with the a script calling the merge command from
the RCS package.
Typically this is run with the a script calling git's imitation of
the merge command from the RCS package.
A sample script called "git-merge-one-file" is included in the
distribution.

12
Documentation/git-merge.txt
View file

@ -8,12 +8,13 @@ git-merge - Grand Unified Merge Driver
SYNOPSIS
--------
'git-merge' [-n] [--no-commit] [-s <strategy>]... <msg> <head> <remote> <remote>...
[verse]
'git-merge' [-n] [--no-commit] [--squash] [-s <strategy>]...
-m=<msg> <remote> <remote>...
DESCRIPTION
-----------
This is the top-level user interface to the merge machinery
This is the top-level interface to the merge machinery
which drives multiple merge strategy scripts.
@ -27,10 +28,11 @@ include::merge-options.txt[]
to give a good default for automated `git-merge` invocations.
<head>::
our branch head commit.
Our branch head commit. This has to be `HEAD`, so new
syntax does not require it
<remote>::
other branch head merged into our branch. You need at
Other branch head merged into our branch. You need at
least one <remote>. Specifying more than one <remote>
obviously means you are trying an Octopus.

2
Documentation/git-p4import.txt
View file

@ -93,7 +93,7 @@ perforce branch into a branch named "jammy", like so:
------------
$ mkdir -p /home/sean/import/jam
$ cd /home/sean/import/jam
$ git init-db
$ git init
$ git p4import //public/jam jammy
------------

63
Documentation/git-pack-objects.txt
View file

@ -9,9 +9,9 @@ git-pack-objects - Create a packed archive of objects
SYNOPSIS
--------
[verse]
'git-pack-objects' [-q] [--no-reuse-delta] [--non-empty]
[--local] [--incremental] [--window=N] [--depth=N]
{--stdout | base-name} < object-list
'git-pack-objects' [-q] [--no-reuse-delta] [--delta-base-offset] [--non-empty]
[--local] [--incremental] [--window=N] [--depth=N] [--all-progress]
[--revs [--unpacked | --all]*] [--stdout | base-name] < object-list
DESCRIPTION
@ -47,17 +47,34 @@ base-name::
<base-name> to determine the name of the created file.
When this option is used, the two files are written in
<base-name>-<SHA1>.{pack,idx} files. <SHA1> is a hash
of object names (currently in random order so it does
not have any useful meaning) to make the resulting
filename reasonably unique, and written to the standard
of the sorted object names to make the resulting filename
based on the pack content, and written to the standard
output of the command.
--stdout::
Write the pack contents (what would have been written to
.pack file) out to the standard output.
--window and --depth::
These two options affects how the objects contained in
--revs::
Read the revision arguments from the standard input, instead of
individual object names. The revision arguments are processed
the same way as gitlink:git-rev-list[1] with `--objects` flag
uses its `commit` arguments to build the list of objects it
outputs. The objects on the resulting list are packed.
--unpacked::
This implies `--revs`. When processing the list of
revision arguments read from the standard input, limit
the objects packed to those that are not already packed.
--all::
This implies `--revs`. In addition to the list of
revision arguments read from the standard input, pretend
as if all refs under `$GIT_DIR/refs` are specified to be
included.
--window=[N], --depth=[N]::
These two options affect how the objects contained in
the pack are stored using delta compression. The
objects are first internally sorted by type, size and
optionally names and compared against the other objects
@ -66,6 +83,7 @@ base-name::
it too deep affects the performance on the unpacker
side, because delta data needs to be applied that many
times to get to the necessary object.
The default value for both --window and --depth is 10.
--incremental::
This flag causes an object already in a pack ignored
@ -81,6 +99,23 @@ base-name::
Only create a packed archive if it would contain at
least one object.
--progress::
Progress status is reported on the standard error stream
by default when it is attached to a terminal, unless -q
is specified. This flag forces progress status even if
the standard error stream is not directed to a terminal.
--all-progress::
When --stdout is specified then progress report is
displayed during the object count and deltification phases
but inhibited during the write-out phase. The reason is
that in some cases the output stream is directly linked
to another command which may wish to display progress
status of its own as it processes incoming pack data.
This flag is like --progress except that it forces progress
report for the write-out phase as well even if --stdout is
used.
-q::
This flag makes the command not to report its progress
on the standard error stream.
@ -92,6 +127,17 @@ base-name::
This flag tells the command not to reuse existing deltas
but compute them from scratch.
--delta-base-offset::
A packed archive can express base object of a delta as
either 20-byte object name or as an offset in the
stream, but older version of git does not understand the
latter. By default, git-pack-objects only uses the
former format for better compatibility. This option
allows the command to use the latter format for
compactness. Depending on the average delta chain
length, this option typically shrinks the resulting
packfile by 3-5 per-cent.
Author
------
@ -103,6 +149,7 @@ Documentation by Junio C Hamano
See Also
--------
gitlink:git-rev-list[1]
gitlink:git-repack[1]
gitlink:git-prune-packed[1]

55
Documentation/git-pack-refs.txt Normal file
View file

@ -0,0 +1,55 @@
git-pack-refs(1)
================
NAME
----
git-pack-refs - Pack heads and tags for efficient repository access
SYNOPSIS
--------
'git-pack-refs' [--all] [--no-prune]
DESCRIPTION
-----------
Traditionally, tips of branches and tags (collectively known as
'refs') were stored one file per ref under `$GIT_DIR/refs`
directory. While many branch tips tend to be updated often,
most tags and some branch tips are never updated. When a
repository has hundreds or thousands of tags, this
one-file-per-ref format both wastes storage and hurts
performance.
This command is used to solve the storage and performance
problem by stashing the refs in a single file,
`$GIT_DIR/packed-refs`. When a ref is missing from the
traditional `$GIT_DIR/refs` hierarchy, it is looked up in this
file and used if found.
Subsequent updates to branches always creates new file under
`$GIT_DIR/refs` hierarchy.
OPTIONS
-------
\--all::
The command by default packs all tags and leaves branch tips
alone. This is because branches are expected to be actively
developed and packing their tips does not help performance.
This option causes branch tips to be packed as well. Useful for
a repository with many branches of historical interests.
\--no-prune::
The command usually removes loose refs under `$GIT_DIR/refs`
hierarchy after packing them. This option tells it not to.
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
GIT
---
Part of the gitlink:git[7] suite

5
Documentation/git-prune-packed.txt
View file

@ -9,7 +9,7 @@ residing in a pack file.
SYNOPSIS
--------
'git-prune-packed' [-n]
'git-prune-packed' [-n] [-q]
DESCRIPTION
@ -32,6 +32,9 @@ OPTIONS
Don't actually remove any objects, only show those that would have been
removed.
-q::
Squelch the progress indicator.
Author
------
Written by Linus Torvalds <torvalds@osdl.org>

69
Documentation/git-pull.txt
View file

@ -3,7 +3,7 @@ git-pull(1)
NAME
----
git-pull - Pull and merge from another repository
git-pull - Pull and merge from another repository or a local branch
SYNOPSIS
@ -37,17 +37,27 @@ EXAMPLES
--------
git pull, git pull origin::
Fetch the default head from the repository you cloned
from and merge it into your current branch.
Update the remote-tracking branches for the repository
you cloned from, then merge one of them into your
current branch. Normally the branch merged in is
the HEAD of the remote repository, but the choice is
determined by the branch.<name>.remote and
branch.<name>.merge options; see gitlink:git-repo-config[1]
for details.
git pull -s ours . obsolete::
Merge local branch `obsolete` into the current branch,
using `ours` merge strategy.
git pull origin next::
Merge into the current branch the remote branch `next`;
leaves a copy of `next` temporarily in FETCH_HEAD, but
does not update any remote-tracking branches.
git pull . fixes enhancements::
Bundle local branch `fixes` and `enhancements` on top of
the current branch, making an Octopus merge.
git pull -s ours . obsolete::
Merge local branch `obsolete` into the current branch,
using `ours` merge strategy.
git pull --no-commit . maint::
Merge local branch `maint` into the current branch, but
do not make a commit automatically. This can be used
@ -61,48 +71,19 @@ release/version name would be acceptable.
Command line pull of multiple branches from one repository::
+
------------------------------------------------
$ cat .git/remotes/origin
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: master:origin
$ git checkout master
$ git fetch origin master:origin +pu:pu maint:maint
$ git pull . origin
$ git fetch origin +pu:pu maint:tmp
$ git pull . tmp
------------------------------------------------
+
Here, a typical `.git/remotes/origin` file from a
`git-clone` operation is used in combination with
command line options to `git-fetch` to first update
multiple branches of the local repository and then
to merge the remote `origin` branch into the local
`master` branch. The local `pu` branch is updated
even if it does not result in a fast forward update.
Here, the pull can obtain its objects from the local
repository using `.`, as the previous `git-fetch` is
known to have already obtained and made available
all the necessary objects.
Pull of multiple branches from one repository using `.git/remotes` file::
This updates (or creates, as necessary) branches `pu` and `tmp`
in the local repository by fetching from the branches
(respectively) `pu` and `maint` from the remote repository.
+
------------------------------------------------
$ cat .git/remotes/origin
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: master:origin
Pull: +pu:pu
Pull: maint:maint
$ git checkout master
$ git pull origin
------------------------------------------------
The `pu` branch will be updated even if it is does not
fast-forward; the others will not be.
+
Here, a typical `.git/remotes/origin` file from a
`git-clone` operation has been hand-modified to include
the branch-mapping of additional remote and local
heads directly. A single `git-pull` operation while
in the `master` branch will fetch multiple heads and
merge the remote `origin` head into the current,
local `master` branch.
The final command then merges the newly fetched `tmp` into master.
If you tried a pull which resulted in a complex conflicts and
@ -112,7 +93,7 @@ gitlink:git-reset[1].
SEE ALSO
--------
gitlink:git-fetch[1], gitlink:git-merge[1]
gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-repo-config[1]
Author

15
Documentation/git-push.txt
View file

@ -49,12 +49,14 @@ corresponding remotes file---see below), then all the
refs that exist both on the local side and on the remote
side are updated.
+
Some short-cut notations are also supported.
`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+
* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
* A parameter <ref> without a colon is equivalent to
<ref>`:`<ref>, hence updates <ref> in the destination from <ref>
in the source.
A parameter <ref> without a colon is equivalent to
<ref>`:`<ref>, hence updates <ref> in the destination from <ref>
in the source.
+
Pushing an empty <src> allows you to delete the <dst> ref from
the remote repository.
\--all::
Instead of naming each ref to push, specifies that all
@ -75,7 +77,8 @@ include::urls.txt[]
Author
------
Written by Junio C Hamano <junkio@cox.net>
Written by Junio C Hamano <junkio@cox.net>, later rewritten in C
by Linus Torvalds <torvalds@osdl.org>
Documentation
--------------

16
Documentation/git-read-tree.txt
View file

@ -8,7 +8,7 @@ git-read-tree - Reads tree information into the index
SYNOPSIS
--------
'git-read-tree' (<tree-ish> | [[-m [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
'git-read-tree' (<tree-ish> | [[-m [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
DESCRIPTION
@ -71,6 +71,20 @@ OPTIONS
directory. Note that the `<prefix>/` value must end
with a slash.
--exclude-per-directory=<gitignore>::
When running the command with `-u` and `-m` options, the
merge result may need to overwrite paths that are not
tracked in the current branch. The command usually
refuses to proceed with the merge to avoid losing such a
path. However this safety valve sometimes gets in the
way. For example, it often happens that the other
branch added a file that used to be a generated file in
your branch, and the safety valve triggers when you try
to switch to that branch after you ran `make` but before
running `make clean` to remove the generated file. This
option tells the command to read per-directory exclude
file (usually '.gitignore') and allows such an untracked
but explicitly ignored file to be overwritten.
<tree-ish#>::
The id of the tree object(s) to be read/merged.

70
Documentation/git-rebase.txt
View file

@ -7,7 +7,7 @@ git-rebase - Rebase local commits to a new head
SYNOPSIS
--------
'git-rebase' [--merge] [--onto <newbase>] <upstream> [<branch>]
'git-rebase' [-v] [--merge] [--onto <newbase>] <upstream> [<branch>]
'git-rebase' --continue | --skip | --abort
@ -51,20 +51,69 @@ would be:
D---E---F---G master
------------
While, starting from the same point, the result of either of the following
commands:
The latter form is just a short-hand of `git checkout topic`
followed by `git rebase master`.
git-rebase --onto master~1 master
git-rebase --onto master~1 master topic
Here is how you would transplant a topic branch based on one
branch to another, to pretend that you forked the topic branch
from the latter branch, using `rebase --onto`.
would be:
First let's assume your 'topic' is based on branch 'next'.
For example feature developed in 'topic' depends on some
functionality which is found in 'next'.
------------
A'--B'--C' topic
/
D---E---F---G master
o---o---o---o---o master
\
o---o---o---o---o next
\
o---o---o topic
------------
We would want to make 'topic' forked from branch 'master',
for example because the functionality 'topic' branch depend on
got merged into more stable 'master' branch, like this:
------------
o---o---o---o---o master
| \
| o'--o'--o' topic
\
o---o---o---o---o next
------------
We can get this using the following command:
git-rebase --onto master next topic
Another example of --onto option is to rebase part of a
branch. If we have the following situation:
------------
H---I---J topicB
/
E---F---G topicA
/
A---B---C---D master
------------
then the command
git-rebase --onto master topicA topicB
would result in:
------------
H'--I'--J' topicB
/
| E---F---G topicA
|/
A---B---C---D master
------------
This is useful when topicB does not depend on topicA.
In case of conflict, git-rebase will stop at the first problematic commit
and leave conflict markers in the tree. You can use git diff to locate
the markers (<<<<<<) and make edits to resolve the conflict. For each
@ -121,6 +170,9 @@ OPTIONS
is used instead (`git-merge-recursive` when merging a single
head, `git-merge-octopus` otherwise). This implies --merge.
-v, \--verbose::
Display a diffstat of what changed upstream since the last rebase.
include::merge-strategies.txt[]
NOTES

2
Documentation/git-receive-pack.txt
View file

@ -73,6 +73,8 @@ packed and is served via a dumb transport.
There are other real-world examples of using update and
post-update hooks found in the Documentation/howto directory.
git-receive-pack honours the receive.denyNonFastforwards flag, which
tells it if updates to a ref should be denied if they are not fast-forwards.
OPTIONS
-------

59
Documentation/git-reflog.txt Normal file
View file

@ -0,0 +1,59 @@
git-reflog(1)
=============
NAME
----
git-reflog - Manage reflog information
SYNOPSIS
--------
[verse]
'git-reflog' expire [--dry-run]
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
DESCRIPTION
-----------
Reflog is a mechanism to record when the tip of branches are
updated. This command is to manage the information recorded in it.
The subcommand "expire" is used to prune older reflog entries.
Entries older than `expire` time, or entries older than
`expire-unreachable` time and are not reachable from the current
tip, are removed from the reflog. This is typically not used
directly by the end users -- instead, see gitlink:git-gc[1].
OPTIONS
-------
--expire=<time>::
Entries older than this time are pruned. Without the
option it is taken from configuration `gc.reflogExpire`,
which in turn defaults to 90 days.
--expire-unreachable=<time>::
Entries older than this time and are not reachable from
the current tip of the branch are pruned. Without the
option it is taken from configuration
`gc.reflogExpireUnreachable`, which in turn defaults to
30 days.
--all::
Instead of listing <refs> explicitly, prune all refs.
Author
------
Written by Junio C Hamano <junkio@cox.net>
Documentation
--------------
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite

76
Documentation/git-remote.txt Normal file
View file

@ -0,0 +1,76 @@
git-remote(1)
============
NAME
----
git-remote - manage set of tracked repositories
SYNOPSIS
--------
[verse]
'git-remote'
'git-remote' add <name> <url>
'git-remote' show <name>
DESCRIPTION
-----------
Manage the set of repositories ("remotes") whose branches you track.
With no arguments, shows a list of existing remotes.
In the second form, adds a remote named <name> for the repository at
<url>. The command `git fetch <name>` can then be used to create and
update remote-tracking branches <name>/<branch>.
In the third form, gives some information about the remote <name>.
The remote configuration is achieved using the `remote.origin.url` and
`remote.origin.fetch` configuration variables. (See
gitlink:git-repo-config[1]).
Examples
--------
Add a new remote, fetch, and check out a branch from it:
------------
$ git remote
origin
$ git branch -r
origin/master
$ git remote add linux-nfs git://linux-nfs.org/pub/nfs-2.6.git
$ git remote
linux-nfs
origin
$ git fetch
* refs/remotes/linux-nfs/master: storing branch 'master' ...
commit: bf81b46
$ git branch -r
origin/master
linux-nfs/master
$ git checkout -b nfs linux-nfs/master
...
------------
See Also
--------
gitlink:git-fetch[1]
gitlink:git-branch[1]
gitlink:git-repo-config[1]
Author
------
Written by Junio Hamano
Documentation
--------------
Documentation by J. Bruce Fields and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite

27
Documentation/git-repack.txt
View file

@ -9,7 +9,7 @@ objects into pack files.
SYNOPSIS
--------
'git-repack' [-a] [-d] [-f] [-l] [-n] [-q]
'git-repack' [-a] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]
DESCRIPTION
-----------
@ -56,6 +56,31 @@ OPTIONS
Do not update the server information with
`git update-server-info`.
--window=[N], --depth=[N]::
These two options affect how the objects contained in the pack are
stored using delta compression. The objects are first internally
sorted by type, size and optionally names and compared against the
other objects within `--window` to see if using delta compression saves
space. `--depth` limits the maximum delta depth; making it too deep
affects the performance on the unpacker side, because delta data needs
to be applied that many times to get to the necessary object.
The default value for both --window and --depth is 10.
Configuration
-------------
When configuration variable `repack.UseDeltaBaseOffset` is set
for the repository, the command passes `--delta-base-offset`
option to `git-pack-objects`; this typically results in slightly
smaller packs, but the generated packs are incompatible with
versions of git older than (and including) v1.4.3; do not set
the variable in a repository that older version of git needs to
be able to read (this includes repositories from which packs can
be copied out over http or rsync, and people who obtained packs
that way can try to use older git with it).
Author
------
Written by Linus Torvalds <torvalds@osdl.org>

57
Documentation/git-repo-config.txt
View file

@ -3,19 +3,20 @@ git-repo-config(1)
NAME
----
git-repo-config - Get and set options in .git/config
git-repo-config - Get and set repository or global options.
SYNOPSIS
--------
[verse]
'git-repo-config' [type] name [value [value_regex]]
'git-repo-config' [type] --replace-all name [value [value_regex]]
'git-repo-config' [type] --get name [value_regex]
'git-repo-config' [type] --get-all name [value_regex]
'git-repo-config' [type] --unset name [value_regex]
'git-repo-config' [type] --unset-all name [value_regex]
'git-repo-config' -l | --list
'git-repo-config' [--global] [type] name [value [value_regex]]
'git-repo-config' [--global] [type] --add name value
'git-repo-config' [--global] [type] --replace-all name [value [value_regex]]
'git-repo-config' [--global] [type] --get name [value_regex]
'git-repo-config' [--global] [type] --get-all name [value_regex]
'git-repo-config' [--global] [type] --unset name [value_regex]
'git-repo-config' [--global] [type] --unset-all name [value_regex]
'git-repo-config' [--global] -l | --list
DESCRIPTION
-----------
@ -23,7 +24,8 @@ You can query/set/replace/unset options with this command. The name is
actually the section and the key separated by a dot, and the value will be
escaped.
If you want to set/unset an option which can occur on multiple
Multiple lines can be added to an option by using the '--add' option.
If you want to update or unset an option which can occur on multiple
lines, a POSIX regexp `value_regex` needs to be given. Only the
existing values that match the regexp are updated or unset. If
you want to handle the lines that do *not* match the regex, just
@ -41,8 +43,9 @@ This command will fail if:
. Can not write to .git/config,
. no section was provided,
. the section or key is invalid,
. you try to unset an option which does not exist, or
. you try to unset/set an option for which multiple lines match.
. you try to unset an option which does not exist,
. you try to unset/set an option for which multiple lines match, or
. you use --global option without $HOME being properly set.
OPTIONS
@ -52,9 +55,14 @@ OPTIONS
Default behavior is to replace at most one line. This replaces
all lines matching the key (and optionally the value_regex).
--add::
Adds a new line to the option without altering any existing
values. This is the same as providing '^$' as the value_regex.
--get::
Get the value for a given key (optionally filtered by a regex
matching the value).
matching the value). Returns error code 1 if the key was not
found and error code 2 if multiple key values were found.
--get-all::
Like get, but does not fail if the number of values for the key
@ -63,14 +71,26 @@ OPTIONS
--get-regexp::
Like --get-all, but interprets the name as a regular expression.
--global::
Use global ~/.gitconfig file rather than the repository .git/config.
--unset::
Remove the line matching the key from .git/config.
Remove the line matching the key from config file.
--unset-all::
Remove all matching lines from .git/config.
Remove all matching lines from config file.
-l, --list::
List all variables set in .git/config.
List all variables set in config file.
--bool::
git-repo-config will ensure that the output is "true" or "false"
--int::
git-repo-config will ensure that the output is a simple
decimal number. An optional value suffix of 'k', 'm', or 'g'
in the config file will cause the value to be multiplied
by 1024, 1048576, or 1073741824 prior to output.
ENVIRONMENT
@ -78,6 +98,7 @@ ENVIRONMENT
GIT_CONFIG::
Take the configuration from the given file instead of .git/config.
Using the "--global" option forces this to ~/.gitconfig.
GIT_CONFIG_LOCAL::
Currently the same as $GIT_CONFIG; when Git will support global
@ -182,6 +203,12 @@ To actually match only values with an exclamation mark, you have to
% git repo-config section.key value '[!]'
------------
To add a new proxy, without altering any of the existing ones, use
------------
% git repo-config core.gitproxy '"proxy" for example.com'
------------
include::config.txt[]

39
Documentation/git-rerere.txt
View file

@ -7,8 +7,7 @@ git-rerere - Reuse recorded resolve
SYNOPSIS
--------
'git-rerere'
'git-rerere' [clear|diff|status|gc]
DESCRIPTION
-----------
@ -27,6 +26,42 @@ results and applying the previously recorded hand resolution.
You need to create `$GIT_DIR/rr-cache` directory to enable this
command.
COMMANDS
--------
Normally, git-rerere is run without arguments or user-intervention.
However, it has several commands that allow it to interact with
its working state.
'clear'::
This resets the metadata used by rerere if a merge resolution is to be
is aborted. Calling gitlink:git-am[1] --skip or gitlink:git-rebase[1]
[--skip|--abort] will automatcally invoke this command.
'diff'::
This displays diffs for the current state of the resolution. It is
useful for tracking what has changed while the user is resolving
conflicts. Additional arguments are passed directly to the system
diff(1) command installed in PATH.
'status'::
Like diff, but this only prints the filenames that will be tracked
for resolutions.
'gc'::
This command is used to prune records of conflicted merge that
occurred long time ago. By default, conflicts older than 15
days that you have not recorded their resolution, and conflicts
older than 60 days, are pruned. These are controlled with
`gc.rerereunresolved` and `gc.rerereresolved` configuration
variables.
DISCUSSION
----------

14
Documentation/git-reset.txt
View file

@ -7,7 +7,9 @@ git-reset - Reset current HEAD to the specified state
SYNOPSIS
--------
'git-reset' [--mixed | --soft | --hard] [<commit-ish>]
[verse]
'git-reset' [--mixed | --soft | --hard] [<commit>]
'git-reset' [--mixed] <commit> [--] <paths>...
DESCRIPTION
-----------
@ -21,6 +23,10 @@ the undo in the history.
If you want to undo a commit other than the latest on a branch,
gitlink:git-revert[1] is your friend.
The second form with 'paths' is used to revert selected paths in
the index from a given commit, without moving HEAD.
OPTIONS
-------
--mixed::
@ -31,15 +37,15 @@ OPTIONS
--soft::
Does not touch the index file nor the working tree at all, but
requires them to be in a good order. This leaves all your changed
files "Updated but not checked in", as gitlink:git-status[1] would
files "Added but not yet committed", as gitlink:git-status[1] would
put it.
--hard::
Matches the working tree and index to that of the tree being
switched to. Any changes to tracked files in the working tree
since <commit-ish> are lost.
since <commit> are lost.
<commit-ish>::
<commit>::
Commit to make the current HEAD.
Examples

266
Documentation/git-rev-list.txt
View file

@ -10,6 +10,7 @@ SYNOPSIS
--------
[verse]
'git-rev-list' [ \--max-count=number ]
[ \--skip=number ]
[ \--max-age=timestamp ]
[ \--min-age=timestamp ]
[ \--sparse ]
@ -17,8 +18,11 @@ SYNOPSIS
[ \--remove-empty ]
[ \--not ]
[ \--all ]
[ \--stdin ]
[ \--topo-order ]
[ \--parents ]
[ \--encoding[=<encoding>] ]
[ \--(author|committer|grep)=<pattern> ]
[ [\--objects | \--objects-edge] [ \--unpacked ] ]
[ \--pretty | \--header ]
[ \--bisect ]
@ -27,116 +31,258 @@ SYNOPSIS
DESCRIPTION
-----------
Lists commit objects in reverse chronological order starting at the
given commit(s), taking ancestry relationship into account. This is
useful to produce human-readable log output.
Commits which are stated with a preceding '{caret}' cause listing to stop at
that point. Their parents are implied. "git-rev-list foo bar {caret}baz" thus
Commits which are stated with a preceding '{caret}' cause listing to
stop at that point. Their parents are implied. Thus the following
command:
-----------------------------------------------------------------------
$ git-rev-list foo bar ^baz
-----------------------------------------------------------------------
means "list all the commits which are included in 'foo' and 'bar', but
not in 'baz'".
A special notation <commit1>..<commit2> can be used as a
short-hand for {caret}<commit1> <commit2>.
A special notation "'<commit1>'..'<commit2>'" can be used as a
short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of
the following may be used interchangeably:
Another special notation is <commit1>...<commit2> which is useful for
merges. The resulting set of commits is the symmetric difference
-----------------------------------------------------------------------
$ git-rev-list origin..HEAD
$ git-rev-list HEAD ^origin
-----------------------------------------------------------------------
Another special notation is "'<commit1>'...'<commit2>'" which is useful
for merges. The resulting set of commits is the symmetric difference
between the two operands. The following two commands are equivalent:
------------
$ git-rev-list A B --not $(git-merge-base --all A B)
$ git-rev-list A...B
------------
-----------------------------------------------------------------------
$ git-rev-list A B --not $(git-merge-base --all A B)
$ git-rev-list A...B
-----------------------------------------------------------------------
gitlink:git-rev-list[1] is a very essential git program, since it
provides the ability to build and traverse commit ancestry graphs. For
this reason, it has a lot of different options that enables it to be
used by commands as different as gitlink:git-bisect[1] and
gitlink:git-repack[1].
OPTIONS
-------
--pretty::
Print the contents of the commit changesets in human-readable form.
Commit Formatting
~~~~~~~~~~~~~~~~~
Using these options, gitlink:git-rev-list[1] will act similar to the
more specialized family of commit log tools: gitlink:git-log[1],
gitlink:git-show[1], and gitlink:git-whatchanged[1]
include::pretty-formats.txt[]
--relative-date::
Show dates relative to the current time, e.g. "2 hours ago".
Only takes effect for dates shown in human-readable format, such
as when using "--pretty".
--header::
Print the contents of the commit in raw-format; each
record is separated with a NUL character.
Print the contents of the commit in raw-format; each record is
separated with a NUL character.
--parents::
Print the parents of the commit.
--objects::
Print the object IDs of any object referenced by the listed commits.
'git-rev-list --objects foo ^bar' thus means "send me all object IDs
which I need to download if I have the commit object 'bar', but
not 'foo'".
Diff Formatting
~~~~~~~~~~~~~~~
--objects-edge::
Similar to `--objects`, but also print the IDs of
excluded commits prefixed with a `-` character. This is
used by `git-pack-objects` to build 'thin' pack, which
records objects in deltified form based on objects
contained in these excluded commits to reduce network
traffic.
Below are listed options that control the formatting of diff output.
Some of them are specific to gitlink:git-rev-list[1], however other diff
options may be given. See gitlink:git-diff-files[1] for more options.
--unpacked::
Only useful with `--objects`; print the object IDs that
are not in packs.
-c::
--bisect::
Limit output to the one commit object which is roughly halfway
between the included and excluded commits. Thus, if 'git-rev-list
--bisect foo {caret}bar {caret}baz' outputs 'midpoint', the output
of 'git-rev-list foo {caret}midpoint' and 'git-rev-list midpoint
{caret}bar {caret}baz' would be of roughly the same length.
Finding the change
which introduces a regression is thus reduced to a binary search:
repeatedly generate and test new 'midpoint's until the commit chain
is of length one.
This flag changes the way a merge commit is displayed. It shows
the differences from each of the parents to the merge result
simultaneously instead of showing pairwise diff between a parent
and the result one at a time. Furthermore, it lists only files
which were modified from all parents.
--cc::
This flag implies the '-c' options and further compresses the
patch output by omitting hunks that show differences from only
one parent, or show the same change from all but one parent for
an Octopus merge.
-r::
Show recursive diffs.
-t::
Show the tree objects in the diff output. This implies '-r'.
Commit Limiting
~~~~~~~~~~~~~~~
Besides specifying a range of commits that should be listed using the
special notations explained in the description, additional commit
limiting may be applied.
--
-n 'number', --max-count='number'::
--max-count::
Limit the number of commits output.
--max-age=timestamp, --min-age=timestamp::
--skip='number'::
Skip 'number' commits before starting to show the commit output.
--since='date', --after='date'::
Show commits more recent than a specific date.
--until='date', --before='date'::
Show commits older than a specific date.
--max-age='timestamp', --min-age='timestamp'::
Limit the commits output to specified time range.
--sparse::
When optional paths are given, the command outputs only
the commits that changes at least one of them, and also
ignores merges that do not touch the given paths. This
flag makes the command output all eligible commits
(still subject to count and age limitation), but apply
merge simplification nevertheless.
--author='pattern', --committer='pattern'::
Limit the commits output to ones with author/committer
header lines that match the specified pattern.
--grep='pattern'::
Limit the commits output to ones with log message that
matches the specified pattern.
--remove-empty::
Stop when a given path disappears from the tree.
--no-merges::
Do not print commits with more than one parent.
--not::
Reverses the meaning of the '{caret}' prefix (or lack
thereof) for all following revision specifiers, up to
the next `--not`.
Reverses the meaning of the '{caret}' prefix (or lack thereof)
for all following revision specifiers, up to the next '--not'.
--all::
Pretend as if all the refs in `$GIT_DIR/refs/` are
listed on the command line as <commit>.
--topo-order::
By default, the commits are shown in reverse
chronological order. This option makes them appear in
topological order (i.e. descendant commits are shown
before their parents).
Pretend as if all the refs in `$GIT_DIR/refs/` are listed on the
command line as '<commit>'.
--stdin::
In addition to the '<commit>' listed on the command
line, read them from the standard input.
--merge::
After a failed merge, show refs that touch files having a
conflict and don't exist on all heads to merge.
--boundary::
Output uninteresting commits at the boundary, which are usually
not shown.
--dense, --sparse::
When optional paths are given, the default behaviour ('--dense') is to
only output commits that changes at least one of them, and also ignore
merges that do not touch the given paths.
Use the '--sparse' flag to makes the command output all eligible commits
(still subject to count and age limitation), but apply merge
simplification nevertheless.
--bisect::
Limit output to the one commit object which is roughly halfway between
the included and excluded commits. Thus, if
-----------------------------------------------------------------------
$ git-rev-list --bisect foo ^bar ^baz
-----------------------------------------------------------------------
outputs 'midpoint', the output of the two commands
-----------------------------------------------------------------------
$ git-rev-list foo ^midpoint
$ git-rev-list midpoint ^bar ^baz
-----------------------------------------------------------------------
would be of roughly the same length. Finding the change which
introduces a regression is thus reduced to a binary search: repeatedly
generate and test new 'midpoint's until the commit chain is of length
one.
--
Commit Ordering
~~~~~~~~~~~~~~~
By default, the commits are shown in reverse chronological order.
--topo-order::
This option makes them appear in topological order (i.e.
descendant commits are shown before their parents).
--date-order::
This option is similar to '--topo-order' in the sense that no
parent comes before all of its children, but otherwise things
are still ordered in the commit timestamp order.
Object Traversal
~~~~~~~~~~~~~~~~
These options are mostly targeted for packing of git repositories.
--objects::
Print the object IDs of any object referenced by the listed
commits. 'git-rev-list --objects foo ^bar' thus means "send me
all object IDs which I need to download if I have the commit
object 'bar', but not 'foo'".
--objects-edge::
Similar to '--objects', but also print the IDs of excluded
commits prefixed with a "-" character. This is used by
gitlink:git-pack-objects[1] to build "thin" pack, which records
objects in deltified form based on objects contained in these
excluded commits to reduce network traffic.
--unpacked::
Only useful with '--objects'; print the object IDs that are not
in packs.
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
Documentation
--------------
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
Documentation by David Greaves, Junio C Hamano, Jonas Fonseca
and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite

54
Documentation/git-rev-parse.txt
View file

@ -111,7 +111,9 @@ SPECIFYING REVISIONS
A revision parameter typically, but not necessarily, names a
commit object. They use what is called an 'extended SHA1'
syntax.
syntax. Here are various ways to spell object names. The
ones listed near the end of this list are to name trees and
blobs contained in a commit.
* The full SHA1 object name (40-byte hexadecimal string), or
a substring of such that is unique within the repository.
@ -119,12 +121,31 @@ syntax.
name the same commit object if there are no other object in
your repository whose object name starts with dae86e.
* An output from `git-describe`; i.e. a closest tag, followed by a
dash, a `g`, and an abbreviated object name.
* A symbolic ref name. E.g. 'master' typically means the commit
object referenced by $GIT_DIR/refs/heads/master. If you
happen to have both heads/master and tags/master, you can
explicitly say 'heads/master' to tell git which one you mean.
When ambiguous, a `<name>` is disambiguated by taking the
first match in the following rules:
* A suffix '@' followed by a date specification enclosed in a brace
. if `$GIT_DIR/<name>` exists, that is what you mean (this is usually
useful only for `HEAD`, `FETCH_HEAD` and `MERGE_HEAD`);
. otherwise, `$GIT_DIR/refs/<name>` if exists;
. otherwise, `$GIT_DIR/refs/tags/<name>` if exists;
. otherwise, `$GIT_DIR/refs/heads/<name>` if exists;
. otherwise, `$GIT_DIR/refs/remotes/<name>` if exists;
. otherwise, `$GIT_DIR/refs/remotes/<name>/HEAD` if exists.
* A ref followed by the suffix '@' with a date specification
enclosed in a brace
pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1
second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value
of the ref at a prior point in time. This suffix may only be
@ -138,11 +159,12 @@ syntax.
'rev{caret}0' means the commit itself and is used when 'rev' is the
object name of a tag object that refers to a commit object.
* A suffix '~<n>' to a revision parameter means the commit
* A suffix '{tilde}<n>' to a revision parameter means the commit
object that is the <n>th generation grand-parent of the named
commit object, following only the first parent. I.e. rev~3 is
equivalent to rev{caret}{caret}{caret} which is equivalent to\
rev{caret}1{caret}1{caret}1.
equivalent to rev{caret}{caret}{caret} which is equivalent to
rev{caret}1{caret}1{caret}1. See below for a illustration of
the usage of this form.
* A suffix '{caret}' followed by an object type name enclosed in
brace pair (e.g. `v0.99.8{caret}\{commit\}`) means the object
@ -156,6 +178,15 @@ syntax.
and dereference the tag recursively until a non-tag object is
found.
* A suffix ':' followed by a path; this names the blob or tree
at the given path in the tree-ish object named by the part
before the colon.
* A colon, optionally followed by a stage number (0 to 3) and a
colon, followed by a path; this names a blob object in the
index at the given path. Missing stage number (and the colon
that follows it) names an stage 0 entry.
Here is an illustration, by Jon Loeliger. Both node B and C are
a commit parents of commit node A. Parent commits are ordered
left-to-right.
@ -208,14 +239,21 @@ of `r1` and `r2` and is defined as
It it the set of commits that are reachable from either one of
`r1` or `r2` but not from both.
Here are a few examples:
Two other shorthands for naming a set that is formed by a commit
and its parent commits exists. `r1{caret}@` notation means all
parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
its all parents.
Here are a handful examples:
D A B D
D F A B C D F
^A G B D
^A G B D
^A F B C F
G...I C D F G I
^B G I C D F G I
^B G I C D F G I
F^@ A B C
F^! H D F H
Author
------

51
Documentation/git-rm.txt
View file

@ -7,51 +7,54 @@ git-rm - Remove files from the working tree and from the index
SYNOPSIS
--------
'git-rm' [-f] [-n] [-v] [--] <file>...
'git-rm' [-f] [-n] [-r] [--cached] [--] <file>...
DESCRIPTION
-----------
A convenience wrapper for git-update-index --remove. For those coming
from cvs, git-rm provides an operation similar to "cvs rm" or "cvs
remove".
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).
OPTIONS
-------
<file>...::
Files to remove from the index and optionally, from the
working tree as well.
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.
-f::
Remove files from the working tree as well as from the index.
Override the up-to-date check.
-n::
Don't actually remove the file(s), just show if they exist in
the index.
-v::
Be verbose.
-r::
Allow recursive removal when a leading directory name is
given.
\--::
This option can be used to separate command-line options from
the list of files, (useful when filenames might be mistaken
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.
DISCUSSION
----------
The list of <file> given to the command is fed to `git-ls-files`
command to list files that are registered in the index and
are not ignored/excluded by `$GIT_DIR/info/exclude` file or
`.gitignore` file in each directory. This means two things:
. You can put the name of a directory on the command line, and the
command will remove all files in it and its subdirectories (the
directories themselves are never removed from the working tree);
. Giving the name of a file that is not in the index does not
remove that file.
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
a file that you have not told git about does not remove that file.
EXAMPLES
@ -69,10 +72,10 @@ subdirectories of `Documentation/` directory.
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`.
are removed from the index, and from the working
tree. 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`.
See Also
--------

69
Documentation/git-runstatus.txt Normal file
View file

@ -0,0 +1,69 @@
git-runstatus(1)
================
NAME
----
git-runstatus - A helper for git-status and git-commit
SYNOPSIS
--------
'git-runstatus' [--color|--nocolor] [--amend] [--verbose] [--untracked]
DESCRIPTION
-----------
Examines paths in the working tree that has changes unrecorded
to the index file, and changes between the index file and the
current HEAD commit. The former paths are what you _could_
commit by running 'git-update-index' before running 'git
commit', and the latter paths are what you _would_ commit by
running 'git commit'.
If there is no path that is different between the index file and
the current HEAD commit, the command exits with non-zero status.
Note that this is _not_ the user level command you would want to
run from the command line. Use 'git-status' instead.
OPTIONS
-------
--color::
Show colored status, highlighting modified file names.
--nocolor::
Turn off coloring.
--amend::
Show status based on HEAD^1, not HEAD, i.e. show what
'git-commit --amend' would do.
--verbose::
Show unified diff of all file changes.
--untracked::
Show files in untracked directories, too. Without this
option only its name and a trailing slash are displayed
for each untracked directory.
OUTPUT
------
The output from this command is designed to be used as a commit
template comments, and all the output lines are prefixed with '#'.
Author
------
Originally written by Linus Torvalds <torvalds@osdl.org> as part
of git-commit, and later rewritten in C by Jeff King.
Documentation
--------------
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite

9
Documentation/git-send-email.txt
View file

@ -66,8 +66,13 @@ The options available are:
all that is output.
--smtp-server::
If set, specifies the outgoing SMTP server to use. Defaults to
localhost.
If set, specifies the outgoing SMTP server to use. A full
pathname of a sendmail-like program can be specified instead;
the program must support the `-i` option. Default value can
be specified by the 'sendemail.smtpserver' configuration
option; the built-in default is `/usr/sbin/sendmail` or
`/usr/lib/sendmail` if such program is available, or
`localhost` otherwise.
--subject::
Specify the initial subject of the email thread.

2
Documentation/git-send-pack.txt
View file

@ -43,7 +43,7 @@ OPTIONS
<directory>::
The repository to update.
<ref>...:
<ref>...::
The remote refs to update.

18
Documentation/git-shortlog.txt
View file

@ -7,16 +7,30 @@ git-shortlog - Summarize 'git log' output
SYNOPSIS
--------
git-log --pretty=short | 'git-shortlog'
git-log --pretty=short | 'git-shortlog' [-h] [-n] [-s]
git-shortlog [-n|--number] [-s|--summary] [<committish>...]
DESCRIPTION
-----------
Summarizes 'git log' output in a format suitable for inclusion
in release announcements. Each commit will be grouped by author
in release announcements. Each commit will be grouped by author and
the first line of the commit message will be shown.
Additionally, "[PATCH]" will be stripped from the commit description.
OPTIONS
-------
-h::
Print a short usage message and exit.
-n::
Sort output according to the number of commits per author instead
of author alphabetic order.
-s::
Supress commit description and provide a commit count summary only.
FILES
-----
'.mailmap'::

25
Documentation/git-show-branch.txt
View file

@ -8,9 +8,10 @@ git-show-branch - Show branches and their commits
SYNOPSIS
--------
[verse]
'git-show-branch' [--all] [--heads] [--tags] [--topo-order] [--current]
'git-show-branch' [--all] [--remotes] [--topo-order] [--current]
[--more=<n> | --list | --independent | --merge-base]
[--no-name | --sha1-name] [<rev> | <glob>]...
[--no-name | --sha1-name] [--topics] [<rev> | <glob>]...
'git-show-branch' --reflog[=<n>] <ref>
DESCRIPTION
-----------
@ -37,9 +38,11 @@ OPTIONS
branches under $GIT_DIR/refs/heads/topic, giving
`topic/*` would show all of them.
--all --heads --tags::
Show all refs under $GIT_DIR/refs, $GIT_DIR/refs/heads,
and $GIT_DIR/refs/tags, respectively.
-r|--remotes::
Show the remote-tracking branches.
-a|--all::
Show both remote-tracking branches and local branches.
--current::
With this option, the command includes the current
@ -86,6 +89,18 @@ OPTIONS
of "master"), name them with the unique prefix of their
object names.
--topics::
Shows only commits that are NOT on the first branch given.
This helps track topic branches by hiding any commit that
is already in the main line of development. When given
"git show-branch --topics master topic1 topic2", this
will show the revisions given by "git rev-list {caret}master
topic1 topic2"
--reflog[=<n>] <ref>::
Shows <n> most recent ref-log entries for the given ref.
Note that --more, --list, --independent and --merge-base options
are mutually exclusive.

156
Documentation/git-show-ref.txt Normal file
View file

@ -0,0 +1,156 @@
git-show-ref(1)
===============
NAME
----
git-show-ref - List references in a local repository
SYNOPSIS
--------
[verse]
'git-show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
[-s|--hash] [--abbrev] [--tags] [--heads] [--] <pattern>...
DESCRIPTION
-----------
Displays references available in a local repository along with the associated
commit IDs. Results can be filtered using a pattern and tags can be
dereferenced into object IDs. Additionally, it can be used to test whether a
particular ref exists.
Use of this utility is encouraged in favor of directly accessing files under
in the `.git` directory.
OPTIONS
-------
-h, --head::
Show the HEAD reference.
--tags, --heads::
Limit to only "refs/heads" and "refs/tags", respectively. These
options are not mutually exclusive; when given both, references stored
in "refs/heads" and "refs/tags" are displayed.
-d, --dereference::
Dereference tags into object IDs as well. They will be shown with "^{}"
appended.
-s, --hash::
Only show the SHA1 hash, not the reference name. When also using
--dereference the dereferenced tag will still be shown after the SHA1.
--verify::
Enable stricter reference checking by requiring an exact ref path.
Aside from returning an error code of 1, it will also print an error
message if '--quiet' was not specified.
--abbrev, --abbrev=len::
Abbreviate the object name. When using `--hash`, you do
not have to say `--hash --abbrev`; `--hash=len` would do.
-q, --quiet::
Do not print any results to stdout. When combined with '--verify' this
can be used to silently check if a reference exists.
<pattern>::
Show references matching one or more patterns.
OUTPUT
------
The output is in the format: '<SHA-1 ID>' '<space>' '<reference name>'.
-----------------------------------------------------------------------------
$ git show-ref --head --dereference
832e76a9899f560a90ffd62ae2ce83bbeff58f54 HEAD
832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/master
832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/origin
3521017556c5de4159da4615a39fa4d5d2c279b5 refs/tags/v0.99.9c
6ddc0964034342519a87fe013781abf31c6db6ad refs/tags/v0.99.9c^{}
055e4ae3ae6eb344cbabf2a5256a49ea66040131 refs/tags/v1.0rc4
423325a2d24638ddcc82ce47be5e40be550f4507 refs/tags/v1.0rc4^{}
...
-----------------------------------------------------------------------------
When using --hash (and not --dereference) the output format is: '<SHA-1 ID>'
-----------------------------------------------------------------------------
$ git show-ref --heads --hash
2e3ba0114a1f52b47df29743d6915d056be13278
185008ae97960c8d551adcd9e23565194651b5d1
03adf42c988195b50e1a1935ba5fcbc39b2b029b
...
-----------------------------------------------------------------------------
EXAMPLE
-------
To show all references called "master", whether tags or heads or anything
else, and regardless of how deep in the reference naming hierarchy they are,
use:
-----------------------------------------------------------------------------
git show-ref master
-----------------------------------------------------------------------------
This will show "refs/heads/master" but also "refs/remote/other-repo/master",
if such references exists.
When using the '--verify' flag, the command requires an exact path:
-----------------------------------------------------------------------------
git show-ref --verify refs/heads/master
-----------------------------------------------------------------------------
will only match the exact branch called "master".
If nothing matches, gitlink:git-show-ref[1] will return an error code of 1,
and in the case of verification, it will show an error message.
For scripting, you can ask it to be quiet with the "--quiet" flag, which
allows you to do things like
-----------------------------------------------------------------------------
git-show-ref --quiet --verify -- "refs/heads/$headname" ||
echo "$headname is not a valid branch"
-----------------------------------------------------------------------------
to check whether a particular branch exists or not (notice how we don't
actually want to show any results, and we want to use the full refname for it
in order to not trigger the problem with ambiguous partial matches).
To show only tags, or only proper branch heads, use "--tags" and/or "--heads"
respectively (using both means that it shows tags and heads, but not other
random references under the refs/ subdirectory).
To do automatic tag object dereferencing, use the "-d" or "--dereference"
flag, so you can do
-----------------------------------------------------------------------------
git show-ref --tags --dereference
-----------------------------------------------------------------------------
to get a listing of all tags together with what they dereference.
SEE ALSO
--------
gitlink:git-ls-remote[1], gitlink:git-peek-remote[1]
AUTHORS
-------
Written by Linus Torvalds <torvalds@osdl.org>.
Man page by Jonas Fonseca <fonseca@diku.dk>.
GIT
---
Part of the gitlink:git[7] suite

58
Documentation/git-show.txt
View file

@ -3,38 +3,68 @@ git-show(1)
NAME
----
git-show - Show one commit with difference it introduces
git-show - Show various types of objects
SYNOPSIS
--------
'git-show' <option>...
'git-show' [options] <object>...
DESCRIPTION
-----------
Shows commit log and textual diff for a single commit. The
command internally invokes 'git-rev-list' piped to
'git-diff-tree', and takes command line options for both of
these commands. It also presents the merge commit in a special
format as produced by 'git-diff-tree --cc'.
Shows one or more objects (blobs, trees, tags and commits).
For commits it shows the log message and textual diff. It also
presents the merge commit in a special format as produced by
'git-diff-tree --cc'.
For tags, it shows the tag message and the referenced objects.
For trees, it shows the names (equivalent to gitlink:git-ls-tree[1]
with \--name-only).
For plain blobs, it shows the plain contents.
This manual page describes only the most frequently used options.
OPTIONS
-------
<commitid>::
ID of the commit to show.
<object>::
The name of the object to show.
--pretty=<format>::
Controls the output format for the commit logs.
<format> can be one of 'raw', 'medium', 'short', 'full',
and 'oneline'.
include::pretty-formats.txt[]
EXAMPLES
--------
git show v1.0.0::
Shows the tag `v1.0.0`, along with the object the tags
points at.
git show v1.0.0^{tree}::
Shows the tree pointed to by the tag `v1.0.0`.
git show next~10:Documentation/README
Shows the contents of the file `Documentation/README` as
they were current in the 10th last commit of the branch
`next`.
git show master:Makefile master:t/Makefile
Concatenates the contents of said Makefiles in the head
of the branch `master`.
Discussion
----------
include::i18n.txt[]
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and
Junio C Hamano <junkio@cox.net>
Junio C Hamano <junkio@cox.net>. Significantly enhanced by
Johannes Schindelin <Johannes.Schindelin@gmx.de>.
Documentation

496
Documentation/git-svn.txt
View file

@ -3,7 +3,7 @@ git-svn(1)
NAME
----
git-svn - bidirectional operation between a single Subversion branch and git
git-svn - bidirectional operation between Subversion and git
SYNOPSIS
--------
@ -11,49 +11,84 @@ SYNOPSIS
DESCRIPTION
-----------
git-svn is a simple conduit for changesets between a single Subversion
branch and git.
git-svn is a simple conduit for changesets between Subversion and git.
It is not to be confused with gitlink:git-svnimport[1], which is
read-only and geared towards tracking multiple branches.
git-svn is not to be confused with git-svnimport. The were designed
with very different goals in mind.
git-svn is designed for an individual developer who wants a
git-svn was originally designed for an individual developer who wants a
bidirectional flow of changesets between a single branch in Subversion
and an arbitrary number of branches in git. git-svnimport is designed
for read-only operation on repositories that match a particular layout
(albeit the recommended one by SVN developers).
and an arbitrary number of branches in git. Since its inception,
git-svn has gained the ability to track multiple branches in a manner
similar to git-svnimport; but it cannot (yet) automatically detect new
branches and tags like git-svnimport does.
For importing svn, git-svnimport is potentially more powerful when
operating on repositories organized under the recommended
trunk/branch/tags structure, and should be faster, too.
git-svn mostly ignores the very limited view of branching that
Subversion has. This allows git-svn to be much easier to use,
especially on repositories that are not organized in a manner that
git-svnimport is designed for.
git-svn is especially useful when it comes to tracking repositories
not organized in the way Subversion developers recommend (trunk,
branches, tags directories).
COMMANDS
--------
init::
--
'init'::
Creates an empty git repository with additional metadata
directories for git-svn. The Subversion URL must be specified
as a command-line argument.
as a command-line argument. Optionally, the target directory
to operate on can be specified as a second argument. Normally
this command initializes the current directory.
fetch::
Fetch unfetched revisions from the Subversion URL we are
tracking. refs/remotes/git-svn will be updated to the
latest revision.
'fetch'::
Note: You should never attempt to modify the remotes/git-svn
branch outside of git-svn. Instead, create a branch from
remotes/git-svn and work on that branch. Use the 'commit'
command (see below) to write git commits back to
remotes/git-svn.
Fetch unfetched revisions from the Subversion URL we are
tracking. refs/remotes/git-svn will be updated to the
latest revision.
See 'Additional Fetch Arguments' if you are interested in
manually joining branches on commit.
Note: You should never attempt to modify the remotes/git-svn
branch outside of git-svn. Instead, create a branch from
remotes/git-svn and work on that branch. Use the 'dcommit'
command (see below) to write git commits back to
remotes/git-svn.
commit::
See '<<fetch-args,Additional Fetch Arguments>>' if you are interested in
manually joining branches on commit.
'dcommit'::
Commit each diff from a specified head directly to the SVN
repository, and then rebase or reset (depending on whether or
not there is a diff between SVN and head). This will create
a revision in SVN for each commit in git.
It is recommended that you run git-svn fetch and rebase (not
pull or merge) your commits against the latest changes in the
SVN repository.
An optional command-line argument may be specified as an
alternative to HEAD.
This is advantageous over 'set-tree' (below) because it produces
cleaner, more linear history.
'log'::
This should make it easy to look up svn log messages when svn
users refer to -r/--revision numbers.
The following features from `svn log' are supported:
--revision=<n>[:<n>] - is supported, non-numeric args are not:
HEAD, NEXT, BASE, PREV, etc ...
-v/--verbose - it's not completely compatible with
the --verbose output in svn log, but
reasonably close.
--limit=<n> - is NOT the same as --max-count,
doesn't count merged/excluded commits
--incremental - supported
New features:
--show-commit - shows the git commit sha1, as well
--oneline - our version of --pretty=oneline
Any other arguments are passed directly to `git log'
'set-tree'::
You should consider using 'dcommit' instead of this command.
Commit specified commit or tree objects to SVN. This relies on
your imported fetch data being up-to-date. This makes
absolutely no attempts to do patching when committing to SVN, it
@ -61,9 +96,9 @@ commit::
commit. All merging is assumed to have taken place
independently of git-svn functions.
rebuild::
'rebuild'::
Not a part of daily usage, but this is a useful command if
you've just cloned a repository (using git-clone) that was
you've just cloned a repository (using gitlink:git-clone[1]) that was
tracked with git-svn. Unfortunately, git-clone does not clone
git-svn metadata and the svn working tree that git-svn uses for
its operations. This rebuilds the metadata so git-svn can
@ -71,176 +106,344 @@ rebuild::
specified at the command-line if the directory/repository you're
tracking has moved or changed protocols.
show-ignore::
'show-ignore'::
Recursively finds and lists the svn:ignore property on
directories. The output is suitable for appending to
the $GIT_DIR/info/exclude file.
'commit-diff'::
Commits the diff of two tree-ish arguments from the
command-line. This command is intended for interopability with
git-svnimport and does not rely on being inside an git-svn
init-ed repository. This command takes three arguments, (a) the
original tree to diff against, (b) the new tree result, (c) the
URL of the target Subversion repository. The final argument
(URL) may be omitted if you are working from a git-svn-aware
repository (that has been init-ed with git-svn).
The -r<revision> option is required for this.
'graft-branches'::
This command attempts to detect merges/branches from already
imported history. Techniques used currently include regexes,
file copies, and tree-matches). This command generates (or
modifies) the $GIT_DIR/info/grafts file. This command is
considered experimental, and inherently flawed because
merge-tracking in SVN is inherently flawed and inconsistent
across different repositories.
'multi-init'::
This command supports git-svnimport-like command-line syntax for
importing repositories that are layed out as recommended by the
SVN folks. This is a bit more tolerant than the git-svnimport
command-line syntax and doesn't require the user to figure out
where the repository URL ends and where the repository path
begins.
-T<trunk_subdir>::
--trunk=<trunk_subdir>::
-t<tags_subdir>::
--tags=<tags_subdir>::
-b<branches_subdir>::
--branches=<branches_subdir>::
These are the command-line options for multi-init. Each of
these flags can point to a relative repository path
(--tags=project/tags') or a full url
(--tags=https://foo.org/project/tags)
--prefix=<prefix>
This allows one to specify a prefix which is prepended to the
names of remotes. The prefix does not automatically include a
trailing slash, so be sure you include one in the argument if
that is what you want. This is useful if you wish to track
multiple projects that share a common repository.
'multi-fetch'::
This runs fetch on all known SVN branches we're tracking. This
will NOT discover new branches (unlike git-svnimport), so
multi-init will need to be re-run (it's idempotent).
--
OPTIONS
-------
--
--shared::
--template=<template_directory>::
Only used with the 'init' command.
These are passed directly to gitlink:git-init[1].
-r <ARG>::
--revision <ARG>::
Only used with the 'fetch' command.
Takes any valid -r<argument> svn would accept and passes it
directly to svn. -r<ARG1>:<ARG2> ranges and "{" DATE "}" syntax
is also supported. This is passed directly to svn, see svn
documentation for more details.
Only used with the 'fetch' command.
This can allow you to make partial mirrors when running fetch.
Takes any valid -r<argument> svn would accept and passes it
directly to svn. -r<ARG1>:<ARG2> ranges and "{" DATE "}" syntax
is also supported. This is passed directly to svn, see svn
documentation for more details.
This can allow you to make partial mirrors when running fetch.
-::
--stdin::
Only used with the 'commit' command.
Read a list of commits from stdin and commit them in reverse
order. Only the leading sha1 is read from each line, so
git-rev-list --pretty=oneline output can be used.
Only used with the 'set-tree' command.
Read a list of commits from stdin and commit them in reverse
order. Only the leading sha1 is read from each line, so
git-rev-list --pretty=oneline output can be used.
--rmdir::
Only used with the 'commit' command.
Remove directories from the SVN tree if there are no files left
behind. SVN can version empty directories, and they are not
removed by default if there are no files left in them. git
cannot version empty directories. Enabling this flag will make
the commit to SVN act like git.
Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
repo-config key: svn.rmdir
Remove directories from the SVN tree if there are no files left
behind. SVN can version empty directories, and they are not
removed by default if there are no files left in them. git
cannot version empty directories. Enabling this flag will make
the commit to SVN act like git.
repo-config key: svn.rmdir
-e::
--edit::
Only used with the 'commit' command.
Edit the commit message before committing to SVN. This is off by
default for objects that are commits, and forced on when committing
tree objects.
Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
repo-config key: svn.edit
Edit the commit message before committing to SVN. This is off by
default for objects that are commits, and forced on when committing
tree objects.
repo-config key: svn.edit
-l<num>::
--find-copies-harder::
Both of these are only used with the 'commit' command.
They are both passed directly to git-diff-tree see
git-diff-tree(1) for more information.
Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
repo-config key: svn.l
repo-config key: svn.findcopiesharder
They are both passed directly to git-diff-tree see
gitlink:git-diff-tree[1] for more information.
[verse]
repo-config key: svn.l
repo-config key: svn.findcopiesharder
-A<filename>::
--authors-file=<filename>::
Syntax is compatible with the files used by git-svnimport and
git-cvsimport:
Syntax is compatible with the files used by git-svnimport and
git-cvsimport:
------------------------------------------------------------------------
loginname = Joe User <user@example.com>
loginname = Joe User <user@example.com>
------------------------------------------------------------------------
If this option is specified and git-svn encounters an SVN
committer name that does not exist in the authors-file, git-svn
will abort operation. The user will then have to add the
appropriate entry. Re-running the previous git-svn command
after the authors-file is modified should continue operation.
If this option is specified and git-svn encounters an SVN
committer name that does not exist in the authors-file, git-svn
will abort operation. The user will then have to add the
appropriate entry. Re-running the previous git-svn command
after the authors-file is modified should continue operation.
repo-config key: svn.authors-file
repo-config key: svn.authorsfile
-q::
--quiet::
Make git-svn less verbose.
--repack[=<n>]::
--repack-flags=<flags>
These should help keep disk usage sane for large fetches
with many revisions.
--repack takes an optional argument for the number of revisions
to fetch before repacking. This defaults to repacking every
1000 commits fetched if no argument is specified.
--repack-flags are passed directly to gitlink:git-repack[1].
repo-config key: svn.repack
repo-config key: svn.repackflags
-m::
--merge::
-s<strategy>::
--strategy=<strategy>::
These are only used with the 'dcommit' command.
Passed directly to git-rebase when using 'dcommit' if a
'git-reset' cannot be used (see dcommit).
-n::
--dry-run::
This is only used with the 'dcommit' command.
Print out the series of git arguments that would show
which diffs would be committed to SVN.
--
ADVANCED OPTIONS
----------------
--
-b<refname>::
--branch <refname>::
Used with 'fetch' or 'commit'.
Used with 'fetch', 'dcommit' or 'set-tree'.
This can be used to join arbitrary git branches to remotes/git-svn
on new commits where the tree object is equivalent.
This can be used to join arbitrary git branches to remotes/git-svn
on new commits where the tree object is equivalent.
When used with different GIT_SVN_ID values, tags and branches in
SVN can be tracked this way, as can some merges where the heads
end up having completely equivalent content. This can even be
used to track branches across multiple SVN _repositories_.
When used with different GIT_SVN_ID values, tags and branches in
SVN can be tracked this way, as can some merges where the heads
end up having completely equivalent content. This can even be
used to track branches across multiple SVN _repositories_.
This option may be specified multiple times, once for each
branch.
This option may be specified multiple times, once for each
branch.
repo-config key: svn.branch
repo-config key: svn.branch
-i<GIT_SVN_ID>::
--id <GIT_SVN_ID>::
This sets GIT_SVN_ID (instead of using the environment). See
the section on "Tracking Multiple Repositories or Branches" for
more information on using GIT_SVN_ID.
This sets GIT_SVN_ID (instead of using the environment). See the
section on
'<<tracking-multiple-repos,Tracking Multiple Repositories or Branches>>'
for more information on using GIT_SVN_ID.
--follow-parent::
This is especially helpful when we're tracking a directory
that has been moved around within the repository, or if we
started tracking a branch and never tracked the trunk it was
descended from.
repo-config key: svn.followparent
--no-metadata::
This gets rid of the git-svn-id: lines at the end of every commit.
With this, you lose the ability to use the rebuild command. If
you ever lose your .git/svn/git-svn/.rev_db file, you won't be
able to fetch again, either. This is fine for one-shot imports.
The 'git-svn log' command will not work on repositories using this,
either.
repo-config key: svn.nometadata
--
COMPATIBILITY OPTIONS
---------------------
--
--upgrade::
Only used with the 'rebuild' command.
Only used with the 'rebuild' command.
Run this if you used an old version of git-svn that used
"git-svn-HEAD" instead of "remotes/git-svn" as the branch
for tracking the remote.
Run this if you used an old version of git-svn that used
"git-svn-HEAD" instead of "remotes/git-svn" as the branch
for tracking the remote.
--no-ignore-externals::
Only used with the 'fetch' and 'rebuild' command.
--ignore-nodate::
Only used with the 'fetch' command.
By default, git-svn passes --ignore-externals to svn to avoid
fetching svn:external trees into git. Pass this flag to enable
externals tracking directly via git.
By default git-svn will crash if it tries to import a revision
from SVN which has '(no date)' listed as the date of the revision.
This is repository corruption on SVN's part, plain and simple.
But sometimes you really need those revisions anyway.
Versions of svn that do not support --ignore-externals are
automatically detected and this flag will be automatically
enabled for them.
If supplied git-svn will convert '(no date)' entries to the UNIX
epoch (midnight on Jan. 1, 1970). Yes, that's probably very wrong.
SVN was very wrong.
Otherwise, do not enable this flag unless you know what you're
doing.
repo-config key: svn.noignoreexternals
--
Basic Examples
~~~~~~~~~~~~~~
Tracking and contributing to an Subversion managed-project:
Tracking and contributing to a the trunk of a Subversion-managed project:
------------------------------------------------------------------------
# Initialize a tree (like git init-db):
# Initialize a repo (like git init):
git-svn init http://svn.foo.org/project/trunk
# Fetch remote revisions:
git-svn fetch
# Create your own branch to hack on:
git checkout -b my-branch remotes/git-svn
# Commit only the git commits you want to SVN:
git-svn commit <tree-ish> [<tree-ish_2> ...]
# Commit all the git commits from my-branch that don't exist in SVN:
git-svn commit remotes/git-svn..my-branch
# Something is committed to SVN, pull the latest into your branch:
git-svn fetch && git pull . remotes/git-svn
# Do some work, and then commit your new changes to SVN, as well as
# automatically updating your working HEAD:
git-svn dcommit
# Something is committed to SVN, rebase the latest into your branch:
git-svn fetch && git rebase remotes/git-svn
# Append svn:ignore settings to the default git exclude file:
git-svn show-ignore >> .git/info/exclude
------------------------------------------------------------------------
Tracking and contributing to an entire Subversion-managed project
(complete with a trunk, tags and branches):
See also:
'<<tracking-multiple-repos,Tracking Multiple Repositories or Branches>>'
------------------------------------------------------------------------
# Initialize a repo (like git init):
git-svn multi-init http://svn.foo.org/project \
-T trunk -b branches -t tags
# Fetch remote revisions:
git-svn multi-fetch
# Create your own branch of trunk to hack on:
git checkout -b my-trunk remotes/trunk
# Do some work, and then commit your new changes to SVN, as well as
# automatically updating your working HEAD:
git-svn dcommit -i trunk
# Something has been committed to trunk, rebase the latest into your branch:
git-svn multi-fetch && git rebase remotes/trunk
# Append svn:ignore settings of trunk to the default git exclude file:
git-svn show-ignore -i trunk >> .git/info/exclude
# Check for new branches and tags (no arguments are needed):
git-svn multi-init
------------------------------------------------------------------------
REBASE VS. PULL/MERGE
---------------------
Originally, git-svn recommended that the remotes/git-svn branch be
pulled or merged from. This is because the author favored
'git-svn set-tree B' to commit a single head rather than the
'git-svn set-tree A..B' notation to commit multiple commits.
If you use 'git-svn set-tree A..B' to commit several diffs and you do
not have the latest remotes/git-svn merged into my-branch, you should
use 'git rebase' to update your work branch instead of 'git pull' or
'git merge'. 'pull/merge' can cause non-linear history to be flattened
when committing into SVN, which can lead to merge commits reversing
previous commits in SVN.
DESIGN PHILOSOPHY
-----------------
Merge tracking in Subversion is lacking and doing branched development
with Subversion is cumbersome as a result. git-svn completely forgoes
any automated merge/branch tracking on the Subversion side and leaves it
entirely up to the user on the git side. It's simply not worth it to do
a useful translation when the original signal is weak.
with Subversion is cumbersome as a result. git-svn does not do
automated merge/branch tracking by default and leaves it entirely up to
the user on the git side.
[[tracking-multiple-repos]]
TRACKING MULTIPLE REPOSITORIES OR BRANCHES
------------------------------------------
This is for advanced users, most users should ignore this section.
Because git-svn does not care about relationships between different
branches or directories in a Subversion repository, git-svn has a simple
hack to allow it to track an arbitrary number of related _or_ unrelated
SVN repositories via one git repository. Simply set the GIT_SVN_ID
environment variable to a name other other than "git-svn" (the default)
and git-svn will ignore the contents of the $GIT_DIR/git-svn directory
and instead do all of its work in $GIT_DIR/$GIT_SVN_ID for that
invocation. The interface branch will be remotes/$GIT_SVN_ID, instead of
remotes/git-svn. Any remotes/$GIT_SVN_ID branch should never be modified
by the user outside of git-svn commands.
SVN repositories via one git repository. Simply use the --id/-i flag or
set the GIT_SVN_ID environment variable to a name other other than
"git-svn" (the default) and git-svn will ignore the contents of the
$GIT_DIR/svn/git-svn directory and instead do all of its work in
$GIT_DIR/svn/$GIT_SVN_ID for that invocation. The interface branch will
be remotes/$GIT_SVN_ID, instead of remotes/git-svn. Any
remotes/$GIT_SVN_ID branch should never be modified by the user outside
of git-svn commands.
[[fetch-args]]
ADDITIONAL FETCH ARGUMENTS
--------------------------
This is for advanced users, most users should ignore this section.
@ -251,58 +454,33 @@ optionally be specified in the form of sha1 hex sums at the
command-line. Unfetched SVN revisions may also be tied to particular
git commits with the following syntax:
------------------------------------------------
svn_revision_number=git_commit_sha1
------------------------------------------------
This allows you to tie unfetched SVN revision 375 to your current HEAD::
This allows you to tie unfetched SVN revision 375 to your current HEAD:
`git-svn fetch 375=$(git-rev-parse HEAD)`
------------------------------------------------
git-svn fetch 375=$(git-rev-parse HEAD)
------------------------------------------------
Advanced Example: Tracking a Reorganized Repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you're tracking a directory that has moved, or otherwise been
branched or tagged off of another directory in the repository and you
care about the full history of the project, then you can read this
section.
care about the full history of the project, then you can use
the --follow-parent option.
This is how Yann Dirson tracked the trunk of the ufoai directory when
the /trunk directory of his repository was moved to /ufoai/trunk and
he needed to continue tracking /ufoai/trunk where /trunk left off.
------------------------------------------------------------------------
# This log message shows when the repository was reorganized:
r166 | ydirson | 2006-03-02 01:36:55 +0100 (Thu, 02 Mar 2006) | 1 line
Changed paths:
D /trunk
A /ufoai/trunk (from /trunk:165)
# First we start tracking the old revisions:
GIT_SVN_ID=git-oldsvn git-svn init \
https://svn.sourceforge.net/svnroot/ufoai/trunk
GIT_SVN_ID=git-oldsvn git-svn fetch -r1:165
# And now, we continue tracking the new revisions:
GIT_SVN_ID=git-newsvn git-svn init \
https://svn.sourceforge.net/svnroot/ufoai/ufoai/trunk
GIT_SVN_ID=git-newsvn git-svn fetch \
166=`git-rev-parse refs/remotes/git-oldsvn`
------------------------------------------------------------------------
------------------------------------------------
git-svn fetch --follow-parent
------------------------------------------------
BUGS
----
If somebody commits a conflicting changeset to SVN at a bad moment
(right before you commit) causing a conflict and your commit to fail,
your svn working tree ($GIT_DIR/git-svn/tree) may be dirtied. The
easiest thing to do is probably just to rm -rf $GIT_DIR/git-svn/tree and
run 'rebuild'.
We ignore all SVN properties except svn:executable. Too difficult to
map them since we rely heavily on git write-tree being _exactly_ the
same on both the SVN and git working trees and I prefer not to clutter
working trees with metadata files.
svn:keywords can't be ignored in Subversion (at least I don't know of
a way to ignore them).
Renamed and copied directories are not detected by git and hence not
tracked when committing to SVN. I do not plan on adding support for
this as it's quite difficult and time-consuming to get working for all
@ -310,6 +488,10 @@ the possible corner cases (git doesn't do it, either). Renamed and
copied files are fully supported if they're similar enough for git to
detect them.
SEE ALSO
--------
gitlink:git-rebase[1]
Author
------
Written by Eric Wong <normalperson@yhbt.net>.

21
Documentation/git-svnimport.txt
View file

@ -15,6 +15,7 @@ SYNOPSIS
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
[ -s start_chg ] [ -m ] [ -r ] [ -M regex ]
[ -I <ignorefile_name> ] [ -A <author_file> ]
[ -R <repack_each_revs>] [ -P <path_from_trunk> ]
<SVN_repository_URL> [ <path> ]
@ -103,9 +104,25 @@ repository without -A.
-l <max_rev>::
Specify a maximum revision number to pull.
+
Formerly, this option controlled how many revisions to pull,
due to SVN memory leaks. (These have been worked around.)
Formerly, this option controlled how many revisions to pull,
due to SVN memory leaks. (These have been worked around.)
-R <repack_each_revs>::
Specify how often git repository should be repacked.
+
The default value is 1000. git-svnimport will do import in chunks of 1000
revisions, after each chunk git repository will be repacked. To disable
this behavior specify some big value here which is mote than number of
revisions to import.
-P <path_from_trunk>::
Partial import of the SVN tree.
+
By default, the whole tree on the SVN trunk (/trunk) is imported.
'-P my/proj' will import starting only from '/trunk/my/proj'.
This option is useful when you want to import one project from a
svn repo which hosts multiple projects under the same trunk.
-v::
Verbosity: let 'svnimport' report what it is doing.

29
Documentation/git-symbolic-ref.txt
View file

@ -19,29 +19,22 @@ argument to see on which branch your working tree is on.
Give two arguments, create or update a symbolic ref <name> to
point at the given branch <ref>.
Traditionally, `.git/HEAD` is a symlink pointing at
`refs/heads/master`. When we want to switch to another branch,
we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we want
A symbolic ref is a regular file that stores a string that
begins with `ref: refs/`. For example, your `.git/HEAD` is
a regular file whose contents is `ref: refs/heads/master`.
NOTES
-----
In the past, `.git/HEAD` was a symbolic link pointing at
`refs/heads/master`. When we wanted to switch to another branch,
we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we wanted
to find out which branch we are on, we did `readlink .git/HEAD`.
This was fine, and internally that is what still happens by
default, but on platforms that do not have working symlinks,
or that do not have the `readlink(1)` command, this was a bit
cumbersome. On some platforms, `ln -sf` does not even work as
advertised (horrors).
A symbolic ref can be a regular file that stores a string that
begins with `ref: refs/`. For example, your `.git/HEAD` *can*
be a regular file whose contents is `ref: refs/heads/master`.
This can be used on a filesystem that does not support symbolic
links. Instead of doing `readlink .git/HEAD`, `git-symbolic-ref
HEAD` can be used to find out which branch we are on. To point
the HEAD to `newbranch`, instead of `ln -sf refs/heads/newbranch
.git/HEAD`, `git-symbolic-ref HEAD refs/heads/newbranch` can be
used.
Currently, .git/HEAD uses a regular file symbolic ref on Cygwin,
and everywhere else it is implemented as a symlink. This can be
changed at compilation time.
advertised (horrors). Therefore symbolic links are now deprecated
and symbolic refs are used by default.
Author
------

11
Documentation/git-tag.txt
View file

@ -9,7 +9,8 @@ git-tag - Create a tag object signed with GPG
SYNOPSIS
--------
[verse]
'git-tag' [-a | -s | -u <key-id>] [-f | -d] [-m <msg>] <name> [<head>]
'git-tag' [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg> | -F <file>]
<name> [<head>]
'git-tag' -l [<pattern>]
DESCRIPTION
@ -34,6 +35,8 @@ GnuPG key for signing.
`-d <tag>` deletes the tag.
`-v <tag>` verifies the gpg signature of the tag.
`-l <pattern>` lists tags that match the given pattern (or all
if no pattern is given).
@ -54,12 +57,18 @@ OPTIONS
-d::
Delete an existing tag with the given name
-v::
Verify the gpg signature of given the tag
-l <pattern>::
List tags that match the given pattern (or all if no pattern is given).
-m <msg>::
Use the given tag message (instead of prompting)
-F <file>::
Take the tag message from the given file. Use '-' to
read the message from the standard input.
Author
------

3
Documentation/git-tar-tree.txt
View file

@ -12,6 +12,9 @@ SYNOPSIS
DESCRIPTION
-----------
THIS COMMAND IS DEPRECATED. Use `git-archive` with `--format=tar`
option instead.
Creates a tar archive containing the tree structure for the named tree.
When <base> is specified it is added as a leading path to the files in the
generated tar archive.

8
Documentation/git-unpack-objects.txt
View file

@ -8,7 +8,7 @@ git-unpack-objects - Unpack objects from a packed archive
SYNOPSIS
--------
'git-unpack-objects' [-n] [-q] <pack-file
'git-unpack-objects' [-n] [-q] [-r] <pack-file
DESCRIPTION
@ -34,6 +34,12 @@ OPTIONS
The command usually shows percentage progress. This
flag suppresses it.
-r::
When unpacking a corrupt packfile, the command dies at
the first corruption. This flag tells it to keep going
and make the best effort to recover as many objects as
possible.
Author
------

8
Documentation/git-update-index.txt
View file

@ -15,7 +15,7 @@ SYNOPSIS
[--cacheinfo <mode> <object> <file>]\*
[--chmod=(+|-)x]
[--assume-unchanged | --no-assume-unchanged]
[--really-refresh] [--unresolve] [--again]
[--really-refresh] [--unresolve] [--again | -g]
[--info-only] [--index-info]
[-z] [--stdin]
[--verbose]
@ -80,7 +80,7 @@ OPTIONS
filesystem that has very slow lstat(2) system call
(e.g. cifs).
--again::
--again, -g::
Runs `git-update-index` itself on the paths whose index
entries are different from those from the `HEAD` commit.
@ -216,8 +216,8 @@ $ git ls-files -s
------------
Using "assume unchanged" bit
----------------------------
Using ``assume unchanged'' bit
------------------------------
Many operations in git depend on your filesystem to have an
efficient `lstat(2)` implementation, so that `st_mtime`

10
Documentation/git-update-ref.txt
View file

@ -7,7 +7,7 @@ git-update-ref - update the object name stored in a ref safely
SYNOPSIS
--------
'git-update-ref' [-m <reason>] <ref> <newvalue> [<oldvalue>]
'git-update-ref' [-m <reason>] (-d <ref> <oldvalue> | <ref> <newvalue> [<oldvalue>])
DESCRIPTION
-----------
@ -20,7 +20,9 @@ possibly dereferencing the symbolic refs, after verifying that
the current value of the <ref> matches <oldvalue>.
E.g. `git-update-ref refs/heads/master <newvalue> <oldvalue>`
updates the master branch head to <newvalue> only if its current
value is <oldvalue>.
value is <oldvalue>. You can specify 40 "0" or an empty string
as <oldvalue> to make sure that the ref you are creating does
not exist.
It also allows a "ref" file to be a symbolic pointer to another
ref file by starting with the four-byte header sequence of
@ -49,6 +51,10 @@ 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).
With `-d` flag, it deletes the named <ref> after verifying it
still contains <oldvalue>.
Logging Updates
---------------
If config parameter "core.logAllRefUpdates" is true or the file

37
Documentation/git-upload-archive.txt Normal file
View file

@ -0,0 +1,37 @@
git-upload-archive(1)
====================
NAME
----
git-upload-archive - Send archive
SYNOPSIS
--------
'git-upload-archive' <directory>
DESCRIPTION
-----------
Invoked by 'git-archive --remote' and sends a generated archive to the
other end over the git protocol.
This command is usually not invoked directly by the end user. The UI
for the protocol is on the 'git-archive' side, and the program pair
is meant to be used to get an archive from a remote repository.
OPTIONS
-------
<directory>::
The repository to get a tar archive from.
Author
------
Written by Franck Bui-Huu.
Documentation
--------------
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite

39
Documentation/git-upload-tar.txt
View file

@ -1,39 +0,0 @@
git-upload-tar(1)
=================
NAME
----
git-upload-tar - Send tar archive
SYNOPSIS
--------
'git-upload-tar' <directory>
DESCRIPTION
-----------
Invoked by 'git-tar-tree --remote' and sends a generated tar archive
to the other end over the git protocol.
This command is usually not invoked directly by the end user.
The UI for the protocol is on the 'git-tar-tree' side, and the
program pair is meant to be used to get a tar archive from a
remote repository.
OPTIONS
-------
<directory>::
The repository to get a tar archive from.
Author
------
Written by Junio C Hamano <junio@kernel.org>
Documentation
--------------
Documentation by Junio C Hamano.
GIT
---
Part of the gitlink:git[7] suite

440
Documentation/git.txt
View file

@ -8,8 +8,9 @@ git - the stupid content tracker
SYNOPSIS
--------
[verse]
'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate]
[--bare] [--git-dir=GIT_DIR] [--help] COMMAND [ARGS]
[--bare] [--git-dir=GIT_DIR] [--help] COMMAND [ARGS]
DESCRIPTION
-----------
@ -71,186 +72,6 @@ GIT COMMANDS
We divide git into high level ("porcelain") commands and low level
("plumbing") commands.
Low-level commands (plumbing)
-----------------------------
Although git includes its
own porcelain layer, its low-level commands are sufficient to support
development of alternative porcelains. Developers of such porcelains
might start by reading about gitlink:git-update-index[1] and
gitlink:git-read-tree[1].
We divide the low-level commands into commands that manipulate objects (in
the repository, index, and working tree), commands that interrogate and
compare objects, and commands that move objects and references between
repositories.
Manipulation commands
~~~~~~~~~~~~~~~~~~~~~
gitlink:git-apply[1]::
Reads a "diff -up1" or git generated patch file and
applies it to the working tree.
gitlink:git-checkout-index[1]::
Copy files from the index to the working tree.
gitlink:git-commit-tree[1]::
Creates a new commit object.
gitlink:git-hash-object[1]::
Computes the object ID from a file.
gitlink:git-index-pack[1]::
Build pack idx file for an existing packed archive.
gitlink:git-init-db[1]::
Creates an empty git object database, or reinitialize an
existing one.
gitlink:git-merge-index[1]::
Runs a merge for files needing merging.
gitlink:git-mktag[1]::
Creates a tag object.
gitlink:git-mktree[1]::
Build a tree-object from ls-tree formatted text.
gitlink:git-pack-objects[1]::
Creates a packed archive of objects.
gitlink:git-prune-packed[1]::
Remove extra objects that are already in pack files.
gitlink:git-read-tree[1]::
Reads tree information into the index.
gitlink:git-repo-config[1]::
Get and set options in .git/config.
gitlink:git-unpack-objects[1]::
Unpacks objects out of a packed archive.
gitlink:git-update-index[1]::
Registers files in the working tree to the index.
gitlink:git-write-tree[1]::
Creates a tree from the index.
Interrogation commands
~~~~~~~~~~~~~~~~~~~~~~
gitlink:git-cat-file[1]::
Provide content or type/size information for repository objects.
gitlink:git-describe[1]::
Show the most recent tag that is reachable from a commit.
gitlink:git-diff-index[1]::
Compares content and mode of blobs between the index and repository.
gitlink:git-diff-files[1]::
Compares files in the working tree and the index.
gitlink:git-diff-stages[1]::
Compares two "merge stages" in the index.
gitlink:git-diff-tree[1]::
Compares the content and mode of blobs found via two tree objects.
gitlink:git-fsck-objects[1]::
Verifies the connectivity and validity of the objects in the database.
gitlink:git-ls-files[1]::
Information about files in the index and the working tree.
gitlink:git-ls-tree[1]::
Displays a tree object in human readable form.
gitlink:git-merge-base[1]::
Finds as good common ancestors as possible for a merge.
gitlink:git-name-rev[1]::
Find symbolic names for given revs.
gitlink:git-pack-redundant[1]::
Find redundant pack files.
gitlink:git-rev-list[1]::
Lists commit objects in reverse chronological order.
gitlink:git-show-index[1]::
Displays contents of a pack idx file.
gitlink:git-tar-tree[1]::
Creates a tar archive of the files in the named tree object.
gitlink:git-unpack-file[1]::
Creates a temporary file with a blob's contents.
gitlink:git-var[1]::
Displays a git logical variable.
gitlink:git-verify-pack[1]::
Validates packed git archive files.
In general, the interrogate commands do not touch the files in
the working tree.
Synching repositories
~~~~~~~~~~~~~~~~~~~~~
gitlink:git-fetch-pack[1]::
Updates from a remote repository (engine for ssh and
local transport).
gitlink:git-http-fetch[1]::
Downloads a remote git repository via HTTP by walking
commit chain.
gitlink:git-local-fetch[1]::
Duplicates another git repository on a local system by
walking commit chain.
gitlink:git-peek-remote[1]::
Lists references on a remote repository using
upload-pack protocol (engine for ssh and local
transport).
gitlink:git-receive-pack[1]::
Invoked by 'git-send-pack' to receive what is pushed to it.
gitlink:git-send-pack[1]::
Pushes to a remote repository, intelligently.
gitlink:git-http-push[1]::
Push missing objects using HTTP/DAV.
gitlink:git-shell[1]::
Restricted shell for GIT-only SSH access.
gitlink:git-ssh-fetch[1]::
Pulls from a remote repository over ssh connection by
walking commit chain.
gitlink:git-ssh-upload[1]::
Helper "server-side" program used by git-ssh-fetch.
gitlink:git-update-server-info[1]::
Updates auxiliary information on a dumb server to help
clients discover references and packs on it.
gitlink:git-upload-pack[1]::
Invoked by 'git-fetch-pack' to push
what are asked for.
gitlink:git-upload-tar[1]::
Invoked by 'git-tar-tree --remote' to return the tar
archive the other end asked for.
High-level commands (porcelain)
-------------------------------
@ -269,6 +90,9 @@ gitlink:git-am[1]::
gitlink:git-applymbox[1]::
Apply patches from a mailbox, original version by Linus.
gitlink:git-archive[1]::
Creates an archive of files from a named tree.
gitlink:git-bisect[1]::
Find the change that introduced a bug by binary search.
@ -302,6 +126,9 @@ gitlink:git-format-patch[1]::
gitlink:git-grep[1]::
Print lines matching a pattern.
gitlink:gitk[1]::
The git repository browser.
gitlink:git-log[1]::
Shows commit logs.
@ -314,8 +141,11 @@ gitlink:git-merge[1]::
gitlink:git-mv[1]::
Move or rename a file, a directory, or a symlink.
gitlink:git-pack-refs[1]::
Pack heads and tags for efficient repository access.
gitlink:git-pull[1]::
Fetch from and merge with a remote repository.
Fetch from and merge with a remote repository or a local branch.
gitlink:git-push[1]::
Update remote refs along with associated objects.
@ -382,6 +212,9 @@ gitlink:git-cvsexportcommit[1]::
gitlink:git-cvsserver[1]::
A CVS server emulator for git.
gitlink:git-gc[1]::
Cleanup unnecessary files and optimize the local repository.
gitlink:git-lost-found[1]::
Recover lost refs that luckily have not yet been pruned.
@ -394,6 +227,9 @@ gitlink:git-prune[1]::
gitlink:git-quiltimport[1]::
Applies a quilt patchset onto the current branch.
gitlink:git-reflog[1]::
Manage reflog information.
gitlink:git-relink[1]::
Hardlink common objects in local repositories.
@ -422,7 +258,7 @@ gitlink:git-annotate[1]::
Annotate file lines with commit info.
gitlink:git-blame[1]::
Blame file lines on commits.
Find out where each line in a file came from.
gitlink:git-check-ref-format[1]::
Make sure ref name is well formed.
@ -472,6 +308,9 @@ gitlink:git-request-pull[1]::
gitlink:git-rev-parse[1]::
Pick out and massage parameters.
gitlink:git-runstatus[1]::
A helper for git-status and git-commit.
gitlink:git-send-email[1]::
Send patch e-mails out of "format-patch --mbox" output.
@ -482,11 +321,192 @@ gitlink:git-stripspace[1]::
Filter out empty lines.
Commands not yet documented
---------------------------
Low-level commands (plumbing)
-----------------------------
gitlink:gitk[1]::
The gitk repository browser.
Although git includes its
own porcelain layer, its low-level commands are sufficient to support
development of alternative porcelains. Developers of such porcelains
might start by reading about gitlink:git-update-index[1] and
gitlink:git-read-tree[1].
We divide the low-level commands into commands that manipulate objects (in
the repository, index, and working tree), commands that interrogate and
compare objects, and commands that move objects and references between
repositories.
Manipulation commands
~~~~~~~~~~~~~~~~~~~~~
gitlink:git-apply[1]::
Reads a "diff -up1" or git generated patch file and
applies it to the working tree.
gitlink:git-checkout-index[1]::
Copy files from the index to the working tree.
gitlink:git-commit-tree[1]::
Creates a new commit object.
gitlink:git-hash-object[1]::
Computes the object ID from a file.
gitlink:git-index-pack[1]::
Build pack idx file for an existing packed archive.
gitlink:git-init[1]::
Creates an empty git repository, or reinitialize an
existing one.
gitlink:git-merge-file[1]::
Runs a threeway merge.
gitlink:git-merge-index[1]::
Runs a merge for files needing merging.
gitlink:git-mktag[1]::
Creates a tag object.
gitlink:git-mktree[1]::
Build a tree-object from ls-tree formatted text.
gitlink:git-pack-objects[1]::
Creates a packed archive of objects.
gitlink:git-prune-packed[1]::
Remove extra objects that are already in pack files.
gitlink:git-read-tree[1]::
Reads tree information into the index.
gitlink:git-repo-config[1]::
Get and set options in .git/config.
gitlink:git-unpack-objects[1]::
Unpacks objects out of a packed archive.
gitlink:git-update-index[1]::
Registers files in the working tree to the index.
gitlink:git-write-tree[1]::
Creates a tree from the index.
Interrogation commands
~~~~~~~~~~~~~~~~~~~~~~
gitlink:git-cat-file[1]::
Provide content or type/size information for repository objects.
gitlink:git-describe[1]::
Show the most recent tag that is reachable from a commit.
gitlink:git-diff-index[1]::
Compares content and mode of blobs between the index and repository.
gitlink:git-diff-files[1]::
Compares files in the working tree and the index.
gitlink:git-diff-stages[1]::
Compares two "merge stages" in the index.
gitlink:git-diff-tree[1]::
Compares the content and mode of blobs found via two tree objects.
gitlink:git-for-each-ref[1]::
Output information on each ref.
gitlink:git-fsck-objects[1]::
Verifies the connectivity and validity of the objects in the database.
gitlink:git-ls-files[1]::
Information about files in the index and the working tree.
gitlink:git-ls-tree[1]::
Displays a tree object in human readable form.
gitlink:git-merge-base[1]::
Finds as good common ancestors as possible for a merge.
gitlink:git-name-rev[1]::
Find symbolic names for given revs.
gitlink:git-pack-redundant[1]::
Find redundant pack files.
gitlink:git-rev-list[1]::
Lists commit objects in reverse chronological order.
gitlink:git-show-index[1]::
Displays contents of a pack idx file.
gitlink:git-show-ref[1]::
List references in a local repository.
gitlink:git-tar-tree[1]::
Creates a tar archive of the files in the named tree object.
gitlink:git-unpack-file[1]::
Creates a temporary file with a blob's contents.
gitlink:git-var[1]::
Displays a git logical variable.
gitlink:git-verify-pack[1]::
Validates packed git archive files.
In general, the interrogate commands do not touch the files in
the working tree.
Synching repositories
~~~~~~~~~~~~~~~~~~~~~
gitlink:git-fetch-pack[1]::
Updates from a remote repository (engine for ssh and
local transport).
gitlink:git-http-fetch[1]::
Downloads a remote git repository via HTTP by walking
commit chain.
gitlink:git-local-fetch[1]::
Duplicates another git repository on a local system by
walking commit chain.
gitlink:git-peek-remote[1]::
Lists references on a remote repository using
upload-pack protocol (engine for ssh and local
transport).
gitlink:git-receive-pack[1]::
Invoked by 'git-send-pack' to receive what is pushed to it.
gitlink:git-send-pack[1]::
Pushes to a remote repository, intelligently.
gitlink:git-http-push[1]::
Push missing objects using HTTP/DAV.
gitlink:git-shell[1]::
Restricted shell for GIT-only SSH access.
gitlink:git-ssh-fetch[1]::
Pulls from a remote repository over ssh connection by
walking commit chain.
gitlink:git-ssh-upload[1]::
Helper "server-side" program used by git-ssh-fetch.
gitlink:git-update-server-info[1]::
Updates auxiliary information on a dumb server to help
clients discover references and packs on it.
gitlink:git-upload-archive[1]::
Invoked by 'git-archive' to send a generated archive.
gitlink:git-upload-pack[1]::
Invoked by 'git-fetch-pack' to push
what are asked for.
Configuration Mechanism
@ -563,6 +583,9 @@ HEAD::
a valid head 'name'
(i.e. the contents of `$GIT_DIR/refs/heads/<head>`).
For a more complete list of ways to spell object names, see
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
File/Directory Structure
------------------------
@ -625,11 +648,35 @@ git Commits
git Diffs
~~~~~~~~~
'GIT_DIFF_OPTS'::
Only valid setting is "--unified=??" or "-u??" to set the
number of context lines shown when a unified diff is created.
This takes precedence over any "-U" or "--unified" option
value passed on the git diff command line.
'GIT_EXTERNAL_DIFF'::
see the "generating patches" section in :
gitlink:git-diff-index[1];
gitlink:git-diff-files[1];
gitlink:git-diff-tree[1]
When the environment variable 'GIT_EXTERNAL_DIFF' is set, the
program named by it is called, instead of the diff invocation
described above. For a path that is added, removed, or modified,
'GIT_EXTERNAL_DIFF' is called with 7 parameters:
path old-file old-hex old-mode new-file new-hex new-mode
+
where:
<old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the
contents of <old|new>,
<old|new>-hex:: are the 40-hexdigit SHA1 hashes,
<old|new>-mode:: are the octal representation of the file modes.
+
The file parameters can point at the user's working file
(e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file`
when a new file is added), or a temporary file (e.g. `old-file` in the
index). 'GIT_EXTERNAL_DIFF' should not worry about unlinking the
temporary file --- it is removed when 'GIT_EXTERNAL_DIFF' exits.
+
For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1
parameter, <path>.
other
~~~~~
@ -637,9 +684,18 @@ other
This environment variable overrides `$PAGER`.
'GIT_TRACE'::
If this variable is set git will print `trace:` messages on
If this variable is set to "1", "2" or "true" (comparison
is case insensitive), git will print `trace:` messages on
stderr telling about alias expansion, built-in command
execution and external command execution.
If this variable is set to an integer value greater than 1
and lower than 10 (strictly) then git will interpret this
value as an open file descriptor and will try to write the
trace messages into this file descriptor.
Alternatively, if this variable is set to an absolute path
(starting with a '/' character), git will interpret this
as a file path and will try to write the trace messages
into it.
Discussion[[Discussion]]
------------------------

69
Documentation/gitk.txt
View file

@ -3,26 +3,56 @@ gitk(1)
NAME
----
gitk - Some git command not yet documented.
gitk - git repository browser
SYNOPSIS
--------
'gitk' [ --option ] <args>...
'gitk' [<option>...] [<revs>] [--] [<path>...]
DESCRIPTION
-----------
Does something not yet documented.
Displays changes in a repository or a selected set of commits. This includes
visualizing the commit graph, showing information related to each commit, and
the files in the trees of each revision.
Historically, gitk was the first repository browser. It's written in tcl/tk
and started off in a separate repository but was later merged into the main
git repository.
OPTIONS
-------
--option::
Some option not yet documented.
To control which revisions to shown, the command takes options applicable to
the gitlink:git-rev-list[1] command. This manual page describes only the most
frequently used options.
<args>...::
Some argument not yet documented.
-n <number>, --max-count=<number>::
Limits the number of commits to show.
--since=<date>::
Show commits more recent than a specific date.
--until=<date>::
Show commits older than a specific date.
--all::
Show all branches.
<revs>::
Limit the revisions to show. This can be either a single revision
meaning show from the given revision and back, or it can be a range in
the form "'<from>'..'<to>'" to show all revisions between '<from>' and
back to '<to>'. Note, more advanced revision selection can be applied.
<path>::
Limit commits to the ones touching files in the given paths. Note, to
avoid ambiguity wrt. revision names use "--" to separate the paths
from any preceeding options.
Examples
--------
@ -37,13 +67,32 @@ gitk --since="2 weeks ago" \-- gitk::
The "--" is necessary to avoid confusion with the *branch* named
'gitk'
gitk --max-count=100 --all -- Makefile::
Show at most 100 changes made to the file 'Makefile'. Instead of only
looking for changes in the current branch look in all branches.
See Also
--------
'qgit(1)'::
A repository browser written in C++ using Qt.
'gitview(1)'::
A repository browser written in Python using Gtk. It's based on
'bzrk(1)' and distributed in the contrib area of the git repository.
'tig(1)'::
A minimal repository browser and git tool output highlighter written
in C using Ncurses.
Author
------
Written by Paul Mackerras <paulus@samba.org>
Written by Paul Mackerras <paulus@samba.org>.
Documentation
--------------
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
Documentation by Junio C Hamano, Jonas Fonseca, and the git-list
<git@vger.kernel.org>.
GIT
---

27
Documentation/glossary.txt
View file

@ -179,7 +179,7 @@ object name::
character hexadecimal encoding of the hash of the object (possibly
followed by a white space).
object type:
object type::
One of the identifiers "commit","tree","tag" and "blob" describing
the type of an object.
@ -188,11 +188,12 @@ octopus::
predator.
origin::
The default upstream tracking branch. Most projects have at
The default upstream repository. Most projects have at
least one upstream project which they track. By default
'origin' is used for that purpose. New upstream updates
will be fetched into this branch; you should never commit
to it yourself.
will be fetched into remote tracking branches named
origin/name-of-upstream-branch, which you can see using
"git branch -r".
pack::
A set of objects which have been compressed into one file (to save
@ -234,8 +235,11 @@ push::
local head, the push fails.
reachable::
An object is reachable from a ref/commit/tree/tag, if there is a
chain leading from the latter to the former.
All of the ancestors of a given commit are said to be reachable from
that commit. More generally, one object is reachable from another if
we can reach the one from the other by a chain that follows tags to
whatever they tag, commits to their parents or trees, and trees to the
trees or blobs that they contain.
rebase::
To clean a branch by starting from the head of the main line of
@ -255,7 +259,7 @@ refspec::
means "grab the master branch head from the $URL and store
it as my origin branch head".
And `git push $URL refs/heads/master:refs/heads/to-upstream`
means "publish my master branch head as to-upstream master head
means "publish my master branch head as to-upstream branch
at $URL". See also gitlink:git-push[1]
repository::
@ -282,6 +286,13 @@ SCM::
SHA1::
Synonym for object name.
symref::
Symbolic reference: instead of containing the SHA1 id itself, it
is of the format 'ref: refs/some/thing' and when referenced, it
recursively dereferences to this reference. 'HEAD' is a prime
example of a symref. Symbolic references are manipulated with
the gitlink:git-symbolic-ref[1] command.
topic branch::
A regular git branch that is used by a developer to
identify a conceptual line of development. Since branches
@ -324,7 +335,7 @@ tag::
A tag is most typically used to mark a particular point in the
commit ancestry chain.
unmerged index:
unmerged index::
An index which contains unmerged index entries.
working tree::

58
Documentation/hooks.txt
View file

@ -3,10 +3,9 @@ Hooks used by git
Hooks are little scripts you can place in `$GIT_DIR/hooks`
directory to trigger action at certain points. When
`git-init-db` is run, a handful example hooks are copied in the
`git-init` is run, a handful example hooks are copied in the
`hooks` directory of the new repository, but by default they are
all disabled. To enable a hook, make it executable with `chmod
+x`.
all disabled. To enable a hook, make it executable with `chmod +x`.
This document describes the currently defined hooks.
@ -16,16 +15,16 @@ applypatch-msg
This hook is invoked by `git-applypatch` script, which is
typically invoked by `git-applymbox`. It takes a single
parameter, the name of the file that holds the proposed commit
log message. Exiting with non-zero status causes the
'git-applypatch' to abort before applying the patch.
log message. Exiting with non-zero status causes
`git-applypatch` to abort before applying the patch.
The hook is allowed to edit the message file in place, and can
be used to normalize the message into some project standard
format (if the project has one). It can also be used to refuse
the commit after inspecting the message file.
The default applypatch-msg hook, when enabled, runs the
commit-msg hook, if the latter is enabled.
The default 'applypatch-msg' hook, when enabled, runs the
'commit-msg' hook, if the latter is enabled.
pre-applypatch
--------------
@ -39,8 +38,8 @@ after application of the patch not committed.
It can be used to inspect the current working tree and refuse to
make a commit if it does not pass certain test.
The default pre-applypatch hook, when enabled, runs the
pre-commit hook, if the latter is enabled.
The default 'pre-applypatch' hook, when enabled, runs the
'pre-commit' hook, if the latter is enabled.
post-applypatch
---------------
@ -61,9 +60,9 @@ invoked before obtaining the proposed commit log message and
making a commit. Exiting with non-zero status from this script
causes the `git-commit` to abort.
The default pre-commit hook, when enabled, catches introduction
The default 'pre-commit' hook, when enabled, catches introduction
of lines with trailing whitespaces and aborts the commit when
a such line is found.
such a line is found.
commit-msg
----------
@ -79,8 +78,8 @@ be used to normalize the message into some project standard
format (if the project has one). It can also be used to refuse
the commit after inspecting the message file.
The default commit-msg hook, when enabled, detects duplicate
Signed-off-by: lines, and aborts the commit when one is found.
The default 'commit-msg' hook, when enabled, detects duplicate
"Signed-off-by" lines, and aborts the commit if one is found.
post-commit
-----------
@ -91,23 +90,24 @@ parameter, and is invoked after a commit is made.
This hook is meant primarily for notification, and cannot affect
the outcome of `git-commit`.
The default post-commit hook, when enabled, demonstrates how to
The default 'post-commit' hook, when enabled, demonstrates how to
send out a commit notification e-mail.
update
------
This hook is invoked by `git-receive-pack` on the remote repository,
which is happens when a `git push` is done on a local repository.
which happens when a `git push` is done on a local repository.
Just before updating the ref on the remote repository, the update hook
is invoked. Its exit status determines the success or failure of
the ref update.
The hook executes once for each ref to be updated, and takes
three parameters:
- the name of the ref being updated,
- the old object name stored in the ref,
- and the new objectname to be stored in the ref.
- the name of the ref being updated,
- the old object name stored in the ref,
- and the new objectname to be stored in the ref.
A zero exit from the update hook allows the ref to be updated.
Exiting with a non-zero status prevents `git-receive-pack`
@ -126,16 +126,16 @@ Another use suggested on the mailing list is to use this hook to
implement access control which is finer grained than the one
based on filesystem group.
The standard output of this hook is sent to /dev/null; if you
want to report something to the git-send-pack on the other end,
you can redirect your output to your stderr.
The standard output of this hook is sent to `stderr`, so if you
want to report something to the `git-send-pack` on the other end,
you can simply `echo` your messages.
post-update
-----------
This hook is invoked by `git-receive-pack` on the remote repository,
which is happens when a `git push` is done on a local repository.
which happens when a `git push` is done on a local repository.
It executes on the remote repository once after all the refs have
been updated.
@ -145,16 +145,16 @@ name of ref that was actually updated.
This hook is meant primarily for notification, and cannot affect
the outcome of `git-receive-pack`.
The post-update hook can tell what are the heads that were pushed,
The 'post-update' hook can tell what are the heads that were pushed,
but it does not know what their original and updated values are,
so it is a poor place to do log old..new.
The default post-update hook, when enabled, runs
When enabled, the default 'post-update' hook runs
`git-update-server-info` to keep the information used by dumb
transports (e.g., http) up-to-date. If you are publishing
a git repository that is accessible via http, you should
transports (e.g., HTTP) up-to-date. If you are publishing
a git repository that is accessible via HTTP, you should
probably enable this hook.
The standard output of this hook is sent to /dev/null; if you
want to report something to the git-send-pack on the other end,
you can redirect your output to your stderr.
The standard output of this hook is sent to `/dev/null`; if you
want to report something to the `git-send-pack` on the other end,
you can redirect your output to your `stderr`.

2
Documentation/howto/setup-git-server-over-http.txt
View file

@ -70,7 +70,7 @@ DocumentRoot /where/ever/httpd.conf" to find your root:
Initialize a bare repository
$ cd my-new-repo.git
$ git --bare init-db
$ git --bare init
Change the ownership to your web-server's credentials. Use "grep ^User

57
Documentation/i18n.txt Normal file
View file

@ -0,0 +1,57 @@
At the core level, git is character encoding agnostic.
- The pathnames recorded in the index and in the tree objects
are treated as uninterpreted sequences of non-NUL bytes.
What readdir(2) returns are what are recorded and compared
with the data git keeps track of, which in turn are expected
to be what lstat(2) and creat(2) accepts. There is no such
thing as pathname encoding translation.
- The contents of the blob objects are uninterpreted sequence
of bytes. There is no encoding translation at the core
level.
- The commit log messages are uninterpreted sequence of non-NUL
bytes.
Although we encourage that the commit log messages are encoded
in UTF-8, both the core and git Porcelain are designed not to
force UTF-8 on projects. If all participants of a particular
project find it more convenient to use legacy encodings, git
does not forbid it. However, there are a few things to keep in
mind.
. `git-commit-tree` (hence, `git-commit` which uses it) issues
an warning if the commit log message given to it does not look
like a valid UTF-8 string, unless you explicitly say your
project uses a legacy encoding. The way to say this is to
have core.commitencoding in `.git/config` file, like this:
+
------------
[core]
commitencoding = ISO-8859-1
------------
+
Commit objects created with the above setting record the value
of `core.commitencoding` in its `encoding` header. This is to
help other people who look at them later. Lack of this header
implies that the commit log message is encoded in UTF-8.
. `git-log`, `git-show` and friends looks at the `encoding`
header of a commit object, and tries to re-code the log
message into UTF-8 unless otherwise specified. You can
specify the desired output encoding with
`core.logoutputencoding` in `.git/config` file, like this:
+
------------
[core]
logoutputencoding = ISO-8859-1
------------
+
If you do not have this configuration variable, the value of
`core.commitencoding` is used instead.
Note that we deliberately chose not to re-code the commit log
message when a commit is made to force UTF-8 at the commit
object level, because re-coding to UTF-8 is not necessarily a
reversible operation.

31
Documentation/install-doc-quick.sh Executable file
View file

@ -0,0 +1,31 @@
#!/bin/sh
# This requires a branch named in $head
# (usually 'man' or 'html', provided by the git.git repository)
set -e
head="$1"
mandir="$2"
SUBDIRECTORY_OK=t
USAGE='<refname> <target directory>'
. git-sh-setup
export GIT_DIR
test -z "$mandir" && usage
if ! git-rev-parse --verify "$head^0" >/dev/null; then
echo >&2 "head: $head does not exist in the current repository"
usage
fi
GIT_INDEX_FILE=`pwd`/.quick-doc.index
export GIT_INDEX_FILE
rm -f "$GIT_INDEX_FILE"
git-read-tree $head
git-checkout-index -a -f --prefix="$mandir"/
if test -n "$GZ"; then
cd "$mandir"
for i in `git-ls-tree -r --name-only $head`
do
gzip < $i > $i.gz && rm $i
done
fi
rm -f "$GIT_INDEX_FILE"

85
Documentation/pretty-formats.txt Normal file
View file

@ -0,0 +1,85 @@
--pretty[='<format>']::
Pretty-prints the details of a commit. `--pretty`
without an explicit `=<format>` defaults to 'medium'.
If the commit is a merge, and if the pretty-format
is not 'oneline', 'email' or 'raw', an additional line is
inserted before the 'Author:' line. This line begins with
"Merge: " and the sha1s of ancestral commits are printed,
separated by spaces. Note that the listed commits may not
necessarily be the list of the *direct* parent commits if you
have limited your view of history: for example, if you are
only interested in changes related to a certain directory or
file. Here are some additional details for each format:
* 'oneline'
<sha1> <title line>
+
This is designed to be as compact as possible.
* 'short'
commit <sha1>
Author: <author>
<title line>
* 'medium'
commit <sha1>
Author: <author>
Date: <date>
<title line>
<full commit message>
* 'full'
commit <sha1>
Author: <author>
Commit: <committer>
<title line>
<full commit message>
* 'fuller'
commit <sha1>
Author: <author>
AuthorDate: <date & time>
Commit: <committer>
CommitDate: <date & time>
<title line>
<full commit message>
* 'email'
From <sha1> <date>
From: <author>
Date: <date & time>
Subject: [PATCH] <title line>
full commit message>
* 'raw'
+
The 'raw' format shows the entire commit exactly as
stored in the commit object. Notably, the SHA1s are
displayed in full, regardless of whether --abbrev or
--no-abbrev are used, and 'parents' information show the
true parent commits, without taking grafts nor history
simplification into account.
--encoding[=<encoding>]::
The commit objects record the encoding used for the log message
in their encoding header; this option can be used to tell the
command to re-code the commit log message in the encoding
preferred by the user. For non plumbing commands this
defaults to UTF-8.

4
Documentation/pull-fetch-param.txt
View file

@ -39,10 +39,6 @@ checkout -b my-B remote-B`). Run `git fetch` to keep track of
the progress of the remote side, and when you see something new
on the remote branch, merge it into your development branch with
`git pull . remote-B`, while you are on `my-B` branch.
The common `Pull: master:origin` mapping of a remote `master`
branch to a local `origin` branch, which is then merged to a
local development branch, again typically named `master`, is made
when you run `git clone` for you to follow this pattern.
+
[NOTE]
There is a difference between listing multiple <refspec>

33
Documentation/repository-layout.txt
View file

@ -52,9 +52,20 @@ objects/info/packs::
by default.
objects/info/alternates::
This file records absolute filesystem paths of alternate
object stores that this object store borrows objects
from, one pathname per line.
This file records paths to alternate object stores that
this object store borrows objects from, one pathname per
line. Note that not only native Git tools use it locally,
but the HTTP fetcher also tries to use it remotely; this
will usually work if you have relative paths (relative
to the object database, not to the repository!) in your
alternates file, but it will not work if you use absolute
paths unless the absolute path in filesystem and web URL
is the same. See also 'objects/info/http-alternates'.
objects/info/http-alternates::
This file records URLs to alternate object stores that
this object store borrows objects from, to be used when
the repository is fetched over HTTP.
refs::
References are stored in subdirectories of this
@ -70,12 +81,16 @@ refs/tags/`name`::
object, or a tag object that points at a commit object).
HEAD::
A symlink of the form `refs/heads/'name'` to point at
the current branch, if exists. It does not mean much if
the repository is not associated with any working tree
A symref (see glossary) to the `refs/heads/` namespace
describing the currently active branch. It does not mean
much if the repository is not associated with any working tree
(i.e. a 'bare' repository), but a valid git repository
*must* have such a symlink here. It is legal if the
named branch 'name' does not (yet) exist.
*must* have the HEAD file; some porcelains may use it to
guess the designated "default" branch of the repository
(usually 'master'). It is legal if the named branch
'name' does not (yet) exist. In some legacy setups, it is
a symbolic link instead of a symref that points at the current
branch.
branches::
A slightly deprecated way to store shorthands to be used
@ -87,7 +102,7 @@ branches::
hooks::
Hooks are customization scripts used by various git
commands. A handful of sample hooks are installed when
`git init-db` is run, but all of them are disabled by
`git init` is run, but all of them are disabled by
default. To enable, they need to be made executable.
Read link:hooks.html[hooks] for more details about
each hook.

38
Documentation/technical/racy-git.txt
View file

@ -4,7 +4,7 @@ Use of index and Racy git problem
Background
----------
The index is one of the most important data structure in git.
The index is one of the most important data structures in git.
It represents a virtual working tree state by recording list of
paths and their object names and serves as a staging area to
write out the next tree object to be committed. The state is
@ -16,7 +16,7 @@ virtual working tree state in the index and the files in the
working tree. The most obvious case is when the user asks `git
diff` (or its low level implementation, `git diff-files`) or
`git-ls-files --modified`. In addition, git internally checks
if the files in the working tree is different from what are
if the files in the working tree are different from what are
recorded in the index to avoid stomping on local changes in them
during patch application, switching branches, and merging.
@ -24,9 +24,9 @@ In order to speed up this comparison between the files in the
working tree and the index entries, the index entries record the
information obtained from the filesystem via `lstat(2)` system
call when they were last updated. When checking if they differ,
git first runs `lstat(2)` on the files and compare the result
git first runs `lstat(2)` on the files and compares the result
with this information (this is what was originally done by the
`ce_match_stat()` function, which the current code does in
`ce_match_stat()` function, but the current code does it in
`ce_match_stat_basic()` function). If some of these "cached
stat information" fields do not match, git can tell that the
files are modified without even looking at their contents.
@ -53,8 +53,9 @@ Racy git
There is one slight problem with the optimization based on the
cached stat information. Consider this sequence:
: modify 'foo'
$ git update-index 'foo'
: modify 'foo' in-place without changing its size
: modify 'foo' again, in-place, without changing its size
The first `update-index` computes the object name of the
contents of file `foo` and updates the index entry for `foo`
@ -62,7 +63,8 @@ along with the `struct stat` information. If the modification
that follows it happens very fast so that the file's `st_mtime`
timestamp does not change, after this sequence, the cached stat
information the index entry records still exactly match what you
can obtain from the filesystem, but the file `foo` is modified.
would see in the filesystem, even though the file `foo` is now
different.
This way, git can incorrectly think files in the working tree
are unmodified even though they actually are. This is called
the "racy git" problem (discovered by Pasky), and the entries
@ -87,7 +89,7 @@ the stat information from updated paths, `st_mtime` timestamp of
it is usually the same as or newer than any of the paths the
index contains. And no matter how quick the modification that
follows `git update-index foo` finishes, the resulting
`st_mtime` timestamp on `foo` cannot get the timestamp earlier
`st_mtime` timestamp on `foo` cannot get a value earlier
than the index file. Therefore, index entries that can be
racily clean are limited to the ones that have the same
timestamp as the index file itself.
@ -111,7 +113,7 @@ value, and falsely clean entry `foo` would not be caught by the
timestamp comparison check done with the former logic anymore.
The latter makes sure that the cached stat information for `foo`
would never match with the file in the working tree, so later
checks by `ce_match_stat_basic()` would report the index entry
checks by `ce_match_stat_basic()` would report that the index entry
does not match the file and git does not have to fall back on more
expensive `ce_modified_check_fs()`.
@ -155,17 +157,16 @@ of the cached stat information.
Avoiding runtime penalty
------------------------
In order to avoid the above runtime penalty, the recent "master"
branch (post 1.4.2) has a code that makes sure the index file
gets timestamp newer than the youngest files in the index when
In order to avoid the above runtime penalty, post 1.4.2 git used
to have a code that made sure the index file
got timestamp newer than the youngest files in the index when
there are many young files with the same timestamp as the
resulting index file would otherwise would have by waiting
before finishing writing the index file out.
I suspect that in practice the situation where many paths in the
index are all racily clean is quite rare. The only code paths
that can record recent timestamp for large number of paths I
know of are:
I suspected that in practice the situation where many paths in the
index are all racily clean was quite rare. The only code paths
that can record recent timestamp for large number of paths are:
. Initial `git add .` of a large project.
@ -188,6 +189,7 @@ youngest file in the working tree. This means that in these
cases there actually will not be any racily clean entry in
the resulting index.
So in summary I think we should not worry about avoiding the
runtime penalty and get rid of the "wait before finishing
writing" code out.
Based on this discussion, the current code does not use the
"workaround" to avoid the runtime penalty that does not exist in
practice anymore. This was done with commit 0fc82cff on Aug 15,
2006.

63
Documentation/technical/send-pack-pipeline.txt Normal file
View file

@ -0,0 +1,63 @@
git-send-pack
=============
Overall operation
-----------------
. Connects to the remote side and invokes git-receive-pack.
. Learns what refs the remote has and what commit they point at.
Matches them to the refspecs we are pushing.
. Checks if there are non-fast-forwards. Unlike fetch-pack,
the repository send-pack runs in is supposed to be a superset
of the recipient in fast-forward cases, so there is no need
for want/have exchanges, and fast-forward check can be done
locally. Tell the result to the other end.
. Calls pack_objects() which generates a packfile and sends it
over to the other end.
. If the remote side is new enough (v1.1.0 or later), wait for
the unpack and hook status from the other end.
. Exit with appropriate error codes.
Pack_objects pipeline
---------------------
This function gets one file descriptor (`fd`) which is either a
socket (over the network) or a pipe (local). What's written to
this fd goes to git-receive-pack to be unpacked.
send-pack ---> fd ---> receive-pack
The function pack_objects creates a pipe and then forks. The
forked child execs pack-objects with --revs to receive revision
parameters from its standard input. This process will write the
packfile to the other end.
send-pack
|
pack_objects() ---> fd ---> receive-pack
| ^ (pipe)
v |
(child)
The child dup2's to arrange its standard output to go back to
the other end, and read its standard input to come from the
pipe. After that it exec's pack-objects. On the other hand,
the parent process, before starting to feed the child pipeline,
closes the reading side of the pipe and fd to receive-pack.
send-pack
|
pack_objects(parent)
|
v [0]
pack-objects [0] ---> receive-pack
[jc: the pipeline was much more complex and needed documentation before
I understood an earlier bug, but now it is trivial and straightforward.]

46
Documentation/tutorial-2.txt
View file

@ -17,18 +17,19 @@ Let's start a new project and create a small amount of history:
------------------------------------------------
$ mkdir test-project
$ cd test-project
$ git init-db
defaulting to local storage area
$ git init
Initialized empty Git repository in .git/
$ echo 'hello world' > file.txt
$ git add .
$ git commit -a -m "initial commit"
Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe
Created initial commit 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
create mode 100644 file.txt
$ echo 'hello world!' >file.txt
$ git commit -a -m "add emphasis"
Created commit c4d59f390b9cfd4318117afde11d601c1085f241
------------------------------------------------
What are the 40 digits of hex that git responded to the first commit
with?
What are the 40 digits of hex that git responded to the commit with?
We saw in part one of the tutorial that commits have names like this.
It turns out that every object in the git history is stored under
@ -38,13 +39,25 @@ the same data twice (since identical data is given an identical SHA1
name), and that the contents of a git object will never change (since
that would change the object's name as well).
It is expected that the content of the commit object you created while
following the example above generates a different SHA1 hash than
the one shown above because the commit object records the time when
it was created and the name of the person performing the commit.
We can ask git about this particular object with the cat-file
command--just cut-and-paste from the reply to the initial commit, to
save yourself typing all 40 hex digits:
command. Don't copy the 40 hex digits from this example but use those
from your own version. Note that you can shorten it to only a few
characters to save yourself typing all 40 hex digits:
------------------------------------------------
$ git cat-file -t 92b8b694ffb1675e5975148e1121810081dbdffe
tree
$ git-cat-file -t 54196cc2
commit
$ git-cat-file commit 54196cc2
tree 92b8b694ffb1675e5975148e1121810081dbdffe
author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
initial commit
------------------------------------------------
A tree can refer to one or more "blob" objects, each corresponding to
@ -101,8 +114,7 @@ $ find .git/objects/
and the contents of these files is just the compressed data plus a
header identifying their length and their type. The type is either a
blob, a tree, a commit, or a tag. We've seen a blob and a tree now,
so next we should look at a commit.
blob, a tree, a commit, or a tag.
The simplest commit to find is the HEAD commit, which we can find
from .git/HEAD:
@ -341,23 +353,23 @@ situation:
------------------------------------------------
$ git status
#
# Updated but not checked in:
# Added but not yet committed:
# (will commit)
#
# new file: closing.txt
#
#
# Changed but not updated:
# (use git-update-index to mark for commit)
# Changed but not added:
# (use "git add file1 file2" to include for commit)
#
# modified: file.txt
#
------------------------------------------------
Since the current state of closing.txt is cached in the index file,
it is listed as "updated but not checked in". Since file.txt has
it is listed as "added but not yet committed". Since file.txt has
changes in the working directory that aren't reflected in the index,
it is marked "changed but not updated". At this point, running "git
it is marked "changed but not added". At this point, running "git
commit" would create a commit that added closing.txt (with its new
contents), but that didn't modify file.txt.
@ -368,7 +380,7 @@ in the index file is identical to the one in the working directory.
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 link:core-tutorial.txt[core tutorial] and the relevant man
See the link:core-tutorial.html[core tutorial] and the relevant man
pages for details.
What next?

182
Documentation/tutorial.txt
View file

@ -11,6 +11,18 @@ diff" with:
$ man git-diff
------------------------------------------------
It is a good idea to introduce yourself to git before doing any
operation. The easiest way to do so is:
------------------------------------------------
$ cat >~/.gitconfig <<\EOF
[user]
name = Your Name Comes Here
email = you@yourdomain.example.com
EOF
------------------------------------------------
Importing a new project
-----------------------
@ -20,18 +32,18 @@ can place it under git revision control as follows.
------------------------------------------------
$ tar xzf project.tar.gz
$ cd project
$ git init-db
$ git init
------------------------------------------------
Git will reply
------------------------------------------------
defaulting to local storage area
Initialized empty Git repository in .git/
------------------------------------------------
You've now initialized the working directory--you may notice a new
directory created, named ".git". Tell git that you want it to track
every file under the current directory with
every file under the current directory (note the '.') with:
------------------------------------------------
$ git add .
@ -40,42 +52,90 @@ $ git add .
Finally,
------------------------------------------------
$ git commit -a
$ git commit
------------------------------------------------
will prompt you for a commit message, then record the current state
of all the files to the repository.
Making changes
--------------
Try modifying some files, then run
------------------------------------------------
$ git diff
------------------------------------------------
to review your changes. When you're done,
to review your changes. When you're done, tell git that you
want the updated contents of these files in the commit and then
make a commit, like this:
------------------------------------------------
$ git add file1 file2 file3
$ git commit
------------------------------------------------
This will again prompt your for a message describing the change, and then
record the new versions of the files you listed.
Alternatively, instead of running `git add` beforehand, you can use
------------------------------------------------
$ git commit -a
------------------------------------------------
will again prompt your for a message describing the change, and then
record the new versions of the modified files.
which will automatically notice modified (but not new) files.
A note on commit messages: Though not required, it's a good idea to
begin the commit message with a single short (less than 50 character)
line summarizing the change, followed by a blank line and then a more
thorough description. Tools that turn commits into email, for
example, use the first line on the Subject line and the rest of the
example, use the first line on the Subject: line and the rest of the
commit in the body.
To add a new file, first create the file, then
------------------------------------------------
$ git add path/to/new/file
------------------------------------------------
Git tracks content not files
----------------------------
then commit as usual. No special command is required when removing a
file; just remove it, then commit.
With git you have to explicitly "add" all the changed _content_ you
want to commit together. This can be done in a few different ways:
1) By using 'git add <file_spec>...'
This can be performed multiple times before a commit. Note that this
is not only for adding new files. Even modified files must be
added to the set of changes about to be committed. The "git status"
command gives you a summary of what is included so far for the
next commit. When done you should use the 'git commit' command to
make it real.
Note: don't forget to 'add' a file again if you modified it after the
first 'add' and before 'commit'. Otherwise only the previous added
state of that file will be committed. This is because git tracks
content, so what you're really 'add'ing to the commit is the *content*
of the file in the state it is in when you 'add' it.
2) By using 'git commit -a' directly
This is a quick way to automatically 'add' the content from all files
that were modified since the previous commit, and perform the actual
commit without having to separately 'add' them beforehand. This will
not add content from new files i.e. files that were never added before.
Those files still have to be added explicitly before performing a
commit.
But here's a twist. If you do 'git commit <file1> <file2> ...' then only
the changes belonging to those explicitly specified files will be
committed, entirely bypassing the current "added" changes. Those "added"
changes will still remain available for a subsequent commit though.
However, for normal usage you only have to remember 'git add' + 'git commit'
and/or 'git commit -a'.
Viewing the changelog
---------------------
At any point you can view the history of your changes using
@ -89,6 +149,13 @@ If you also want to see complete diffs at each step, use
$ git log -p
------------------------------------------------
Often the overview of the change is useful to get a feel of
each step
------------------------------------------------
$ git log --stat --summary
------------------------------------------------
Managing branches
-----------------
@ -141,7 +208,7 @@ $ git commit -a
------------------------------------------------
at this point the two branches have diverged, with different changes
made in each. To merge the changes made in the two branches, run
made in each. To merge the changes made in experimental into master, run
------------------------------------------------
$ git pull . experimental
@ -169,6 +236,15 @@ $ gitk
will show a nice graphical representation of the resulting history.
At this point you could delete the experimental branch with
------------------------------------------------
$ git branch -d experimental
------------------------------------------------
This command ensures that the changes in the experimental branch are
already in the current branch.
If you develop on a branch crazy-idea, then regret it, you can always
delete the branch with
@ -209,29 +285,28 @@ at /home/bob/myrepo. She does this with:
------------------------------------------------
$ cd /home/alice/project
$ git pull /home/bob/myrepo
$ git pull /home/bob/myrepo master
------------------------------------------------
This actually pulls changes from the branch in Bob's repository named
"master". Alice could request a different branch by adding the name
of the branch to the end of the git pull command line.
This merges the changes from Bob's "master" branch into Alice's
current branch. If Alice has made her own changes in the meantime,
then she may need to manually fix any conflicts. (Note that the
"master" argument in the above command is actually unnecessary, as it
is the default.)
This merges Bob's changes into her repository; "git log" will
now show the new commits. If Alice has made her own changes in the
meantime, then Bob's changes will be merged in, and she will need to
manually fix any conflicts.
The "pull" command thus performs two operations: it fetches changes
from a remote branch, then merges them into the current branch.
A more cautious Alice might wish to examine Bob's changes before
pulling them. She can do this by creating a temporary branch just
for the purpose of studying Bob's changes:
You can perform the first operation alone using the "git fetch"
command. For example, Alice could create a temporary branch just to
track Bob's changes, without merging them with her own, using:
-------------------------------------
$ git fetch /home/bob/myrepo master:bob-incoming
-------------------------------------
which fetches the changes from Bob's master branch into a new branch
named bob-incoming. (Unlike git pull, git fetch just fetches a copy
of Bob's line of development without doing any merging). Then
named bob-incoming. Then
-------------------------------------
$ git log -p master..bob-incoming
@ -240,8 +315,8 @@ $ git log -p master..bob-incoming
shows a list of all the changes that Bob made since he branched from
Alice's master branch.
After examining those changes, and possibly fixing things, Alice can
pull the changes into her master branch:
After examining those changes, and possibly fixing things, Alice
could pull the changes into her master branch:
-------------------------------------
$ git checkout master
@ -251,6 +326,18 @@ $ git pull . bob-incoming
The last command is a pull from the "bob-incoming" branch in Alice's
own repository.
Alice could also perform both steps at once with:
-------------------------------------
$ git pull /home/bob/myrepo master:bob-incoming
-------------------------------------
This is just like the "git pull /home/bob/myrepo master" that we saw
before, except that it also stores the unmerged changes from bob's
master branch in bob-incoming before merging them into Alice's
current branch. Note that git pull always merges into the current
branch, regardless of what else is given on the commandline.
Later, Bob can update his repo with Alice's latest changes using
-------------------------------------
@ -259,20 +346,25 @@ $ git pull
Note that he doesn't need to give the path to Alice's repository;
when Bob cloned Alice's repository, git stored the location of her
repository in the file .git/remotes/origin, and that location is used
as the default for pulls.
Bob may also notice a branch in his repository that he didn't create:
repository in the repository configuration, and that location is
used for pulls:
-------------------------------------
$ git branch
* master
origin
$ git repo-config --get remote.origin.url
/home/bob/myrepo
-------------------------------------
The "origin" branch, which was created automatically by "git clone",
is a pristine copy of Alice's master branch; Bob should never commit
to it.
(The complete configuration created by git-clone is visible using
"git repo-config -l", and the gitlink:git-repo-config[1] man page
explains the meaning of each option.)
Git also keeps a pristine copy of Alice's master branch under the
name "origin/master":
-------------------------------------
$ git branch -r
origin/master
-------------------------------------
If Bob later decides to work from a different host, he can still
perform clones and pulls using the ssh protocol:
@ -312,7 +404,7 @@ commit.
$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
-------------------------------------
But there other ways to refer to commits. You can use any initial
But there are other ways to refer to commits. You can use any initial
part of the name that is long enough to uniquely identify the commit:
-------------------------------------
@ -322,8 +414,8 @@ $ git show HEAD # the tip of the current branch
$ git show experimental # the tip of the "experimental" branch
-------------------------------------
Every commit has at least one "parent" commit, which points to the
previous state of the project:
Every commit usually has one "parent" commit
which points to the previous state of the project:
-------------------------------------
$ git show HEAD^ # to see the parent of HEAD
@ -441,10 +533,10 @@ of the file:
$ git diff v2.5:Makefile HEAD:Makefile.in
-------------------------------------
You can also use "git cat-file -p" to see any such file:
You can also use "git show" to see any such file:
-------------------------------------
$ git cat-file -p v2.5:Makefile
$ git show v2.5:Makefile
-------------------------------------
Next Steps

19
Documentation/urls.txt
View file

@ -40,10 +40,13 @@ In addition to the above, as a short-hand, the name of a
file in `$GIT_DIR/remotes` directory can be given; the
named file should be in the following format:
------------
URL: one of the above URL format
Push: <refspec>
Pull: <refspec>
------------
Then such a short-hand is specified in place of
<repository> without <refspec> parameters on the command
line, <refspec> specified on `Push:` lines or `Pull:`
@ -51,6 +54,17 @@ lines are used for `git-push` and `git-fetch`/`git-pull`,
respectively. Multiple `Push:` and `Pull:` lines may
be specified for additional branch mappings.
Or, equivalently, in the `$GIT_DIR/config` (note the use
of `fetch` instead of `Pull:`):
------------
[remote "<remote>"]
url = <url>
push = <refspec>
fetch = <refspec>
------------
The name of a file in `$GIT_DIR/branches` directory can be
specified as an older notation short-hand; the named
file should contain a single line, a URL in one of the
@ -60,10 +74,15 @@ name of remote head (URL fragment notation).
without the fragment is equivalent to have this in the
corresponding file in the `$GIT_DIR/remotes/` directory.
------------
URL: <url>
Pull: refs/heads/master:<remote>
------------
while having `<url>#<head>` is equivalent to
------------
URL: <url>
Pull: refs/heads/<head>:<remote>
------------

2
GIT-VERSION-GEN
View file

@ -1,7 +1,7 @@
#!/bin/sh
GVF=GIT-VERSION-FILE
DEF_VER=v1.4.2.GIT
DEF_VER=v1.5.0-rc1.GIT
LF='
'

37
INSTALL
View file

@ -38,6 +38,19 @@ Issues of note:
has been actively developed since 1997, and people have moved over to
graphical file managers.
- You can use git after building but without installing if you
wanted to. Various git commands need to find other git
commands and scripts to do their work, so you would need to
arrange a few environment variables to tell them that their
friends will be found in your built source area instead of at
their standard installation area. Something like this works
for me:
GIT_EXEC_PATH=`pwd`
PATH=`pwd`:$PATH
GITPERLLIB=`pwd`/perl/blib/lib
export GIT_EXEC_PATH PATH GITPERLLIB
- Git is reasonably self-sufficient, but does depend on a few external
programs and libraries:
@ -59,25 +72,6 @@ Issues of note:
- expat library; git-http-push uses it for remote lock
management over DAV. Similar to "curl" above, this is optional.
- "GNU diff" to generate patches. Of course, you don't _have_ to
generate patches if you don't want to, but let's face it, you'll
be wanting to. Or why did you get git in the first place?
Non-GNU versions of the diff/patch programs don't generally support
the unified patch format (which is the one git uses), so you
really do want to get the GNU one. Trust me, you will want to
do that even if it wasn't for git. There's no point in living
in the dark ages any more.
- "merge", the standard UNIX three-way merge program. It usually
comes with the "rcs" package on most Linux distributions, so if
you have a developer install you probably have it already, but a
"graphical user desktop" install might have left it out.
You'll only need the merge program if you do development using
git, and if you only use git to track other peoples work you'll
never notice the lack of it.
- "wish", the Tcl/Tk windowing shell is used in gitk to show the
history graphically
@ -86,9 +80,6 @@ Issues of note:
- "perl" and POSIX-compliant shells are needed to use most of
the barebone Porcelainish scripts.
- "python" 2.3 or more recent; if you have 2.3, you may need
to build with "make WITH_OWN_SUBPROCESS_PY=YesPlease".
- Some platform specific issues are dealt with Makefile rules,
but depending on your specific installation, you may not
have all the libraries/tools needed, or you may have
@ -104,7 +95,7 @@ Issues of note:
repository itself. For example, you could:
$ mkdir manual && cd manual
$ git init-db
$ git init
$ git fetch-pack git://git.kernel.org/pub/scm/git/git.git man html |
while read a b
do

353
Makefile
View file

@ -1,11 +1,6 @@
# The default target of this Makefile is...
all:
all::
# Define MOZILLA_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine coming from Mozilla. It is GPL'd and should be fast
# on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default
# choice) has very fast version optimized for i586.
#
# Define NO_OPENSSL environment variable if you do not have OpenSSL.
# This also implies MOZILLA_SHA1.
#
@ -60,6 +55,11 @@ all:
# Define ARM_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for ARM.
#
# Define MOZILLA_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine coming from Mozilla. It is GPL'd and should be fast
# on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default
# choice) has very fast version optimized for i586.
#
# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
#
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
@ -69,7 +69,14 @@ all:
#
# Define NO_MMAP if you want to avoid mmap.
#
# Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3.
# Define NO_PREAD if you have a problem with pread() system call (e.g.
# cygwin.dll before v1.5.22).
#
# Define NO_FAST_WORKING_DIRECTORY if accessing objects in pack files is
# generally faster on your platform than accessing the working directory.
#
# Define NO_TRUSTABLE_FILEMODE if your filesystem may claim to support
# the executable mode bit, but doesn't really do so.
#
# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
#
@ -78,23 +85,22 @@ all:
#
# Define NO_ICONV if your libc does not properly support iconv.
#
# Define NO_ACCURATE_DIFF if your diff program at least sometimes misses
# a missing newline at the end of the file.
# Define NO_R_TO_GCC if your gcc does not like "-R/path/lib" that
# tells runtime paths to dynamic libraries; "-Wl,-rpath=/path/lib"
# is used instead.
#
# Define NO_PYTHON if you want to lose all benefits of the recursive merge.
#
# Define COLLISION_CHECK below if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# sufficient guarantee that no collisions between objects will ever happen.
# Define USE_NSEC below if you want git to care about sub-second file mtimes
# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
# randomly break unless your underlying filesystem supports those sub-second
# times (my ext3 doesn't).
#
# Define USE_STDEV below if you want git to care about the underlying device
# change being considered an inode change from the update-cache perspective.
#
# Define NO_PERL_MAKEMAKER if you cannot use Makefiles generated by perl's
# MakeMaker (e.g. using ActiveState under Cygwin).
#
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@ -118,7 +124,6 @@ prefix = $(HOME)
bindir = $(prefix)/bin
gitexecdir = $(bindir)
template_dir = $(prefix)/share/git-core/templates/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
# DESTDIR=
# default configuration for gitweb
@ -126,13 +131,18 @@ GITWEB_CONFIG = gitweb_config.perl
GITWEB_HOME_LINK_STR = projects
GITWEB_SITENAME =
GITWEB_PROJECTROOT = /pub/git
GITWEB_EXPORT_OK =
GITWEB_STRICT_EXPORT =
GITWEB_BASE_URL =
GITWEB_LIST =
GITWEB_HOMETEXT = indextext.html
GITWEB_CSS = gitweb.css
GITWEB_LOGO = git-logo.png
GITWEB_FAVICON = git-favicon.png
GITWEB_SITE_HEADER =
GITWEB_SITE_FOOTER =
export prefix bindir gitexecdir template_dir GIT_PYTHON_DIR
export prefix bindir gitexecdir template_dir
CC = gcc
AR = ar
@ -148,10 +158,16 @@ SPARSE_FLAGS = -D__BIG_ENDIAN__ -D__powerpc__
### --- END CONFIGURATION SECTION ---
# Those must not be GNU-specific; they are shared with perl/ which may
# be built by a different compiler. (Note that this is an artifact now
# but it still might be nice to keep that distinction.)
BASIC_CFLAGS =
BASIC_LDFLAGS =
SCRIPT_SH = \
git-bisect.sh git-branch.sh git-checkout.sh \
git-cherry.sh git-clean.sh git-clone.sh git-commit.sh \
git-fetch.sh \
git-bisect.sh git-checkout.sh \
git-clean.sh git-clone.sh git-commit.sh \
git-fetch.sh git-gc.sh \
git-ls-remote.sh \
git-merge-one-file.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh \
@ -164,30 +180,23 @@ SCRIPT_SH = \
git-lost-found.sh git-quiltimport.sh
SCRIPT_PERL = \
git-add--interactive.perl \
git-archimport.perl git-cvsimport.perl git-relink.perl \
git-shortlog.perl git-rerere.perl \
git-annotate.perl git-cvsserver.perl \
git-cvsserver.perl git-remote.perl \
git-svnimport.perl git-cvsexportcommit.perl \
git-send-email.perl git-svn.perl
SCRIPT_PYTHON = \
git-merge-recursive.py
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
git-cherry-pick git-status git-instaweb
# The ones that do not have to link with lcrypto, lz nor xdiff.
SIMPLE_PROGRAMS = \
git-daemon$X
# ... and all the rest that could be moved out of bindir to gitexecdir
PROGRAMS = \
git-convert-objects$X git-fetch-pack$X git-fsck-objects$X \
git-hash-object$X git-index-pack$X git-local-fetch$X \
git-fast-import$X \
git-merge-base$X \
git-daemon$X \
git-merge-index$X git-mktag$X git-mktree$X git-patch-id$X \
git-peek-remote$X git-receive-pack$X \
git-send-pack$X git-shell$X \
@ -196,19 +205,21 @@ PROGRAMS = \
git-update-server-info$X \
git-upload-pack$X git-verify-pack$X \
git-pack-redundant$X git-var$X \
git-describe$X git-merge-tree$X git-blame$X git-imap-send$X \
git-merge-tree$X git-imap-send$X \
git-merge-recursive$X \
$(EXTRA_PROGRAMS)
# Empty...
EXTRA_PROGRAMS =
BUILT_INS = \
git-format-patch$X git-show$X git-whatchanged$X \
git-get-tar-commit-id$X \
git-format-patch$X git-show$X git-whatchanged$X git-cherry$X \
git-get-tar-commit-id$X git-init$X \
$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS) \
git-merge-recur$X
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
@ -220,21 +231,18 @@ endif
ifndef PERL_PATH
PERL_PATH = /usr/bin/perl
endif
ifndef PYTHON_PATH
PYTHON_PATH = /usr/bin/python
endif
PYMODULES = \
gitMergeCommon.py
export PERL_PATH
LIB_FILE=libgit.a
XDIFF_LIB=xdiff/lib.a
LIB_H = \
blob.h cache.h commit.h csum-file.h delta.h \
diff.h object.h pack.h pkt-line.h quote.h refs.h \
archive.h blob.h cache.h commit.h csum-file.h delta.h grep.h \
diff.h object.h pack.h pkt-line.h quote.h refs.h list-objects.h sideband.h \
run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h
tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
utf8.h
DIFF_OBJS = \
diff.o diff-lib.o diffcore-break.o diffcore-order.o \
@ -243,29 +251,39 @@ DIFF_OBJS = \
LIB_OBJS = \
blob.o commit.o connect.o csum-file.o cache-tree.o base85.o \
date.o diff-delta.o entry.o exec_cmd.o ident.o lockfile.o \
object.o pack-check.o patch-delta.o path.o pkt-line.o \
date.o diff-delta.o entry.o exec_cmd.o ident.o \
interpolate.o \
lockfile.o \
object.o pack-check.o patch-delta.o path.o pkt-line.o sideband.o \
reachable.o \
quote.o read-cache.o refs.o run-command.o dir.o object-refs.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
fetch-clone.o revision.o pager.o tree-walk.o xdiff-interface.o \
write_or_die.o \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS)
revision.o pager.o tree-walk.o xdiff-interface.o \
write_or_die.o trace.o list-objects.o grep.o \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
color.o wt-status.o archive-zip.o archive-tar.o shallow.o utf8.o
BUILTIN_OBJS = \
builtin-add.o \
builtin-annotate.o \
builtin-apply.o \
builtin-archive.o \
builtin-blame.o \
builtin-branch.o \
builtin-cat-file.o \
builtin-checkout-index.o \
builtin-check-ref-format.o \
builtin-commit-tree.o \
builtin-count-objects.o \
builtin-describe.o \
builtin-diff.o \
builtin-diff-files.o \
builtin-diff-index.o \
builtin-diff-stages.o \
builtin-diff-tree.o \
builtin-fmt-merge-msg.o \
builtin-for-each-ref.o \
builtin-grep.o \
builtin-init-db.o \
builtin-log.o \
@ -273,6 +291,7 @@ BUILTIN_OBJS = \
builtin-ls-tree.o \
builtin-mailinfo.o \
builtin-mailsplit.o \
builtin-merge-file.o \
builtin-mv.o \
builtin-name-rev.o \
builtin-pack-objects.o \
@ -280,10 +299,14 @@ BUILTIN_OBJS = \
builtin-prune-packed.o \
builtin-push.o \
builtin-read-tree.o \
builtin-reflog.o \
builtin-repo-config.o \
builtin-rerere.o \
builtin-rev-list.o \
builtin-rev-parse.o \
builtin-rm.o \
builtin-runstatus.o \
builtin-shortlog.o \
builtin-show-branch.o \
builtin-stripspace.o \
builtin-symbolic-ref.o \
@ -291,12 +314,14 @@ BUILTIN_OBJS = \
builtin-unpack-objects.o \
builtin-update-index.o \
builtin-update-ref.o \
builtin-upload-tar.o \
builtin-upload-archive.o \
builtin-verify-pack.o \
builtin-write-tree.o
builtin-write-tree.o \
builtin-show-ref.o \
builtin-pack-refs.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
EXTLIBS = -lz
#
# Platform specific tweaks
@ -316,18 +341,6 @@ ifeq ($(uname_S),Darwin)
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
NO_STRLCPY = YesPlease
ifndef NO_FINK
ifeq ($(shell test -d /sw/lib && echo y),y)
ALL_CFLAGS += -I/sw/include
ALL_LDFLAGS += -L/sw/lib
endif
endif
ifndef NO_DARWIN_PORTS
ifeq ($(shell test -d /opt/local/lib && echo y),y)
ALL_CFLAGS += -I/opt/local/include
ALL_LDFLAGS += -L/opt/local/lib
endif
endif
endif
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
@ -347,7 +360,7 @@ ifeq ($(uname_S),SunOS)
endif
INSTALL = ginstall
TAR = gtar
ALL_CFLAGS += -D__EXTENSIONS__
BASIC_CFLAGS += -D__EXTENSIONS__
endif
ifeq ($(uname_O),Cygwin)
NO_D_TYPE_IN_DIRENT = YesPlease
@ -356,30 +369,33 @@ ifeq ($(uname_O),Cygwin)
NO_SYMLINK_HEAD = YesPlease
NEEDS_LIBICONV = YesPlease
NO_C99_FORMAT = YesPlease
NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes
NO_TRUSTABLE_FILEMODE = UnfortunatelyYes
# There are conflicting reports about this.
# On some boxes NO_MMAP is needed, and not so elsewhere.
# Try uncommenting this if you see things break -- YMMV.
# NO_MMAP = YesPlease
# Try commenting this out if you suspect MMAP is more efficient
NO_MMAP = YesPlease
NO_IPV6 = YesPlease
X = .exe
endif
ifeq ($(uname_S),FreeBSD)
NEEDS_LIBICONV = YesPlease
ALL_CFLAGS += -I/usr/local/include
ALL_LDFLAGS += -L/usr/local/lib
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
NEEDS_LIBICONV = YesPlease
ALL_CFLAGS += -I/usr/local/include
ALL_LDFLAGS += -L/usr/local/lib
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
endif
ifeq ($(uname_S),NetBSD)
ifeq ($(shell expr "$(uname_R)" : '[01]\.'),2)
NEEDS_LIBICONV = YesPlease
endif
ALL_CFLAGS += -I/usr/pkg/include
ALL_LDFLAGS += -L/usr/pkg/lib -Wl,-rpath,/usr/pkg/lib
BASIC_CFLAGS += -I/usr/pkg/include
BASIC_LDFLAGS += -L/usr/pkg/lib
ALL_LDFLAGS += -Wl,-rpath,/usr/pkg/lib
endif
ifeq ($(uname_S),AIX)
NO_STRCASESTR=YesPlease
@ -393,9 +409,9 @@ ifeq ($(uname_S),IRIX64)
NO_STRLCPY = YesPlease
NO_SOCKADDR_STORAGE=YesPlease
SHELL_PATH=/usr/gnu/bin/bash
ALL_CFLAGS += -DPATH_MAX=1024
BASIC_CFLAGS += -DPATH_MAX=1024
# for now, build 32-bit version
ALL_LDFLAGS += -L/usr/lib32
BASIC_LDFLAGS += -L/usr/lib32
endif
ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
@ -404,21 +420,34 @@ endif
-include config.mak.autogen
-include config.mak
ifdef WITH_OWN_SUBPROCESS_PY
PYMODULES += compat/subprocess.py
else
ifeq ($(NO_PYTHON),)
ifneq ($(shell $(PYTHON_PATH) -c 'import subprocess;print"OK"' 2>/dev/null),OK)
PYMODULES += compat/subprocess.py
ifeq ($(uname_S),Darwin)
ifndef NO_FINK
ifeq ($(shell test -d /sw/lib && echo y),y)
BASIC_CFLAGS += -I/sw/include
BASIC_LDFLAGS += -L/sw/lib
endif
endif
ifndef NO_DARWIN_PORTS
ifeq ($(shell test -d /opt/local/lib && echo y),y)
BASIC_CFLAGS += -I/opt/local/include
BASIC_LDFLAGS += -L/opt/local/lib
endif
endif
endif
ifdef NO_R_TO_GCC_LINKER
# Some gcc does not accept and pass -R to the linker to specify
# the runtime dynamic library path.
CC_LD_DYNPATH = -Wl,-rpath=
else
CC_LD_DYNPATH = -R
endif
ifndef NO_CURL
ifdef CURLDIR
# This is still problematic -- gcc does not always want -R.
ALL_CFLAGS += -I$(CURLDIR)/include
CURL_LIBCURL = -L$(CURLDIR)/lib -R$(CURLDIR)/lib -lcurl
# Try "-Wl,-rpath=$(CURLDIR)/lib" in such a case.
BASIC_CFLAGS += -I$(CURLDIR)/include
CURL_LIBCURL = -L$(CURLDIR)/lib $(CC_LD_DYNPATH)$(CURLDIR)/lib -lcurl
else
CURL_LIBCURL = -lcurl
endif
@ -437,14 +466,13 @@ endif
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
ifdef OPENSSLDIR
# Again this may be problematic -- gcc does not always want -R.
ALL_CFLAGS += -I$(OPENSSLDIR)/include
OPENSSL_LINK = -L$(OPENSSLDIR)/lib -R$(OPENSSLDIR)/lib
BASIC_CFLAGS += -I$(OPENSSLDIR)/include
OPENSSL_LINK = -L$(OPENSSLDIR)/lib $(CC_LD_DYNPATH)$(OPENSSLDIR)/lib
else
OPENSSL_LINK =
endif
else
ALL_CFLAGS += -DNO_OPENSSL
BASIC_CFLAGS += -DNO_OPENSSL
MOZILLA_SHA1 = 1
OPENSSL_LIBSSL =
endif
@ -455,33 +483,30 @@ else
endif
ifdef NEEDS_LIBICONV
ifdef ICONVDIR
# Again this may be problematic -- gcc does not always want -R.
ALL_CFLAGS += -I$(ICONVDIR)/include
ICONV_LINK = -L$(ICONVDIR)/lib -R$(ICONVDIR)/lib
BASIC_CFLAGS += -I$(ICONVDIR)/include
ICONV_LINK = -L$(ICONVDIR)/lib $(CC_LD_DYNPATH)$(ICONVDIR)/lib
else
ICONV_LINK =
endif
LIBS += $(ICONV_LINK) -liconv
EXTLIBS += $(ICONV_LINK) -liconv
endif
ifdef NEEDS_SOCKET
LIBS += -lsocket
SIMPLE_LIB += -lsocket
EXTLIBS += -lsocket
endif
ifdef NEEDS_NSL
LIBS += -lnsl
SIMPLE_LIB += -lnsl
EXTLIBS += -lnsl
endif
ifdef NO_D_TYPE_IN_DIRENT
ALL_CFLAGS += -DNO_D_TYPE_IN_DIRENT
BASIC_CFLAGS += -DNO_D_TYPE_IN_DIRENT
endif
ifdef NO_D_INO_IN_DIRENT
ALL_CFLAGS += -DNO_D_INO_IN_DIRENT
BASIC_CFLAGS += -DNO_D_INO_IN_DIRENT
endif
ifdef NO_C99_FORMAT
ALL_CFLAGS += -DNO_C99_FORMAT
endif
ifdef NO_SYMLINK_HEAD
ALL_CFLAGS += -DNO_SYMLINK_HEAD
BASIC_CFLAGS += -DNO_SYMLINK_HEAD
endif
ifdef NO_STRCASESTR
COMPAT_CFLAGS += -DNO_STRCASESTR
@ -495,7 +520,7 @@ ifdef NO_SETENV
COMPAT_CFLAGS += -DNO_SETENV
COMPAT_OBJS += compat/setenv.o
endif
ifdef NO_SETENV
ifdef NO_UNSETENV
COMPAT_CFLAGS += -DNO_UNSETENV
COMPAT_OBJS += compat/unsetenv.o
endif
@ -503,22 +528,35 @@ ifdef NO_MMAP
COMPAT_CFLAGS += -DNO_MMAP
COMPAT_OBJS += compat/mmap.o
endif
ifdef NO_PREAD
COMPAT_CFLAGS += -DNO_PREAD
COMPAT_OBJS += compat/pread.o
endif
ifdef NO_FAST_WORKING_DIRECTORY
BASIC_CFLAGS += -DNO_FAST_WORKING_DIRECTORY
endif
ifdef NO_TRUSTABLE_FILEMODE
BASIC_CFLAGS += -DNO_TRUSTABLE_FILEMODE
endif
ifdef NO_IPV6
ALL_CFLAGS += -DNO_IPV6
BASIC_CFLAGS += -DNO_IPV6
endif
ifdef NO_SOCKADDR_STORAGE
ifdef NO_IPV6
ALL_CFLAGS += -Dsockaddr_storage=sockaddr_in
BASIC_CFLAGS += -Dsockaddr_storage=sockaddr_in
else
ALL_CFLAGS += -Dsockaddr_storage=sockaddr_in6
BASIC_CFLAGS += -Dsockaddr_storage=sockaddr_in6
endif
endif
ifdef NO_INET_NTOP
LIB_OBJS += compat/inet_ntop.o
endif
ifdef NO_INET_PTON
LIB_OBJS += compat/inet_pton.o
endif
ifdef NO_ICONV
ALL_CFLAGS += -DNO_ICONV
BASIC_CFLAGS += -DNO_ICONV
endif
ifdef PPC_SHA1
@ -534,12 +572,12 @@ ifdef MOZILLA_SHA1
LIB_OBJS += mozilla-sha1/sha1.o
else
SHA1_HEADER = <openssl/sha.h>
LIBS += $(LIB_4_CRYPTO)
EXTLIBS += $(LIB_4_CRYPTO)
endif
endif
endif
ifdef NO_ACCURATE_DIFF
ALL_CFLAGS += -DNO_ACCURATE_DIFF
ifdef NO_PERL_MAKEMAKER
export NO_PERL_MAKEMAKER
endif
# Shell quote (do not use $(call) to accommodate ancient setups);
@ -554,17 +592,27 @@ prefix_SQ = $(subst ','\'',$(prefix))
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
PYTHON_PATH_SQ = $(subst ','\'',$(PYTHON_PATH))
GIT_PYTHON_DIR_SQ = $(subst ','\'',$(GIT_PYTHON_DIR))
ALL_CFLAGS += -DSHA1_HEADER='$(SHA1_HEADER_SQ)' $(COMPAT_CFLAGS)
LIBS = $(GITLIBS) $(EXTLIBS)
BASIC_CFLAGS += -DSHA1_HEADER='$(SHA1_HEADER_SQ)' $(COMPAT_CFLAGS)
LIB_OBJS += $(COMPAT_OBJS)
ALL_CFLAGS += $(BASIC_CFLAGS)
ALL_LDFLAGS += $(BASIC_LDFLAGS)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk gitweb/gitweb.cgi
all:: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk gitweb/gitweb.cgi
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), rm -f '$p';)
endif
all:
all::
$(MAKE) -C perl PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
$(MAKE) -C templates
strip: $(PROGRAMS) git$X
@ -577,6 +625,9 @@ git$X: git.c common-cmds.h $(BUILTIN_OBJS) $(GITLIBS) GIT-CFLAGS
help.o: common-cmds.h
git-merge-recur$X: git-merge-recursive$X
rm -f $@ && ln git-merge-recursive$X $@
$(BUILT_INS): git$X
rm -f $@ && ln git$X $@
@ -590,28 +641,31 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
-e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
-e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
$@.sh >$@+
chmod +x $@+
mv $@+ $@
$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
perl/perl.mak: GIT-CFLAGS
$(MAKE) -C perl PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' $(@F)
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
rm -f $@ $@+
sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
INSTLIBDIR=`$(MAKE) -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!$(PERL_PATH_SQ)|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $$ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.perl >$@+
chmod +x $@+
mv $@+ $@
$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py GIT-CFLAGS
rm -f $@ $@+
sed -e '1s|#!.*python|#!$(PYTHON_PATH_SQ)|' \
-e 's|@@GIT_PYTHON_PATH@@|$(GIT_PYTHON_DIR_SQ)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.py >$@+
chmod +x $@+
mv $@+ $@
git-cherry-pick: git-revert
cp $< $@+
mv $@+ $@
@ -629,11 +683,16 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_HOME_LINK_STR++|$(GITWEB_HOME_LINK_STR)|g' \
-e 's|++GITWEB_SITENAME++|$(GITWEB_SITENAME)|g' \
-e 's|++GITWEB_PROJECTROOT++|$(GITWEB_PROJECTROOT)|g' \
-e 's|++GITWEB_EXPORT_OK++|$(GITWEB_EXPORT_OK)|g' \
-e 's|++GITWEB_STRICT_EXPORT++|$(GITWEB_STRICT_EXPORT)|g' \
-e 's|++GITWEB_BASE_URL++|$(GITWEB_BASE_URL)|g' \
-e 's|++GITWEB_LIST++|$(GITWEB_LIST)|g' \
-e 's|++GITWEB_HOMETEXT++|$(GITWEB_HOMETEXT)|g' \
-e 's|++GITWEB_CSS++|$(GITWEB_CSS)|g' \
-e 's|++GITWEB_LOGO++|$(GITWEB_LOGO)|g' \
-e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \
-e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
-e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
$< >$@+
chmod +x $@+
mv $@+ $@
@ -643,7 +702,6 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
-e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
-e '/@@GITWEB_CGI@@/r gitweb/gitweb.cgi' \
-e '/@@GITWEB_CGI@@/d' \
-e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
@ -663,7 +721,6 @@ configure: configure.ac
git$X git.spec \
$(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
: GIT-VERSION-FILE
%.o: %.c GIT-CFLAGS
@ -687,11 +744,6 @@ endif
git-%$X: %.o $(GITLIBS)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
$(SIMPLE_PROGRAMS) : $(LIB_FILE)
$(SIMPLE_PROGRAMS) : git-%$X : %.o
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIB_FILE) $(SIMPLE_LIB)
ssh-pull.o: ssh-fetch.c
ssh-push.o: ssh-upload.c
git-local-fetch$X: fetch.o
@ -718,12 +770,19 @@ $(DIFF_OBJS): diffcore.h
$(LIB_FILE): $(LIB_OBJS)
rm -f $@ && $(AR) rcs $@ $(LIB_OBJS)
XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o
XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o \
xdiff/xmerge.o
$(XDIFF_OBJS): xdiff/xinclude.h xdiff/xmacros.h xdiff/xdiff.h xdiff/xtypes.h \
xdiff/xutils.h xdiff/xprepare.h xdiff/xdiffi.h xdiff/xemit.h
$(XDIFF_LIB): $(XDIFF_OBJS)
rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)
perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
(cd perl && $(PERL_PATH) Makefile.PL \
PREFIX='$(prefix_SQ)')
doc:
$(MAKE) -C Documentation all
@ -736,7 +795,7 @@ tags:
find . -name '*.[hcS]' -print | xargs ctags -a
### Detect prefix changes
TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):$(GIT_PYTHON_DIR_SQ):\
TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):\
$(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ)
GIT-CFLAGS: .FORCE-GIT-CFLAGS
@ -752,7 +811,6 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
# However, the environment gets quite big, and some programs have problems
# with that.
export NO_PYTHON
export NO_SVN_TESTS
test: all
@ -761,8 +819,8 @@ test: all
test-date$X: test-date.c date.o ctype.o
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) test-date.c date.o ctype.o
test-delta$X: test-delta.c diff-delta.o patch-delta.o
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $^
test-delta$X: test-delta.o diff-delta.o patch-delta.o $(GITLIBS)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
test-dump-cache-tree$X: dump-cache-tree.o $(GITLIBS)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
@ -773,7 +831,7 @@ test-sha1$X: test-sha1.o $(GITLIBS)
check-sha1:: test-sha1$X
./test-sha1.sh
check:
check: common-cmds.h
for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
@ -786,8 +844,7 @@ install: all
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) git$X gitk '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
$(INSTALL) $(PYMODULES) '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
$(MAKE) -C perl prefix='$(prefix_SQ)' install
if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
then \
ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
@ -796,10 +853,15 @@ install: all
'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
fi
$(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
endif
install-doc:
$(MAKE) -C Documentation install
quick-install-doc:
$(MAKE) -C Documentation quick-install
@ -810,8 +872,9 @@ git.spec: git.spec.in
mv $@+ $@
GIT_TARNAME=git-$(GIT_VERSION)
dist: git.spec git-tar-tree
./git-tar-tree HEAD^{tree} $(GIT_TARNAME) > $(GIT_TARNAME).tar
dist: git.spec git-archive
./git-archive --format=tar \
--prefix=$(GIT_TARNAME)/ HEAD^{tree} > $(GIT_TARNAME).tar
@mkdir -p $(GIT_TARNAME)
@cp git.spec $(GIT_TARNAME)
@echo $(GIT_VERSION) > $(GIT_TARNAME)/version
@ -856,7 +919,8 @@ clean:
rm -f $(htmldocs).tar.gz $(manpages).tar.gz
rm -f gitweb/gitweb.cgi
$(MAKE) -C Documentation/ clean
$(MAKE) -C templates clean
$(MAKE) -C perl clean
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
rm -f GIT-VERSION-FILE GIT-CFLAGS
@ -870,7 +934,7 @@ check-docs::
do \
case "$$v" in \
git-merge-octopus | git-merge-ours | git-merge-recursive | \
git-merge-resolve | git-merge-stupid | \
git-merge-resolve | git-merge-stupid | git-merge-recur | \
git-ssh-pull | git-ssh-push ) continue ;; \
esac ; \
test -f "Documentation/$$v.txt" || \
@ -881,3 +945,8 @@ check-docs::
*) echo "no link: $$v";; \
esac ; \
done | sort
### Make sure built-ins do not have dups and listed in git.c
#
check-builtins::
./check-builtins.sh

323
archive-tar.c Normal file
View file

@ -0,0 +1,323 @@
/*
* Copyright (c) 2005, 2006 Rene Scharfe
*/
#include "cache.h"
#include "commit.h"
#include "strbuf.h"
#include "tar.h"
#include "builtin.h"
#include "archive.h"
#define RECORDSIZE (512)
#define BLOCKSIZE (RECORDSIZE * 20)
static char block[BLOCKSIZE];
static unsigned long offset;
static time_t archive_time;
static int tar_umask = 002;
static int verbose;
/* writes out the whole block, but only if it is full */
static void write_if_needed(void)
{
if (offset == BLOCKSIZE) {
write_or_die(1, block, BLOCKSIZE);
offset = 0;
}
}
/*
* queues up writes, so that all our write(2) calls write exactly one
* full block; pads writes to RECORDSIZE
*/
static void write_blocked(const void *data, unsigned long size)
{
const char *buf = data;
unsigned long tail;
if (offset) {
unsigned long chunk = BLOCKSIZE - offset;
if (size < chunk)
chunk = size;
memcpy(block + offset, buf, chunk);
size -= chunk;
offset += chunk;
buf += chunk;
write_if_needed();
}
while (size >= BLOCKSIZE) {
write_or_die(1, buf, BLOCKSIZE);
size -= BLOCKSIZE;
buf += BLOCKSIZE;
}
if (size) {
memcpy(block + offset, buf, size);
offset += size;
}
tail = offset % RECORDSIZE;
if (tail) {
memset(block + offset, 0, RECORDSIZE - tail);
offset += RECORDSIZE - tail;
}
write_if_needed();
}
/*
* The end of tar archives is marked by 2*512 nul bytes and after that
* follows the rest of the block (if any).
*/
static void write_trailer(void)
{
int tail = BLOCKSIZE - offset;
memset(block + offset, 0, tail);
write_or_die(1, block, BLOCKSIZE);
if (tail < 2 * RECORDSIZE) {
memset(block, 0, offset);
write_or_die(1, block, BLOCKSIZE);
}
}
static void strbuf_append_string(struct strbuf *sb, const char *s)
{
int slen = strlen(s);
int total = sb->len + slen;
if (total > sb->alloc) {
sb->buf = xrealloc(sb->buf, total);
sb->alloc = total;
}
memcpy(sb->buf + sb->len, s, slen);
sb->len = total;
}
/*
* pax extended header records have the format "%u %s=%s\n". %u contains
* the size of the whole string (including the %u), the first %s is the
* keyword, the second one is the value. This function constructs such a
* string and appends it to a struct strbuf.
*/
static void strbuf_append_ext_header(struct strbuf *sb, const char *keyword,
const char *value, unsigned int valuelen)
{
char *p;
int len, total, tmp;
/* "%u %s=%s\n" */
len = 1 + 1 + strlen(keyword) + 1 + valuelen + 1;
for (tmp = len; tmp > 9; tmp /= 10)
len++;
total = sb->len + len;
if (total > sb->alloc) {
sb->buf = xrealloc(sb->buf, total);
sb->alloc = total;
}
p = sb->buf;
p += sprintf(p, "%u %s=", len, keyword);
memcpy(p, value, valuelen);
p += valuelen;
*p = '\n';
sb->len = total;
}
static unsigned int ustar_header_chksum(const struct ustar_header *header)
{
char *p = (char *)header;
unsigned int chksum = 0;
while (p < header->chksum)
chksum += *p++;
chksum += sizeof(header->chksum) * ' ';
p += sizeof(header->chksum);
while (p < (char *)header + sizeof(struct ustar_header))
chksum += *p++;
return chksum;
}
static int get_path_prefix(const struct strbuf *path, int maxlen)
{
int i = path->len;
if (i > maxlen)
i = maxlen;
do {
i--;
} while (i > 0 && path->buf[i] != '/');
return i;
}
static void write_entry(const unsigned char *sha1, struct strbuf *path,
unsigned int mode, void *buffer, unsigned long size)
{
struct ustar_header header;
struct strbuf ext_header;
memset(&header, 0, sizeof(header));
ext_header.buf = NULL;
ext_header.len = ext_header.alloc = 0;
if (!sha1) {
*header.typeflag = TYPEFLAG_GLOBAL_HEADER;
mode = 0100666;
strcpy(header.name, "pax_global_header");
} else if (!path) {
*header.typeflag = TYPEFLAG_EXT_HEADER;
mode = 0100666;
sprintf(header.name, "%s.paxheader", sha1_to_hex(sha1));
} else {
if (verbose)
fprintf(stderr, "%.*s\n", path->len, path->buf);
if (S_ISDIR(mode)) {
*header.typeflag = TYPEFLAG_DIR;
mode = (mode | 0777) & ~tar_umask;
} else if (S_ISLNK(mode)) {
*header.typeflag = TYPEFLAG_LNK;
mode |= 0777;
} else if (S_ISREG(mode)) {
*header.typeflag = TYPEFLAG_REG;
mode = (mode | ((mode & 0100) ? 0777 : 0666)) & ~tar_umask;
} else {
error("unsupported file mode: 0%o (SHA1: %s)",
mode, sha1_to_hex(sha1));
return;
}
if (path->len > sizeof(header.name)) {
int plen = get_path_prefix(path, sizeof(header.prefix));
int rest = path->len - plen - 1;
if (plen > 0 && rest <= sizeof(header.name)) {
memcpy(header.prefix, path->buf, plen);
memcpy(header.name, path->buf + plen + 1, rest);
} else {
sprintf(header.name, "%s.data",
sha1_to_hex(sha1));
strbuf_append_ext_header(&ext_header, "path",
path->buf, path->len);
}
} else
memcpy(header.name, path->buf, path->len);
}
if (S_ISLNK(mode) && buffer) {
if (size > sizeof(header.linkname)) {
sprintf(header.linkname, "see %s.paxheader",
sha1_to_hex(sha1));
strbuf_append_ext_header(&ext_header, "linkpath",
buffer, size);
} else
memcpy(header.linkname, buffer, size);
}
sprintf(header.mode, "%07o", mode & 07777);
sprintf(header.size, "%011lo", S_ISREG(mode) ? size : 0);
sprintf(header.mtime, "%011lo", archive_time);
sprintf(header.uid, "%07o", 0);
sprintf(header.gid, "%07o", 0);
strlcpy(header.uname, "root", sizeof(header.uname));
strlcpy(header.gname, "root", sizeof(header.gname));
sprintf(header.devmajor, "%07o", 0);
sprintf(header.devminor, "%07o", 0);
memcpy(header.magic, "ustar", 6);
memcpy(header.version, "00", 2);
sprintf(header.chksum, "%07o", ustar_header_chksum(&header));
if (ext_header.len > 0) {
write_entry(sha1, NULL, 0, ext_header.buf, ext_header.len);
free(ext_header.buf);
}
write_blocked(&header, sizeof(header));
if (S_ISREG(mode) && buffer && size > 0)
write_blocked(buffer, size);
}
static void write_global_extended_header(const unsigned char *sha1)
{
struct strbuf ext_header;
ext_header.buf = NULL;
ext_header.len = ext_header.alloc = 0;
strbuf_append_ext_header(&ext_header, "comment", sha1_to_hex(sha1), 40);
write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);
free(ext_header.buf);
}
static int git_tar_config(const char *var, const char *value)
{
if (!strcmp(var, "tar.umask")) {
if (!strcmp(value, "user")) {
tar_umask = umask(0);
umask(tar_umask);
} else {
tar_umask = git_config_int(var, value);
}
return 0;
}
return git_default_config(var, value);
}
static int write_tar_entry(const unsigned char *sha1,
const char *base, int baselen,
const char *filename, unsigned mode, int stage)
{
static struct strbuf path;
int filenamelen = strlen(filename);
void *buffer;
char type[20];
unsigned long size;
if (!path.alloc) {
path.buf = xmalloc(PATH_MAX);
path.alloc = PATH_MAX;
path.len = path.eof = 0;
}
if (path.alloc < baselen + filenamelen) {
free(path.buf);
path.buf = xmalloc(baselen + filenamelen);
path.alloc = baselen + filenamelen;
}
memcpy(path.buf, base, baselen);
memcpy(path.buf + baselen, filename, filenamelen);
path.len = baselen + filenamelen;
if (S_ISDIR(mode)) {
strbuf_append_string(&path, "/");
buffer = NULL;
size = 0;
} else {
buffer = read_sha1_file(sha1, type, &size);
if (!buffer)
die("cannot read %s", sha1_to_hex(sha1));
}
write_entry(sha1, &path, mode, buffer, size);
free(buffer);
return READ_TREE_RECURSIVE;
}
int write_tar_archive(struct archiver_args *args)
{
int plen = args->base ? strlen(args->base) : 0;
git_config(git_tar_config);
archive_time = args->time;
verbose = args->verbose;
if (args->commit_sha1)
write_global_extended_header(args->commit_sha1);
if (args->base && plen > 0 && args->base[plen - 1] == '/') {
char *base = xstrdup(args->base);
int baselen = strlen(base);
while (baselen > 0 && base[baselen - 1] == '/')
base[--baselen] = '\0';
write_tar_entry(args->tree->object.sha1, "", 0, base, 040777, 0);
free(base);
}
read_tree_recursive(args->tree, args->base, plen, 0,
args->pathspec, write_tar_entry);
write_trailer();
return 0;
}

349
archive-zip.c Normal file
View file

@ -0,0 +1,349 @@
/*
* Copyright (c) 2006 Rene Scharfe
*/
#include "cache.h"
#include "commit.h"
#include "blob.h"
#include "tree.h"
#include "quote.h"
#include "builtin.h"
#include "archive.h"
static int verbose;
static int zip_date;
static int zip_time;
static unsigned char *zip_dir;
static unsigned int zip_dir_size;
static unsigned int zip_offset;
static unsigned int zip_dir_offset;
static unsigned int zip_dir_entries;
#define ZIP_DIRECTORY_MIN_SIZE (1024 * 1024)
struct zip_local_header {
unsigned char magic[4];
unsigned char version[2];
unsigned char flags[2];
unsigned char compression_method[2];
unsigned char mtime[2];
unsigned char mdate[2];
unsigned char crc32[4];
unsigned char compressed_size[4];
unsigned char size[4];
unsigned char filename_length[2];
unsigned char extra_length[2];
unsigned char _end[1];
};
struct zip_dir_header {
unsigned char magic[4];
unsigned char creator_version[2];
unsigned char version[2];
unsigned char flags[2];
unsigned char compression_method[2];
unsigned char mtime[2];
unsigned char mdate[2];
unsigned char crc32[4];
unsigned char compressed_size[4];
unsigned char size[4];
unsigned char filename_length[2];
unsigned char extra_length[2];
unsigned char comment_length[2];
unsigned char disk[2];
unsigned char attr1[2];
unsigned char attr2[4];
unsigned char offset[4];
unsigned char _end[1];
};
struct zip_dir_trailer {
unsigned char magic[4];
unsigned char disk[2];
unsigned char directory_start_disk[2];
unsigned char entries_on_this_disk[2];
unsigned char entries[2];
unsigned char size[4];
unsigned char offset[4];
unsigned char comment_length[2];
unsigned char _end[1];
};
/*
* On ARM, padding is added at the end of the struct, so a simple
* sizeof(struct ...) reports two bytes more than the payload size
* we're interested in.
*/
#define ZIP_LOCAL_HEADER_SIZE offsetof(struct zip_local_header, _end)
#define ZIP_DIR_HEADER_SIZE offsetof(struct zip_dir_header, _end)
#define ZIP_DIR_TRAILER_SIZE offsetof(struct zip_dir_trailer, _end)
static void copy_le16(unsigned char *dest, unsigned int n)
{
dest[0] = 0xff & n;
dest[1] = 0xff & (n >> 010);
}
static void copy_le32(unsigned char *dest, unsigned int n)
{
dest[0] = 0xff & n;
dest[1] = 0xff & (n >> 010);
dest[2] = 0xff & (n >> 020);
dest[3] = 0xff & (n >> 030);
}
static void *zlib_deflate(void *data, unsigned long size,
unsigned long *compressed_size)
{
z_stream stream;
unsigned long maxsize;
void *buffer;
int result;
memset(&stream, 0, sizeof(stream));
deflateInit(&stream, zlib_compression_level);
maxsize = deflateBound(&stream, size);
buffer = xmalloc(maxsize);
stream.next_in = data;
stream.avail_in = size;
stream.next_out = buffer;
stream.avail_out = maxsize;
do {
result = deflate(&stream, Z_FINISH);
} while (result == Z_OK);
if (result != Z_STREAM_END) {
free(buffer);
return NULL;
}
deflateEnd(&stream);
*compressed_size = stream.total_out;
return buffer;
}
static char *construct_path(const char *base, int baselen,
const char *filename, int isdir, int *pathlen)
{
int filenamelen = strlen(filename);
int len = baselen + filenamelen;
char *path, *p;
if (isdir)
len++;
p = path = xmalloc(len + 1);
memcpy(p, base, baselen);
p += baselen;
memcpy(p, filename, filenamelen);
p += filenamelen;
if (isdir)
*p++ = '/';
*p = '\0';
*pathlen = len;
return path;
}
static int write_zip_entry(const unsigned char *sha1,
const char *base, int baselen,
const char *filename, unsigned mode, int stage)
{
struct zip_local_header header;
struct zip_dir_header dirent;
unsigned long attr2;
unsigned long compressed_size;
unsigned long uncompressed_size;
unsigned long crc;
unsigned long direntsize;
unsigned long size;
int method;
int result = -1;
int pathlen;
unsigned char *out;
char *path;
char type[20];
void *buffer = NULL;
void *deflated = NULL;
crc = crc32(0, NULL, 0);
path = construct_path(base, baselen, filename, S_ISDIR(mode), &pathlen);
if (verbose)
fprintf(stderr, "%s\n", path);
if (pathlen > 0xffff) {
error("path too long (%d chars, SHA1: %s): %s", pathlen,
sha1_to_hex(sha1), path);
goto out;
}
if (S_ISDIR(mode)) {
method = 0;
attr2 = 16;
result = READ_TREE_RECURSIVE;
out = NULL;
uncompressed_size = 0;
compressed_size = 0;
} else if (S_ISREG(mode) || S_ISLNK(mode)) {
method = 0;
attr2 = S_ISLNK(mode) ? ((mode | 0777) << 16) : 0;
if (S_ISREG(mode) && zlib_compression_level != 0)
method = 8;
result = 0;
buffer = read_sha1_file(sha1, type, &size);
if (!buffer)
die("cannot read %s", sha1_to_hex(sha1));
crc = crc32(crc, buffer, size);
out = buffer;
uncompressed_size = size;
compressed_size = size;
} else {
error("unsupported file mode: 0%o (SHA1: %s)", mode,
sha1_to_hex(sha1));
goto out;
}
if (method == 8) {
deflated = zlib_deflate(buffer, size, &compressed_size);
if (deflated && compressed_size - 6 < size) {
/* ZLIB --> raw compressed data (see RFC 1950) */
/* CMF and FLG ... */
out = (unsigned char *)deflated + 2;
compressed_size -= 6; /* ... and ADLER32 */
} else {
method = 0;
compressed_size = size;
}
}
/* make sure we have enough free space in the dictionary */
direntsize = ZIP_DIR_HEADER_SIZE + pathlen;
while (zip_dir_size < zip_dir_offset + direntsize) {
zip_dir_size += ZIP_DIRECTORY_MIN_SIZE;
zip_dir = xrealloc(zip_dir, zip_dir_size);
}
copy_le32(dirent.magic, 0x02014b50);
copy_le16(dirent.creator_version, S_ISLNK(mode) ? 0x0317 : 0);
copy_le16(dirent.version, 10);
copy_le16(dirent.flags, 0);
copy_le16(dirent.compression_method, method);
copy_le16(dirent.mtime, zip_time);
copy_le16(dirent.mdate, zip_date);
copy_le32(dirent.crc32, crc);
copy_le32(dirent.compressed_size, compressed_size);
copy_le32(dirent.size, uncompressed_size);
copy_le16(dirent.filename_length, pathlen);
copy_le16(dirent.extra_length, 0);
copy_le16(dirent.comment_length, 0);
copy_le16(dirent.disk, 0);
copy_le16(dirent.attr1, 0);
copy_le32(dirent.attr2, attr2);
copy_le32(dirent.offset, zip_offset);
memcpy(zip_dir + zip_dir_offset, &dirent, ZIP_DIR_HEADER_SIZE);
zip_dir_offset += ZIP_DIR_HEADER_SIZE;
memcpy(zip_dir + zip_dir_offset, path, pathlen);
zip_dir_offset += pathlen;
zip_dir_entries++;
copy_le32(header.magic, 0x04034b50);
copy_le16(header.version, 10);
copy_le16(header.flags, 0);
copy_le16(header.compression_method, method);
copy_le16(header.mtime, zip_time);
copy_le16(header.mdate, zip_date);
copy_le32(header.crc32, crc);
copy_le32(header.compressed_size, compressed_size);
copy_le32(header.size, uncompressed_size);
copy_le16(header.filename_length, pathlen);
copy_le16(header.extra_length, 0);
write_or_die(1, &header, ZIP_LOCAL_HEADER_SIZE);
zip_offset += ZIP_LOCAL_HEADER_SIZE;
write_or_die(1, path, pathlen);
zip_offset += pathlen;
if (compressed_size > 0) {
write_or_die(1, out, compressed_size);
zip_offset += compressed_size;
}
out:
free(buffer);
free(deflated);
free(path);
return result;
}
static void write_zip_trailer(const unsigned char *sha1)
{
struct zip_dir_trailer trailer;
copy_le32(trailer.magic, 0x06054b50);
copy_le16(trailer.disk, 0);
copy_le16(trailer.directory_start_disk, 0);
copy_le16(trailer.entries_on_this_disk, zip_dir_entries);
copy_le16(trailer.entries, zip_dir_entries);
copy_le32(trailer.size, zip_dir_offset);
copy_le32(trailer.offset, zip_offset);
copy_le16(trailer.comment_length, sha1 ? 40 : 0);
write_or_die(1, zip_dir, zip_dir_offset);
write_or_die(1, &trailer, ZIP_DIR_TRAILER_SIZE);
if (sha1)
write_or_die(1, sha1_to_hex(sha1), 40);
}
static void dos_time(time_t *time, int *dos_date, int *dos_time)
{
struct tm *t = localtime(time);
*dos_date = t->tm_mday + (t->tm_mon + 1) * 32 +
(t->tm_year + 1900 - 1980) * 512;
*dos_time = t->tm_sec / 2 + t->tm_min * 32 + t->tm_hour * 2048;
}
int write_zip_archive(struct archiver_args *args)
{
int plen = strlen(args->base);
dos_time(&args->time, &zip_date, &zip_time);
zip_dir = xmalloc(ZIP_DIRECTORY_MIN_SIZE);
zip_dir_size = ZIP_DIRECTORY_MIN_SIZE;
verbose = args->verbose;
if (args->base && plen > 0 && args->base[plen - 1] == '/') {
char *base = xstrdup(args->base);
int baselen = strlen(base);
while (baselen > 0 && base[baselen - 1] == '/')
base[--baselen] = '\0';
write_zip_entry(args->tree->object.sha1, "", 0, base, 040777, 0);
free(base);
}
read_tree_recursive(args->tree, args->base, plen, 0,
args->pathspec, write_zip_entry);
write_zip_trailer(args->commit_sha1);
free(zip_dir);
return 0;
}
void *parse_extra_zip_args(int argc, const char **argv)
{
for (; argc > 0; argc--, argv++) {
const char *arg = argv[0];
if (arg[0] == '-' && isdigit(arg[1]) && arg[2] == '\0')
zlib_compression_level = arg[1] - '0';
else
die("Unknown argument for zip format: %s", arg);
}
return NULL;
}

Some files were not shown because too many files have changed in this diff Show more