development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-08-27 11:39:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'bc/reflog-fix' into js/reflog-delete

Browse source 
* bc/reflog-fix: (1490 commits)
  builtin-reflog.c: don't install new reflog on write failure
  hash: fix lookup_hash semantics
  gitweb: Better chopping in commit search results
  builtin-tag.c: remove cruft
  git-merge-index documentation: clarify synopsis
  send-email: fix In-Reply-To regression
  git-reset --hard and git-read-tree --reset: fix read_cache_unmerged()
  Teach git-grep --name-only as synonym for -l
  diff: fix java funcname pattern for solaris
  t3404: use configured shell instead of /bin/sh
  git_config_*: don't assume we are parsing a config file
  prefix_path: use is_absolute_path() instead of *orig == '/'
  git-clean: handle errors if removing files fails
  Clarified the meaning of git-add -u in the documentation
  git-clone.sh: properly configure remote even if remote's head is dangling
  git.el: Set process-environment instead of invoking env
  Documentation/git-stash: document options for git stash list
  send-email: squelch warning due to comparing undefined $_ to ""
  cvsexportcommit: be graceful when "cvs status" reorders the arguments
  Rename git-core rpm to just git and rename the meta-pacakge to git-all.
  ...

Conflicts:

	Documentation/git-reflog.txt
	t/t1410-reflog.sh
This commit is contained in:
Junio C Hamano 2008-02-22 22:54:37 -08:00
parent cb97cc9fef 4cd883d724
commit 50f3ac29cb
691 changed files with 56179 additions and 14446 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
.gitattributes vendored Normal file
View file

@ -0,0 +1,2 @@
* whitespace=!indent,trail,space
*.[ch] whitespace

11
.gitignore vendored
View file

@ -35,12 +35,12 @@ git-diff-files
git-diff-index
git-diff-tree
git-describe
git-fast-export
git-fast-import
git-fetch
git-fetch--tool
git-fetch-pack
git-filter-branch
git-findtags
git-fmt-merge-msg
git-for-each-ref
git-format-patch
@ -57,7 +57,6 @@ git-index-pack
git-init
git-init-db
git-instaweb
git-local-fetch
git-log
git-lost-found
git-ls-files
@ -109,7 +108,6 @@ git-rev-list
git-rev-parse
git-revert
git-rm
git-runstatus
git-send-email
git-send-pack
git-sh-setup
@ -119,16 +117,11 @@ git-show
git-show-branch
git-show-index
git-show-ref
git-ssh-fetch
git-ssh-pull
git-ssh-push
git-ssh-upload
git-stash
git-status
git-stripspace
git-submodule
git-svn
git-svnimport
git-symbolic-ref
git-tag
git-tar-tree
@ -142,6 +135,7 @@ git-upload-pack
git-var
git-verify-pack
git-verify-tag
git-web--browse
git-whatchanged
git-write-tree
git-core-*/?*
@ -154,6 +148,7 @@ test-delta
test-dump-cache-tree
test-genrandom
test-match-trees
test-parse-options
test-sha1
common-cmds.h
*.tar.gz

5
.mailmap
View file

@ -6,6 +6,7 @@
#
Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Brian M. Carlson <sandals@crustytoothpaste.ath.cx>
Chris Shoemaker <c.shoemaker@cox.net>
Dana L. How <danahow@gmail.com>
Dana L. How <how@deathvalley.cswitch.com>
@ -16,6 +17,7 @@ H. Peter Anvin <hpa@bonde.sc.orionmulti.com>
H. Peter Anvin <hpa@tazenda.sc.orionmulti.com>
H. Peter Anvin <hpa@trantor.hos.anvin.org>
Horst H. von Brand <vonbrand@inf.utfsm.cl>
Jay Soffian <jaysoffian+git@gmail.com>
Joachim Berdal Haga <cjhaga@fys.uio.no>
Jon Loeliger <jdl@freescale.com>
Jon Seymour <jon@blackcubes.dyndns.org>
@ -24,6 +26,7 @@ Karl Hasselström <kha@treskal.com>
Kent Engstrom <kent@lysator.liu.se>
Lars Doelle <lars.doelle@on-line ! de>
Lars Doelle <lars.doelle@on-line.de>
Li Hong <leehong@pku.edu.cn>
Lukas Sandström <lukass@etek.chalmers.se>
Martin Langhoff <martin@catalyst.net.nz>
Michael Coleman <tutufan@gmail.com>
@ -37,9 +40,11 @@ Sam Vilain <sam@vilain.net>
Santi Béjar <sbejar@gmail.com>
Sean Estabrooks <seanlkml@sympatico.ca>
Shawn O. Pearce <spearce@spearce.org>
Steven Grimm <koreth@midwinter.com>
Theodore Ts'o <tytso@mit.edu>
Tony Luck <tony.luck@intel.com>
Uwe Kleine-König <Uwe_Zeisberger@digi.com>
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Uwe Kleine-König <uzeisberger@io.fsforth.de>
Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>

1
Documentation/.gitattributes vendored Normal file
View file

@ -0,0 +1 @@
*.txt whitespace

1
Documentation/.gitignore vendored
View file

@ -2,6 +2,7 @@
*.html
*.[1-8]
*.made
git.info
howto-index.txt
doc.dep
cmds-*.txt

112
Documentation/CodingGuidelines Normal file
View file

@ -0,0 +1,112 @@
Like other projects, we also have some guidelines to keep to the
code. For git in general, three rough rules are:
- Most importantly, we never say "It's in POSIX; we'll happily
ignore your needs should your system not conform to it."
We live in the real world.
- However, we often say "Let's stay away from that construct,
it's not even in POSIX".
- In spite of the above two rules, we sometimes say "Although
this is not in POSIX, it (is so convenient | makes the code
much more readable | has other good characteristics) and
practically all the platforms we care about support it, so
let's use it".
Again, we live in the real world, and it is sometimes a
judgement call, the decision based more on real world
constraints people face than what the paper standard says.
As for more concrete guidelines, just imitate the existing code
(this is a good guideline, no matter which project you are
contributing to). But if you must have a list of rules,
here they are.
For shell scripts specifically (not exhaustive):
- We prefer $( ... ) for command substitution; unlike ``, it
properly nests. It should have been the way Bourne spelled
it from day one, but unfortunately isn't.
- We use ${parameter-word} and its [-=?+] siblings, and their
colon'ed "unset or null" form.
- We use ${parameter#word} and its [#%] siblings, and their
doubled "longest matching" form.
- We use Arithmetic Expansion $(( ... )).
- No "Substring Expansion" ${parameter:offset:length}.
- No shell arrays.
- No strlen ${#parameter}.
- No regexp ${parameter/pattern/string}.
- We do not use Process Substitution <(list) or >(list).
- We prefer "test" over "[ ... ]".
- We do not write the noiseword "function" in front of shell
functions.
For C programs:
- We use tabs to indent, and interpret tabs as taking up to
8 spaces.
- We try to keep to at most 80 characters per line.
- When declaring pointers, the star sides with the variable
name, i.e. "char *string", not "char* string" or
"char * string". This makes it easier to understand code
like "char *string, c;".
- We avoid using braces unnecessarily. I.e.
if (bla) {
x = 1;
}
is frowned upon. A gray area is when the statement extends
over a few lines, and/or you have a lengthy comment atop of
it. Also, like in the Linux kernel, if there is a long list
of "else if" statements, it can make sense to add braces to
single line blocks.
- Try to make your code understandable. You may put comments
in, but comments invariably tend to stale out when the code
they were describing changes. Often splitting a function
into two makes the intention of the code much clearer.
- Double negation is often harder to understand than no negation
at all.
- Some clever tricks, like using the !! operator with arithmetic
constructs, can be extremely confusing to others. Avoid them,
unless there is a compelling reason to use them.
- Use the API. No, really. We have a strbuf (variable length
string), several arrays with the ALLOC_GROW() macro, a
path_list for sorted string lists, a hash map (mapping struct
objects) named "struct decorate", amongst other things.
- When you come up with an API, document it.
- The first #include in C files, except in platform specific
compat/ implementations, should be git-compat-util.h or another
header file that includes it, such as cache.h or builtin.h.
- If you are planning a new command, consider writing it in shell
or perl first, so that changes in semantics can be easily
changed and discussed. Many git commands started out like
that, and a few are still scripts.
- Avoid introducing a new dependency into git. This means you
usually should stay away from scripting languages not already
used in the git core command set (unless your command is clearly
separate from it, such as an importer to convert random-scm-X
repositories to git).

101
Documentation/Makefile
View file

@ -2,10 +2,14 @@ MAN1_TXT= \
$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard git-*.txt)) \
gitk.txt
MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt
MAN5_TXT=gitattributes.txt gitignore.txt gitcli.txt gitmodules.txt
MAN7_TXT=git.txt
DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT))
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
DOC_HTML=$(MAN_HTML)
ARTICLES = tutorial
ARTICLES += tutorial-2
@ -19,7 +23,10 @@ ARTICLES += everyday
ARTICLES += git-tools
ARTICLES += glossary
# with their own formatting rules.
SP_ARTICLES = howto/revert-branch-rebase user-manual
SP_ARTICLES = howto/revert-branch-rebase howto/using-merge-subtree user-manual
API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
SP_ARTICLES += $(API_DOCS)
SP_ARTICLES += technical/api-index
DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))
@ -29,6 +36,7 @@ DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
prefix?=$(HOME)
bindir?=$(prefix)/bin
htmldir?=$(prefix)/share/doc/git-doc
mandir?=$(prefix)/share/man
man1dir=$(mandir)/man1
man5dir=$(mandir)/man5
@ -37,9 +45,7 @@ man7dir=$(mandir)/man7
ASCIIDOC=asciidoc
ASCIIDOC_EXTRA =
ifdef ASCIIDOC8
ASCIIDOC_EXTRA += -a asciidoc7compatible
endif
MANPAGE_XSL = callouts.xsl
INSTALL?=install
RM ?= rm -f
DOC_REF = origin/man
@ -48,10 +54,21 @@ infodir?=$(prefix)/share/info
MAKEINFO=makeinfo
INSTALL_INFO=install-info
DOCBOOK2X_TEXI=docbook2x-texi
ifndef PERL_PATH
PERL_PATH = /usr/bin/perl
endif
-include ../config.mak.autogen
-include ../config.mak
ifdef ASCIIDOC8
ASCIIDOC_EXTRA += -a asciidoc7compatible
endif
ifdef DOCBOOK_XSL_172
ASCIIDOC_EXTRA += -a docbook-xsl-172
MANPAGE_XSL = manpage-1.72.xsl
endif
#
# Please note that there is a minor bug in asciidoc.
# The version after 6.0.3 _will_ include the patch found here:
@ -72,25 +89,29 @@ man1: $(DOC_MAN1)
man5: $(DOC_MAN5)
man7: $(DOC_MAN7)
info: git.info
info: git.info gitman.info
install: man
$(INSTALL) -d -m755 $(DESTDIR)$(man1dir)
$(INSTALL) -d -m755 $(DESTDIR)$(man5dir)
$(INSTALL) -d -m755 $(DESTDIR)$(man7dir)
$(INSTALL) -m644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
$(INSTALL) -m644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
$(INSTALL) -m644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
$(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
$(INSTALL) -d -m 755 $(DESTDIR)$(man5dir)
$(INSTALL) -d -m 755 $(DESTDIR)$(man7dir)
$(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
$(INSTALL) -m 644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
$(INSTALL) -m 644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
install-info: info
$(INSTALL) -d -m755 $(DESTDIR)$(infodir)
$(INSTALL) -m644 git.info $(DESTDIR)$(infodir)
$(INSTALL) -d -m 755 $(DESTDIR)$(infodir)
$(INSTALL) -m 644 git.info gitman.info $(DESTDIR)$(infodir)
if test -r $(DESTDIR)$(infodir)/dir; then \
$(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\
$(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) gitman.info ;\
else \
echo "No directory found in $(DESTDIR)$(infodir)" >&2 ; \
fi
install-html: html
sh ./install-webdoc.sh $(DESTDIR)$(htmldir)
../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
$(MAKE) -C ../ GIT-VERSION-FILE
@ -101,7 +122,7 @@ install-info: info
#
doc.dep : $(wildcard *.txt) build-docdep.perl
$(RM) $@+ $@
perl ./build-docdep.perl >$@+
$(PERL_PATH) ./build-docdep.perl >$@+
mv $@+ $@
-include doc.dep
@ -118,18 +139,21 @@ cmds_txt = cmds-ancillaryinterrogators.txt \
$(cmds_txt): cmd-list.made
cmd-list.made: cmd-list.perl $(MAN1_TXT)
cmd-list.made: cmd-list.perl ../command-list.txt $(MAN1_TXT)
$(RM) $@
perl ./cmd-list.perl
$(PERL_PATH) ./cmd-list.perl ../command-list.txt
date >$@
git.7 git.html: git.txt
clean:
$(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 *.texi *.texi+ howto-index.txt howto/*.html doc.dep
$(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7
$(RM) *.texi *.texi+ git.info gitman.info
$(RM) howto-index.txt howto/*.html doc.dep
$(RM) technical/api-*.html technical/api-index.txt
$(RM) $(cmds_txt) *.made
%.html : %.txt
$(MAN_HTML): %.html : %.txt
$(RM) $@+ $@
$(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
@ -137,7 +161,7 @@ clean:
%.1 %.5 %.7 : %.xml
$(RM) $@
xmlto -m callouts.xsl man $<
xmlto -m $(MANPAGE_XSL) man $<
%.xml : %.txt
$(RM) $@+ $@
@ -148,18 +172,41 @@ clean:
user-manual.xml: user-manual.txt user-manual.conf
$(ASCIIDOC) -b docbook -d book $<
technical/api-index.txt: technical/api-index-skel.txt \
technical/api-index.sh $(patsubst %,%.txt,$(API_DOCS))
cd technical && sh ./api-index.sh
$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt
$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt
XSLT = docbook.xsl
XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
user-manual.html: user-manual.xml
xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
git.info: user-manual.xml
$(RM) $@ $*.texi $*.texi+
$(DOCBOOK2X_TEXI) user-manual.xml --to-stdout >$*.texi+
perl fix-texi.perl <$*.texi+ >$*.texi
git.info: user-manual.texi
$(MAKEINFO) --no-split -o $@ user-manual.texi
user-manual.texi: user-manual.xml
$(RM) $@+ $@
$(DOCBOOK2X_TEXI) user-manual.xml --to-stdout | $(PERL_PATH) fix-texi.perl >$@+
mv $@+ $@
gitman.texi: $(MAN_XML) cat-texi.perl
$(RM) $@+ $@
($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --to-stdout $(xml);)) | \
$(PERL_PATH) cat-texi.perl $@ >$@+
mv $@+ $@
gitman.info: gitman.texi
$(MAKEINFO) --no-split $*.texi
$(RM) $*.texi $*.texi+
$(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
$(RM) $@+ $@
$(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@+
mv $@+ $@
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
$(RM) $@+ $@
@ -180,6 +227,6 @@ install-webdoc : html
sh ./install-webdoc.sh $(WEBDOC_DEST)
quick-install:
sh ./install-doc-quick.sh $(DOC_REF) $(mandir)
sh ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
.PHONY: .FORCE-GIT-VERSION-FILE

2
Documentation/RelNotes-1.5.3.3.txt
View file

@ -12,7 +12,7 @@ Fixes since v1.5.3.2
* The default shell on some FreeBSD did not execute the
argument parsing code correctly and made git unusable.
* git-svn incorrectly spawned pager even when the user user
* git-svn incorrectly spawned pager even when the user
explicitly asked not to.
* sample post-receive hook overquoted the envelope sender

60
Documentation/RelNotes-1.5.3.5.txt
View file

@ -4,37 +4,91 @@ GIT v1.5.3.5 Release Notes
Fixes since v1.5.3.4
--------------------
* Comes with git-gui 0.8.4.
* "git-config" silently ignored options after --list; now it will
error out with a usage message.
* "git-config --file" failed if the argument used a relative path
as it changed directories before opening the file.
* "git-config --file" now displays a proper error message if it
cannot read the file specified on the command line.
* "git-config", "git-diff", "git-apply" failed if run from a
subdirectory with relative GIT_DIR and GIT_WORK_TREE set.
* "git-blame" crashed if run during a merge conflict.
* "git-add -i" did not handle single line hunks correctly.
* "git-rebase -i" failed if external diff drivers were used for one
or more files in a commit. It now avoids calling the external
diff drivers.
* "git-rebase -i" and "git-stash apply" failed if external diff
drivers were used for one or more files in a commit. They now
avoid calling the external diff drivers.
* "git-log --follow" did not work unless diff generation (e.g. -p)
was also requested.
* "git-log --follow -B" did not work at all. Fixed.
* "git-log -M -B" did not correctly handle cases of very large files
being renamed and replaced by very small files in the same commit.
* "git-log" printed extra newlines between commits when a diff
was generated internally (e.g. -S or --follow) but not displayed.
* "git-push" error message is more helpful when pushing to a
repository with no matching refs and none specified.
* "git-push" now respects + (force push) on wildcard refspecs,
matching the behavior of git-fetch.
* "git-filter-branch" now updates the working directory when it
has finished filtering the current branch.
* "git-instaweb" no longer fails on Mac OS X.
* "git-cvsexportcommit" didn't always create new parent directories
before trying to create new child directories. Fixed.
* "git-fetch" printed a scary (but bogus) error message while
fetching a tag that pointed to a tree or blob. The error did
not impact correctness, only user perception. The bogus error
is no longer printed.
* "git-ls-files --ignored" did not properly descend into non-ignored
directories that themselves contained ignored files if d_type
was not supported by the filesystem. This bug impacted systems
such as AFS. Fixed.
* Git segfaulted when reading an invalid .gitattributes file. Fixed.
* post-receive-email example hook was fixed for non-fast-forward
updates.
* Documentation updates for supported (but previously undocumented)
options of "git-archive" and "git-reflog".
* "make clean" no longer deletes the configure script that ships
with the git tarball, making multiple architecture builds easier.
* "git-remote show origin" spewed a warning message from Perl
when no remote is defined for the current branch via
branch.<name>.remote configuration settings.
* Building with NO_PERL_MAKEMAKER excessively rebuilt contents
of perl/ subdirectory by rewriting perl.mak.
* http.sslVerify configuration settings were not used in scripted
Porcelains.
* "git-add" leaked a bit of memory while scanning for files to add.
* A few workarounds to squelch false warnings from recent gcc have
been added.
* "git-send-pack $remote frotz" segfaulted when there is nothing
named 'frotz' on the local end.
* "git-rebase --interactive" did not handle its "--strategy" option
properly.

48
Documentation/RelNotes-1.5.3.6.txt Normal file
View file

@ -0,0 +1,48 @@
GIT v1.5.3.6 Release Notes
==========================
Fixes since v1.5.3.5
--------------------
* git-cvsexportcommit handles root commits better.
* git-svn dcommit used to clobber when sending a series of
patches.
* git-svn dcommit failed after attempting to rebase when
started with a dirty index; now it stops upfront.
* git-grep sometimes refused to work when your index was
unmerged.
* "git-grep -A1 -B2" acted as if it was told to run "git -A1 -B21".
* git-hash-object did not honor configuration variables, such as
core.compression.
* git-index-pack choked on a huge pack on 32-bit machines, even when
large file offsets are supported.
* atom feeds from git-web said "10" for the month of November.
* a memory leak in commit walker was plugged.
* When git-send-email inserted the original author's From:
address in body, it did not mark the message with
Content-type: as needed.
* git-revert and git-cherry-pick incorrectly refused to start
when the work tree was dirty.
* git-clean did not honor core.excludesfile configuration.
* git-add mishandled ".gitignore" files when applying them to
subdirectories.
* While importing a too branchy history, git-fastimport did not
honor delta depth limit properly.
* Support for zlib implementations that lack ZLIB_VERNUM and definition
of deflateBound() has been added.
* Quite a lot of documentation clarifications.

45
Documentation/RelNotes-1.5.3.7.txt Normal file
View file

@ -0,0 +1,45 @@
GIT v1.5.3.7 Release Notes
==========================
Fixes since v1.5.3.6
--------------------
* git-send-email added 8-bit contents to the payload without
marking it as 8-bit in a CTE header.
* "git-bundle create a.bndl HEAD" dereferenced the symref and
did not record the ref as 'HEAD'; this prevented a bundle
from being used as a normal source of git-clone.
* The code to reject nonsense command line of the form
"git-commit -a paths..." and "git-commit --interactive
paths..." were broken.
* Adding a signature that is not ASCII-only to an original
commit that is ASCII-only would make the result non-ASCII.
"git-format-patch -s" did not mark such a message correctly
with MIME encoding header.
* git-add sometimes did not mark the resulting index entry
stat-clean. This affected only cases when adding the
contents with the same length as the previously staged
contents, and the previous staging made the index entry
"racily clean".
* git-commit did not honor GIT_INDEX_FILE the user had in the
environment.
* When checking out a revision, git-checkout did not report where the
updated HEAD is if you happened to have a file called HEAD in the
work tree.
* "git-rev-list --objects" mishandled a tree that points at a
submodule.
* "git cvsimport" was not ready for packed refs that "git gc" can
produce and gave incorrect results.
* Many scripted Porcelains were confused when you happened to have a
file called "HEAD" in your work tree.
Also it contains updates to the user manual and documentation.

25
Documentation/RelNotes-1.5.3.8.txt Normal file
View file

@ -0,0 +1,25 @@
GIT v1.5.3.8 Release Notes
==========================
Fixes since v1.5.3.7
--------------------
* Some documentation used "email.com" as an example domain.
* git-svn fix to handle funky branch and project names going over
http/https correctly.
* git-svn fix to tone down a needlessly alarming warning message.
* git-clone did not correctly report errors while fetching over http.
* git-send-email added redundant Message-Id: header to the outgoing
e-mail when the patch text already had one.
* a read-beyond-end-of-buffer bug in configuration file updater was fixed.
* git-grep used to show the same hit repeatedly for unmerged paths.
* After amending the patch title in "git-am -i", the command did not
report the patch it applied with the updated title.

17
Documentation/RelNotes-1.5.4.1.txt Normal file
View file

@ -0,0 +1,17 @@
GIT v1.5.4.1 Release Notes
==========================
Fixes since v1.5.4
------------------
* "git-commit -C $tag" used to work but rewrite in C done in
1.5.4 broke it.
* An entry in the .gitattributes file that names a pattern in a
subdirectory of the directory it is in did not match
correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should
match "a/b/foo.c" but it didn't).
* Customized color specification was parsed incorrectly when
numeric color values are used. This was fixed in 1.5.4.1.

43
Documentation/RelNotes-1.5.4.2.txt Normal file
View file

@ -0,0 +1,43 @@
GIT v1.5.4.2 Release Notes
==========================
Fixes since v1.5.4
------------------
* The configuration parser was not prepared to see string
valued variables misspelled as boolean and segfaulted.
* Temporary files left behind due to interrupted object
transfers were not cleaned up with "git prune".
* "git config --unset" was confused when the unset variables
were spelled with continuation lines in the config file.
* The merge message detection in "git cvsimport" did not catch
a message that began with "Merge...".
* "git status" suggests "git rm --cached" for unstaging the
earlier "git add" before the initial commit.
* "git status" output was incorrect during a partial commit.
* "git bisect" refused to start when the HEAD was detached.
* "git bisect" allowed a wildcard character in the commit
message expanded while writing its log file.
* Manual pages were not formatted correctly with docbook xsl
1.72; added a workaround.
* "git-commit -C $tag" used to work but rewrite in C done in
1.5.4 broke it. This was fixed in 1.5.4.1.
* An entry in the .gitattributes file that names a pattern in a
subdirectory of the directory it is in did not match
correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should
match "a/b/foo.c" but it didn't). This was fixed in 1.5.4.1.
* Customized color specification was parsed incorrectly when
numeric color values are used. This was fixed in 1.5.4.1.
* http transport misbehaved when linked with curl-gnutls.

368
Documentation/RelNotes-1.5.4.txt
View file

@ -1,35 +1,377 @@
GIT v1.5.4 Release Notes
========================
Removal
-------
* "git svnimport" was removed in favor of "git svn". It is still there
in the source tree (contrib/examples) but unsupported.
* As git-commit and git-status have been rewritten, "git runstatus"
helper script lost all its users and has been removed.
Temporarily disabled
--------------------
* "git http-push" is known not to work well with cURL library older
than 7.16, and we had reports of repository corruption. It is
disabled on such platforms for now. Unfortunately, 1.5.3.8 shares
the same issue. In other words, this does not mean you will be
fine if you stick to an older git release. For now, please do not
use http-push from older git with cURL older than 7.16 if you
value your data. A proper fix will hopefully materialize in
later versions.
Deprecation notices
-------------------
* From v1.6.0, git will by default install dashed form of commands
(e.g. "git-commit") outside of users' normal $PATH, and will install
only selected commands ("git" itself, and "gitk") in $PATH. This
implies:
- Using dashed forms of git commands (e.g. "git-commit") from the
command line has been informally deprecated since early 2006, but
now it officially is, and will be removed in the future. Use
dash-less forms (e.g. "git commit") instead.
- Using dashed forms from your scripts, without first prepending the
return value from "git --exec-path" to the scripts' PATH, has been
informally deprecated since early 2006, but now it officially is.
- Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
PATH" early in your script is not deprecated with this change.
Users are strongly encouraged to adjust their habits and scripts now
to prepare for this change.
* The post-receive hook was introduced in March 2007 to supersede
the post-update hook, primarily to overcome the command line length
limitation of the latter. Use of post-update hook will be deprecated
in future versions of git, starting from v1.6.0.
* "git lost-found" was deprecated in favor of "git fsck"'s --lost-found
option, and will be removed in the future.
* "git peek-remote" is deprecated, as "git ls-remote" was written in C
and works for all transports; "git peek-remote" will be removed in
the future.
* "git repo-config" which was an old name for "git config" command
has been supported without being advertised for a long time. The
next feature release will remove it.
* From v1.6.0, the repack.usedeltabaseoffset config option will default
to true, which will give denser packfiles (i.e. more efficient storage).
The downside is that git older than version 1.4.4 will not be able
to directly use a repository packed using this setting.
* From v1.6.0, the pack.indexversion config option will default to 2,
which is slightly more efficient, and makes repacking more immune to
data corruptions. Git older than version 1.5.2 may revert to version 1
of the pack index with a manual "git index-pack" to be able to directly
access corresponding pack files.
Updates since v1.5.3
--------------------
* git-reset is now built-in.
* Comes with much improved gitk, with i18n.
* git-send-email can optionally talk over ssmtp and use SMTP-AUTH.
* Comes with git-gui 0.9.2 with i18n.
* git-rebase learned --whitespace option.
* gitk is now merged as a subdirectory of git.git project, in
preparation for its i18n.
* git-remote knows --mirror mode.
* progress displays from many commands are a lot nicer to the eye.
Transfer commands show throughput data.
* git-merge can call the "post-merge" hook.
* many commands that pay attention to per-directory .gitignore now do
so lazily, which makes the usual case go much faster.
* git-pack-objects can optionally run deltification with multiple threads.
* Output processing for '--pretty=format:<user format>' has been
optimized.
* git-archive can optionally substitute keywords in files marked with
export-subst attribute.
* Rename detection of diff family while detecting exact matches has
been greatly optimized.
* Rename detection of diff family tries to make more natural looking
pairing. Earlier, if multiple identical rename sources were
found in the preimage, the source used was picked pretty much at random.
* Value "true" for color.diff and color.status configuration used to
mean "always" (even when the output is not going to a terminal).
This has been corrected to mean the same thing as "auto".
* "git diff" Porcelain now respects diff.external configuration, which
is another way to specify GIT_EXTERNAL_DIFF.
* "git diff" can be told to use different prefixes other than
"a/" and "b/" e.g. "git diff --src-prefix=l/ --dst-prefix=k/".
* "git diff" sometimes did not quote paths with funny
characters properly.
* "git log" (and any revision traversal commands) misbehaved
when --diff-filter is given but was not asked to actually
produce diff.
* HTTP proxy can be specified per remote repository using
remote.*.httpproxy configuration, or global http.proxy configuration
variable.
* Various Perforce importer updates.
* Example update and post-receive hooks have been improved.
* Any command that wants to take a commit object name can now use
":/string" syntax to name a commit.
* "git reset" is now built-in and its output can be squelched with -q.
* "git reset --hard" does not make any sense in a bare
repository, but did not error out; fixed.
* "git send-email" can optionally talk over ssmtp and use SMTP-AUTH.
* "git rebase" learned --whitespace option.
* In "git rebase", when you decide not to replay a particular change
after the command stopped with a conflict, you can say "git rebase
--skip" without first running "git reset --hard", as the command now
runs it for you.
* "git rebase --interactive" mode can now work on detached HEAD.
* Other minor to serious bugs in "git rebase -i" have been fixed.
* "git rebase" now detaches head during its operation, so after a
successful "git rebase" operation, the reflog entry branch@{1} for
the current branch points at the commit before the rebase was
started.
* "git rebase -i" also triggers rerere to help your repeated merges.
* "git merge" can call the "post-merge" hook.
* "git pack-objects" can optionally run deltification with multiple
threads.
* "git archive" can optionally substitute keywords in files marked with
export-subst attribute.
* "git cherry-pick" made a misguided attempt to repeat the original
command line in the generated log message, when told to cherry-pick a
commit by naming a tag that points at it. It does not anymore.
* "git for-each-ref" learned %(xxxdate:<date-format>) syntax to show the
various date fields in different formats.
* "git gc --auto" is a low-impact way to automatically run a variant of
"git repack" that does not lose unreferenced objects (read: safer
than the usual one) after the user accumulates too many loose
objects.
* "git clean" has been rewritten in C.
* You need to explicitly set clean.requireForce to "false" to allow
"git clean" without -f to do any damage (lack of the configuration
variable used to mean "do not require -f option to lose untracked
files", but we now use the safer default).
* The kinds of whitespace errors "git diff" and "git apply" notice (and
fix) can be controlled via 'core.whitespace' configuration variable
and 'whitespace' attribute in .gitattributes file.
* "git push" learned --dry-run option to show what would happen if a
push is run.
* "git push" does not update a tracking ref on the local side when the
remote refused to update the corresponding ref.
* "git push" learned --mirror option. This is to push the local refs
one-to-one to the remote, and deletes refs from the remote that do
not exist anymore in the repository on the pushing side.
* "git push" can remove a corrupt ref at the remote site with the usual
":ref" refspec.
* "git remote" knows --mirror mode. This is to set up configuration to
push into a remote repository to store local branch heads to the same
branch on the remote side, and remove branch heads locally removed
from local repository at the same time. Suitable for pushing into a
back-up repository.
* "git remote" learned "rm" subcommand.
* "git cvsserver" can be run via "git shell". Also, "cvs" is
recognized as a synonym for "git cvsserver", so that CVS users
can be switched to git just by changing their login shell.
* "git cvsserver" acts more like receive-pack by running post-receive
and post-update hooks.
* "git am" and "git rebase" are far less verbose.
* "git pull" learned to pass --[no-]ff option to underlying "git
merge".
* "git pull --rebase" is a different way to integrate what you fetched
into your current branch.
* "git fast-export" produces data-stream that can be fed to fast-import
to reproduce the history recorded in a git repository.
* "git add -i" takes pathspecs to limit the set of files to work on.
* "git add -p" is a short-hand to go directly to the selective patch
subcommand in the interactive command loop and to exit when done.
* "git add -i" UI has been colorized. The interactive prompt
and menu can be colored by setting color.interactive
configuration. The diff output (including the hunk picker)
are colored with color.diff configuration.
* "git commit --allow-empty" allows you to create a single-parent
commit that records the same tree as its parent, overriding the usual
safety valve.
* "git commit --amend" can amend a merge that does not change the tree
from its first parent.
* "git commit" used to unconditionally strip comment lines that
began with '#' and removed excess blank lines. This behavior has
been made configurable.
* "git commit" has been rewritten in C.
* "git stash random-text" does not create a new stash anymore. It was
a UI mistake. Use "git stash save random-text", or "git stash"
(without extra args) for that.
* "git stash clear extra-text" does not clear the whole stash
anymore. It is tempting to expect "git stash clear stash@{2}"
to drop only a single named stash entry, and it is rude to
discard everything when that is asked (but not provided).
* "git prune --expire <time>" can exempt young loose objects from
getting pruned.
* "git branch --contains <commit>" can list branches that are
descendants of a given commit.
* "git log" learned --early-output option to help interactive GUI
implementations.
* "git bisect" learned "skip" action to mark untestable commits.
* "git bisect visualize" learned a shorter synonym "git bisect view".
* "git bisect visualize" runs "git log" in a non-windowed
environments. It also can be told what command to run (e.g. "git
bisect visualize tig").
* "git format-patch" learned "format.numbered" configuration variable
to automatically turn --numbered option on when more than one commits
are formatted.
* "git ls-files" learned "--exclude-standard" to use the canned set of
exclude files.
* "git tag -a -f existing" begins the editor session using the existing
annotation message.
* "git tag -m one -m bar" (multiple -m options) behaves similarly to
"git commit"; the parameters to -m options are formatted as separate
paragraphs.
* The format "git show" outputs an annotated tag has been updated to
include "Tagger: " and "Date: " lines from the tag itself. Strictly
speaking this is a backward incompatible change, but this is a
reasonable usability fix and people's scripts shouldn't have been
relying on the exact output from "git show" Porcelain anyway.
* "git cvsimport" did not notice errors from underlying "cvsps"
and produced a corrupt import silently.
* "git cvsexportcommit" learned -w option to specify and switch to the
CVS working directory.
* "git checkout" from a subdirectory learned to use "../path" to allow
checking out a path outside the current directory without cd'ing up.
* "git checkout" from and to detached HEAD leaves a bit more
information in the reflog.
* "git send-email --dry-run" shows full headers for easier diagnosis.
* "git merge-ours" is now built-in.
* "git svn" learned "info" and "show-externals" subcommands.
* "git svn" run from a subdirectory failed to read settings from the
.git/config.
* "git svn" learned --use-log-author option, which picks up more
descriptive name from From: and Signed-off-by: lines in the commit
message.
* "git svn" wasted way too much disk to record revision mappings
between svn and git; a new representation that is much more compact
for this information has been introduced to correct this.
* "git svn" left temporary index files it used without cleaning them
up; this was corrected.
* "git status" from a subdirectory now shows relative paths, which
makes copy-and-pasting for git-checkout/git-add/git-rm easier. The
traditional behavior to show the full path relative to the top of
the work tree can be had by setting status.relativepaths
configuration variable to false.
* "git blame" kept text for each annotated revision in core needlessly;
this has been corrected.
* "git shortlog" learned to default to HEAD when the standard input is
a terminal and the user did not give any revision parameter.
* "git shortlog" learned "-e" option to show e-mail addresses as well as
authors' names.
* "git help" learned "-w" option to show documentation in browsers.
* In addition there are quite a few internal clean-ups. Notably:
- many fork/exec have been replaced with run-command API,
brought from the msysgit effort.
- introduction and more use of the option parser API.
- enhancement and more use of the strbuf API.
* Makefile tweaks to support HP-UX is in.
Fixes since v1.5.3
------------------
All of the fixes in v1.5.3 maintenance series are included in
this release, unless otherwise noted.
--
exec >/var/tmp/1
O=v1.5.3.2-99-ge4b2890
echo O=`git describe refs/heads/master`
git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint
These fixes are only in v1.5.4 and not backported to v1.5.3 maintenance
series.
* The way "git diff --check" behaves is much more consistent with the way
"git apply --whitespace=warn" works.
* "git svn" talking with the SVN over HTTP will correctly quote branch
and project names.
* "git config" did not work correctly on platforms that define
REG_NOMATCH to an even number.
* Recent versions of AsciiDoc 8 has a change to break our
documentation; a workaround has been implemented.
* "git diff --color-words" colored context lines in a wrong color.

78
Documentation/RelNotes-1.5.5.txt Normal file
View file

@ -0,0 +1,78 @@
GIT v1.5.5 Release Notes
========================
Updates since v1.5.4
--------------------
(performance)
* On platforms with suboptimal qsort(3) implementation, there
is an option to use more reasonable substitute we ship with
our software.
* New configuration variable "pack.packsizelimit" can be used
in place of command line option --max-pack-size.
* "git fetch" over the native git protocol used to make a
connection to find out the set of current remote refs and
another to actually download the pack data. We now use only
one connection for these tasks.
* "git commit" does not run lstat(2) more than necessary
anymore.
(usability, bells and whistles)
* You can be warned when core.autocrlf conversion is applied in
such a way that results in an irreversible conversion.
* A pattern "foo/" in .gitignore file now matches a directory
"foo". Pattern "foo" also matches as before.
* "git describe" learned to limit the tags to be used for
naming with --match option.
* "git describe --contains" now barfs when the named commit
cannot be described.
* bash completion's prompt helper function can talk about
operation in-progress (e.g. merge, rebase, etc.).
* "git commit" learned a new hook "prepare-commit-msg" that can
inspect what is going to be committed and prepare the commit
log message template to be edited.
* "git gui" learned an auto-spell checking.
* "git send-email" learned to prompt for passwords
interactively.
* "git send-email" learned an easier way to suppress CC
recipients.
* Various "git cvsimport", "git cvsexportcommit", "git svn" and
"git p4" improvements.
(internal)
* Duplicated code between git-help and git-instaweb that
launches user's preferred browser has been refactored.
* It is now easier to write test scripts that records known
breakages.
Fixes since v1.5.4
------------------
All of the fixes in v1.5.4 maintenance series are included in
this release, unless otherwise noted.
---
exec >/var/tmp/1
O=v1.5.4
O=v1.5.4.2-122-g7cb97da
echo O=`git describe refs/heads/master`
git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint

70
Documentation/SubmittingPatches
View file

@ -10,7 +10,7 @@ Checklist (and a short version for the impatient):
- the first line of the commit message should be a short
description and should skip the full stop
- if you want your work included in git.git, add a
"Signed-off-by: Your Name <your@email.com>" line to the
"Signed-off-by: Your Name <you@example.com>" line to the
commit message (or just use the option "-s" when
committing) to confirm that you agree to the Developer's
Certificate of Origin
@ -20,9 +20,6 @@ Checklist (and a short version for the impatient):
Patch:
- use "git format-patch -M" to create the patch
- send your patch to <git@vger.kernel.org>. If you use
git-send-email(1), please test it first by sending
email to yourself.
- do not PGP sign your patch
- do not attach your patch, but read in the mail
body, unless you cannot teach your mailer to
@ -31,13 +28,15 @@ Checklist (and a short version for the impatient):
corrupt whitespaces.
- provide additional information (which is unsuitable for
the commit message) between the "---" and the diffstat
- send the patch to the list (git@vger.kernel.org) and the
maintainer (gitster@pobox.com).
- if you change, add, or remove a command line option or
make some other user interface change, the associated
documentation should be updated as well.
- if your name is not writable in ASCII, make sure that
you send off a message in the correct encoding.
- send the patch to the list (git@vger.kernel.org) and the
maintainer (gitster@pobox.com) if (and only if) the patch
is ready for inclusion. If you use git-send-email(1),
please test it first by sending email to yourself.
Long version:
@ -113,7 +112,12 @@ lose tabs that way if you are not careful.
It is a common convention to prefix your subject line with
[PATCH]. This lets people easily distinguish patches from other
e-mail discussions.
e-mail discussions. Use of additional markers after PATCH and
the closing bracket to mark the nature of the patch is also
encouraged. E.g. [PATCH/RFC] is often used when the patch is
not ready to be applied but it is for discussion, [PATCH v2],
[PATCH v3] etc. are often seen when you are sending an update to
what you have previously sent.
"git format-patch" command follows the best current practice to
format the body of an e-mail message. At the beginning of the
@ -158,7 +162,8 @@ Note that your maintainer does not necessarily read everything
on the git mailing list. If your patch is for discussion first,
send it "To:" the mailing list, and optionally "cc:" him. If it
is trivially correct or after the list reached a consensus, send
it "To:" the maintainer and optionally "cc:" the list.
it "To:" the maintainer and optionally "cc:" the list for
inclusion.
Also note that your maintainer does not actively involve himself in
maintaining what are in contrib/ hierarchy. When you send fixes and
@ -211,10 +216,53 @@ then you just add a line saying
This line can be automatically added by git if you run the git-commit
command with the -s option.
Some people also put extra tags at the end. They'll just be ignored for
now, but you can do this to mark internal company procedures or just
point out some special detail about the sign-off.
Notice that you can place your own Signed-off-by: line when
forwarding somebody else's patch with the above rules for
D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
the change to its true author (see (2) above).
Some people also put extra tags at the end.
"Acked-by:" says that the patch was reviewed by the person who
is more familiar with the issues and the area the patch attempts
to modify. "Tested-by:" says the patch was tested by the person
and found to have the desired effect.
------------------------------------------------
An ideal patch flow
Here is an ideal patch flow for this project the current maintainer
suggests to the contributors:
(0) You come up with an itch. You code it up.
(1) Send it to the list and cc people who may need to know about
the change.
The people who may need to know are the ones whose code you
are butchering. These people happen to be the ones who are
most likely to be knowledgeable enough to help you, but
they have no obligation to help you (i.e. you ask for help,
don't demand). "git log -p -- $area_you_are_modifying" would
help you find out who they are.
(2) You get comments and suggestions for improvements. You may
even get them in a "on top of your change" patch form.
(3) Polish, refine, and re-send to the list and the people who
spend their time to improve your patch. Go back to step (2).
(4) The list forms consensus that the last round of your patch is
good. Send it to the list and cc the maintainer.
(5) A topic branch is created with the patch and is merged to 'next',
and cooked further and eventually graduates to 'master'.
In any time between the (2)-(3) cycle, the maintainer may pick it up
from the list and queue it to 'pu', in order to make it easier for
people play with it without having to pick up and apply the patch to
their trees themselves.
------------------------------------------------
MUA specific hints

11
Documentation/asciidoc.conf
View file

@ -1,6 +1,6 @@
## gitlink: macro
## linkgit: macro
#
# Usage: gitlink:command[manpage-section]
# Usage: linkgit:command[manpage-section]
#
# Note, {0} is the manpage section, while {target} is the command.
#
@ -15,7 +15,7 @@ endsb=&#93;
tilde=&#126;
ifdef::backend-docbook[]
[gitlink-inlinemacro]
[linkgit-inlinemacro]
{0%{target}}
{0#<citerefentry>}
{0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>}
@ -23,7 +23,9 @@ ifdef::backend-docbook[]
endif::backend-docbook[]
ifdef::backend-docbook[]
ifndef::docbook-xsl-172[]
# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this.
# v1.72 breaks with this because it replaces dots not in roff requests.
[listingblock]
<example><title>{title}</title>
<literallayout>
@ -36,6 +38,7 @@ ifdef::doctype-manpage[]
endif::doctype-manpage[]
</literallayout>
{title#}</example>
endif::docbook-xsl-172[]
endif::backend-docbook[]
ifdef::doctype-manpage[]
@ -58,6 +61,6 @@ endif::backend-docbook[]
endif::doctype-manpage[]
ifdef::backend-xhtml11[]
[gitlink-inlinemacro]
[linkgit-inlinemacro]
<a href="{target}.html">{target}{0?({0})}</a>
endif::backend-xhtml11[]

4
Documentation/blame-options.txt
View file

@ -39,7 +39,7 @@ of lines before or after the line given by <start>.
Show raw timestamp (Default: off).
-S <revs-file>::
Use revs from revs-file instead of calling gitlink:git-rev-list[1].
Use revs from revs-file instead of calling linkgit:git-rev-list[1].
-p, --porcelain::
Show in a format designed for machine consumption.
@ -52,7 +52,7 @@ of lines before or after the line given by <start>.
When <rev> is not specified, the command annotates the
changes starting backwards from the working tree copy.
This flag makes the command pretend as if the working
tree copy has the contents of he named file (specify
tree copy has the contents of the named file (specify
`-` to make the command read from the standard input).
-M|<num>|::

38
Documentation/cat-texi.perl Executable file
View file

@ -0,0 +1,38 @@
#!/usr/bin/perl -w
my @menu = ();
my $output = $ARGV[0];
open TMP, '>', "$output.tmp";
while (<STDIN>) {
next if (/^\\input texinfo/../\@node Top/);
next if (/^\@bye/ || /^\.ft/);
if (s/^\@top (.*)/\@node $1,,,Top/) {
push @menu, $1;
}
s/\(\@pxref{\[URLS\]}\)//;
print TMP;
}
close TMP;
printf '\input texinfo
@setfilename gitman.info
@documentencoding us-ascii
@node Top,,%s
@top Git Manual Pages
@documentlanguage en
@menu
', $menu[0];
for (@menu) {
print "* ${_}::\n";
}
print "\@end menu\n";
open TMP, '<', "$output.tmp";
while (<TMP>) {
print;
}
close TMP;
print "\@bye\n";
unlink "$output.tmp";

151
Documentation/cmd-list.perl
View file

@ -3,7 +3,8 @@
use File::Compare qw(compare);
sub format_one {
my ($out, $name) = @_;
my ($out, $nameattr) = @_;
my ($name, $attr) = @$nameattr;
my ($state, $description);
$state = 0;
open I, '<', "$name.txt" or die "No such file $name.txt";
@ -26,8 +27,11 @@ sub format_one {
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";
print $out "linkgit:$name\[1\]::\n\t";
if ($attr =~ / deprecated /) {
print $out "(deprecated) ";
}
print $out "$text.\n\n";
}
else {
die "Description does not match $name: $description";
@ -35,12 +39,13 @@ sub format_one {
}
my %cmds = ();
while (<DATA>) {
for (sort <>) {
next if /^#/;
chomp;
my ($name, $cat) = /^(\S+)\s+(.*)$/;
push @{$cmds{$cat}}, $name;
my ($name, $cat, $attr) = /^(\S+)\s+(.*?)(?:\s+(.*))?$/;
$attr = '' unless defined $attr;
push @{$cmds{$cat}}, [$name, " $attr "];
}
for my $cat (qw(ancillaryinterrogators
@ -67,137 +72,3 @@ sub format_one {
rename "$out+", "$out";
}
}
# The following list is sorted with "sort -d" to make it easier
# to find entry in the resulting git.html manual page.
__DATA__
git-add mainporcelain
git-am mainporcelain
git-annotate ancillaryinterrogators
git-apply plumbingmanipulators
git-archimport foreignscminterface
git-archive mainporcelain
git-bisect mainporcelain
git-blame ancillaryinterrogators
git-branch mainporcelain
git-bundle mainporcelain
git-cat-file plumbinginterrogators
git-check-attr purehelpers
git-checkout mainporcelain
git-checkout-index plumbingmanipulators
git-check-ref-format purehelpers
git-cherry ancillaryinterrogators
git-cherry-pick mainporcelain
git-citool mainporcelain
git-clean mainporcelain
git-clone mainporcelain
git-commit mainporcelain
git-commit-tree plumbingmanipulators
git-config ancillarymanipulators
git-count-objects ancillaryinterrogators
git-cvsexportcommit foreignscminterface
git-cvsimport foreignscminterface
git-cvsserver foreignscminterface
git-daemon synchingrepositories
git-describe mainporcelain
git-diff mainporcelain
git-diff-files plumbinginterrogators
git-diff-index plumbinginterrogators
git-diff-tree plumbinginterrogators
git-fast-import ancillarymanipulators
git-fetch mainporcelain
git-fetch-pack synchingrepositories
git-filter-branch ancillarymanipulators
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-gui 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 mainporcelain
git-merge-base plumbinginterrogators
git-merge-file plumbingmanipulators
git-merge-index plumbingmanipulators
git-merge-one-file purehelpers
git-mergetool ancillarymanipulators
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-remote ancillarymanipulators
git-repack ancillarymanipulators
git-request-pull foreignscminterface
git-rerere ancillaryinterrogators
git-reset 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-stash mainporcelain
git-status mainporcelain
git-stripspace purehelpers
git-submodule mainporcelain
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

342
Documentation/config.txt
View file

@ -115,7 +115,7 @@ porcelain configuration variables in the respective porcelain documentation.
core.fileMode::
If false, the executable bit differences between the index and
the working copy are ignored; useful on broken filesystems like FAT.
See gitlink:git-update-index[1]. True by default.
See linkgit:git-update-index[1]. True by default.
core.quotepath::
The commands that output paths (e.g. `ls-files`,
@ -139,10 +139,55 @@ core.autocrlf::
"text" (i.e. be subjected to the autocrlf mechanism) is
decided purely based on the contents.
core.safecrlf::
If true, makes git check if converting `CRLF` as controlled by
`core.autocrlf` is reversible. Git will verify if a command
modifies a file in the work tree either directly or indirectly.
For example, committing a file followed by checking out the
same file should yield the original file in the work tree. If
this is not the case for the current setting of
`core.autocrlf`, git will reject the file. The variable can
be set to "warn", in which case git will only warn about an
irreversible conversion but continue the operation.
+
CRLF conversion bears a slight chance of corrupting data.
autocrlf=true will convert CRLF to LF during commit and LF to
CRLF during checkout. A file that contains a mixture of LF and
CRLF before the commit cannot be recreated by git. For text
files this is the right thing to do: it corrects line endings
such that we have only LF line endings in the repository.
But for binary files that are accidentally classified as text the
conversion can corrupt data.
+
If you recognize such corruption early you can easily fix it by
setting the conversion type explicitly in .gitattributes. Right
after committing you still have the original file in your work
tree and this file is not yet corrupted. You can explicitly tell
git that this file is binary and git will handle the file
appropriately.
+
Unfortunately, the desired effect of cleaning up text files with
mixed line endings and the undesired effect of corrupting binary
files cannot be distinguished. In both cases CRLFs are removed
in an irreversible way. For text files this is the right thing
to do because CRLFs are line endings, while for binary files
converting CRLFs corrupts data.
+
Note, this safety check does not mean that a checkout will generate a
file identical to the original file for a different setting of
`core.autocrlf`, but only for the current one. For example, a text
file with `LF` would be accepted with `core.autocrlf=input` and could
later be checked out with `core.autocrlf=true`, in which case the
resulting file would contain `CRLF`, although the original file
contained `LF`. However, in both work trees the line endings would be
consistent, that is either all `LF` or all `CRLF`, but never mixed. A
file with mixed line endings would be reported by the `core.safecrlf`
mechanism.
core.symlinks::
If false, symbolic links are checked out as small plain files that
contain the link text. gitlink:git-update-index[1] and
gitlink:git-add[1] will not change the recorded type to regular
contain the link text. linkgit:git-update-index[1] and
linkgit:git-add[1] will not change the recorded type to regular
file. Useful on filesystems like FAT that do not support
symbolic links. True by default.
@ -163,7 +208,7 @@ core.ignoreStat::
The working copy files are assumed to stay unchanged until you
mark them otherwise manually - Git will not detect the file changes
by lstat() calls. This is useful on systems where those are very
slow, such as Microsoft Windows. See gitlink:git-update-index[1].
slow, such as Microsoft Windows. See linkgit:git-update-index[1].
False by default.
core.preferSymlinkRefs::
@ -176,10 +221,10 @@ core.bare::
If true this repository is assumed to be 'bare' and has no
working directory associated with it. If this is the case a
number of commands that require a working directory will be
disabled, such as gitlink:git-add[1] or gitlink:git-merge[1].
disabled, such as linkgit:git-add[1] or linkgit:git-merge[1].
+
This setting is automatically guessed by gitlink:git-clone[1] or
gitlink:git-init[1] when the repository was created. By default a
This setting is automatically guessed by linkgit:git-clone[1] or
linkgit:git-init[1] when the repository was created. By default a
repository that ends in "/.git" is assumed to be not bare (bare =
false), while all other repositories are assumed to be bare (bare
= true).
@ -216,7 +261,7 @@ core.sharedRepository::
group-writable). When 'all' (or 'world' or 'everybody'), the
repository will be readable by all users, additionally to being
group-shareable. When 'umask' (or 'false'), git will use permissions
reported by umask(2). See gitlink:git-init[1]. False by default.
reported by umask(2). See linkgit:git-init[1]. False by default.
core.warnAmbiguousRefs::
If true, git will warn you if the ref name you passed it is ambiguous
@ -226,13 +271,15 @@ core.compression::
An integer -1..9, indicating a default compression level.
-1 is the zlib default. 0 means no compression,
and 1..9 are various speed/size tradeoffs, 9 being slowest.
If set, this provides a default to other compression variables,
such as 'core.loosecompression' and 'pack.compression'.
core.loosecompression::
An integer -1..9, indicating the compression level for objects that
are not in a pack file. -1 is the zlib default. 0 means no
compression, and 1..9 are various speed/size tradeoffs, 9 being
slowest. If not set, defaults to core.compression. If that is
not set, defaults to 0 (best speed).
not set, defaults to 1 (best speed).
core.packedGitWindowSize::
Number of bytes of a pack file to map into memory in a
@ -279,7 +326,7 @@ core.excludesfile::
In addition to '.gitignore' (per-directory) and
'.git/info/exclude', git looks into this file for patterns
of files which are not meant to be tracked. See
gitlink:gitignore[5].
linkgit:gitignore[5].
core.editor::
Commands such as `commit` and `tag` that lets you edit
@ -293,8 +340,22 @@ core.pager::
The command that git will use to paginate output. Can be overridden
with the `GIT_PAGER` environment variable.
core.whitespace::
A comma separated list of common whitespace problems to
notice. `git diff` will use `color.diff.whitespace` to
highlight them, and `git apply --whitespace=error` will
consider them as errors:
+
* `trailing-space` treats trailing whitespaces at the end of the line
as an error (enabled by default).
* `space-before-tab` treats a space character that appears immediately
before a tab character in the initial indent part of the line as an
error (enabled by default).
* `indent-with-non-tab` treats a line that is indented with 8 or more
space characters as an error (not enabled by default).
alias.*::
Command aliases for the gitlink:git[1] command wrapper - e.g.
Command aliases for the linkgit:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
"git last" is equivalent to "git cat-file commit HEAD". To avoid
confusion and troubles with script usage, aliases that
@ -310,24 +371,25 @@ it will be treated as a shell command. For example, defining
apply.whitespace::
Tells `git-apply` how to handle whitespaces, in the same way
as the '--whitespace' option. See gitlink:git-apply[1].
as the '--whitespace' option. See linkgit:git-apply[1].
branch.autosetupmerge::
Tells `git-branch` and `git-checkout` to setup new branches
so that gitlink:git-pull[1] will appropriately merge from that
so that linkgit:git-pull[1] will appropriately merge from that
remote branch. Note that even if this option is not set,
this behavior can be chosen per-branch using the `--track`
and `--no-track` options. This option defaults to false.
and `--no-track` options. This option defaults to true.
branch.<name>.remote::
When in branch <name>, it tells `git fetch` which remote to fetch.
If this option is not given, `git fetch` defaults to remote "origin".
branch.<name>.merge::
When in branch <name>, it tells `git fetch` the default refspec to
be marked for merging in FETCH_HEAD. The value has exactly to match
a remote part of one of the refspecs which are fetched from the remote
given by "branch.<name>.remote".
When in branch <name>, it tells `git fetch` the default
refspec to be marked for merging in FETCH_HEAD. The value is
handled like the remote part of a refspec, and must match a
ref which is fetched from the remote given by
"branch.<name>.remote".
The merge information is used by `git pull` (which at first calls
`git fetch`) to lookup the default branch for merging. Without
this option, `git pull` defaults to merge the first refspec fetched.
@ -339,18 +401,30 @@ branch.<name>.merge::
branch.<name>.mergeoptions::
Sets default options for merging into branch <name>. The syntax and
supported options are equal to that of gitlink:git-merge[1], but
supported options are equal to that of linkgit:git-merge[1], but
option values containing whitespace characters are currently not
supported.
branch.<name>.rebase::
When true, rebase the branch <name> on top of the fetched branch,
instead of merging the default branch from the default remote.
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand the implications (see linkgit:git-rebase[1]
for details).
browser.<tool>.path::
Override the path for the given tool that may be used to
browse HTML help (see '-w' option in linkgit:git-help[1]) or a
working repository in gitweb (see linkgit:git-instaweb[1]).
clean.requireForce::
A boolean to make git-clean do nothing unless given -f or -n. Defaults
to false.
A boolean to make git-clean do nothing unless given -f
or -n. Defaults to true.
color.branch::
A boolean to enable/disable color in the output of
gitlink:git-branch[1]. May be set to `true` (or `always`),
`false` (or `never`) or `auto`, in which case colors are used
linkgit:git-branch[1]. May be set to `always`,
`false` (or `never`) or `auto` (or `true`), in which case colors are used
only when the output is to a terminal. Defaults to false.
color.branch.<slot>::
@ -368,17 +442,30 @@ 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.
When false (or `never`), never. When set to `auto`, use
colors only when the output is to the terminal.
When set to `always`, always use colors in patch.
When false (or `never`), never. When set to `true` or `auto`, use
colors only when the output is to the terminal. Defaults to false.
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), `new` (added lines),
`commit` (commit headers), or `whitespace` (highlighting dubious
whitespace). The values of these variables may be specified as
`commit` (commit headers), or `whitespace` (highlighting
whitespace errors). The values of these variables may be specified as
in color.branch.<slot>.
color.interactive::
When set to `always`, always use colors for interactive prompts
and displays (such as those used by "git add --interactive").
When false (or `never`), never. When set to `true` or `auto`, use
colors only when the output is to the terminal. Defaults to false.
color.interactive.<slot>::
Use customized color for `git add --interactive`
output. `<slot>` may be `prompt`, `header`, or `help`, for
three distinct types of normal output from interactive
programs. The values of these variables may be specified as
in color.branch.<slot>.
color.pager::
@ -387,8 +474,8 @@ color.pager::
color.status::
A boolean to enable/disable color in the output of
gitlink:git-status[1]. May be set to `true` (or `always`),
`false` (or `never`) or `auto`, in which case colors are used
linkgit:git-status[1]. May be set to `always`,
`false` (or `never`) or `auto` (or `true`), in which case colors are used
only when the output is to a terminal. Defaults to false.
color.status.<slot>::
@ -402,6 +489,13 @@ color.status.<slot>::
commit.template::
Specify a file to use as the template for new commit messages.
color.ui::
When set to `always`, always use colors in all git commands which
are capable of colored output. When false (or `never`), never. When
set to `true` or `auto`, use colors only when the output is to the
terminal. When more specific variables of color.* are set, they always
take precedence over this setting. Defaults to false.
diff.autorefreshindex::
When using `git diff` to compare with work tree
files, do not consider stat-only change as changed.
@ -412,6 +506,13 @@ diff.autorefreshindex::
affects only `git diff` Porcelain, and not lower level
`diff` commands, such as `git diff-files`.
diff.external::
If this config variable is set, diff generation is not
performed using the internal diff machinery, but using the
given command. Note: if you want to use an external diff
program only on a subset of your files, you might want to
use linkgit:gitattributes[5] instead.
diff.renameLimit::
The number of files to consider when performing the copy/rename
detection; equivalent to the git diff option '-l'.
@ -429,11 +530,18 @@ fetch.unpackLimit::
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.
especially on slow filesystems. If not set, the value of
`transfer.unpackLimit` is used instead.
format.numbered::
A boolean which can enable sequence numbers in patch subjects.
Setting this option to "auto" will enable it only if there is
more than one patch. See --numbered option in
linkgit:git-format-patch[1].
format.headers::
Additional email headers to include in a patch to be submitted
by mail. See gitlink:git-format-patch[1].
by mail. See linkgit:git-format-patch[1].
format.suffix::
The default for format-patch is to output files with the suffix
@ -449,14 +557,14 @@ gc.auto::
When there are approximately more than this many loose
objects in the repository, `git gc --auto` will pack them.
Some Porcelain commands use this command to perform a
light-weight garbage collection from time to time. Setting
this to 0 disables it.
light-weight garbage collection from time to time. The
default value is 6700. Setting this to 0 disables it.
gc.autopacklimit::
When there are more than this many packs that are not
marked with `*.keep` file in the repository, `git gc
--auto` consolidates them into one larger pack. Setting
this to 0 disables this.
--auto` consolidates them into one larger pack. The
default value is 20. Setting this to 0 disables it.
gc.packrefs::
`git gc` does not run `git pack-refs` in a bare repository by
@ -481,25 +589,27 @@ gc.reflogexpireunreachable::
gc.rerereresolved::
Records of conflicted merge you resolved earlier are
kept for this many days when `git rerere gc` is run.
The default is 60 days. See gitlink:git-rerere[1].
The default is 60 days. See linkgit:git-rerere[1].
gc.rerereunresolved::
Records of conflicted merge you have not resolved are
kept for this many days when `git rerere gc` is run.
The default is 15 days. See gitlink:git-rerere[1].
The default is 15 days. See linkgit:git-rerere[1].
rerere.enabled::
Activate recording of resolved conflicts, so that identical
conflict hunks can be resolved automatically, should they
be encountered again. See gitlink:git-rerere[1].
be encountered again. linkgit:git-rerere[1] command is by
default enabled if you create `rr-cache` directory under
`$GIT_DIR`, but can be disabled by setting this option to false.
gitcvs.enabled::
Whether the CVS server interface is enabled for this repository.
See gitlink:git-cvsserver[1].
See linkgit:git-cvsserver[1].
gitcvs.logfile::
Path to a log file where the CVS server interface well... logs
various stuff. See gitlink:git-cvsserver[1].
various stuff. See linkgit:git-cvsserver[1].
gitcvs.allbinary::
If true, all files are sent to the client in mode '-kb'. This
@ -512,7 +622,7 @@ gitcvs.dbname::
derived from the git repository. The exact meaning depends on the
used database driver, for SQLite (which is the default driver) this
is a filename. Supports variable substitution (see
gitlink:git-cvsserver[1] for details). May not contain semicolons (`;`).
linkgit:git-cvsserver[1] for details). May not contain semicolons (`;`).
Default: '%Ggitcvs.%m.sqlite'
gitcvs.dbdriver::
@ -521,19 +631,33 @@ gitcvs.dbdriver::
with 'DBD::SQLite', reported to work with 'DBD::Pg', and
reported *not* to work with 'DBD::mysql'. Experimental feature.
May not contain double colons (`:`). Default: 'SQLite'.
See gitlink:git-cvsserver[1].
See linkgit:git-cvsserver[1].
gitcvs.dbuser, gitcvs.dbpass::
Database user and password. Only useful if setting 'gitcvs.dbdriver',
since SQLite has no concept of database users and/or passwords.
'gitcvs.dbuser' supports variable substitution (see
gitlink:git-cvsserver[1] for details).
linkgit:git-cvsserver[1] for details).
All gitcvs variables except for 'gitcvs.allbinary' can also be
specified as 'gitcvs.<access_method>.<varname>' (where 'access_method'
is one of "ext" and "pserver") to make them apply only for the given
access method.
help.browser::
Specify the browser that will be used to display help in the
'web' format. See linkgit:git-help[1].
help.format::
Override the default help format used by linkgit:git-help[1].
Values 'man', 'info', 'web' and 'html' are supported. 'man' is
the default. 'web' and 'html' are the same.
http.proxy::
Override the HTTP proxy, normally configured using the 'http_proxy'
environment variable (see linkgit:curl[1]). This can be overridden
on a per-remote basis; see remote.<name>.proxy
http.sslVerify::
Whether to verify the SSL certificate when fetching or pushing
over HTTPS. Can be overridden by the 'GIT_SSL_NO_VERIFY' environment
@ -580,16 +704,35 @@ i18n.commitEncoding::
does not care per se, but this information is necessary e.g. when
importing commits from emails or in the gitk graphical history
browser (and possibly at other places in the future or in other
porcelains). See e.g. gitlink:git-mailinfo[1]. Defaults to 'utf-8'.
porcelains). See e.g. linkgit:git-mailinfo[1]. Defaults to 'utf-8'.
i18n.logOutputEncoding::
Character encoding the commit messages are converted to when
running `git-log` and friends.
instaweb.browser::
Specify the program that will be used to browse your working
repository in gitweb. See linkgit:git-instaweb[1].
instaweb.httpd::
The HTTP daemon command-line to start gitweb on your working
repository. See linkgit:git-instaweb[1].
instaweb.local::
If true the web server started by linkgit:git-instaweb[1] will
be bound to the local IP (127.0.0.1).
instaweb.modulepath::
The module path for an apache httpd used by linkgit:git-instaweb[1].
instaweb.port::
The port number to bind the gitweb httpd to. See
linkgit:git-instaweb[1].
log.showroot::
If true, the initial commit will be shown as a big creation event.
This is equivalent to a diff against an empty tree.
Tools like gitlink:git-log[1] or gitlink:git-whatchanged[1], which
Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
normally hide the root commit will now show it. True by default.
merge.summary::
@ -598,7 +741,7 @@ merge.summary::
merge.tool::
Controls which merge resolution program is used by
gitlink:git-mergetool[1]. Valid values are: "kdiff3", "tkdiff",
linkgit:git-mergetool[1]. Valid values are: "kdiff3", "tkdiff",
"meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and "opendiff".
merge.verbosity::
@ -611,27 +754,31 @@ merge.verbosity::
merge.<driver>.name::
Defines a human readable name for a custom low-level
merge driver. See gitlink:gitattributes[5] for details.
merge driver. See linkgit:gitattributes[5] for details.
merge.<driver>.driver::
Defines the command that implements a custom low-level
merge driver. See gitlink:gitattributes[5] for details.
merge driver. See linkgit:gitattributes[5] for details.
merge.<driver>.recursive::
Names a low-level merge driver to be used when
performing an internal merge between common ancestors.
See gitlink:gitattributes[5] for details.
See linkgit:gitattributes[5] for details.
mergetool.<tool>.path::
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
pack.window::
The size of the window used by gitlink:git-pack-objects[1] when no
The size of the window used by linkgit:git-pack-objects[1] when no
window size is given on the command line. Defaults to 10.
pack.depth::
The maximum delta depth used by gitlink:git-pack-objects[1] when no
The maximum delta depth used by linkgit:git-pack-objects[1] when no
maximum depth is given on the command line. Defaults to 50.
pack.windowMemory::
The window memory size limit used by gitlink:git-pack-objects[1]
The window memory size limit used by linkgit:git-pack-objects[1]
when no limit is given on the command line. The value can be
suffixed with "k", "m", or "g". Defaults to 0, meaning no
limit.
@ -641,25 +788,42 @@ pack.compression::
in a pack file. -1 is the zlib default. 0 means no
compression, and 1..9 are various speed/size tradeoffs, 9 being
slowest. If not set, defaults to core.compression. If that is
not set, defaults to -1.
not set, defaults to -1, the zlib default, which is "a default
compromise between speed and compression (currently equivalent
to level 6)."
pack.deltaCacheSize::
The maximum memory in bytes used for caching deltas in
gitlink:git-pack-objects[1].
linkgit:git-pack-objects[1].
A value of 0 means no limit. Defaults to 0.
pack.deltaCacheLimit::
The maximum size of a delta, that is cached in
gitlink:git-pack-objects[1]. Defaults to 1000.
linkgit:git-pack-objects[1]. Defaults to 1000.
pack.threads::
Specifies the number of threads to spawn when searching for best
delta matches. This requires that gitlink:git-pack-objects[1]
delta matches. This requires that linkgit:git-pack-objects[1]
be compiled with pthreads otherwise this option is ignored with a
warning. This is meant to reduce packing time on multiprocessor
machines. The required amount of memory for the delta search window
is however multiplied by the number of threads.
pack.indexVersion::
Specify the default pack index version. Valid values are 1 for
legacy pack index used by Git versions prior to 1.5.2, and 2 for
the new pack index with capabilities for packs larger than 4 GB
as well as proper protection against the repacking of corrupted
packs. Version 2 is selected and this config option ignored
whenever the corresponding pack is larger than 2 GB. Otherwise
the default is 1.
pack.packSizeLimit:
The default maximum size of a pack. This setting only affects
packing to a file, i.e. the git:// protocol is unaffected. It
can be overridden by the `\--max-pack-size` option of
linkgit:git-repack[1].
pull.octopus::
The default merge strategy to use when pulling multiple branches
at once.
@ -668,28 +832,33 @@ pull.twohead::
The default merge strategy to use when pulling a single branch.
remote.<name>.url::
The URL of a remote repository. See gitlink:git-fetch[1] or
gitlink:git-push[1].
The URL of a remote repository. See linkgit:git-fetch[1] or
linkgit:git-push[1].
remote.<name>.proxy::
For remotes that require curl (http, https and ftp), the URL to
the proxy to use for that remote. Set to the empty string to
disable proxying for that remote.
remote.<name>.fetch::
The default set of "refspec" for gitlink:git-fetch[1]. See
gitlink:git-fetch[1].
The default set of "refspec" for linkgit:git-fetch[1]. See
linkgit:git-fetch[1].
remote.<name>.push::
The default set of "refspec" for gitlink:git-push[1]. See
gitlink:git-push[1].
The default set of "refspec" for linkgit:git-push[1]. See
linkgit:git-push[1].
remote.<name>.skipDefaultUpdate::
If true, this remote will be skipped by default when updating
using the remote subcommand of gitlink:git-remote[1].
using the update subcommand of linkgit:git-remote[1].
remote.<name>.receivepack::
The default program to execute on the remote side when pushing. See
option \--exec of gitlink:git-push[1].
option \--exec of linkgit: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].
option \--exec of linkgit:git-fetch-pack[1].
remote.<name>.tagopt::
Setting this value to --no-tags disables automatic tag following when fetching
@ -697,51 +866,57 @@ remote.<name>.tagopt::
remotes.<group>::
The list of remotes which are fetched by "git remote update
<group>". See gitlink:git-remote[1].
<group>". See linkgit:git-remote[1].
repack.usedeltabaseoffset::
Allow gitlink:git-repack[1] to create packs that uses
Allow linkgit:git-repack[1] to create packs that uses
delta-base offset. Defaults to false.
show.difftree::
The default gitlink:git-diff-tree[1] arguments to be used
for gitlink:git-show[1].
The default linkgit:git-diff-tree[1] arguments to be used
for linkgit:git-show[1].
showbranch.default::
The default set of branches for gitlink:git-show-branch[1].
See gitlink:git-show-branch[1].
The default set of branches for linkgit:git-show-branch[1].
See linkgit:git-show-branch[1].
status.relativePaths::
By default, linkgit:git-status[1] shows paths relative to the
current directory. Setting this variable to `false` shows paths
relative to the repository root (this was the default for git
prior to v1.5.4).
tar.umask::
This variable can be used to restrict the permission bits of
tar archive entries. The default is 0002, which turns off the
world write bit. The special value "user" indicates that the
archiving user's umask will be used instead. See umask(2) and
gitlink:git-archive[1].
linkgit:git-archive[1].
user.email::
Your email address to be recorded in any newly created commits.
Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and
'EMAIL' environment variables. See gitlink:git-commit-tree[1].
'EMAIL' environment variables. See linkgit:git-commit-tree[1].
user.name::
Your full name to be recorded in any newly created commits.
Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
environment variables. See gitlink:git-commit-tree[1].
environment variables. See linkgit:git-commit-tree[1].
user.signingkey::
If gitlink:git-tag[1] is not selecting the key you want it to
If linkgit: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].
The default linkgit:git-diff-tree[1] arguments to be used
for linkgit:git-whatchanged[1].
imap::
The configuration variables in the 'imap' section are described
in gitlink:git-imap-send[1].
in linkgit:git-imap-send[1].
receive.unpackLimit::
If the number of objects received in a push is below this
@ -750,7 +925,8 @@ receive.unpackLimit::
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.
especially on slow filesystems. If not set, the value of
`transfer.unpackLimit` is used instead.
receive.denyNonFastForwards::
If set to true, git-receive-pack will deny a ref update which is
@ -761,3 +937,9 @@ receive.denyNonFastForwards::
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.
The default value is 100.
web.browser::
Specify a web browser that may be used by some commands.
Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
may use it.

64
Documentation/core-tutorial.txt
View file

@ -553,13 +553,8 @@ can explore on your own.
[NOTE]
Most likely, you are not directly using the core
git Plumbing commands, but using Porcelain like Cogito on top
of it. Cogito works a bit differently and you usually do not
have to run `git-update-index` yourself for changed files (you
do tell underlying git about additions and removals via
`cg-add` and `cg-rm` commands). Just before you make a commit
with `cg-commit`, Cogito figures out which files you modified,
and runs `git-update-index` on them for you.
git Plumbing commands, but using Porcelain such as `git-add`, `git-rm'
and `git-commit'.
Tagging a version
@ -583,7 +578,7 @@ particular state. You can, for example, do
$ git diff my-first-tag
----------------
to diff your current state against that tag (which at this point will
to diff your current state against that tag which at this point will
obviously be an empty diff, but if you continue to develop and commit
stuff, you can use your tag as an "anchor-point" to see what has changed
since you tagged it.
@ -686,8 +681,8 @@ $ git reset
and in fact a lot of the common git command combinations can be scripted
with the `git xyz` interfaces. You can learn things by just looking
at what the various git scripts do. For example, `git reset` is the
above two lines implemented in `git-reset`, but some things like
at what the various git scripts do. For example, `git reset` used to be
the above two lines implemented in `git-reset`, but some things like
`git status` and `git commit` are slightly more complex scripts around
the basic git commands.
@ -805,8 +800,8 @@ you have, you can say
$ git branch
------------
which is nothing more than a simple script around `ls .git/refs/heads`.
There will be asterisk in front of the branch you are currently on.
which used to be nothing more than a simple script around `ls .git/refs/heads`.
There will be an asterisk in front of the branch you are currently on.
Sometimes you may wish to create a new branch _without_ actually
checking it out and switching to it. If so, just use the command
@ -833,7 +828,7 @@ that branch, and do some work there.
------------------------------------------------
$ git checkout mybranch
$ echo "Work, work, work" >>hello
$ git commit -m 'Some work.' -i hello
$ git commit -m "Some work." -i hello
------------------------------------------------
Here, we just added another line to `hello`, and we used a shorthand for
@ -858,7 +853,7 @@ hasn't happened in the `master` branch at all. Then do
------------
$ echo "Play, play, play" >>hello
$ echo "Lots of fun" >>example
$ git commit -m 'Some fun.' -i hello example
$ git commit -m "Some fun." -i hello example
------------
since the master branch is obviously in a much better mood.
@ -883,7 +878,7 @@ script called `git merge`, which wants to know which branches you want
to resolve and what the merge is all about:
------------
$ git merge "Merge work in mybranch" HEAD mybranch
$ git merge -m "Merge work in mybranch" mybranch
------------
where the first argument is going to be used as the commit message if
@ -936,12 +931,13 @@ Another useful tool, especially if you do not always work in X-Window
environment, is `git show-branch`.
------------------------------------------------
$ git show-branch --topo-order master mybranch
$ git-show-branch --topo-order --more=1 master mybranch
* [master] Merge work in mybranch
! [mybranch] Some work.
--
- [master] Merge work in mybranch
*+ [mybranch] Some work.
* [master^] Some fun.
------------------------------------------------
The first two lines indicate that it is showing the two branches
@ -952,17 +948,29 @@ the later output lines is used to show commits contained in the
`master` branch, and the second column for the `mybranch`
branch. Three commits are shown along with their log messages.
All of them have non blank characters in the first column (`*`
shows an ordinary commit on the current branch, `.` is a merge commit), which
shows an ordinary commit on the current branch, `-` is a merge commit), which
means they are now part of the `master` branch. Only the "Some
work" commit has the plus `+` character in the second column,
because `mybranch` has not been merged to incorporate these
commits from the master branch. The string inside brackets
before the commit log message is a short name you can use to
name the commit. In the above example, 'master' and 'mybranch'
are branch heads. 'master~1' is the first parent of 'master'
are branch heads. 'master^' is the first parent of 'master'
branch head. Please see 'git-rev-parse' documentation if you
see more complex cases.
[NOTE]
Without the '--more=1' option, 'git-show-branch' would not output the
'[master^]' commit, as '[mybranch]' commit is a common ancestor of
both 'master' and 'mybranch' tips. Please see 'git-show-branch'
documentation for details.
[NOTE]
If there were more commits on the 'master' branch after the merge, the
merge commit itself would not be shown by 'git-show-branch' by
default. You would need to provide '--sparse' option to make the
merge commit visible in this case.
Now, let's pretend you are the one who did all the work in
`mybranch`, and the fruit of your hard work has finally been merged
to the `master` branch. Let's go back to `mybranch`, and run
@ -970,7 +978,7 @@ to the `master` branch. Let's go back to `mybranch`, and run
------------
$ git checkout mybranch
$ git merge "Merge upstream changes." HEAD master
$ git merge -m "Merge upstream changes." master
------------
This outputs something like this (the actual commit object names
@ -1082,11 +1090,6 @@ server like git Native transport does. Any stock HTTP server
that does not even support directory index would suffice. But
you must prepare your repository with `git-update-server-info`
to help dumb transport downloaders.
+
There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload`
programs, which are 'commit walkers'; they outlived their
usefulness when git Native and SSH transports were introduced,
and not used by `git pull` or `git push` scripts.
Once you fetch from the remote repository, you `merge` that
with your current branch.
@ -1149,7 +1152,7 @@ back to the earlier repository with "hello" and "example" file,
and bring ourselves back to the pre-merge state:
------------
$ git show-branch --more=3 master mybranch
$ git show-branch --more=2 master mybranch
! [master] Merge work in mybranch
* [mybranch] Merge work in mybranch
--
@ -1193,7 +1196,7 @@ $ mb=$(git-merge-base HEAD mybranch)
The command writes the commit object name of the common ancestor
to the standard output, so we captured its output to a variable,
because we will be using it in the next step. BTW, the common
because we will be using it in the next step. By the way, the common
ancestor commit is the "New day." commit in this case. You can
tell it by:
@ -1212,7 +1215,7 @@ $ git-read-tree -m -u $mb HEAD mybranch
This is the same `git-read-tree` command we have already seen,
but it takes three trees, unlike previous examples. This reads
the contents of each tree into different 'stage' in the index
file (the first tree goes to stage 1, the second stage 2,
file (the first tree goes to stage 1, the second to stage 2,
etc.). After reading three trees into three stages, the paths
that are the same in all three stages are 'collapsed' into stage
0. Also paths that are the same in two of three stages are
@ -1459,8 +1462,7 @@ Although git is a truly distributed system, it is often
convenient to organize your project with an informal hierarchy
of developers. Linux kernel development is run this way. There
is a nice illustration (page 17, "Merges to Mainline") in
link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf
[Randy Dunlap's presentation].
link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation].
It should be stressed that this hierarchy is purely *informal*.
There is nothing fundamental in git that enforces the "chain of
@ -1613,8 +1615,8 @@ in both of them. You could merge in 'diff-fix' first and then
'commit-fix' next, like this:
------------
$ git merge 'Merge fix in diff-fix' master diff-fix
$ git merge 'Merge fix in commit-fix' master commit-fix
$ git merge -m "Merge fix in diff-fix" diff-fix
$ git merge -m "Merge fix in commit-fix" commit-fix
------------
Which would result in:

10
Documentation/cvs-migration.txt
View file

@ -36,12 +36,12 @@ 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 config -l` and the gitlink:git-config[1] man
command; see `git config -l` and the linkgit:git-config[1] man
page for details.
================================
You can update the shared repository with your changes by first committing
your changes, and then using the gitlink:git-push[1] command:
your changes, and then using the linkgit:git-push[1] command:
------------------------------------------------
$ git push origin master
@ -88,7 +88,7 @@ Next, give every team member read/write access to this repository. One
easy way to do this is to give all the team members ssh access to the
machine where the repository is hosted. If you don't want to give them a
full shell on the machine, there is a restricted shell which only allows
users to do git pushes and pulls; see gitlink:git-shell[1].
users to do git pushes and pulls; see linkgit:git-shell[1].
Put all the committers in the same group, and make the repository
writable by that group:
@ -106,7 +106,7 @@ Importing a CVS archive
First, install version 2.1 or higher of cvsps from
link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
sure it is in your path. Then cd to a checked out CVS working directory
of the project you are interested in and run gitlink:git-cvsimport[1]:
of the project you are interested in and run linkgit:git-cvsimport[1]:
-------------------------------------------
$ git cvsimport -C <destination> <module>
@ -146,7 +146,7 @@ Providing CVS Access to a git Repository
----------------------------------------
It is also possible to provide true CVS access to a git repository, so
that developers can still use CVS; see gitlink:git-cvsserver[1] for
that developers can still use CVS; see linkgit:git-cvsserver[1] for
details.
Alternative Development Models

199
Documentation/diff-format.txt
View file

@ -1,5 +1,5 @@
The output format from "git-diff-index", "git-diff-tree" and
"git-diff-files" are very similar.
The output format from "git-diff-index", "git-diff-tree",
"git-diff-files" and "git diff --raw" are very similar.
These commands all compare two sets of things; what is
compared differs:
@ -62,7 +62,8 @@ respectively.
diff format for merges
----------------------
"git-diff-tree" and "git-diff-files" can take '-c' or '--cc' option
"git-diff-tree", "git-diff-files" and "git-diff --raw"
can take '-c' or '--cc' option
to generate diff output also for merge commits. The output differs
from the format described above in the following way:
@ -82,161 +83,65 @@ Note that 'combined diff' lists only files which were modified from
all parents.
Generating patches with -p
--------------------------
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
with a '-p' option, they do not produce the output described above;
instead they produce a patch file. You can customize the creation
of such patches via the GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS
environment variables.
What the -p option produces is slightly different from the traditional
diff format.
1. It is preceded with a "git diff" header, that looks like
this:
diff --git a/file1 b/file2
+
The `a/` and `b/` filenames are the same unless rename/copy is
involved. Especially, even for a creation or a deletion,
`/dev/null` is _not_ used in place of `a/` or `b/` filenames.
+
When rename/copy is involved, `file1` and `file2` show the
name of the source file of the rename/copy and the name of
the file that rename/copy produces, respectively.
2. It is followed by one or more extended header lines:
old mode <mode>
new mode <mode>
deleted file mode <mode>
new file mode <mode>
copy from <path>
copy to <path>
rename from <path>
rename to <path>
similarity index <number>
dissimilarity index <number>
index <hash>..<hash> <mode>
3. TAB, LF, double quote and backslash characters in pathnames
are represented as `\t`, `\n`, `\"` and `\\`, respectively.
If there is need for such substitution then the whole
pathname is put in double quotes.
The similarity index is the percentage of unchanged lines, and
the dissimilarity index is the percentage of changed lines. It
is a rounded down integer, followed by a percent sign. The
similarity index value of 100% is thus reserved for two equal
files, while 100% dissimilarity means that no line from the old
file made it into the new one.
include::diff-generate-patch.txt[]
combined diff format
--------------------
other diff formats
------------------
git-diff-tree and git-diff-files can take '-c' or '--cc' option
to produce 'combined diff', which looks like this:
The `--summary` option describes newly added, deleted, renamed and
copied files. The `--stat` option adds diffstat(1) graph to the
output. These options can be combined with other options, such as
`-p`, and are meant for human consumption.
------------
diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
}
When showing a change that involves a rename or a copy, `--stat` output
formats the pathnames compactly by combining common prefix and suffix of
the pathnames. For example, a change that moves `arch/i386/Makefile` to
`arch/x86/Makefile` while modifying 4 lines will be shown like this:
- static void describe(char *arg)
-static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
{
+ unsigned char sha1[20];
+ struct commit *cmit;
struct commit_list *list;
static int initialized = 0;
struct commit_name *n;
------------------------------------
arch/{i386 => x86}/Makefile | 4 +--
------------------------------------
+ if (get_sha1(arg, sha1) < 0)
+ usage(describe_usage);
+ cmit = lookup_commit_reference(sha1);
+ if (!cmit)
+ usage(describe_usage);
+
if (!initialized) {
initialized = 1;
for_each_ref(get_name);
------------
The `--numstat` option gives the diffstat(1) information but is designed
for easier machine consumption. An entry in `--numstat` output looks
like this:
1. It is preceded with a "git diff" header, that looks like
this (when '-c' option is used):
----------------------------------------
1 2 README
3 1 arch/{i386 => x86}/Makefile
----------------------------------------
diff --combined file
+
or like this (when '--cc' option is used):
That is, from left to right:
diff --c file
. the number of added lines;
. a tab;
. the number of deleted lines;
. a tab;
. pathname (possibly with rename/copy information);
. a newline.
2. It is followed by one or more extended header lines
(this example shows a merge with two parents):
When `-z` output option is in effect, the output is formatted this way:
index <hash>,<hash>..<hash>
mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>
+
The `mode <mode>,<mode>..<mode>` line appears only if at least one of
the <mode> is different from the rest. Extended headers with
information about detected contents movement (renames and
copying detection) are designed to work with diff of two
<tree-ish> and are not used by combined diff format.
----------------------------------------
1 2 README NUL
3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL
----------------------------------------
3. It is followed by two-line from-file/to-file header
That is:
--- a/file
+++ b/file
+
Similar to two-line header for traditional 'unified' diff
format, `/dev/null` is used to signal created or deleted
files.
. the number of added lines;
. a tab;
. the number of deleted lines;
. a tab;
. a NUL (only exists if renamed/copied);
. pathname in preimage;
. a NUL (only exists if renamed/copied);
. pathname in postimage (only exists if renamed/copied);
. a NUL.
4. Chunk header format is modified to prevent people from
accidentally feeding it to `patch -p1`. Combined diff format
was created for review of merge commit changes, and was not
meant for apply. The change is similar to the change in the
extended 'index' header:
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
+
There are (number of parents + 1) `@` characters in the chunk
header for combined diff format.
Unlike the traditional 'unified' diff format, which shows two
files A and B with a single column that has `-` (minus --
appears in A but removed in B), `+` (plus -- missing in A but
added to B), or `" "` (space -- unchanged) prefix, this format
compares two or more files file1, file2,... with one file X, and
shows how X differs from each of fileN. One column for each of
fileN is prepended to the output line to note how X's line is
different from it.
A `-` character in the column N means that the line appears in
fileN but it does not appear in the result. A `+` character
in the column N means that the line appears in the last file,
and fileN does not have that line (in other words, the line was
added, from the point of view of that parent).
In the above example output, the function signature was changed
from both files (hence two `-` removals from both file1 and
file2, plus `++` to mean one line that was added does not appear
in either file1 nor file2). Also two other lines are the same
from file1 but do not appear in file2 (hence prefixed with ` +`).
When shown by `git diff-tree -c`, it compares the parents of a
merge commit with the merge result (i.e. file1..fileN are the
parents). When shown by `git diff-files -c`, it compares the
two unresolved merge parents with the working tree file
(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
"their version").
The extra `NUL` before the preimage path in renamed case is to allow
scripts that read the output to tell if the current record being read is
a single-path record or a rename/copy record without reading ahead.
After reading added and deleted lines, reading up to `NUL` would yield
the pathname, but if that is `NUL`, the record will show two paths.

161
Documentation/diff-generate-patch.txt Normal file
View file

@ -0,0 +1,161 @@
Generating patches with -p
--------------------------
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
with a '-p' option, "git diff" without the '--raw' option, or
"git log" with the "-p" option, they
do not produce the output described above; instead they produce a
patch file. You can customize the creation of such patches via the
GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
What the -p option produces is slightly different from the traditional
diff format.
1. It is preceded with a "git diff" header, that looks like
this:
diff --git a/file1 b/file2
+
The `a/` and `b/` filenames are the same unless rename/copy is
involved. Especially, even for a creation or a deletion,
`/dev/null` is _not_ used in place of `a/` or `b/` filenames.
+
When rename/copy is involved, `file1` and `file2` show the
name of the source file of the rename/copy and the name of
the file that rename/copy produces, respectively.
2. It is followed by one or more extended header lines:
old mode <mode>
new mode <mode>
deleted file mode <mode>
new file mode <mode>
copy from <path>
copy to <path>
rename from <path>
rename to <path>
similarity index <number>
dissimilarity index <number>
index <hash>..<hash> <mode>
3. TAB, LF, double quote and backslash characters in pathnames
are represented as `\t`, `\n`, `\"` and `\\`, respectively.
If there is need for such substitution then the whole
pathname is put in double quotes.
The similarity index is the percentage of unchanged lines, and
the dissimilarity index is the percentage of changed lines. It
is a rounded down integer, followed by a percent sign. The
similarity index value of 100% is thus reserved for two equal
files, while 100% dissimilarity means that no line from the old
file made it into the new one.
combined diff format
--------------------
"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
'--cc' option to produce 'combined diff'. For showing a merge commit
with "git log -p", this is the default format.
A 'combined diff' format looks like this:
------------
diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
}
- static void describe(char *arg)
-static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
{
+ unsigned char sha1[20];
+ struct commit *cmit;
struct commit_list *list;
static int initialized = 0;
struct commit_name *n;
+ if (get_sha1(arg, sha1) < 0)
+ usage(describe_usage);
+ cmit = lookup_commit_reference(sha1);
+ if (!cmit)
+ usage(describe_usage);
+
if (!initialized) {
initialized = 1;
for_each_ref(get_name);
------------
1. It is preceded with a "git diff" header, that looks like
this (when '-c' option is used):
diff --combined file
+
or like this (when '--cc' option is used):
diff --c file
2. It is followed by one or more extended header lines
(this example shows a merge with two parents):
index <hash>,<hash>..<hash>
mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>
+
The `mode <mode>,<mode>..<mode>` line appears only if at least one of
the <mode> is different from the rest. Extended headers with
information about detected contents movement (renames and
copying detection) are designed to work with diff of two
<tree-ish> and are not used by combined diff format.
3. It is followed by two-line from-file/to-file header
--- a/file
+++ b/file
+
Similar to two-line header for traditional 'unified' diff
format, `/dev/null` is used to signal created or deleted
files.
4. Chunk header format is modified to prevent people from
accidentally feeding it to `patch -p1`. Combined diff format
was created for review of merge commit changes, and was not
meant for apply. The change is similar to the change in the
extended 'index' header:
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
+
There are (number of parents + 1) `@` characters in the chunk
header for combined diff format.
Unlike the traditional 'unified' diff format, which shows two
files A and B with a single column that has `-` (minus --
appears in A but removed in B), `+` (plus -- missing in A but
added to B), or `" "` (space -- unchanged) prefix, this format
compares two or more files file1, file2,... with one file X, and
shows how X differs from each of fileN. One column for each of
fileN is prepended to the output line to note how X's line is
different from it.
A `-` character in the column N means that the line appears in
fileN but it does not appear in the result. A `+` character
in the column N means that the line appears in the last file,
and fileN does not have that line (in other words, the line was
added, from the point of view of that parent).
In the above example output, the function signature was changed
from both files (hence two `-` removals from both file1 and
file2, plus `++` to mean one line that was added does not appear
in either file1 nor file2). Also two other lines are the same
from file1 but do not appear in file2 (hence prefixed with ` +`).
When shown by `git diff-tree -c`, it compares the parents of a
merge commit with the merge result (i.e. file1..fileN are the
parents). When shown by `git diff-files -c`, it compares the
two unresolved merge parents with the working tree file
(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
"their version").

55
Documentation/diff-options.txt
View file

@ -1,5 +1,27 @@
// Please don't remove this comment as asciidoc behaves badly when
// the first non-empty line is ifdef/ifndef. The symptom is that
// without this comment the <git-diff-core> attribute conditionally
// defined below ends up being defined unconditionally.
// Last checked with asciidoc 7.0.2.
ifndef::git-format-patch[]
ifndef::git-diff[]
ifndef::git-log[]
:git-diff-core: 1
endif::git-log[]
endif::git-diff[]
endif::git-format-patch[]
ifdef::git-format-patch[]
-p::
Generate patch (see section on generating patches)
Generate patches without diffstat.
endif::git-format-patch[]
ifndef::git-format-patch[]
-p::
Generate patch (see section on generating patches).
{git-diff? This is the default.}
endif::git-format-patch[]
-u::
Synonym for "-p".
@ -13,6 +35,7 @@
--raw::
Generate the raw format.
{git-diff-core? This is the default.}
--patch-with-raw::
Synonym for "-p --raw".
@ -41,6 +64,7 @@
--patch-with-stat::
Synonym for "-p --stat".
{git-format-patch? This is the default.}
-z::
NUL-line termination on output. This affects the --raw
@ -69,7 +93,9 @@
--check::
Warn if changes introduce trailing whitespace
or an indent that uses a space before a tab.
or an indent that uses a space before a tab. Exits with
non-zero status if problems are found. Not compatible with
--exit-code.
--full-index::
Instead of the first handful characters, show full
@ -151,19 +177,19 @@
Shorthand for "--text".
--ignore-space-at-eol::
Ignore changes in white spaces at EOL.
Ignore changes in whitespace at EOL.
--ignore-space-change::
Ignore changes in amount of white space. This ignores white
space at line end, and consider all other sequences of one or
more white space characters to be equivalent.
Ignore changes in amount of whitespace. This ignores whitespace
at line end, and considers all other sequences of one or
more whitespace characters to be equivalent.
-b::
Shorthand for "--ignore-space-change".
--ignore-all-space::
Ignore white space when comparing lines. This ignores
difference even if one line has white space where the other
Ignore whitespace when comparing lines. This ignores
differences even if one line has whitespace where the other
line has none.
-w::
@ -179,11 +205,20 @@
--ext-diff::
Allow an external diff helper to be executed. If you set an
external diff driver with gitlink:gitattributes[5], you need
to use this option with gitlink:git-log[1] and friends.
external diff driver with linkgit:gitattributes[5], you need
to use this option with linkgit:git-log[1] and friends.
--no-ext-diff::
Disallow external diff drivers.
--src-prefix=<prefix>::
Show the given source prefix instead of "a/".
--dst-prefix=<prefix>::
Show the given destination prefix instead of "b/".
--no-prefix::
Do not show any source or destination prefix.
For more detailed explanation on these common options, see also
link:diffcore.html[diffcore documentation].

71
Documentation/everyday.txt
View file

@ -25,16 +25,12 @@ Basic Repository[[Basic Repository]]
Everybody uses these commands to maintain git repositories.
* gitlink:git-init[1] or gitlink:git-clone[1] to create a
* linkgit:git-init[1] or linkgit:git-clone[1] to create a
new repository.
* gitlink:git-fsck[1] to check the repository for errors.
* linkgit:git-fsck[1] to check the repository for errors.
* gitlink:git-prune[1] to remove unused objects in the repository.
* gitlink:git-repack[1] to pack loose objects for efficiency.
* gitlink:git-gc[1] to do common housekeeping tasks such as
* linkgit:git-gc[1] to do common housekeeping tasks such as
repack and prune.
Examples
@ -45,24 +41,21 @@ Check health and remove cruft.::
------------
$ git fsck <1>
$ git count-objects <2>
$ git repack <3>
$ git gc <4>
$ git gc <3>
------------
+
<1> running without `\--full` is usually cheap and assures the
repository health reasonably well.
<2> check how many loose objects there are and how much
disk space is wasted by not repacking.
<3> without `-a` repacks incrementally. repacking every 4-5MB
of loose objects accumulation may be a good rule of thumb.
<4> it is easier to use `git gc` than individual housekeeping commands
such as `prune` and `repack`. This runs `repack -a -d`.
<3> repacks the local repository and performs other housekeeping tasks. Running
without `--prune` is a safe operation even while other ones are in progress.
Repack a small project into single pack.::
+
------------
$ git repack -a -d <1>
$ git prune
$ git gc <1>
$ git gc --prune
------------
+
<1> pack all the objects reachable from the refs into one pack,
@ -76,28 +69,28 @@ A standalone individual developer does not exchange patches with
other people, and works alone in a single repository, using the
following commands.
* gitlink:git-show-branch[1] to see where you are.
* linkgit:git-show-branch[1] to see where you are.
* gitlink:git-log[1] to see what happened.
* linkgit:git-log[1] to see what happened.
* gitlink:git-checkout[1] and gitlink:git-branch[1] to switch
* linkgit:git-checkout[1] and linkgit:git-branch[1] to switch
branches.
* gitlink:git-add[1] to manage the index file.
* linkgit:git-add[1] to manage the index file.
* gitlink:git-diff[1] and gitlink:git-status[1] to see what
* linkgit:git-diff[1] and linkgit:git-status[1] to see what
you are in the middle of doing.
* gitlink:git-commit[1] to advance the current branch.
* linkgit:git-commit[1] to advance the current branch.
* gitlink:git-reset[1] and gitlink:git-checkout[1] (with
* linkgit:git-reset[1] and linkgit:git-checkout[1] (with
pathname parameters) to undo changes.
* gitlink:git-merge[1] to merge between local branches.
* linkgit:git-merge[1] to merge between local branches.
* gitlink:git-rebase[1] to maintain topic branches.
* linkgit:git-rebase[1] to maintain topic branches.
* gitlink:git-tag[1] to mark known point.
* linkgit:git-tag[1] to mark known point.
Examples
~~~~~~~~
@ -109,7 +102,7 @@ $ tar zxf frotz.tar.gz
$ cd frotz
$ git-init
$ git add . <1>
$ git commit -m 'import of frotz source tree.'
$ git commit -m "import of frotz source tree."
$ git tag v2.43 <2>
------------
+
@ -163,16 +156,16 @@ A developer working as a participant in a group project needs to
learn how to communicate with others, and uses these commands in
addition to the ones needed by a standalone developer.
* gitlink:git-clone[1] from the upstream to prime your local
* linkgit:git-clone[1] from the upstream to prime your local
repository.
* gitlink:git-pull[1] and gitlink:git-fetch[1] from "origin"
* linkgit:git-pull[1] and linkgit:git-fetch[1] from "origin"
to keep up-to-date with the upstream.
* gitlink:git-push[1] to shared repository, if you adopt CVS
* linkgit:git-push[1] to shared repository, if you adopt CVS
style shared repository workflow.
* gitlink:git-format-patch[1] to prepare e-mail submission, if
* linkgit:git-format-patch[1] to prepare e-mail submission, if
you adopt Linux kernel-style public forum workflow.
Examples
@ -189,7 +182,7 @@ $ git pull <3>
$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
$ git reset --hard ORIG_HEAD <6>
$ git prune <7>
$ git gc --prune <7>
$ git fetch --tags <8>
------------
+
@ -265,17 +258,17 @@ project receives changes made by others, reviews and integrates
them and publishes the result for others to use, using these
commands in addition to the ones needed by participants.
* gitlink:git-am[1] to apply patches e-mailed in from your
* linkgit:git-am[1] to apply patches e-mailed in from your
contributors.
* gitlink:git-pull[1] to merge from your trusted lieutenants.
* linkgit:git-pull[1] to merge from your trusted lieutenants.
* gitlink:git-format-patch[1] to prepare and send suggested
* linkgit:git-format-patch[1] to prepare and send suggested
alternative to contributors.
* gitlink:git-revert[1] to undo botched commits.
* linkgit:git-revert[1] to undo botched commits.
* gitlink:git-push[1] to publish the bleeding edge.
* linkgit:git-push[1] to publish the bleeding edge.
Examples
@ -300,7 +293,7 @@ $ git merge topic/one topic/two && git merge hold/linus <8>
$ git checkout maint
$ git cherry-pick master~4 <9>
$ compile/test
$ git tag -s -m 'GIT 0.99.9x' v0.99.9x <10>
$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
$ git fetch ko && git show-branch master maint 'tags/ko-*' <11>
$ git push ko <12>
$ git push ko v0.99.9x <13>
@ -350,10 +343,10 @@ Repository Administration[[Repository Administration]]
A repository administrator uses the following tools to set up
and maintain access to the repository by developers.
* gitlink:git-daemon[1] to allow anonymous download from
* linkgit:git-daemon[1] to allow anonymous download from
repository.
* gitlink:git-shell[1] can be used as a 'restricted login shell'
* linkgit:git-shell[1] can be used as a 'restricted login shell'
for shared central repository users.
link:howto/update-hook-example.txt[update hook howto] has a good

14
Documentation/fetch-options.txt
View file

@ -23,11 +23,15 @@
fetches is a descendant of `<lbranch>`. This option
overrides that check.
ifdef::git-pull[]
\--no-tags::
endif::git-pull[]
ifndef::git-pull[]
-n, \--no-tags::
By default, `git-fetch` fetches tags that point at
objects that are downloaded from the remote repository
and stores them locally. This option disables this
automatic tag following.
endif::git-pull[]
By default, tags that point at objects that are downloaded
from the remote repository are fetched and stored locally.
This option disables this automatic tag following.
-t, \--tags::
Most of the tags are fetched automatically as branch
@ -50,5 +54,5 @@
\--depth=<depth>::
Deepen the history of a 'shallow' repository created by
`git clone` with `--depth=<depth>` option (see gitlink:git-clone[1])
`git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
by the specified number of commits.

36
Documentation/git-add.txt
View file

@ -8,7 +8,7 @@ git-add - Add file contents to the index
SYNOPSIS
--------
[verse]
'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--refresh]
'git-add' [-n] [-v] [-f] [--interactive | -i] [--patch | -p] [-u] [--refresh]
[--] <filepattern>...
DESCRIPTION
@ -37,7 +37,7 @@ directory recursion or filename globbing performed by Git (quote your
globs before the shell) will be silently ignored. The 'add' command can
be used to add ignored files with the `-f` (force) option.
Please see gitlink:git-commit[1] for alternative ways to add content to a
Please see linkgit:git-commit[1] for alternative ways to add content to a
commit.
@ -50,10 +50,10 @@ OPTIONS
and `dir/file2`) can be given to add all files in the
directory, recursively.
-n::
-n, \--dry-run::
Don't actually add the file(s), just show if they exist.
-v::
-v, \--verbose::
Be verbose.
-f::
@ -61,14 +61,21 @@ OPTIONS
-i, \--interactive::
Add modified contents in the working tree interactively to
the index.
the index. Optional path arguments may be supplied to limit
operation to a subset of the working tree. See ``Interactive
mode'' for details.
-p, \--patch::
Similar to Interactive mode but the initial command loop is
bypassed and the 'patch' subcommand is invoked using each of
the specified filepatterns before exiting.
-u::
Update only files that git already knows about. This is similar
to what "git commit -a" does in preparation for making a commit,
except that the update is limited to paths specified on the
command line. If no paths are specified, all tracked files are
updated.
command line. If no paths are specified, all tracked files in the
current directory and its subdirectories are updated.
\--refresh::
Don't add the file(s), but only refresh their stat()
@ -210,6 +217,8 @@ patch::
k - do not decide on this hunk now, and view the previous
undecided hunk
K - do not decide on this hunk now, and view the previous hunk
s - split the current hunk into smaller hunks
? - print help
+
After deciding the fate for all hunks, if there is any hunk
that was chosen, the index is updated with the selected hunks.
@ -222,11 +231,12 @@ diff::
See Also
--------
gitlink:git-status[1]
gitlink:git-rm[1]
gitlink:git-mv[1]
gitlink:git-commit[1]
gitlink:git-update-index[1]
linkgit:git-status[1]
linkgit:git-rm[1]
linkgit:git-reset[1]
linkgit:git-mv[1]
linkgit:git-commit[1]
linkgit:git-update-index[1]
Author
------
@ -238,4 +248,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

16
Documentation/git-am.txt
View file

@ -37,10 +37,10 @@ OPTIONS
area to store extracted patches.
-k, --keep::
Pass `-k` flag to `git-mailinfo` (see gitlink:git-mailinfo[1]).
Pass `-k` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
-u, --utf8::
Pass `-u` flag to `git-mailinfo` (see gitlink:git-mailinfo[1]).
Pass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
The proposed commit log message taken from the e-mail
is re-coded into UTF-8 encoding (configuration variable
`i18n.commitencoding` can be used to specify project's
@ -51,7 +51,7 @@ default. You could use `--no-utf8` to override this.
--no-utf8::
Pass `-n` flag to `git-mailinfo` (see
gitlink:git-mailinfo[1]).
linkgit:git-mailinfo[1]).
-3, --3way::
When the patch does not apply cleanly, fall back on
@ -61,15 +61,15 @@ default. You could use `--no-utf8` to override this.
-b, --binary::
Pass `--allow-binary-replacement` flag to `git-apply`
(see gitlink:git-apply[1]).
(see linkgit:git-apply[1]).
--whitespace=<option>::
This flag is passed to the `git-apply` (see gitlink:git-apply[1])
This flag is passed to the `git-apply` (see linkgit:git-apply[1])
program that applies
the patch.
-C<n>, -p<n>::
These flags are passed to the `git-apply` (see gitlink:git-apply[1])
These flags are passed to the `git-apply` (see linkgit:git-apply[1])
program that applies
the patch.
@ -144,7 +144,7 @@ names.
SEE ALSO
--------
gitlink:git-apply[1].
linkgit:git-apply[1].
Author
@ -157,4 +157,4 @@ Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.o
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

4
Documentation/git-annotate.txt
View file

@ -20,7 +20,7 @@ include::blame-options.txt[]
SEE ALSO
--------
gitlink:git-blame[1]
linkgit:git-blame[1]
AUTHOR
------
@ -28,4 +28,4 @@ Written by Ryan Anderson <ryan@michonline.com>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

47
Documentation/git-apply.txt
View file

@ -13,7 +13,7 @@ SYNOPSIS
[--apply] [--no-add] [--build-fake-ancestor <file>] [-R | --reverse]
[--allow-binary-replacement | --binary] [--reject] [-z]
[-pNUM] [-CNUM] [--inaccurate-eof] [--cached]
[--whitespace=<nowarn|warn|error|error-all|strip>]
[--whitespace=<nowarn|warn|fix|error|error-all>]
[--exclude=PATH] [--verbose] [<patch>...]
DESCRIPTION
@ -77,7 +77,7 @@ the information is read from the current index instead.
Apply the patch in reverse.
--reject::
For atomicity, gitlink:git-apply[1] by default fails the whole patch and
For atomicity, linkgit:git-apply[1] by default fails the whole patch and
does not touch the working tree when some of the hunks
do not apply. This option makes it apply
the parts of the patch that are applicable, and leave the
@ -101,7 +101,7 @@ the information is read from the current index instead.
ever ignored.
--unidiff-zero::
By default, gitlink:git-apply[1] expects that the patch being
By default, linkgit:git-apply[1] expects that the patch being
applied is a unified diff with at least one line of context.
This provides good safety measures, but breaks down when
applying a diff generated with --unified=0. To bypass these
@ -112,14 +112,14 @@ discouraged.
--apply::
If you use any of the options marked "Turns off
'apply'" above, gitlink:git-apply[1] reads and outputs the
'apply'" above, linkgit:git-apply[1] reads and outputs the
information you asked without actually applying the
patch. Give this flag after those flags to also apply
the patch.
--no-add::
When applying a patch, ignore additions made by the
patch. This can be used to extract common part between
patch. This can be used to extract the common part between
two files by first running `diff` on them and applying
the result with this option, which would apply the
deletion part but not addition part.
@ -135,25 +135,32 @@ discouraged.
be useful when importing patchsets, where you want to exclude certain
files or directories.
--whitespace=<option>::
When applying a patch, detect a new or modified line
that ends with trailing whitespaces (this includes a
line that solely consists of whitespaces). By default,
the command outputs warning messages and applies the
patch.
When gitlink:git-apply[1] is used for statistics and not applying a
patch, it defaults to `nowarn`.
You can use different `<option>` to control this
behavior:
--whitespace=<action>::
When applying a patch, detect a new or modified line that has
whitespace errors. What are considered whitespace errors is
controlled by `core.whitespace` configuration. By default,
trailing whitespaces (including lines that solely consist of
whitespaces) and a space character that is immediately followed
by a tab character inside the initial indent of the line are
considered whitespace errors.
+
By default, the command outputs warning messages but applies the patch.
When linkgit:git-apply[1] is used for statistics and not applying a
patch, it defaults to `nowarn`.
+
You can use different `<action>` to control this
behavior:
+
* `nowarn` turns off the trailing whitespace warning.
* `warn` outputs warnings for a few such errors, but applies the
patch (default).
patch as-is (default).
* `fix` outputs warnings for a few such errors, and applies the
patch after fixing them (`strip` is a synonym --- the tool
used to consider only trailing whitespaces as errors, and the
fix involved 'stripping' them, but modern gits do more).
* `error` outputs warnings for a few such errors, and refuses
to apply the patch.
* `error-all` is similar to `error` but shows all errors.
* `strip` outputs warnings for a few such errors, strips out the
trailing whitespaces and applies the patch.
--inaccurate-eof::
Under certain circumstances, some versions of diff do not correctly
@ -176,7 +183,7 @@ apply.whitespace::
Submodules
----------
If the patch contains any changes to submodules then gitlink:git-apply[1]
If the patch contains any changes to submodules then linkgit:git-apply[1]
treats these changes as follows.
If --index is specified (explicitly or implicitly), then the submodule
@ -199,4 +206,4 @@ Documentation by Junio C Hamano
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

2
Documentation/git-archimport.txt
View file

@ -117,4 +117,4 @@ Documentation by Junio C Hamano, Martin Langhoff and the git-list <git@vger.kern
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

2
Documentation/git-archive.txt
View file

@ -118,4 +118,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

42
Documentation/git-bisect.txt
View file

@ -16,8 +16,9 @@ The command takes various subcommands, and different options depending
on the subcommand:
git bisect start [<bad> [<good>...]] [--] [<paths>...]
git bisect bad <rev>
git bisect good <rev>
git bisect bad [<rev>]
git bisect good [<rev>...]
git bisect skip [<rev>...]
git bisect reset [<branch>]
git bisect visualize
git bisect replay <logfile>
@ -91,7 +92,16 @@ During the bisection process, you can say
$ git bisect visualize
------------
to see the currently remaining suspects in `gitk`.
to see the currently remaining suspects in `gitk`. `visualize` is a bit
too long to type and `view` is provided as a synonym.
If `DISPLAY` environment variable is not set, `git log` is used
instead. You can even give command line options such as `-p` and
`--stat`.
------------
$ git bisect view --stat
------------
Bisect log and bisect replay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -134,6 +144,20 @@ $ git reset --hard HEAD~3 # try 3 revs before what
Then compile and test the one you chose to try. After that, tell
bisect what the result was as usual.
Bisect skip
~~~~~~~~~~~~
Instead of choosing by yourself a nearby commit, you may just want git
to do it for you using:
------------
$ git bisect skip # Current version cannot be tested
------------
But computing the commit to test may be slower afterwards and git may
eventually not be able to tell the first bad among a bad and one or
more "skip"ped commits.
Cutting down bisection by giving more parameters to bisect start
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -167,14 +191,18 @@ $ git bisect run my_script
------------
Note that the "run" script (`my_script` in the above example) should
exit with code 0 in case the current source code is good and with a
code between 1 and 127 (included) in case the current source code is
bad.
exit with code 0 in case the current source code is good. Exit with a
code between 1 and 127 (inclusive), except 125, if the current
source code is bad.
Any other exit code will abort the automatic bisect process. (A
program that does "exit(-1)" leaves $? = 255, see exit(3) manual page,
the value is chopped with "& 0377".)
The special exit code 125 should be used when the current source code
cannot be tested. If the "run" script exits with this code, the current
revision will be skipped, see `git bisect skip` above.
You may often find that during bisect you want to have near-constant
tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
"revision that does not have this commit needs this patch applied to
@ -199,4 +227,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

8
Documentation/git-blame.txt
View file

@ -21,7 +21,7 @@ last modified the line. Optionally, start annotating from the given revision.
Also it can limit the range of lines annotated.
This report doesn't tell you anything about lines which have been deleted or
replaced; you need to use a tool such as gitlink:git-diff[1] or the "pickaxe"
replaced; you need to use a tool such as linkgit:git-diff[1] or the "pickaxe"
interface briefly mentioned in the following paragraph.
Apart from supporting file annotation, git also supports searching the
@ -41,7 +41,7 @@ OPTIONS
include::blame-options.txt[]
-c::
Use the same output mode as gitlink:git-annotate[1] (Default: off).
Use the same output mode as linkgit:git-annotate[1] (Default: off).
--score-debug::
Include debugging information related to the movement of
@ -184,7 +184,7 @@ commit commentary), a blame viewer won't ever care.
SEE ALSO
--------
gitlink:git-annotate[1]
linkgit:git-annotate[1]
AUTHOR
------
@ -192,4 +192,4 @@ Written by Junio C Hamano <junkio@cox.net>
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

50
Documentation/git-branch.txt
View file

@ -10,6 +10,7 @@ SYNOPSIS
[verse]
'git-branch' [--color | --no-color] [-r | -a]
[-v [--abbrev=<length> | --no-abbrev]]
[--contains <commit>]
'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git-branch' (-m | -M) [<oldbranch>] <newbranch>
'git-branch' (-d | -D) [-r] <branchname>...
@ -20,6 +21,9 @@ With no arguments given a list of existing branches
will be shown, the current branch will be highlighted with an asterisk.
Option `-r` causes the remote-tracking branches to be listed,
and option `-a` shows both.
With `--contains <commit>`, shows only the branches that
contains the named commit (in other words, the branches whose
tip commits are descendant of the named commit).
In its second form, a new branch named <branchname> will be created.
It will start out with a head equal to the one given as <start-point>.
@ -30,11 +34,11 @@ Note that this will create the new branch, but it will not switch the
working tree to it; use "git checkout <newbranch>" to switch to the
new branch.
When a local branch is started off a remote branch, git can setup the
branch so that gitlink:git-pull[1] will appropriately merge from that
remote branch. If this behavior is desired, it is possible to make it
the default using the global `branch.autosetupmerge` configuration
flag. Otherwise, it can be chosen per-branch using the `--track`
When a local branch is started off a remote branch, git sets up the
branch so that linkgit:git-pull[1] will appropriately merge from that
remote branch. If this behavior is not desired, it is possible to
disable it using the global `branch.autosetupmerge` configuration
flag. That setting can be overridden by using the `--track`
and `--no-track` options.
With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.
@ -45,17 +49,22 @@ to happen.
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
has a reflog then the reflog will also be deleted. Use -r together with -d
to delete remote-tracking branches.
has a reflog then the reflog will also be deleted.
Use -r together with -d to delete remote-tracking branches. Note, that it
only makes sense to delete remote-tracking branches if they no longer exist
in remote repository or if linkgit:git-fetch[1] was configured not to fetch
them again. See also 'prune' subcommand of linkgit:git-remote[1] for way to
clean up all obsolete remote-tracking branches.
OPTIONS
-------
-d::
Delete a branch. The branch must be fully merged.
Delete a branch. The branch must be fully merged in HEAD.
-D::
Delete a branch irrespective of its index status.
Delete a branch irrespective of its merged status.
-l::
Create the branch's reflog. This activates recording of
@ -85,7 +94,7 @@ OPTIONS
-a::
List both remote-tracking branches and local branches.
-v::
-v, --verbose::
Show sha1 and commit subject line for each head.
--abbrev=<length>::
@ -99,13 +108,14 @@ OPTIONS
Set up configuration so that git-pull will automatically
retrieve data from the remote branch. Use this if you always
pull from the same remote branch into the new branch, or if you
don't want to use "git pull <repository> <refspec>" explicitly. Set the
branch.autosetupmerge configuration variable to true if you
don't want to use "git pull <repository> <refspec>" explicitly.
This behavior is the default. Set the
branch.autosetupmerge configuration variable to false if you
want git-checkout and git-branch to always behave as if
'--track' were given.
'--no-track' were given.
--no-track::
When -b is given and a branch is created off a remote branch,
When a branch is created off a remote branch,
set up configuration so that git-pull will not retrieve data
from the remote branch, ignoring the branch.autosetupmerge
configuration variable.
@ -113,7 +123,7 @@ OPTIONS
<branchname>::
The name of the branch to create or delete.
The new branch name must pass all checks defined by
gitlink:git-check-ref-format[1]. Some of these checks
linkgit:git-check-ref-format[1]. Some of these checks
may restrict the characters allowed in a branch name.
<start-point>::
@ -153,9 +163,11 @@ $ git branch -d -r origin/todo origin/html origin/man <1>
$ git branch -D test <2>
------------
+
<1> Delete remote-tracking branches "todo", "html", "man"
<2> Delete "test" branch even if the "master" branch does not have all
commits from test branch.
<1> Delete remote-tracking branches "todo", "html", "man". Next 'fetch' or
'pull' will create them again unless you configure them not to. See
linkgit:git-fetch[1].
<2> Delete "test" branch even if the "master" branch (or whichever branch is
currently checked out) does not have all commits from test branch.
Notes
@ -176,4 +188,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

10
Documentation/git-bundle.txt
View file

@ -23,7 +23,7 @@ be directly connected so the interactive git protocols (git, ssh,
rsync, http) cannot be used. This command provides support for
git-fetch and git-pull to operate by packaging objects and references
in an archive at the originating machine, then importing those into
another repository using gitlink:git-fetch[1] and gitlink:git-pull[1]
another repository using linkgit:git-fetch[1] and linkgit:git-pull[1]
after moving the archive by some means (i.e., by sneakernet). As no
direct connection between repositories exists, the user must specify a
basis for the bundle that is held by the destination repository: the
@ -51,12 +51,12 @@ list-heads <file>::
printed out.
unbundle <file>::
Passes the objects in the bundle to gitlink:git-index-pack[1]
Passes the objects in the bundle to linkgit:git-index-pack[1]
for storage in the repository, then prints the names of all
defined references. If a reflist is given, only references
matching those in the given list are printed. This command is
really plumbing, intended to be called only by
gitlink:git-fetch[1].
linkgit:git-fetch[1].
[git-rev-list-args...]::
A list of arguments, acceptable to git-rev-parse and
@ -73,7 +73,7 @@ unbundle <file>::
available. This is principally of use to git-fetch, which
expects to receive only those references asked for and not
necessarily everything in the pack (in this case, git-bundle is
acting like gitlink:git-fetch-pack[1]).
acting like linkgit:git-fetch-pack[1]).
SPECIFYING REFERENCES
---------------------
@ -145,4 +145,4 @@ Written by Mark Levedahl <mdl123@verizon.net>
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

4
Documentation/git-cat-file.txt
View file

@ -21,7 +21,7 @@ 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].
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
-t::
Instead of the content, show the object type identified by
@ -70,4 +70,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

7
Documentation/git-check-attr.txt
View file

@ -23,6 +23,11 @@ OPTIONS
be treated as an attribute.
SEE ALSO
--------
linkgit:gitattributes[5].
Author
------
Written by Junio C Hamano <junkio@cox.net>
@ -33,4 +38,4 @@ Documentation by James Bowes.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

6
Documentation/git-check-ref-format.txt
View file

@ -35,7 +35,7 @@ imposes the following rules on how refs are named:
These rules makes it easy for shell script based tools to parse
refnames, pathname expansion by the shell when a refname is used
unquoted (by mistake), and also avoids ambiguities in certain
refname expressions (see gitlink:git-rev-parse[1]). Namely:
refname expressions (see linkgit:git-rev-parse[1]). Namely:
. double-dot `..` are often used as in `ref1..ref2`, and in some
context this notation means `{caret}ref1 ref2` (i.e. not in
@ -47,9 +47,9 @@ refname expressions (see gitlink:git-rev-parse[1]). Namely:
. colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
value and store it in dstref" in fetch and push operations.
It may also be used to select a specific object such as with
gitlink:git-cat-file[1] "git-cat-file blob v1.3.3:refs.c".
linkgit:git-cat-file[1] "git-cat-file blob v1.3.3:refs.c".
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -181,4 +181,4 @@ Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

11
Documentation/git-checkout.txt
View file

@ -44,7 +44,7 @@ OPTIONS
-b::
Create a new branch named <new_branch> and start it at
<branch>. The new branch name must pass all checks defined
by gitlink:git-check-ref-format[1]. Some of these checks
by linkgit:git-check-ref-format[1]. Some of these checks
may restrict the characters allowed in a branch name.
--track::
@ -52,10 +52,11 @@ OPTIONS
set up configuration so that git-pull will automatically
retrieve data from the remote branch. Use this if you always
pull from the same remote branch into the new branch, or if you
don't want to use "git pull <repository> <refspec>" explicitly. Set the
branch.autosetupmerge configuration variable to true if you
don't want to use "git pull <repository> <refspec>" explicitly.
This behavior is the default. Set the
branch.autosetupmerge configuration variable to false if you
want git-checkout and git-branch to always behave as if
'--track' were given.
'--no-track' were given.
--no-track::
When -b is given and a branch is created off a remote branch,
@ -216,4 +217,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -7,7 +7,7 @@ git-cherry-pick - Apply the change introduced by an existing commit
SYNOPSIS
--------
'git-cherry-pick' [--edit] [-n] [-x] <commit>
'git-cherry-pick' [--edit] [-n] [-m parent-number] [-x] <commit>
DESCRIPTION
-----------
@ -20,18 +20,19 @@ 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].
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
-e|--edit::
With this option, `git-cherry-pick` will let you edit the commit
message prior committing.
message prior to committing.
-x::
Cause the command to append which commit was
cherry-picked after the original commit message when
making a commit. Do not use this option if you are
cherry-picking from your private branch because the
information is useless to the recipient. If on the
When recording the commit, append to the original commit
message a note that indicates which commit this change
was cherry-picked from. Append the note only for cherry
picks without conflicts. Do not use this option if
you are cherry-picking from your private branch because
the information is useless to the recipient. If on the
other hand you are cherry-picking between two publicly
visible branches (e.g. backporting a fix to a
maintenance branch for an older release from a
@ -43,6 +44,13 @@ OPTIONS
described above, and `-r` was to disable it. Now the
default is not to do `-x` so this option is a no-op.
-m parent-number|--mainline parent-number::
Usually you cannot revert a merge because you do not know which
side of the merge should be considered the mainline. This
option specifies the parent number (starting from 1) of
the mainline and allows cherry-pick to replay the change
relative to the specified parent.
-n|--no-commit::
Usually the command automatically creates a commit with
a commit log message stating which commit was
@ -67,4 +75,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

2
Documentation/git-cherry.txt
View file

@ -66,4 +66,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

6
Documentation/git-citool.txt
View file

@ -14,10 +14,10 @@ DESCRIPTION
A Tcl/Tk based graphical interface to review modified files, stage
them into the index, enter a commit message and record the new
commit onto the current branch. This interface is an alternative
to the less interactive gitlink:git-commit[1] program.
to the less interactive linkgit:git-commit[1] program.
git-citool is actually a standard alias for 'git gui citool'.
See gitlink:git-gui[1] for more details.
See linkgit:git-gui[1] for more details.
Author
------
@ -29,4 +29,4 @@ Documentation by Shawn O. Pearce <spearce@spearce.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

4
Documentation/git-clean.txt
View file

@ -39,7 +39,7 @@ OPTIONS
-x::
Don't use the ignore rules. This allows removing all untracked
files, including build products. This can be used (possibly in
conjunction with gitlink:git-reset[1]) to create a pristine
conjunction with linkgit:git-reset[1]) to create a pristine
working directory to test a clean build.
-X::
@ -54,4 +54,4 @@ Written by Pavel Roskin <proski@gnu.org>
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

20
Documentation/git-clone.txt
View file

@ -12,7 +12,7 @@ SYNOPSIS
'git-clone' [--template=<template_directory>]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
[--depth <depth>] <repository> [<directory>]
[--depth <depth>] [--] <repository> [<directory>]
DESCRIPTION
-----------
@ -62,6 +62,15 @@ OPTIONS
.git/objects/info/alternates to share the objects
with the source repository. The resulting repository
starts out without any object of its own.
+
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand what it does. If you clone your
repository using this option, then delete branches in the
source repository and then run linkgit:git-gc[1] using the
'--prune' option in the source repository, it may remove
objects which are referenced by the cloned repository.
--reference <repository>::
If the reference repository is on the local machine
@ -111,11 +120,11 @@ OPTIONS
--depth <depth>::
Create a 'shallow' clone with a history truncated to the
specified number of revs. A shallow repository has
specified number of revisions. A shallow repository has a
number of limitations (you cannot clone or fetch from
it, nor push from nor into it), but is adequate if you
want to only look at near the tip of a large project
with a long history, and would want to send in a fixes
are only interested in the recent history of a large project
with a long history, and would want to send in fixes
as patches.
<repository>::
@ -130,6 +139,7 @@ OPTIONS
for "host.xz:foo/.git"). Cloning into an existing directory
is not allowed.
:git-clone: 1
include::urls.txt[]
Examples
@ -190,4 +200,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
This is usually not what an end user wants to run directly. See
gitlink:git-commit[1] instead.
linkgit: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
@ -90,7 +90,7 @@ include::i18n.txt[]
See Also
--------
gitlink:git-write-tree[1]
linkgit:git-write-tree[1]
Author
@ -103,4 +103,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

65
Documentation/git-commit.txt
View file

@ -10,8 +10,8 @@ SYNOPSIS
[verse]
'git-commit' [-a | --interactive] [-s] [-v] [-u]
[(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
[--no-verify] [-e] [--author <author>]
[--] [[-i | -o ]<file>...]
[--allow-empty] [--no-verify] [-e] [--author <author>]
[--cleanup=<mode>] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
@ -20,11 +20,11 @@ commit along with a log message describing the changes you have made.
The content to be added can be specified in several ways:
1. by using gitlink:git-add[1] to incrementally "add" changes to the
1. by using linkgit:git-add[1] to incrementally "add" changes to the
index before using the 'commit' command (Note: even modified
files must be "added");
2. by using gitlink:git-rm[1] to remove files from the working tree
2. by using linkgit:git-rm[1] to remove files from the working tree
and the index, again before using the 'commit' command;
3. by listing files as arguments to the 'commit' command, in which
@ -41,13 +41,13 @@ The content to be added can be specified in several ways:
by one which files should be part of the commit, before finalizing the
operation. Currently, this is done by invoking `git-add --interactive`.
The gitlink:git-status[1] command can be used to obtain a
The linkgit:git-status[1] command can be used to obtain a
summary of what is included by any of the above for the next
commit by giving the same set of parameters you would give to
this command.
If you make a commit and then found a mistake immediately after
that, you can recover from it with gitlink:git-reset[1].
that, you can recover from it with linkgit:git-reset[1].
OPTIONS
@ -86,9 +86,25 @@ OPTIONS
Add Signed-off-by line at the end of the commit message.
--no-verify::
This option bypasses the pre-commit hook.
This option bypasses the pre-commit and commit-msg hooks.
See also link:hooks.html[hooks].
--allow-empty::
Usually recording a commit that has the exact same tree as its
sole parent commit is a mistake, and the command prevents you
from making such a commit. This option bypasses the safety, and
is primarily for use by foreign scm interface scripts.
--cleanup=<mode>::
This option sets how the commit message is cleaned up.
The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
and 'default'. The 'default' mode will strip leading and
trailing empty lines and #commentary from the commit message
only if the message is to be edited. Otherwise only whitespace
removed. The 'verbatim' mode does not change message at all,
'whitespace' removes just leading/trailing whitespace lines
and 'strip' removes both whitespace and commentary.
-e|--edit::
The message taken from file with `-F`, command line with
`-m`, and from file with `-C` are usually used as the
@ -154,10 +170,13 @@ EXAMPLES
--------
When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
called the "index" with gitlink:git-add[1]. Removal
of a file is staged with gitlink:git-rm[1]. After building the
state to be committed incrementally with these commands, `git
commit` (without any pathname parameter) is used to record what
called the "index" with linkgit:git-add[1]. A file can be
reverted back, only in the index but not in the working tree,
to that of the last commit with `git-reset HEAD -- <file>`,
which effectively reverts `git-add` and prevents the changes to
this file from participating in the next commit. After building
the state to be committed incrementally with these commands,
`git commit` (without any pathname parameter) is used to record what
has been staged so far. This is the most basic form of the
command. An example:
@ -210,13 +229,13 @@ $ git commit
this second commit would record the changes to `hello.c` and
`hello.h` as expected.
After a merge (initiated by either gitlink:git-merge[1] or
gitlink:git-pull[1]) stops because of conflicts, cleanly merged
After a merge (initiated by either linkgit:git-merge[1] or
linkgit:git-pull[1]) stops because of conflicts, cleanly merged
paths are already staged to be committed for you, and paths that
conflicted are left in unmerged state. You would have to first
check which paths are conflicting with gitlink:git-status[1]
check which paths are conflicting with linkgit:git-status[1]
and after fixing them manually in your working tree, you would
stage the result as usual with gitlink:git-add[1]:
stage the result as usual with linkgit:git-add[1]:
------------
$ git status | grep unmerged
@ -261,18 +280,18 @@ order).
HOOKS
-----
This command can run `commit-msg`, `pre-commit`, and
`post-commit` hooks. See link:hooks.html[hooks] for more
This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
and `post-commit` hooks. See link:hooks.html[hooks] for more
information.
SEE ALSO
--------
gitlink:git-add[1],
gitlink:git-rm[1],
gitlink:git-mv[1],
gitlink:git-merge[1],
gitlink:git-commit-tree[1]
linkgit:git-add[1],
linkgit:git-rm[1],
linkgit:git-mv[1],
linkgit:git-merge[1],
linkgit:git-commit-tree[1]
Author
------
@ -282,4 +301,4 @@ Junio C Hamano <junkio@cox.net>
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

30
Documentation/git-config.txt
View file

@ -20,6 +20,8 @@ SYNOPSIS
'git-config' [<file-option>] --rename-section old_name new_name
'git-config' [<file-option>] --remove-section name
'git-config' [<file-option>] [-z|--null] -l | --list
'git-config' [<file-option>] --get-color name [default]
'git-config' [<file-option>] --get-colorbool name [stdout-is-tty]
DESCRIPTION
-----------
@ -128,12 +130,27 @@ See also <<FILES>>.
-z, --null::
For all options that output values and/or keys, always
end values with with the null character (instead of a
end values with the null character (instead of a
newline). Use newline instead as a delimiter between
key and value. This allows for secure parsing of the
output without getting confused e.g. by values that
contain line breaks.
--get-colorbool name [stdout-is-tty]::
Find the color setting for `name` (e.g. `color.diff`) and output
"true" or "false". `stdout-is-tty` should be either "true" or
"false", and is taken into account when configuration says
"auto". If `stdout-is-tty` is missing, then checks the standard
output of the command itself, and exits with status 0 if color
is to be used, or exits with status 1 otherwise.
--get-color name default::
Find the color configured for `name` (e.g. `color.diff.new`) and
output it as the ANSI color escape sequence to the standard
output. The optional `default` parameter is used instead, if
there is no color configured for `name`.
[[FILES]]
FILES
@ -292,6 +309,15 @@ To add a new proxy, without altering any of the existing ones, use
% git config core.gitproxy '"proxy-command" for example.com'
------------
An example to use customized color from the configuration in your
script:
------------
#!/bin/sh
WS=$(git config --get-color color.diff.whitespace "blue reverse")
RESET=$(git config --get-color "" "reset")
echo "${WS}your whitespace color or blue reverse${RESET}"
------------
include::config.txt[]
@ -306,4 +332,4 @@ Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.ker
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -34,4 +34,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

26
Documentation/git-cvsexportcommit.txt
View file

@ -8,7 +8,7 @@ git-cvsexportcommit - Export a single commit to a CVS checkout
SYNOPSIS
--------
'git-cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
'git-cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
DESCRIPTION
@ -16,8 +16,9 @@ DESCRIPTION
Exports a commit from GIT to a CVS checkout, making it easier
to merge patches from a git repository into a CVS repository.
Execute it from the root of the CVS working copy. GIT_DIR must be defined.
See examples below.
Specify the name of a CVS checkout using the -w switch or execute it
from the root of the CVS working copy. In the latter case GIT_DIR must
be defined. See examples below.
It does its best to do the safe thing, it will check that the files are
unchanged and up to date in the CVS checkout, and it will not autocommit
@ -61,6 +62,11 @@ OPTIONS
-u::
Update affected files from CVS repository before attempting export.
-w::
Specify the location of the CVS checkout to use for the export. This
option does not require GIT_DIR to be set before execution if the
current directory is within a git repository.
-v::
Verbose.
@ -73,7 +79,13 @@ Merge one patch into CVS::
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
$ git-cvsexportcommit -v <commit-sha1>
$ cvs commit -F .mgs <files>
$ cvs commit -F .msg <files>
------------
Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::
+
------------
$ git-cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
------------
Merge pending patches into CVS automatically -- only if you really know what you are doing::
@ -86,12 +98,12 @@ $ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit
Author
------
Written by Martin Langhoff <martin@catalyst.net.nz>
Written by Martin Langhoff <martin@catalyst.net.nz> and others.
Documentation
--------------
Documentation by Martin Langhoff <martin@catalyst.net.nz>
Documentation by Martin Langhoff <martin@catalyst.net.nz> and others.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

8
Documentation/git-cvsimport.txt
View file

@ -107,8 +107,8 @@ If you need to pass multiple options, separate them with a comma.
-M <regex>::
Attempt to detect merges based on the commit message with a custom
regex. It can be used with '-m' to also see the default regexes.
You must escape forward slashes.
regex. It can be used with '-m' to enable the default regexes
as well. You must escape forward slashes.
-S <regex>::
Skip paths matching the regex.
@ -142,7 +142,7 @@ file each time git-cvsimport is run.
+
It is not recommended to use this feature if you intend to
export changes back to CVS again later with
gitlink:git-cvsexportcommit[1].
linkgit:git-cvsexportcommit[1].
-h::
Print a short usage message and exit.
@ -166,4 +166,4 @@ Documentation by Matthias Urlichs <smurf@smurf.noris.de>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

10
Documentation/git-cvsserver.txt
View file

@ -28,7 +28,7 @@ OPTIONS
-------
All these options obviously only make sense if enforced by the server side.
They have been implemented to resemble the gitlink:git-daemon[1] options as
They have been implemented to resemble the linkgit:git-daemon[1] options as
closely as possible.
--base-path <path>::
@ -183,7 +183,7 @@ access method and requested operation.
That means that even if you offer only read access (e.g. by using
the pserver method), git-cvsserver should have write access to
the database to work reliably (otherwise you need to make sure
that the database if up-to-date all the time git-cvsserver is run).
that the database is up-to-date any time git-cvsserver is executed).
By default it uses SQLite databases in the git directory, named
`gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates
@ -204,7 +204,7 @@ about `DBI->connect()`.
gitcvs.dbname::
Database name. The exact meaning depends on the
used database driver, for SQLite this is a filename.
selected database driver, for SQLite this is a filename.
Supports variable substitution (see below). May
not contain semicolons (`;`).
Default: '%Ggitcvs.%m.sqlite'
@ -215,7 +215,7 @@ gitcvs.dbdriver::
with 'DBD::SQLite', reported to work with
'DBD::Pg', and reported *not* to work with 'DBD::mysql'.
Please regard this as an experimental feature. May not
contain double colons (`:`).
contain colons (`:`).
Default: 'SQLite'
gitcvs.dbuser::
@ -319,4 +319,4 @@ Documentation by Martyn Smith <martyn@catalyst.net.nz>, Martin Langhoff <martin@
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

8
Documentation/git-daemon.txt
View file

@ -31,8 +31,8 @@ pass some directory paths as 'git-daemon' arguments, you can further restrict
the offers to a whitelist comprising of those.
By default, only `upload-pack` service is enabled, which serves
`git-fetch-pack` and `git-peek-remote` clients that are invoked
from `git-fetch`, `git-ls-remote`, and `git-clone`.
`git-fetch-pack` and `git-ls-remote` clients, which are invoked
from `git-fetch`, `git-pull`, and `git-clone`.
This is ideally suited for read-only updates, i.e., pulling from
git repositories.
@ -166,7 +166,7 @@ the per-repository configuration file can be used to enable or
disable them.
upload-pack::
This serves `git-fetch-pack` and `git-peek-remote`
This serves `git-fetch-pack` and `git-ls-remote`
clients. It is enabled by default, but a repository can
disable it by setting `daemon.uploadpack` configuration
item to `false`.
@ -272,4 +272,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

6
Documentation/git-describe.txt
View file

@ -51,6 +51,10 @@ OPTIONS
being employed to standard error. The tag name will still
be printed to standard out.
--match <pattern>::
Only consider tags matching the given pattern (can be used to avoid
leaking private tags made from the repository).
EXAMPLES
--------
@ -123,4 +127,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

2
Documentation/git-diff-files.txt
View file

@ -57,4 +57,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -129,4 +129,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -165,4 +165,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

12
Documentation/git-diff.txt
View file

@ -21,7 +21,7 @@ tree and the index file, or the index file and the working tree.
the index (staging area for the next commit). In other
words, the differences are what you _could_ tell git to
further add to the index but you still haven't. You can
stage these changes by using gitlink:git-add[1].
stage these changes by using linkgit:git-add[1].
+
If exactly two paths are given, and at least one is untracked,
compare the two files / directories. This behavior can be
@ -67,14 +67,15 @@ for the last two forms that use ".." notations, 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].
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
However, "diff" is about comparing two _endpoints_, not ranges,
and the range notations ("<commit>..<commit>" and
"<commit>\...<commit>") do not mean a range as defined in the
"SPECIFYING RANGES" section in gitlink:git-rev-parse[1].
"SPECIFYING RANGES" section in linkgit:git-rev-parse[1].
OPTIONS
-------
:git-diff: 1
include::diff-options.txt[]
<path>...::
@ -82,6 +83,9 @@ include::diff-options.txt[]
the diff to the named paths (you can give directory
names and get diff for all files under them).
Output format
-------------
include::diff-format.txt[]
EXAMPLES
--------
@ -164,4 +168,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

83
Documentation/git-fast-export.txt Normal file
View file

@ -0,0 +1,83 @@
git-fast-export(1)
==================
NAME
----
git-fast-export - Git data exporter
SYNOPSIS
--------
'git-fast-export [options]' | 'git-fast-import'
DESCRIPTION
-----------
This program dumps the given revisions in a form suitable to be piped
into linkgit:git-fast-import[1].
You can use it as a human readable bundle replacement (see
linkgit:git-bundle[1]), or as a kind of an interactive
linkgit:git-filter-branch[1].
OPTIONS
-------
--progress=<n>::
Insert 'progress' statements every <n> objects, to be shown by
linkgit:git-fast-import[1] during import.
--signed-tags=(verbatim|warn|strip|abort)::
Specify how to handle signed tags. Since any transformation
after the export can change the tag names (which can also happen
when excluding revisions) the signatures will not match.
+
When asking to 'abort' (which is the default), this program will die
when encountering a signed tag. With 'strip', the tags will be made
unsigned, with 'verbatim', they will be silently exported
and with 'warn', they will be exported, but you will see a warning.
EXAMPLES
--------
-------------------------------------------------------------------
$ git fast-export --all | (cd /empty/repository && git fast-import)
-------------------------------------------------------------------
This will export the whole repository and import it into the existing
empty repository. Except for reencoding commits that are not in
UTF-8, it would be a one-to-one mirror.
-----------------------------------------------------
$ git fast-export master~5..master |
sed "s|refs/heads/master|refs/heads/other|" |
git fast-import
-----------------------------------------------------
This makes a new branch called 'other' from 'master~5..master'
(i.e. if 'master' has linear history, it will take the last 5 commits).
Note that this assumes that none of the blobs and commit messages
referenced by that revision range contains the string
'refs/heads/master'.
Limitations
-----------
Since linkgit:git-fast-import[1] cannot tag trees, you will not be
able to export the linux-2.6.git repository completely, as it contains
a tag referencing a tree instead of a commit.
Author
------
Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
Documentation
--------------
Documentation by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
GIT
---
Part of the linkgit:git[7] suite

105
Documentation/git-fast-import.txt
View file

@ -24,7 +24,7 @@ updated branch and tag refs, fully updating the current repository
with the newly imported data.
The fast-import backend itself can import into an empty repository (one that
has already been initialized by gitlink:git-init[1]) or incrementally
has already been initialized by linkgit:git-init[1]) or incrementally
update an existing populated repository. Whether or not incremental
imports are supported from a particular foreign source depends on
the frontend program in use.
@ -82,7 +82,7 @@ OPTIONS
This information may be useful after importing projects
whose total object set exceeds the 4 GiB packfile limit,
as these commits can be used as edge points during calls
to gitlink:git-pack-objects[1].
to linkgit:git-pack-objects[1].
--quiet::
Disable all non-fatal output, making fast-import silent when it
@ -220,7 +220,7 @@ variation in formatting will cause fast-import to reject the value.
+
An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git
parser is accurate, but a little on the lenient side. It is the
same parser used by gitlink:git-am[1] when applying patches
same parser used by linkgit:git-am[1] when applying patches
received from email.
+
Some malformed strings may be accepted as valid dates. In some of
@ -256,7 +256,7 @@ timezone.
This particular format is supplied as its short to implement and
may be useful to a process that wants to create a new commit
right now, without needing to use a working directory or
gitlink:git-update-index[1].
linkgit:git-update-index[1].
+
If separate `author` and `committer` commands are used in a `commit`
the timestamps may not match, as the system clock will be polled
@ -411,7 +411,7 @@ Marks must be declared (via `mark`) before they can be used.
* A complete 40 byte or abbreviated commit SHA-1 in hex.
* Any valid Git SHA-1 expression that resolves to a commit. See
``SPECIFYING REVISIONS'' in gitlink:git-rev-parse[1] for details.
``SPECIFYING REVISIONS'' in linkgit:git-rev-parse[1] for details.
The special case of restarting an incremental import from the
current branch value should be written as:
@ -649,7 +649,7 @@ recommended, as the frontend does not (easily) have access to the
complete set of bytes which normally goes into such a signature.
If signing is required, create lightweight tags from within fast-import with
`reset`, then create the annotated versions of those tags offline
with the standard gitlink:git-tag[1] process.
with the standard linkgit:git-tag[1] process.
`reset`
~~~~~~~
@ -805,6 +805,93 @@ Placing a `progress` command immediately after a `checkpoint` will
inform the reader when the `checkpoint` has been completed and it
can safely access the refs that fast-import updated.
Crash Reports
-------------
If fast-import is supplied invalid input it will terminate with a
non-zero exit status and create a crash report in the top level of
the Git repository it was importing into. Crash reports contain
a snapshot of the internal fast-import state as well as the most
recent commands that lead up to the crash.
All recent commands (including stream comments, file changes and
progress commands) are shown in the command history within the crash
report, but raw file data and commit messages are excluded from the
crash report. This exclusion saves space within the report file
and reduces the amount of buffering that fast-import must perform
during execution.
After writing a crash report fast-import will close the current
packfile and export the marks table. This allows the frontend
developer to inspect the repository state and resume the import from
the point where it crashed. The modified branches and tags are not
updated during a crash, as the import did not complete successfully.
Branch and tag information can be found in the crash report and
must be applied manually if the update is needed.
An example crash:
====
$ cat >in <<END_OF_INPUT
# my very first test commit
commit refs/heads/master
committer Shawn O. Pearce <spearce> 19283 -0400
# who is that guy anyway?
data <<EOF
this is my commit
EOF
M 644 inline .gitignore
data <<EOF
.gitignore
EOF
M 777 inline bob
END_OF_INPUT
$ git-fast-import <in
fatal: Corrupt mode: M 777 inline bob
fast-import: dumping crash report to .git/fast_import_crash_8434
$ cat .git/fast_import_crash_8434
fast-import crash report:
fast-import process: 8434
parent process : 1391
at Sat Sep 1 00:58:12 2007
fatal: Corrupt mode: M 777 inline bob
Most Recent Commands Before Crash
---------------------------------
# my very first test commit
commit refs/heads/master
committer Shawn O. Pearce <spearce> 19283 -0400
# who is that guy anyway?
data <<EOF
M 644 inline .gitignore
data <<EOF
* M 777 inline bob
Active Branch LRU
-----------------
active_branches = 1 cur, 5 max
pos clock name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 0 refs/heads/master
Inactive Branches
-----------------
refs/heads/master:
status : active loaded dirty
tip commit : 0000000000000000000000000000000000000000
old tree : 0000000000000000000000000000000000000000
cur tree : 0000000000000000000000000000000000000000
commit clock: 0
last pack :
-------------------
END OF CRASH REPORT
====
Tips and Tricks
---------------
The following tips and tricks have been collected from various
@ -863,7 +950,7 @@ is not `refs/heads/TAG_FIXUP`).
When committing fixups, consider using `merge` to connect the
commit(s) which are supplying file revisions to the fixup branch.
Doing so will allow tools such as gitlink:git-blame[1] to track
Doing so will allow tools such as linkgit:git-blame[1] to track
through the real commit history and properly annotate the source
files.
@ -892,7 +979,7 @@ Repacking Historical Data
~~~~~~~~~~~~~~~~~~~~~~~~~
If you are repacking very old imported data (e.g. older than the
last year), consider expending some extra CPU time and supplying
\--window=50 (or higher) when you run gitlink:git-repack[1].
\--window=50 (or higher) when you run linkgit:git-repack[1].
This will take longer, but will also produce a smaller packfile.
You only need to expend the effort once, and everyone using your
project will benefit from the smaller repository.
@ -1027,4 +1114,4 @@ Documentation by Shawn O. Pearce <spearce@spearce.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -12,7 +12,7 @@ SYNOPSIS
DESCRIPTION
-----------
Usually you would want to use gitlink:git-fetch[1] which is a
Usually you would want to use linkgit:git-fetch[1] which is a
higher level wrapper of this command instead.
Invokes 'git-upload-pack' on a potentially remote repository,
@ -93,4 +93,4 @@ Documentation by Junio C Hamano.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

4
Documentation/git-fetch.txt
View file

@ -39,7 +39,7 @@ include::urls-remotes.txt[]
SEE ALSO
--------
gitlink:git-pull[1]
linkgit:git-pull[1]
Author
@ -53,4 +53,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

20
Documentation/git-filter-branch.txt
View file

@ -72,7 +72,7 @@ OPTIONS
This is the filter for modifying the environment in which
the commit will be performed. Specifically, you might want
to rewrite the author/committer name/email/time environment
variables (see gitlink:git-commit[1] for details). Do not forget
variables (see linkgit:git-commit[1] for details). Do not forget
to re-export the variables.
--tree-filter <command>::
@ -86,13 +86,13 @@ OPTIONS
--index-filter <command>::
This is the filter for rewriting the index. It is similar to the
tree filter but does not check out the tree, which makes it much
faster. For hairy cases, see gitlink:git-update-index[1].
faster. For hairy cases, see linkgit:git-update-index[1].
--parent-filter <command>::
This is the filter for rewriting the commit's parent list.
It will receive the parent string on stdin and shall output
the new parent string on stdout. The parent string is in
a format accepted by gitlink:git-commit-tree[1]: empty for
a format accepted by linkgit:git-commit-tree[1]: empty for
the initial commit, "-p parent" for a normal commit and
"-p parent1 -p parent2 -p parent3 ..." for a merge commit.
@ -105,7 +105,7 @@ OPTIONS
--commit-filter <command>::
This is the filter for performing the commit.
If this filter is specified, it will be called instead of the
gitlink:git-commit-tree[1] command, with arguments of the form
linkgit:git-commit-tree[1] command, with arguments of the form
"<TREE_ID> [-p <PARENT_COMMIT_ID>]..." and the log message on
stdin. The commit id is expected on stdout.
+
@ -116,7 +116,7 @@ have all of them as parents.
You can use the 'map' convenience function in this filter, and other
convenience functions, too. For example, calling 'skip_commit "$@"'
will leave out the current commit (but not its changes! If you want
that, use gitlink:git-rebase[1] instead).
that, use linkgit:git-rebase[1] instead).
--tag-name-filter <command>::
This is the filter for rewriting tag names. When passed,
@ -152,14 +152,14 @@ definition impossible to preserve signatures at any rate.)
does this in the '.git-rewrite/' directory but you can override
that choice by this parameter.
-f\|--force::
-f|--force::
`git filter-branch` refuses to start with an existing temporary
directory or when there are already refs starting with
'refs/original/', unless forced.
<rev-list-options>::
When options are given after the new branch name, they will
be passed to gitlink:git-rev-list[1]. Only commits in the resulting
be passed to linkgit:git-rev-list[1]. Only commits in the resulting
output will be filtered, although the filtered commits can still
reference parents which are outside of that set.
@ -219,7 +219,7 @@ git filter-branch --commit-filter '
fi' HEAD
------------------------------------------------------------------------------
The function 'skip_commits' is defined as follows:
The function 'skip_commit' is defined as follows:
--------------------------
skip_commit()
@ -249,7 +249,7 @@ will print.
*NOTE* the changes introduced by the commits, and which are not reverted
by subsequent commits, will still be in the rewritten branch. If you want
to throw out _changes_ together with the commits, you should use the
interactive mode of gitlink:git-rebase[1].
interactive mode of linkgit:git-rebase[1].
Consider this history:
@ -295,4 +295,4 @@ Documentation by Petr Baudis and the git list.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

4
Documentation/git-fmt-merge-msg.txt
View file

@ -46,7 +46,7 @@ merge.summary::
SEE ALSO
--------
gitlink:git-merge[1]
linkgit:git-merge[1]
Author
@ -59,4 +59,4 @@ Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.o
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

24
Documentation/git-format-patch.txt
View file

@ -9,9 +9,10 @@ git-format-patch - Prepare patches for e-mail submission
SYNOPSIS
--------
[verse]
'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--thread]
'git-format-patch' [-k] [-o <dir> | --stdout] [--thread]
[--attach[=<boundary>] | --inline[=<boundary>]]
[-s | --signoff] [<common diff options>]
[-n | --numbered | -N | --no-numbered]
[--start-number <n>] [--numbered-files]
[--in-reply-to=Message-Id] [--suffix=.<sfx>]
[--ignore-if-in-upstream]
@ -24,7 +25,7 @@ DESCRIPTION
Prepare each commit with its patch in
one file per commit, formatted to resemble UNIX mailbox format.
The output of this command is convenient for e-mail submission or
for use with gitlink:git-am[1].
for use with linkgit:git-am[1].
There are two ways to specify which commits to operate on.
@ -33,7 +34,7 @@ There are two ways to specify which commits to operate on.
that leads to the <since> to be output.
2. Generic <revision range> expression (see "SPECIFYING
REVISIONS" section in gitlink:git-rev-parse[1]) means the
REVISIONS" section in linkgit:git-rev-parse[1]) means the
commits in the specified range.
A single commit, when interpreted as a <revision range>
@ -65,6 +66,7 @@ reference.
OPTIONS
-------
:git-format-patch: 1
include::diff-options.txt[]
-<n>::
@ -77,6 +79,9 @@ include::diff-options.txt[]
-n|--numbered::
Name output in '[PATCH n/m]' format.
-N|--no-numbered::
Name output in '[PATCH]' format.
--start-number <n>::
Start numbering the patches at <n> instead of 1.
@ -142,15 +147,16 @@ not add any suffix.
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each
message in the repository configuration. You can also specify
new defaults for the subject prefix and file suffix.
You can specify extra mail header lines to be added to each message
in the repository configuration, new defaults for the subject prefix
and file suffix, and number patches when outputting more than one.
------------
[format]
headers = "Organization: git-foo\n"
subjectprefix = CHANGE
suffix = .txt
numbered = auto
------------
@ -168,7 +174,7 @@ git-format-patch origin::
is created in the current directory.
git-format-patch \--root origin::
Extract all commits which that leads to 'origin' since the
Extract all commits that lead to 'origin' since the
inception of the project.
git-format-patch -M -B origin::
@ -186,7 +192,7 @@ git-format-patch -3::
See Also
--------
gitlink:git-am[1], gitlink:git-send-email[1]
linkgit:git-am[1], linkgit:git-send-email[1]
Author
@ -199,4 +205,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

2
Documentation/git-fsck-objects.txt
View file

@ -13,5 +13,5 @@ SYNOPSIS
DESCRIPTION
-----------
This is a synonym for gitlink:git-fsck[1]. Please refer to the
This is a synonym for linkgit:git-fsck[1]. Please refer to the
documentation of that command.

2
Documentation/git-fsck.txt
View file

@ -150,4 +150,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

52
Documentation/git-gc.txt
View file

@ -15,11 +15,12 @@ DESCRIPTION
Runs a number of housekeeping tasks within the current repository,
such as compressing file revisions (to reduce disk space and increase
performance) and removing unreachable objects which may have been
created from prior invocations of gitlink:git-add[1].
created from prior invocations of linkgit:git-add[1].
Users are encouraged to run this task on a regular basis within
each repository to maintain good disk space utilization and good
operating performance.
operating performance. Some git commands may automatically run
`git-gc`; see the `--auto` flag below for details.
OPTIONS
-------
@ -44,18 +45,23 @@ OPTIONS
few hundred changesets or so.
--auto::
With this option, `git gc` checks if there are too many
loose objects in the repository and runs
gitlink:git-repack[1] with `-d -l` option to pack them.
The threshold for loose objects is set with `gc.auto` configuration
variable, and can be disabled by setting it to 0. Some
Porcelain commands use this after they perform operation
that could create many loose objects automatically.
Additionally, when there are too many packs are present,
they are consolidated into one larger pack by running
the `git-repack` command with `-A` option. The
threshold for number of packs is set with
`gc.autopacklimit` configuration variable.
With this option, `git gc` checks whether any housekeeping is
required; if not, it exits without performing any work.
Some git commands run `git gc --auto` after performing
operations that could create many loose objects.
+
Housekeeping is required if there are too many loose objects or
too many packs in the repository. If the number of loose objects
exceeds the value of the `gc.auto` configuration variable, then
all loose objects are combined into a single pack using
`git-repack -d -l`. Setting the value of `gc.auto` to 0
disables automatic packing of loose objects.
+
If the number of packs exceeds the value of `gc.autopacklimit`,
then existing packs (except those marked with a `.keep` file)
are consolidated into a single pack by using the `-A` option of
`git-repack`. Setting `gc.autopacklimit` to 0 disables
automatic consolidation of packs.
Configuration
-------------
@ -84,23 +90,23 @@ how long records of conflicted merge you have not resolved are
kept. This defaults to 15 days.
The optional configuration variable 'gc.packrefs' determines if
`git gc` runs `git-pack-refs`. Without the configuration, `git-pack-refs`
is not run in bare repositories by default, to allow older dumb-transport
clients fetch from the repository, but this will change in the future.
`git gc` runs `git-pack-refs`. This can be set to "nobare" to enable
it within all non-bare repos or it can be set to a boolean value.
This defaults to true.
The optional configuration variable 'gc.aggressiveWindow' controls how
much time is spent optimizing the delta compression of the objects in
the repository when the --aggressive option is specified. The larger
the value, the more time is spent optimizing the delta compression. See
the documentation for the --window' option in gitlink:git-repack[1] for
the documentation for the --window' option in linkgit:git-repack[1] for
more details. This defaults to 10.
See Also
--------
gitlink:git-prune[1]
gitlink:git-reflog[1]
gitlink:git-repack[1]
gitlink:git-rerere[1]
linkgit:git-prune[1]
linkgit:git-reflog[1]
linkgit:git-repack[1]
linkgit:git-rerere[1]
Author
------
@ -108,4 +114,4 @@ Written by Shawn O. Pearce <spearce@spearce.org>
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

8
Documentation/git-get-tar-commit-id.txt
View file

@ -3,7 +3,7 @@ git-get-tar-commit-id(1)
NAME
----
git-get-tar-commit-id - Extract commit ID from an archive created using git-tar-tree
git-get-tar-commit-id - Extract commit ID from an archive created using git-archive
SYNOPSIS
@ -14,12 +14,12 @@ SYNOPSIS
DESCRIPTION
-----------
Acts as a filter, extracting the commit ID stored in archives created by
git-tar-tree. It reads only the first 1024 bytes of input, thus its
linkgit:git-archive[1]. It reads only the first 1024 bytes of input, thus its
runtime is not influenced by the size of <tarfile> very much.
If no commit ID is found, git-get-tar-commit-id quietly exists with a
return code of 1. This can happen if <tarfile> had not been created
using git-tar-tree or if the first parameter of git-tar-tree had been
using git-archive or if the first parameter of git-archive had been
a tree ID instead of a commit ID or tag.
@ -33,4 +33,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

6
Documentation/git-grep.txt
View file

@ -75,9 +75,11 @@ OPTIONS
-n::
Prefix the line number to matching lines.
-l | --files-with-matches | -L | --files-without-match::
-l | --files-with-matches | --name-only | -L | --files-without-match::
Instead of showing every matched line, show only the
names of files that contain (or do not contain) matches.
For better compatability with git-diff, --name-only is a
synonym for --files-with-matches.
-c | --count::
Instead of showing every matched line, show the number of
@ -143,4 +145,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

4
Documentation/git-gui.txt
View file

@ -16,7 +16,7 @@ on allowing users to make changes to their repository by making
new commits, amending existing ones, creating branches, performing
local merges, and fetching/pushing to remote repositories.
Unlike gitlink:gitk[1], git-gui focuses on commit generation
Unlike linkgit:gitk[1], git-gui focuses on commit generation
and single file annotation, and does not show project history.
It does however supply menu actions to start a gitk session from
within git-gui.
@ -112,4 +112,4 @@ Documentation by Shawn O. Pearce <spearce@spearce.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -42,4 +42,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

95
Documentation/git-help.txt Normal file
View file

@ -0,0 +1,95 @@
git-help(1)
===========
NAME
----
git-help - display help information about git
SYNOPSIS
--------
'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
DESCRIPTION
-----------
With no options and no COMMAND given, the synopsis of the 'git'
command and a list of the most commonly used git commands are printed
on the standard output.
If the option '--all' or '-a' is given, then all available commands are
printed on the standard output.
If a git command is named, a manual page for that command is brought
up. The 'man' program is used by default for this purpose, but this
can be overridden by other options or configuration variables.
Note that 'git --help ...' is identical as 'git help ...' because the
former is internally converted into the latter.
OPTIONS
-------
-a|--all::
Prints all the available commands on the standard output. This
option supersedes any other option.
-i|--info::
Use the 'info' program to display the manual page, instead of
the 'man' program that is used by default.
-m|--man::
Use the 'man' program to display the manual page. This may be
used to override a value set in the 'help.format'
configuration variable.
-w|--web::
Use a web browser to display the HTML manual page, instead of
the 'man' program that is used by default.
+
The web browser can be specified using the configuration variable
'help.browser', or 'web.browser' if the former is not set. If none of
these config variables is set, the 'git-web--browse' helper script
(called by 'git-help') will pick a suitable default. See
linkgit:git-web--browse[1] for more information about this.
CONFIGURATION VARIABLES
-----------------------
If no command line option is passed, the 'help.format' configuration
variable will be checked. The following values are supported for this
variable; they make 'git-help' behave as their corresponding command
line option:
* "man" corresponds to '-m|--man',
* "info" corresponds to '-i|--info',
* "web" or "html" correspond to '-w|--web',
The 'help.browser', 'web.browser' and 'browser.<tool>.path' will also
be checked if the 'web' format is chosen (either by command line
option or configuration variable). See '-w|--web' in the OPTIONS
section above and linkgit:git-web--browse[1].
Note that these configuration variables should probably be set using
the '--global' flag, for example like this:
------------------------------------------------
$ git config --global help.format web
$ git config --global web.browser firefox
------------------------------------------------
as they are probably more user specific than repository specific.
See linkgit:git-config[1] for more information about this.
Author
------
Written by Junio C Hamano <gitster@pobox.com> and the git-list
<git@vger.kernel.org>.
Documentation
-------------
Initial documentation was part of the linkgit:git[7] man page.
Christian Couder <chriscool@tuxfamily.org> extracted and rewrote it a
little. Maintenance is done by the git-list <git@vger.kernel.org>.
GIT
---
Part of the linkgit:git[7] suite

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

@ -53,4 +53,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -8,13 +8,16 @@ git-http-push - Push objects over HTTP/DAV to another repository
SYNOPSIS
--------
'git-http-push' [--all] [--force] [--verbose] <url> <ref> [<ref>...]
'git-http-push' [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>...]
DESCRIPTION
-----------
Sends missing objects to remote repository, and updates the
remote branch.
*NOTE*: This command is temporarily disabled if your cURL
library is older than 7.16, as the combination has been reported
not to work and sometimes corrupts repository.
OPTIONS
-------
@ -30,6 +33,9 @@ OPTIONS
the remote repository can lose commits; use it with
care.
--dry-run::
Do everything except actually send the updates.
--verbose::
Report the list of objects being walked locally and the
list of objects successfully sent to the remote repository.
@ -95,4 +101,4 @@ Documentation by Nick Hengeveld
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -59,4 +59,4 @@ Documentation by Mike McCormack
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -43,10 +43,10 @@ OPTIONS
a default name determined from the pack content. If
<pack-file> is not specified consider using --keep to
prevent a race condition between this process and
gitlink::git-repack[1].
linkgit:git-repack[1].
--fix-thin::
It is possible for gitlink:git-pack-objects[1] to build
It is possible for linkgit:git-pack-objects[1] to build
"thin" pack, which records objects in deltified form based on
objects not included in the pack to reduce network traffic.
Those objects are expected to be present on the receiving end
@ -59,7 +59,7 @@ OPTIONS
Before moving the index into its final destination
create an empty .keep file for the associated pack file.
This option is usually necessary with --stdin to prevent a
simultaneous gitlink:git-repack[1] process from deleting
simultaneous linkgit:git-repack[1] process from deleting
the newly constructed pack and index before refs can be
updated to use objects contained in the pack.
@ -83,7 +83,7 @@ Once the index has been created, the list of object names is sorted
and the SHA1 hash of that list is printed to stdout. If --stdin was
also used then this is prefixed by either "pack\t", or "keep\t" if a
new .keep file was successfully created. This is useful to remove a
.keep file used as a lock to prevent the race with gitlink:git-repack[1]
.keep file used as a lock to prevent the race with linkgit:git-repack[1]
mentioned above.
@ -97,4 +97,4 @@ Documentation by Sergey Vlasov
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -14,5 +14,5 @@ SYNOPSIS
DESCRIPTION
-----------
This is a synonym for gitlink:git-init[1]. Please refer to the
This is a synonym for linkgit:git-init[1]. Please refer to the
documentation of that command.

4
Documentation/git-init.txt
View file

@ -52,7 +52,7 @@ is given:
- 'all' (or 'world' or 'everybody'): Same as 'group', but make the repository
readable by all users.
By default, the configuration flag receive.denyNonFastforward is enabled
By default, the configuration flag receive.denyNonFastForwards is enabled
in shared repositories, so that you cannot force a non fast-forwarding push
into it.
@ -111,4 +111,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

15
Documentation/git-instaweb.txt
View file

@ -38,10 +38,11 @@ OPTIONS
The port number to bind the httpd to. (Default: 1234)
-b|--browser::
The web browser command-line to execute to view the gitweb page.
If blank, the URL of the gitweb instance will be printed to
stdout. (Default: 'firefox')
The web browser that should be used to view the gitweb
page. This will be passed to the 'git-web--browse' helper
script along with the URL of the gitweb instance. See
linkgit:git-web--browse[1] for more information about this. If
the script fails, the URL will be printed to stdout.
--start::
Start the httpd instance and exit. This does not generate
@ -71,6 +72,10 @@ You may specify configuration in your .git/config
-----------------------------------------------------------------------
If the configuration variable 'instaweb.browser' is not set,
'web.browser' will be used instead if it is defined. See
linkgit:git-web--browse[1] for more information about this.
Author
------
Written by Eric Wong <normalperson@yhbt.net>
@ -81,4 +86,4 @@ Documentation by Eric Wong <normalperson@yhbt.net>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

66
Documentation/git-local-fetch.txt
View file

@ -1,66 +0,0 @@
git-local-fetch(1)
==================
NAME
----
git-local-fetch - Duplicate another git repository on a local system
SYNOPSIS
--------
[verse]
'git-local-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [-l] [-s] [-n]
commit-id path
DESCRIPTION
-----------
THIS COMMAND IS DEPRECATED.
Duplicates another git repository on a local system.
OPTIONS
-------
-c::
Get the commit objects.
-t::
Get trees associated with the commit objects.
-a::
Get all the objects.
-v::
Report what is downloaded.
-s::
Instead of regular file-to-file copying use symbolic links to the objects
in the remote repository.
-l::
Before attempting symlinks (if -s is specified) or file-to-file copying the
remote objects, try to hardlink the remote objects into the local
repository.
-n::
Never attempt to file-to-file copy remote objects. Only useful with
-s or -l command-line options.
-w <filename>::
Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on
the local end after the transfer is complete.
--stdin::
Instead of a commit id on the command line (which is not expected in this
case), 'git-local-fetch' expects lines on stdin in the format
<commit-id>['\t'<filename-as-in--w>]
--recover::
Verify that everything reachable from target is fetched. Used after
an earlier fetch is interrupted.
Author
------
Written by Junio C Hamano <junkio@cox.net>
Documentation
--------------
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite

30
Documentation/git-log.txt
View file

@ -14,18 +14,17 @@ DESCRIPTION
-----------
Shows the commit logs.
The command takes options applicable to the gitlink:git-rev-list[1]
The command takes options applicable to the linkgit:git-rev-list[1]
command to control what is shown and how, and options applicable to
the gitlink:git-diff-tree[1] commands to control how the changes
the linkgit:git-diff-tree[1] commands to control how the changes
each commit introduces are shown.
This manual page describes only the most frequently used options.
OPTIONS
-------
include::pretty-options.txt[]
:git-log: 1
include::diff-options.txt[]
-<n>::
Limits the number of commits to show.
@ -36,21 +35,7 @@ include::pretty-options.txt[]
`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].
--first-parent::
Follow only the first parent commit upon seeing a merge
commit. This option gives a better overview of the
evolution of a particular branch.
-p::
Show the change the commit introduces in a patch form.
-g, \--walk-reflogs::
Show commits as they were recorded in the reflog. The log contains
a record about how the tip of a reference was changed.
Cannot be combined with --reverse.
See also gitlink:git-reflog[1].
linkgit:git-rev-parse[1].
--decorate::
Print out the ref names of any commits that are shown.
@ -76,8 +61,11 @@ include::pretty-options.txt[]
Show only commits that affect the specified paths.
include::rev-list-options.txt[]
include::pretty-formats.txt[]
include::diff-generate-patch.txt[]
Examples
--------
@ -124,4 +112,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

6
Documentation/git-lost-found.txt
View file

@ -11,6 +11,10 @@ SYNOPSIS
DESCRIPTION
-----------
*NOTE*: this command is deprecated. Use linkgit:git-fsck[1] with
the option '--lost-found' instead.
Finds dangling commits and tags from the object database, and
creates refs to them in the .git/lost-found/ directory. Commits and
tags that dereference to commits are stored in .git/lost-found/commit,
@ -74,4 +78,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

14
Documentation/git-ls-files.txt
View file

@ -15,6 +15,7 @@ SYNOPSIS
[-x <pattern>|--exclude=<pattern>]
[-X <file>|--exclude-from=<file>]
[--exclude-per-directory=<file>]
[--exclude-standard]
[--error-unmatch] [--with-tree=<tree-ish>]
[--full-name] [--abbrev] [--] [<file>]\*
@ -77,6 +78,10 @@ OPTIONS
read additional exclude patterns that apply only to the
directory and its subdirectories in <file>.
--exclude-standard::
Add the standard git exclusions: .git/info/exclude, .gitignore
in each directory, and the user's global exclusion file.
--error-unmatch::
If any <file> does not appear in the index, treat this as an
error (return 1).
@ -100,7 +105,8 @@ OPTIONS
-v::
Similar to `-t`, but use lowercase letters for files
that are marked as 'always matching index'.
that are marked as 'assume unchanged' (see
linkgit:git-update-index[1]).
--full-name::
When run from a subdirectory, the command usually
@ -146,7 +152,7 @@ Exclude Patterns
'git-ls-files' can use a list of "exclude patterns" when
traversing the directory tree and finding files to show when the
flags --others or --ignored are specified. gitlink:gitignore[5]
flags --others or --ignored are specified. linkgit:gitignore[5]
specifies the format of exclude patterns.
These exclude patterns come from these places, in order:
@ -173,7 +179,7 @@ pattern file appears in.
See Also
--------
gitlink:git-read-tree[1], gitlink:gitignore[5]
linkgit:git-read-tree[1], linkgit:gitignore[5]
Author
@ -186,4 +192,4 @@ Documentation by David Greaves, Junio C Hamano, Josh Triplett, and the git-list
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -27,10 +27,10 @@ OPTIONS
displayed.
-u <exec>, --upload-pack=<exec>::
Specify the full path of gitlink:git-upload-pack[1] on the remote
Specify the full path of linkgit:git-upload-pack[1] on the remote
host. This allows listing references from repositories accessed via
SSH and where the SSH daemon does not use the PATH configured by the
user. Also see the '--exec' option for gitlink:git-peek-remote[1].
user.
<repository>::
Location of the repository. The shorthand defined in
@ -69,4 +69,4 @@ Written by Junio C Hamano <junkio@cox.net>
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -91,4 +91,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

4
Documentation/git-mailinfo.txt
View file

@ -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-am
to create a commit. It is usually not necessary to use this
command directly. See gitlink:git-am[1] instead.
command directly. See linkgit:git-am[1] instead.
OPTIONS
@ -66,4 +66,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

2
Documentation/git-mailsplit.txt
View file

@ -55,4 +55,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -39,4 +39,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -41,7 +41,7 @@ conflicts otherwise. If the merge was clean, the exit value is 0.
git-merge-file is designed to be a minimal clone of RCS merge, that is, it
implements all of RCS merge's functionality which is needed by
gitlink:git[1].
linkgit:git[1].
OPTIONS
@ -89,4 +89,4 @@ with parts copied from the original documentation of RCS merge.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -8,7 +8,7 @@ git-merge-index - Run a merge for files needing merging
SYNOPSIS
--------
'git-merge-index' [-o] [-q] <merge-program> (-a | \-- | <file>\*)
'git-merge-index' [-o] [-q] <merge-program> (-a | [--] <file>\*)
DESCRIPTION
-----------
@ -84,4 +84,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -26,4 +26,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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

@ -33,4 +33,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

30
Documentation/git-merge.txt
View file

@ -11,26 +11,27 @@ SYNOPSIS
[verse]
'git-merge' [-n] [--summary] [--no-commit] [--squash] [-s <strategy>]...
[-m <msg>] <remote> <remote>...
'git-merge' <msg> HEAD <remote>...
DESCRIPTION
-----------
This is the top-level interface to the merge machinery
which drives multiple merge strategy scripts.
The second syntax (<msg> `HEAD` <remote>) is supported for
historical reasons. Do not use it from the command line or in
new scripts. It is the same as `git merge -m <msg> <remote>`.
OPTIONS
-------
include::merge-options.txt[]
<msg>::
-m <msg>::
The commit message to be used for the merge commit (in case
it is created). The `git-fmt-merge-msg` script can be used
to give a good default for automated `git-merge` invocations.
<head>::
Our branch head commit. This has to be `HEAD`, so new
syntax does not require it
<remote>::
Other branch head merged into our branch. You need at
least one <remote>. Specifying more than one <remote>
@ -41,7 +42,7 @@ include::merge-strategies.txt[]
If you tried a merge which resulted in a complex conflicts and
would want to start over, you can recover with
gitlink:git-reset[1].
linkgit:git-reset[1].
CONFIGURATION
-------------
@ -73,14 +74,14 @@ it happens. In other words, `git-diff --cached HEAD` must
report no changes.
[NOTE]
This is a bit of lie. In certain special cases, your index are
allowed to be different from the tree of `HEAD` commit. The most
This is a bit of a lie. In certain special cases, your index is
allowed to be different from the tree of the `HEAD` commit. The most
notable case is when your `HEAD` commit is already ahead of what
is being merged, in which case your index can have arbitrary
difference from your `HEAD` commit. Otherwise, your index entries
are allowed have differences from your `HEAD` commit that match
the result of trivial merge (e.g. you received the same patch
from external source to produce the same result as what you are
differences from your `HEAD` commit. Also, your index entries
may have differences from your `HEAD` commit that match
the result of a trivial merge (e.g. you received the same patch
from an external source to produce the same result as what you are
merging). For example, if a path did not exist in the common
ancestor and your head commit but exists in the tree you are
merging into your repository, and if you already happen to have
@ -162,7 +163,8 @@ After seeing a conflict, you can do two things:
SEE ALSO
--------
gitlink:git-fmt-merge-msg[1], gitlink:git-pull[1]
linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],
linkgit:gitattributes[5]
Author
@ -176,4 +178,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

12
Documentation/git-mergetool.txt
View file

@ -13,7 +13,7 @@ DESCRIPTION
-----------
Use 'git mergetool' to run one of several merge utilities to resolve
merge conflicts. It is typically run after gitlink:git-merge[1].
merge conflicts. It is typically run after linkgit:git-merge[1].
If one or more <file> parameters are given, the merge tool program will
be run to resolve differences on each file. If no <file> names are
@ -25,12 +25,18 @@ OPTIONS
-t or --tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid merge tools are:
kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, and opendiff
kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
configuration variable merge.tool is not set, 'git mergetool'
will pick a suitable default.
+
You can explicitly provide a full path to the tool by setting the
configuration variable mergetool.<tool>.path. For example, you
can configure the absolute path to kdiff3 by setting
mergetool.kdiff3.path. Otherwise, 'git mergetool' assumes the tool
is available in PATH.
Author
------
@ -42,4 +48,4 @@ Documentation by Theodore Y Ts'o.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

2
Documentation/git-mktag.txt
View file

@ -43,4 +43,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite

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