mirror of
https://github.com/git/git
synced 2024-08-25 02:35:46 +00:00
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
This commit is contained in:
commit
76db9dec81
2
.gitignore
vendored
2
.gitignore
vendored
|
@ -23,6 +23,7 @@ git-clean
|
|||
git-clone
|
||||
git-commit
|
||||
git-commit-tree
|
||||
git-config
|
||||
git-convert-objects
|
||||
git-count-objects
|
||||
git-cvsexportcommit
|
||||
|
@ -42,6 +43,7 @@ git-findtags
|
|||
git-fmt-merge-msg
|
||||
git-for-each-ref
|
||||
git-format-patch
|
||||
git-fsck
|
||||
git-fsck-objects
|
||||
git-gc
|
||||
git-get-tar-commit-id
|
||||
|
|
2
.mailmap
2
.mailmap
|
@ -30,7 +30,9 @@ Robert Fitzsimons <robfitz@273k.net>
|
|||
Santi Béjar <sbejar@gmail.com>
|
||||
Sean Estabrooks <seanlkml@sympatico.ca>
|
||||
Shawn O. Pearce <spearce@spearce.org>
|
||||
Theodore Ts'o <tytso@mit.edu>
|
||||
Tony Luck <tony.luck@intel.com>
|
||||
Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
|
||||
Ville Skyttä <scop@xemacs.org>
|
||||
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
|
||||
anonymous <linux@horizon.com>
|
||||
|
|
2
Documentation/.gitignore
vendored
2
Documentation/.gitignore
vendored
|
@ -4,4 +4,4 @@
|
|||
*.7
|
||||
howto-index.txt
|
||||
doc.dep
|
||||
README
|
||||
cmds-*.txt
|
||||
|
|
|
@ -71,14 +71,24 @@ doc.dep : $(wildcard *.txt) build-docdep.perl
|
|||
|
||||
-include doc.dep
|
||||
|
||||
git.7: README
|
||||
cmds_txt = cmds-ancillaryinterrogators.txt \
|
||||
cmds-ancillarymanipulators.txt \
|
||||
cmds-mainporcelain.txt \
|
||||
cmds-plumbinginterrogators.txt \
|
||||
cmds-plumbingmanipulators.txt \
|
||||
cmds-synchingrepositories.txt \
|
||||
cmds-synchelpers.txt \
|
||||
cmds-purehelpers.txt \
|
||||
cmds-foreignscminterface.txt
|
||||
|
||||
README: ../README
|
||||
cp $< $@
|
||||
$(cmds_txt): cmd-list.perl $(MAN1_TXT)
|
||||
perl ./cmd-list.perl
|
||||
|
||||
git.7 git.html: git.txt core-intro.txt
|
||||
|
||||
clean:
|
||||
rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep README
|
||||
rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep
|
||||
rm -f $(cmds_txt)
|
||||
|
||||
%.html : %.txt
|
||||
asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
|
||||
|
@ -89,8 +99,6 @@ clean:
|
|||
%.xml : %.txt
|
||||
asciidoc -b docbook -d manpage -f asciidoc.conf $<
|
||||
|
||||
git.html: git.txt README
|
||||
|
||||
glossary.html : glossary.txt sort_glossary.pl
|
||||
cat $< | \
|
||||
perl sort_glossary.pl | \
|
||||
|
|
|
@ -23,7 +23,8 @@ probably need to split up your commit to finer grained pieces.
|
|||
|
||||
Oh, another thing. I am picky about whitespaces. Make sure your
|
||||
changes do not trigger errors with the sample pre-commit hook shipped
|
||||
in templates/hooks--pre-commit.
|
||||
in templates/hooks--pre-commit. To help ensure this does not happen,
|
||||
run git diff --check on your changes before you commit.
|
||||
|
||||
|
||||
(2) Generate your patch using git tools out of your commits.
|
||||
|
@ -72,7 +73,9 @@ other than the commit message itself. Place such "cover letter"
|
|||
material between the three dash lines and the diffstat.
|
||||
|
||||
Do not attach the patch as a MIME attachment, compressed or not.
|
||||
Do not let your e-mail client send quoted-printable. Many
|
||||
Do not let your e-mail client send quoted-printable. Do not let
|
||||
your e-mail client send format=flowed which would destroy
|
||||
whitespaces in your patches. Many
|
||||
popular e-mail applications will not always transmit a MIME
|
||||
attachment as plain text, making it impossible to comment on
|
||||
your code. A MIME attachment also takes a bit more time to
|
||||
|
@ -312,3 +315,19 @@ settings but I haven't tried, yet.
|
|||
mail.identity.default.compose_html => false
|
||||
mail.identity.id?.compose_html => false
|
||||
|
||||
|
||||
|
||||
Gnus
|
||||
----
|
||||
|
||||
'|' in the *Summary* buffer can be used to pipe the current
|
||||
message to an external program, and this is a handy way to drive
|
||||
"git am". However, if the message is MIME encoded, what is
|
||||
piped into the program is the representation you see in your
|
||||
*Article* buffer after unwrapping MIME. This is often not what
|
||||
you would want for two reasons. It tends to screw up non ASCII
|
||||
characters (most notably in people's names), and also
|
||||
whitespaces (fatal in patches). Running 'C-u g' to display the
|
||||
message in raw form before using '|' to run the pipe can work
|
||||
this problem around.
|
||||
|
||||
|
|
186
Documentation/cmd-list.perl
Executable file
186
Documentation/cmd-list.perl
Executable file
|
@ -0,0 +1,186 @@
|
|||
#
|
||||
|
||||
sub format_one {
|
||||
my ($out, $name) = @_;
|
||||
my ($state, $description);
|
||||
open I, '<', "$name.txt" or die "No such file $name.txt";
|
||||
while (<I>) {
|
||||
if (/^NAME$/) {
|
||||
$state = 1;
|
||||
next;
|
||||
}
|
||||
if ($state == 1 && /^----$/) {
|
||||
$state = 2;
|
||||
next;
|
||||
}
|
||||
next if ($state != 2);
|
||||
chomp;
|
||||
$description = $_;
|
||||
last;
|
||||
}
|
||||
close I;
|
||||
if (!defined $description) {
|
||||
die "No description found in $name.txt";
|
||||
}
|
||||
if (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) {
|
||||
print $out "gitlink:$name\[1\]::\n";
|
||||
print $out "\t$text.\n\n";
|
||||
}
|
||||
else {
|
||||
die "Description does not match $name: $description";
|
||||
}
|
||||
}
|
||||
|
||||
my %cmds = ();
|
||||
while (<DATA>) {
|
||||
next if /^#/;
|
||||
|
||||
chomp;
|
||||
my ($name, $cat) = /^(\S+)\s+(.*)$/;
|
||||
push @{$cmds{$cat}}, $name;
|
||||
}
|
||||
|
||||
for my $cat (qw(ancillaryinterrogators
|
||||
ancillarymanipulators
|
||||
mainporcelain
|
||||
plumbinginterrogators
|
||||
plumbingmanipulators
|
||||
synchingrepositories
|
||||
foreignscminterface
|
||||
purehelpers
|
||||
synchelpers)) {
|
||||
my $out = "cmds-$cat.txt";
|
||||
open O, '>', "$out+" or die "Cannot open output file $out+";
|
||||
for (@{$cmds{$cat}}) {
|
||||
format_one(\*O, $_);
|
||||
}
|
||||
close O;
|
||||
rename "$out+", "$out";
|
||||
}
|
||||
|
||||
__DATA__
|
||||
git-add mainporcelain
|
||||
git-am mainporcelain
|
||||
git-annotate ancillaryinterrogators
|
||||
git-applymbox ancillaryinterrogators
|
||||
git-applypatch purehelpers
|
||||
git-apply plumbingmanipulators
|
||||
git-archimport foreignscminterface
|
||||
git-archive mainporcelain
|
||||
git-bisect mainporcelain
|
||||
git-blame ancillaryinterrogators
|
||||
git-branch mainporcelain
|
||||
git-cat-file plumbinginterrogators
|
||||
git-checkout-index plumbingmanipulators
|
||||
git-checkout mainporcelain
|
||||
git-check-ref-format purehelpers
|
||||
git-cherry ancillaryinterrogators
|
||||
git-cherry-pick mainporcelain
|
||||
git-clean mainporcelain
|
||||
git-clone mainporcelain
|
||||
git-commit mainporcelain
|
||||
git-commit-tree plumbingmanipulators
|
||||
git-convert-objects ancillarymanipulators
|
||||
git-count-objects ancillaryinterrogators
|
||||
git-cvsexportcommit foreignscminterface
|
||||
git-cvsimport foreignscminterface
|
||||
git-cvsserver foreignscminterface
|
||||
git-daemon synchingrepositories
|
||||
git-describe mainporcelain
|
||||
git-diff-files plumbinginterrogators
|
||||
git-diff-index plumbinginterrogators
|
||||
git-diff mainporcelain
|
||||
git-diff-stages plumbinginterrogators
|
||||
git-diff-tree plumbinginterrogators
|
||||
git-fetch mainporcelain
|
||||
git-fetch-pack synchingrepositories
|
||||
git-fmt-merge-msg purehelpers
|
||||
git-for-each-ref plumbinginterrogators
|
||||
git-format-patch mainporcelain
|
||||
git-fsck ancillaryinterrogators
|
||||
git-gc mainporcelain
|
||||
git-get-tar-commit-id ancillaryinterrogators
|
||||
git-grep mainporcelain
|
||||
git-hash-object plumbingmanipulators
|
||||
git-http-fetch synchelpers
|
||||
git-http-push synchelpers
|
||||
git-imap-send foreignscminterface
|
||||
git-index-pack plumbingmanipulators
|
||||
git-init mainporcelain
|
||||
git-instaweb ancillaryinterrogators
|
||||
gitk mainporcelain
|
||||
git-local-fetch synchingrepositories
|
||||
git-log mainporcelain
|
||||
git-lost-found ancillarymanipulators
|
||||
git-ls-files plumbinginterrogators
|
||||
git-ls-remote plumbinginterrogators
|
||||
git-ls-tree plumbinginterrogators
|
||||
git-mailinfo purehelpers
|
||||
git-mailsplit purehelpers
|
||||
git-merge-base plumbinginterrogators
|
||||
git-merge-file plumbingmanipulators
|
||||
git-merge-index plumbingmanipulators
|
||||
git-merge mainporcelain
|
||||
git-merge-one-file purehelpers
|
||||
git-merge-tree ancillaryinterrogators
|
||||
git-mktag plumbingmanipulators
|
||||
git-mktree plumbingmanipulators
|
||||
git-mv mainporcelain
|
||||
git-name-rev plumbinginterrogators
|
||||
git-pack-objects plumbingmanipulators
|
||||
git-pack-redundant plumbinginterrogators
|
||||
git-pack-refs ancillarymanipulators
|
||||
git-parse-remote synchelpers
|
||||
git-patch-id purehelpers
|
||||
git-peek-remote purehelpers
|
||||
git-prune ancillarymanipulators
|
||||
git-prune-packed plumbingmanipulators
|
||||
git-pull mainporcelain
|
||||
git-push mainporcelain
|
||||
git-quiltimport foreignscminterface
|
||||
git-read-tree plumbingmanipulators
|
||||
git-rebase mainporcelain
|
||||
git-receive-pack synchelpers
|
||||
git-reflog ancillarymanipulators
|
||||
git-relink ancillarymanipulators
|
||||
git-repack ancillarymanipulators
|
||||
git-config ancillarymanipulators
|
||||
git-request-pull foreignscminterface
|
||||
git-rerere ancillaryinterrogators
|
||||
git-reset mainporcelain
|
||||
git-resolve mainporcelain
|
||||
git-revert mainporcelain
|
||||
git-rev-list plumbinginterrogators
|
||||
git-rev-parse ancillaryinterrogators
|
||||
git-rm mainporcelain
|
||||
git-runstatus ancillaryinterrogators
|
||||
git-send-email foreignscminterface
|
||||
git-send-pack synchingrepositories
|
||||
git-shell synchelpers
|
||||
git-shortlog mainporcelain
|
||||
git-show mainporcelain
|
||||
git-show-branch ancillaryinterrogators
|
||||
git-show-index plumbinginterrogators
|
||||
git-show-ref plumbinginterrogators
|
||||
git-sh-setup purehelpers
|
||||
git-ssh-fetch synchingrepositories
|
||||
git-ssh-upload synchingrepositories
|
||||
git-status mainporcelain
|
||||
git-stripspace purehelpers
|
||||
git-svn foreignscminterface
|
||||
git-svnimport foreignscminterface
|
||||
git-symbolic-ref plumbingmanipulators
|
||||
git-tag mainporcelain
|
||||
git-tar-tree plumbinginterrogators
|
||||
git-unpack-file plumbinginterrogators
|
||||
git-unpack-objects plumbingmanipulators
|
||||
git-update-index plumbingmanipulators
|
||||
git-update-ref plumbingmanipulators
|
||||
git-update-server-info synchingrepositories
|
||||
git-upload-archive synchelpers
|
||||
git-upload-pack synchelpers
|
||||
git-var plumbinginterrogators
|
||||
git-verify-pack plumbinginterrogators
|
||||
git-verify-tag ancillaryinterrogators
|
||||
git-whatchanged ancillaryinterrogators
|
||||
git-write-tree plumbingmanipulators
|
|
@ -2,21 +2,84 @@ CONFIGURATION FILE
|
|||
------------------
|
||||
|
||||
The git configuration file contains a number of variables that affect
|
||||
the git command's behavior. They can be used by both the git plumbing
|
||||
the git command's behavior. `.git/config` file for each repository
|
||||
is used to store the information for that repository, and
|
||||
`$HOME/.gitconfig` is used to store per user information to give
|
||||
fallback values for `.git/config` file.
|
||||
|
||||
They can be used by both the git plumbing
|
||||
and the porcelains. The variables are divided into sections, where
|
||||
in the fully qualified variable name the variable itself is the last
|
||||
dot-separated segment and the section name is everything before the last
|
||||
dot. The variable names are case-insensitive and only alphanumeric
|
||||
characters are allowed. Some variables may appear multiple times.
|
||||
|
||||
Syntax
|
||||
~~~~~~
|
||||
|
||||
The syntax is fairly flexible and permissive; whitespaces are mostly
|
||||
ignored. The '#' and ';' characters begin comments to the end of line,
|
||||
blank lines are ignored, lines containing strings enclosed in square
|
||||
brackets start sections and all the other lines are recognized
|
||||
as setting variables, in the form 'name = value'. If there is no equal
|
||||
sign on the line, the entire line is taken as 'name' and the variable
|
||||
is recognized as boolean "true". String values may be entirely or partially
|
||||
enclosed in double quotes; some variables may require special value format.
|
||||
ignored. The '#' and ';' characters begin comments to the end of line,
|
||||
blank lines are ignored.
|
||||
|
||||
The file consists of sections and variables. A section begins with
|
||||
the name of the section in square brackets and continues until the next
|
||||
section begins. Section names are not case sensitive. Only alphanumeric
|
||||
characters, '`-`' and '`.`' are allowed in section names. Each variable
|
||||
must belong to some section, which means that there must be section
|
||||
header before first setting of a variable.
|
||||
|
||||
Sections can be further divided into subsections. To begin a subsection
|
||||
put its name in double quotes, separated by space from the section name,
|
||||
in the section header, like in example below:
|
||||
|
||||
--------
|
||||
[section "subsection"]
|
||||
|
||||
--------
|
||||
|
||||
Subsection names can contain any characters except newline (doublequote
|
||||
'`"`' and backslash have to be escaped as '`\"`' and '`\\`',
|
||||
respecitvely) and are case sensitive. Section header cannot span multiple
|
||||
lines. Variables may belong directly to a section or to a given subsection.
|
||||
You can have `[section]` if you have `[section "subsection"]`, but you
|
||||
don't need to.
|
||||
|
||||
There is also (case insensitive) alternative `[section.subsection]` syntax.
|
||||
In this syntax subsection names follow the same restrictions as for section
|
||||
name.
|
||||
|
||||
All the other lines are recognized as setting variables, in the form
|
||||
'name = value'. If there is no equal sign on the line, the entire line
|
||||
is taken as 'name' and the variable is recognized as boolean "true".
|
||||
The variable names are case-insensitive and only alphanumeric
|
||||
characters and '`-`' are allowed. There can be more than one value
|
||||
for a given variable; we say then that variable is multivalued.
|
||||
|
||||
Leading and trailing whitespace in a variable value is discarded.
|
||||
Internal whitespace within a variable value is retained verbatim.
|
||||
|
||||
The values following the equals sign in variable assign are all either
|
||||
a string, an integer, or a boolean. Boolean values may be given as yes/no,
|
||||
0/1 or true/false. Case is not significant in boolean values, when
|
||||
converting value to the canonical form using '--bool' type specifier;
|
||||
`git-config` will ensure that the output is "true" or "false".
|
||||
|
||||
String values may be entirely or partially enclosed in double quotes.
|
||||
You need to enclose variable value in double quotes if you want to
|
||||
preserve leading or trailing whitespace, or if variable value contains
|
||||
beginning of comment characters (if it contains '#' or ';').
|
||||
Double quote '`"`' and backslash '`\`' characters in variable value must
|
||||
be escaped: use '`\"`' for '`"`' and '`\\`' for '`\`'.
|
||||
|
||||
The following escape sequences (beside '`\"`' and '`\\`') are recognized:
|
||||
'`\n`' for newline character (NL), '`\t`' for horizontal tabulation (HT, TAB)
|
||||
and '`\b`' for backspace (BS). No other char escape sequence, nor octal
|
||||
char sequences are valid.
|
||||
|
||||
Variable value ending in a '`\`' is continued on the next line in the
|
||||
customary UNIX fashion.
|
||||
|
||||
Some variables may require special value format.
|
||||
|
||||
Example
|
||||
~~~~~~~
|
||||
|
@ -35,6 +98,10 @@ Example
|
|||
remote = origin
|
||||
merge = refs/heads/devel
|
||||
|
||||
# Proxy settings
|
||||
[core]
|
||||
gitProxy="ssh" for "ssh://kernel.org/"
|
||||
gitProxy=default-proxy ; for the rest
|
||||
|
||||
Variables
|
||||
~~~~~~~~~
|
||||
|
@ -183,10 +250,15 @@ color.branch.<slot>::
|
|||
Use customized color for branch coloration. `<slot>` is one of
|
||||
`current` (the current branch), `local` (a local branch),
|
||||
`remote` (a tracking branch in refs/remotes/), `plain` (other
|
||||
refs), or `reset` (the normal terminal color). The value for
|
||||
these configuration variables can be one of: `normal`, `bold`,
|
||||
`dim`, `ul`, `blink`, `reverse`, `reset`, `black`, `red`,
|
||||
`green`, `yellow`, `blue`, `magenta`, `cyan`, or `white`.
|
||||
refs).
|
||||
+
|
||||
The value for these configuration variables is a list of colors (at most
|
||||
two) and attributes (at most one), separated by spaces. The colors
|
||||
accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`,
|
||||
`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`,
|
||||
`blink` and `reverse`. The first color given is the foreground; the
|
||||
second is the background. The position of the attribute, if any,
|
||||
doesn't matter.
|
||||
|
||||
color.diff::
|
||||
When true (or `always`), always use colors in patch.
|
||||
|
@ -194,12 +266,13 @@ color.diff::
|
|||
colors only when the output is to the terminal.
|
||||
|
||||
color.diff.<slot>::
|
||||
Use customized color for diff colorization. `<slot>`
|
||||
specifies which part of the patch to use the specified
|
||||
color, and is one of `plain` (context text), `meta`
|
||||
(metainformation), `frag` (hunk header), `old` (removed
|
||||
lines), or `new` (added lines). The values of these
|
||||
variables may be specified as in color.branch.<slot>.
|
||||
Use customized color for diff colorization. `<slot>` specifies
|
||||
which part of the patch to use the specified color, and is one
|
||||
of `plain` (context text), `meta` (metainformation), `frag`
|
||||
(hunk header), `old` (removed lines), `new` (added lines),
|
||||
`commit` (commit headers), or `whitespace` (highlighting dubious
|
||||
whitespace). The values of these variables may be specified as
|
||||
in color.branch.<slot>.
|
||||
|
||||
color.pager::
|
||||
A boolean to enable/disable colored output when the pager is in
|
||||
|
@ -228,6 +301,16 @@ diff.renames::
|
|||
will enable basic rename detection. If set to "copies" or
|
||||
"copy", it will detect copies, as well.
|
||||
|
||||
fetch.unpackLimit::
|
||||
If the number of objects fetched over the git native
|
||||
transfer is below this
|
||||
limit, then the objects will be unpacked into loose object
|
||||
files. However if the number of received objects equals or
|
||||
exceeds this limit then the received pack will be stored as
|
||||
a pack, after adding any missing delta bases. Storing the
|
||||
pack from a push can make the push operation complete faster,
|
||||
especially on slow filesystems.
|
||||
|
||||
format.headers::
|
||||
Additional email headers to include in a patch to be submitted
|
||||
by mail. See gitlink:git-format-patch[1].
|
||||
|
@ -321,6 +404,13 @@ merge.summary::
|
|||
Whether to include summaries of merged commits in newly created
|
||||
merge commit messages. False by default.
|
||||
|
||||
merge.verbosity::
|
||||
Controls the amount of output shown by the recursive merge
|
||||
strategy. Level 0 outputs nothing except a final error
|
||||
message if conflicts were detected. Level 1 outputs only
|
||||
conflicts, 2 outputs conflicts and file changes. Level 5 and
|
||||
above outputs debugging information. The default is level 2.
|
||||
|
||||
pack.window::
|
||||
The size of the window used by gitlink:git-pack-objects[1] when no
|
||||
window size is given on the command line. Defaults to 10.
|
||||
|
@ -344,6 +434,14 @@ remote.<name>.push::
|
|||
The default set of "refspec" for gitlink:git-push[1]. See
|
||||
gitlink:git-push[1].
|
||||
|
||||
remote.<name>.receivepack::
|
||||
The default program to execute on the remote side when pushing. See
|
||||
option \--exec of gitlink:git-push[1].
|
||||
|
||||
remote.<name>.uploadpack::
|
||||
The default program to execute on the remote side when fetching. See
|
||||
option \--exec of gitlink:git-fetch-pack[1].
|
||||
|
||||
repack.usedeltabaseoffset::
|
||||
Allow gitlink:git-repack[1] to create packs that uses
|
||||
delta-base offset. Defaults to false.
|
||||
|
@ -377,6 +475,13 @@ user.name::
|
|||
Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
|
||||
environment variables. See gitlink:git-commit-tree[1].
|
||||
|
||||
user.signingkey::
|
||||
If gitlink:git-tag[1] is not selecting the key you want it to
|
||||
automatically when creating a signed tag, you can override the
|
||||
default selection with this variable. This option is passed
|
||||
unchanged to gpg's --local-user parameter, so you may specify a key
|
||||
using any method that gpg supports.
|
||||
|
||||
whatchanged.difftree::
|
||||
The default gitlink:git-diff-tree[1] arguments to be used
|
||||
for gitlink:git-whatchanged[1].
|
||||
|
@ -400,3 +505,8 @@ receive.denyNonFastForwards::
|
|||
even if that push is forced. This configuration variable is
|
||||
set when initializing a shared repository.
|
||||
|
||||
transfer.unpackLimit::
|
||||
When `fetch.unpackLimit` or `receive.unpackLimit` are
|
||||
not set, the value of this variable is used instead.
|
||||
|
||||
|
||||
|
|
590
Documentation/core-intro.txt
Normal file
590
Documentation/core-intro.txt
Normal file
|
@ -0,0 +1,590 @@
|
|||
////////////////////////////////////////////////////////////////
|
||||
|
||||
GIT - the stupid content tracker
|
||||
|
||||
////////////////////////////////////////////////////////////////
|
||||
|
||||
"git" can mean anything, depending on your mood.
|
||||
|
||||
- random three-letter combination that is pronounceable, and not
|
||||
actually used by any common UNIX command. The fact that it is a
|
||||
mispronunciation of "get" may or may not be relevant.
|
||||
- stupid. contemptible and despicable. simple. Take your pick from the
|
||||
dictionary of slang.
|
||||
- "global information tracker": you're in a good mood, and it actually
|
||||
works for you. Angels sing, and a light suddenly fills the room.
|
||||
- "goddamn idiotic truckload of sh*t": when it breaks
|
||||
|
||||
This is a (not so) stupid but extremely fast directory content manager.
|
||||
It doesn't do a whole lot at its core, but what it 'does' do is track
|
||||
directory contents efficiently.
|
||||
|
||||
There are two object abstractions: the "object database", and the
|
||||
"current directory cache" aka "index".
|
||||
|
||||
The Object Database
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
The object database is literally just a content-addressable collection
|
||||
of objects. All objects are named by their content, which is
|
||||
approximated by the SHA1 hash of the object itself. Objects may refer
|
||||
to other objects (by referencing their SHA1 hash), and so you can
|
||||
build up a hierarchy of objects.
|
||||
|
||||
All objects have a statically determined "type" aka "tag", which is
|
||||
determined at object creation time, and which identifies the format of
|
||||
the object (i.e. how it is used, and how it can refer to other
|
||||
objects). There are currently four different object types: "blob",
|
||||
"tree", "commit" and "tag".
|
||||
|
||||
A "blob" object cannot refer to any other object, and is, like the type
|
||||
implies, a pure storage object containing some user data. It is used to
|
||||
actually store the file data, i.e. a blob object is associated with some
|
||||
particular version of some file.
|
||||
|
||||
A "tree" object is an object that ties one or more "blob" objects into a
|
||||
directory structure. In addition, a tree object can refer to other tree
|
||||
objects, thus creating a directory hierarchy.
|
||||
|
||||
A "commit" object ties such directory hierarchies together into
|
||||
a DAG of revisions - each "commit" is associated with exactly one tree
|
||||
(the directory hierarchy at the time of the commit). In addition, a
|
||||
"commit" refers to one or more "parent" commit objects that describe the
|
||||
history of how we arrived at that directory hierarchy.
|
||||
|
||||
As a special case, a commit object with no parents is called the "root"
|
||||
object, and is the point of an initial project commit. Each project
|
||||
must have at least one root, and while you can tie several different
|
||||
root objects together into one project by creating a commit object which
|
||||
has two or more separate roots as its ultimate parents, that's probably
|
||||
just going to confuse people. So aim for the notion of "one root object
|
||||
per project", even if git itself does not enforce that.
|
||||
|
||||
A "tag" object symbolically identifies and can be used to sign other
|
||||
objects. It contains the identifier and type of another object, a
|
||||
symbolic name (of course!) and, optionally, a signature.
|
||||
|
||||
Regardless of object type, all objects share the following
|
||||
characteristics: they are all deflated with zlib, and have a header
|
||||
that not only specifies their type, but also provides size information
|
||||
about the data in the object. It's worth noting that the SHA1 hash
|
||||
that is used to name the object is the hash of the original data
|
||||
plus this header, so `sha1sum` 'file' does not match the object name
|
||||
for 'file'.
|
||||
(Historical note: in the dawn of the age of git the hash
|
||||
was the sha1 of the 'compressed' object.)
|
||||
|
||||
As a result, the general consistency of an object can always be tested
|
||||
independently of the contents or the type of the object: all objects can
|
||||
be validated by verifying that (a) their hashes match the content of the
|
||||
file and (b) the object successfully inflates to a stream of bytes that
|
||||
forms a sequence of <ascii type without space> + <space> + <ascii decimal
|
||||
size> + <byte\0> + <binary object data>.
|
||||
|
||||
The structured objects can further have their structure and
|
||||
connectivity to other objects verified. This is generally done with
|
||||
the `git-fsck` program, which generates a full dependency graph
|
||||
of all objects, and verifies their internal consistency (in addition
|
||||
to just verifying their superficial consistency through the hash).
|
||||
|
||||
The object types in some more detail:
|
||||
|
||||
Blob Object
|
||||
~~~~~~~~~~~
|
||||
A "blob" object is nothing but a binary blob of data, and doesn't
|
||||
refer to anything else. There is no signature or any other
|
||||
verification of the data, so while the object is consistent (it 'is'
|
||||
indexed by its sha1 hash, so the data itself is certainly correct), it
|
||||
has absolutely no other attributes. No name associations, no
|
||||
permissions. It is purely a blob of data (i.e. normally "file
|
||||
contents").
|
||||
|
||||
In particular, since the blob is entirely defined by its data, if two
|
||||
files in a directory tree (or in multiple different versions of the
|
||||
repository) have the same contents, they will share the same blob
|
||||
object. The object is totally independent of its location in the
|
||||
directory tree, and renaming a file does not change the object that
|
||||
file is associated with in any way.
|
||||
|
||||
A blob is typically created when gitlink:git-update-index[1]
|
||||
is run, and its data can be accessed by gitlink:git-cat-file[1].
|
||||
|
||||
Tree Object
|
||||
~~~~~~~~~~~
|
||||
The next hierarchical object type is the "tree" object. A tree object
|
||||
is a list of mode/name/blob data, sorted by name. Alternatively, the
|
||||
mode data may specify a directory mode, in which case instead of
|
||||
naming a blob, that name is associated with another TREE object.
|
||||
|
||||
Like the "blob" object, a tree object is uniquely determined by the
|
||||
set contents, and so two separate but identical trees will always
|
||||
share the exact same object. This is true at all levels, i.e. it's
|
||||
true for a "leaf" tree (which does not refer to any other trees, only
|
||||
blobs) as well as for a whole subdirectory.
|
||||
|
||||
For that reason a "tree" object is just a pure data abstraction: it
|
||||
has no history, no signatures, no verification of validity, except
|
||||
that since the contents are again protected by the hash itself, we can
|
||||
trust that the tree is immutable and its contents never change.
|
||||
|
||||
So you can trust the contents of a tree to be valid, the same way you
|
||||
can trust the contents of a blob, but you don't know where those
|
||||
contents 'came' from.
|
||||
|
||||
Side note on trees: since a "tree" object is a sorted list of
|
||||
"filename+content", you can create a diff between two trees without
|
||||
actually having to unpack two trees. Just ignore all common parts,
|
||||
and your diff will look right. In other words, you can effectively
|
||||
(and efficiently) tell the difference between any two random trees by
|
||||
O(n) where "n" is the size of the difference, rather than the size of
|
||||
the tree.
|
||||
|
||||
Side note 2 on trees: since the name of a "blob" depends entirely and
|
||||
exclusively on its contents (i.e. there are no names or permissions
|
||||
involved), you can see trivial renames or permission changes by
|
||||
noticing that the blob stayed the same. However, renames with data
|
||||
changes need a smarter "diff" implementation.
|
||||
|
||||
A tree is created with gitlink:git-write-tree[1] and
|
||||
its data can be accessed by gitlink:git-ls-tree[1].
|
||||
Two trees can be compared with gitlink:git-diff-tree[1].
|
||||
|
||||
Commit Object
|
||||
~~~~~~~~~~~~~
|
||||
The "commit" object is an object that introduces the notion of
|
||||
history into the picture. In contrast to the other objects, it
|
||||
doesn't just describe the physical state of a tree, it describes how
|
||||
we got there, and why.
|
||||
|
||||
A "commit" is defined by the tree-object that it results in, the
|
||||
parent commits (zero, one or more) that led up to that point, and a
|
||||
comment on what happened. Again, a commit is not trusted per se:
|
||||
the contents are well-defined and "safe" due to the cryptographically
|
||||
strong signatures at all levels, but there is no reason to believe
|
||||
that the tree is "good" or that the merge information makes sense.
|
||||
The parents do not have to actually have any relationship with the
|
||||
result, for example.
|
||||
|
||||
Note on commits: unlike real SCM's, commits do not contain
|
||||
rename information or file mode change information. All of that is
|
||||
implicit in the trees involved (the result tree, and the result trees
|
||||
of the parents), and describing that makes no sense in this idiotic
|
||||
file manager.
|
||||
|
||||
A commit is created with gitlink:git-commit-tree[1] and
|
||||
its data can be accessed by gitlink:git-cat-file[1].
|
||||
|
||||
Trust
|
||||
~~~~~
|
||||
An aside on the notion of "trust". Trust is really outside the scope
|
||||
of "git", but it's worth noting a few things. First off, since
|
||||
everything is hashed with SHA1, you 'can' trust that an object is
|
||||
intact and has not been messed with by external sources. So the name
|
||||
of an object uniquely identifies a known state - just not a state that
|
||||
you may want to trust.
|
||||
|
||||
Furthermore, since the SHA1 signature of a commit refers to the
|
||||
SHA1 signatures of the tree it is associated with and the signatures
|
||||
of the parent, a single named commit specifies uniquely a whole set
|
||||
of history, with full contents. You can't later fake any step of the
|
||||
way once you have the name of a commit.
|
||||
|
||||
So to introduce some real trust in the system, the only thing you need
|
||||
to do is to digitally sign just 'one' special note, which includes the
|
||||
name of a top-level commit. Your digital signature shows others
|
||||
that you trust that commit, and the immutability of the history of
|
||||
commits tells others that they can trust the whole history.
|
||||
|
||||
In other words, you can easily validate a whole archive by just
|
||||
sending out a single email that tells the people the name (SHA1 hash)
|
||||
of the top commit, and digitally sign that email using something
|
||||
like GPG/PGP.
|
||||
|
||||
To assist in this, git also provides the tag object...
|
||||
|
||||
Tag Object
|
||||
~~~~~~~~~~
|
||||
Git provides the "tag" object to simplify creating, managing and
|
||||
exchanging symbolic and signed tokens. The "tag" object at its
|
||||
simplest simply symbolically identifies another object by containing
|
||||
the sha1, type and symbolic name.
|
||||
|
||||
However it can optionally contain additional signature information
|
||||
(which git doesn't care about as long as there's less than 8k of
|
||||
it). This can then be verified externally to git.
|
||||
|
||||
Note that despite the tag features, "git" itself only handles content
|
||||
integrity; the trust framework (and signature provision and
|
||||
verification) has to come from outside.
|
||||
|
||||
A tag is created with gitlink:git-mktag[1],
|
||||
its data can be accessed by gitlink:git-cat-file[1],
|
||||
and the signature can be verified by
|
||||
gitlink:git-verify-tag[1].
|
||||
|
||||
|
||||
The "index" aka "Current Directory Cache"
|
||||
-----------------------------------------
|
||||
The index is a simple binary file, which contains an efficient
|
||||
representation of a virtual directory content at some random time. It
|
||||
does so by a simple array that associates a set of names, dates,
|
||||
permissions and content (aka "blob") objects together. The cache is
|
||||
always kept ordered by name, and names are unique (with a few very
|
||||
specific rules) at any point in time, but the cache has no long-term
|
||||
meaning, and can be partially updated at any time.
|
||||
|
||||
In particular, the index certainly does not need to be consistent with
|
||||
the current directory contents (in fact, most operations will depend on
|
||||
different ways to make the index 'not' be consistent with the directory
|
||||
hierarchy), but it has three very important attributes:
|
||||
|
||||
'(a) it can re-generate the full state it caches (not just the
|
||||
directory structure: it contains pointers to the "blob" objects so
|
||||
that it can regenerate the data too)'
|
||||
|
||||
As a special case, there is a clear and unambiguous one-way mapping
|
||||
from a current directory cache to a "tree object", which can be
|
||||
efficiently created from just the current directory cache without
|
||||
actually looking at any other data. So a directory cache at any one
|
||||
time uniquely specifies one and only one "tree" object (but has
|
||||
additional data to make it easy to match up that tree object with what
|
||||
has happened in the directory)
|
||||
|
||||
'(b) it has efficient methods for finding inconsistencies between that
|
||||
cached state ("tree object waiting to be instantiated") and the
|
||||
current state.'
|
||||
|
||||
'(c) it can additionally efficiently represent information about merge
|
||||
conflicts between different tree objects, allowing each pathname to be
|
||||
associated with sufficient information about the trees involved that
|
||||
you can create a three-way merge between them.'
|
||||
|
||||
Those are the three ONLY things that the directory cache does. It's a
|
||||
cache, and the normal operation is to re-generate it completely from a
|
||||
known tree object, or update/compare it with a live tree that is being
|
||||
developed. If you blow the directory cache away entirely, you generally
|
||||
haven't lost any information as long as you have the name of the tree
|
||||
that it described.
|
||||
|
||||
At the same time, the index is at the same time also the
|
||||
staging area for creating new trees, and creating a new tree always
|
||||
involves a controlled modification of the index file. In particular,
|
||||
the index file can have the representation of an intermediate tree that
|
||||
has not yet been instantiated. So the index can be thought of as a
|
||||
write-back cache, which can contain dirty information that has not yet
|
||||
been written back to the backing store.
|
||||
|
||||
|
||||
|
||||
The Workflow
|
||||
------------
|
||||
Generally, all "git" operations work on the index file. Some operations
|
||||
work *purely* on the index file (showing the current state of the
|
||||
index), but most operations move data to and from the index file. Either
|
||||
from the database or from the working directory. Thus there are four
|
||||
main combinations:
|
||||
|
||||
1) working directory -> index
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You update the index with information from the working directory with
|
||||
the gitlink:git-update-index[1] command. You
|
||||
generally update the index information by just specifying the filename
|
||||
you want to update, like so:
|
||||
|
||||
git-update-index filename
|
||||
|
||||
but to avoid common mistakes with filename globbing etc, the command
|
||||
will not normally add totally new entries or remove old entries,
|
||||
i.e. it will normally just update existing cache entries.
|
||||
|
||||
To tell git that yes, you really do realize that certain files no
|
||||
longer exist, or that new files should be added, you
|
||||
should use the `--remove` and `--add` flags respectively.
|
||||
|
||||
NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
|
||||
necessarily be removed: if the files still exist in your directory
|
||||
structure, the index will be updated with their new status, not
|
||||
removed. The only thing `--remove` means is that update-cache will be
|
||||
considering a removed file to be a valid thing, and if the file really
|
||||
does not exist any more, it will update the index accordingly.
|
||||
|
||||
As a special case, you can also do `git-update-index --refresh`, which
|
||||
will refresh the "stat" information of each index to match the current
|
||||
stat information. It will 'not' update the object status itself, and
|
||||
it will only update the fields that are used to quickly test whether
|
||||
an object still matches its old backing store object.
|
||||
|
||||
2) index -> object database
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You write your current index file to a "tree" object with the program
|
||||
|
||||
git-write-tree
|
||||
|
||||
that doesn't come with any options - it will just write out the
|
||||
current index into the set of tree objects that describe that state,
|
||||
and it will return the name of the resulting top-level tree. You can
|
||||
use that tree to re-generate the index at any time by going in the
|
||||
other direction:
|
||||
|
||||
3) object database -> index
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You read a "tree" file from the object database, and use that to
|
||||
populate (and overwrite - don't do this if your index contains any
|
||||
unsaved state that you might want to restore later!) your current
|
||||
index. Normal operation is just
|
||||
|
||||
git-read-tree <sha1 of tree>
|
||||
|
||||
and your index file will now be equivalent to the tree that you saved
|
||||
earlier. However, that is only your 'index' file: your working
|
||||
directory contents have not been modified.
|
||||
|
||||
4) index -> working directory
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You update your working directory from the index by "checking out"
|
||||
files. This is not a very common operation, since normally you'd just
|
||||
keep your files updated, and rather than write to your working
|
||||
directory, you'd tell the index files about the changes in your
|
||||
working directory (i.e. `git-update-index`).
|
||||
|
||||
However, if you decide to jump to a new version, or check out somebody
|
||||
else's version, or just restore a previous tree, you'd populate your
|
||||
index file with read-tree, and then you need to check out the result
|
||||
with
|
||||
|
||||
git-checkout-index filename
|
||||
|
||||
or, if you want to check out all of the index, use `-a`.
|
||||
|
||||
NOTE! git-checkout-index normally refuses to overwrite old files, so
|
||||
if you have an old version of the tree already checked out, you will
|
||||
need to use the "-f" flag ('before' the "-a" flag or the filename) to
|
||||
'force' the checkout.
|
||||
|
||||
|
||||
Finally, there are a few odds and ends which are not purely moving
|
||||
from one representation to the other:
|
||||
|
||||
5) Tying it all together
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
To commit a tree you have instantiated with "git-write-tree", you'd
|
||||
create a "commit" object that refers to that tree and the history
|
||||
behind it - most notably the "parent" commits that preceded it in
|
||||
history.
|
||||
|
||||
Normally a "commit" has one parent: the previous state of the tree
|
||||
before a certain change was made. However, sometimes it can have two
|
||||
or more parent commits, in which case we call it a "merge", due to the
|
||||
fact that such a commit brings together ("merges") two or more
|
||||
previous states represented by other commits.
|
||||
|
||||
In other words, while a "tree" represents a particular directory state
|
||||
of a working directory, a "commit" represents that state in "time",
|
||||
and explains how we got there.
|
||||
|
||||
You create a commit object by giving it the tree that describes the
|
||||
state at the time of the commit, and a list of parents:
|
||||
|
||||
git-commit-tree <tree> -p <parent> [-p <parent2> ..]
|
||||
|
||||
and then giving the reason for the commit on stdin (either through
|
||||
redirection from a pipe or file, or by just typing it at the tty).
|
||||
|
||||
git-commit-tree will return the name of the object that represents
|
||||
that commit, and you should save it away for later use. Normally,
|
||||
you'd commit a new `HEAD` state, and while git doesn't care where you
|
||||
save the note about that state, in practice we tend to just write the
|
||||
result to the file pointed at by `.git/HEAD`, so that we can always see
|
||||
what the last committed state was.
|
||||
|
||||
Here is an ASCII art by Jon Loeliger that illustrates how
|
||||
various pieces fit together.
|
||||
|
||||
------------
|
||||
|
||||
commit-tree
|
||||
commit obj
|
||||
+----+
|
||||
| |
|
||||
| |
|
||||
V V
|
||||
+-----------+
|
||||
| Object DB |
|
||||
| Backing |
|
||||
| Store |
|
||||
+-----------+
|
||||
^
|
||||
write-tree | |
|
||||
tree obj | |
|
||||
| | read-tree
|
||||
| | tree obj
|
||||
V
|
||||
+-----------+
|
||||
| Index |
|
||||
| "cache" |
|
||||
+-----------+
|
||||
update-index ^
|
||||
blob obj | |
|
||||
| |
|
||||
checkout-index -u | | checkout-index
|
||||
stat | | blob obj
|
||||
V
|
||||
+-----------+
|
||||
| Working |
|
||||
| Directory |
|
||||
+-----------+
|
||||
|
||||
------------
|
||||
|
||||
|
||||
6) Examining the data
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can examine the data represented in the object database and the
|
||||
index with various helper tools. For every object, you can use
|
||||
gitlink:git-cat-file[1] to examine details about the
|
||||
object:
|
||||
|
||||
git-cat-file -t <objectname>
|
||||
|
||||
shows the type of the object, and once you have the type (which is
|
||||
usually implicit in where you find the object), you can use
|
||||
|
||||
git-cat-file blob|tree|commit|tag <objectname>
|
||||
|
||||
to show its contents. NOTE! Trees have binary content, and as a result
|
||||
there is a special helper for showing that content, called
|
||||
`git-ls-tree`, which turns the binary content into a more easily
|
||||
readable form.
|
||||
|
||||
It's especially instructive to look at "commit" objects, since those
|
||||
tend to be small and fairly self-explanatory. In particular, if you
|
||||
follow the convention of having the top commit name in `.git/HEAD`,
|
||||
you can do
|
||||
|
||||
git-cat-file commit HEAD
|
||||
|
||||
to see what the top commit was.
|
||||
|
||||
7) Merging multiple trees
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Git helps you do a three-way merge, which you can expand to n-way by
|
||||
repeating the merge procedure arbitrary times until you finally
|
||||
"commit" the state. The normal situation is that you'd only do one
|
||||
three-way merge (two parents), and commit it, but if you like to, you
|
||||
can do multiple parents in one go.
|
||||
|
||||
To do a three-way merge, you need the two sets of "commit" objects
|
||||
that you want to merge, use those to find the closest common parent (a
|
||||
third "commit" object), and then use those commit objects to find the
|
||||
state of the directory ("tree" object) at these points.
|
||||
|
||||
To get the "base" for the merge, you first look up the common parent
|
||||
of two commits with
|
||||
|
||||
git-merge-base <commit1> <commit2>
|
||||
|
||||
which will return you the commit they are both based on. You should
|
||||
now look up the "tree" objects of those commits, which you can easily
|
||||
do with (for example)
|
||||
|
||||
git-cat-file commit <commitname> | head -1
|
||||
|
||||
since the tree object information is always the first line in a commit
|
||||
object.
|
||||
|
||||
Once you know the three trees you are going to merge (the one
|
||||
"original" tree, aka the common case, and the two "result" trees, aka
|
||||
the branches you want to merge), you do a "merge" read into the
|
||||
index. This will complain if it has to throw away your old index contents, so you should
|
||||
make sure that you've committed those - in fact you would normally
|
||||
always do a merge against your last commit (which should thus match
|
||||
what you have in your current index anyway).
|
||||
|
||||
To do the merge, do
|
||||
|
||||
git-read-tree -m -u <origtree> <yourtree> <targettree>
|
||||
|
||||
which will do all trivial merge operations for you directly in the
|
||||
index file, and you can just write the result out with
|
||||
`git-write-tree`.
|
||||
|
||||
Historical note. We did not have `-u` facility when this
|
||||
section was first written, so we used to warn that
|
||||
the merge is done in the index file, not in your
|
||||
working tree, and your working tree will not match your
|
||||
index after this step.
|
||||
This is no longer true. The above command, thanks to `-u`
|
||||
option, updates your working tree with the merge results for
|
||||
paths that have been trivially merged.
|
||||
|
||||
|
||||
8) Merging multiple trees, continued
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Sadly, many merges aren't trivial. If there are files that have
|
||||
been added.moved or removed, or if both branches have modified the
|
||||
same file, you will be left with an index tree that contains "merge
|
||||
entries" in it. Such an index tree can 'NOT' be written out to a tree
|
||||
object, and you will have to resolve any such merge clashes using
|
||||
other tools before you can write out the result.
|
||||
|
||||
You can examine such index state with `git-ls-files --unmerged`
|
||||
command. An example:
|
||||
|
||||
------------------------------------------------
|
||||
$ git-read-tree -m $orig HEAD $target
|
||||
$ git-ls-files --unmerged
|
||||
100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c
|
||||
100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c
|
||||
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c
|
||||
------------------------------------------------
|
||||
|
||||
Each line of the `git-ls-files --unmerged` output begins with
|
||||
the blob mode bits, blob SHA1, 'stage number', and the
|
||||
filename. The 'stage number' is git's way to say which tree it
|
||||
came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`
|
||||
tree, and stage3 `$target` tree.
|
||||
|
||||
Earlier we said that trivial merges are done inside
|
||||
`git-read-tree -m`. For example, if the file did not change
|
||||
from `$orig` to `HEAD` nor `$target`, or if the file changed
|
||||
from `$orig` to `HEAD` and `$orig` to `$target` the same way,
|
||||
obviously the final outcome is what is in `HEAD`. What the
|
||||
above example shows is that file `hello.c` was changed from
|
||||
`$orig` to `HEAD` and `$orig` to `$target` in a different way.
|
||||
You could resolve this by running your favorite 3-way merge
|
||||
program, e.g. `diff3` or `merge`, on the blob objects from
|
||||
these three stages yourself, like this:
|
||||
|
||||
------------------------------------------------
|
||||
$ git-cat-file blob 263414f... >hello.c~1
|
||||
$ git-cat-file blob 06fa6a2... >hello.c~2
|
||||
$ git-cat-file blob cc44c73... >hello.c~3
|
||||
$ merge hello.c~2 hello.c~1 hello.c~3
|
||||
------------------------------------------------
|
||||
|
||||
This would leave the merge result in `hello.c~2` file, along
|
||||
with conflict markers if there are conflicts. After verifying
|
||||
the merge result makes sense, you can tell git what the final
|
||||
merge result for this file is by:
|
||||
|
||||
mv -f hello.c~2 hello.c
|
||||
git-update-index hello.c
|
||||
|
||||
When a path is in unmerged state, running `git-update-index` for
|
||||
that path tells git to mark the path resolved.
|
||||
|
||||
The above is the description of a git merge at the lowest level,
|
||||
to help you understand what conceptually happens under the hood.
|
||||
In practice, nobody, not even git itself, uses three `git-cat-file`
|
||||
for this. There is `git-merge-index` program that extracts the
|
||||
stages to temporary files and calls a "merge" script on it:
|
||||
|
||||
git-merge-index git-merge-one-file hello.c
|
||||
|
||||
and that is what higher level `git resolve` is implemented with.
|
|
@ -906,18 +906,13 @@ of it as it can automatically (which in this case is just merge the `example`
|
|||
file, which had no differences in the `mybranch` branch), and say:
|
||||
|
||||
----------------
|
||||
Trying really trivial in-index merge...
|
||||
fatal: Merge requires file-level merging
|
||||
Nope.
|
||||
...
|
||||
Auto-merging hello
|
||||
CONFLICT (content): Merge conflict in hello
|
||||
Automatic merge failed; fix up by hand
|
||||
----------------
|
||||
|
||||
which is way too verbose, but it basically tells you that it failed the
|
||||
really trivial merge ("Simple merge") and did an "Automatic merge"
|
||||
instead, but that too failed due to conflicts in `hello`.
|
||||
It tells you that it did an "Automatic merge", which
|
||||
failed due to conflicts in `hello`.
|
||||
|
||||
Not to worry. It left the (trivial) conflict in `hello` in the same form you
|
||||
should already be well used to if you've ever used CVS, so let's just
|
||||
|
@ -1129,46 +1124,26 @@ juggle multiple lines of development simultaneously. Of
|
|||
course, you will pay the price of more disk usage to hold
|
||||
multiple working trees, but disk space is cheap these days.
|
||||
|
||||
[NOTE]
|
||||
You could even pull from your own repository by
|
||||
giving '.' as <remote-repository> parameter to `git pull`. This
|
||||
is useful when you want to merge a local branch (or more, if you
|
||||
are making an Octopus) into the current branch.
|
||||
|
||||
It is likely that you will be pulling from the same remote
|
||||
repository from time to time. As a short hand, you can store
|
||||
the remote repository URL in a file under .git/remotes/
|
||||
directory, like this:
|
||||
the remote repository URL in the local repository's config file
|
||||
like this:
|
||||
|
||||
------------------------------------------------
|
||||
$ mkdir -p .git/remotes/
|
||||
$ cat >.git/remotes/linus <<\EOF
|
||||
URL: http://www.kernel.org/pub/scm/git/git.git/
|
||||
EOF
|
||||
------------------------------------------------
|
||||
|
||||
and use the filename to `git pull` instead of the full URL.
|
||||
The URL specified in such file can even be a prefix
|
||||
of a full URL, like this:
|
||||
|
||||
------------------------------------------------
|
||||
$ cat >.git/remotes/jgarzik <<\EOF
|
||||
URL: http://www.kernel.org/pub/scm/linux/git/jgarzik/
|
||||
EOF
|
||||
$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
|
||||
------------------------------------------------
|
||||
|
||||
and use the "linus" keyword with `git pull` instead of the full URL.
|
||||
|
||||
Examples.
|
||||
|
||||
. `git pull linus`
|
||||
. `git pull linus tag v0.99.1`
|
||||
. `git pull jgarzik/netdev-2.6.git/ e100`
|
||||
|
||||
the above are equivalent to:
|
||||
|
||||
. `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD`
|
||||
. `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1`
|
||||
. `git pull http://www.kernel.org/pub/.../jgarzik/netdev-2.6.git e100`
|
||||
|
||||
|
||||
How does the merge work?
|
||||
|
@ -1546,7 +1521,8 @@ on that project and has an own "public repository" goes like this:
|
|||
|
||||
1. Prepare your work repository, by `git clone` the public
|
||||
repository of the "project lead". The URL used for the
|
||||
initial cloning is stored in `.git/remotes/origin`.
|
||||
initial cloning is stored in the remote.origin.url
|
||||
configuration variable.
|
||||
|
||||
2. Prepare a public repository accessible to others, just like
|
||||
the "project lead" person does.
|
||||
|
@ -1586,14 +1562,15 @@ like this:
|
|||
1. Prepare your work repository, by `git clone` the public
|
||||
repository of the "project lead" (or a "subsystem
|
||||
maintainer", if you work on a subsystem). The URL used for
|
||||
the initial cloning is stored in `.git/remotes/origin`.
|
||||
the initial cloning is stored in the remote.origin.url
|
||||
configuration variable.
|
||||
|
||||
2. Do your work in your repository on 'master' branch.
|
||||
|
||||
3. Run `git fetch origin` from the public repository of your
|
||||
upstream every once in a while. This does only the first
|
||||
half of `git pull` but does not merge. The head of the
|
||||
public repository is stored in `.git/refs/heads/origin`.
|
||||
public repository is stored in `.git/refs/remotes/origin/master`.
|
||||
|
||||
4. Use `git cherry origin` to see which ones of your patches
|
||||
were accepted, and/or use `git rebase origin` to port your
|
||||
|
@ -1681,11 +1658,11 @@ $ git reset --hard master~2
|
|||
|
||||
You can make sure 'git show-branch' matches the state before
|
||||
those two 'git merge' you just did. Then, instead of running
|
||||
two 'git merge' commands in a row, you would pull these two
|
||||
two 'git merge' commands in a row, you would merge these two
|
||||
branch heads (this is known as 'making an Octopus'):
|
||||
|
||||
------------
|
||||
$ git pull . commit-fix diff-fix
|
||||
$ git merge commit-fix diff-fix
|
||||
$ git show-branch
|
||||
! [commit-fix] Fix commit message normalization.
|
||||
! [diff-fix] Fix rename detection.
|
||||
|
@ -1701,7 +1678,7 @@ $ git show-branch
|
|||
|
||||
Note that you should not do Octopus because you can. An octopus
|
||||
is a valid thing to do and often makes it easier to view the
|
||||
commit history if you are pulling more than two independent
|
||||
commit history if you are merging more than two independent
|
||||
changes at the same time. However, if you have merge conflicts
|
||||
with any of the branches you are merging in and need to hand
|
||||
resolve, that is an indication that the development happened in
|
||||
|
|
|
@ -36,7 +36,7 @@ them first before running git pull.
|
|||
================================
|
||||
The `pull` command knows where to get updates from because of certain
|
||||
configuration variables that were set by the first `git clone`
|
||||
command; see `git repo-config -l` and the gitlink:git-repo-config[1] man
|
||||
command; see `git config -l` and the gitlink:git-config[1] man
|
||||
page for details.
|
||||
================================
|
||||
|
||||
|
|
|
@ -58,6 +58,10 @@
|
|||
Turn off rename detection, even when the configuration
|
||||
file gives the default to do so.
|
||||
|
||||
--check::
|
||||
Warn if changes introduce trailing whitespace
|
||||
or an indent that uses a space before a tab.
|
||||
|
||||
--full-index::
|
||||
Instead of the first handful characters, show full
|
||||
object name of pre- and post-image blob on the "index"
|
||||
|
|
|
@ -28,7 +28,7 @@ Everybody uses these commands to maintain git repositories.
|
|||
* gitlink:git-init[1] or gitlink:git-clone[1] to create a
|
||||
new repository.
|
||||
|
||||
* gitlink:git-fsck-objects[1] to check the repository for errors.
|
||||
* gitlink:git-fsck[1] to check the repository for errors.
|
||||
|
||||
* gitlink:git-prune[1] to remove unused objects in the repository.
|
||||
|
||||
|
@ -43,7 +43,7 @@ Examples
|
|||
Check health and remove cruft.::
|
||||
+
|
||||
------------
|
||||
$ git fsck-objects <1>
|
||||
$ git fsck <1>
|
||||
$ git count-objects <2>
|
||||
$ git repack <3>
|
||||
$ git gc <4>
|
||||
|
@ -148,8 +148,7 @@ modification will be caught if you do `git commit -a` later.
|
|||
<8> redo the commit undone in the previous step, using the message
|
||||
you originally wrote.
|
||||
<9> switch to the master branch.
|
||||
<10> merge a topic branch into your master branch. You can also use
|
||||
`git pull . alsa-audio`, i.e. pull from the local repository.
|
||||
<10> merge a topic branch into your master branch.
|
||||
<11> review commit logs; other forms to limit output can be
|
||||
combined and include `\--max-count=10` (show 10 commits),
|
||||
`\--until=2005-12-10`, etc.
|
||||
|
@ -213,12 +212,12 @@ Push into another repository.::
|
|||
------------
|
||||
satellite$ git clone mothership:frotz frotz <1>
|
||||
satellite$ cd frotz
|
||||
satellite$ git repo-config --get-regexp '^(remote|branch)\.' <2>
|
||||
satellite$ git config --get-regexp '^(remote|branch)\.' <2>
|
||||
remote.origin.url mothership:frotz
|
||||
remote.origin.fetch refs/heads/*:refs/remotes/origin/*
|
||||
branch.master.remote origin
|
||||
branch.master.merge refs/heads/master
|
||||
satellite$ git repo-config remote.origin.push \
|
||||
satellite$ git config remote.origin.push \
|
||||
master:refs/remotes/satellite/master <3>
|
||||
satellite$ edit/compile/test/commit
|
||||
satellite$ git push origin <4>
|
||||
|
|
|
@ -7,7 +7,7 @@ git-add - Add file contents to the changeset to be committed next
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git-add' [-n] [-v] [-f] [--interactive] [--] <file>...
|
||||
'git-add' [-n] [-v] [-f] [--interactive | -i] [--] <file>...
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
@ -52,7 +52,7 @@ OPTIONS
|
|||
-f::
|
||||
Allow adding otherwise ignored files.
|
||||
|
||||
\--interactive::
|
||||
\i, \--interactive::
|
||||
Add modified contents in the working tree interactively to
|
||||
the index.
|
||||
|
||||
|
@ -83,7 +83,7 @@ git-add git-*.sh::
|
|||
Interactive mode
|
||||
----------------
|
||||
When the command enters the interactive mode, it shows the
|
||||
output of the 'status' subcommand, and then goes into ints
|
||||
output of the 'status' subcommand, and then goes into its
|
||||
interactive command loop.
|
||||
|
||||
The command loop shows the list of subcommands available, and
|
||||
|
|
|
@ -3,7 +3,7 @@ git-am(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-am - Apply a series of patches in a mailbox
|
||||
git-am - Apply a series of patches from a mailbox
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-apply(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-apply - Apply patch on a git index file and a work tree
|
||||
git-apply - Apply a patch on a git index file and a working tree
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -12,6 +12,9 @@ SYNOPSIS
|
|||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
This is usually not what an end user wants to run directly. See
|
||||
gitlink:git-am[1] instead.
|
||||
|
||||
Takes three files <msg>, <patch>, and <info> prepared from an
|
||||
e-mail message by 'git-mailinfo', and creates a commit. It is
|
||||
usually not necessary to use this command directly.
|
||||
|
|
|
@ -3,7 +3,7 @@ git-archive(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-archive - Creates a archive of the files in the named tree
|
||||
git-archive - Creates an archive of files from a named tree
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-bisect(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-bisect - Find the change that introduced a bug
|
||||
git-bisect - Find the change that introduced a bug by binary search
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -8,7 +8,7 @@ git-blame - Show what revision and author last modified each line of a file
|
|||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git-blame' [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>]
|
||||
'git-blame' [-c] [-l] [-t] [-f] [-n] [-p] [--incremental] [-L n,m] [-S <revs-file>]
|
||||
[-M] [-C] [-C] [--since=<date>] [<rev>] [--] <file>
|
||||
|
||||
DESCRIPTION
|
||||
|
@ -24,7 +24,7 @@ replaced; you need to use a tool such as gitlink:git-diff[1] or the "pickaxe"
|
|||
interface briefly mentioned in the following paragraph.
|
||||
|
||||
Apart from supporting file annotation, git also supports searching the
|
||||
development history for when a code snippet occured in a change. This makes it
|
||||
development history for when a code snippet occurred in a change. This makes it
|
||||
possible to track when a code snippet was added to a file, moved or copied
|
||||
between files, and eventually deleted or replaced. It works by searching for
|
||||
a text string in the diff. A small example:
|
||||
|
@ -63,6 +63,10 @@ OPTIONS
|
|||
-p, --porcelain::
|
||||
Show in a format designed for machine consumption.
|
||||
|
||||
--incremental::
|
||||
Show the result incrementally in a format designed for
|
||||
machine consumption.
|
||||
|
||||
-M::
|
||||
Detect moving lines in the file as well. When a commit
|
||||
moves a block of lines in a file (e.g. the original file
|
||||
|
@ -89,7 +93,7 @@ THE PORCELAIN FORMAT
|
|||
--------------------
|
||||
|
||||
In this format, each line is output after a header; the
|
||||
header at the minumum has the first line which has:
|
||||
header at the minimum has the first line which has:
|
||||
|
||||
- 40-byte SHA-1 of the commit the line is attributed to;
|
||||
- the line number of the line in the original file;
|
||||
|
@ -112,15 +116,18 @@ header, prefixed by a TAB. This is to allow adding more
|
|||
header elements later.
|
||||
|
||||
|
||||
SPECIFIYING RANGES
|
||||
------------------
|
||||
SPECIFYING RANGES
|
||||
-----------------
|
||||
|
||||
Unlike `git-blame` and `git-annotate` in older git, the extent
|
||||
of annotation can be limited to both line ranges and revision
|
||||
ranges. When you are interested in finding the origin for
|
||||
ll. 40-60 for file `foo`, you can use `-L` option like this:
|
||||
ll. 40-60 for file `foo`, you can use `-L` option like these
|
||||
(they mean the same thing -- both ask for 21 lines starting at
|
||||
line 40):
|
||||
|
||||
git blame -L 40,60 foo
|
||||
git blame -L 40,+21 foo
|
||||
|
||||
Also you can use regular expression to specify the line range.
|
||||
|
||||
|
@ -155,6 +162,47 @@ parents, using `commit{caret}!` notation:
|
|||
git blame -C -C -f $commit^! -- foo
|
||||
|
||||
|
||||
INCREMENTAL OUTPUT
|
||||
------------------
|
||||
|
||||
When called with `--incremental` option, the command outputs the
|
||||
result as it is built. The output generally will talk about
|
||||
lines touched by more recent commits first (i.e. the lines will
|
||||
be annotated out of order) and is meant to be used by
|
||||
interactive viewers.
|
||||
|
||||
The output format is similar to the Porcelain format, but it
|
||||
does not contain the actual lines from the file that is being
|
||||
annotated.
|
||||
|
||||
. Each blame entry always starts with a line of:
|
||||
|
||||
<40-byte hex sha1> <sourceline> <resultline> <num_lines>
|
||||
+
|
||||
Line numbers count from 1.
|
||||
|
||||
. The first time that commit shows up in the stream, it has various
|
||||
other information about it printed out with a one-word tag at the
|
||||
beginning of each line about that "extended commit info" (author,
|
||||
email, committer, dates, summary etc).
|
||||
|
||||
. Unlike Porcelain format, the filename information is always
|
||||
given and terminates the entry:
|
||||
|
||||
"filename" <whitespace-quoted-filename-goes-here>
|
||||
+
|
||||
and thus it's really quite easy to parse for some line- and word-oriented
|
||||
parser (which should be quite natural for most scripting languages).
|
||||
+
|
||||
[NOTE]
|
||||
For people who do parsing: to make it more robust, just ignore any
|
||||
lines in between the first and last one ("<sha1>" and "filename" lines)
|
||||
where you don't recognize the tag-words (or care about that particular
|
||||
one) at the beginning of the "extended information" lines. That way, if
|
||||
there is ever added information (like the commit encoding or extended
|
||||
commit commentary), a blame viewer won't ever care.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
gitlink:git-annotate[1]
|
||||
|
|
|
@ -3,7 +3,7 @@ git-branch(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-branch - List, create, or delete branches.
|
||||
git-branch - List, create, or delete branches
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
@ -74,7 +74,7 @@ OPTIONS
|
|||
List both remote-tracking branches and local branches.
|
||||
|
||||
-v::
|
||||
Show sha1 and commit subjectline for each head.
|
||||
Show sha1 and commit subject line for each head.
|
||||
|
||||
--abbrev=<length>::
|
||||
Alter minimum display length for sha1 in output listing,
|
||||
|
|
|
@ -3,7 +3,7 @@ git-cat-file(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-cat-file - Provide content or type information for repository objects
|
||||
git-cat-file - Provide content or type/size information for repository objects
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-checkout-index(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-checkout-index - Copy files from the index to the working directory
|
||||
git-checkout-index - Copy files from the index to the working tree
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -9,7 +9,7 @@ SYNOPSIS
|
|||
--------
|
||||
[verse]
|
||||
'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<branch>]
|
||||
'git-checkout' [-m] [<branch>] <paths>...
|
||||
'git-checkout' [<branch>] <paths>...
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
@ -63,7 +63,57 @@ and mark the resolved paths with `git update-index`.
|
|||
|
||||
<branch>::
|
||||
Branch to checkout; may be any object ID that resolves to a
|
||||
commit. Defaults to HEAD.
|
||||
commit. Defaults to HEAD.
|
||||
+
|
||||
When this parameter names a non-branch (but still a valid commit object),
|
||||
your HEAD becomes 'detached'.
|
||||
|
||||
|
||||
Detached HEAD
|
||||
-------------
|
||||
|
||||
It is sometimes useful to be able to 'checkout' a commit that is
|
||||
not at the tip of one of your branches. The most obvious
|
||||
example is to check out the commit at a tagged official release
|
||||
point, like this:
|
||||
|
||||
------------
|
||||
$ git checkout v2.6.18
|
||||
------------
|
||||
|
||||
Earlier versions of git did not allow this and asked you to
|
||||
create a temporary branch using `-b` option, but starting from
|
||||
version 1.5.0, the above command 'detaches' your HEAD from the
|
||||
current branch and directly point at the commit named by the tag
|
||||
(`v2.6.18` in the above example).
|
||||
|
||||
You can use usual git commands while in this state. You can use
|
||||
`git-reset --hard $othercommit` to further move around, for
|
||||
example. You can make changes and create a new commit on top of
|
||||
a detached HEAD. You can even create a merge by using `git
|
||||
merge $othercommit`.
|
||||
|
||||
The state you are in while your HEAD is detached is not recorded
|
||||
by any branch (which is natural --- you are not on any branch).
|
||||
What this means is that you can discard your temporary commits
|
||||
and merges by switching back to an existing branch (e.g. `git
|
||||
checkout master`), and a later `git prune` or `git gc` would
|
||||
garbage-collect them.
|
||||
|
||||
The command would refuse to switch back to make sure that you do
|
||||
not discard your temporary state by mistake when your detached
|
||||
HEAD is not pointed at by any existing ref. If you did want to
|
||||
save your state (e.g. "I was interested in the fifth commit from
|
||||
the top of 'master' branch", or "I made two commits to fix minor
|
||||
bugs while on a detached HEAD" -- and if you do not want to lose
|
||||
these facts), you can create a new branch and switch to it with
|
||||
`git checkout -b newbranch` so that you can keep building on
|
||||
that state, or tag it first so that you can come back to it
|
||||
later and switch to the branch you wanted to switch to with `git
|
||||
tag that_state; git checkout master`. On the other hand, if you
|
||||
did want to discard the temporary state, you can give `-f`
|
||||
option (e.g. `git checkout -f master`) to override this
|
||||
behaviour.
|
||||
|
||||
|
||||
EXAMPLES
|
||||
|
|
|
@ -19,6 +19,8 @@ OPTIONS
|
|||
-------
|
||||
<commit>::
|
||||
Commit to cherry-pick.
|
||||
For a more complete list of ways to spell commits, see
|
||||
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
|
||||
|
||||
-e|--edit::
|
||||
With this option, `git-cherry-pick` will let you edit the commit
|
||||
|
|
|
@ -3,7 +3,7 @@ git-clone(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-clone - Clones a repository
|
||||
git-clone - Clones a repository into a new directory
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-commit-tree(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-commit-tree - Creates a new commit object
|
||||
git-commit-tree - Create a new commit object
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
@ -12,6 +12,9 @@ SYNOPSIS
|
|||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
This is usually not what an end user wants to run directly. See
|
||||
gitlink:git-commit[1] instead.
|
||||
|
||||
Creates a new commit object based on the provided tree object and
|
||||
emits the new commit object id on stdout. If no parent is given then
|
||||
it is considered to be an initial tree.
|
||||
|
|
|
@ -3,13 +3,13 @@ git-commit(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-commit - Record your changes
|
||||
git-commit - Record changes to the repository
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
|
||||
[--no-verify] [--amend] [-e] [--author <author>]
|
||||
'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg> |
|
||||
--amend] [--no-verify] [-e] [--author <author>]
|
||||
[--] [[-i | -o ]<file>...]
|
||||
|
||||
DESCRIPTION
|
||||
|
@ -111,7 +111,7 @@ but can be used to amend a merge commit.
|
|||
are concluding a conflicted merge.
|
||||
|
||||
-q|--quiet::
|
||||
Supress commit summary message.
|
||||
Suppress commit summary message.
|
||||
|
||||
\--::
|
||||
Do not interpret any more arguments as options.
|
||||
|
@ -142,11 +142,6 @@ $ git add hello.c
|
|||
$ git commit
|
||||
------------
|
||||
|
||||
////////////
|
||||
We should fix 'git rm' to remove goodbye.c from both index and
|
||||
working tree for the above example.
|
||||
////////////
|
||||
|
||||
Instead of staging files after each individual change, you can
|
||||
tell `git commit` to notice the changes to the files whose
|
||||
contents are tracked in
|
||||
|
@ -223,6 +218,12 @@ refuses to run when given pathnames (but see `-i` option).
|
|||
DISCUSSION
|
||||
----------
|
||||
|
||||
Though not required, it's a good idea to begin the commit message
|
||||
with a single short (less than 50 character) line summarizing the
|
||||
change, followed by a blank line and then a more thorough description.
|
||||
Tools that turn commits into email, for example, use the first line
|
||||
on the Subject: line and the rest of the commit in the body.
|
||||
|
||||
include::i18n.txt[]
|
||||
|
||||
ENVIRONMENT VARIABLES
|
||||
|
|
227
Documentation/git-config.txt
Normal file
227
Documentation/git-config.txt
Normal file
|
@ -0,0 +1,227 @@
|
|||
git-config(1)
|
||||
=============
|
||||
|
||||
NAME
|
||||
----
|
||||
git-config - Get and set repository or global options
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git-config' [--global] [type] name [value [value_regex]]
|
||||
'git-config' [--global] [type] --add name value
|
||||
'git-config' [--global] [type] --replace-all name [value [value_regex]]
|
||||
'git-config' [--global] [type] --get name [value_regex]
|
||||
'git-config' [--global] [type] --get-all name [value_regex]
|
||||
'git-config' [--global] [type] --unset name [value_regex]
|
||||
'git-config' [--global] [type] --unset-all name [value_regex]
|
||||
'git-config' [--global] -l | --list
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
You can query/set/replace/unset options with this command. The name is
|
||||
actually the section and the key separated by a dot, and the value will be
|
||||
escaped.
|
||||
|
||||
Multiple lines can be added to an option by using the '--add' option.
|
||||
If you want to update or unset an option which can occur on multiple
|
||||
lines, a POSIX regexp `value_regex` needs to be given. Only the
|
||||
existing values that match the regexp are updated or unset. If
|
||||
you want to handle the lines that do *not* match the regex, just
|
||||
prepend a single exclamation mark in front (see EXAMPLES).
|
||||
|
||||
The type specifier can be either '--int' or '--bool', which will make
|
||||
'git-config' ensure that the variable(s) are of the given type and
|
||||
convert the value to the canonical form (simple decimal number for int,
|
||||
a "true" or "false" string for bool). If no type specifier is passed,
|
||||
no checks or transformations are performed on the value.
|
||||
|
||||
This command will fail if:
|
||||
|
||||
. The .git/config file is invalid,
|
||||
. Can not write to .git/config,
|
||||
. no section was provided,
|
||||
. the section or key is invalid,
|
||||
. you try to unset an option which does not exist,
|
||||
. you try to unset/set an option for which multiple lines match, or
|
||||
. you use --global option without $HOME being properly set.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
--replace-all::
|
||||
Default behavior is to replace at most one line. This replaces
|
||||
all lines matching the key (and optionally the value_regex).
|
||||
|
||||
--add::
|
||||
Adds a new line to the option without altering any existing
|
||||
values. This is the same as providing '^$' as the value_regex.
|
||||
|
||||
--get::
|
||||
Get the value for a given key (optionally filtered by a regex
|
||||
matching the value). Returns error code 1 if the key was not
|
||||
found and error code 2 if multiple key values were found.
|
||||
|
||||
--get-all::
|
||||
Like get, but does not fail if the number of values for the key
|
||||
is not exactly one.
|
||||
|
||||
--get-regexp::
|
||||
Like --get-all, but interprets the name as a regular expression.
|
||||
|
||||
--global::
|
||||
Use global ~/.gitconfig file rather than the repository .git/config.
|
||||
|
||||
--unset::
|
||||
Remove the line matching the key from config file.
|
||||
|
||||
--unset-all::
|
||||
Remove all matching lines from config file.
|
||||
|
||||
-l, --list::
|
||||
List all variables set in config file.
|
||||
|
||||
--bool::
|
||||
git-config will ensure that the output is "true" or "false"
|
||||
|
||||
--int::
|
||||
git-config will ensure that the output is a simple
|
||||
decimal number. An optional value suffix of 'k', 'm', or 'g'
|
||||
in the config file will cause the value to be multiplied
|
||||
by 1024, 1048576, or 1073741824 prior to output.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
GIT_CONFIG::
|
||||
Take the configuration from the given file instead of .git/config.
|
||||
Using the "--global" option forces this to ~/.gitconfig.
|
||||
|
||||
GIT_CONFIG_LOCAL::
|
||||
Currently the same as $GIT_CONFIG; when Git will support global
|
||||
configuration files, this will cause it to take the configuration
|
||||
from the global configuration file in addition to the given file.
|
||||
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
|
||||
Given a .git/config like this:
|
||||
|
||||
#
|
||||
# This is the config file, and
|
||||
# a '#' or ';' character indicates
|
||||
# a comment
|
||||
#
|
||||
|
||||
; core variables
|
||||
[core]
|
||||
; Don't trust file modes
|
||||
filemode = false
|
||||
|
||||
; Our diff algorithm
|
||||
[diff]
|
||||
external = "/usr/local/bin/gnu-diff -u"
|
||||
renames = true
|
||||
|
||||
; Proxy settings
|
||||
[core]
|
||||
gitproxy="ssh" for "ssh://kernel.org/"
|
||||
gitproxy="proxy-command" for kernel.org
|
||||
gitproxy="myprotocol-command" for "my://"
|
||||
gitproxy=default-proxy ; for all the rest
|
||||
|
||||
you can set the filemode to true with
|
||||
|
||||
------------
|
||||
% git config core.filemode true
|
||||
------------
|
||||
|
||||
The hypothetical proxy command entries actually have a postfix to discern
|
||||
what URL they apply to. Here is how to change the entry for kernel.org
|
||||
to "ssh".
|
||||
|
||||
------------
|
||||
% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
|
||||
------------
|
||||
|
||||
This makes sure that only the key/value pair for kernel.org is replaced.
|
||||
|
||||
To delete the entry for renames, do
|
||||
|
||||
------------
|
||||
% git config --unset diff.renames
|
||||
------------
|
||||
|
||||
If you want to delete an entry for a multivar (like core.gitproxy above),
|
||||
you have to provide a regex matching the value of exactly one line.
|
||||
|
||||
To query the value for a given key, do
|
||||
|
||||
------------
|
||||
% git config --get core.filemode
|
||||
------------
|
||||
|
||||
or
|
||||
|
||||
------------
|
||||
% git config core.filemode
|
||||
------------
|
||||
|
||||
or, to query a multivar:
|
||||
|
||||
------------
|
||||
% git config --get core.gitproxy "for kernel.org$"
|
||||
------------
|
||||
|
||||
If you want to know all the values for a multivar, do:
|
||||
|
||||
------------
|
||||
% git config --get-all core.gitproxy
|
||||
------------
|
||||
|
||||
If you like to live dangerous, you can replace *all* core.gitproxy by a
|
||||
new one with
|
||||
|
||||
------------
|
||||
% git config --replace-all core.gitproxy ssh
|
||||
------------
|
||||
|
||||
However, if you really only want to replace the line for the default proxy,
|
||||
i.e. the one without a "for ..." postfix, do something like this:
|
||||
|
||||
------------
|
||||
% git config core.gitproxy ssh '! for '
|
||||
------------
|
||||
|
||||
To actually match only values with an exclamation mark, you have to
|
||||
|
||||
------------
|
||||
% git config section.key value '[!]'
|
||||
------------
|
||||
|
||||
To add a new proxy, without altering any of the existing ones, use
|
||||
|
||||
------------
|
||||
% git config core.gitproxy '"proxy" for example.com'
|
||||
------------
|
||||
|
||||
|
||||
include::config.txt[]
|
||||
|
||||
|
||||
Author
|
||||
------
|
||||
Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
|
||||
|
||||
Documentation
|
||||
--------------
|
||||
Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>.
|
||||
|
||||
GIT
|
||||
---
|
||||
Part of the gitlink:git[7] suite
|
||||
|
|
@ -3,7 +3,7 @@ git-count-objects(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-count-objects - Reports on unpacked objects
|
||||
git-count-objects - Count unpacked number of objects and their disk consumption
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
|
|
@ -3,7 +3,7 @@ git-cvsexportcommit(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-cvsexportcommit - Export a commit to a CVS checkout
|
||||
git-cvsexportcommit - Export a single commit to a CVS checkout
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-cvsimport(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-cvsimport - Import a CVS repository into git
|
||||
git-cvsimport - Salvage your data out of another SCM people love to hate
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
@ -97,7 +97,7 @@ If you need to pass multiple options, separate them with a comma.
|
|||
Substitute the character "/" in branch names with <subst>
|
||||
|
||||
-A <author-conv-file>::
|
||||
CVS by default uses the unix username when writing its
|
||||
CVS by default uses the Unix username when writing its
|
||||
commit logs. Using this option and an author-conv-file
|
||||
in this format
|
||||
|
||||
|
|
|
@ -131,14 +131,14 @@ Giving these options is an error when used with `--inetd`; use
|
|||
the facility of inet daemon to achieve the same before spawning
|
||||
`git-daemon` if needed.
|
||||
|
||||
--enable-service, --disable-service::
|
||||
--enable=service, --disable=service::
|
||||
Enable/disable the service site-wide per default. Note
|
||||
that a service disabled site-wide can still be enabled
|
||||
per repository if it is marked overridable and the
|
||||
repository enables the service with an configuration
|
||||
item.
|
||||
|
||||
--allow-override, --forbid-override::
|
||||
--allow-override=service, --forbid-override=service::
|
||||
Allow/forbid overriding the site-wide default with per
|
||||
repository configuration. By default, all the services
|
||||
are overridable.
|
||||
|
|
|
@ -14,8 +14,8 @@ DESCRIPTION
|
|||
-----------
|
||||
The command finds the most recent tag that is reachable from a
|
||||
commit, and if the commit itself is pointed at by the tag, shows
|
||||
the tag. Otherwise, it suffixes the tag name with abbreviated
|
||||
object name of the commit.
|
||||
the tag. Otherwise, it suffixes the tag name with the number of
|
||||
additional commits and the abbreviated object name of the commit.
|
||||
|
||||
|
||||
OPTIONS
|
||||
|
@ -35,6 +35,16 @@ OPTIONS
|
|||
Instead of using the default 8 hexadecimal digits as the
|
||||
abbreviated object name, use <n> digits.
|
||||
|
||||
--candidates=<n>::
|
||||
Instead of considering only the 10 most recent tags as
|
||||
candidates to describe the input committish consider
|
||||
up to <n> candidates. Increasing <n> above 10 will take
|
||||
slightly longer but may produce a more accurate result.
|
||||
|
||||
--debug::
|
||||
Verbosely display information about the searching strategy
|
||||
being employed to standard error. The tag name will still
|
||||
be printed to standard out.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
@ -42,12 +52,18 @@ EXAMPLES
|
|||
With something like git.git current tree, I get:
|
||||
|
||||
[torvalds@g5 git]$ git-describe parent
|
||||
v1.0.4-g2414721b
|
||||
v1.0.4-14-g2414721
|
||||
|
||||
i.e. the current head of my "parent" branch is based on v1.0.4,
|
||||
but since it has a few commits on top of that, it has added the
|
||||
git hash of the thing to the end: "-g" + 8-char shorthand for
|
||||
the commit `2414721b194453f058079d897d13c4e377f92dc6`.
|
||||
but since it has a handful commits on top of that,
|
||||
describe has added the number of additional commits ("14") and
|
||||
an abbreviated object name for the commit itself ("2414721")
|
||||
at the end.
|
||||
|
||||
The number of additional commits is the number
|
||||
of commits which would be displayed by "git log v1.0.4..parent".
|
||||
The hash suffix is "-g" + 7-char abbreviation for the tip commit
|
||||
of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
|
||||
|
||||
Doing a "git-describe" on a tag-name will just show the tag name:
|
||||
|
||||
|
@ -58,16 +74,43 @@ With --all, the command can use branch heads as references, so
|
|||
the output shows the reference path as well:
|
||||
|
||||
[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
|
||||
tags/v1.0.0-g975b
|
||||
tags/v1.0.0-21-g975b
|
||||
|
||||
[torvalds@g5 git]$ git describe --all HEAD^
|
||||
heads/lt/describe-g975b
|
||||
heads/lt/describe-7-g975b
|
||||
|
||||
With --abbrev set to 0, the command can be used to find the
|
||||
closest tagname without any suffix:
|
||||
|
||||
[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
|
||||
tags/v1.0.0
|
||||
|
||||
SEARCH STRATEGY
|
||||
---------------
|
||||
|
||||
For each committish supplied "git describe" will first look for
|
||||
a tag which tags exactly that commit. Annotated tags will always
|
||||
be preferred over lightweight tags, and tags with newer dates will
|
||||
always be preferred over tags with older dates. If an exact match
|
||||
is found, its name will be output and searching will stop.
|
||||
|
||||
If an exact match was not found "git describe" will walk back
|
||||
through the commit history to locate an ancestor commit which
|
||||
has been tagged. The ancestor's tag will be output along with an
|
||||
abbreviation of the input committish's SHA1.
|
||||
|
||||
If multiple tags were found during the walk then the tag which
|
||||
has the fewest commits different from the input committish will be
|
||||
selected and output. Here fewest commits different is defined as
|
||||
the number of commits which would be shown by "git log tag..input"
|
||||
will be the smallest number of commits possible.
|
||||
|
||||
|
||||
Author
|
||||
------
|
||||
Written by Linus Torvalds <torvalds@osdl.org>, but somewhat
|
||||
butchered by Junio C Hamano <junkio@cox.net>
|
||||
butchered by Junio C Hamano <junkio@cox.net>. Later significantly
|
||||
updated by Shawn Pearce <spearce@spearce.org>.
|
||||
|
||||
Documentation
|
||||
--------------
|
||||
|
|
|
@ -3,7 +3,7 @@ git-diff-stages(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-diff-stages - Compares content and mode of blobs between stages in an unmerged index file
|
||||
git-diff-stages - Compares two merge stages in the index
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -47,6 +47,9 @@ Just in case if you are doing something exotic, it should be
|
|||
noted that all of the <commit> in the above description can be
|
||||
any <tree-ish>.
|
||||
|
||||
For a more complete list of ways to spell <commit>, see
|
||||
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
|
|
@ -8,10 +8,13 @@ git-fetch-pack - Receive missing objects from another repository
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git-fetch-pack' [-q] [-k] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...]
|
||||
'git-fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--upload-pack=<git-upload-pack>] [--depth=<n>] [-v] [<host>:]<directory> [<refs>...]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Usually you would want to use gitlink:git-fetch[1] which is a
|
||||
higher level wrapper of this command instead.
|
||||
|
||||
Invokes 'git-upload-pack' on a potentially remote repository,
|
||||
and asks it to send objects missing from this repository, to
|
||||
update the named heads. The list of commits available locally
|
||||
|
@ -25,17 +28,24 @@ have a common ancestor commit.
|
|||
|
||||
OPTIONS
|
||||
-------
|
||||
-q::
|
||||
\--all::
|
||||
Fetch all remote refs.
|
||||
|
||||
\--quiet, \-q::
|
||||
Pass '-q' flag to 'git-unpack-objects'; this makes the
|
||||
cloning process less verbose.
|
||||
|
||||
-k::
|
||||
\--keep, \-k::
|
||||
Do not invoke 'git-unpack-objects' on received data, but
|
||||
create a single packfile out of it instead, and store it
|
||||
in the object database. If provided twice then the pack is
|
||||
locked against repacking.
|
||||
|
||||
--exec=<git-upload-pack>::
|
||||
\--thin::
|
||||
Spend extra cycles to minimize the number of objects to be sent.
|
||||
Use it on slower connection.
|
||||
|
||||
\--upload-pack=<git-upload-pack>::
|
||||
Use this to specify the path to 'git-upload-pack' on the
|
||||
remote side, if is not found on your $PATH.
|
||||
Installations of sshd ignores the user's environment
|
||||
|
@ -47,6 +57,15 @@ OPTIONS
|
|||
shells by having a lean .bashrc file (they set most of
|
||||
the things up in .bash_profile).
|
||||
|
||||
\--exec=<git-upload-pack>::
|
||||
Same as \--upload-pack=<git-upload-pack>.
|
||||
|
||||
\--depth=<n>::
|
||||
Limit fetching to ancestor-chains not longer than n.
|
||||
|
||||
\-v::
|
||||
Run verbosely.
|
||||
|
||||
<host>::
|
||||
A remote host that houses the repository. When this
|
||||
part is specified, 'git-upload-pack' is invoked via
|
||||
|
|
|
@ -3,7 +3,7 @@ git-fetch(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-fetch - Download objects and a head from another repository
|
||||
git-fetch - Download objects and refs from another repository
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -7,7 +7,7 @@ git-for-each-ref - Output information on each ref
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git-for-each-ref' [--count=<count>]\* [--shell|--perl|--python] [--sort=<key>]\* [--format=<format>] [<pattern>]
|
||||
'git-for-each-ref' [--count=<count>]\* [--shell|--perl|--python|--tcl] [--sort=<key>]\* [--format=<format>] [<pattern>]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
@ -15,7 +15,7 @@ DESCRIPTION
|
|||
Iterate over all refs that match `<pattern>` and show them
|
||||
according to the given `<format>`, after sorting them according
|
||||
to the given set of `<key>`. If `<max>` is given, stop after
|
||||
showing that many refs. The interporated values in `<format>`
|
||||
showing that many refs. The interpolated values in `<format>`
|
||||
can optionally be quoted as string literals in the specified
|
||||
host language allowing their direct evaluation in that language.
|
||||
|
||||
|
@ -49,7 +49,7 @@ OPTIONS
|
|||
using fnmatch(3). Refs that do not match the pattern
|
||||
are not shown.
|
||||
|
||||
--shell, --perl, --python::
|
||||
--shell, --perl, --python, --tcl::
|
||||
If given, strings that substitute `%(fieldname)`
|
||||
placeholders are quoted as string literals suitable for
|
||||
the specified host language. This is meant to produce
|
||||
|
|
|
@ -11,7 +11,8 @@ SYNOPSIS
|
|||
[verse]
|
||||
'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [--thread]
|
||||
[-s | --signoff] [--diff-options] [--start-number <n>]
|
||||
[--in-reply-to=Message-Id]
|
||||
[--in-reply-to=Message-Id] [--suffix=.<sfx>]
|
||||
[--ignore-if-in-upstream]
|
||||
<since>[..<until>]
|
||||
|
||||
DESCRIPTION
|
||||
|
@ -20,7 +21,9 @@ DESCRIPTION
|
|||
Prepare each commit between <since> and <until> with its patch in
|
||||
one file per commit, formatted to resemble UNIX mailbox format.
|
||||
If ..<until> is not specified, the head of the current working
|
||||
tree is implied.
|
||||
tree is implied. For a more complete list of ways to spell
|
||||
<since> and <until>, see "SPECIFYING REVISIONS" section in
|
||||
gitlink:git-rev-parse[1].
|
||||
|
||||
The output of this command is convenient for e-mail submission or
|
||||
for use with gitlink:git-am[1].
|
||||
|
@ -78,13 +81,34 @@ OPTIONS
|
|||
reply to the given Message-Id, which avoids breaking threads to
|
||||
provide a new patch series.
|
||||
|
||||
--ignore-if-in-upstream::
|
||||
Do not include a patch that matches a commit in
|
||||
<until>..<since>. This will examine all patches reachable
|
||||
from <since> but not from <until> and compare them with the
|
||||
patches being generated, and any patch that matches is
|
||||
ignored.
|
||||
|
||||
--suffix=.<sfx>::
|
||||
Instead of using `.patch` as the suffix for generated
|
||||
filenames, use specifed suffix. A common alternative is
|
||||
`--suffix=.txt`.
|
||||
+
|
||||
Note that you would need to include the leading dot `.` if you
|
||||
want a filename like `0001-description-of-my-change.patch`, and
|
||||
the first letter does not have to be a dot. Leaving it empty would
|
||||
not add any suffix.
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
You can specify extra mail header lines to be added to each
|
||||
message in the repository configuration as follows:
|
||||
message in the repository configuration. Also you can specify
|
||||
the default suffix different from the built-in one:
|
||||
|
||||
------------
|
||||
[format]
|
||||
headers = "Organization: git-foo\n"
|
||||
suffix = .txt
|
||||
------------
|
||||
|
||||
|
||||
EXAMPLES
|
||||
|
@ -109,6 +133,9 @@ git-format-patch -M -B origin::
|
|||
understand renaming patches, so use it only when you know
|
||||
the recipient uses git to apply your patch.
|
||||
|
||||
git-format-patch -3::
|
||||
Extract three topmost commits from the current branch
|
||||
and format them as e-mailable patches.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
|
|
@ -8,132 +8,10 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git-fsck-objects' [--tags] [--root] [--unreachable] [--cache]
|
||||
[--full] [--strict] [<object>*]
|
||||
'git-fsck-objects' ...
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Verifies the connectivity and validity of the objects in the database.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
<object>::
|
||||
An object to treat as the head of an unreachability trace.
|
||||
+
|
||||
If no objects are given, git-fsck-objects defaults to using the
|
||||
index file and all SHA1 references in .git/refs/* as heads.
|
||||
|
||||
--unreachable::
|
||||
Print out objects that exist but that aren't readable from any
|
||||
of the reference nodes.
|
||||
|
||||
--root::
|
||||
Report root nodes.
|
||||
|
||||
--tags::
|
||||
Report tags.
|
||||
|
||||
--cache::
|
||||
Consider any object recorded in the index also as a head node for
|
||||
an unreachability trace.
|
||||
|
||||
--full::
|
||||
Check not just objects in GIT_OBJECT_DIRECTORY
|
||||
($GIT_DIR/objects), but also the ones found in alternate
|
||||
object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES
|
||||
or $GIT_DIR/objects/info/alternates,
|
||||
and in packed git archives found in $GIT_DIR/objects/pack
|
||||
and corresponding pack subdirectories in alternate
|
||||
object pools.
|
||||
|
||||
--strict::
|
||||
Enable more strict checking, namely to catch a file mode
|
||||
recorded with g+w bit set, which was created by older
|
||||
versions of git. Existing repositories, including the
|
||||
Linux kernel, git itself, and sparse repository have old
|
||||
objects that triggers this check, but it is recommended
|
||||
to check new projects with this flag.
|
||||
|
||||
It tests SHA1 and general object sanity, and it does full tracking of
|
||||
the resulting reachability and everything else. It prints out any
|
||||
corruption it finds (missing or bad objects), and if you use the
|
||||
'--unreachable' flag it will also print out objects that exist but
|
||||
that aren't readable from any of the specified head nodes.
|
||||
|
||||
So for example
|
||||
|
||||
git-fsck-objects --unreachable HEAD $(cat .git/refs/heads/*)
|
||||
|
||||
will do quite a _lot_ of verification on the tree. There are a few
|
||||
extra validity tests to be added (make sure that tree objects are
|
||||
sorted properly etc), but on the whole if "git-fsck-objects" is happy, you
|
||||
do have a valid tree.
|
||||
|
||||
Any corrupt objects you will have to find in backups or other archives
|
||||
(i.e., you can just remove them and do an "rsync" with some other site in
|
||||
the hopes that somebody else has the object you have corrupted).
|
||||
|
||||
Of course, "valid tree" doesn't mean that it wasn't generated by some
|
||||
evil person, and the end result might be crap. git is a revision
|
||||
tracking system, not a quality assurance system ;)
|
||||
|
||||
Extracted Diagnostics
|
||||
---------------------
|
||||
|
||||
expect dangling commits - potential heads - due to lack of head information::
|
||||
You haven't specified any nodes as heads so it won't be
|
||||
possible to differentiate between un-parented commits and
|
||||
root nodes.
|
||||
|
||||
missing sha1 directory '<dir>'::
|
||||
The directory holding the sha1 objects is missing.
|
||||
|
||||
unreachable <type> <object>::
|
||||
The <type> object <object>, isn't actually referred to directly
|
||||
or indirectly in any of the trees or commits seen. This can
|
||||
mean that there's another root node that you're not specifying
|
||||
or that the tree is corrupt. If you haven't missed a root node
|
||||
then you might as well delete unreachable nodes since they
|
||||
can't be used.
|
||||
|
||||
missing <type> <object>::
|
||||
The <type> object <object>, is referred to but isn't present in
|
||||
the database.
|
||||
|
||||
dangling <type> <object>::
|
||||
The <type> object <object>, is present in the database but never
|
||||
'directly' used. A dangling commit could be a root node.
|
||||
|
||||
warning: git-fsck-objects: tree <tree> has full pathnames in it::
|
||||
And it shouldn't...
|
||||
|
||||
sha1 mismatch <object>::
|
||||
The database has an object who's sha1 doesn't match the
|
||||
database value.
|
||||
This indicates a serious data integrity problem.
|
||||
|
||||
Environment Variables
|
||||
---------------------
|
||||
|
||||
GIT_OBJECT_DIRECTORY::
|
||||
used to specify the object database root (usually $GIT_DIR/objects)
|
||||
|
||||
GIT_INDEX_FILE::
|
||||
used to specify the index file of the index
|
||||
|
||||
GIT_ALTERNATE_OBJECT_DIRECTORIES::
|
||||
used to specify additional object database roots (usually unset)
|
||||
|
||||
Author
|
||||
------
|
||||
Written by Linus Torvalds <torvalds@osdl.org>
|
||||
|
||||
Documentation
|
||||
--------------
|
||||
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
|
||||
|
||||
GIT
|
||||
---
|
||||
Part of the gitlink:git[7] suite
|
||||
|
||||
This is a synonym for gitlink:git-fsck[1]. Please refer to the
|
||||
documentation of that command.
|
||||
|
|
139
Documentation/git-fsck.txt
Normal file
139
Documentation/git-fsck.txt
Normal file
|
@ -0,0 +1,139 @@
|
|||
git-fsck(1)
|
||||
===========
|
||||
|
||||
NAME
|
||||
----
|
||||
git-fsck - Verifies the connectivity and validity of the objects in the database
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git-fsck' [--tags] [--root] [--unreachable] [--cache]
|
||||
[--full] [--strict] [<object>*]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Verifies the connectivity and validity of the objects in the database.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
<object>::
|
||||
An object to treat as the head of an unreachability trace.
|
||||
+
|
||||
If no objects are given, git-fsck defaults to using the
|
||||
index file and all SHA1 references in .git/refs/* as heads.
|
||||
|
||||
--unreachable::
|
||||
Print out objects that exist but that aren't readable from any
|
||||
of the reference nodes.
|
||||
|
||||
--root::
|
||||
Report root nodes.
|
||||
|
||||
--tags::
|
||||
Report tags.
|
||||
|
||||
--cache::
|
||||
Consider any object recorded in the index also as a head node for
|
||||
an unreachability trace.
|
||||
|
||||
--full::
|
||||
Check not just objects in GIT_OBJECT_DIRECTORY
|
||||
($GIT_DIR/objects), but also the ones found in alternate
|
||||
object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES
|
||||
or $GIT_DIR/objects/info/alternates,
|
||||
and in packed git archives found in $GIT_DIR/objects/pack
|
||||
and corresponding pack subdirectories in alternate
|
||||
object pools.
|
||||
|
||||
--strict::
|
||||
Enable more strict checking, namely to catch a file mode
|
||||
recorded with g+w bit set, which was created by older
|
||||
versions of git. Existing repositories, including the
|
||||
Linux kernel, git itself, and sparse repository have old
|
||||
objects that triggers this check, but it is recommended
|
||||
to check new projects with this flag.
|
||||
|
||||
It tests SHA1 and general object sanity, and it does full tracking of
|
||||
the resulting reachability and everything else. It prints out any
|
||||
corruption it finds (missing or bad objects), and if you use the
|
||||
'--unreachable' flag it will also print out objects that exist but
|
||||
that aren't readable from any of the specified head nodes.
|
||||
|
||||
So for example
|
||||
|
||||
git-fsck --unreachable HEAD $(cat .git/refs/heads/*)
|
||||
|
||||
will do quite a _lot_ of verification on the tree. There are a few
|
||||
extra validity tests to be added (make sure that tree objects are
|
||||
sorted properly etc), but on the whole if "git-fsck" is happy, you
|
||||
do have a valid tree.
|
||||
|
||||
Any corrupt objects you will have to find in backups or other archives
|
||||
(i.e., you can just remove them and do an "rsync" with some other site in
|
||||
the hopes that somebody else has the object you have corrupted).
|
||||
|
||||
Of course, "valid tree" doesn't mean that it wasn't generated by some
|
||||
evil person, and the end result might be crap. git is a revision
|
||||
tracking system, not a quality assurance system ;)
|
||||
|
||||
Extracted Diagnostics
|
||||
---------------------
|
||||
|
||||
expect dangling commits - potential heads - due to lack of head information::
|
||||
You haven't specified any nodes as heads so it won't be
|
||||
possible to differentiate between un-parented commits and
|
||||
root nodes.
|
||||
|
||||
missing sha1 directory '<dir>'::
|
||||
The directory holding the sha1 objects is missing.
|
||||
|
||||
unreachable <type> <object>::
|
||||
The <type> object <object>, isn't actually referred to directly
|
||||
or indirectly in any of the trees or commits seen. This can
|
||||
mean that there's another root node that you're not specifying
|
||||
or that the tree is corrupt. If you haven't missed a root node
|
||||
then you might as well delete unreachable nodes since they
|
||||
can't be used.
|
||||
|
||||
missing <type> <object>::
|
||||
The <type> object <object>, is referred to but isn't present in
|
||||
the database.
|
||||
|
||||
dangling <type> <object>::
|
||||
The <type> object <object>, is present in the database but never
|
||||
'directly' used. A dangling commit could be a root node.
|
||||
|
||||
warning: git-fsck: tree <tree> has full pathnames in it::
|
||||
And it shouldn't...
|
||||
|
||||
sha1 mismatch <object>::
|
||||
The database has an object who's sha1 doesn't match the
|
||||
database value.
|
||||
This indicates a serious data integrity problem.
|
||||
|
||||
Environment Variables
|
||||
---------------------
|
||||
|
||||
GIT_OBJECT_DIRECTORY::
|
||||
used to specify the object database root (usually $GIT_DIR/objects)
|
||||
|
||||
GIT_INDEX_FILE::
|
||||
used to specify the index file of the index
|
||||
|
||||
GIT_ALTERNATE_OBJECT_DIRECTORIES::
|
||||
used to specify additional object database roots (usually unset)
|
||||
|
||||
Author
|
||||
------
|
||||
Written by Linus Torvalds <torvalds@osdl.org>
|
||||
|
||||
Documentation
|
||||
--------------
|
||||
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
|
||||
|
||||
GIT
|
||||
---
|
||||
Part of the gitlink:git[7] suite
|
||||
|
|
@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git-gc'
|
||||
'git-gc' [--prune]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
@ -21,6 +21,21 @@ Users are encouraged to run this task on a regular basis within
|
|||
each repository to maintain good disk space utilization and good
|
||||
operating performance.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
--prune::
|
||||
Usually `git-gc` packs refs, expires old reflog entries,
|
||||
packs loose objects,
|
||||
and removes old 'rerere' records. Removal
|
||||
of unreferenced loose objects is an unsafe operation
|
||||
while other git operations are in progress, so it is not
|
||||
done by default. Pass this option if you want it, and only
|
||||
when you know nobody else is creating new objects in the
|
||||
repository at the same time (e.g. never use this option
|
||||
in a cron script).
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
|
@ -35,7 +50,7 @@ can be set to indicate how long historical reflog entries which
|
|||
are not part of the current branch should remain available in
|
||||
this repository. These types of entries are generally created as
|
||||
a result of using `git commit \--amend` or `git rebase` and are the
|
||||
commits prior to the amend or rebase occuring. Since these changes
|
||||
commits prior to the amend or rebase occurring. Since these changes
|
||||
are not part of the current project most users will want to expire
|
||||
them sooner. This option defaults to '30 days'.
|
||||
|
||||
|
|
|
@ -91,7 +91,7 @@ OPTIONS
|
|||
combined by 'or'.
|
||||
|
||||
--and | --or | --not | ( | )::
|
||||
Specify how multiple patterns are combined using boolean
|
||||
Specify how multiple patterns are combined using Boolean
|
||||
expressions. `--or` is the default operator. `--and` has
|
||||
higher precedence than `--or`. `-e` has to be used for all
|
||||
patterns.
|
||||
|
|
|
@ -3,7 +3,7 @@ git-hash-object(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-hash-object - Computes object ID and optionally creates a blob from a file
|
||||
git-hash-object - Compute object ID and optionally creates a blob from a file
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-http-fetch(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-http-fetch - downloads a remote git repository via HTTP
|
||||
git-http-fetch - Download from a remote git repository via HTTP
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-http-push(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-http-push - Push missing objects using HTTP/DAV
|
||||
git-http-push - Push objects over HTTP/DAV to another repository
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-init(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-init - Creates an empty git repository
|
||||
git-init - Create an empty git repository or reinitialize an existing one
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-instaweb(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-instaweb - instantly browse your working repository in gitweb
|
||||
git-instaweb - Instantly browse your working repository in gitweb
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
|
|
@ -3,7 +3,7 @@ git-local-fetch(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-local-fetch - Duplicates another git repository on a local system
|
||||
git-local-fetch - Duplicate another git repository on a local system
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -27,13 +27,16 @@ OPTIONS
|
|||
|
||||
include::pretty-formats.txt[]
|
||||
|
||||
--max-count=<n>::
|
||||
-<n>::
|
||||
Limits the number of commits to show.
|
||||
|
||||
<since>..<until>::
|
||||
Show only commits between the named two commits. When
|
||||
either <since> or <until> is omitted, it defaults to
|
||||
`HEAD`, i.e. the tip of the current branch.
|
||||
For a more complete list of ways to spell <since>
|
||||
and <until>, see "SPECIFYING REVISIONS" section in
|
||||
gitlink:git-rev-parse[1].
|
||||
|
||||
-p::
|
||||
Show the change the commit introduces in a patch form.
|
||||
|
|
|
@ -3,7 +3,7 @@ git-ls-files(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-ls-files - Information about files in the index/working directory
|
||||
git-ls-files - Show information about files in the index and the working tree
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -29,7 +29,7 @@ OPTIONS
|
|||
-u <exec>, --upload-pack=<exec>::
|
||||
Specify the full path of gitlink:git-upload-pack[1] on the remote
|
||||
host. This allows listing references from repositories accessed via
|
||||
SSH and where the SSH deamon does not use the PATH configured by the
|
||||
SSH and where the SSH daemon does not use the PATH configured by the
|
||||
user. Also see the '--exec' option for gitlink:git-peek-remote[1].
|
||||
|
||||
<repository>::
|
||||
|
|
|
@ -3,7 +3,7 @@ git-ls-tree(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-ls-tree - Lists the contents of a tree object
|
||||
git-ls-tree - List the contents of a tree object
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-mailinfo(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-mailinfo - Extracts patch from a single e-mail message
|
||||
git-mailinfo - Extracts patch and authorship from a single e-mail message
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
@ -18,7 +18,7 @@ writes the commit log message in <msg> file, and the patches in
|
|||
<patch> file. The author name, e-mail and e-mail subject are
|
||||
written out to the standard output to be used by git-applypatch
|
||||
to create a commit. It is usually not necessary to use this
|
||||
command directly.
|
||||
command directly. See gitlink:git-am[1] instead.
|
||||
|
||||
|
||||
OPTIONS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-mailsplit(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-mailsplit - Totally braindamaged mbox splitter program
|
||||
git-mailsplit - Simple UNIX mbox splitter program
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
|
|
@ -3,7 +3,7 @@ git-merge-base(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-merge-base - Finds as good a common ancestor as possible for a merge
|
||||
git-merge-base - Find as good common ancestors as possible for a merge
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-merge-file(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-merge-file - three-way file merge
|
||||
git-merge-file - Run a three-way file merge
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-merge-index(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-merge-index - Runs a merge for files needing merging
|
||||
git-merge-index - Run a merge for files needing merging
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-merge-one-file(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-merge-one-file - The standard helper program to use with "git-merge-index"
|
||||
git-merge-one-file - The standard helper program to use with git-merge-index
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-merge(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-merge - Grand Unified Merge Driver
|
||||
git-merge - Join two or more development histories together
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-mv(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-mv - Move or rename a file, directory or symlink
|
||||
git-mv - Move or rename a file, a directory, or a symlink
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-pack-redundant(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-pack-redundant - Program used to find redundant pack files
|
||||
git-pack-redundant - Find redundant pack files
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
@ -21,7 +21,7 @@ given will be ignored when checking which packs are required. This makes the
|
|||
following command useful when wanting to remove packs which contain unreachable
|
||||
objects.
|
||||
|
||||
git-fsck-objects --full --unreachable | cut -d ' ' -f3 | \
|
||||
git-fsck --full --unreachable | cut -d ' ' -f3 | \
|
||||
git-pack-redundant --all | xargs rm
|
||||
|
||||
OPTIONS
|
||||
|
|
|
@ -29,12 +29,23 @@ file and used if found.
|
|||
Subsequent updates to branches always creates new file under
|
||||
`$GIT_DIR/refs` hierarchy.
|
||||
|
||||
A recommended practice to deal with a repository with too many
|
||||
refs is to pack its refs with `--all --prune` once, and
|
||||
occasionally run `git-pack-refs \--prune`. Tags are by
|
||||
definition stationary and are not expected to change. Branch
|
||||
heads will be packed with the initial `pack-refs --all`, but
|
||||
only the currently active branch heads will become unpacked,
|
||||
and next `pack-refs` (without `--all`) will leave them
|
||||
unpacked.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
\--all::
|
||||
|
||||
The command by default packs all tags and leaves branch tips
|
||||
The command by default packs all tags and refs that are already
|
||||
packed, and leaves other refs
|
||||
alone. This is because branches are expected to be actively
|
||||
developed and packing their tips does not help performance.
|
||||
This option causes branch tips to be packed as well. Useful for
|
||||
|
|
|
@ -3,7 +3,7 @@ git-parse-remote(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-parse-remote - Routines to help parsing $GIT_DIR/remotes/
|
||||
git-parse-remote - Routines to help parsing remote repository access parameters
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
@ -14,7 +14,8 @@ DESCRIPTION
|
|||
-----------
|
||||
This script is included in various scripts to supply
|
||||
routines to parse files under $GIT_DIR/remotes/ and
|
||||
$GIT_DIR/branches/.
|
||||
$GIT_DIR/branches/ and configuration variables that are related
|
||||
to fetching, pulling and pushing.
|
||||
|
||||
The primary entry points are:
|
||||
|
||||
|
@ -25,7 +26,8 @@ get_remote_refs_for_fetch::
|
|||
(e.g. `refs/heads/foo`). When `<refspec>...` is empty
|
||||
the returned list of refs consists of the defaults
|
||||
for the given `<repo>`, if specified in
|
||||
`$GIT_DIR/remotes/` or `$GIT_DIR/branches/`.
|
||||
`$GIT_DIR/remotes/`, `$GIT_DIR/branches/`, or `remote.*.fetch`
|
||||
configuration.
|
||||
|
||||
get_remote_refs_for_push::
|
||||
Given the list of user-supplied `<repo> <refspec>...`,
|
||||
|
|
|
@ -3,7 +3,7 @@ git-patch-id(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-patch-id - Generate a patch ID
|
||||
git-patch-id - Compute unique ID for a patch
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
|
|
@ -3,12 +3,12 @@ git-peek-remote(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-peek-remote - Lists the references in a remote repository
|
||||
git-peek-remote - List the references in a remote repository
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git-peek-remote' [--exec=<git-upload-pack>] [<host>:]<directory>
|
||||
'git-peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
@ -17,7 +17,7 @@ stores them in the local repository under the same name.
|
|||
|
||||
OPTIONS
|
||||
-------
|
||||
--exec=<git-upload-pack>::
|
||||
\--upload-pack=<git-upload-pack>::
|
||||
Use this to specify the path to 'git-upload-pack' on the
|
||||
remote side, if it is not found on your $PATH. Some
|
||||
installations of sshd ignores the user's environment
|
||||
|
@ -29,6 +29,9 @@ OPTIONS
|
|||
shells, but prefer having a lean .bashrc file (they set most of
|
||||
the things up in .bash_profile).
|
||||
|
||||
\--exec=<git-upload-pack>::
|
||||
Same \--upload-pack=<git-upload-pack>.
|
||||
|
||||
<host>::
|
||||
A remote host that houses the repository. When this
|
||||
part is specified, 'git-upload-pack' is invoked via
|
||||
|
|
|
@ -3,8 +3,7 @@ git-prune-packed(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-prune-packed - Program used to remove the extra object files that are now
|
||||
residing in a pack file.
|
||||
git-prune-packed - Remove extra objects that are already in pack files
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -13,7 +13,7 @@ SYNOPSIS
|
|||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
This runs `git-fsck-objects --unreachable` using all the refs
|
||||
This runs `git-fsck --unreachable` using all the refs
|
||||
available in `$GIT_DIR/refs`, optionally with additional set of
|
||||
objects specified on the command line, and prunes all
|
||||
objects unreachable from any of these head objects from the object database.
|
||||
|
|
|
@ -3,7 +3,7 @@ git-pull(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-pull - Pull and merge from another repository or a local branch
|
||||
git-pull - Fetch from and merge with another repository or a local branch
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
@ -42,7 +42,7 @@ git pull, git pull origin::
|
|||
current branch. Normally the branch merged in is
|
||||
the HEAD of the remote repository, but the choice is
|
||||
determined by the branch.<name>.remote and
|
||||
branch.<name>.merge options; see gitlink:git-repo-config[1]
|
||||
branch.<name>.merge options; see gitlink:git-config[1]
|
||||
for details.
|
||||
|
||||
git pull origin next::
|
||||
|
@ -52,7 +52,8 @@ git pull origin next::
|
|||
|
||||
git pull . fixes enhancements::
|
||||
Bundle local branch `fixes` and `enhancements` on top of
|
||||
the current branch, making an Octopus merge.
|
||||
the current branch, making an Octopus merge. This `git pull .`
|
||||
syntax is equivalent to `git merge`.
|
||||
|
||||
git pull -s ours . obsolete::
|
||||
Merge local branch `obsolete` into the current branch,
|
||||
|
@ -93,7 +94,7 @@ gitlink:git-reset[1].
|
|||
|
||||
SEE ALSO
|
||||
--------
|
||||
gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-repo-config[1]
|
||||
gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-config[1]
|
||||
|
||||
|
||||
Author
|
||||
|
|
|
@ -8,7 +8,7 @@ git-push - Update remote refs along with associated objects
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git-push' [--all] [--tags] [-f | --force] <repository> <refspec>...
|
||||
'git-push' [--all] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
@ -67,12 +67,33 @@ the remote repository.
|
|||
addition to refspecs explicitly listed on the command
|
||||
line.
|
||||
|
||||
\--receive-pack=<git-receive-pack>::
|
||||
Path to the 'git-receive-pack' program on the remote
|
||||
end. Sometimes useful when pushing to a remote
|
||||
repository over ssh, and you do not have the program in
|
||||
a directory on the default $PATH.
|
||||
|
||||
\--exec=<git-receive-pack>::
|
||||
Same as \--receive-pack=<git-receive-pack>.
|
||||
|
||||
-f, \--force::
|
||||
Usually, the command refuses to update a remote ref that is
|
||||
not a descendant of the local ref used to overwrite it.
|
||||
This flag disables the check. This can cause the
|
||||
remote repository to lose commits; use it with care.
|
||||
|
||||
\--repo=<repo>::
|
||||
When no repository is specified the command defaults to
|
||||
"origin"; this overrides it.
|
||||
|
||||
\--thin, \--no-thin::
|
||||
These options are passed to `git-send-pack`. Thin
|
||||
transfer spends extra cycles to minimize the number of
|
||||
objects to be sent and meant to be used on slower connection.
|
||||
|
||||
-v::
|
||||
Run verbosely.
|
||||
|
||||
include::urls.txt[]
|
||||
|
||||
Author
|
||||
|
|
|
@ -3,7 +3,7 @@ git-rebase(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-rebase - Rebase local commits to a new head
|
||||
git-rebase - Forward-port local commits to the updated upstream head
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
|
|
@ -3,7 +3,7 @@ git-receive-pack(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-receive-pack - Receive what is pushed into it
|
||||
git-receive-pack - Receive what is pushed into the repository
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -9,7 +9,7 @@ git-reflog - Manage reflog information
|
|||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git-reflog' expire [--dry-run]
|
||||
'git-reflog' expire [--dry-run] [--stale-fix]
|
||||
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
|
||||
|
||||
|
||||
|
|
|
@ -28,7 +28,7 @@ In the third form, gives some information about the remote <name>.
|
|||
|
||||
The remote configuration is achieved using the `remote.origin.url` and
|
||||
`remote.origin.fetch` configuration variables. (See
|
||||
gitlink:git-repo-config[1]).
|
||||
gitlink:git-config[1]).
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
@ -58,7 +58,7 @@ See Also
|
|||
--------
|
||||
gitlink:git-fetch[1]
|
||||
gitlink:git-branch[1]
|
||||
gitlink:git-repo-config[1]
|
||||
gitlink:git-config[1]
|
||||
|
||||
Author
|
||||
------
|
||||
|
|
|
@ -3,8 +3,7 @@ git-repack(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-repack - Script used to pack a repository from a collection of
|
||||
objects into pack files.
|
||||
git-repack - Pack unpacked objects in a repository
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,225 +3,16 @@ git-repo-config(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-repo-config - Get and set repository or global options.
|
||||
git-repo-config - Get and set repository or global options
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git-repo-config' [--global] [type] name [value [value_regex]]
|
||||
'git-repo-config' [--global] [type] --add name value
|
||||
'git-repo-config' [--global] [type] --replace-all name [value [value_regex]]
|
||||
'git-repo-config' [--global] [type] --get name [value_regex]
|
||||
'git-repo-config' [--global] [type] --get-all name [value_regex]
|
||||
'git-repo-config' [--global] [type] --unset name [value_regex]
|
||||
'git-repo-config' [--global] [type] --unset-all name [value_regex]
|
||||
'git-repo-config' [--global] -l | --list
|
||||
'git-repo-config' ...
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
You can query/set/replace/unset options with this command. The name is
|
||||
actually the section and the key separated by a dot, and the value will be
|
||||
escaped.
|
||||
|
||||
Multiple lines can be added to an option by using the '--add' option.
|
||||
If you want to update or unset an option which can occur on multiple
|
||||
lines, a POSIX regexp `value_regex` needs to be given. Only the
|
||||
existing values that match the regexp are updated or unset. If
|
||||
you want to handle the lines that do *not* match the regex, just
|
||||
prepend a single exclamation mark in front (see EXAMPLES).
|
||||
|
||||
The type specifier can be either '--int' or '--bool', which will make
|
||||
'git-repo-config' ensure that the variable(s) are of the given type and
|
||||
convert the value to the canonical form (simple decimal number for int,
|
||||
a "true" or "false" string for bool). If no type specifier is passed,
|
||||
no checks or transformations are performed on the value.
|
||||
|
||||
This command will fail if:
|
||||
|
||||
. The .git/config file is invalid,
|
||||
. Can not write to .git/config,
|
||||
. no section was provided,
|
||||
. the section or key is invalid,
|
||||
. you try to unset an option which does not exist,
|
||||
. you try to unset/set an option for which multiple lines match, or
|
||||
. you use --global option without $HOME being properly set.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
--replace-all::
|
||||
Default behavior is to replace at most one line. This replaces
|
||||
all lines matching the key (and optionally the value_regex).
|
||||
|
||||
--add::
|
||||
Adds a new line to the option without altering any existing
|
||||
values. This is the same as providing '^$' as the value_regex.
|
||||
|
||||
--get::
|
||||
Get the value for a given key (optionally filtered by a regex
|
||||
matching the value). Returns error code 1 if the key was not
|
||||
found and error code 2 if multiple key values were found.
|
||||
|
||||
--get-all::
|
||||
Like get, but does not fail if the number of values for the key
|
||||
is not exactly one.
|
||||
|
||||
--get-regexp::
|
||||
Like --get-all, but interprets the name as a regular expression.
|
||||
|
||||
--global::
|
||||
Use global ~/.gitconfig file rather than the repository .git/config.
|
||||
|
||||
--unset::
|
||||
Remove the line matching the key from config file.
|
||||
|
||||
--unset-all::
|
||||
Remove all matching lines from config file.
|
||||
|
||||
-l, --list::
|
||||
List all variables set in config file.
|
||||
|
||||
--bool::
|
||||
git-repo-config will ensure that the output is "true" or "false"
|
||||
|
||||
--int::
|
||||
git-repo-config will ensure that the output is a simple
|
||||
decimal number. An optional value suffix of 'k', 'm', or 'g'
|
||||
in the config file will cause the value to be multiplied
|
||||
by 1024, 1048576, or 1073741824 prior to output.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
GIT_CONFIG::
|
||||
Take the configuration from the given file instead of .git/config.
|
||||
Using the "--global" option forces this to ~/.gitconfig.
|
||||
|
||||
GIT_CONFIG_LOCAL::
|
||||
Currently the same as $GIT_CONFIG; when Git will support global
|
||||
configuration files, this will cause it to take the configuration
|
||||
from the global configuration file in addition to the given file.
|
||||
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
|
||||
Given a .git/config like this:
|
||||
|
||||
#
|
||||
# This is the config file, and
|
||||
# a '#' or ';' character indicates
|
||||
# a comment
|
||||
#
|
||||
|
||||
; core variables
|
||||
[core]
|
||||
; Don't trust file modes
|
||||
filemode = false
|
||||
|
||||
; Our diff algorithm
|
||||
[diff]
|
||||
external = "/usr/local/bin/gnu-diff -u"
|
||||
renames = true
|
||||
|
||||
; Proxy settings
|
||||
[core]
|
||||
gitproxy="ssh" for "ssh://kernel.org/"
|
||||
gitproxy="proxy-command" for kernel.org
|
||||
gitproxy="myprotocol-command" for "my://"
|
||||
gitproxy=default-proxy ; for all the rest
|
||||
|
||||
you can set the filemode to true with
|
||||
|
||||
------------
|
||||
% git repo-config core.filemode true
|
||||
------------
|
||||
|
||||
The hypothetical proxy command entries actually have a postfix to discern
|
||||
what URL they apply to. Here is how to change the entry for kernel.org
|
||||
to "ssh".
|
||||
|
||||
------------
|
||||
% git repo-config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
|
||||
------------
|
||||
|
||||
This makes sure that only the key/value pair for kernel.org is replaced.
|
||||
|
||||
To delete the entry for renames, do
|
||||
|
||||
------------
|
||||
% git repo-config --unset diff.renames
|
||||
------------
|
||||
|
||||
If you want to delete an entry for a multivar (like core.gitproxy above),
|
||||
you have to provide a regex matching the value of exactly one line.
|
||||
|
||||
To query the value for a given key, do
|
||||
|
||||
------------
|
||||
% git repo-config --get core.filemode
|
||||
------------
|
||||
|
||||
or
|
||||
|
||||
------------
|
||||
% git repo-config core.filemode
|
||||
------------
|
||||
|
||||
or, to query a multivar:
|
||||
|
||||
------------
|
||||
% git repo-config --get core.gitproxy "for kernel.org$"
|
||||
------------
|
||||
|
||||
If you want to know all the values for a multivar, do:
|
||||
|
||||
------------
|
||||
% git repo-config --get-all core.gitproxy
|
||||
------------
|
||||
|
||||
If you like to live dangerous, you can replace *all* core.gitproxy by a
|
||||
new one with
|
||||
|
||||
------------
|
||||
% git repo-config --replace-all core.gitproxy ssh
|
||||
------------
|
||||
|
||||
However, if you really only want to replace the line for the default proxy,
|
||||
i.e. the one without a "for ..." postfix, do something like this:
|
||||
|
||||
------------
|
||||
% git repo-config core.gitproxy ssh '! for '
|
||||
------------
|
||||
|
||||
To actually match only values with an exclamation mark, you have to
|
||||
|
||||
------------
|
||||
% git repo-config section.key value '[!]'
|
||||
------------
|
||||
|
||||
To add a new proxy, without altering any of the existing ones, use
|
||||
|
||||
------------
|
||||
% git repo-config core.gitproxy '"proxy" for example.com'
|
||||
------------
|
||||
|
||||
|
||||
include::config.txt[]
|
||||
|
||||
|
||||
Author
|
||||
------
|
||||
Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
|
||||
|
||||
Documentation
|
||||
--------------
|
||||
Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>.
|
||||
|
||||
GIT
|
||||
---
|
||||
Part of the gitlink:git[7] suite
|
||||
|
||||
This is a synonym for gitlink:git-config[1]. Please refer to the
|
||||
documentation of that command.
|
||||
|
|
|
@ -3,7 +3,7 @@ git-rerere(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-rerere - Reuse recorded resolve
|
||||
git-rerere - Reuse recorded resolution of conflicted merges
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
@ -38,7 +38,7 @@ its working state.
|
|||
|
||||
This resets the metadata used by rerere if a merge resolution is to be
|
||||
is aborted. Calling gitlink:git-am[1] --skip or gitlink:git-rebase[1]
|
||||
[--skip|--abort] will automatcally invoke this command.
|
||||
[--skip|--abort] will automatically invoke this command.
|
||||
|
||||
'diff'::
|
||||
|
||||
|
@ -81,7 +81,7 @@ One way to do it is to pull master into the topic branch:
|
|||
|
||||
------------
|
||||
$ git checkout topic
|
||||
$ git pull . master
|
||||
$ git merge master
|
||||
|
||||
o---*---o---+ topic
|
||||
/ /
|
||||
|
@ -103,10 +103,10 @@ in which case the final commit graph would look like this:
|
|||
|
||||
------------
|
||||
$ git checkout topic
|
||||
$ git pull . master
|
||||
$ git merge master
|
||||
$ ... work on both topic and master branches
|
||||
$ git checkout master
|
||||
$ git pull . topic
|
||||
$ git merge topic
|
||||
|
||||
o---*---o---+---o---o topic
|
||||
/ / \
|
||||
|
@ -126,11 +126,11 @@ top of the tip before the test merge:
|
|||
|
||||
------------
|
||||
$ git checkout topic
|
||||
$ git pull . master
|
||||
$ git merge master
|
||||
$ git reset --hard HEAD^ ;# rewind the test merge
|
||||
$ ... work on both topic and master branches
|
||||
$ git checkout master
|
||||
$ git pull . topic
|
||||
$ git merge topic
|
||||
|
||||
o---*---o-------o---o topic
|
||||
/ \
|
||||
|
|
|
@ -121,10 +121,6 @@ Undo a merge or pull::
|
|||
+
|
||||
------------
|
||||
$ git pull <1>
|
||||
Trying really trivial in-index merge...
|
||||
fatal: Merge requires file-level merging
|
||||
Nope.
|
||||
...
|
||||
Auto-merging nitfol
|
||||
CONFLICT (content): Merge conflict in nitfol
|
||||
Automatic merge failed/prevented; fix up by hand
|
||||
|
|
|
@ -12,6 +12,8 @@ SYNOPSIS
|
|||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
DEPRECATED. Use `git-merge` instead.
|
||||
|
||||
Given two commits and a merge message, merge the <merged> commit
|
||||
into <current> commit, with the commit log message <message>.
|
||||
|
||||
|
|
|
@ -27,6 +27,7 @@ SYNOPSIS
|
|||
[ \--pretty | \--header ]
|
||||
[ \--bisect ]
|
||||
[ \--merge ]
|
||||
[ \--walk-reflogs ]
|
||||
<commit>... [ \-- <paths>... ]
|
||||
|
||||
DESCRIPTION
|
||||
|
@ -190,6 +191,22 @@ limiting may be applied.
|
|||
In addition to the '<commit>' listed on the command
|
||||
line, read them from the standard input.
|
||||
|
||||
-g, --walk-reflogs::
|
||||
|
||||
Instead of walking the commit ancestry chain, walk
|
||||
reflog entries from the most recent one to older ones.
|
||||
When this option is used you cannot specify commits to
|
||||
exclude (that is, '{caret}commit', 'commit1..commit2',
|
||||
nor 'commit1...commit2' notations cannot be used).
|
||||
+
|
||||
With '\--pretty' format other than oneline (for obvious reasons),
|
||||
this causes the output to have two extra lines of information
|
||||
taken from the reflog. By default, 'commit@{Nth}' notation is
|
||||
used in the output. When the starting commit is specified as
|
||||
'commit@{now}', output also uses 'commit@{timestamp}' notation
|
||||
instead. Under '\--pretty=oneline', the commit message is
|
||||
prefixed with this information on the same line.
|
||||
|
||||
--merge::
|
||||
|
||||
After a failed merge, show refs that touch files having a
|
||||
|
|
|
@ -152,6 +152,14 @@ blobs contained in a commit.
|
|||
used immediately following a ref name and the ref must have an
|
||||
existing log ($GIT_DIR/logs/<ref>).
|
||||
|
||||
* A ref followed by the suffix '@' with an ordinal specification
|
||||
enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify
|
||||
the n-th prior value of that ref. For example 'master@\{1\}'
|
||||
is the immediate prior value of 'master' while 'master@\{5\}'
|
||||
is the 5th prior value of 'master'. This suffix may only be used
|
||||
immediately following a ref name and the ref must have an existing
|
||||
log ($GIT_DIR/logs/<ref>).
|
||||
|
||||
* A suffix '{caret}' to a revision parameter means the first parent of
|
||||
that commit object. '{caret}<n>' means the <n>th parent (i.e.
|
||||
'rev{caret}'
|
||||
|
|
|
@ -19,6 +19,8 @@ OPTIONS
|
|||
-------
|
||||
<commit>::
|
||||
Commit to revert.
|
||||
For a more complete list of ways to spell commit names, see
|
||||
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
|
||||
|
||||
-e|--edit::
|
||||
With this option, `git-revert` will let you edit the commit
|
||||
|
|
|
@ -60,21 +60,17 @@ a file that you have not told git about does not remove that file.
|
|||
EXAMPLES
|
||||
--------
|
||||
git-rm Documentation/\\*.txt::
|
||||
|
||||
Removes all `\*.txt` files from the index that are under the
|
||||
`Documentation` directory and any of its subdirectories. The
|
||||
files are not removed from the working tree.
|
||||
`Documentation` directory and any of its subdirectories.
|
||||
+
|
||||
Note that the asterisk `\*` is quoted from the shell in this
|
||||
example; this lets the command include the files from
|
||||
subdirectories of `Documentation/` directory.
|
||||
|
||||
git-rm -f git-*.sh::
|
||||
|
||||
Remove all git-*.sh scripts that are in the index. The files
|
||||
are removed from the index, and from the working
|
||||
tree. Because this example lets the shell expand the
|
||||
asterisk (i.e. you are listing the files explicitly), it
|
||||
Remove all git-*.sh scripts that are in the index.
|
||||
Because this example lets the shell expand the asterisk
|
||||
(i.e. you are listing the files explicitly), it
|
||||
does not remove `subdir/git-foo.sh`.
|
||||
|
||||
See Also
|
||||
|
|
|
@ -3,38 +3,51 @@ git-send-pack(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-send-pack - Push missing objects packed
|
||||
git-send-pack - Push objects over git protocol to another reposiotory
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git-send-pack' [--all] [--force] [--exec=<git-receive-pack>] [<host>:]<directory> [<ref>...]
|
||||
'git-send-pack' [--all] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Usually you would want to use gitlink:git-push[1] which is a
|
||||
higher level wrapper of this command instead.
|
||||
|
||||
Invokes 'git-receive-pack' on a possibly remote repository, and
|
||||
updates it from the current repository, sending named refs.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
--exec=<git-receive-pack>::
|
||||
\--receive-pack=<git-receive-pack>::
|
||||
Path to the 'git-receive-pack' program on the remote
|
||||
end. Sometimes useful when pushing to a remote
|
||||
repository over ssh, and you do not have the program in
|
||||
a directory on the default $PATH.
|
||||
|
||||
--all::
|
||||
\--exec=<git-receive-pack>::
|
||||
Same as \--receive-pack=<git-receive-pack>.
|
||||
|
||||
\--all::
|
||||
Instead of explicitly specifying which refs to update,
|
||||
update all refs that locally exist.
|
||||
|
||||
--force::
|
||||
\--force::
|
||||
Usually, the command refuses to update a remote ref that
|
||||
is not an ancestor of the local ref used to overwrite it.
|
||||
This flag disables the check. What this means is that
|
||||
the remote repository can lose commits; use it with
|
||||
care.
|
||||
|
||||
\--verbose::
|
||||
Run verbosely.
|
||||
|
||||
\--thin::
|
||||
Spend extra cycles to minimize the number of objects to be sent.
|
||||
Use it on slower connection.
|
||||
|
||||
<host>::
|
||||
A remote host to house the repository. When this
|
||||
part is specified, 'git-receive-pack' is invoked via
|
||||
|
|
|
@ -12,14 +12,51 @@ SYNOPSIS
|
|||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
Sets up the normal git environment variables and a few helper functions
|
||||
(currently just "die()"), and returns OK if it all looks like a git archive.
|
||||
So, to make the rest of the git scripts more careful and readable,
|
||||
use it as follows:
|
||||
This is not a command the end user would want to run. Ever.
|
||||
This documentation is meant for people who are studying the
|
||||
Porcelain-ish scripts and/or are writing new ones.
|
||||
|
||||
The `git-sh-setup` scriptlet is designed to be sourced (using
|
||||
`.`) by other shell scripts to set up some variables pointing at
|
||||
the normal git directories and a few helper shell functions.
|
||||
|
||||
Before sourcing it, your script should set up a few variables;
|
||||
`USAGE` (and `LONG_USAGE`, if any) is used to define message
|
||||
given by `usage()` shell function. `SUBDIRECTORY_OK` can be set
|
||||
if the script can run from a subdirectory of the working tree
|
||||
(some commands do not).
|
||||
|
||||
The scriptlet sets `GIT_DIR` and `GIT_OBJECT_DIRECTORY` shell
|
||||
variables, but does *not* export them to the environment.
|
||||
|
||||
FUNCTIONS
|
||||
---------
|
||||
|
||||
die::
|
||||
exit after emitting the supplied error message to the
|
||||
standard error stream.
|
||||
|
||||
usage::
|
||||
die with the usage message.
|
||||
|
||||
set_reflog_action::
|
||||
set the message that will be recorded to describe the
|
||||
end-user action in the reflog, when the script updates a
|
||||
ref.
|
||||
|
||||
is_bare_repository::
|
||||
outputs `true` or `false` to the standard output stream
|
||||
to indicate if the repository is a bare repository
|
||||
(i.e. without an associated working tree).
|
||||
|
||||
cd_to_toplevel::
|
||||
runs chdir to the toplevel of the working tree.
|
||||
|
||||
require_work_tree::
|
||||
checks if the repository is a bare repository, and dies
|
||||
if so. Used by scripts that require working tree
|
||||
(e.g. `checkout`).
|
||||
|
||||
-------------------------------------------------
|
||||
. git-sh-setup || die "Not a git archive"
|
||||
-------------------------------------------------
|
||||
|
||||
Author
|
||||
------
|
||||
|
|
|
@ -3,7 +3,7 @@ git-shell(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-shell - Restricted login shell for GIT over SSH only
|
||||
git-shell - Restricted login shell for GIT-only SSH access
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -29,7 +29,7 @@ OPTIONS
|
|||
of author alphabetic order.
|
||||
|
||||
-s::
|
||||
Supress commit description and provide a commit count summary only.
|
||||
Suppress commit description and provide a commit count summary only.
|
||||
|
||||
FILES
|
||||
-----
|
||||
|
|
|
@ -11,7 +11,7 @@ SYNOPSIS
|
|||
'git-show-branch' [--all] [--remotes] [--topo-order] [--current]
|
||||
[--more=<n> | --list | --independent | --merge-base]
|
||||
[--no-name | --sha1-name] [--topics] [<rev> | <glob>]...
|
||||
'git-show-branch' --reflog[=<n>] <ref>
|
||||
'git-show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] <ref>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
@ -97,9 +97,11 @@ OPTIONS
|
|||
will show the revisions given by "git rev-list {caret}master
|
||||
topic1 topic2"
|
||||
|
||||
--reflog[=<n>] <ref>::
|
||||
Shows <n> most recent ref-log entries for the given ref.
|
||||
|
||||
--reflog[=<n>[,<base>]] <ref>::
|
||||
Shows <n> most recent ref-log entries for the given
|
||||
ref. If <base> is given, <n> entries going back from
|
||||
that entry. <base> can be specified as count or date.
|
||||
`-g` can be used as a short-hand for this option.
|
||||
|
||||
Note that --more, --list, --independent and --merge-base options
|
||||
are mutually exclusive.
|
||||
|
@ -165,6 +167,13 @@ With this, `git show-branch` without extra parameters would show
|
|||
only the primary branches. In addition, if you happen to be on
|
||||
your topic branch, it is shown as well.
|
||||
|
||||
------------
|
||||
$ git show-branch --reflog='10,1 hour ago' --list master
|
||||
------------
|
||||
|
||||
shows 10 reflog entries going back from the tip as of 1 hour ago.
|
||||
Without `--list`, the output also shows how these tips are
|
||||
topologically related with each other.
|
||||
|
||||
|
||||
Author
|
||||
|
|
|
@ -32,6 +32,8 @@ OPTIONS
|
|||
-------
|
||||
<object>::
|
||||
The name of the object to show.
|
||||
For a more complete list of ways to spell object names, see
|
||||
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
|
||||
|
||||
include::pretty-formats.txt[]
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@ git-ssh-fetch(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-ssh-fetch - Pulls from a remote repository over ssh connection
|
||||
git-ssh-fetch - Fetch from a remote repository over ssh connection
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@ git-ssh-upload(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-ssh-upload - Pushes to a remote repository over ssh connection
|
||||
git-ssh-upload - Push to a remote repository over ssh connection
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
|
@ -3,7 +3,7 @@ git-status(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-status - Show working tree status
|
||||
git-status - Show the working tree status
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
@ -34,6 +34,15 @@ The output from this command is designed to be used as a commit
|
|||
template comments, and all the output lines are prefixed with '#'.
|
||||
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
|
||||
The command honors `color.status` (or `status.color` -- they
|
||||
mean the same thing and the latter is kept for backward
|
||||
compatibility) and `color.status.<slot>` configuration variables
|
||||
to colorize its output.
|
||||
|
||||
|
||||
Author
|
||||
------
|
||||
Written by Linus Torvalds <torvalds@osdl.org> and
|
||||
|
|
|
@ -3,7 +3,7 @@ git-svn(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-svn - bidirectional operation between Subversion and git
|
||||
git-svn - Bidirectional operation between a single Subversion branch and git
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
@ -113,7 +113,7 @@ manually joining branches on commit.
|
|||
|
||||
'commit-diff'::
|
||||
Commits the diff of two tree-ish arguments from the
|
||||
command-line. This command is intended for interopability with
|
||||
command-line. This command is intended for interoperability with
|
||||
git-svnimport and does not rely on being inside an git-svn
|
||||
init-ed repository. This command takes three arguments, (a) the
|
||||
original tree to diff against, (b) the new tree result, (c) the
|
||||
|
@ -204,7 +204,7 @@ removed by default if there are no files left in them. git
|
|||
cannot version empty directories. Enabling this flag will make
|
||||
the commit to SVN act like git.
|
||||
|
||||
repo-config key: svn.rmdir
|
||||
config key: svn.rmdir
|
||||
|
||||
-e::
|
||||
--edit::
|
||||
|
@ -215,7 +215,7 @@ Edit the commit message before committing to SVN. This is off by
|
|||
default for objects that are commits, and forced on when committing
|
||||
tree objects.
|
||||
|
||||
repo-config key: svn.edit
|
||||
config key: svn.edit
|
||||
|
||||
-l<num>::
|
||||
--find-copies-harder::
|
||||
|
@ -226,8 +226,8 @@ They are both passed directly to git-diff-tree see
|
|||
gitlink:git-diff-tree[1] for more information.
|
||||
|
||||
[verse]
|
||||
repo-config key: svn.l
|
||||
repo-config key: svn.findcopiesharder
|
||||
config key: svn.l
|
||||
config key: svn.findcopiesharder
|
||||
|
||||
-A<filename>::
|
||||
--authors-file=<filename>::
|
||||
|
@ -245,7 +245,7 @@ will abort operation. The user will then have to add the
|
|||
appropriate entry. Re-running the previous git-svn command
|
||||
after the authors-file is modified should continue operation.
|
||||
|
||||
repo-config key: svn.authorsfile
|
||||
config key: svn.authorsfile
|
||||
|
||||
-q::
|
||||
--quiet::
|
||||
|
@ -262,8 +262,8 @@ repo-config key: svn.authorsfile
|
|||
|
||||
--repack-flags are passed directly to gitlink:git-repack[1].
|
||||
|
||||
repo-config key: svn.repack
|
||||
repo-config key: svn.repackflags
|
||||
config key: svn.repack
|
||||
config key: svn.repackflags
|
||||
|
||||
-m::
|
||||
--merge::
|
||||
|
@ -304,7 +304,7 @@ used to track branches across multiple SVN _repositories_.
|
|||
This option may be specified multiple times, once for each
|
||||
branch.
|
||||
|
||||
repo-config key: svn.branch
|
||||
config key: svn.branch
|
||||
|
||||
-i<GIT_SVN_ID>::
|
||||
--id <GIT_SVN_ID>::
|
||||
|
@ -320,7 +320,7 @@ for more information on using GIT_SVN_ID.
|
|||
started tracking a branch and never tracked the trunk it was
|
||||
descended from.
|
||||
|
||||
repo-config key: svn.followparent
|
||||
config key: svn.followparent
|
||||
|
||||
--no-metadata::
|
||||
This gets rid of the git-svn-id: lines at the end of every commit.
|
||||
|
@ -332,7 +332,7 @@ repo-config key: svn.followparent
|
|||
The 'git-svn log' command will not work on repositories using this,
|
||||
either.
|
||||
|
||||
repo-config key: svn.nometadata
|
||||
config key: svn.nometadata
|
||||
|
||||
--
|
||||
|
||||
|
|
|
@ -3,11 +3,11 @@ git-symbolic-ref(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-symbolic-ref - read and modify symbolic refs
|
||||
git-symbolic-ref - Read and modify symbolic refs
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git-symbolic-ref' <name> [<ref>]
|
||||
'git-symbolic-ref' [-q] <name> [<ref>]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
@ -23,6 +23,14 @@ A symbolic ref is a regular file that stores a string that
|
|||
begins with `ref: refs/`. For example, your `.git/HEAD` is
|
||||
a regular file whose contents is `ref: refs/heads/master`.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
-q::
|
||||
Do not issue an error message if the <name> is not a
|
||||
symbolic ref but a detached HEAD; instead exit with
|
||||
non-zero status silently.
|
||||
|
||||
NOTES
|
||||
-----
|
||||
In the past, `.git/HEAD` was a symbolic link pointing at
|
||||
|
@ -36,6 +44,10 @@ cumbersome. On some platforms, `ln -sf` does not even work as
|
|||
advertised (horrors). Therefore symbolic links are now deprecated
|
||||
and symbolic refs are used by default.
|
||||
|
||||
git-symbolic-ref will exit with status 0 if the contents of the
|
||||
symbolic ref were printed correctly, with status 1 if the requested
|
||||
name is not a symbolic ref, or 128 if another error occurs.
|
||||
|
||||
Author
|
||||
------
|
||||
Written by Junio C Hamano <junkio@cox.net>
|
||||
|
|
|
@ -3,14 +3,14 @@ git-tag(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-tag - Create a tag object signed with GPG
|
||||
git-tag - Create, list, delete or verify a tag object signed with GPG
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git-tag' [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg> | -F <file>]
|
||||
<name> [<head>]
|
||||
'git-tag' [-a | -s | -u <key-id>] [-f | -v] [-m <msg> | -F <file>] <name> [<head>]
|
||||
'git-tag' -d <name>...
|
||||
'git-tag' -l [<pattern>]
|
||||
|
||||
DESCRIPTION
|
||||
|
@ -55,7 +55,7 @@ OPTIONS
|
|||
Replace an existing tag with the given name (instead of failing)
|
||||
|
||||
-d::
|
||||
Delete an existing tag with the given name
|
||||
Delete existing tags with the given names.
|
||||
|
||||
-v::
|
||||
Verify the gpg signature of given the tag
|
||||
|
@ -70,6 +70,16 @@ OPTIONS
|
|||
Take the tag message from the given file. Use '-' to
|
||||
read the message from the standard input.
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
By default, git-tag in sign-with-default mode (-s) will use your
|
||||
committer identity (of the form "Your Name <your@email.address>") to
|
||||
find a key. If you want to use a different default key, you can specify
|
||||
it in the repository configuration as follows:
|
||||
|
||||
[user]
|
||||
signingkey = <gpg-key-id>
|
||||
|
||||
Author
|
||||
------
|
||||
Written by Linus Torvalds <torvalds@osdl.org>,
|
||||
|
|
|
@ -3,7 +3,7 @@ git-tar-tree(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-tar-tree - Creates a tar archive of the files in the named tree
|
||||
git-tar-tree - Create a tar archive of the files in the named tree object
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
@ -50,7 +50,7 @@ repository configuration as follows :
|
|||
umask = 002 ;# group friendly
|
||||
|
||||
The special umask value "user" indicates that the user's current umask
|
||||
will be used instead. The default value remains 0, which means world
|
||||
will be used instead. The default value is 002, which means group
|
||||
readable/writable files and directories.
|
||||
|
||||
EXAMPLES
|
||||
|
|
|
@ -50,7 +50,7 @@ History Viewers
|
|||
gitview is a GTK based repository browser for git
|
||||
|
||||
|
||||
- *gitweb* (ftp://ftp.kernel.org/pub/software/scm/gitweb/)
|
||||
- *gitweb* (shipped with git-core)
|
||||
|
||||
GITweb provides full-fledged web interface for GIT repositories.
|
||||
|
||||
|
@ -63,12 +63,18 @@ History Viewers
|
|||
Currently it is the fastest and most feature rich among the git
|
||||
viewers and commit tools.
|
||||
|
||||
- *tig* (http://jonas.nitro.dk/tig/)
|
||||
|
||||
tig by Jonas Fonseca is a simple git repository browser
|
||||
written using ncurses. Basically, it just acts as a front-end
|
||||
for git-log and git-show/git-diff. Additionally, you can also
|
||||
use it as a pager for git commands.
|
||||
|
||||
|
||||
Foreign SCM interface
|
||||
---------------------
|
||||
|
||||
- *git-svn* (contrib/)
|
||||
- *git-svn* (shipped with git-core)
|
||||
|
||||
git-svn is a simple conduit for changesets between a single Subversion
|
||||
branch and git.
|
||||
|
@ -95,3 +101,7 @@ Others
|
|||
This is an Emacs interface for git. The user interface is modeled on
|
||||
pcl-cvs. It has been developed on Emacs 21 and will probably need some
|
||||
tweaking to work on XEmacs.
|
||||
|
||||
|
||||
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools has more
|
||||
comprehensive list.
|
||||
|
|
|
@ -3,7 +3,7 @@ git-update-index(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-update-index - Modifies the index or directory cache
|
||||
git-update-index - Register file contents in the working tree to the index
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
@ -289,7 +289,7 @@ Configuration
|
|||
|
||||
The command honors `core.filemode` configuration variable. If
|
||||
your repository is on an filesystem whose executable bits are
|
||||
unreliable, this should be set to 'false' (see gitlink:git-repo-config[1]).
|
||||
unreliable, this should be set to 'false' (see gitlink:git-config[1]).
|
||||
This causes the command to ignore differences in file modes recorded
|
||||
in the index and the file mode on the filesystem if they differ only on
|
||||
executable bit. On such an unfortunate filesystem, you may
|
||||
|
@ -301,7 +301,7 @@ The command looks at `core.ignorestat` configuration variable. See
|
|||
|
||||
See Also
|
||||
--------
|
||||
gitlink:git-repo-config[1]
|
||||
gitlink:git-config[1]
|
||||
|
||||
|
||||
Author
|
||||
|
|
|
@ -3,7 +3,7 @@ git-update-ref(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-update-ref - update the object name stored in a ref safely
|
||||
git-update-ref - Update the object name stored in a ref safely
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
|
|
@ -3,7 +3,7 @@ git-upload-archive(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-upload-archive - Send archive
|
||||
git-upload-archive - Send archive back to git-archive
|
||||
|
||||
|
||||
SYNOPSIS
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue