Merge branch 'master' into sp/gfi
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
maint
Shawn O. Pearce
commit
76db9dec81
|
|
@ -23,6 +23,7 @@ git-clean
|
||||||
git-clone
|
git-clone
|
||||||
git-commit
|
git-commit
|
||||||
git-commit-tree
|
git-commit-tree
|
||||||
|
git-config
|
||||||
git-convert-objects
|
git-convert-objects
|
||||||
git-count-objects
|
git-count-objects
|
||||||
git-cvsexportcommit
|
git-cvsexportcommit
|
||||||
|
|
@ -42,6 +43,7 @@ git-findtags
|
||||||
git-fmt-merge-msg
|
git-fmt-merge-msg
|
||||||
git-for-each-ref
|
git-for-each-ref
|
||||||
git-format-patch
|
git-format-patch
|
||||||
|
git-fsck
|
||||||
git-fsck-objects
|
git-fsck-objects
|
||||||
git-gc
|
git-gc
|
||||||
git-get-tar-commit-id
|
git-get-tar-commit-id
|
||||||
|
|
|
||||||
2
.mailmap
2
.mailmap
|
|
@ -30,7 +30,9 @@ Robert Fitzsimons <robfitz@273k.net>
|
||||||
Santi Béjar <sbejar@gmail.com>
|
Santi Béjar <sbejar@gmail.com>
|
||||||
Sean Estabrooks <seanlkml@sympatico.ca>
|
Sean Estabrooks <seanlkml@sympatico.ca>
|
||||||
Shawn O. Pearce <spearce@spearce.org>
|
Shawn O. Pearce <spearce@spearce.org>
|
||||||
|
Theodore Ts'o <tytso@mit.edu>
|
||||||
Tony Luck <tony.luck@intel.com>
|
Tony Luck <tony.luck@intel.com>
|
||||||
|
Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
|
||||||
Ville Skyttä <scop@xemacs.org>
|
Ville Skyttä <scop@xemacs.org>
|
||||||
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
|
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
|
||||||
anonymous <linux@horizon.com>
|
anonymous <linux@horizon.com>
|
||||||
|
|
|
||||||
|
|
@ -4,4 +4,4 @@
|
||||||
*.7
|
*.7
|
||||||
howto-index.txt
|
howto-index.txt
|
||||||
doc.dep
|
doc.dep
|
||||||
README
|
cmds-*.txt
|
||||||
|
|
|
||||||
|
|
@ -71,14 +71,24 @@ doc.dep : $(wildcard *.txt) build-docdep.perl
|
||||||
|
|
||||||
-include doc.dep
|
-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
|
$(cmds_txt): cmd-list.perl $(MAN1_TXT)
|
||||||
cp $< $@
|
perl ./cmd-list.perl
|
||||||
|
|
||||||
|
git.7 git.html: git.txt core-intro.txt
|
||||||
|
|
||||||
clean:
|
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
|
%.html : %.txt
|
||||||
asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
|
asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
|
||||||
|
|
@ -89,8 +99,6 @@ clean:
|
||||||
%.xml : %.txt
|
%.xml : %.txt
|
||||||
asciidoc -b docbook -d manpage -f asciidoc.conf $<
|
asciidoc -b docbook -d manpage -f asciidoc.conf $<
|
||||||
|
|
||||||
git.html: git.txt README
|
|
||||||
|
|
||||||
glossary.html : glossary.txt sort_glossary.pl
|
glossary.html : glossary.txt sort_glossary.pl
|
||||||
cat $< | \
|
cat $< | \
|
||||||
perl sort_glossary.pl | \
|
perl sort_glossary.pl | \
|
||||||
|
|
|
||||||
|
|
@ -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
|
Oh, another thing. I am picky about whitespaces. Make sure your
|
||||||
changes do not trigger errors with the sample pre-commit hook shipped
|
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.
|
(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.
|
material between the three dash lines and the diffstat.
|
||||||
|
|
||||||
Do not attach the patch as a MIME attachment, compressed or not.
|
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
|
popular e-mail applications will not always transmit a MIME
|
||||||
attachment as plain text, making it impossible to comment on
|
attachment as plain text, making it impossible to comment on
|
||||||
your code. A MIME attachment also takes a bit more time to
|
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.default.compose_html => false
|
||||||
mail.identity.id?.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.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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
|
||||||
|
|
@ -2,21 +2,84 @@ CONFIGURATION FILE
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
The git configuration file contains a number of variables that affect
|
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
|
and the porcelains. The variables are divided into sections, where
|
||||||
in the fully qualified variable name the variable itself is the last
|
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-separated segment and the section name is everything before the last
|
||||||
dot. The variable names are case-insensitive and only alphanumeric
|
dot. The variable names are case-insensitive and only alphanumeric
|
||||||
characters are allowed. Some variables may appear multiple times.
|
characters are allowed. Some variables may appear multiple times.
|
||||||
|
|
||||||
|
Syntax
|
||||||
|
~~~~~~
|
||||||
|
|
||||||
The syntax is fairly flexible and permissive; whitespaces are mostly
|
The syntax is fairly flexible and permissive; whitespaces are mostly
|
||||||
ignored. The '#' and ';' characters begin comments to the end of line,
|
ignored. The '#' and ';' characters begin comments to the end of line,
|
||||||
blank lines are ignored, lines containing strings enclosed in square
|
blank lines are ignored.
|
||||||
brackets start sections and all the other lines are recognized
|
|
||||||
as setting variables, in the form 'name = value'. If there is no equal
|
The file consists of sections and variables. A section begins with
|
||||||
sign on the line, the entire line is taken as 'name' and the variable
|
the name of the section in square brackets and continues until the next
|
||||||
is recognized as boolean "true". String values may be entirely or partially
|
section begins. Section names are not case sensitive. Only alphanumeric
|
||||||
enclosed in double quotes; some variables may require special value format.
|
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
|
Example
|
||||||
~~~~~~~
|
~~~~~~~
|
||||||
|
|
@ -35,6 +98,10 @@ Example
|
||||||
remote = origin
|
remote = origin
|
||||||
merge = refs/heads/devel
|
merge = refs/heads/devel
|
||||||
|
|
||||||
|
# Proxy settings
|
||||||
|
[core]
|
||||||
|
gitProxy="ssh" for "ssh://kernel.org/"
|
||||||
|
gitProxy=default-proxy ; for the rest
|
||||||
|
|
||||||
Variables
|
Variables
|
||||||
~~~~~~~~~
|
~~~~~~~~~
|
||||||
|
|
@ -183,10 +250,15 @@ color.branch.<slot>::
|
||||||
Use customized color for branch coloration. `<slot>` is one of
|
Use customized color for branch coloration. `<slot>` is one of
|
||||||
`current` (the current branch), `local` (a local branch),
|
`current` (the current branch), `local` (a local branch),
|
||||||
`remote` (a tracking branch in refs/remotes/), `plain` (other
|
`remote` (a tracking branch in refs/remotes/), `plain` (other
|
||||||
refs), or `reset` (the normal terminal color). The value for
|
refs).
|
||||||
these configuration variables can be one of: `normal`, `bold`,
|
+
|
||||||
`dim`, `ul`, `blink`, `reverse`, `reset`, `black`, `red`,
|
The value for these configuration variables is a list of colors (at most
|
||||||
`green`, `yellow`, `blue`, `magenta`, `cyan`, or `white`.
|
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::
|
color.diff::
|
||||||
When true (or `always`), always use colors in patch.
|
When true (or `always`), always use colors in patch.
|
||||||
|
|
@ -194,12 +266,13 @@ color.diff::
|
||||||
colors only when the output is to the terminal.
|
colors only when the output is to the terminal.
|
||||||
|
|
||||||
color.diff.<slot>::
|
color.diff.<slot>::
|
||||||
Use customized color for diff colorization. `<slot>`
|
Use customized color for diff colorization. `<slot>` specifies
|
||||||
specifies which part of the patch to use the specified
|
which part of the patch to use the specified color, and is one
|
||||||
color, and is one of `plain` (context text), `meta`
|
of `plain` (context text), `meta` (metainformation), `frag`
|
||||||
(metainformation), `frag` (hunk header), `old` (removed
|
(hunk header), `old` (removed lines), `new` (added lines),
|
||||||
lines), or `new` (added lines). The values of these
|
`commit` (commit headers), or `whitespace` (highlighting dubious
|
||||||
variables may be specified as in color.branch.<slot>.
|
whitespace). The values of these variables may be specified as
|
||||||
|
in color.branch.<slot>.
|
||||||
|
|
||||||
color.pager::
|
color.pager::
|
||||||
A boolean to enable/disable colored output when the pager is in
|
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
|
will enable basic rename detection. If set to "copies" or
|
||||||
"copy", it will detect copies, as well.
|
"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::
|
format.headers::
|
||||||
Additional email headers to include in a patch to be submitted
|
Additional email headers to include in a patch to be submitted
|
||||||
by mail. See gitlink:git-format-patch[1].
|
by mail. See gitlink:git-format-patch[1].
|
||||||
|
|
@ -321,6 +404,13 @@ merge.summary::
|
||||||
Whether to include summaries of merged commits in newly created
|
Whether to include summaries of merged commits in newly created
|
||||||
merge commit messages. False by default.
|
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::
|
pack.window::
|
||||||
The size of the window used by gitlink:git-pack-objects[1] when no
|
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.
|
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
|
The default set of "refspec" for gitlink:git-push[1]. See
|
||||||
gitlink:git-push[1].
|
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::
|
repack.usedeltabaseoffset::
|
||||||
Allow gitlink:git-repack[1] to create packs that uses
|
Allow gitlink:git-repack[1] to create packs that uses
|
||||||
delta-base offset. Defaults to false.
|
delta-base offset. Defaults to false.
|
||||||
|
|
@ -377,6 +475,13 @@ user.name::
|
||||||
Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
|
Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
|
||||||
environment variables. See gitlink:git-commit-tree[1].
|
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::
|
whatchanged.difftree::
|
||||||
The default gitlink:git-diff-tree[1] arguments to be used
|
The default gitlink:git-diff-tree[1] arguments to be used
|
||||||
for gitlink:git-whatchanged[1].
|
for gitlink:git-whatchanged[1].
|
||||||
|
|
@ -400,3 +505,8 @@ receive.denyNonFastForwards::
|
||||||
even if that push is forced. This configuration variable is
|
even if that push is forced. This configuration variable is
|
||||||
set when initializing a shared repository.
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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.
|
||||||
|
|
@ -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:
|
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
|
Auto-merging hello
|
||||||
CONFLICT (content): Merge conflict in hello
|
CONFLICT (content): Merge conflict in hello
|
||||||
Automatic merge failed; fix up by hand
|
Automatic merge failed; fix up by hand
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
which is way too verbose, but it basically tells you that it failed the
|
It tells you that it did an "Automatic merge", which
|
||||||
really trivial merge ("Simple merge") and did an "Automatic merge"
|
failed due to conflicts in `hello`.
|
||||||
instead, but that too failed due to conflicts in `hello`.
|
|
||||||
|
|
||||||
Not to worry. It left the (trivial) conflict in `hello` in the same form you
|
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
|
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
|
course, you will pay the price of more disk usage to hold
|
||||||
multiple working trees, but disk space is cheap these days.
|
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
|
It is likely that you will be pulling from the same remote
|
||||||
repository from time to time. As a short hand, you can store
|
repository from time to time. As a short hand, you can store
|
||||||
the remote repository URL in a file under .git/remotes/
|
the remote repository URL in the local repository's config file
|
||||||
directory, like this:
|
like this:
|
||||||
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
$ mkdir -p .git/remotes/
|
$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
|
||||||
$ 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
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
|
||||||
|
and use the "linus" keyword with `git pull` instead of the full URL.
|
||||||
|
|
||||||
Examples.
|
Examples.
|
||||||
|
|
||||||
. `git pull linus`
|
. `git pull linus`
|
||||||
. `git pull linus tag v0.99.1`
|
. `git pull linus tag v0.99.1`
|
||||||
. `git pull jgarzik/netdev-2.6.git/ e100`
|
|
||||||
|
|
||||||
the above are equivalent to:
|
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/ HEAD`
|
||||||
. `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1`
|
. `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?
|
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
|
1. Prepare your work repository, by `git clone` the public
|
||||||
repository of the "project lead". The URL used for the
|
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
|
2. Prepare a public repository accessible to others, just like
|
||||||
the "project lead" person does.
|
the "project lead" person does.
|
||||||
|
|
@ -1586,14 +1562,15 @@ like this:
|
||||||
1. Prepare your work repository, by `git clone` the public
|
1. Prepare your work repository, by `git clone` the public
|
||||||
repository of the "project lead" (or a "subsystem
|
repository of the "project lead" (or a "subsystem
|
||||||
maintainer", if you work on a subsystem). The URL used for
|
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.
|
2. Do your work in your repository on 'master' branch.
|
||||||
|
|
||||||
3. Run `git fetch origin` from the public repository of your
|
3. Run `git fetch origin` from the public repository of your
|
||||||
upstream every once in a while. This does only the first
|
upstream every once in a while. This does only the first
|
||||||
half of `git pull` but does not merge. The head of the
|
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
|
4. Use `git cherry origin` to see which ones of your patches
|
||||||
were accepted, and/or use `git rebase origin` to port your
|
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
|
You can make sure 'git show-branch' matches the state before
|
||||||
those two 'git merge' you just did. Then, instead of running
|
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'):
|
branch heads (this is known as 'making an Octopus'):
|
||||||
|
|
||||||
------------
|
------------
|
||||||
$ git pull . commit-fix diff-fix
|
$ git merge commit-fix diff-fix
|
||||||
$ git show-branch
|
$ git show-branch
|
||||||
! [commit-fix] Fix commit message normalization.
|
! [commit-fix] Fix commit message normalization.
|
||||||
! [diff-fix] Fix rename detection.
|
! [diff-fix] Fix rename detection.
|
||||||
|
|
@ -1701,7 +1678,7 @@ $ git show-branch
|
||||||
|
|
||||||
Note that you should not do Octopus because you can. An octopus
|
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
|
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
|
changes at the same time. However, if you have merge conflicts
|
||||||
with any of the branches you are merging in and need to hand
|
with any of the branches you are merging in and need to hand
|
||||||
resolve, that is an indication that the development happened in
|
resolve, that is an indication that the development happened in
|
||||||
|
|
|
||||||
|
|
@ -36,7 +36,7 @@ them first before running git pull.
|
||||||
================================
|
================================
|
||||||
The `pull` command knows where to get updates from because of certain
|
The `pull` command knows where to get updates from because of certain
|
||||||
configuration variables that were set by the first `git clone`
|
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.
|
page for details.
|
||||||
================================
|
================================
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -58,6 +58,10 @@
|
||||||
Turn off rename detection, even when the configuration
|
Turn off rename detection, even when the configuration
|
||||||
file gives the default to do so.
|
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::
|
--full-index::
|
||||||
Instead of the first handful characters, show full
|
Instead of the first handful characters, show full
|
||||||
object name of pre- and post-image blob on the "index"
|
object name of pre- and post-image blob on the "index"
|
||||||
|
|
|
||||||
|
|
@ -28,7 +28,7 @@ Everybody uses these commands to maintain git repositories.
|
||||||
* gitlink:git-init[1] or gitlink:git-clone[1] to create a
|
* gitlink:git-init[1] or gitlink:git-clone[1] to create a
|
||||||
new repository.
|
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.
|
* gitlink:git-prune[1] to remove unused objects in the repository.
|
||||||
|
|
||||||
|
|
@ -43,7 +43,7 @@ Examples
|
||||||
Check health and remove cruft.::
|
Check health and remove cruft.::
|
||||||
+
|
+
|
||||||
------------
|
------------
|
||||||
$ git fsck-objects <1>
|
$ git fsck <1>
|
||||||
$ git count-objects <2>
|
$ git count-objects <2>
|
||||||
$ git repack <3>
|
$ git repack <3>
|
||||||
$ git gc <4>
|
$ 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
|
<8> redo the commit undone in the previous step, using the message
|
||||||
you originally wrote.
|
you originally wrote.
|
||||||
<9> switch to the master branch.
|
<9> switch to the master branch.
|
||||||
<10> merge a topic branch into your master branch. You can also use
|
<10> merge a topic branch into your master branch.
|
||||||
`git pull . alsa-audio`, i.e. pull from the local repository.
|
|
||||||
<11> review commit logs; other forms to limit output can be
|
<11> review commit logs; other forms to limit output can be
|
||||||
combined and include `\--max-count=10` (show 10 commits),
|
combined and include `\--max-count=10` (show 10 commits),
|
||||||
`\--until=2005-12-10`, etc.
|
`\--until=2005-12-10`, etc.
|
||||||
|
|
@ -213,12 +212,12 @@ Push into another repository.::
|
||||||
------------
|
------------
|
||||||
satellite$ git clone mothership:frotz frotz <1>
|
satellite$ git clone mothership:frotz frotz <1>
|
||||||
satellite$ cd frotz
|
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.url mothership:frotz
|
||||||
remote.origin.fetch refs/heads/*:refs/remotes/origin/*
|
remote.origin.fetch refs/heads/*:refs/remotes/origin/*
|
||||||
branch.master.remote origin
|
branch.master.remote origin
|
||||||
branch.master.merge refs/heads/master
|
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>
|
master:refs/remotes/satellite/master <3>
|
||||||
satellite$ edit/compile/test/commit
|
satellite$ edit/compile/test/commit
|
||||||
satellite$ git push origin <4>
|
satellite$ git push origin <4>
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@ git-add - Add file contents to the changeset to be committed next
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
'git-add' [-n] [-v] [-f] [--interactive] [--] <file>...
|
'git-add' [-n] [-v] [-f] [--interactive | -i] [--] <file>...
|
||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
|
|
@ -52,7 +52,7 @@ OPTIONS
|
||||||
-f::
|
-f::
|
||||||
Allow adding otherwise ignored files.
|
Allow adding otherwise ignored files.
|
||||||
|
|
||||||
\--interactive::
|
\i, \--interactive::
|
||||||
Add modified contents in the working tree interactively to
|
Add modified contents in the working tree interactively to
|
||||||
the index.
|
the index.
|
||||||
|
|
||||||
|
|
@ -83,7 +83,7 @@ git-add git-*.sh::
|
||||||
Interactive mode
|
Interactive mode
|
||||||
----------------
|
----------------
|
||||||
When the command enters the interactive mode, it shows the
|
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.
|
interactive command loop.
|
||||||
|
|
||||||
The command loop shows the list of subcommands available, and
|
The command loop shows the list of subcommands available, and
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-am(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-am - Apply a series of patches in a mailbox
|
git-am - Apply a series of patches from a mailbox
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-apply(1)
|
||||||
|
|
||||||
NAME
|
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
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -12,6 +12,9 @@ SYNOPSIS
|
||||||
|
|
||||||
DESCRIPTION
|
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
|
Takes three files <msg>, <patch>, and <info> prepared from an
|
||||||
e-mail message by 'git-mailinfo', and creates a commit. It is
|
e-mail message by 'git-mailinfo', and creates a commit. It is
|
||||||
usually not necessary to use this command directly.
|
usually not necessary to use this command directly.
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-archive(1)
|
||||||
|
|
||||||
NAME
|
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
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-bisect(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-bisect - Find the change that introduced a bug
|
git-bisect - Find the change that introduced a bug by binary search
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,7 @@ git-blame - Show what revision and author last modified each line of a file
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
[verse]
|
[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>
|
[-M] [-C] [-C] [--since=<date>] [<rev>] [--] <file>
|
||||||
|
|
||||||
DESCRIPTION
|
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.
|
interface briefly mentioned in the following paragraph.
|
||||||
|
|
||||||
Apart from supporting file annotation, git also supports searching the
|
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
|
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
|
between files, and eventually deleted or replaced. It works by searching for
|
||||||
a text string in the diff. A small example:
|
a text string in the diff. A small example:
|
||||||
|
|
@ -63,6 +63,10 @@ OPTIONS
|
||||||
-p, --porcelain::
|
-p, --porcelain::
|
||||||
Show in a format designed for machine consumption.
|
Show in a format designed for machine consumption.
|
||||||
|
|
||||||
|
--incremental::
|
||||||
|
Show the result incrementally in a format designed for
|
||||||
|
machine consumption.
|
||||||
|
|
||||||
-M::
|
-M::
|
||||||
Detect moving lines in the file as well. When a commit
|
Detect moving lines in the file as well. When a commit
|
||||||
moves a block of lines in a file (e.g. the original file
|
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
|
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;
|
- 40-byte SHA-1 of the commit the line is attributed to;
|
||||||
- the line number of the line in the original file;
|
- the line number of the line in the original file;
|
||||||
|
|
@ -112,15 +116,18 @@ header, prefixed by a TAB. This is to allow adding more
|
||||||
header elements later.
|
header elements later.
|
||||||
|
|
||||||
|
|
||||||
SPECIFIYING RANGES
|
SPECIFYING RANGES
|
||||||
------------------
|
-----------------
|
||||||
|
|
||||||
Unlike `git-blame` and `git-annotate` in older git, the extent
|
Unlike `git-blame` and `git-annotate` in older git, the extent
|
||||||
of annotation can be limited to both line ranges and revision
|
of annotation can be limited to both line ranges and revision
|
||||||
ranges. When you are interested in finding the origin for
|
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,60 foo
|
||||||
|
git blame -L 40,+21 foo
|
||||||
|
|
||||||
Also you can use regular expression to specify the line range.
|
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
|
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
|
SEE ALSO
|
||||||
--------
|
--------
|
||||||
gitlink:git-annotate[1]
|
gitlink:git-annotate[1]
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-branch(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-branch - List, create, or delete branches.
|
git-branch - List, create, or delete branches
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-cat-file(1)
|
||||||
|
|
||||||
NAME
|
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
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-checkout-index(1)
|
||||||
|
|
||||||
NAME
|
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
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -9,7 +9,7 @@ SYNOPSIS
|
||||||
--------
|
--------
|
||||||
[verse]
|
[verse]
|
||||||
'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<branch>]
|
'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<branch>]
|
||||||
'git-checkout' [-m] [<branch>] <paths>...
|
'git-checkout' [<branch>] <paths>...
|
||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
|
|
@ -64,6 +64,56 @@ and mark the resolved paths with `git update-index`.
|
||||||
<branch>::
|
<branch>::
|
||||||
Branch to checkout; may be any object ID that resolves to a
|
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
|
EXAMPLES
|
||||||
|
|
|
||||||
|
|
@ -19,6 +19,8 @@ OPTIONS
|
||||||
-------
|
-------
|
||||||
<commit>::
|
<commit>::
|
||||||
Commit to cherry-pick.
|
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::
|
-e|--edit::
|
||||||
With this option, `git-cherry-pick` will let you edit the commit
|
With this option, `git-cherry-pick` will let you edit the commit
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-clone(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-clone - Clones a repository
|
git-clone - Clones a repository into a new directory
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-commit-tree(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-commit-tree - Creates a new commit object
|
git-commit-tree - Create a new commit object
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
@ -12,6 +12,9 @@ SYNOPSIS
|
||||||
|
|
||||||
DESCRIPTION
|
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
|
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
|
emits the new commit object id on stdout. If no parent is given then
|
||||||
it is considered to be an initial tree.
|
it is considered to be an initial tree.
|
||||||
|
|
|
||||||
|
|
@ -3,13 +3,13 @@ git-commit(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-commit - Record your changes
|
git-commit - Record changes to the repository
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
[verse]
|
[verse]
|
||||||
'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
|
'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg> |
|
||||||
[--no-verify] [--amend] [-e] [--author <author>]
|
--amend] [--no-verify] [-e] [--author <author>]
|
||||||
[--] [[-i | -o ]<file>...]
|
[--] [[-i | -o ]<file>...]
|
||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
|
|
@ -111,7 +111,7 @@ but can be used to amend a merge commit.
|
||||||
are concluding a conflicted merge.
|
are concluding a conflicted merge.
|
||||||
|
|
||||||
-q|--quiet::
|
-q|--quiet::
|
||||||
Supress commit summary message.
|
Suppress commit summary message.
|
||||||
|
|
||||||
\--::
|
\--::
|
||||||
Do not interpret any more arguments as options.
|
Do not interpret any more arguments as options.
|
||||||
|
|
@ -142,11 +142,6 @@ $ git add hello.c
|
||||||
$ git commit
|
$ 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
|
Instead of staging files after each individual change, you can
|
||||||
tell `git commit` to notice the changes to the files whose
|
tell `git commit` to notice the changes to the files whose
|
||||||
contents are tracked in
|
contents are tracked in
|
||||||
|
|
@ -223,6 +218,12 @@ refuses to run when given pathnames (but see `-i` option).
|
||||||
DISCUSSION
|
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[]
|
include::i18n.txt[]
|
||||||
|
|
||||||
ENVIRONMENT VARIABLES
|
ENVIRONMENT VARIABLES
|
||||||
|
|
|
||||||
|
|
@ -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
|
||||||
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-count-objects(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-count-objects - Reports on unpacked objects
|
git-count-objects - Count unpacked number of objects and their disk consumption
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-cvsexportcommit(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-cvsexportcommit - Export a commit to a CVS checkout
|
git-cvsexportcommit - Export a single commit to a CVS checkout
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-cvsimport(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-cvsimport - Import a CVS repository into git
|
git-cvsimport - Salvage your data out of another SCM people love to hate
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
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>
|
Substitute the character "/" in branch names with <subst>
|
||||||
|
|
||||||
-A <author-conv-file>::
|
-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
|
commit logs. Using this option and an author-conv-file
|
||||||
in this format
|
in this format
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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
|
the facility of inet daemon to achieve the same before spawning
|
||||||
`git-daemon` if needed.
|
`git-daemon` if needed.
|
||||||
|
|
||||||
--enable-service, --disable-service::
|
--enable=service, --disable=service::
|
||||||
Enable/disable the service site-wide per default. Note
|
Enable/disable the service site-wide per default. Note
|
||||||
that a service disabled site-wide can still be enabled
|
that a service disabled site-wide can still be enabled
|
||||||
per repository if it is marked overridable and the
|
per repository if it is marked overridable and the
|
||||||
repository enables the service with an configuration
|
repository enables the service with an configuration
|
||||||
item.
|
item.
|
||||||
|
|
||||||
--allow-override, --forbid-override::
|
--allow-override=service, --forbid-override=service::
|
||||||
Allow/forbid overriding the site-wide default with per
|
Allow/forbid overriding the site-wide default with per
|
||||||
repository configuration. By default, all the services
|
repository configuration. By default, all the services
|
||||||
are overridable.
|
are overridable.
|
||||||
|
|
|
||||||
|
|
@ -14,8 +14,8 @@ DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
The command finds the most recent tag that is reachable from a
|
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
|
commit, and if the commit itself is pointed at by the tag, shows
|
||||||
the tag. Otherwise, it suffixes the tag name with abbreviated
|
the tag. Otherwise, it suffixes the tag name with the number of
|
||||||
object name of the commit.
|
additional commits and the abbreviated object name of the commit.
|
||||||
|
|
||||||
|
|
||||||
OPTIONS
|
OPTIONS
|
||||||
|
|
@ -35,6 +35,16 @@ OPTIONS
|
||||||
Instead of using the default 8 hexadecimal digits as the
|
Instead of using the default 8 hexadecimal digits as the
|
||||||
abbreviated object name, use <n> digits.
|
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
|
EXAMPLES
|
||||||
--------
|
--------
|
||||||
|
|
@ -42,12 +52,18 @@ EXAMPLES
|
||||||
With something like git.git current tree, I get:
|
With something like git.git current tree, I get:
|
||||||
|
|
||||||
[torvalds@g5 git]$ git-describe parent
|
[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,
|
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
|
but since it has a handful commits on top of that,
|
||||||
git hash of the thing to the end: "-g" + 8-char shorthand for
|
describe has added the number of additional commits ("14") and
|
||||||
the commit `2414721b194453f058079d897d13c4e377f92dc6`.
|
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:
|
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:
|
the output shows the reference path as well:
|
||||||
|
|
||||||
[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
|
[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^
|
[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
|
Author
|
||||||
------
|
------
|
||||||
Written by Linus Torvalds <torvalds@osdl.org>, but somewhat
|
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
|
Documentation
|
||||||
--------------
|
--------------
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-diff-stages(1)
|
||||||
|
|
||||||
NAME
|
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
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -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
|
noted that all of the <commit> in the above description can be
|
||||||
any <tree-ish>.
|
any <tree-ish>.
|
||||||
|
|
||||||
|
For a more complete list of ways to spell <commit>, see
|
||||||
|
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
|
||||||
|
|
||||||
|
|
||||||
OPTIONS
|
OPTIONS
|
||||||
-------
|
-------
|
||||||
|
|
|
||||||
|
|
@ -8,10 +8,13 @@ git-fetch-pack - Receive missing objects from another repository
|
||||||
|
|
||||||
SYNOPSIS
|
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
|
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,
|
Invokes 'git-upload-pack' on a potentially remote repository,
|
||||||
and asks it to send objects missing from this repository, to
|
and asks it to send objects missing from this repository, to
|
||||||
update the named heads. The list of commits available locally
|
update the named heads. The list of commits available locally
|
||||||
|
|
@ -25,17 +28,24 @@ have a common ancestor commit.
|
||||||
|
|
||||||
OPTIONS
|
OPTIONS
|
||||||
-------
|
-------
|
||||||
-q::
|
\--all::
|
||||||
|
Fetch all remote refs.
|
||||||
|
|
||||||
|
\--quiet, \-q::
|
||||||
Pass '-q' flag to 'git-unpack-objects'; this makes the
|
Pass '-q' flag to 'git-unpack-objects'; this makes the
|
||||||
cloning process less verbose.
|
cloning process less verbose.
|
||||||
|
|
||||||
-k::
|
\--keep, \-k::
|
||||||
Do not invoke 'git-unpack-objects' on received data, but
|
Do not invoke 'git-unpack-objects' on received data, but
|
||||||
create a single packfile out of it instead, and store it
|
create a single packfile out of it instead, and store it
|
||||||
in the object database. If provided twice then the pack is
|
in the object database. If provided twice then the pack is
|
||||||
locked against repacking.
|
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
|
Use this to specify the path to 'git-upload-pack' on the
|
||||||
remote side, if is not found on your $PATH.
|
remote side, if is not found on your $PATH.
|
||||||
Installations of sshd ignores the user's environment
|
Installations of sshd ignores the user's environment
|
||||||
|
|
@ -47,6 +57,15 @@ OPTIONS
|
||||||
shells by having a lean .bashrc file (they set most of
|
shells by having a lean .bashrc file (they set most of
|
||||||
the things up in .bash_profile).
|
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>::
|
<host>::
|
||||||
A remote host that houses the repository. When this
|
A remote host that houses the repository. When this
|
||||||
part is specified, 'git-upload-pack' is invoked via
|
part is specified, 'git-upload-pack' is invoked via
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-fetch(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-fetch - Download objects and a head from another repository
|
git-fetch - Download objects and refs from another repository
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@ git-for-each-ref - Output information on each ref
|
||||||
|
|
||||||
SYNOPSIS
|
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
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
|
|
@ -15,7 +15,7 @@ DESCRIPTION
|
||||||
Iterate over all refs that match `<pattern>` and show them
|
Iterate over all refs that match `<pattern>` and show them
|
||||||
according to the given `<format>`, after sorting them according
|
according to the given `<format>`, after sorting them according
|
||||||
to the given set of `<key>`. If `<max>` is given, stop after
|
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
|
can optionally be quoted as string literals in the specified
|
||||||
host language allowing their direct evaluation in that language.
|
host language allowing their direct evaluation in that language.
|
||||||
|
|
||||||
|
|
@ -49,7 +49,7 @@ OPTIONS
|
||||||
using fnmatch(3). Refs that do not match the pattern
|
using fnmatch(3). Refs that do not match the pattern
|
||||||
are not shown.
|
are not shown.
|
||||||
|
|
||||||
--shell, --perl, --python::
|
--shell, --perl, --python, --tcl::
|
||||||
If given, strings that substitute `%(fieldname)`
|
If given, strings that substitute `%(fieldname)`
|
||||||
placeholders are quoted as string literals suitable for
|
placeholders are quoted as string literals suitable for
|
||||||
the specified host language. This is meant to produce
|
the specified host language. This is meant to produce
|
||||||
|
|
|
||||||
|
|
@ -11,7 +11,8 @@ SYNOPSIS
|
||||||
[verse]
|
[verse]
|
||||||
'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [--thread]
|
'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [--thread]
|
||||||
[-s | --signoff] [--diff-options] [--start-number <n>]
|
[-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>]
|
<since>[..<until>]
|
||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
|
|
@ -20,7 +21,9 @@ DESCRIPTION
|
||||||
Prepare each commit between <since> and <until> with its patch in
|
Prepare each commit between <since> and <until> with its patch in
|
||||||
one file per commit, formatted to resemble UNIX mailbox format.
|
one file per commit, formatted to resemble UNIX mailbox format.
|
||||||
If ..<until> is not specified, the head of the current working
|
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
|
The output of this command is convenient for e-mail submission or
|
||||||
for use with gitlink:git-am[1].
|
for use with gitlink:git-am[1].
|
||||||
|
|
@ -78,13 +81,34 @@ OPTIONS
|
||||||
reply to the given Message-Id, which avoids breaking threads to
|
reply to the given Message-Id, which avoids breaking threads to
|
||||||
provide a new patch series.
|
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
|
CONFIGURATION
|
||||||
-------------
|
-------------
|
||||||
You can specify extra mail header lines to be added to each
|
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]
|
[format]
|
||||||
headers = "Organization: git-foo\n"
|
headers = "Organization: git-foo\n"
|
||||||
|
suffix = .txt
|
||||||
|
------------
|
||||||
|
|
||||||
|
|
||||||
EXAMPLES
|
EXAMPLES
|
||||||
|
|
@ -109,6 +133,9 @@ git-format-patch -M -B origin::
|
||||||
understand renaming patches, so use it only when you know
|
understand renaming patches, so use it only when you know
|
||||||
the recipient uses git to apply your patch.
|
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
|
See Also
|
||||||
--------
|
--------
|
||||||
|
|
|
||||||
|
|
@ -8,132 +8,10 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
[verse]
|
'git-fsck-objects' ...
|
||||||
'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache]
|
|
||||||
[--full] [--strict] [<object>*]
|
|
||||||
|
|
||||||
DESCRIPTION
|
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.
|
||||||
|
|
|
||||||
|
|
@ -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
|
||||||
|
|
||||||
|
|
@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
'git-gc'
|
'git-gc' [--prune]
|
||||||
|
|
||||||
DESCRIPTION
|
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
|
each repository to maintain good disk space utilization and good
|
||||||
operating performance.
|
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
|
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
|
are not part of the current branch should remain available in
|
||||||
this repository. These types of entries are generally created as
|
this repository. These types of entries are generally created as
|
||||||
a result of using `git commit \--amend` or `git rebase` and are the
|
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
|
are not part of the current project most users will want to expire
|
||||||
them sooner. This option defaults to '30 days'.
|
them sooner. This option defaults to '30 days'.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -91,7 +91,7 @@ OPTIONS
|
||||||
combined by 'or'.
|
combined by 'or'.
|
||||||
|
|
||||||
--and | --or | --not | ( | )::
|
--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
|
expressions. `--or` is the default operator. `--and` has
|
||||||
higher precedence than `--or`. `-e` has to be used for all
|
higher precedence than `--or`. `-e` has to be used for all
|
||||||
patterns.
|
patterns.
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-hash-object(1)
|
||||||
|
|
||||||
NAME
|
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
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-http-fetch(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-http-fetch - downloads a remote git repository via HTTP
|
git-http-fetch - Download from a remote git repository via HTTP
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-http-push(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-http-push - Push missing objects using HTTP/DAV
|
git-http-push - Push objects over HTTP/DAV to another repository
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-init(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-init - Creates an empty git repository
|
git-init - Create an empty git repository or reinitialize an existing one
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-instaweb(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-instaweb - instantly browse your working repository in gitweb
|
git-instaweb - Instantly browse your working repository in gitweb
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-local-fetch(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-local-fetch - Duplicates another git repository on a local system
|
git-local-fetch - Duplicate another git repository on a local system
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -27,13 +27,16 @@ OPTIONS
|
||||||
|
|
||||||
include::pretty-formats.txt[]
|
include::pretty-formats.txt[]
|
||||||
|
|
||||||
--max-count=<n>::
|
-<n>::
|
||||||
Limits the number of commits to show.
|
Limits the number of commits to show.
|
||||||
|
|
||||||
<since>..<until>::
|
<since>..<until>::
|
||||||
Show only commits between the named two commits. When
|
Show only commits between the named two commits. When
|
||||||
either <since> or <until> is omitted, it defaults to
|
either <since> or <until> is omitted, it defaults to
|
||||||
`HEAD`, i.e. the tip of the current branch.
|
`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::
|
-p::
|
||||||
Show the change the commit introduces in a patch form.
|
Show the change the commit introduces in a patch form.
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-ls-files(1)
|
||||||
|
|
||||||
NAME
|
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
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -29,7 +29,7 @@ OPTIONS
|
||||||
-u <exec>, --upload-pack=<exec>::
|
-u <exec>, --upload-pack=<exec>::
|
||||||
Specify the full path of gitlink:git-upload-pack[1] on the remote
|
Specify the full path of gitlink:git-upload-pack[1] on the remote
|
||||||
host. This allows listing references from repositories accessed via
|
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].
|
user. Also see the '--exec' option for gitlink:git-peek-remote[1].
|
||||||
|
|
||||||
<repository>::
|
<repository>::
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-ls-tree(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-ls-tree - Lists the contents of a tree object
|
git-ls-tree - List the contents of a tree object
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-mailinfo(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-mailinfo - Extracts patch from a single e-mail message
|
git-mailinfo - Extracts patch and authorship from a single e-mail message
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
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
|
<patch> file. The author name, e-mail and e-mail subject are
|
||||||
written out to the standard output to be used by git-applypatch
|
written out to the standard output to be used by git-applypatch
|
||||||
to create a commit. It is usually not necessary to use this
|
to create a commit. It is usually not necessary to use this
|
||||||
command directly.
|
command directly. See gitlink:git-am[1] instead.
|
||||||
|
|
||||||
|
|
||||||
OPTIONS
|
OPTIONS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-mailsplit(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-mailsplit - Totally braindamaged mbox splitter program
|
git-mailsplit - Simple UNIX mbox splitter program
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-merge-base(1)
|
||||||
|
|
||||||
NAME
|
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
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-merge-file(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-merge-file - three-way file merge
|
git-merge-file - Run a three-way file merge
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-merge-index(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-merge-index - Runs a merge for files needing merging
|
git-merge-index - Run a merge for files needing merging
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-merge-one-file(1)
|
||||||
|
|
||||||
NAME
|
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
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-merge(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-merge - Grand Unified Merge Driver
|
git-merge - Join two or more development histories together
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-mv(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-mv - Move or rename a file, directory or symlink
|
git-mv - Move or rename a file, a directory, or a symlink
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-pack-redundant(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-pack-redundant - Program used to find redundant pack files
|
git-pack-redundant - Find redundant pack files
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
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
|
following command useful when wanting to remove packs which contain unreachable
|
||||||
objects.
|
objects.
|
||||||
|
|
||||||
git-fsck-objects --full --unreachable | cut -d ' ' -f3 | \
|
git-fsck --full --unreachable | cut -d ' ' -f3 | \
|
||||||
git-pack-redundant --all | xargs rm
|
git-pack-redundant --all | xargs rm
|
||||||
|
|
||||||
OPTIONS
|
OPTIONS
|
||||||
|
|
|
||||||
|
|
@ -29,12 +29,23 @@ file and used if found.
|
||||||
Subsequent updates to branches always creates new file under
|
Subsequent updates to branches always creates new file under
|
||||||
`$GIT_DIR/refs` hierarchy.
|
`$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
|
OPTIONS
|
||||||
-------
|
-------
|
||||||
|
|
||||||
\--all::
|
\--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
|
alone. This is because branches are expected to be actively
|
||||||
developed and packing their tips does not help performance.
|
developed and packing their tips does not help performance.
|
||||||
This option causes branch tips to be packed as well. Useful for
|
This option causes branch tips to be packed as well. Useful for
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-parse-remote(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-parse-remote - Routines to help parsing $GIT_DIR/remotes/
|
git-parse-remote - Routines to help parsing remote repository access parameters
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
@ -14,7 +14,8 @@ DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
This script is included in various scripts to supply
|
This script is included in various scripts to supply
|
||||||
routines to parse files under $GIT_DIR/remotes/ and
|
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:
|
The primary entry points are:
|
||||||
|
|
||||||
|
|
@ -25,7 +26,8 @@ get_remote_refs_for_fetch::
|
||||||
(e.g. `refs/heads/foo`). When `<refspec>...` is empty
|
(e.g. `refs/heads/foo`). When `<refspec>...` is empty
|
||||||
the returned list of refs consists of the defaults
|
the returned list of refs consists of the defaults
|
||||||
for the given `<repo>`, if specified in
|
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::
|
get_remote_refs_for_push::
|
||||||
Given the list of user-supplied `<repo> <refspec>...`,
|
Given the list of user-supplied `<repo> <refspec>...`,
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-patch-id(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-patch-id - Generate a patch ID
|
git-patch-id - Compute unique ID for a patch
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
|
|
|
||||||
|
|
@ -3,12 +3,12 @@ git-peek-remote(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-peek-remote - Lists the references in a remote repository
|
git-peek-remote - List the references in a remote repository
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
'git-peek-remote' [--exec=<git-upload-pack>] [<host>:]<directory>
|
'git-peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory>
|
||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
|
|
@ -17,7 +17,7 @@ stores them in the local repository under the same name.
|
||||||
|
|
||||||
OPTIONS
|
OPTIONS
|
||||||
-------
|
-------
|
||||||
--exec=<git-upload-pack>::
|
\--upload-pack=<git-upload-pack>::
|
||||||
Use this to specify the path to 'git-upload-pack' on the
|
Use this to specify the path to 'git-upload-pack' on the
|
||||||
remote side, if it is not found on your $PATH. Some
|
remote side, if it is not found on your $PATH. Some
|
||||||
installations of sshd ignores the user's environment
|
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
|
shells, but prefer having a lean .bashrc file (they set most of
|
||||||
the things up in .bash_profile).
|
the things up in .bash_profile).
|
||||||
|
|
||||||
|
\--exec=<git-upload-pack>::
|
||||||
|
Same \--upload-pack=<git-upload-pack>.
|
||||||
|
|
||||||
<host>::
|
<host>::
|
||||||
A remote host that houses the repository. When this
|
A remote host that houses the repository. When this
|
||||||
part is specified, 'git-upload-pack' is invoked via
|
part is specified, 'git-upload-pack' is invoked via
|
||||||
|
|
|
||||||
|
|
@ -3,8 +3,7 @@ git-prune-packed(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-prune-packed - Program used to remove the extra object files that are now
|
git-prune-packed - Remove extra objects that are already in pack files
|
||||||
residing in a pack file.
|
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -13,7 +13,7 @@ SYNOPSIS
|
||||||
DESCRIPTION
|
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
|
available in `$GIT_DIR/refs`, optionally with additional set of
|
||||||
objects specified on the command line, and prunes all
|
objects specified on the command line, and prunes all
|
||||||
objects unreachable from any of these head objects from the object database.
|
objects unreachable from any of these head objects from the object database.
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-pull(1)
|
||||||
|
|
||||||
NAME
|
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
|
SYNOPSIS
|
||||||
|
|
@ -42,7 +42,7 @@ git pull, git pull origin::
|
||||||
current branch. Normally the branch merged in is
|
current branch. Normally the branch merged in is
|
||||||
the HEAD of the remote repository, but the choice is
|
the HEAD of the remote repository, but the choice is
|
||||||
determined by the branch.<name>.remote and
|
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.
|
for details.
|
||||||
|
|
||||||
git pull origin next::
|
git pull origin next::
|
||||||
|
|
@ -52,7 +52,8 @@ git pull origin next::
|
||||||
|
|
||||||
git pull . fixes enhancements::
|
git pull . fixes enhancements::
|
||||||
Bundle local branch `fixes` and `enhancements` on top of
|
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::
|
git pull -s ours . obsolete::
|
||||||
Merge local branch `obsolete` into the current branch,
|
Merge local branch `obsolete` into the current branch,
|
||||||
|
|
@ -93,7 +94,7 @@ gitlink:git-reset[1].
|
||||||
|
|
||||||
SEE ALSO
|
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
|
Author
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,7 @@ git-push - Update remote refs along with associated objects
|
||||||
|
|
||||||
SYNOPSIS
|
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
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
|
|
@ -67,12 +67,33 @@ the remote repository.
|
||||||
addition to refspecs explicitly listed on the command
|
addition to refspecs explicitly listed on the command
|
||||||
line.
|
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::
|
-f, \--force::
|
||||||
Usually, the command refuses to update a remote ref that is
|
Usually, the command refuses to update a remote ref that is
|
||||||
not a descendant of the local ref used to overwrite it.
|
not a descendant of the local ref used to overwrite it.
|
||||||
This flag disables the check. This can cause the
|
This flag disables the check. This can cause the
|
||||||
remote repository to lose commits; use it with care.
|
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[]
|
include::urls.txt[]
|
||||||
|
|
||||||
Author
|
Author
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-rebase(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-rebase - Rebase local commits to a new head
|
git-rebase - Forward-port local commits to the updated upstream head
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-receive-pack(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-receive-pack - Receive what is pushed into it
|
git-receive-pack - Receive what is pushed into the repository
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -9,7 +9,7 @@ git-reflog - Manage reflog information
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
[verse]
|
[verse]
|
||||||
'git-reflog' expire [--dry-run]
|
'git-reflog' expire [--dry-run] [--stale-fix]
|
||||||
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
|
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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
|
The remote configuration is achieved using the `remote.origin.url` and
|
||||||
`remote.origin.fetch` configuration variables. (See
|
`remote.origin.fetch` configuration variables. (See
|
||||||
gitlink:git-repo-config[1]).
|
gitlink:git-config[1]).
|
||||||
|
|
||||||
Examples
|
Examples
|
||||||
--------
|
--------
|
||||||
|
|
@ -58,7 +58,7 @@ See Also
|
||||||
--------
|
--------
|
||||||
gitlink:git-fetch[1]
|
gitlink:git-fetch[1]
|
||||||
gitlink:git-branch[1]
|
gitlink:git-branch[1]
|
||||||
gitlink:git-repo-config[1]
|
gitlink:git-config[1]
|
||||||
|
|
||||||
Author
|
Author
|
||||||
------
|
------
|
||||||
|
|
|
||||||
|
|
@ -3,8 +3,7 @@ git-repack(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-repack - Script used to pack a repository from a collection of
|
git-repack - Pack unpacked objects in a repository
|
||||||
objects into pack files.
|
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,225 +3,16 @@ git-repo-config(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-repo-config - Get and set repository or global options.
|
git-repo-config - Get and set repository or global options
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
[verse]
|
'git-repo-config' ...
|
||||||
'git-repo-config' [--global] [type] name [value [value_regex]]
|
|
||||||
'git-repo-config' [--global] [type] --add name value
|
|
||||||
'git-repo-config' [--global] [type] --replace-all name [value [value_regex]]
|
|
||||||
'git-repo-config' [--global] [type] --get name [value_regex]
|
|
||||||
'git-repo-config' [--global] [type] --get-all name [value_regex]
|
|
||||||
'git-repo-config' [--global] [type] --unset name [value_regex]
|
|
||||||
'git-repo-config' [--global] [type] --unset-all name [value_regex]
|
|
||||||
'git-repo-config' [--global] -l | --list
|
|
||||||
|
|
||||||
DESCRIPTION
|
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.
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-rerere(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-rerere - Reuse recorded resolve
|
git-rerere - Reuse recorded resolution of conflicted merges
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
|
|
@ -38,7 +38,7 @@ its working state.
|
||||||
|
|
||||||
This resets the metadata used by rerere if a merge resolution is to be
|
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]
|
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'::
|
'diff'::
|
||||||
|
|
||||||
|
|
@ -81,7 +81,7 @@ One way to do it is to pull master into the topic branch:
|
||||||
|
|
||||||
------------
|
------------
|
||||||
$ git checkout topic
|
$ git checkout topic
|
||||||
$ git pull . master
|
$ git merge master
|
||||||
|
|
||||||
o---*---o---+ topic
|
o---*---o---+ topic
|
||||||
/ /
|
/ /
|
||||||
|
|
@ -103,10 +103,10 @@ in which case the final commit graph would look like this:
|
||||||
|
|
||||||
------------
|
------------
|
||||||
$ git checkout topic
|
$ git checkout topic
|
||||||
$ git pull . master
|
$ git merge master
|
||||||
$ ... work on both topic and master branches
|
$ ... work on both topic and master branches
|
||||||
$ git checkout master
|
$ git checkout master
|
||||||
$ git pull . topic
|
$ git merge topic
|
||||||
|
|
||||||
o---*---o---+---o---o topic
|
o---*---o---+---o---o topic
|
||||||
/ / \
|
/ / \
|
||||||
|
|
@ -126,11 +126,11 @@ top of the tip before the test merge:
|
||||||
|
|
||||||
------------
|
------------
|
||||||
$ git checkout topic
|
$ git checkout topic
|
||||||
$ git pull . master
|
$ git merge master
|
||||||
$ git reset --hard HEAD^ ;# rewind the test merge
|
$ git reset --hard HEAD^ ;# rewind the test merge
|
||||||
$ ... work on both topic and master branches
|
$ ... work on both topic and master branches
|
||||||
$ git checkout master
|
$ git checkout master
|
||||||
$ git pull . topic
|
$ git merge topic
|
||||||
|
|
||||||
o---*---o-------o---o topic
|
o---*---o-------o---o topic
|
||||||
/ \
|
/ \
|
||||||
|
|
|
||||||
|
|
@ -121,10 +121,6 @@ Undo a merge or pull::
|
||||||
+
|
+
|
||||||
------------
|
------------
|
||||||
$ git pull <1>
|
$ git pull <1>
|
||||||
Trying really trivial in-index merge...
|
|
||||||
fatal: Merge requires file-level merging
|
|
||||||
Nope.
|
|
||||||
...
|
|
||||||
Auto-merging nitfol
|
Auto-merging nitfol
|
||||||
CONFLICT (content): Merge conflict in nitfol
|
CONFLICT (content): Merge conflict in nitfol
|
||||||
Automatic merge failed/prevented; fix up by hand
|
Automatic merge failed/prevented; fix up by hand
|
||||||
|
|
|
||||||
|
|
@ -12,6 +12,8 @@ SYNOPSIS
|
||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
|
DEPRECATED. Use `git-merge` instead.
|
||||||
|
|
||||||
Given two commits and a merge message, merge the <merged> commit
|
Given two commits and a merge message, merge the <merged> commit
|
||||||
into <current> commit, with the commit log message <message>.
|
into <current> commit, with the commit log message <message>.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -27,6 +27,7 @@ SYNOPSIS
|
||||||
[ \--pretty | \--header ]
|
[ \--pretty | \--header ]
|
||||||
[ \--bisect ]
|
[ \--bisect ]
|
||||||
[ \--merge ]
|
[ \--merge ]
|
||||||
|
[ \--walk-reflogs ]
|
||||||
<commit>... [ \-- <paths>... ]
|
<commit>... [ \-- <paths>... ]
|
||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
|
|
@ -190,6 +191,22 @@ limiting may be applied.
|
||||||
In addition to the '<commit>' listed on the command
|
In addition to the '<commit>' listed on the command
|
||||||
line, read them from the standard input.
|
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::
|
--merge::
|
||||||
|
|
||||||
After a failed merge, show refs that touch files having a
|
After a failed merge, show refs that touch files having a
|
||||||
|
|
|
||||||
|
|
@ -152,6 +152,14 @@ blobs contained in a commit.
|
||||||
used immediately following a ref name and the ref must have an
|
used immediately following a ref name and the ref must have an
|
||||||
existing log ($GIT_DIR/logs/<ref>).
|
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
|
* A suffix '{caret}' to a revision parameter means the first parent of
|
||||||
that commit object. '{caret}<n>' means the <n>th parent (i.e.
|
that commit object. '{caret}<n>' means the <n>th parent (i.e.
|
||||||
'rev{caret}'
|
'rev{caret}'
|
||||||
|
|
|
||||||
|
|
@ -19,6 +19,8 @@ OPTIONS
|
||||||
-------
|
-------
|
||||||
<commit>::
|
<commit>::
|
||||||
Commit to revert.
|
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::
|
-e|--edit::
|
||||||
With this option, `git-revert` will let you edit the commit
|
With this option, `git-revert` will let you edit the commit
|
||||||
|
|
|
||||||
|
|
@ -60,21 +60,17 @@ a file that you have not told git about does not remove that file.
|
||||||
EXAMPLES
|
EXAMPLES
|
||||||
--------
|
--------
|
||||||
git-rm Documentation/\\*.txt::
|
git-rm Documentation/\\*.txt::
|
||||||
|
|
||||||
Removes all `\*.txt` files from the index that are under the
|
Removes all `\*.txt` files from the index that are under the
|
||||||
`Documentation` directory and any of its subdirectories. The
|
`Documentation` directory and any of its subdirectories.
|
||||||
files are not removed from the working tree.
|
|
||||||
+
|
+
|
||||||
Note that the asterisk `\*` is quoted from the shell in this
|
Note that the asterisk `\*` is quoted from the shell in this
|
||||||
example; this lets the command include the files from
|
example; this lets the command include the files from
|
||||||
subdirectories of `Documentation/` directory.
|
subdirectories of `Documentation/` directory.
|
||||||
|
|
||||||
git-rm -f git-*.sh::
|
git-rm -f git-*.sh::
|
||||||
|
Remove all git-*.sh scripts that are in the index.
|
||||||
Remove all git-*.sh scripts that are in the index. The files
|
Because this example lets the shell expand the asterisk
|
||||||
are removed from the index, and from the working
|
(i.e. you are listing the files explicitly), it
|
||||||
tree. Because this example lets the shell expand the
|
|
||||||
asterisk (i.e. you are listing the files explicitly), it
|
|
||||||
does not remove `subdir/git-foo.sh`.
|
does not remove `subdir/git-foo.sh`.
|
||||||
|
|
||||||
See Also
|
See Also
|
||||||
|
|
|
||||||
|
|
@ -3,38 +3,51 @@ git-send-pack(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-send-pack - Push missing objects packed
|
git-send-pack - Push objects over git protocol to another reposiotory
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
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
|
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
|
Invokes 'git-receive-pack' on a possibly remote repository, and
|
||||||
updates it from the current repository, sending named refs.
|
updates it from the current repository, sending named refs.
|
||||||
|
|
||||||
|
|
||||||
OPTIONS
|
OPTIONS
|
||||||
-------
|
-------
|
||||||
--exec=<git-receive-pack>::
|
\--receive-pack=<git-receive-pack>::
|
||||||
Path to the 'git-receive-pack' program on the remote
|
Path to the 'git-receive-pack' program on the remote
|
||||||
end. Sometimes useful when pushing to a remote
|
end. Sometimes useful when pushing to a remote
|
||||||
repository over ssh, and you do not have the program in
|
repository over ssh, and you do not have the program in
|
||||||
a directory on the default $PATH.
|
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,
|
Instead of explicitly specifying which refs to update,
|
||||||
update all refs that locally exist.
|
update all refs that locally exist.
|
||||||
|
|
||||||
--force::
|
\--force::
|
||||||
Usually, the command refuses to update a remote ref that
|
Usually, the command refuses to update a remote ref that
|
||||||
is not an ancestor of the local ref used to overwrite it.
|
is not an ancestor of the local ref used to overwrite it.
|
||||||
This flag disables the check. What this means is that
|
This flag disables the check. What this means is that
|
||||||
the remote repository can lose commits; use it with
|
the remote repository can lose commits; use it with
|
||||||
care.
|
care.
|
||||||
|
|
||||||
|
\--verbose::
|
||||||
|
Run verbosely.
|
||||||
|
|
||||||
|
\--thin::
|
||||||
|
Spend extra cycles to minimize the number of objects to be sent.
|
||||||
|
Use it on slower connection.
|
||||||
|
|
||||||
<host>::
|
<host>::
|
||||||
A remote host to house the repository. When this
|
A remote host to house the repository. When this
|
||||||
part is specified, 'git-receive-pack' is invoked via
|
part is specified, 'git-receive-pack' is invoked via
|
||||||
|
|
|
||||||
|
|
@ -12,14 +12,51 @@ SYNOPSIS
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
Sets up the normal git environment variables and a few helper functions
|
This is not a command the end user would want to run. Ever.
|
||||||
(currently just "die()"), and returns OK if it all looks like a git archive.
|
This documentation is meant for people who are studying the
|
||||||
So, to make the rest of the git scripts more careful and readable,
|
Porcelain-ish scripts and/or are writing new ones.
|
||||||
use it as follows:
|
|
||||||
|
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
|
Author
|
||||||
------
|
------
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-shell(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-shell - Restricted login shell for GIT over SSH only
|
git-shell - Restricted login shell for GIT-only SSH access
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -29,7 +29,7 @@ OPTIONS
|
||||||
of author alphabetic order.
|
of author alphabetic order.
|
||||||
|
|
||||||
-s::
|
-s::
|
||||||
Supress commit description and provide a commit count summary only.
|
Suppress commit description and provide a commit count summary only.
|
||||||
|
|
||||||
FILES
|
FILES
|
||||||
-----
|
-----
|
||||||
|
|
|
||||||
|
|
@ -11,7 +11,7 @@ SYNOPSIS
|
||||||
'git-show-branch' [--all] [--remotes] [--topo-order] [--current]
|
'git-show-branch' [--all] [--remotes] [--topo-order] [--current]
|
||||||
[--more=<n> | --list | --independent | --merge-base]
|
[--more=<n> | --list | --independent | --merge-base]
|
||||||
[--no-name | --sha1-name] [--topics] [<rev> | <glob>]...
|
[--no-name | --sha1-name] [--topics] [<rev> | <glob>]...
|
||||||
'git-show-branch' --reflog[=<n>] <ref>
|
'git-show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] <ref>
|
||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
|
|
@ -97,9 +97,11 @@ OPTIONS
|
||||||
will show the revisions given by "git rev-list {caret}master
|
will show the revisions given by "git rev-list {caret}master
|
||||||
topic1 topic2"
|
topic1 topic2"
|
||||||
|
|
||||||
--reflog[=<n>] <ref>::
|
--reflog[=<n>[,<base>]] <ref>::
|
||||||
Shows <n> most recent ref-log entries for the given 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
|
Note that --more, --list, --independent and --merge-base options
|
||||||
are mutually exclusive.
|
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
|
only the primary branches. In addition, if you happen to be on
|
||||||
your topic branch, it is shown as well.
|
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
|
Author
|
||||||
|
|
|
||||||
|
|
@ -32,6 +32,8 @@ OPTIONS
|
||||||
-------
|
-------
|
||||||
<object>::
|
<object>::
|
||||||
The name of the object to show.
|
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[]
|
include::pretty-formats.txt[]
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-ssh-fetch(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-ssh-fetch - Pulls from a remote repository over ssh connection
|
git-ssh-fetch - Fetch from a remote repository over ssh connection
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-ssh-upload(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-ssh-upload - Pushes to a remote repository over ssh connection
|
git-ssh-upload - Push to a remote repository over ssh connection
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-status(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-status - Show working tree status
|
git-status - Show the working tree status
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
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 '#'.
|
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
|
Author
|
||||||
------
|
------
|
||||||
Written by Linus Torvalds <torvalds@osdl.org> and
|
Written by Linus Torvalds <torvalds@osdl.org> and
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-svn(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-svn - bidirectional operation between Subversion and git
|
git-svn - Bidirectional operation between a single Subversion branch and git
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
|
|
@ -113,7 +113,7 @@ manually joining branches on commit.
|
||||||
|
|
||||||
'commit-diff'::
|
'commit-diff'::
|
||||||
Commits the diff of two tree-ish arguments from the
|
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
|
git-svnimport and does not rely on being inside an git-svn
|
||||||
init-ed repository. This command takes three arguments, (a) the
|
init-ed repository. This command takes three arguments, (a) the
|
||||||
original tree to diff against, (b) the new tree result, (c) 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
|
cannot version empty directories. Enabling this flag will make
|
||||||
the commit to SVN act like git.
|
the commit to SVN act like git.
|
||||||
|
|
||||||
repo-config key: svn.rmdir
|
config key: svn.rmdir
|
||||||
|
|
||||||
-e::
|
-e::
|
||||||
--edit::
|
--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
|
default for objects that are commits, and forced on when committing
|
||||||
tree objects.
|
tree objects.
|
||||||
|
|
||||||
repo-config key: svn.edit
|
config key: svn.edit
|
||||||
|
|
||||||
-l<num>::
|
-l<num>::
|
||||||
--find-copies-harder::
|
--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.
|
gitlink:git-diff-tree[1] for more information.
|
||||||
|
|
||||||
[verse]
|
[verse]
|
||||||
repo-config key: svn.l
|
config key: svn.l
|
||||||
repo-config key: svn.findcopiesharder
|
config key: svn.findcopiesharder
|
||||||
|
|
||||||
-A<filename>::
|
-A<filename>::
|
||||||
--authors-file=<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
|
appropriate entry. Re-running the previous git-svn command
|
||||||
after the authors-file is modified should continue operation.
|
after the authors-file is modified should continue operation.
|
||||||
|
|
||||||
repo-config key: svn.authorsfile
|
config key: svn.authorsfile
|
||||||
|
|
||||||
-q::
|
-q::
|
||||||
--quiet::
|
--quiet::
|
||||||
|
|
@ -262,8 +262,8 @@ repo-config key: svn.authorsfile
|
||||||
|
|
||||||
--repack-flags are passed directly to gitlink:git-repack[1].
|
--repack-flags are passed directly to gitlink:git-repack[1].
|
||||||
|
|
||||||
repo-config key: svn.repack
|
config key: svn.repack
|
||||||
repo-config key: svn.repackflags
|
config key: svn.repackflags
|
||||||
|
|
||||||
-m::
|
-m::
|
||||||
--merge::
|
--merge::
|
||||||
|
|
@ -304,7 +304,7 @@ used to track branches across multiple SVN _repositories_.
|
||||||
This option may be specified multiple times, once for each
|
This option may be specified multiple times, once for each
|
||||||
branch.
|
branch.
|
||||||
|
|
||||||
repo-config key: svn.branch
|
config key: svn.branch
|
||||||
|
|
||||||
-i<GIT_SVN_ID>::
|
-i<GIT_SVN_ID>::
|
||||||
--id <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
|
started tracking a branch and never tracked the trunk it was
|
||||||
descended from.
|
descended from.
|
||||||
|
|
||||||
repo-config key: svn.followparent
|
config key: svn.followparent
|
||||||
|
|
||||||
--no-metadata::
|
--no-metadata::
|
||||||
This gets rid of the git-svn-id: lines at the end of every commit.
|
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,
|
The 'git-svn log' command will not work on repositories using this,
|
||||||
either.
|
either.
|
||||||
|
|
||||||
repo-config key: svn.nometadata
|
config key: svn.nometadata
|
||||||
|
|
||||||
--
|
--
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -3,11 +3,11 @@ git-symbolic-ref(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-symbolic-ref - read and modify symbolic refs
|
git-symbolic-ref - Read and modify symbolic refs
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
'git-symbolic-ref' <name> [<ref>]
|
'git-symbolic-ref' [-q] <name> [<ref>]
|
||||||
|
|
||||||
DESCRIPTION
|
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
|
begins with `ref: refs/`. For example, your `.git/HEAD` is
|
||||||
a regular file whose contents is `ref: refs/heads/master`.
|
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
|
NOTES
|
||||||
-----
|
-----
|
||||||
In the past, `.git/HEAD` was a symbolic link pointing at
|
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
|
advertised (horrors). Therefore symbolic links are now deprecated
|
||||||
and symbolic refs are used by default.
|
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
|
Author
|
||||||
------
|
------
|
||||||
Written by Junio C Hamano <junkio@cox.net>
|
Written by Junio C Hamano <junkio@cox.net>
|
||||||
|
|
|
||||||
|
|
@ -3,14 +3,14 @@ git-tag(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-tag - Create a tag object signed with GPG
|
git-tag - Create, list, delete or verify a tag object signed with GPG
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
[verse]
|
[verse]
|
||||||
'git-tag' [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg> | -F <file>]
|
'git-tag' [-a | -s | -u <key-id>] [-f | -v] [-m <msg> | -F <file>] <name> [<head>]
|
||||||
<name> [<head>]
|
'git-tag' -d <name>...
|
||||||
'git-tag' -l [<pattern>]
|
'git-tag' -l [<pattern>]
|
||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
|
|
@ -55,7 +55,7 @@ OPTIONS
|
||||||
Replace an existing tag with the given name (instead of failing)
|
Replace an existing tag with the given name (instead of failing)
|
||||||
|
|
||||||
-d::
|
-d::
|
||||||
Delete an existing tag with the given name
|
Delete existing tags with the given names.
|
||||||
|
|
||||||
-v::
|
-v::
|
||||||
Verify the gpg signature of given the tag
|
Verify the gpg signature of given the tag
|
||||||
|
|
@ -70,6 +70,16 @@ OPTIONS
|
||||||
Take the tag message from the given file. Use '-' to
|
Take the tag message from the given file. Use '-' to
|
||||||
read the message from the standard input.
|
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
|
Author
|
||||||
------
|
------
|
||||||
Written by Linus Torvalds <torvalds@osdl.org>,
|
Written by Linus Torvalds <torvalds@osdl.org>,
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-tar-tree(1)
|
||||||
|
|
||||||
NAME
|
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
|
SYNOPSIS
|
||||||
|
|
@ -50,7 +50,7 @@ repository configuration as follows :
|
||||||
umask = 002 ;# group friendly
|
umask = 002 ;# group friendly
|
||||||
|
|
||||||
The special umask value "user" indicates that the user's current umask
|
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.
|
readable/writable files and directories.
|
||||||
|
|
||||||
EXAMPLES
|
EXAMPLES
|
||||||
|
|
|
||||||
|
|
@ -50,7 +50,7 @@ History Viewers
|
||||||
gitview is a GTK based repository browser for git
|
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.
|
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
|
Currently it is the fastest and most feature rich among the git
|
||||||
viewers and commit tools.
|
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
|
Foreign SCM interface
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
- *git-svn* (contrib/)
|
- *git-svn* (shipped with git-core)
|
||||||
|
|
||||||
git-svn is a simple conduit for changesets between a single Subversion
|
git-svn is a simple conduit for changesets between a single Subversion
|
||||||
branch and git.
|
branch and git.
|
||||||
|
|
@ -95,3 +101,7 @@ Others
|
||||||
This is an Emacs interface for git. The user interface is modeled on
|
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
|
pcl-cvs. It has been developed on Emacs 21 and will probably need some
|
||||||
tweaking to work on XEmacs.
|
tweaking to work on XEmacs.
|
||||||
|
|
||||||
|
|
||||||
|
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools has more
|
||||||
|
comprehensive list.
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-update-index(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-update-index - Modifies the index or directory cache
|
git-update-index - Register file contents in the working tree to the index
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
@ -289,7 +289,7 @@ Configuration
|
||||||
|
|
||||||
The command honors `core.filemode` configuration variable. If
|
The command honors `core.filemode` configuration variable. If
|
||||||
your repository is on an filesystem whose executable bits are
|
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
|
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
|
in the index and the file mode on the filesystem if they differ only on
|
||||||
executable bit. On such an unfortunate filesystem, you may
|
executable bit. On such an unfortunate filesystem, you may
|
||||||
|
|
@ -301,7 +301,7 @@ The command looks at `core.ignorestat` configuration variable. See
|
||||||
|
|
||||||
See Also
|
See Also
|
||||||
--------
|
--------
|
||||||
gitlink:git-repo-config[1]
|
gitlink:git-config[1]
|
||||||
|
|
||||||
|
|
||||||
Author
|
Author
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-update-ref(1)
|
||||||
|
|
||||||
NAME
|
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
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ git-upload-archive(1)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-upload-archive - Send archive
|
git-upload-archive - Send archive back to git-archive
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
|
|
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue