undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'master' into sp/gfi

Browse Source 
git-fast-import requires use of inttypes.h, but the master branch has
added it to git-compat-util differently than git-fast-import originally
had used it.  This merge back of master to the fast-import topic is to
get (and use) inttypes.h the way master is using it.

This is a partially evil merge to remove the call to setup_ident(),
as the master branch now contains a change which makes this implicit
and therefore removed the function declaration. (commit 01754769).

Conflicts:

	git-compat-util.h
This commit is contained in:
Shawn O. Pearce 2007-01-30 11:07:24 -05:00
commit 76db9dec81
252 changed files with 5438 additions and 2659 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.gitignore vendored
View File

@ -23,6 +23,7 @@ git-clean
git-clone
git-commit
git-commit-tree
git-config
git-convert-objects
git-count-objects
git-cvsexportcommit
@ -42,6 +43,7 @@ git-findtags
git-fmt-merge-msg
git-for-each-ref
git-format-patch
git-fsck
git-fsck-objects
git-gc
git-get-tar-commit-id

2
.mailmap
View File

@ -30,7 +30,9 @@ Robert Fitzsimons <robfitz@273k.net>
Santi Béjar <sbejar@gmail.com>
Sean Estabrooks <seanlkml@sympatico.ca>
Shawn O. Pearce <spearce@spearce.org>
Theodore Ts'o <tytso@mit.edu>
Tony Luck <tony.luck@intel.com>
Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Ville Skyttä <scop@xemacs.org>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
anonymous <linux@horizon.com>

2
Documentation/.gitignore vendored
View File

@ -4,4 +4,4 @@
*.7
howto-index.txt
doc.dep
README
cmds-*.txt

20
Documentation/Makefile
View File

@ -71,14 +71,24 @@ doc.dep : $(wildcard *.txt) build-docdep.perl
-include doc.dep
git.7: README
cmds_txt = cmds-ancillaryinterrogators.txt \
cmds-ancillarymanipulators.txt \
cmds-mainporcelain.txt \
cmds-plumbinginterrogators.txt \
cmds-plumbingmanipulators.txt \
cmds-synchingrepositories.txt \
cmds-synchelpers.txt \
cmds-purehelpers.txt \
cmds-foreignscminterface.txt
README: ../README
cp $< $@
$(cmds_txt): cmd-list.perl $(MAN1_TXT)
perl ./cmd-list.perl
git.7 git.html: git.txt core-intro.txt
clean:
rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep README
rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep
rm -f $(cmds_txt)
%.html : %.txt
asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
@ -89,8 +99,6 @@ clean:
%.xml : %.txt
asciidoc -b docbook -d manpage -f asciidoc.conf $<
git.html: git.txt README
glossary.html : glossary.txt sort_glossary.pl
cat $< | \
perl sort_glossary.pl | \

23
Documentation/SubmittingPatches
View File

@ -23,7 +23,8 @@ probably need to split up your commit to finer grained pieces.
Oh, another thing. I am picky about whitespaces. Make sure your
changes do not trigger errors with the sample pre-commit hook shipped
in templates/hooks--pre-commit.
in templates/hooks--pre-commit. To help ensure this does not happen,
run git diff --check on your changes before you commit.
(2) Generate your patch using git tools out of your commits.
@ -72,7 +73,9 @@ other than the commit message itself. Place such "cover letter"
material between the three dash lines and the diffstat.
Do not attach the patch as a MIME attachment, compressed or not.
Do not let your e-mail client send quoted-printable. Many
Do not let your e-mail client send quoted-printable. Do not let
your e-mail client send format=flowed which would destroy
whitespaces in your patches. Many
popular e-mail applications will not always transmit a MIME
attachment as plain text, making it impossible to comment on
your code. A MIME attachment also takes a bit more time to
@ -312,3 +315,19 @@ settings but I haven't tried, yet.
mail.identity.default.compose_html => false
mail.identity.id?.compose_html => false
Gnus
----
'|' in the *Summary* buffer can be used to pipe the current
message to an external program, and this is a handy way to drive
"git am". However, if the message is MIME encoded, what is
piped into the program is the representation you see in your
*Article* buffer after unwrapping MIME. This is often not what
you would want for two reasons. It tends to screw up non ASCII
characters (most notably in people's names), and also
whitespaces (fatal in patches). Running 'C-u g' to display the
message in raw form before using '|' to run the pipe can work
this problem around.

186
Documentation/cmd-list.perl Executable file
View File

@ -0,0 +1,186 @@
#
sub format_one {
my ($out, $name) = @_;
my ($state, $description);
open I, '<', "$name.txt" or die "No such file $name.txt";
while (<I>) {
if (/^NAME$/) {
$state = 1;
next;
}
if ($state == 1 && /^----$/) {
$state = 2;
next;
}
next if ($state != 2);
chomp;
$description = $_;
last;
}
close I;
if (!defined $description) {
die "No description found in $name.txt";
}
if (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) {
print $out "gitlink:$name\[1\]::\n";
print $out "\t$text.\n\n";
}
else {
die "Description does not match $name: $description";
}
}
my %cmds = ();
while (<DATA>) {
next if /^#/;
chomp;
my ($name, $cat) = /^(\S+)\s+(.*)$/;
push @{$cmds{$cat}}, $name;
}
for my $cat (qw(ancillaryinterrogators
ancillarymanipulators
mainporcelain
plumbinginterrogators
plumbingmanipulators
synchingrepositories
foreignscminterface
purehelpers
synchelpers)) {
my $out = "cmds-$cat.txt";
open O, '>', "$out+" or die "Cannot open output file $out+";
for (@{$cmds{$cat}}) {
format_one(\*O, $_);
}
close O;
rename "$out+", "$out";
}
__DATA__
git-add mainporcelain
git-am mainporcelain
git-annotate ancillaryinterrogators
git-applymbox ancillaryinterrogators
git-applypatch purehelpers
git-apply plumbingmanipulators
git-archimport foreignscminterface
git-archive mainporcelain
git-bisect mainporcelain
git-blame ancillaryinterrogators
git-branch mainporcelain
git-cat-file plumbinginterrogators
git-checkout-index plumbingmanipulators
git-checkout mainporcelain
git-check-ref-format purehelpers
git-cherry ancillaryinterrogators
git-cherry-pick mainporcelain
git-clean mainporcelain
git-clone mainporcelain
git-commit mainporcelain
git-commit-tree plumbingmanipulators
git-convert-objects ancillarymanipulators
git-count-objects ancillaryinterrogators
git-cvsexportcommit foreignscminterface
git-cvsimport foreignscminterface
git-cvsserver foreignscminterface
git-daemon synchingrepositories
git-describe mainporcelain
git-diff-files plumbinginterrogators
git-diff-index plumbinginterrogators
git-diff mainporcelain
git-diff-stages plumbinginterrogators
git-diff-tree plumbinginterrogators
git-fetch mainporcelain
git-fetch-pack synchingrepositories
git-fmt-merge-msg purehelpers
git-for-each-ref plumbinginterrogators
git-format-patch mainporcelain
git-fsck ancillaryinterrogators
git-gc mainporcelain
git-get-tar-commit-id ancillaryinterrogators
git-grep mainporcelain
git-hash-object plumbingmanipulators
git-http-fetch synchelpers
git-http-push synchelpers
git-imap-send foreignscminterface
git-index-pack plumbingmanipulators
git-init mainporcelain
git-instaweb ancillaryinterrogators
gitk mainporcelain
git-local-fetch synchingrepositories
git-log mainporcelain
git-lost-found ancillarymanipulators
git-ls-files plumbinginterrogators
git-ls-remote plumbinginterrogators
git-ls-tree plumbinginterrogators
git-mailinfo purehelpers
git-mailsplit purehelpers
git-merge-base plumbinginterrogators
git-merge-file plumbingmanipulators
git-merge-index plumbingmanipulators
git-merge mainporcelain
git-merge-one-file purehelpers
git-merge-tree ancillaryinterrogators
git-mktag plumbingmanipulators
git-mktree plumbingmanipulators
git-mv mainporcelain
git-name-rev plumbinginterrogators
git-pack-objects plumbingmanipulators
git-pack-redundant plumbinginterrogators
git-pack-refs ancillarymanipulators
git-parse-remote synchelpers
git-patch-id purehelpers
git-peek-remote purehelpers
git-prune ancillarymanipulators
git-prune-packed plumbingmanipulators
git-pull mainporcelain
git-push mainporcelain
git-quiltimport foreignscminterface
git-read-tree plumbingmanipulators
git-rebase mainporcelain
git-receive-pack synchelpers
git-reflog ancillarymanipulators
git-relink ancillarymanipulators
git-repack ancillarymanipulators
git-config ancillarymanipulators
git-request-pull foreignscminterface
git-rerere ancillaryinterrogators
git-reset mainporcelain
git-resolve mainporcelain
git-revert mainporcelain
git-rev-list plumbinginterrogators
git-rev-parse ancillaryinterrogators
git-rm mainporcelain
git-runstatus ancillaryinterrogators
git-send-email foreignscminterface
git-send-pack synchingrepositories
git-shell synchelpers
git-shortlog mainporcelain
git-show mainporcelain
git-show-branch ancillaryinterrogators
git-show-index plumbinginterrogators
git-show-ref plumbinginterrogators
git-sh-setup purehelpers
git-ssh-fetch synchingrepositories
git-ssh-upload synchingrepositories
git-status mainporcelain
git-stripspace purehelpers
git-svn foreignscminterface
git-svnimport foreignscminterface
git-symbolic-ref plumbingmanipulators
git-tag mainporcelain
git-tar-tree plumbinginterrogators
git-unpack-file plumbinginterrogators
git-unpack-objects plumbingmanipulators
git-update-index plumbingmanipulators
git-update-ref plumbingmanipulators
git-update-server-info synchingrepositories
git-upload-archive synchelpers
git-upload-pack synchelpers
git-var plumbinginterrogators
git-verify-pack plumbinginterrogators
git-verify-tag ancillaryinterrogators
git-whatchanged ancillaryinterrogators
git-write-tree plumbingmanipulators

146
Documentation/config.txt
View File

@ -2,21 +2,84 @@ CONFIGURATION FILE
------------------
The git configuration file contains a number of variables that affect
the git command's behavior. They can be used by both the git plumbing
the git command's behavior. `.git/config` file for each repository
is used to store the information for that repository, and
`$HOME/.gitconfig` is used to store per user information to give
fallback values for `.git/config` file.
They can be used by both the git plumbing
and the porcelains. The variables are divided into sections, where
in the fully qualified variable name the variable itself is the last
dot-separated segment and the section name is everything before the last
dot. The variable names are case-insensitive and only alphanumeric
characters are allowed. Some variables may appear multiple times.
Syntax
~~~~~~
The syntax is fairly flexible and permissive; whitespaces are mostly
ignored. The '#' and ';' characters begin comments to the end of line,
blank lines are ignored, lines containing strings enclosed in square
brackets start sections and all the other lines are recognized
as setting variables, in the form 'name = value'. If there is no equal
sign on the line, the entire line is taken as 'name' and the variable
is recognized as boolean "true". String values may be entirely or partially
enclosed in double quotes; some variables may require special value format.
ignored. The '#' and ';' characters begin comments to the end of line,
blank lines are ignored.
The file consists of sections and variables. A section begins with
the name of the section in square brackets and continues until the next
section begins. Section names are not case sensitive. Only alphanumeric
characters, '`-`' and '`.`' are allowed in section names. Each variable
must belong to some section, which means that there must be section
header before first setting of a variable.
Sections can be further divided into subsections. To begin a subsection
put its name in double quotes, separated by space from the section name,
in the section header, like in example below:
--------
[section "subsection"]
--------
Subsection names can contain any characters except newline (doublequote
'`"`' and backslash have to be escaped as '`\"`' and '`\\`',
respecitvely) and are case sensitive. Section header cannot span multiple
lines. Variables may belong directly to a section or to a given subsection.
You can have `[section]` if you have `[section "subsection"]`, but you
don't need to.
There is also (case insensitive) alternative `[section.subsection]` syntax.
In this syntax subsection names follow the same restrictions as for section
name.
All the other lines are recognized as setting variables, in the form
'name = value'. If there is no equal sign on the line, the entire line
is taken as 'name' and the variable is recognized as boolean "true".
The variable names are case-insensitive and only alphanumeric
characters and '`-`' are allowed. There can be more than one value
for a given variable; we say then that variable is multivalued.
Leading and trailing whitespace in a variable value is discarded.
Internal whitespace within a variable value is retained verbatim.
The values following the equals sign in variable assign are all either
a string, an integer, or a boolean. Boolean values may be given as yes/no,
0/1 or true/false. Case is not significant in boolean values, when
converting value to the canonical form using '--bool' type specifier;
`git-config` will ensure that the output is "true" or "false".
String values may be entirely or partially enclosed in double quotes.
You need to enclose variable value in double quotes if you want to
preserve leading or trailing whitespace, or if variable value contains
beginning of comment characters (if it contains '#' or ';').
Double quote '`"`' and backslash '`\`' characters in variable value must
be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'.
The following escape sequences (beside '`\"`' and '`\\`') are recognized:
'`\n`' for newline character (NL), '`\t`' for horizontal tabulation (HT, TAB)
and '`\b`' for backspace (BS). No other char escape sequence, nor octal
char sequences are valid.
Variable value ending in a '`\`' is continued on the next line in the
customary UNIX fashion.
Some variables may require special value format.
Example
~~~~~~~
@ -35,6 +98,10 @@ Example
remote = origin
merge = refs/heads/devel
# Proxy settings
[core]
gitProxy="ssh" for "ssh://kernel.org/"
gitProxy=default-proxy ; for the rest
Variables
~~~~~~~~~
@ -183,10 +250,15 @@ 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`.
refs).
+
The value for these configuration variables is a list of colors (at most
two) and attributes (at most one), separated by spaces. The colors
accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`,
`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`,
`blink` and `reverse`. The first color given is the foreground; the
second is the background. The position of the attribute, if any,
doesn't matter.
color.diff::
When true (or `always`), always use colors in patch.
@ -194,12 +266,13 @@ color.diff::
colors only when the output is to the terminal.
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 values of these
variables may be specified as in color.branch.<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), `new` (added lines),
`commit` (commit headers), or `whitespace` (highlighting dubious
whitespace). 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
@ -228,6 +301,16 @@ diff.renames::
will enable basic rename detection. If set to "copies" or
"copy", it will detect copies, as well.
fetch.unpackLimit::
If the number of objects fetched over the git native
transfer 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.
format.headers::
Additional email headers to include in a patch to be submitted
by mail. See gitlink:git-format-patch[1].
@ -321,6 +404,13 @@ merge.summary::
Whether to include summaries of merged commits in newly created
merge commit messages. False by default.
merge.verbosity::
Controls the amount of output shown by the recursive merge
strategy. Level 0 outputs nothing except a final error
message if conflicts were detected. Level 1 outputs only
conflicts, 2 outputs conflicts and file changes. Level 5 and
above outputs debugging information. The default is level 2.
pack.window::
The size of the window used by gitlink:git-pack-objects[1] when no
window size is given on the command line. Defaults to 10.
@ -344,6 +434,14 @@ remote.<name>.push::
The default set of "refspec" for gitlink:git-push[1]. See
gitlink:git-push[1].
remote.<name>.receivepack::
The default program to execute on the remote side when pushing. See
option \--exec of gitlink:git-push[1].
remote.<name>.uploadpack::
The default program to execute on the remote side when fetching. See
option \--exec of gitlink:git-fetch-pack[1].
repack.usedeltabaseoffset::
Allow gitlink:git-repack[1] to create packs that uses
delta-base offset. Defaults to false.
@ -377,6 +475,13 @@ user.name::
Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
environment variables. See gitlink:git-commit-tree[1].
user.signingkey::
If gitlink:git-tag[1] is not selecting the key you want it to
automatically when creating a signed tag, you can override the
default selection with this variable. This option is passed
unchanged to gpg's --local-user parameter, so you may specify a key
using any method that gpg supports.
whatchanged.difftree::
The default gitlink:git-diff-tree[1] arguments to be used
for gitlink:git-whatchanged[1].
@ -400,3 +505,8 @@ receive.denyNonFastForwards::
even if that push is forced. This configuration variable is
set when initializing a shared repository.
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.

590
Documentation/core-intro.txt Normal file
View File

@ -0,0 +1,590 @@
////////////////////////////////////////////////////////////////
GIT - the stupid content tracker
////////////////////////////////////////////////////////////////
"git" can mean anything, depending on your mood.
- random three-letter combination that is pronounceable, and not
actually used by any common UNIX command. The fact that it is a
mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the
dictionary of slang.
- "global information tracker": you're in a good mood, and it actually
works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks
This is a (not so) stupid but extremely fast directory content manager.
It doesn't do a whole lot at its core, but what it 'does' do is track
directory contents efficiently.
There are two object abstractions: the "object database", and the
"current directory cache" aka "index".
The Object Database
~~~~~~~~~~~~~~~~~~~
The object database is literally just a content-addressable collection
of objects. All objects are named by their content, which is
approximated by the SHA1 hash of the object itself. Objects may refer
to other objects (by referencing their SHA1 hash), and so you can
build up a hierarchy of objects.
All objects have a statically determined "type" aka "tag", which is
determined at object creation time, and which identifies the format of
the object (i.e. how it is used, and how it can refer to other
objects). There are currently four different object types: "blob",
"tree", "commit" and "tag".
A "blob" object cannot refer to any other object, and is, like the type
implies, a pure storage object containing some user data. It is used to
actually store the file data, i.e. a blob object is associated with some
particular version of some file.
A "tree" object is an object that ties one or more "blob" objects into a
directory structure. In addition, a tree object can refer to other tree
objects, thus creating a directory hierarchy.
A "commit" object ties such directory hierarchies together into
a DAG of revisions - each "commit" is associated with exactly one tree
(the directory hierarchy at the time of the commit). In addition, a
"commit" refers to one or more "parent" commit objects that describe the
history of how we arrived at that directory hierarchy.
As a special case, a commit object with no parents is called the "root"
object, and is the point of an initial project commit. Each project
must have at least one root, and while you can tie several different
root objects together into one project by creating a commit object which
has two or more separate roots as its ultimate parents, that's probably
just going to confuse people. So aim for the notion of "one root object
per project", even if git itself does not enforce that.
A "tag" object symbolically identifies and can be used to sign other
objects. It contains the identifier and type of another object, a
symbolic name (of course!) and, optionally, a signature.
Regardless of object type, all objects share the following
characteristics: they are all deflated with zlib, and have a header
that not only specifies their type, but also provides size information
about the data in the object. It's worth noting that the SHA1 hash
that is used to name the object is the hash of the original data
plus this header, so `sha1sum` 'file' does not match the object name
for 'file'.
(Historical note: in the dawn of the age of git the hash
was the sha1 of the 'compressed' object.)
As a result, the general consistency of an object can always be tested
independently of the contents or the type of the object: all objects can
be validated by verifying that (a) their hashes match the content of the
file and (b) the object successfully inflates to a stream of bytes that
forms a sequence of <ascii type without space> + <space> + <ascii decimal
size> + <byte\0> + <binary object data>.
The structured objects can further have their structure and
connectivity to other objects verified. This is generally done with
the `git-fsck` program, which generates a full dependency graph
of all objects, and verifies their internal consistency (in addition
to just verifying their superficial consistency through the hash).
The object types in some more detail:
Blob Object
~~~~~~~~~~~
A "blob" object is nothing but a binary blob of data, and doesn't
refer to anything else. There is no signature or any other
verification of the data, so while the object is consistent (it 'is'
indexed by its sha1 hash, so the data itself is certainly correct), it
has absolutely no other attributes. No name associations, no
permissions. It is purely a blob of data (i.e. normally "file
contents").
In particular, since the blob is entirely defined by its data, if two
files in a directory tree (or in multiple different versions of the
repository) have the same contents, they will share the same blob
object. The object is totally independent of its location in the
directory tree, and renaming a file does not change the object that
file is associated with in any way.
A blob is typically created when gitlink:git-update-index[1]
is run, and its data can be accessed by gitlink:git-cat-file[1].
Tree Object
~~~~~~~~~~~
The next hierarchical object type is the "tree" object. A tree object
is a list of mode/name/blob data, sorted by name. Alternatively, the
mode data may specify a directory mode, in which case instead of
naming a blob, that name is associated with another TREE object.
Like the "blob" object, a tree object is uniquely determined by the
set contents, and so two separate but identical trees will always
share the exact same object. This is true at all levels, i.e. it's
true for a "leaf" tree (which does not refer to any other trees, only
blobs) as well as for a whole subdirectory.
For that reason a "tree" object is just a pure data abstraction: it
has no history, no signatures, no verification of validity, except
that since the contents are again protected by the hash itself, we can
trust that the tree is immutable and its contents never change.
So you can trust the contents of a tree to be valid, the same way you
can trust the contents of a blob, but you don't know where those
contents 'came' from.
Side note on trees: since a "tree" object is a sorted list of
"filename+content", you can create a diff between two trees without
actually having to unpack two trees. Just ignore all common parts,
and your diff will look right. In other words, you can effectively
(and efficiently) tell the difference between any two random trees by
O(n) where "n" is the size of the difference, rather than the size of
the tree.
Side note 2 on trees: since the name of a "blob" depends entirely and
exclusively on its contents (i.e. there are no names or permissions
involved), you can see trivial renames or permission changes by
noticing that the blob stayed the same. However, renames with data
changes need a smarter "diff" implementation.
A tree is created with gitlink:git-write-tree[1] and
its data can be accessed by gitlink:git-ls-tree[1].
Two trees can be compared with gitlink:git-diff-tree[1].
Commit Object
~~~~~~~~~~~~~
The "commit" object is an object that introduces the notion of
history into the picture. In contrast to the other objects, it
doesn't just describe the physical state of a tree, it describes how
we got there, and why.
A "commit" is defined by the tree-object that it results in, the
parent commits (zero, one or more) that led up to that point, and a
comment on what happened. Again, a commit is not trusted per se:
the contents are well-defined and "safe" due to the cryptographically
strong signatures at all levels, but there is no reason to believe
that the tree is "good" or that the merge information makes sense.
The parents do not have to actually have any relationship with the
result, for example.
Note on commits: unlike real SCM's, commits do not contain
rename information or file mode change information. All of that is
implicit in the trees involved (the result tree, and the result trees
of the parents), and describing that makes no sense in this idiotic
file manager.
A commit is created with gitlink:git-commit-tree[1] and
its data can be accessed by gitlink:git-cat-file[1].
Trust
~~~~~
An aside on the notion of "trust". Trust is really outside the scope
of "git", but it's worth noting a few things. First off, since
everything is hashed with SHA1, you 'can' trust that an object is
intact and has not been messed with by external sources. So the name
of an object uniquely identifies a known state - just not a state that
you may want to trust.
Furthermore, since the SHA1 signature of a commit refers to the
SHA1 signatures of the tree it is associated with and the signatures
of the parent, a single named commit specifies uniquely a whole set
of history, with full contents. You can't later fake any step of the
way once you have the name of a commit.
So to introduce some real trust in the system, the only thing you need
to do is to digitally sign just 'one' special note, which includes the
name of a top-level commit. Your digital signature shows others
that you trust that commit, and the immutability of the history of
commits tells others that they can trust the whole history.
In other words, you can easily validate a whole archive by just
sending out a single email that tells the people the name (SHA1 hash)
of the top commit, and digitally sign that email using something
like GPG/PGP.
To assist in this, git also provides the tag object...
Tag Object
~~~~~~~~~~
Git provides the "tag" object to simplify creating, managing and
exchanging symbolic and signed tokens. The "tag" object at its
simplest simply symbolically identifies another object by containing
the sha1, type and symbolic name.
However it can optionally contain additional signature information
(which git doesn't care about as long as there's less than 8k of
it). This can then be verified externally to git.
Note that despite the tag features, "git" itself only handles content
integrity; the trust framework (and signature provision and
verification) has to come from outside.
A tag is created with gitlink:git-mktag[1],
its data can be accessed by gitlink:git-cat-file[1],
and the signature can be verified by
gitlink:git-verify-tag[1].
The "index" aka "Current Directory Cache"
-----------------------------------------
The index is a simple binary file, which contains an efficient
representation of a virtual directory content at some random time. It
does so by a simple array that associates a set of names, dates,
permissions and content (aka "blob") objects together. The cache is
always kept ordered by name, and names are unique (with a few very
specific rules) at any point in time, but the cache has no long-term
meaning, and can be partially updated at any time.
In particular, the index certainly does not need to be consistent with
the current directory contents (in fact, most operations will depend on
different ways to make the index 'not' be consistent with the directory
hierarchy), but it has three very important attributes:
'(a) it can re-generate the full state it caches (not just the
directory structure: it contains pointers to the "blob" objects so
that it can regenerate the data too)'
As a special case, there is a clear and unambiguous one-way mapping
from a current directory cache to a "tree object", which can be
efficiently created from just the current directory cache without
actually looking at any other data. So a directory cache at any one
time uniquely specifies one and only one "tree" object (but has
additional data to make it easy to match up that tree object with what
has happened in the directory)
'(b) it has efficient methods for finding inconsistencies between that
cached state ("tree object waiting to be instantiated") and the
current state.'
'(c) it can additionally efficiently represent information about merge
conflicts between different tree objects, allowing each pathname to be
associated with sufficient information about the trees involved that
you can create a three-way merge between them.'
Those are the three ONLY things that the directory cache does. It's a
cache, and the normal operation is to re-generate it completely from a
known tree object, or update/compare it with a live tree that is being
developed. If you blow the directory cache away entirely, you generally
haven't lost any information as long as you have the name of the tree
that it described.
At the same time, the index is at the same time also the
staging area for creating new trees, and creating a new tree always
involves a controlled modification of the index file. In particular,
the index file can have the representation of an intermediate tree that
has not yet been instantiated. So the index can be thought of as a
write-back cache, which can contain dirty information that has not yet
been written back to the backing store.
The Workflow
------------
Generally, all "git" operations work on the index file. Some operations
work *purely* on the index file (showing the current state of the
index), but most operations move data to and from the index file. Either
from the database or from the working directory. Thus there are four
main combinations:
1) working directory -> index
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You update the index with information from the working directory with
the gitlink:git-update-index[1] command. You
generally update the index information by just specifying the filename
you want to update, like so:
git-update-index filename
but to avoid common mistakes with filename globbing etc, the command
will not normally add totally new entries or remove old entries,
i.e. it will normally just update existing cache entries.
To tell git that yes, you really do realize that certain files no
longer exist, or that new files should be added, you
should use the `--remove` and `--add` flags respectively.
NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
necessarily be removed: if the files still exist in your directory
structure, the index will be updated with their new status, not
removed. The only thing `--remove` means is that update-cache will be
considering a removed file to be a valid thing, and if the file really
does not exist any more, it will update the index accordingly.
As a special case, you can also do `git-update-index --refresh`, which
will refresh the "stat" information of each index to match the current
stat information. It will 'not' update the object status itself, and
it will only update the fields that are used to quickly test whether
an object still matches its old backing store object.
2) index -> object database
~~~~~~~~~~~~~~~~~~~~~~~~~~~
You write your current index file to a "tree" object with the program
git-write-tree
that doesn't come with any options - it will just write out the
current index into the set of tree objects that describe that state,
and it will return the name of the resulting top-level tree. You can
use that tree to re-generate the index at any time by going in the
other direction:
3) object database -> index
~~~~~~~~~~~~~~~~~~~~~~~~~~~
You read a "tree" file from the object database, and use that to
populate (and overwrite - don't do this if your index contains any
unsaved state that you might want to restore later!) your current
index. Normal operation is just
git-read-tree <sha1 of tree>
and your index file will now be equivalent to the tree that you saved
earlier. However, that is only your 'index' file: your working
directory contents have not been modified.
4) index -> working directory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You update your working directory from the index by "checking out"
files. This is not a very common operation, since normally you'd just
keep your files updated, and rather than write to your working
directory, you'd tell the index files about the changes in your
working directory (i.e. `git-update-index`).
However, if you decide to jump to a new version, or check out somebody
else's version, or just restore a previous tree, you'd populate your
index file with read-tree, and then you need to check out the result
with
git-checkout-index filename
or, if you want to check out all of the index, use `-a`.
NOTE! git-checkout-index normally refuses to overwrite old files, so
if you have an old version of the tree already checked out, you will
need to use the "-f" flag ('before' the "-a" flag or the filename) to
'force' the checkout.
Finally, there are a few odds and ends which are not purely moving
from one representation to the other:
5) Tying it all together
~~~~~~~~~~~~~~~~~~~~~~~~
To commit a tree you have instantiated with "git-write-tree", you'd
create a "commit" object that refers to that tree and the history
behind it - most notably the "parent" commits that preceded it in
history.
Normally a "commit" has one parent: the previous state of the tree
before a certain change was made. However, sometimes it can have two
or more parent commits, in which case we call it a "merge", due to the
fact that such a commit brings together ("merges") two or more
previous states represented by other commits.
In other words, while a "tree" represents a particular directory state
of a working directory, a "commit" represents that state in "time",
and explains how we got there.
You create a commit object by giving it the tree that describes the
state at the time of the commit, and a list of parents:
git-commit-tree <tree> -p <parent> [-p <parent2> ..]
and then giving the reason for the commit on stdin (either through
redirection from a pipe or file, or by just typing it at the tty).
git-commit-tree will return the name of the object that represents
that commit, and you should save it away for later use. Normally,
you'd commit a new `HEAD` state, and while git doesn't care where you
save the note about that state, in practice we tend to just write the
result to the file pointed at by `.git/HEAD`, so that we can always see
what the last committed state was.
Here is an ASCII art by Jon Loeliger that illustrates how
various pieces fit together.
------------
commit-tree
commit obj
+----+
| |
| |
V V
+-----------+
| Object DB |
| Backing |
| Store |
+-----------+
^
write-tree | |
tree obj | |
| | read-tree
| | tree obj
V
+-----------+
| Index |
| "cache" |
+-----------+
update-index ^
blob obj | |
| |
checkout-index -u | | checkout-index
stat | | blob obj
V
+-----------+
| Working |
| Directory |
+-----------+
------------
6) Examining the data
~~~~~~~~~~~~~~~~~~~~~
You can examine the data represented in the object database and the
index with various helper tools. For every object, you can use
gitlink:git-cat-file[1] to examine details about the
object:
git-cat-file -t <objectname>
shows the type of the object, and once you have the type (which is
usually implicit in where you find the object), you can use
git-cat-file blob|tree|commit|tag <objectname>
to show its contents. NOTE! Trees have binary content, and as a result
there is a special helper for showing that content, called
`git-ls-tree`, which turns the binary content into a more easily
readable form.
It's especially instructive to look at "commit" objects, since those
tend to be small and fairly self-explanatory. In particular, if you
follow the convention of having the top commit name in `.git/HEAD`,
you can do
git-cat-file commit HEAD
to see what the top commit was.
7) Merging multiple trees
~~~~~~~~~~~~~~~~~~~~~~~~~
Git helps you do a three-way merge, which you can expand to n-way by
repeating the merge procedure arbitrary times until you finally
"commit" the state. The normal situation is that you'd only do one
three-way merge (two parents), and commit it, but if you like to, you
can do multiple parents in one go.
To do a three-way merge, you need the two sets of "commit" objects
that you want to merge, use those to find the closest common parent (a
third "commit" object), and then use those commit objects to find the
state of the directory ("tree" object) at these points.
To get the "base" for the merge, you first look up the common parent
of two commits with
git-merge-base <commit1> <commit2>
which will return you the commit they are both based on. You should
now look up the "tree" objects of those commits, which you can easily
do with (for example)
git-cat-file commit <commitname> | head -1
since the tree object information is always the first line in a commit
object.
Once you know the three trees you are going to merge (the one
"original" tree, aka the common case, and the two "result" trees, aka
the branches you want to merge), you do a "merge" read into the
index. This will complain if it has to throw away your old index contents, so you should
make sure that you've committed those - in fact you would normally
always do a merge against your last commit (which should thus match
what you have in your current index anyway).
To do the merge, do
git-read-tree -m -u <origtree> <yourtree> <targettree>
which will do all trivial merge operations for you directly in the
index file, and you can just write the result out with
`git-write-tree`.
Historical note. We did not have `-u` facility when this
section was first written, so we used to warn that
the merge is done in the index file, not in your
working tree, and your working tree will not match your
index after this step.
This is no longer true. The above command, thanks to `-u`
option, updates your working tree with the merge results for
paths that have been trivially merged.
8) Merging multiple trees, continued
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sadly, many merges aren't trivial. If there are files that have
been added.moved or removed, or if both branches have modified the
same file, you will be left with an index tree that contains "merge
entries" in it. Such an index tree can 'NOT' be written out to a tree
object, and you will have to resolve any such merge clashes using
other tools before you can write out the result.
You can examine such index state with `git-ls-files --unmerged`
command. An example:
------------------------------------------------
$ git-read-tree -m $orig HEAD $target
$ git-ls-files --unmerged
100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c
100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c
------------------------------------------------
Each line of the `git-ls-files --unmerged` output begins with
the blob mode bits, blob SHA1, 'stage number', and the
filename. The 'stage number' is git's way to say which tree it
came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`
tree, and stage3 `$target` tree.
Earlier we said that trivial merges are done inside
`git-read-tree -m`. For example, if the file did not change
from `$orig` to `HEAD` nor `$target`, or if the file changed
from `$orig` to `HEAD` and `$orig` to `$target` the same way,
obviously the final outcome is what is in `HEAD`. What the
above example shows is that file `hello.c` was changed from
`$orig` to `HEAD` and `$orig` to `$target` in a different way.
You could resolve this by running your favorite 3-way merge
program, e.g. `diff3` or `merge`, on the blob objects from
these three stages yourself, like this:
------------------------------------------------
$ git-cat-file blob 263414f... >hello.c~1
$ git-cat-file blob 06fa6a2... >hello.c~2
$ git-cat-file blob cc44c73... >hello.c~3
$ merge hello.c~2 hello.c~1 hello.c~3
------------------------------------------------
This would leave the merge result in `hello.c~2` file, along
with conflict markers if there are conflicts. After verifying
the merge result makes sense, you can tell git what the final
merge result for this file is by:
mv -f hello.c~2 hello.c
git-update-index hello.c
When a path is in unmerged state, running `git-update-index` for
that path tells git to mark the path resolved.
The above is the description of a git merge at the lowest level,
to help you understand what conceptually happens under the hood.
In practice, nobody, not even git itself, uses three `git-cat-file`
for this. There is `git-merge-index` program that extracts the
stages to temporary files and calls a "merge" script on it:
git-merge-index git-merge-one-file hello.c
and that is what higher level `git resolve` is implemented with.

51
Documentation/core-tutorial.txt
View File

@ -906,18 +906,13 @@ of it as it can automatically (which in this case is just merge the `example`
file, which had no differences in the `mybranch` branch), and say:
----------------
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
...
Auto-merging hello
CONFLICT (content): Merge conflict in hello
Automatic merge failed; fix up by hand
----------------
which is way too verbose, but it basically tells you that it failed the
really trivial merge ("Simple merge") and did an "Automatic merge"
instead, but that too failed due to conflicts in `hello`.
It tells you that it did an "Automatic merge", which
failed due to conflicts in `hello`.
Not to worry. It left the (trivial) conflict in `hello` in the same form you
should already be well used to if you've ever used CVS, so let's just
@ -1129,46 +1124,26 @@ juggle multiple lines of development simultaneously. Of
course, you will pay the price of more disk usage to hold
multiple working trees, but disk space is cheap these days.
[NOTE]
You could even pull from your own repository by
giving '.' as <remote-repository> parameter to `git pull`. This
is useful when you want to merge a local branch (or more, if you
are making an Octopus) into the current branch.
It is likely that you will be pulling from the same remote
repository from time to time. As a short hand, you can store
the remote repository URL in a file under .git/remotes/
directory, like this:
the remote repository URL in the local repository's config file
like this:
------------------------------------------------
$ mkdir -p .git/remotes/
$ cat >.git/remotes/linus <<\EOF
URL: http://www.kernel.org/pub/scm/git/git.git/
EOF
------------------------------------------------
and use the filename to `git pull` instead of the full URL.
The URL specified in such file can even be a prefix
of a full URL, like this:
------------------------------------------------
$ cat >.git/remotes/jgarzik <<\EOF
URL: http://www.kernel.org/pub/scm/linux/git/jgarzik/
EOF
$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
------------------------------------------------
and use the "linus" keyword with `git pull` instead of the full URL.
Examples.
. `git pull linus`
. `git pull linus tag v0.99.1`
. `git pull jgarzik/netdev-2.6.git/ e100`
the above are equivalent to:
. `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD`
. `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1`
. `git pull http://www.kernel.org/pub/.../jgarzik/netdev-2.6.git e100`
How does the merge work?
@ -1546,7 +1521,8 @@ on that project and has an own "public repository" goes like this:
1. Prepare your work repository, by `git clone` the public
repository of the "project lead". The URL used for the
initial cloning is stored in `.git/remotes/origin`.
initial cloning is stored in the remote.origin.url
configuration variable.
2. Prepare a public repository accessible to others, just like
the "project lead" person does.
@ -1586,14 +1562,15 @@ like this:
1. Prepare your work repository, by `git clone` the public
repository of the "project lead" (or a "subsystem
maintainer", if you work on a subsystem). The URL used for
the initial cloning is stored in `.git/remotes/origin`.
the initial cloning is stored in the remote.origin.url
configuration variable.
2. Do your work in your repository on 'master' branch.
3. Run `git fetch origin` from the public repository of your
upstream every once in a while. This does only the first
half of `git pull` but does not merge. The head of the
public repository is stored in `.git/refs/heads/origin`.
public repository is stored in `.git/refs/remotes/origin/master`.
4. Use `git cherry origin` to see which ones of your patches
were accepted, and/or use `git rebase origin` to port your
@ -1681,11 +1658,11 @@ $ git reset --hard master~2
You can make sure 'git show-branch' matches the state before
those two 'git merge' you just did. Then, instead of running
two 'git merge' commands in a row, you would pull these two
two 'git merge' commands in a row, you would merge these two
branch heads (this is known as 'making an Octopus'):
------------
$ git pull . commit-fix diff-fix
$ git merge commit-fix diff-fix
$ git show-branch
! [commit-fix] Fix commit message normalization.
! [diff-fix] Fix rename detection.
@ -1701,7 +1678,7 @@ $ git show-branch
Note that you should not do Octopus because you can. An octopus
is a valid thing to do and often makes it easier to view the
commit history if you are pulling more than two independent
commit history if you are merging more than two independent
changes at the same time. However, if you have merge conflicts
with any of the branches you are merging in and need to hand
resolve, that is an indication that the development happened in

2
Documentation/cvs-migration.txt
View File

@ -36,7 +36,7 @@ them first before running git pull.
================================
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
command; see `git config -l` and the gitlink:git-config[1] man
page for details.
================================

4
Documentation/diff-options.txt
View File

@ -58,6 +58,10 @@
Turn off rename detection, even when the configuration
file gives the default to do so.
--check::
Warn if changes introduce trailing whitespace
or an indent that uses a space before a tab.
--full-index::
Instead of the first handful characters, show full
object name of pre- and post-image blob on the "index"

11
Documentation/everyday.txt
View File

@ -28,7 +28,7 @@ Everybody uses these commands to maintain git repositories.
* gitlink:git-init[1] or gitlink:git-clone[1] to create a
new repository.
* gitlink:git-fsck-objects[1] to check the repository for errors.
* gitlink:git-fsck[1] to check the repository for errors.
* gitlink:git-prune[1] to remove unused objects in the repository.
@ -43,7 +43,7 @@ Examples
Check health and remove cruft.::
+
------------
$ git fsck-objects <1>
$ git fsck <1>
$ git count-objects <2>
$ git repack <3>
$ git gc <4>
@ -148,8 +148,7 @@ modification will be caught if you do `git 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. You can also use
`git pull . alsa-audio`, i.e. pull from the local repository.
<10> merge a topic branch into your master branch.
<11> review commit logs; other forms to limit output can be
combined and include `\--max-count=10` (show 10 commits),
`\--until=2005-12-10`, etc.
@ -213,12 +212,12 @@ Push into another repository.::
------------
satellite$ git clone mothership:frotz frotz <1>
satellite$ cd frotz
satellite$ git repo-config --get-regexp '^(remote|branch)\.' <2>
satellite$ git 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 \
satellite$ git config remote.origin.push \
master:refs/remotes/satellite/master <3>
satellite$ edit/compile/test/commit
satellite$ git push origin <4>

6
Documentation/git-add.txt
View File

@ -7,7 +7,7 @@ git-add - Add file contents to the changeset to be committed next
SYNOPSIS
--------
'git-add' [-n] [-v] [-f] [--interactive] [--] <file>...
'git-add' [-n] [-v] [-f] [--interactive | -i] [--] <file>...
DESCRIPTION
-----------
@ -52,7 +52,7 @@ OPTIONS
-f::
Allow adding otherwise ignored files.
\--interactive::
\i, \--interactive::
Add modified contents in the working tree interactively to
the index.
@ -83,7 +83,7 @@ git-add git-*.sh::
Interactive mode
----------------
When the command enters the interactive mode, it shows the
output of the 'status' subcommand, and then goes into ints
output of the 'status' subcommand, and then goes into its
interactive command loop.
The command loop shows the list of subcommands available, and

2
Documentation/git-am.txt
View File

@ -3,7 +3,7 @@ git-am(1)
NAME
----
git-am - Apply a series of patches in a mailbox
git-am - Apply a series of patches from a mailbox
SYNOPSIS

2
Documentation/git-apply.txt
View File

@ -3,7 +3,7 @@ git-apply(1)
NAME
----
git-apply - Apply patch on a git index file and a work tree
git-apply - Apply a patch on a git index file and a working tree
SYNOPSIS

3
Documentation/git-applypatch.txt
View File

@ -12,6 +12,9 @@ SYNOPSIS
DESCRIPTION
-----------
This is usually not what an end user wants to run directly. See
gitlink:git-am[1] instead.
Takes three files <msg>, <patch>, and <info> prepared from an
e-mail message by 'git-mailinfo', and creates a commit. It is
usually not necessary to use this command directly.

2
Documentation/git-archive.txt
View File

@ -3,7 +3,7 @@ git-archive(1)
NAME
----
git-archive - Creates a archive of the files in the named tree
git-archive - Creates an archive of files from a named tree
SYNOPSIS

2
Documentation/git-bisect.txt
View File

@ -3,7 +3,7 @@ git-bisect(1)
NAME
----
git-bisect - Find the change that introduced a bug
git-bisect - Find the change that introduced a bug by binary search
SYNOPSIS

60
Documentation/git-blame.txt
View File

@ -8,7 +8,7 @@ git-blame - Show what revision and author last modified each line of a file
SYNOPSIS
--------
[verse]
'git-blame' [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>]
'git-blame' [-c] [-l] [-t] [-f] [-n] [-p] [--incremental] [-L n,m] [-S <revs-file>]
[-M] [-C] [-C] [--since=<date>] [<rev>] [--] <file>
DESCRIPTION
@ -24,7 +24,7 @@ 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
development history for when a code snippet occurred 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:
@ -63,6 +63,10 @@ OPTIONS
-p, --porcelain::
Show in a format designed for machine consumption.
--incremental::
Show the result incrementally 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
@ -89,7 +93,7 @@ THE PORCELAIN FORMAT
--------------------
In this format, each line is output after a header; the
header at the minumum has the first line which has:
header at the minimum 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;
@ -112,15 +116,18 @@ header, prefixed by a TAB. This is to allow adding more
header elements later.
SPECIFIYING RANGES
------------------
SPECIFYING 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:
ll. 40-60 for file `foo`, you can use `-L` option like these
(they mean the same thing -- both ask for 21 lines starting at
line 40):
git blame -L 40,60 foo
git blame -L 40,+21 foo
Also you can use regular expression to specify the line range.
@ -155,6 +162,47 @@ parents, using `commit{caret}!` notation:
git blame -C -C -f $commit^! -- foo
INCREMENTAL OUTPUT
------------------
When called with `--incremental` option, the command outputs the
result as it is built. The output generally will talk about
lines touched by more recent commits first (i.e. the lines will
be annotated out of order) and is meant to be used by
interactive viewers.
The output format is similar to the Porcelain format, but it
does not contain the actual lines from the file that is being
annotated.
. Each blame entry always starts with a line of:
<40-byte hex sha1> <sourceline> <resultline> <num_lines>
+
Line numbers count from 1.
. The first time that commit shows up in the stream, it has various
other information about it printed out with a one-word tag at the
beginning of each line about that "extended commit info" (author,
email, committer, dates, summary etc).
. Unlike Porcelain format, the filename information is always
given and terminates the entry:
"filename" <whitespace-quoted-filename-goes-here>
+
and thus it's really quite easy to parse for some line- and word-oriented
parser (which should be quite natural for most scripting languages).
+
[NOTE]
For people who do parsing: to make it more robust, just ignore any
lines in between the first and last one ("<sha1>" and "filename" lines)
where you don't recognize the tag-words (or care about that particular
one) at the beginning of the "extended information" lines. That way, if
there is ever added information (like the commit encoding or extended
commit commentary), a blame viewer won't ever care.
SEE ALSO
--------
gitlink:git-annotate[1]

4
Documentation/git-branch.txt
View File

@ -3,7 +3,7 @@ git-branch(1)
NAME
----
git-branch - List, create, or delete branches.
git-branch - List, create, or delete branches
SYNOPSIS
--------
@ -74,7 +74,7 @@ OPTIONS
List both remote-tracking branches and local branches.
-v::
Show sha1 and commit subjectline for each head.
Show sha1 and commit subject line for each head.
--abbrev=<length>::
Alter minimum display length for sha1 in output listing,

2
Documentation/git-cat-file.txt
View File

@ -3,7 +3,7 @@ git-cat-file(1)
NAME
----
git-cat-file - Provide content or type information for repository objects
git-cat-file - Provide content or type/size information for repository objects
SYNOPSIS

2
Documentation/git-checkout-index.txt
View File

@ -3,7 +3,7 @@ git-checkout-index(1)
NAME
----
git-checkout-index - Copy files from the index to the working directory
git-checkout-index - Copy files from the index to the working tree
SYNOPSIS

54
Documentation/git-checkout.txt
View File

@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<branch>]
'git-checkout' [-m] [<branch>] <paths>...
'git-checkout' [<branch>] <paths>...
DESCRIPTION
-----------
@ -63,7 +63,57 @@ and mark the resolved paths with `git update-index`.
<branch>::
Branch to checkout; may be any object ID that resolves to a
commit. Defaults to HEAD.
commit. Defaults to HEAD.
+
When this parameter names a non-branch (but still a valid commit object),
your HEAD becomes 'detached'.
Detached HEAD
-------------
It is sometimes useful to be able to 'checkout' a commit that is
not at the tip of one of your branches. The most obvious
example is to check out the commit at a tagged official release
point, like this:
------------
$ git checkout v2.6.18
------------
Earlier versions of git did not allow this and asked you to
create a temporary branch using `-b` option, but starting from
version 1.5.0, the above command 'detaches' your HEAD from the
current branch and directly point at the commit named by the tag
(`v2.6.18` in the above example).
You can use usual git commands while in this state. You can use
`git-reset --hard $othercommit` to further move around, for
example. You can make changes and create a new commit on top of
a detached HEAD. You can even create a merge by using `git
merge $othercommit`.
The state you are in while your HEAD is detached is not recorded
by any branch (which is natural --- you are not on any branch).
What this means is that you can discard your temporary commits
and merges by switching back to an existing branch (e.g. `git
checkout master`), and a later `git prune` or `git gc` would
garbage-collect them.
The command would refuse to switch back to make sure that you do
not discard your temporary state by mistake when your detached
HEAD is not pointed at by any existing ref. If you did want to
save your state (e.g. "I was interested in the fifth commit from
the top of 'master' branch", or "I made two commits to fix minor
bugs while on a detached HEAD" -- and if you do not want to lose
these facts), you can create a new branch and switch to it with
`git checkout -b newbranch` so that you can keep building on
that state, or tag it first so that you can come back to it
later and switch to the branch you wanted to switch to with `git
tag that_state; git checkout master`. On the other hand, if you
did want to discard the temporary state, you can give `-f`
option (e.g. `git checkout -f master`) to override this
behaviour.
EXAMPLES

2
Documentation/git-cherry-pick.txt
View File

@ -19,6 +19,8 @@ OPTIONS
-------
<commit>::
Commit to cherry-pick.
For a more complete list of ways to spell commits, see
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
-e|--edit::
With this option, `git-cherry-pick` will let you edit the commit

2
Documentation/git-clone.txt
View File

@ -3,7 +3,7 @@ git-clone(1)
NAME
----
git-clone - Clones a repository
git-clone - Clones a repository into a new directory
SYNOPSIS

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

@ -3,7 +3,7 @@ git-commit-tree(1)
NAME
----
git-commit-tree - Creates a new commit object
git-commit-tree - Create a new commit object
SYNOPSIS
@ -12,6 +12,9 @@ SYNOPSIS
DESCRIPTION
-----------
This is usually not what an end user wants to run directly. See
gitlink:git-commit[1] instead.
Creates a new commit object based on the provided tree object and
emits the new commit object id on stdout. If no parent is given then
it is considered to be an initial tree.

19
Documentation/git-commit.txt
View File

@ -3,13 +3,13 @@ git-commit(1)
NAME
----
git-commit - Record your changes
git-commit - Record changes to the repository
SYNOPSIS
--------
[verse]
'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
[--no-verify] [--amend] [-e] [--author <author>]
'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg> |
--amend] [--no-verify] [-e] [--author <author>]
[--] [[-i | -o ]<file>...]
DESCRIPTION
@ -111,7 +111,7 @@ but can be used to amend a merge commit.
are concluding a conflicted merge.
-q|--quiet::
Supress commit summary message.
Suppress commit summary message.
\--::
Do not interpret any more arguments as options.
@ -142,11 +142,6 @@ $ 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
@ -223,6 +218,12 @@ refuses to run when given pathnames (but see `-i` option).
DISCUSSION
----------
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 commit in the body.
include::i18n.txt[]
ENVIRONMENT VARIABLES

227
Documentation/git-config.txt Normal file
View File

@ -0,0 +1,227 @@
git-config(1)
=============
NAME
----
git-config - Get and set repository or global options
SYNOPSIS
--------
[verse]
'git-config' [--global] [type] name [value [value_regex]]
'git-config' [--global] [type] --add name value
'git-config' [--global] [type] --replace-all name [value [value_regex]]
'git-config' [--global] [type] --get name [value_regex]
'git-config' [--global] [type] --get-all name [value_regex]
'git-config' [--global] [type] --unset name [value_regex]
'git-config' [--global] [type] --unset-all name [value_regex]
'git-config' [--global] -l | --list
DESCRIPTION
-----------
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.
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
prepend a single exclamation mark in front (see EXAMPLES).
The type specifier can be either '--int' or '--bool', which will make
'git-config' ensure that the variable(s) are of the given type and
convert the value to the canonical form (simple decimal number for int,
a "true" or "false" string for bool). If no type specifier is passed,
no checks or transformations are performed on the value.
This command will fail if:
. The .git/config file is invalid,
. 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,
. you try to unset/set an option for which multiple lines match, or
. you use --global option without $HOME being properly set.
OPTIONS
-------
--replace-all::
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). 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
is not exactly one.
--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 config file.
--unset-all::
Remove all matching lines from config file.
-l, --list::
List all variables set in config file.
--bool::
git-config will ensure that the output is "true" or "false"
--int::
git-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
-----------
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
configuration files, this will cause it to take the configuration
from the global configuration file in addition to the given file.
EXAMPLE
-------
Given a .git/config like this:
#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#
; core variables
[core]
; Don't trust file modes
filemode = false
; Our diff algorithm
[diff]
external = "/usr/local/bin/gnu-diff -u"
renames = true
; Proxy settings
[core]
gitproxy="ssh" for "ssh://kernel.org/"
gitproxy="proxy-command" for kernel.org
gitproxy="myprotocol-command" for "my://"
gitproxy=default-proxy ; for all the rest
you can set the filemode to true with
------------
% git config core.filemode true
------------
The hypothetical proxy command entries actually have a postfix to discern
what URL they apply to. Here is how to change the entry for kernel.org
to "ssh".
------------
% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
------------
This makes sure that only the key/value pair for kernel.org is replaced.
To delete the entry for renames, do
------------
% git config --unset diff.renames
------------
If you want to delete an entry for a multivar (like core.gitproxy above),
you have to provide a regex matching the value of exactly one line.
To query the value for a given key, do
------------
% git config --get core.filemode
------------
or
------------
% git config core.filemode
------------
or, to query a multivar:
------------
% git config --get core.gitproxy "for kernel.org$"
------------
If you want to know all the values for a multivar, do:
------------
% git config --get-all core.gitproxy
------------
If you like to live dangerous, you can replace *all* core.gitproxy by a
new one with
------------
% git config --replace-all core.gitproxy ssh
------------
However, if you really only want to replace the line for the default proxy,
i.e. the one without a "for ..." postfix, do something like this:
------------
% git config core.gitproxy ssh '! for '
------------
To actually match only values with an exclamation mark, you have to
------------
% git config section.key value '[!]'
------------
To add a new proxy, without altering any of the existing ones, use
------------
% git config core.gitproxy '"proxy" for example.com'
------------
include::config.txt[]
Author
------
Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
Documentation
--------------
Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite

2
Documentation/git-count-objects.txt
View File

@ -3,7 +3,7 @@ git-count-objects(1)
NAME
----
git-count-objects - Reports on unpacked objects
git-count-objects - Count unpacked number of objects and their disk consumption
SYNOPSIS
--------

2
Documentation/git-cvsexportcommit.txt
View File

@ -3,7 +3,7 @@ git-cvsexportcommit(1)
NAME
----
git-cvsexportcommit - Export a commit to a CVS checkout
git-cvsexportcommit - Export a single commit to a CVS checkout
SYNOPSIS

4
Documentation/git-cvsimport.txt
View File

@ -3,7 +3,7 @@ git-cvsimport(1)
NAME
----
git-cvsimport - Import a CVS repository into git
git-cvsimport - Salvage your data out of another SCM people love to hate
SYNOPSIS
@ -97,7 +97,7 @@ If you need to pass multiple options, separate them with a comma.
Substitute the character "/" in branch names with <subst>
-A <author-conv-file>::
CVS by default uses the unix username when writing its
CVS by default uses the Unix username when writing its
commit logs. Using this option and an author-conv-file
in this format

4
Documentation/git-daemon.txt
View File

@ -131,14 +131,14 @@ 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=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-override=service, --forbid-override=service::
Allow/forbid overriding the site-wide default with per
repository configuration. By default, all the services
are overridable.

61
Documentation/git-describe.txt
View File

@ -14,8 +14,8 @@ DESCRIPTION
-----------
The command finds the most recent tag that is reachable from a
commit, and if the commit itself is pointed at by the tag, shows
the tag. Otherwise, it suffixes the tag name with abbreviated
object name of the commit.
the tag. Otherwise, it suffixes the tag name with the number of
additional commits and the abbreviated object name of the commit.
OPTIONS
@ -35,6 +35,16 @@ OPTIONS
Instead of using the default 8 hexadecimal digits as the
abbreviated object name, use <n> digits.
--candidates=<n>::
Instead of considering only the 10 most recent tags as
candidates to describe the input committish consider
up to <n> candidates. Increasing <n> above 10 will take
slightly longer but may produce a more accurate result.
--debug::
Verbosely display information about the searching strategy
being employed to standard error. The tag name will still
be printed to standard out.
EXAMPLES
--------
@ -42,12 +52,18 @@ EXAMPLES
With something like git.git current tree, I get:
[torvalds@g5 git]$ git-describe parent
v1.0.4-g2414721b
v1.0.4-14-g2414721
i.e. the current head of my "parent" branch is based on v1.0.4,
but since it has a few commits on top of that, it has added the
git hash of the thing to the end: "-g" + 8-char shorthand for
the commit `2414721b194453f058079d897d13c4e377f92dc6`.
but since it has a handful commits on top of that,
describe has added the number of additional commits ("14") and
an abbreviated object name for the commit itself ("2414721")
at the end.
The number of additional commits is the number
of commits which would be displayed by "git log v1.0.4..parent".
The hash suffix is "-g" + 7-char abbreviation for the tip commit
of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
Doing a "git-describe" on a tag-name will just show the tag name:
@ -58,16 +74,43 @@ With --all, the command can use branch heads as references, so
the output shows the reference path as well:
[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
tags/v1.0.0-g975b
tags/v1.0.0-21-g975b
[torvalds@g5 git]$ git describe --all HEAD^
heads/lt/describe-g975b
heads/lt/describe-7-g975b
With --abbrev set to 0, the command can be used to find the
closest tagname without any suffix:
[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
tags/v1.0.0
SEARCH STRATEGY
---------------
For each committish supplied "git describe" will first look for
a tag which tags exactly that commit. Annotated tags will always
be preferred over lightweight tags, and tags with newer dates will
always be preferred over tags with older dates. If an exact match
is found, its name will be output and searching will stop.
If an exact match was not found "git describe" will walk back
through the commit history to locate an ancestor commit which
has been tagged. The ancestor's tag will be output along with an
abbreviation of the input committish's SHA1.
If multiple tags were found during the walk then the tag which
has the fewest commits different from the input committish will be
selected and output. Here fewest commits different is defined as
the number of commits which would be shown by "git log tag..input"
will be the smallest number of commits possible.
Author
------
Written by Linus Torvalds <torvalds@osdl.org>, but somewhat
butchered by Junio C Hamano <junkio@cox.net>
butchered by Junio C Hamano <junkio@cox.net>. Later significantly
updated by Shawn Pearce <spearce@spearce.org>.
Documentation
--------------

2
Documentation/git-diff-stages.txt
View File

@ -3,7 +3,7 @@ git-diff-stages(1)
NAME
----
git-diff-stages - Compares content and mode of blobs between stages in an unmerged index file
git-diff-stages - Compares two merge stages in the index
SYNOPSIS

3
Documentation/git-diff.txt
View File

@ -47,6 +47,9 @@ 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>.
For a more complete list of ways to spell <commit>, see
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
OPTIONS
-------

27
Documentation/git-fetch-pack.txt
View File

@ -8,10 +8,13 @@ git-fetch-pack - Receive missing objects from another repository
SYNOPSIS
--------
'git-fetch-pack' [-q] [-k] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...]
'git-fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--upload-pack=<git-upload-pack>] [--depth=<n>] [-v] [<host>:]<directory> [<refs>...]
DESCRIPTION
-----------
Usually you would want to use gitlink:git-fetch[1] which is a
higher level wrapper of this command instead.
Invokes 'git-upload-pack' on a potentially remote repository,
and asks it to send objects missing from this repository, to
update the named heads. The list of commits available locally
@ -25,17 +28,24 @@ have a common ancestor commit.
OPTIONS
-------
-q::
\--all::
Fetch all remote refs.
\--quiet, \-q::
Pass '-q' flag to 'git-unpack-objects'; this makes the
cloning process less verbose.
-k::
\--keep, \-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. If provided twice then the pack is
locked against repacking.
--exec=<git-upload-pack>::
\--thin::
Spend extra cycles to minimize the number of objects to be sent.
Use it on slower connection.
\--upload-pack=<git-upload-pack>::
Use this to specify the path to 'git-upload-pack' on the
remote side, if is not found on your $PATH.
Installations of sshd ignores the user's environment
@ -47,6 +57,15 @@ OPTIONS
shells by having a lean .bashrc file (they set most of
the things up in .bash_profile).
\--exec=<git-upload-pack>::
Same as \--upload-pack=<git-upload-pack>.
\--depth=<n>::
Limit fetching to ancestor-chains not longer than n.
\-v::
Run verbosely.
<host>::
A remote host that houses the repository. When this
part is specified, 'git-upload-pack' is invoked via

2
Documentation/git-fetch.txt
View File

@ -3,7 +3,7 @@ git-fetch(1)
NAME
----
git-fetch - Download objects and a head from another repository
git-fetch - Download objects and refs from another repository
SYNOPSIS

6
Documentation/git-for-each-ref.txt
View File

@ -7,7 +7,7 @@ git-for-each-ref - Output information on each ref
SYNOPSIS
--------
'git-for-each-ref' [--count=<count>]\* [--shell|--perl|--python] [--sort=<key>]\* [--format=<format>] [<pattern>]
'git-for-each-ref' [--count=<count>]\* [--shell|--perl|--python|--tcl] [--sort=<key>]\* [--format=<format>] [<pattern>]
DESCRIPTION
-----------
@ -15,7 +15,7 @@ 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>`
showing that many refs. The interpolated values in `<format>`
can optionally be quoted as string literals in the specified
host language allowing their direct evaluation in that language.
@ -49,7 +49,7 @@ OPTIONS
using fnmatch(3). Refs that do not match the pattern
are not shown.
--shell, --perl, --python::
--shell, --perl, --python, --tcl::
If given, strings that substitute `%(fieldname)`
placeholders are quoted as string literals suitable for
the specified host language. This is meant to produce

33
Documentation/git-format-patch.txt
View File

@ -11,7 +11,8 @@ SYNOPSIS
[verse]
'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [--thread]
[-s | --signoff] [--diff-options] [--start-number <n>]
[--in-reply-to=Message-Id]
[--in-reply-to=Message-Id] [--suffix=.<sfx>]
[--ignore-if-in-upstream]
<since>[..<until>]
DESCRIPTION
@ -20,7 +21,9 @@ DESCRIPTION
Prepare each commit between <since> and <until> with its patch in
one file per commit, formatted to resemble UNIX mailbox format.
If ..<until> is not specified, the head of the current working
tree is implied.
tree is implied. For a more complete list of ways to spell
<since> and <until>, see "SPECIFYING REVISIONS" section in
gitlink:git-rev-parse[1].
The output of this command is convenient for e-mail submission or
for use with gitlink:git-am[1].
@ -78,13 +81,34 @@ OPTIONS
reply to the given Message-Id, which avoids breaking threads to
provide a new patch series.
--ignore-if-in-upstream::
Do not include a patch that matches a commit in
<until>..<since>. This will examine all patches reachable
from <since> but not from <until> and compare them with the
patches being generated, and any patch that matches is
ignored.
--suffix=.<sfx>::
Instead of using `.patch` as the suffix for generated
filenames, use specifed suffix. A common alternative is
`--suffix=.txt`.
+
Note that you would need to include the leading dot `.` if you
want a filename like `0001-description-of-my-change.patch`, and
the first letter does not have to be a dot. Leaving it empty would
not add any suffix.
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each
message in the repository configuration as follows:
message in the repository configuration. Also you can specify
the default suffix different from the built-in one:
------------
[format]
headers = "Organization: git-foo\n"
suffix = .txt
------------
EXAMPLES
@ -109,6 +133,9 @@ git-format-patch -M -B origin::
understand renaming patches, so use it only when you know
the recipient uses git to apply your patch.
git-format-patch -3::
Extract three topmost commits from the current branch
and format them as e-mailable patches.
See Also
--------

128
Documentation/git-fsck-objects.txt
View File

@ -8,132 +8,10 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
SYNOPSIS
--------
[verse]
'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache]
[--full] [--strict] [<object>*]
'git-fsck-objects' ...
DESCRIPTION
-----------
Verifies the connectivity and validity of the objects in the database.
OPTIONS
-------
<object>::
An object to treat as the head of an unreachability trace.
+
If no objects are given, git-fsck-objects defaults to using the
index file and all SHA1 references in .git/refs/* as heads.
--unreachable::
Print out objects that exist but that aren't readable from any
of the reference nodes.
--root::
Report root nodes.
--tags::
Report tags.
--cache::
Consider any object recorded in the index also as a head node for
an unreachability trace.
--full::
Check not just objects in GIT_OBJECT_DIRECTORY
($GIT_DIR/objects), but also the ones found in alternate
object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES
or $GIT_DIR/objects/info/alternates,
and in packed git archives found in $GIT_DIR/objects/pack
and corresponding pack subdirectories in alternate
object pools.
--strict::
Enable more strict checking, namely to catch a file mode
recorded with g+w bit set, which was created by older
versions of git. Existing repositories, including the
Linux kernel, git itself, and sparse repository have old
objects that triggers this check, but it is recommended
to check new projects with this flag.
It tests SHA1 and general object sanity, and it does full tracking of
the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
'--unreachable' flag it will also print out objects that exist but
that aren't readable from any of the specified head nodes.
So for example
git-fsck-objects --unreachable HEAD $(cat .git/refs/heads/*)
will do quite a _lot_ of verification on the tree. There are a few
extra validity tests to be added (make sure that tree objects are
sorted properly etc), but on the whole if "git-fsck-objects" is happy, you
do have a valid tree.
Any corrupt objects you will have to find in backups or other archives
(i.e., you can just remove them and do an "rsync" with some other site in
the hopes that somebody else has the object you have corrupted).
Of course, "valid tree" doesn't mean that it wasn't generated by some
evil person, and the end result might be crap. git is a revision
tracking system, not a quality assurance system ;)
Extracted Diagnostics
---------------------
expect dangling commits - potential heads - due to lack of head information::
You haven't specified any nodes as heads so it won't be
possible to differentiate between un-parented commits and
root nodes.
missing sha1 directory '<dir>'::
The directory holding the sha1 objects is missing.
unreachable <type> <object>::
The <type> object <object>, isn't actually referred to directly
or indirectly in any of the trees or commits seen. This can
mean that there's another root node that you're not specifying
or that the tree is corrupt. If you haven't missed a root node
then you might as well delete unreachable nodes since they
can't be used.
missing <type> <object>::
The <type> object <object>, is referred to but isn't present in
the database.
dangling <type> <object>::
The <type> object <object>, is present in the database but never
'directly' used. A dangling commit could be a root node.
warning: git-fsck-objects: tree <tree> has full pathnames in it::
And it shouldn't...
sha1 mismatch <object>::
The database has an object who's sha1 doesn't match the
database value.
This indicates a serious data integrity problem.
Environment Variables
---------------------
GIT_OBJECT_DIRECTORY::
used to specify the object database root (usually $GIT_DIR/objects)
GIT_INDEX_FILE::
used to specify the index file of the index
GIT_ALTERNATE_OBJECT_DIRECTORIES::
used to specify additional object database roots (usually unset)
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-fsck[1]. Please refer to the
documentation of that command.

139
Documentation/git-fsck.txt Normal file
View File

@ -0,0 +1,139 @@
git-fsck(1)
===========
NAME
----
git-fsck - Verifies the connectivity and validity of the objects in the database
SYNOPSIS
--------
[verse]
'git-fsck' [--tags] [--root] [--unreachable] [--cache]
[--full] [--strict] [<object>*]
DESCRIPTION
-----------
Verifies the connectivity and validity of the objects in the database.
OPTIONS
-------
<object>::
An object to treat as the head of an unreachability trace.
+
If no objects are given, git-fsck defaults to using the
index file and all SHA1 references in .git/refs/* as heads.
--unreachable::
Print out objects that exist but that aren't readable from any
of the reference nodes.
--root::
Report root nodes.
--tags::
Report tags.
--cache::
Consider any object recorded in the index also as a head node for
an unreachability trace.
--full::
Check not just objects in GIT_OBJECT_DIRECTORY
($GIT_DIR/objects), but also the ones found in alternate
object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES
or $GIT_DIR/objects/info/alternates,
and in packed git archives found in $GIT_DIR/objects/pack
and corresponding pack subdirectories in alternate
object pools.
--strict::
Enable more strict checking, namely to catch a file mode
recorded with g+w bit set, which was created by older
versions of git. Existing repositories, including the
Linux kernel, git itself, and sparse repository have old
objects that triggers this check, but it is recommended
to check new projects with this flag.
It tests SHA1 and general object sanity, and it does full tracking of
the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
'--unreachable' flag it will also print out objects that exist but
that aren't readable from any of the specified head nodes.
So for example
git-fsck --unreachable HEAD $(cat .git/refs/heads/*)
will do quite a _lot_ of verification on the tree. There are a few
extra validity tests to be added (make sure that tree objects are
sorted properly etc), but on the whole if "git-fsck" is happy, you
do have a valid tree.
Any corrupt objects you will have to find in backups or other archives
(i.e., you can just remove them and do an "rsync" with some other site in
the hopes that somebody else has the object you have corrupted).
Of course, "valid tree" doesn't mean that it wasn't generated by some
evil person, and the end result might be crap. git is a revision
tracking system, not a quality assurance system ;)
Extracted Diagnostics
---------------------
expect dangling commits - potential heads - due to lack of head information::
You haven't specified any nodes as heads so it won't be
possible to differentiate between un-parented commits and
root nodes.
missing sha1 directory '<dir>'::
The directory holding the sha1 objects is missing.
unreachable <type> <object>::
The <type> object <object>, isn't actually referred to directly
or indirectly in any of the trees or commits seen. This can
mean that there's another root node that you're not specifying
or that the tree is corrupt. If you haven't missed a root node
then you might as well delete unreachable nodes since they
can't be used.
missing <type> <object>::
The <type> object <object>, is referred to but isn't present in
the database.
dangling <type> <object>::
The <type> object <object>, is present in the database but never
'directly' used. A dangling commit could be a root node.
warning: git-fsck: tree <tree> has full pathnames in it::
And it shouldn't...
sha1 mismatch <object>::
The database has an object who's sha1 doesn't match the
database value.
This indicates a serious data integrity problem.
Environment Variables
---------------------
GIT_OBJECT_DIRECTORY::
used to specify the object database root (usually $GIT_DIR/objects)
GIT_INDEX_FILE::
used to specify the index file of the index
GIT_ALTERNATE_OBJECT_DIRECTORIES::
used to specify additional object database roots (usually unset)
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

19
Documentation/git-gc.txt
View File

@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
SYNOPSIS
--------
'git-gc'
'git-gc' [--prune]
DESCRIPTION
-----------
@ -21,6 +21,21 @@ Users are encouraged to run this task on a regular basis within
each repository to maintain good disk space utilization and good
operating performance.
OPTIONS
-------
--prune::
Usually `git-gc` packs refs, expires old reflog entries,
packs loose objects,
and removes old 'rerere' records. Removal
of unreferenced loose objects is an unsafe operation
while other git operations are in progress, so it is not
done by default. Pass this option if you want it, and only
when you know nobody else is creating new objects in the
repository at the same time (e.g. never use this option
in a cron script).
Configuration
-------------
@ -35,7 +50,7 @@ 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
commits prior to the amend or rebase occurring. Since these changes
are not part of the current project most users will want to expire
them sooner. This option defaults to '30 days'.

2
Documentation/git-grep.txt
View File

@ -91,7 +91,7 @@ OPTIONS
combined by 'or'.
--and | --or | --not | ( | )::
Specify how multiple patterns are combined using boolean
Specify how multiple patterns are combined using Boolean
expressions. `--or` is the default operator. `--and` has
higher precedence than `--or`. `-e` has to be used for all
patterns.

2
Documentation/git-hash-object.txt
View File

@ -3,7 +3,7 @@ git-hash-object(1)
NAME
----
git-hash-object - Computes object ID and optionally creates a blob from a file
git-hash-object - Compute object ID and optionally creates a blob from a file
SYNOPSIS

2
Documentation/git-http-fetch.txt
View File

@ -3,7 +3,7 @@ git-http-fetch(1)
NAME
----
git-http-fetch - downloads a remote git repository via HTTP
git-http-fetch - Download from a remote git repository via HTTP
SYNOPSIS

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

@ -3,7 +3,7 @@ git-http-push(1)
NAME
----
git-http-push - Push missing objects using HTTP/DAV
git-http-push - Push objects over HTTP/DAV to another repository
SYNOPSIS

2
Documentation/git-init.txt
View File

@ -3,7 +3,7 @@ git-init(1)
NAME
----
git-init - Creates an empty git repository
git-init - Create an empty git repository or reinitialize an existing one
SYNOPSIS

2
Documentation/git-instaweb.txt
View File

@ -3,7 +3,7 @@ git-instaweb(1)
NAME
----
git-instaweb - instantly browse your working repository in gitweb
git-instaweb - Instantly browse your working repository in gitweb
SYNOPSIS
--------

2
Documentation/git-local-fetch.txt
View File

@ -3,7 +3,7 @@ git-local-fetch(1)
NAME
----
git-local-fetch - Duplicates another git repository on a local system
git-local-fetch - Duplicate another git repository on a local system
SYNOPSIS

5
Documentation/git-log.txt
View File

@ -27,13 +27,16 @@ OPTIONS
include::pretty-formats.txt[]
--max-count=<n>::
-<n>::
Limits the number of commits to show.
<since>..<until>::
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.
For a more complete list of ways to spell <since>
and <until>, see "SPECIFYING REVISIONS" section in
gitlink:git-rev-parse[1].
-p::
Show the change the commit introduces in a patch form.

2
Documentation/git-ls-files.txt
View File

@ -3,7 +3,7 @@ git-ls-files(1)
NAME
----
git-ls-files - Information about files in the index/working directory
git-ls-files - Show information about files in the index and the working tree
SYNOPSIS

2
Documentation/git-ls-remote.txt
View File

@ -29,7 +29,7 @@ OPTIONS
-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
SSH and where the SSH daemon does not use the PATH configured by the
user. Also see the '--exec' option for gitlink:git-peek-remote[1].
<repository>::

2
Documentation/git-ls-tree.txt
View File

@ -3,7 +3,7 @@ git-ls-tree(1)
NAME
----
git-ls-tree - Lists the contents of a tree object
git-ls-tree - List the contents of a tree object
SYNOPSIS

4
Documentation/git-mailinfo.txt
View File

@ -3,7 +3,7 @@ git-mailinfo(1)
NAME
----
git-mailinfo - Extracts patch from a single e-mail message
git-mailinfo - Extracts patch and authorship from a single e-mail message
SYNOPSIS
@ -18,7 +18,7 @@ writes the commit log message in <msg> file, and the patches in
<patch> file. The author name, e-mail and e-mail subject are
written out to the standard output to be used by git-applypatch
to create a commit. It is usually not necessary to use this
command directly.
command directly. See gitlink:git-am[1] instead.
OPTIONS

2
Documentation/git-mailsplit.txt
View File

@ -3,7 +3,7 @@ git-mailsplit(1)
NAME
----
git-mailsplit - Totally braindamaged mbox splitter program
git-mailsplit - Simple UNIX mbox splitter program
SYNOPSIS
--------

2
Documentation/git-merge-base.txt
View File

@ -3,7 +3,7 @@ git-merge-base(1)
NAME
----
git-merge-base - Finds as good a common ancestor as possible for a merge
git-merge-base - Find as good common ancestors as possible for a merge
SYNOPSIS

2
Documentation/git-merge-file.txt
View File

@ -3,7 +3,7 @@ git-merge-file(1)
NAME
----
git-merge-file - three-way file merge
git-merge-file - Run a three-way file merge
SYNOPSIS

2
Documentation/git-merge-index.txt
View File

@ -3,7 +3,7 @@ git-merge-index(1)
NAME
----
git-merge-index - Runs a merge for files needing merging
git-merge-index - Run a merge for files needing merging
SYNOPSIS

2
Documentation/git-merge-one-file.txt
View File

@ -3,7 +3,7 @@ git-merge-one-file(1)
NAME
----
git-merge-one-file - The standard helper program to use with "git-merge-index"
git-merge-one-file - The standard helper program to use with git-merge-index
SYNOPSIS

2
Documentation/git-merge.txt
View File

@ -3,7 +3,7 @@ git-merge(1)
NAME
----
git-merge - Grand Unified Merge Driver
git-merge - Join two or more development histories together
SYNOPSIS

2
Documentation/git-mv.txt
View File

@ -3,7 +3,7 @@ git-mv(1)
NAME
----
git-mv - Move or rename a file, directory or symlink
git-mv - Move or rename a file, a directory, or a symlink
SYNOPSIS

4
Documentation/git-pack-redundant.txt
View File

@ -3,7 +3,7 @@ git-pack-redundant(1)
NAME
----
git-pack-redundant - Program used to find redundant pack files
git-pack-redundant - Find redundant pack files
SYNOPSIS
@ -21,7 +21,7 @@ given will be ignored when checking which packs are required. This makes the
following command useful when wanting to remove packs which contain unreachable
objects.
git-fsck-objects --full --unreachable | cut -d ' ' -f3 | \
git-fsck --full --unreachable | cut -d ' ' -f3 | \
git-pack-redundant --all | xargs rm
OPTIONS

13
Documentation/git-pack-refs.txt
View File

@ -29,12 +29,23 @@ file and used if found.
Subsequent updates to branches always creates new file under
`$GIT_DIR/refs` hierarchy.
A recommended practice to deal with a repository with too many
refs is to pack its refs with `--all --prune` once, and
occasionally run `git-pack-refs \--prune`. Tags are by
definition stationary and are not expected to change. Branch
heads will be packed with the initial `pack-refs --all`, but
only the currently active branch heads will become unpacked,
and next `pack-refs` (without `--all`) will leave them
unpacked.
OPTIONS
-------
\--all::
The command by default packs all tags and leaves branch tips
The command by default packs all tags and refs that are already
packed, and leaves other refs
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

8
Documentation/git-parse-remote.txt
View File

@ -3,7 +3,7 @@ git-parse-remote(1)
NAME
----
git-parse-remote - Routines to help parsing $GIT_DIR/remotes/
git-parse-remote - Routines to help parsing remote repository access parameters
SYNOPSIS
@ -14,7 +14,8 @@ DESCRIPTION
-----------
This script is included in various scripts to supply
routines to parse files under $GIT_DIR/remotes/ and
$GIT_DIR/branches/.
$GIT_DIR/branches/ and configuration variables that are related
to fetching, pulling and pushing.
The primary entry points are:
@ -25,7 +26,8 @@ get_remote_refs_for_fetch::
(e.g. `refs/heads/foo`). When `<refspec>...` is empty
the returned list of refs consists of the defaults
for the given `<repo>`, if specified in
`$GIT_DIR/remotes/` or `$GIT_DIR/branches/`.
`$GIT_DIR/remotes/`, `$GIT_DIR/branches/`, or `remote.*.fetch`
configuration.
get_remote_refs_for_push::
Given the list of user-supplied `<repo> <refspec>...`,

2
Documentation/git-patch-id.txt
View File

@ -3,7 +3,7 @@ git-patch-id(1)
NAME
----
git-patch-id - Generate a patch ID
git-patch-id - Compute unique ID for a patch
SYNOPSIS
--------

9
Documentation/git-peek-remote.txt
View File

@ -3,12 +3,12 @@ git-peek-remote(1)
NAME
----
git-peek-remote - Lists the references in a remote repository
git-peek-remote - List the references in a remote repository
SYNOPSIS
--------
'git-peek-remote' [--exec=<git-upload-pack>] [<host>:]<directory>
'git-peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory>
DESCRIPTION
-----------
@ -17,7 +17,7 @@ stores them in the local repository under the same name.
OPTIONS
-------
--exec=<git-upload-pack>::
\--upload-pack=<git-upload-pack>::
Use this to specify the path to 'git-upload-pack' on the
remote side, if it is not found on your $PATH. Some
installations of sshd ignores the user's environment
@ -29,6 +29,9 @@ OPTIONS
shells, but prefer having a lean .bashrc file (they set most of
the things up in .bash_profile).
\--exec=<git-upload-pack>::
Same \--upload-pack=<git-upload-pack>.
<host>::
A remote host that houses the repository. When this
part is specified, 'git-upload-pack' is invoked via

3
Documentation/git-prune-packed.txt
View File

@ -3,8 +3,7 @@ git-prune-packed(1)
NAME
----
git-prune-packed - Program used to remove the extra object files that are now
residing in a pack file.
git-prune-packed - Remove extra objects that are already in pack files
SYNOPSIS

2
Documentation/git-prune.txt
View File

@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
This runs `git-fsck-objects --unreachable` using all the refs
This runs `git-fsck --unreachable` using all the refs
available in `$GIT_DIR/refs`, optionally with additional set of
objects specified on the command line, and prunes all
objects unreachable from any of these head objects from the object database.

9
Documentation/git-pull.txt
View File

@ -3,7 +3,7 @@ git-pull(1)
NAME
----
git-pull - Pull and merge from another repository or a local branch
git-pull - Fetch from and merge with another repository or a local branch
SYNOPSIS
@ -42,7 +42,7 @@ git pull, git pull origin::
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]
branch.<name>.merge options; see gitlink:git-config[1]
for details.
git pull origin next::
@ -52,7 +52,8 @@ git pull origin next::
git pull . fixes enhancements::
Bundle local branch `fixes` and `enhancements` on top of
the current branch, making an Octopus merge.
the current branch, making an Octopus merge. This `git pull .`
syntax is equivalent to `git merge`.
git pull -s ours . obsolete::
Merge local branch `obsolete` into the current branch,
@ -93,7 +94,7 @@ gitlink:git-reset[1].
SEE ALSO
--------
gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-repo-config[1]
gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-config[1]
Author

23
Documentation/git-push.txt
View File

@ -8,7 +8,7 @@ git-push - Update remote refs along with associated objects
SYNOPSIS
--------
'git-push' [--all] [--tags] [-f | --force] <repository> <refspec>...
'git-push' [--all] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]
DESCRIPTION
-----------
@ -67,12 +67,33 @@ the remote repository.
addition to refspecs explicitly listed on the command
line.
\--receive-pack=<git-receive-pack>::
Path to the 'git-receive-pack' program on the remote
end. Sometimes useful when pushing to a remote
repository over ssh, and you do not have the program in
a directory on the default $PATH.
\--exec=<git-receive-pack>::
Same as \--receive-pack=<git-receive-pack>.
-f, \--force::
Usually, the command refuses to update a remote ref that is
not a descendant of the local ref used to overwrite it.
This flag disables the check. This can cause the
remote repository to lose commits; use it with care.
\--repo=<repo>::
When no repository is specified the command defaults to
"origin"; this overrides it.
\--thin, \--no-thin::
These options are passed to `git-send-pack`. Thin
transfer spends extra cycles to minimize the number of
objects to be sent and meant to be used on slower connection.
-v::
Run verbosely.
include::urls.txt[]
Author

2
Documentation/git-rebase.txt
View File

@ -3,7 +3,7 @@ git-rebase(1)
NAME
----
git-rebase - Rebase local commits to a new head
git-rebase - Forward-port local commits to the updated upstream head
SYNOPSIS
--------

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

@ -3,7 +3,7 @@ git-receive-pack(1)
NAME
----
git-receive-pack - Receive what is pushed into it
git-receive-pack - Receive what is pushed into the repository
SYNOPSIS

2
Documentation/git-reflog.txt
View File

@ -9,7 +9,7 @@ git-reflog - Manage reflog information
SYNOPSIS
--------
[verse]
'git-reflog' expire [--dry-run]
'git-reflog' expire [--dry-run] [--stale-fix]
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...

4
Documentation/git-remote.txt
View File

@ -28,7 +28,7 @@ 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]).
gitlink:git-config[1]).
Examples
--------
@ -58,7 +58,7 @@ See Also
--------
gitlink:git-fetch[1]
gitlink:git-branch[1]
gitlink:git-repo-config[1]
gitlink:git-config[1]
Author
------

3
Documentation/git-repack.txt
View File

@ -3,8 +3,7 @@ git-repack(1)
NAME
----
git-repack - Script used to pack a repository from a collection of
objects into pack files.
git-repack - Pack unpacked objects in a repository
SYNOPSIS

219
Documentation/git-repo-config.txt
View File

@ -3,225 +3,16 @@ git-repo-config(1)
NAME
----
git-repo-config - Get and set repository or global options.
git-repo-config - Get and set repository or global options
SYNOPSIS
--------
[verse]
'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
'git-repo-config' ...
DESCRIPTION
-----------
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.
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
prepend a single exclamation mark in front (see EXAMPLES).
The type specifier can be either '--int' or '--bool', which will make
'git-repo-config' ensure that the variable(s) are of the given type and
convert the value to the canonical form (simple decimal number for int,
a "true" or "false" string for bool). If no type specifier is passed,
no checks or transformations are performed on the value.
This command will fail if:
. The .git/config file is invalid,
. 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,
. you try to unset/set an option for which multiple lines match, or
. you use --global option without $HOME being properly set.
OPTIONS
-------
--replace-all::
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). 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
is not exactly one.
--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 config file.
--unset-all::
Remove all matching lines from config file.
-l, --list::
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
-----------
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
configuration files, this will cause it to take the configuration
from the global configuration file in addition to the given file.
EXAMPLE
-------
Given a .git/config like this:
#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#
; core variables
[core]
; Don't trust file modes
filemode = false
; Our diff algorithm
[diff]
external = "/usr/local/bin/gnu-diff -u"
renames = true
; Proxy settings
[core]
gitproxy="ssh" for "ssh://kernel.org/"
gitproxy="proxy-command" for kernel.org
gitproxy="myprotocol-command" for "my://"
gitproxy=default-proxy ; for all the rest
you can set the filemode to true with
------------
% git repo-config core.filemode true
------------
The hypothetical proxy command entries actually have a postfix to discern
what URL they apply to. Here is how to change the entry for kernel.org
to "ssh".
------------
% git repo-config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
------------
This makes sure that only the key/value pair for kernel.org is replaced.
To delete the entry for renames, do
------------
% git repo-config --unset diff.renames
------------
If you want to delete an entry for a multivar (like core.gitproxy above),
you have to provide a regex matching the value of exactly one line.
To query the value for a given key, do
------------
% git repo-config --get core.filemode
------------
or
------------
% git repo-config core.filemode
------------
or, to query a multivar:
------------
% git repo-config --get core.gitproxy "for kernel.org$"
------------
If you want to know all the values for a multivar, do:
------------
% git repo-config --get-all core.gitproxy
------------
If you like to live dangerous, you can replace *all* core.gitproxy by a
new one with
------------
% git repo-config --replace-all core.gitproxy ssh
------------
However, if you really only want to replace the line for the default proxy,
i.e. the one without a "for ..." postfix, do something like this:
------------
% git repo-config core.gitproxy ssh '! for '
------------
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[]
Author
------
Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
Documentation
--------------
Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
This is a synonym for gitlink:git-config[1]. Please refer to the
documentation of that command.

14
Documentation/git-rerere.txt
View File

@ -3,7 +3,7 @@ git-rerere(1)
NAME
----
git-rerere - Reuse recorded resolve
git-rerere - Reuse recorded resolution of conflicted merges
SYNOPSIS
--------
@ -38,7 +38,7 @@ its working state.
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.
[--skip|--abort] will automatically invoke this command.
'diff'::
@ -81,7 +81,7 @@ One way to do it is to pull master into the topic branch:
------------
$ git checkout topic
$ git pull . master
$ git merge master
o---*---o---+ topic
/ /
@ -103,10 +103,10 @@ in which case the final commit graph would look like this:
------------
$ git checkout topic
$ git pull . master
$ git merge master
$ ... work on both topic and master branches
$ git checkout master
$ git pull . topic
$ git merge topic
o---*---o---+---o---o topic
/ / \
@ -126,11 +126,11 @@ top of the tip before the test merge:
------------
$ git checkout topic
$ git pull . master
$ git merge master
$ git reset --hard HEAD^ ;# rewind the test merge
$ ... work on both topic and master branches
$ git checkout master
$ git pull . topic
$ git merge topic
o---*---o-------o---o topic
/ \

4
Documentation/git-reset.txt
View File

@ -121,10 +121,6 @@ Undo a merge or pull::
+
------------
$ git pull <1>
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
...
Auto-merging nitfol
CONFLICT (content): Merge conflict in nitfol
Automatic merge failed/prevented; fix up by hand

2
Documentation/git-resolve.txt
View File

@ -12,6 +12,8 @@ SYNOPSIS
DESCRIPTION
-----------
DEPRECATED. Use `git-merge` instead.
Given two commits and a merge message, merge the <merged> commit
into <current> commit, with the commit log message <message>.

17
Documentation/git-rev-list.txt
View File

@ -27,6 +27,7 @@ SYNOPSIS
[ \--pretty | \--header ]
[ \--bisect ]
[ \--merge ]
[ \--walk-reflogs ]
<commit>... [ \-- <paths>... ]
DESCRIPTION
@ -190,6 +191,22 @@ limiting may be applied.
In addition to the '<commit>' listed on the command
line, read them from the standard input.
-g, --walk-reflogs::
Instead of walking the commit ancestry chain, walk
reflog entries from the most recent one to older ones.
When this option is used you cannot specify commits to
exclude (that is, '{caret}commit', 'commit1..commit2',
nor 'commit1...commit2' notations cannot be used).
+
With '\--pretty' format other than oneline (for obvious reasons),
this causes the output to have two extra lines of information
taken from the reflog. By default, 'commit@{Nth}' notation is
used in the output. When the starting commit is specified as
'commit@{now}', output also uses 'commit@{timestamp}' notation
instead. Under '\--pretty=oneline', the commit message is
prefixed with this information on the same line.
--merge::
After a failed merge, show refs that touch files having a

8
Documentation/git-rev-parse.txt
View File

@ -152,6 +152,14 @@ blobs contained in a commit.
used immediately following a ref name and the ref must have an
existing log ($GIT_DIR/logs/<ref>).
* A ref followed by the suffix '@' with an ordinal specification
enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify
the n-th prior value of that ref. For example 'master@\{1\}'
is the immediate prior value of 'master' while 'master@\{5\}'
is the 5th prior value of 'master'. This suffix may only be used
immediately following a ref name and the ref must have an existing
log ($GIT_DIR/logs/<ref>).
* A suffix '{caret}' to a revision parameter means the first parent of
that commit object. '{caret}<n>' means the <n>th parent (i.e.
'rev{caret}'

2
Documentation/git-revert.txt
View File

@ -19,6 +19,8 @@ OPTIONS
-------
<commit>::
Commit to revert.
For a more complete list of ways to spell commit names, see
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
-e|--edit::
With this option, `git-revert` will let you edit the commit

12
Documentation/git-rm.txt
View File

@ -60,21 +60,17 @@ a file that you have not told git about does not remove that file.
EXAMPLES
--------
git-rm Documentation/\\*.txt::
Removes all `\*.txt` files from the index that are under the
`Documentation` directory and any of its subdirectories. The
files are not removed from the working tree.
`Documentation` directory and any of its subdirectories.
+
Note that the asterisk `\*` is quoted from the shell in this
example; this lets the command include the files from
subdirectories of `Documentation/` directory.
git-rm -f git-*.sh::
Remove all git-*.sh scripts that are in the index. The files
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
Remove all git-*.sh scripts that are in the index.
Because this example lets the shell expand the asterisk
(i.e. you are listing the files explicitly), it
does not remove `subdir/git-foo.sh`.
See Also

23
Documentation/git-send-pack.txt
View File

@ -3,38 +3,51 @@ git-send-pack(1)
NAME
----
git-send-pack - Push missing objects packed
git-send-pack - Push objects over git protocol to another reposiotory
SYNOPSIS
--------
'git-send-pack' [--all] [--force] [--exec=<git-receive-pack>] [<host>:]<directory> [<ref>...]
'git-send-pack' [--all] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
DESCRIPTION
-----------
Usually you would want to use gitlink:git-push[1] which is a
higher level wrapper of this command instead.
Invokes 'git-receive-pack' on a possibly remote repository, and
updates it from the current repository, sending named refs.
OPTIONS
-------
--exec=<git-receive-pack>::
\--receive-pack=<git-receive-pack>::
Path to the 'git-receive-pack' program on the remote
end. Sometimes useful when pushing to a remote
repository over ssh, and you do not have the program in
a directory on the default $PATH.
--all::
\--exec=<git-receive-pack>::
Same as \--receive-pack=<git-receive-pack>.
\--all::
Instead of explicitly specifying which refs to update,
update all refs that locally exist.
--force::
\--force::
Usually, the command refuses to update a remote ref that
is not an ancestor of the local ref used to overwrite it.
This flag disables the check. What this means is that
the remote repository can lose commits; use it with
care.
\--verbose::
Run verbosely.
\--thin::
Spend extra cycles to minimize the number of objects to be sent.
Use it on slower connection.
<host>::
A remote host to house the repository. When this
part is specified, 'git-receive-pack' is invoked via

51
Documentation/git-sh-setup.txt
View File

@ -12,14 +12,51 @@ SYNOPSIS
DESCRIPTION
-----------
Sets up the normal git environment variables and a few helper functions
(currently just "die()"), and returns OK if it all looks like a git archive.
So, to make the rest of the git scripts more careful and readable,
use it as follows:
This is not a command the end user would want to run. Ever.
This documentation is meant for people who are studying the
Porcelain-ish scripts and/or are writing new ones.
The `git-sh-setup` scriptlet is designed to be sourced (using
`.`) by other shell scripts to set up some variables pointing at
the normal git directories and a few helper shell functions.
Before sourcing it, your script should set up a few variables;
`USAGE` (and `LONG_USAGE`, if any) is used to define message
given by `usage()` shell function. `SUBDIRECTORY_OK` can be set
if the script can run from a subdirectory of the working tree
(some commands do not).
The scriptlet sets `GIT_DIR` and `GIT_OBJECT_DIRECTORY` shell
variables, but does *not* export them to the environment.
FUNCTIONS
---------
die::
exit after emitting the supplied error message to the
standard error stream.
usage::
die with the usage message.
set_reflog_action::
set the message that will be recorded to describe the
end-user action in the reflog, when the script updates a
ref.
is_bare_repository::
outputs `true` or `false` to the standard output stream
to indicate if the repository is a bare repository
(i.e. without an associated working tree).
cd_to_toplevel::
runs chdir to the toplevel of the working tree.
require_work_tree::
checks if the repository is a bare repository, and dies
if so. Used by scripts that require working tree
(e.g. `checkout`).
-------------------------------------------------
. git-sh-setup || die "Not a git archive"
-------------------------------------------------
Author
------

2
Documentation/git-shell.txt
View File

@ -3,7 +3,7 @@ git-shell(1)
NAME
----
git-shell - Restricted login shell for GIT over SSH only
git-shell - Restricted login shell for GIT-only SSH access
SYNOPSIS

2
Documentation/git-shortlog.txt
View File

@ -29,7 +29,7 @@ OPTIONS
of author alphabetic order.
-s::
Supress commit description and provide a commit count summary only.
Suppress commit description and provide a commit count summary only.
FILES
-----

17
Documentation/git-show-branch.txt
View File

@ -11,7 +11,7 @@ SYNOPSIS
'git-show-branch' [--all] [--remotes] [--topo-order] [--current]
[--more=<n> | --list | --independent | --merge-base]
[--no-name | --sha1-name] [--topics] [<rev> | <glob>]...
'git-show-branch' --reflog[=<n>] <ref>
'git-show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] <ref>
DESCRIPTION
-----------
@ -97,9 +97,11 @@ OPTIONS
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.
--reflog[=<n>[,<base>]] <ref>::
Shows <n> most recent ref-log entries for the given
ref. If <base> is given, <n> entries going back from
that entry. <base> can be specified as count or date.
`-g` can be used as a short-hand for this option.
Note that --more, --list, --independent and --merge-base options
are mutually exclusive.
@ -165,6 +167,13 @@ With this, `git show-branch` without extra parameters would show
only the primary branches. In addition, if you happen to be on
your topic branch, it is shown as well.
------------
$ git show-branch --reflog='10,1 hour ago' --list master
------------
shows 10 reflog entries going back from the tip as of 1 hour ago.
Without `--list`, the output also shows how these tips are
topologically related with each other.
Author

2
Documentation/git-show.txt
View File

@ -32,6 +32,8 @@ OPTIONS
-------
<object>::
The name of the object to show.
For a more complete list of ways to spell object names, see
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
include::pretty-formats.txt[]

2
Documentation/git-ssh-fetch.txt
View File

@ -3,7 +3,7 @@ git-ssh-fetch(1)
NAME
----
git-ssh-fetch - Pulls from a remote repository over ssh connection
git-ssh-fetch - Fetch from a remote repository over ssh connection

2
Documentation/git-ssh-upload.txt
View File

@ -3,7 +3,7 @@ git-ssh-upload(1)
NAME
----
git-ssh-upload - Pushes to a remote repository over ssh connection
git-ssh-upload - Push to a remote repository over ssh connection
SYNOPSIS

11
Documentation/git-status.txt
View File

@ -3,7 +3,7 @@ git-status(1)
NAME
----
git-status - Show working tree status
git-status - Show the working tree status
SYNOPSIS
@ -34,6 +34,15 @@ The output from this command is designed to be used as a commit
template comments, and all the output lines are prefixed with '#'.
CONFIGURATION
-------------
The command honors `color.status` (or `status.color` -- they
mean the same thing and the latter is kept for backward
compatibility) and `color.status.<slot>` configuration variables
to colorize its output.
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and

24
Documentation/git-svn.txt
View File

@ -3,7 +3,7 @@ git-svn(1)
NAME
----
git-svn - bidirectional operation between Subversion and git
git-svn - Bidirectional operation between a single Subversion branch and git
SYNOPSIS
--------
@ -113,7 +113,7 @@ manually joining branches on commit.
'commit-diff'::
Commits the diff of two tree-ish arguments from the
command-line. This command is intended for interopability with
command-line. This command is intended for interoperability 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
@ -204,7 +204,7 @@ 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
config key: svn.rmdir
-e::
--edit::
@ -215,7 +215,7 @@ 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
config key: svn.edit
-l<num>::
--find-copies-harder::
@ -226,8 +226,8 @@ 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
config key: svn.l
config key: svn.findcopiesharder
-A<filename>::
--authors-file=<filename>::
@ -245,7 +245,7 @@ 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.authorsfile
config key: svn.authorsfile
-q::
--quiet::
@ -262,8 +262,8 @@ repo-config key: svn.authorsfile
--repack-flags are passed directly to gitlink:git-repack[1].
repo-config key: svn.repack
repo-config key: svn.repackflags
config key: svn.repack
config key: svn.repackflags
-m::
--merge::
@ -304,7 +304,7 @@ used to track branches across multiple SVN _repositories_.
This option may be specified multiple times, once for each
branch.
repo-config key: svn.branch
config key: svn.branch
-i<GIT_SVN_ID>::
--id <GIT_SVN_ID>::
@ -320,7 +320,7 @@ for more information on using GIT_SVN_ID.
started tracking a branch and never tracked the trunk it was
descended from.
repo-config key: svn.followparent
config key: svn.followparent
--no-metadata::
This gets rid of the git-svn-id: lines at the end of every commit.
@ -332,7 +332,7 @@ repo-config key: svn.followparent
The 'git-svn log' command will not work on repositories using this,
either.
repo-config key: svn.nometadata
config key: svn.nometadata
--

16
Documentation/git-symbolic-ref.txt
View File

@ -3,11 +3,11 @@ git-symbolic-ref(1)
NAME
----
git-symbolic-ref - read and modify symbolic refs
git-symbolic-ref - Read and modify symbolic refs
SYNOPSIS
--------
'git-symbolic-ref' <name> [<ref>]
'git-symbolic-ref' [-q] <name> [<ref>]
DESCRIPTION
-----------
@ -23,6 +23,14 @@ 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`.
OPTIONS
-------
-q::
Do not issue an error message if the <name> is not a
symbolic ref but a detached HEAD; instead exit with
non-zero status silently.
NOTES
-----
In the past, `.git/HEAD` was a symbolic link pointing at
@ -36,6 +44,10 @@ cumbersome. On some platforms, `ln -sf` does not even work as
advertised (horrors). Therefore symbolic links are now deprecated
and symbolic refs are used by default.
git-symbolic-ref will exit with status 0 if the contents of the
symbolic ref were printed correctly, with status 1 if the requested
name is not a symbolic ref, or 128 if another error occurs.
Author
------
Written by Junio C Hamano <junkio@cox.net>

18
Documentation/git-tag.txt
View File

@ -3,14 +3,14 @@ git-tag(1)
NAME
----
git-tag - Create a tag object signed with GPG
git-tag - Create, list, delete or verify a tag object signed with GPG
SYNOPSIS
--------
[verse]
'git-tag' [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg> | -F <file>]
<name> [<head>]
'git-tag' [-a | -s | -u <key-id>] [-f | -v] [-m <msg> | -F <file>] <name> [<head>]
'git-tag' -d <name>...
'git-tag' -l [<pattern>]
DESCRIPTION
@ -55,7 +55,7 @@ OPTIONS
Replace an existing tag with the given name (instead of failing)
-d::
Delete an existing tag with the given name
Delete existing tags with the given names.
-v::
Verify the gpg signature of given the tag
@ -70,6 +70,16 @@ OPTIONS
Take the tag message from the given file. Use '-' to
read the message from the standard input.
CONFIGURATION
-------------
By default, git-tag in sign-with-default mode (-s) will use your
committer identity (of the form "Your Name <your@email.address>") to
find a key. If you want to use a different default key, you can specify
it in the repository configuration as follows:
[user]
signingkey = <gpg-key-id>
Author
------
Written by Linus Torvalds <torvalds@osdl.org>,

4
Documentation/git-tar-tree.txt
View File

@ -3,7 +3,7 @@ git-tar-tree(1)
NAME
----
git-tar-tree - Creates a tar archive of the files in the named tree
git-tar-tree - Create a tar archive of the files in the named tree object
SYNOPSIS
@ -50,7 +50,7 @@ repository configuration as follows :
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
will be used instead. The default value is 002, which means group
readable/writable files and directories.
EXAMPLES

14
Documentation/git-tools.txt
View File

@ -50,7 +50,7 @@ History Viewers
gitview is a GTK based repository browser for git
- *gitweb* (ftp://ftp.kernel.org/pub/software/scm/gitweb/)
- *gitweb* (shipped with git-core)
GITweb provides full-fledged web interface for GIT repositories.
@ -63,12 +63,18 @@ History Viewers
Currently it is the fastest and most feature rich among the git
viewers and commit tools.
- *tig* (http://jonas.nitro.dk/tig/)
tig by Jonas Fonseca is a simple git repository browser
written using ncurses. Basically, it just acts as a front-end
for git-log and git-show/git-diff. Additionally, you can also
use it as a pager for git commands.
Foreign SCM interface
---------------------
- *git-svn* (contrib/)
- *git-svn* (shipped with git-core)
git-svn is a simple conduit for changesets between a single Subversion
branch and git.
@ -95,3 +101,7 @@ Others
This is an Emacs interface for git. The user interface is modeled on
pcl-cvs. It has been developed on Emacs 21 and will probably need some
tweaking to work on XEmacs.
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools has more
comprehensive list.

6
Documentation/git-update-index.txt
View File

@ -3,7 +3,7 @@ git-update-index(1)
NAME
----
git-update-index - Modifies the index or directory cache
git-update-index - Register file contents in the working tree to the index
SYNOPSIS
@ -289,7 +289,7 @@ Configuration
The command honors `core.filemode` configuration variable. If
your repository is on an filesystem whose executable bits are
unreliable, this should be set to 'false' (see gitlink:git-repo-config[1]).
unreliable, this should be set to 'false' (see gitlink:git-config[1]).
This causes the command to ignore differences in file modes recorded
in the index and the file mode on the filesystem if they differ only on
executable bit. On such an unfortunate filesystem, you may
@ -301,7 +301,7 @@ The command looks at `core.ignorestat` configuration variable. See
See Also
--------
gitlink:git-repo-config[1]
gitlink:git-config[1]
Author

2
Documentation/git-update-ref.txt
View File

@ -3,7 +3,7 @@ git-update-ref(1)
NAME
----
git-update-ref - update the object name stored in a ref safely
git-update-ref - Update the object name stored in a ref safely
SYNOPSIS
--------

2
Documentation/git-upload-archive.txt
View File

@ -3,7 +3,7 @@ git-upload-archive(1)
NAME
----
git-upload-archive - Send archive
git-upload-archive - Send archive back to git-archive
SYNOPSIS

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