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

Merge commit 'v1.7.0' into jc/checkout-reflog-fix

Browse Source 
* commit 'v1.7.0': (4188 commits)
  Git 1.7.0
  Fix typo in 1.6.6.2 release notes
  Re-fix check-ref-format documentation mark-up
  archive documentation: attributes are taken from the tree by default
  Documentation: minor fixes to RelNotes-1.7.0
  bash: support 'git am's new '--continue' option
  filter-branch: Fix error message for --prune-empty --commit-filter
  am: switch --resolved to --continue
  Update draft release notes to 1.7.0 one more time
  Git 1.6.6.2
  t8003: check exit code of command and error message separately
  check-ref-format documentation: fix enumeration mark-up
  Documentation: quote braces in {upstream} notation
  t3902: Protect against OS X normalization
  blame: prevent a segv when -L given start > EOF
  git-push: document all the status flags used in the output
  Fix parsing of imap.preformattedHTML and imap.sslverify
  git-add documentation: Fix shell quoting example
  Revert "pack-objects: fix pack generation when using pack_size_limit"
  archive: simplify archive format guessing
  ...
This commit is contained in:
Junio C Hamano 2011-07-06 15:38:18 -07:00
commit 71ee7fd154
1295 changed files with 132699 additions and 33030 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitattributes vendored
View File

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

361
.gitignore vendored
View File

@ -1,171 +1,202 @@
GIT-BUILD-OPTIONS
GIT-CFLAGS
GIT-GUI-VARS
GIT-VERSION-FILE
git
git-add
git-add--interactive
git-am
git-annotate
git-apply
git-archimport
git-archive
git-bisect
git-blame
git-branch
git-bundle
git-cat-file
git-check-attr
git-check-ref-format
git-checkout
git-checkout-index
git-cherry
git-cherry-pick
git-clean
git-clone
git-commit
git-commit-tree
git-config
git-count-objects
git-cvsexportcommit
git-cvsimport
git-cvsserver
git-daemon
git-diff
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-fmt-merge-msg
git-for-each-ref
git-format-patch
git-fsck
git-fsck-objects
git-gc
git-get-tar-commit-id
git-grep
git-hash-object
git-http-fetch
git-http-push
git-imap-send
git-index-pack
git-init
git-init-db
git-instaweb
git-log
git-lost-found
git-ls-files
git-ls-remote
git-ls-tree
git-mailinfo
git-mailsplit
git-merge
git-merge-base
git-merge-index
git-merge-file
git-merge-tree
git-merge-octopus
git-merge-one-file
git-merge-ours
git-merge-recursive
git-merge-resolve
git-merge-subtree
git-mergetool
git-mktag
git-mktree
git-name-rev
git-mv
git-pack-redundant
git-pack-objects
git-pack-refs
git-parse-remote
git-patch-id
git-peek-remote
git-prune
git-prune-packed
git-pull
git-push
git-quiltimport
git-read-tree
git-rebase
git-rebase--interactive
git-receive-pack
git-reflog
git-relink
git-remote
git-repack
git-repo-config
git-request-pull
git-rerere
git-reset
git-rev-list
git-rev-parse
git-revert
git-rm
git-send-email
git-send-pack
git-sh-setup
git-shell
git-shortlog
git-show
git-show-branch
git-show-index
git-show-ref
git-stash
git-status
git-stripspace
git-submodule
git-svn
git-symbolic-ref
git-tag
git-tar-tree
git-unpack-file
git-unpack-objects
git-update-index
git-update-ref
git-update-server-info
git-upload-archive
git-upload-pack
git-var
git-verify-pack
git-verify-tag
git-web--browse
git-whatchanged
git-write-tree
git-core-*/?*
gitk-wish
gitweb/gitweb.cgi
test-chmtime
test-date
test-delta
test-dump-cache-tree
test-genrandom
test-match-trees
test-parse-options
test-path-utils
test-sha1
common-cmds.h
/GIT-BUILD-OPTIONS
/GIT-CFLAGS
/GIT-GUI-VARS
/GIT-VERSION-FILE
/bin-wrappers/
/git
/git-add
/git-add--interactive
/git-am
/git-annotate
/git-apply
/git-archimport
/git-archive
/git-bisect
/git-bisect--helper
/git-blame
/git-branch
/git-bundle
/git-cat-file
/git-check-attr
/git-check-ref-format
/git-checkout
/git-checkout-index
/git-cherry
/git-cherry-pick
/git-clean
/git-clone
/git-commit
/git-commit-tree
/git-config
/git-count-objects
/git-cvsexportcommit
/git-cvsimport
/git-cvsserver
/git-daemon
/git-diff
/git-diff-files
/git-diff-index
/git-diff-tree
/git-difftool
/git-difftool--helper
/git-describe
/git-fast-export
/git-fast-import
/git-fetch
/git-fetch--tool
/git-fetch-pack
/git-filter-branch
/git-fmt-merge-msg
/git-for-each-ref
/git-format-patch
/git-fsck
/git-fsck-objects
/git-gc
/git-get-tar-commit-id
/git-grep
/git-hash-object
/git-help
/git-http-backend
/git-http-fetch
/git-http-push
/git-imap-send
/git-index-pack
/git-init
/git-init-db
/git-instaweb
/git-log
/git-lost-found
/git-ls-files
/git-ls-remote
/git-ls-tree
/git-mailinfo
/git-mailsplit
/git-merge
/git-merge-base
/git-merge-index
/git-merge-file
/git-merge-tree
/git-merge-octopus
/git-merge-one-file
/git-merge-ours
/git-merge-recursive
/git-merge-resolve
/git-merge-subtree
/git-mergetool
/git-mergetool--lib
/git-mktag
/git-mktree
/git-name-rev
/git-mv
/git-notes
/git-pack-redundant
/git-pack-objects
/git-pack-refs
/git-parse-remote
/git-patch-id
/git-peek-remote
/git-prune
/git-prune-packed
/git-pull
/git-push
/git-quiltimport
/git-read-tree
/git-rebase
/git-rebase--interactive
/git-receive-pack
/git-reflog
/git-relink
/git-remote
/git-remote-curl
/git-remote-http
/git-remote-https
/git-remote-ftp
/git-remote-ftps
/git-repack
/git-replace
/git-repo-config
/git-request-pull
/git-rerere
/git-reset
/git-rev-list
/git-rev-parse
/git-revert
/git-rm
/git-send-email
/git-send-pack
/git-sh-setup
/git-shell
/git-shortlog
/git-show
/git-show-branch
/git-show-index
/git-show-ref
/git-stage
/git-stash
/git-status
/git-stripspace
/git-submodule
/git-svn
/git-symbolic-ref
/git-tag
/git-tar-tree
/git-unpack-file
/git-unpack-objects
/git-update-index
/git-update-ref
/git-update-server-info
/git-upload-archive
/git-upload-pack
/git-var
/git-verify-pack
/git-verify-tag
/git-web--browse
/git-whatchanged
/git-write-tree
/git-core-*/?*
/gitk-git/gitk-wish
/gitweb/gitweb.cgi
/test-chmtime
/test-ctype
/test-date
/test-delta
/test-dump-cache-tree
/test-genrandom
/test-index-version
/test-match-trees
/test-parse-options
/test-path-utils
/test-run-command
/test-sha1
/test-sigchain
/common-cmds.h
*.tar.gz
*.dsc
*.deb
git.spec
/git.spec
*.exe
*.[aos]
*.py[co]
config.mak
autom4te.cache
config.cache
config.log
config.status
config.mak.autogen
config.mak.append
configure
tags
TAGS
cscope*
*+
/config.mak
/autom4te.cache
/config.cache
/config.log
/config.status
/config.mak.autogen
/config.mak.append
/configure
/tags
/TAGS
/cscope*
*.obj
*.lib
*.sln
*.suo
*.ncb
*.vcproj
*.user
*.idb
*.pdb
/Debug/
/Release/

1
.mailmap
View File

@ -41,6 +41,7 @@ Michele Ballabio <barra_cuda@katamail.com>
Nanako Shiraishi <nanako3@bluebottle.com>
Nanako Shiraishi <nanako3@lavabit.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
<nico@fluxnic.net> <nico@cam.org>
Philippe Bruhat <book@cpan.org>
Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
René Scharfe <rene.scharfe@lsrfire.ath.cx>

25
COPYING
View File

@ -22,8 +22,8 @@
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
@ -36,7 +36,7 @@ software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
@ -76,7 +76,7 @@ patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
@ -131,7 +131,7 @@ above, provided that you also meet all of these conditions:
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
@ -189,7 +189,7 @@ access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
@ -246,7 +246,7 @@ impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
@ -299,7 +299,7 @@ PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
@ -324,10 +324,9 @@ the "copyright" line and a pointer to where the full notice is found.
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
Also add information on how to contact you by electronic and paper mail.
@ -357,5 +356,5 @@ necessary. Here is a sample; alter the names:
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License.

1
Documentation/.gitignore vendored
View File

@ -8,3 +8,4 @@ gitman.info
howto-index.txt
doc.dep
cmds-*.txt
manpage-base-url.xsl

12
Documentation/CodingGuidelines
View File

@ -21,8 +21,13 @@ code. For git in general, three rough rules are:
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.
contributing to). It is always preferable to match the _local_
convention. New code added to git suite is expected to match
the overall style of existing code. Modifications to existing
code is expected to match the style the surrounding code already
uses (even if it doesn't match the overall style of existing code).
But if you must have a list of rules, here they are.
For shell scripts specifically (not exhaustive):
@ -124,3 +129,6 @@ For C programs:
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).
- When we pass <string, length> pair to functions, we should try to
pass them in that order.

201
Documentation/Makefile
View File

@ -6,7 +6,7 @@ MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
gitrepository-layout.txt
MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
gitdiffcore.txt
gitdiffcore.txt gitworkflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
@ -17,6 +17,7 @@ DOC_HTML=$(MAN_HTML)
ARTICLES = howto-index
ARTICLES += everyday
ARTICLES += git-tools
ARTICLES += git-bisect-lk2009
# with their own formatting rules.
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)))
@ -32,6 +33,7 @@ DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
prefix?=$(HOME)
bindir?=$(prefix)/bin
htmldir?=$(prefix)/share/doc/git-doc
pdfdir?=$(prefix)/share/doc/git-doc
mandir?=$(prefix)/share/man
man1dir=$(mandir)/man1
man5dir=$(mandir)/man5
@ -40,15 +42,18 @@ man7dir=$(mandir)/man7
ASCIIDOC=asciidoc
ASCIIDOC_EXTRA =
MANPAGE_XSL = callouts.xsl
MANPAGE_XSL = manpage-normal.xsl
XMLTO_EXTRA =
INSTALL?=install
RM ?= rm -f
DOC_REF = origin/man
HTML_REF = origin/html
infodir?=$(prefix)/share/info
MAKEINFO=makeinfo
INSTALL_INFO=install-info
DOCBOOK2X_TEXI=docbook2x-texi
DBLATEX=dblatex
ifndef PERL_PATH
PERL_PATH = /usr/bin/perl
endif
@ -56,13 +61,71 @@ endif
-include ../config.mak.autogen
-include ../config.mak
#
# For asciidoc ...
# -7.1.2, no extra settings are needed.
# 8.0-, set ASCIIDOC8.
#
#
# For docbook-xsl ...
# -1.68.1, set ASCIIDOC_NO_ROFF? (based on changelog from 1.73.0)
# 1.69.0, no extra settings are needed?
# 1.69.1-1.71.0, set DOCBOOK_SUPPRESS_SP?
# 1.71.1, no extra settings are needed?
# 1.72.0, set DOCBOOK_XSL_172.
# 1.73.0-, set ASCIIDOC_NO_ROFF
#
#
# If you had been using DOCBOOK_XSL_172 in an attempt to get rid
# of 'the ".ft C" problem' in your generated manpages, and you
# instead ended up with weird characters around callouts, try
# using ASCIIDOC_NO_ROFF instead (it works fine with ASCIIDOC8).
#
ifdef ASCIIDOC8
ASCIIDOC_EXTRA += -a asciidoc7compatible
ASCIIDOC_EXTRA += -a asciidoc7compatible -a no-inline-literal
endif
ifdef DOCBOOK_XSL_172
ASCIIDOC_EXTRA += -a docbook-xsl-172
ASCIIDOC_EXTRA += -a git-asciidoc-no-roff
MANPAGE_XSL = manpage-1.72.xsl
else
ifdef ASCIIDOC_NO_ROFF
# docbook-xsl after 1.72 needs the regular XSL, but will not
# pass-thru raw roff codes from asciidoc.conf, so turn them off.
ASCIIDOC_EXTRA += -a git-asciidoc-no-roff
endif
endif
ifdef MAN_BOLD_LITERAL
XMLTO_EXTRA += -m manpage-bold-literal.xsl
endif
ifdef DOCBOOK_SUPPRESS_SP
XMLTO_EXTRA += -m manpage-suppress-sp.xsl
endif
# Newer DocBook stylesheet emits warning cruft in the output when
# this is not set, and if set it shows an absolute link. Older
# stylesheets simply ignore this parameter.
#
# Distros may want to use MAN_BASE_URL=file:///path/to/git/docs/
# or similar.
ifndef MAN_BASE_URL
MAN_BASE_URL = file://$(htmldir)/
endif
XMLTO_EXTRA += -m manpage-base-url.xsl
# If your target system uses GNU groff, it may try to render
# apostrophes as a "pretty" apostrophe using unicode. This breaks
# cut&paste, so you should set GNU_ROFF to force them to be ASCII
# apostrophes. Unfortunately does not work with non-GNU roff.
ifdef GNU_ROFF
XMLTO_EXTRA += -m manpage-quote-apos.xsl
endif
SHELL_PATH ?= $(SHELL)
# Shell quote;
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
#
# Please note that there is a minor bug in asciidoc.
@ -73,6 +136,32 @@ endif
# yourself - yes, all 6 characters of it!
#
QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
QUIET_SUBDIR1 =
ifneq ($(findstring $(MAKEFLAGS),w),w)
PRINT_DIR = --no-print-directory
else # "make -w"
NO_SUBDIR = :
endif
ifneq ($(findstring $(MAKEFLAGS),s),s)
ifndef V
QUIET_ASCIIDOC = @echo ' ' ASCIIDOC $@;
QUIET_XMLTO = @echo ' ' XMLTO $@;
QUIET_DB2TEXI = @echo ' ' DB2TEXI $@;
QUIET_MAKEINFO = @echo ' ' MAKEINFO $@;
QUIET_DBLATEX = @echo ' ' DBLATEX $@;
QUIET_XSLTPROC = @echo ' ' XSLTPROC $@;
QUIET_GEN = @echo ' ' GEN $@;
QUIET_STDERR = 2> /dev/null
QUIET_SUBDIR0 = +@subdir=
QUIET_SUBDIR1 = ;$(NO_SUBDIR) echo ' ' SUBDIR $$subdir; \
$(MAKE) $(PRINT_DIR) -C $$subdir
export V
endif
endif
all: html man
html: $(DOC_HTML)
@ -86,7 +175,11 @@ man7: $(DOC_MAN7)
info: git.info gitman.info
install: man
pdf: user-manual.pdf
install: install-man
install-man: man
$(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
$(INSTALL) -d -m 755 $(DESTDIR)$(man5dir)
$(INSTALL) -d -m 755 $(DESTDIR)$(man7dir)
@ -104,11 +197,15 @@ install-info: info
echo "No directory found in $(DESTDIR)$(infodir)" >&2 ; \
fi
install-html: html
sh ./install-webdoc.sh $(DESTDIR)$(htmldir)
install-pdf: pdf
$(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir)
$(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir)
../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
$(MAKE) -C ../ GIT-VERSION-FILE
install-html: html
'$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir)
../GIT-VERSION-FILE: FORCE
$(QUIET_SUBDIR0)../ $(QUIET_SUBDIR1) GIT-VERSION-FILE
-include ../GIT-VERSION-FILE
@ -116,8 +213,8 @@ install-html: html
# Determine "include::" file references in asciidoc files.
#
doc.dep : $(wildcard *.txt) build-docdep.perl
$(RM) $@+ $@
$(PERL_PATH) ./build-docdep.perl >$@+
$(QUIET_GEN)$(RM) $@+ $@ && \
$(PERL_PATH) ./build-docdep.perl >$@+ $(QUIET_STDERR) && \
mv $@+ $@
-include doc.dep
@ -135,91 +232,109 @@ cmds_txt = cmds-ancillaryinterrogators.txt \
$(cmds_txt): cmd-list.made
cmd-list.made: cmd-list.perl ../command-list.txt $(MAN1_TXT)
$(RM) $@
$(PERL_PATH) ./cmd-list.perl ../command-list.txt
$(QUIET_GEN)$(RM) $@ && \
$(PERL_PATH) ./cmd-list.perl ../command-list.txt $(QUIET_STDERR) && \
date >$@
clean:
$(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7
$(RM) *.texi *.texi+ git.info gitman.info
$(RM) *.texi *.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
$(RM) manpage-base-url.xsl
$(MAN_HTML): %.html : %.txt
$(RM) $@+ $@
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \
mv $@+ $@
%.1 %.5 %.7 : %.xml
$(RM) $@
xmlto -m $(MANPAGE_XSL) man $<
manpage-base-url.xsl: manpage-base-url.xsl.in
sed "s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|" $< > $@
%.1 %.5 %.7 : %.xml manpage-base-url.xsl
$(QUIET_XMLTO)$(RM) $@ && \
xmlto -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<
%.xml : %.txt
$(RM) $@+ $@
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
$(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \
mv $@+ $@
user-manual.xml: user-manual.txt user-manual.conf
$(ASCIIDOC) -b docbook -d book $<
$(QUIET_ASCIIDOC)$(ASCIIDOC) $(ASCIIDOC_EXTRA) -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
$(QUIET_GEN)cd technical && '$(SHELL_PATH_SQ)' ./api-index.sh
$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt
$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \
$(QUIET_ASCIIDOC)$(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) $<
$(QUIET_XSLTPROC)xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
git.info: user-manual.texi
$(MAKEINFO) --no-split -o $@ user-manual.texi
$(QUIET_MAKEINFO)$(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 >$@+
$(QUIET_DB2TEXI)$(RM) $@+ $@ && \
$(DOCBOOK2X_TEXI) user-manual.xml --encoding=UTF-8 --to-stdout >$@++ && \
$(PERL_PATH) fix-texi.perl <$@++ >$@+ && \
rm $@++ && \
mv $@+ $@
user-manual.pdf: user-manual.xml
$(QUIET_DBLATEX)$(RM) $@+ $@ && \
$(DBLATEX) -o $@+ -p /etc/asciidoc/dblatex/asciidoc-dblatex.xsl -s /etc/asciidoc/dblatex/asciidoc-dblatex.sty $< && \
mv $@+ $@
gitman.texi: $(MAN_XML) cat-texi.perl
$(RM) $@+ $@
($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --to-stdout $(xml);)) | \
$(PERL_PATH) cat-texi.perl $@ >$@+
$(QUIET_DB2TEXI)$(RM) $@+ $@ && \
($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --encoding=UTF-8 \
--to-stdout $(xml) &&) true) > $@++ && \
$(PERL_PATH) cat-texi.perl $@ <$@++ >$@+ && \
rm $@++ && \
mv $@+ $@
gitman.info: gitman.texi
$(MAKEINFO) --no-split $*.texi
$(QUIET_MAKEINFO)$(MAKEINFO) --no-split --no-validate $*.texi
$(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
$(RM) $@+ $@
$(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@+
$(QUIET_DB2TEXI)$(RM) $@+ $@ && \
$(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@+ && \
mv $@+ $@
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
$(RM) $@+ $@
sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
$(QUIET_GEN)$(RM) $@+ $@ && \
'$(SHELL_PATH_SQ)' ./howto-index.sh $(wildcard howto/*.txt) >$@+ && \
mv $@+ $@
$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
$(ASCIIDOC) -b xhtml11 $*.txt
$(QUIET_ASCIIDOC)$(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 $*.txt
WEBDOC_DEST = /pub/software/scm/git/docs
$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
$(RM) $@+ $@
sed -e '1,/^$$/d' $< | $(ASCIIDOC) -b xhtml11 - >$@+
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
sed -e '1,/^$$/d' $< | $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 - >$@+ && \
mv $@+ $@
install-webdoc : html
sh ./install-webdoc.sh $(WEBDOC_DEST)
'$(SHELL_PATH_SQ)' ./install-webdoc.sh $(WEBDOC_DEST)
quick-install:
sh ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
quick-install: quick-install-man
.PHONY: .FORCE-GIT-VERSION-FILE
quick-install-man:
'$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
quick-install-html:
'$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir)
.PHONY: FORCE

2
Documentation/RelNotes-1.5.2.2.txt
View File

@ -45,7 +45,7 @@ Fixes since v1.5.2.1
correctly when the branch name had slash in it.
- The email address of the user specified with user.email
configuration was overriden by EMAIL environment variable.
configuration was overridden by EMAIL environment variable.
- The tree parser did not warn about tree entries with
nonsense file modes, and assumed they must be blobs.

10
Documentation/RelNotes-1.5.4.7.txt Normal file
View File

@ -0,0 +1,10 @@
GIT v1.5.4.7 Release Notes
==========================
Fixes since 1.5.4.7
-------------------
* Removed support for an obsolete gitweb request URI, whose
implementation ran "git diff" Porcelain, instead of using plumbing,
which would have run an external diff command specified in the
repository configuration as the gitweb user.

10
Documentation/RelNotes-1.5.5.6.txt Normal file
View File

@ -0,0 +1,10 @@
GIT v1.5.5.6 Release Notes
==========================
Fixes since 1.5.5.5
-------------------
* Removed support for an obsolete gitweb request URI, whose
implementation ran "git diff" Porcelain, instead of using plumbing,
which would have run an external diff command specified in the
repository configuration as the gitweb user.

10
Documentation/RelNotes-1.5.6.6.txt Normal file
View File

@ -0,0 +1,10 @@
GIT v1.5.6.6 Release Notes
==========================
Fixes since 1.5.6.5
-------------------
* Removed support for an obsolete gitweb request URI, whose
implementation ran "git diff" Porcelain, instead of using plumbing,
which would have run an external diff command specified in the
repository configuration as the gitweb user.

36
Documentation/RelNotes-1.6.0.1.txt Normal file
View File

@ -0,0 +1,36 @@
GIT v1.6.0.1 Release Notes
==========================
Fixes since v1.6.0
------------------
* "git diff --cc" did not honor content mangling specified by
gitattributes and core.autocrlf when reading from the work tree.
* "git diff --check" incorrectly detected new trailing blank lines when
whitespace check was in effect.
* "git for-each-ref" tried to dereference NULL when asked for '%(body)" on
a tag with a single incomplete line as its payload.
* "git format-patch" peeked before the beginning of a string when
"format.headers" variable is empty (a misconfiguration).
* "git help help" did not work correctly.
* "git mailinfo" (hence "git am") was unhappy when MIME multipart message
contained garbage after the finishing boundary.
* "git mailinfo" also was unhappy when the "From: " line only had a bare
e-mail address.
* "git merge" did not refresh the index correctly when a merge resulted in
a fast-forward.
* "git merge" did not resolve a truly trivial merges that can be done
without content level merges.
* "git svn dcommit" to a repository with URL that has embedded usernames
did not work correctly.
Contains other various documentation fixes.

87
Documentation/RelNotes-1.6.0.2.txt Normal file
View File

@ -0,0 +1,87 @@
GIT v1.6.0.2 Release Notes
==========================
Fixes since v1.6.0.1
--------------------
* Installation on platforms that needs .exe suffix to git-* programs were
broken in 1.6.0.1.
* Installation on filesystems without symbolic links support did not
work well.
* In-tree documentations and test scripts now use "git foo" form to set a
better example, instead of the "git-foo" form (which is an acceptable
form if you have "PATH=$(git --exec-path):$PATH" in your script)
* Many commands did not use the correct working tree location when used
with GIT_WORK_TREE environment settings.
* Some systems needs to use compatibility fnmach and regex libraries
independent from each other; the compat/ area has been reorganized to
allow this.
* "git apply --unidiff-zero" incorrectly applied a -U0 patch that inserts
a new line before the second line.
* "git blame -c" did not exactly work like "git annotate" when range
boundaries are involved.
* "git checkout file" when file is still unmerged checked out contents from
a random high order stage, which was confusing.
* "git clone $there $here/" with extra trailing slashes after explicit
local directory name $here did not work as expected.
* "git diff" on tracked contents with CRLF line endings did not drive "less"
intelligently when showing added or removed lines.
* "git diff --dirstat -M" did not add changes in subdirectories up
correctly for renamed paths.
* "git diff --cumulative" did not imply "--dirstat".
* "git for-each-ref refs/heads/" did not work as expected.
* "git gui" allowed users to feed patch without any context to be applied.
* "git gui" botched parsing "diff" output when a line that begins with two
dashes and a space gets removed or a line that begins with two pluses
and a space gets added.
* "git gui" translation updates and i18n fixes.
* "git index-pack" is more careful against disk corruption while completing
a thin pack.
* "git log -i --grep=pattern" did not ignore case; neither "git log -E
--grep=pattern" triggered extended regexp.
* "git log --pretty="%ad" --date=short" did not use short format when
showing the timestamp.
* "git log --author=author" match incorrectly matched with the
timestamp part of "author " line in commit objects.
* "git log -F --author=author" did not work at all.
* Build procedure for "git shell" that used stub versions of some
functions and globals was not understood by linkers on some platforms.
* "git stash" was fooled by a stat-dirty but otherwise unmodified paths
and refused to work until the user refreshed the index.
* "git svn" was broken on Perl before 5.8 with recent fixes to reduce
use of temporary files.
* "git verify-pack -v" did not work correctly when given more than one
packfile.
Also contains many documentation updates.
--
exec >/var/tmp/1
O=v1.6.0.1-78-g3632cfc
echo O=$(git describe maint)
git shortlog --no-merges $O..maint

117
Documentation/RelNotes-1.6.0.3.txt Normal file
View File

@ -0,0 +1,117 @@
GIT v1.6.0.3 Release Notes
==========================
Fixes since v1.6.0.2
--------------------
* "git archive --format=zip" did not honor core.autocrlf while
--format=tar did.
* Continuing "git rebase -i" was very confused when the user left modified
files in the working tree while resolving conflicts.
* Continuing "git rebase -i" was also very confused when the user left
some staged changes in the index after "edit".
* "git rebase -i" now honors the pre-rebase hook, just like the
other rebase implementations "git rebase" and "git rebase -m".
* "git rebase -i" incorrectly aborted when there is no commit to replay.
* Behaviour of "git diff --quiet" was inconsistent with "diff --exit-code"
with the output redirected to /dev/null.
* "git diff --no-index" on binary files no longer outputs a bogus
"diff --git" header line.
* "git diff" hunk header patterns with multiple elements separated by LF
were not used correctly.
* Hunk headers in "git diff" default to using extended regular
expressions, fixing some of the internal patterns on non-GNU
platforms.
* New config "diff.*.xfuncname" exposes extended regular expressions
for user specified hunk header patterns.
* "git gc" when ejecting otherwise unreachable objects from packfiles into
loose form leaked memory.
* "git index-pack" was recently broken and mishandled objects added by
thin-pack completion processing under memory pressure.
* "git index-pack" was recently broken and misbehaved when run from inside
.git/objects/pack/ directory.
* "git stash apply sash@{1}" was fixed to error out. Prior versions
would have applied stash@{0} incorrectly.
* "git stash apply" now offers a better suggestion on how to continue
if the working tree is currently dirty.
* "git for-each-ref --format=%(subject)" fixed for commits with no
no newline in the message body.
* "git remote" fixed to protect printf from user input.
* "git remote show -v" now displays all URLs of a remote.
* "git checkout -b branch" was confused when branch already existed.
* "git checkout -q" once again suppresses the locally modified file list.
* "git clone -q", "git fetch -q" asks remote side to not send
progress messages, actually making their output quiet.
* Cross-directory renames are no longer used when creating packs. This
allows more graceful behavior on filesystems like sshfs.
* Stale temporary files under $GIT_DIR/objects/pack are now cleaned up
automatically by "git prune".
* "git merge" once again removes directories after the last file has
been removed from it during the merge.
* "git merge" did not allocate enough memory for the structure itself when
enumerating the parents of the resulting commit.
* "git blame -C -C" no longer segfaults while trying to pass blame if
it encounters a submodule reference.
* "git rm" incorrectly claimed that you have local modifications when a
path was merely stat-dirty.
* "git svn" fixed to display an error message when 'set-tree' failed,
instead of a Perl compile error.
* "git submodule" fixed to handle checking out a different commit
than HEAD after initializing the submodule.
* The "git commit" error message when there are still unmerged
files present was clarified to match "git write-tree".
* "git init" was confused when core.bare or core.sharedRepository are set
in system or user global configuration file by mistake. When --bare or
--shared is given from the command line, these now override such
settings made outside the repositories.
* Some segfaults due to uncaught NULL pointers were fixed in multiple
tools such as apply, reset, update-index.
* Solaris builds now default to OLD_ICONV=1 to avoid compile warnings;
Solaris 8 does not define NEEDS_LIBICONV by default.
* "Git.pm" tests relied on unnecessarily more recent version of Perl.
* "gitweb" triggered undef warning on commits without log messages.
* "gitweb" triggered undef warnings on missing trees.
* "gitweb" now removes PATH_INFO from its URLs so users don't have
to manually set the URL in the gitweb configuration.
* Bash completion removed support for legacy "git-fetch", "git-push"
and "git-pull" as these are no longer installed. Dashless form
("git fetch") is still however supported.
Many other documentation updates.

39
Documentation/RelNotes-1.6.0.4.txt Normal file
View File

@ -0,0 +1,39 @@
GIT v1.6.0.4 Release Notes
==========================
Fixes since v1.6.0.3
--------------------
* 'git add -p' said "No changes" when only binary files were changed.
* 'git archive' did not work correctly in bare repositories.
* 'git checkout -t -b newbranch' when you are on detached HEAD was broken.
* when we refuse to detect renames because there are too many new or
deleted files, 'git diff' did not say how many there are.
* 'git push --mirror' tried and failed to push the stash; there is no
point in sending it to begin with.
* 'git push' did not update the remote tracking reference if the corresponding
ref on the remote end happened to be already up to date.
* 'git pull $there $branch:$current_branch' did not work when you were on
a branch yet to be born.
* when giving up resolving a conflicted merge, 'git reset --hard' failed
to remove new paths from the working tree.
* 'git send-email' had a small fd leak while scanning directory.
* 'git status' incorrectly reported a submodule directory as an untracked
directory.
* 'git svn' used deprecated 'git-foo' form of subcommand invocation.
* 'git update-ref -d' to remove a reference did not honor --no-deref option.
* Plugged small memleaks here and there.
* Also contains many documentation updates.

56
Documentation/RelNotes-1.6.0.5.txt Normal file
View File

@ -0,0 +1,56 @@
GIT v1.6.0.5 Release Notes
==========================
Fixes since v1.6.0.4
--------------------
* "git checkout" used to crash when your HEAD was pointing at a deleted
branch.
* "git checkout" from an un-checked-out state did not allow switching out
of the current branch.
* "git diff" always allowed GIT_EXTERNAL_DIFF and --no-ext-diff was no-op for
the command.
* Giving 3 or more tree-ish to "git diff" is supposed to show the combined
diff from second and subsequent trees to the first one, but the order was
screwed up.
* "git fast-export" did not export all tags.
* "git ls-files --with-tree=<tree>" did not work with options other
than -c, most notably with -m.
* "git pack-objects" did not make its best effort to honor --max-pack-size
option when a single first object already busted the given limit and
placed many objects in a single pack.
* "git-p4" fast import frontend was too eager to trigger its keyword expansion
logic, even on a keyword-looking string that does not have closing '$' on the
same line.
* "git push $there" when the remote $there is defined in $GIT_DIR/branches/$there
behaves more like what cg-push from Cogito used to work.
* when giving up resolving a conflicted merge, "git reset --hard" failed
to remove new paths from the working tree.
* "git tag" did not complain when given mutually incompatible set of options.
* The message constructed in the internal editor was discarded when "git
tag -s" failed to sign the message, which was often caused by the user
not configuring GPG correctly.
* "make check" cannot be run without sparse; people may have meant to say
"make test" instead, so suggest that.
* Internal diff machinery had a corner case performance bug that choked on
a large file with many repeated contents.
* "git repack" used to grab objects out of packs marked with .keep
into a new pack.
* Many unsafe call to sprintf() style varargs functions are corrected.
* Also contains quite a few documentation updates.

33
Documentation/RelNotes-1.6.0.6.txt Normal file
View File

@ -0,0 +1,33 @@
GIT v1.6.0.6 Release Notes
==========================
Fixes since 1.6.0.5
-------------------
* "git fsck" had a deep recursion that wasted stack space.
* "git fast-export" and "git fast-import" choked on an old style
annotated tag that lack the tagger information.
* "git mergetool -- file" did not correctly skip "--" marker that
signals the end of options list.
* "git show $tag" segfaulted when an annotated $tag pointed at a
nonexistent object.
* "git show 2>error" when the standard output is automatically redirected
to the pager redirected the standard error to the pager as well; there
was no need to.
* "git send-email" did not correctly handle list of addresses when
they had quoted comma (e.g. "Lastname, Givenname" <mail@addre.ss>).
* Logic to discover branch ancestry in "git svn" was unreliable when
the process to fetch history was interrupted.
* Removed support for an obsolete gitweb request URI, whose
implementation ran "git diff" Porcelain, instead of using plumbing,
which would have run an external diff command specified in the
repository configuration as the gitweb user.
Also contains numerous documentation typofixes.

59
Documentation/RelNotes-1.6.1.1.txt Normal file
View File

@ -0,0 +1,59 @@
GIT v1.6.1.1 Release Notes
==========================
Fixes since v1.6.1
------------------
* "git add frotz/nitfol" when "frotz" is a submodule should have errored
out, but it didn't.
* "git apply" took file modes from the patch text and updated the mode
bits of the target tree even when the patch was not about mode changes.
* "git bisect view" on Cygwin did not launch gitk
* "git checkout $tree" did not trigger an error.
* "git commit" tried to remove COMMIT_EDITMSG from the work tree by mistake.
* "git describe --all" complained when a commit is described with a tag,
which was nonsense.
* "git diff --no-index --" did not trigger no-index (aka "use git-diff as
a replacement of diff on untracked files") behaviour.
* "git format-patch -1 HEAD" on a root commit failed to produce patch
text.
* "git fsck branch" did not work as advertised; instead it behaved the same
way as "git fsck".
* "git log --pretty=format:%s" did not handle a multi-line subject the
same way as built-in log listers (i.e. shortlog, --pretty=oneline, etc.)
* "git daemon", and "git merge-file" are more careful when freopen fails
and barf, instead of going on and writing to unopened filehandle.
* "git http-push" did not like some RFC 4918 compliant DAV server
responses.
* "git merge -s recursive" mistakenly overwritten an untracked file in the
work tree upon delete/modify conflict.
* "git merge -s recursive" didn't leave the index unmerged for entries with
rename/delete conflicts.
* "git merge -s recursive" clobbered untracked files in the work tree.
* "git mv -k" with more than one erroneous paths misbehaved.
* "git read-tree -m -u" hence branch switching incorrectly lost a
subdirectory in rare cases.
* "git rebase -i" issued an unnecessary error message upon a user error of
marking the first commit to be "squash"ed.
* "git shortlog" did not format a commit message with multi-line
subject correctly.
Many documentation updates.

39
Documentation/RelNotes-1.6.1.2.txt Normal file
View File

@ -0,0 +1,39 @@
GIT v1.6.1.2 Release Notes
==========================
Fixes since v1.6.1.1
--------------------
* The logic for rename detection in internal diff used by commands like
"git diff" and "git blame" has been optimized to avoid loading the same
blob repeatedly.
* We did not allow writing out a blob that is larger than 2GB for no good
reason.
* "git format-patch -o $dir", when $dir is a relative directory, used it
as relative to the root of the work tree, not relative to the current
directory.
* v1.6.1 introduced an optimization for "git push" into a repository (A)
that borrows its objects from another repository (B) to avoid sending
objects that are available in repository B, when they are not yet used
by repository A. However the code on the "git push" sender side was
buggy and did not work when repository B had new objects that are not
known by the sender. This caused pushing into a "forked" repository
served by v1.6.1 software using "git push" from v1.6.1 sometimes did not
work. The bug was purely on the "git push" sender side, and has been
corrected.
* "git status -v" did not paint its diff output in colour even when
color.ui configuration was set.
* "git ls-tree" learned --full-tree option to help Porcelain scripts that
want to always see the full path regardless of the current working
directory.
* "git grep" incorrectly searched in work tree paths even when they are
marked as assume-unchanged. It now searches in the index entries.
* "git gc" with no grace period needlessly ejected packed but unreachable
objects in their loose form, only to delete them right away.

32
Documentation/RelNotes-1.6.1.3.txt Normal file
View File

@ -0,0 +1,32 @@
GIT v1.6.1.3 Release Notes
==========================
Fixes since v1.6.1.2
--------------------
* "git diff --binary | git apply" pipeline did not work well when
a binary blob is changed to a symbolic link.
* Some combinations of -b/-w/--ignore-space-at-eol to "git diff" did
not work as expected.
* "git grep" did not pass the -I (ignore binary) option when
calling out an external grep program.
* "git log" and friends include HEAD to the set of starting points
when --all is given. This makes a difference when you are not
on any branch.
* "git mv" to move an untracked file to overwrite a tracked
contents misbehaved.
* "git merge -s octopus" with many potential merge bases did not
work correctly.
* RPM binary package installed the html manpages in a wrong place.
Also includes minor documentation fixes and updates.
--
git shortlog --no-merges v1.6.1.2-33-gc789350..

44
Documentation/RelNotes-1.6.1.4.txt Normal file
View File

@ -0,0 +1,44 @@
GIT v1.6.1.4 Release Notes
==========================
Fixes since v1.6.1.3
--------------------
* .gitignore learned to handle backslash as a quoting mechanism for
comment introduction character "#".
This fix was first merged to 1.6.2.1.
* "git fast-export" produced wrong output with some parents missing from
commits, when the history is clock-skewed.
* "git fast-import" sometimes failed to read back objects it just wrote
out and aborted, because it failed to flush stale cached data.
* "git-ls-tree" and "git-diff-tree" used a pathspec correctly when
deciding to descend into a subdirectory but they did not match the
individual paths correctly. This caused pathspecs "abc/d ab" to match
"abc/0" ("abc/d" made them decide to descend into the directory "abc/",
and then "ab" incorrectly matched "abc/0" when it shouldn't).
This fix was first merged to 1.6.2.3.
* import-zips script (in contrib) did not compute the common directory
prefix correctly.
This fix was first merged to 1.6.2.2.
* "git init" segfaulted when given an overlong template location via
the --template= option.
This fix was first merged to 1.6.2.4.
* "git repack" did not error out when necessary object was missing in the
repository.
* git-repack (invoked from git-gc) did not work as nicely as it should in
a repository that borrows objects from neighbours via alternates
mechanism especially when some packs are marked with the ".keep" flag
to prevent them from being repacked.
This fix was first merged to 1.6.2.3.
Also includes minor documentation fixes and updates.
--
git shortlog --no-merges v1.6.1.3..

286
Documentation/RelNotes-1.6.1.txt Normal file
View File

@ -0,0 +1,286 @@
GIT v1.6.1 Release Notes
========================
Updates since v1.6.0
--------------------
When some commands (e.g. "git log", "git diff") spawn pager internally, we
used to make the pager the parent process of the git command that produces
output. This meant that the exit status of the whole thing comes from the
pager, not the underlying git command. We swapped the order of the
processes around and you will see the exit code from the command from now
on.
(subsystems)
* gitk can call out to git-gui to view "git blame" output; git-gui in turn
can run gitk from its blame view.
* Various git-gui updates including updated translations.
* Various gitweb updates from repo.or.cz installation.
* Updates to emacs bindings.
(portability)
* A few test scripts used nonportable "grep" that did not work well on
some platforms, e.g. Solaris.
* Sample pre-auto-gc script has OS X support.
* Makefile has support for (ancient) FreeBSD 4.9.
(performance)
* Many operations that are lstat(3) heavy can be told to pre-execute
necessary lstat(3) in parallel before their main operations, which
potentially gives much improved performance for cold-cache cases or in
environments with weak metadata caching (e.g. NFS).
* The underlying diff machinery to produce textual output has been
optimized, which would result in faster "git blame" processing.
* Most of the test scripts (but not the ones that try to run servers)
can be run in parallel.
* Bash completion of refnames in a repository with massive number of
refs has been optimized.
* Cygwin port uses native stat/lstat implementations when applicable,
which leads to improved performance.
* "git push" pays attention to alternate repositories to avoid sending
unnecessary objects.
* "git svn" can rebuild an out-of-date rev_map file.
(usability, bells and whistles)
* When you mistype a command name, git helpfully suggests what it guesses
you might have meant to say. help.autocorrect configuration can be set
to a non-zero value to accept the suggestion when git can uniquely
guess.
* The packfile machinery hopefully is more robust when dealing with
corrupt packs if redundant objects involved in the corruption are
available elsewhere.
* "git add -N path..." adds the named paths as an empty blob, so that
subsequent "git diff" will show a diff as if they are creation events.
* "git add" gained a built-in synonym for people who want to say "stage
changes" instead of "add contents to the staging area" which amounts
to the same thing.
* "git apply" learned --include=paths option, similar to the existing
--exclude=paths option.
* "git bisect" is careful about a user mistake and suggests testing of
merge base first when good is not a strict ancestor of bad.
* "git bisect skip" can take a range of commits.
* "git blame" re-encodes the commit metainfo to UTF-8 from i18n.commitEncoding
by default.
* "git check-attr --stdin" can check attributes for multiple paths.
* "git checkout --track origin/hack" used to be a syntax error. It now
DWIMs to create a corresponding local branch "hack", i.e. acts as if you
said "git checkout --track -b hack origin/hack".
* "git checkout --ours/--theirs" can be used to check out one side of a
conflicting merge during conflict resolution.
* "git checkout -m" can be used to recreate the initial conflicted state
during conflict resolution.
* "git cherry-pick" can also utilize rerere for conflict resolution.
* "git clone" learned to be verbose with -v
* "git commit --author=$name" can look up author name from existing
commits.
* output from "git commit" has been reworded in a more concise and yet
more informative way.
* "git count-objects" reports the on-disk footprint for packfiles and
their corresponding idx files.
* "git daemon" learned --max-connections=<count> option.
* "git daemon" exports REMOTE_ADDR to record client address, so that
spawned programs can act differently on it.
* "git describe --tags" favours closer lightweight tags than farther
annotated tags now.
* "git diff" learned to mimic --suppress-blank-empty from GNU diff via a
configuration option.
* "git diff" learned to put more sensible hunk headers for Python,
HTML and ObjC contents.
* "git diff" learned to vary the a/ vs b/ prefix depending on what are
being compared, controlled by diff.mnemonicprefix configuration.
* "git diff" learned --dirstat-by-file to count changed files, not number
of lines, when summarizing the global picture.
* "git diff" learned "textconv" filters --- a binary or hard-to-read
contents can be munged into human readable form and the difference
between the results of the conversion can be viewed (obviously this
cannot produce a patch that can be applied, so this is disabled in
format-patch among other things).
* "--cached" option to "git diff has an easier to remember synonym "--staged",
to ask "what is the difference between the given commit and the
contents staged in the index?"
* "git for-each-ref" learned "refname:short" token that gives an
unambiguously abbreviated refname.
* Auto-numbering of the subject lines is the default for "git
format-patch" now.
* "git grep" learned to accept -z similar to GNU grep.
* "git help" learned to use GIT_MAN_VIEWER environment variable before
using "man" program.
* "git imap-send" can optionally talk SSL.
* "git index-pack" is more careful against disk corruption while
completing a thin pack.
* "git log --check" and "git log --exit-code" passes their underlying diff
status with their exit status code.
* "git log" learned --simplify-merges, a milder variant of --full-history;
"gitk --simplify-merges" is easier to view than with --full-history.
* "git log" learned "--source" to show what ref each commit was reached
from.
* "git log" also learned "--simplify-by-decoration" to show the
birds-eye-view of the topology of the history.
* "git log --pretty=format:" learned "%d" format element that inserts
names of tags that point at the commit.
* "git merge --squash" and "git merge --no-ff" into an unborn branch are
noticed as user errors.
* "git merge -s $strategy" can use a custom built strategy if you have a
command "git-merge-$strategy" on your $PATH.
* "git pull" (and "git fetch") can be told to operate "-v"erbosely or
"-q"uietly.
* "git push" can be told to reject deletion of refs with receive.denyDeletes
configuration.
* "git rebase" honours pre-rebase hook; use --no-verify to bypass it.
* "git rebase -p" uses interactive rebase machinery now to preserve the merges.
* "git reflog expire branch" can be used in place of "git reflog expire
refs/heads/branch".
* "git remote show $remote" lists remote branches one-per-line now.
* "git send-email" can be given revision range instead of files and
maildirs on the command line, and automatically runs format-patch to
generate patches for the given revision range.
* "git submodule foreach" subcommand allows you to iterate over checked
out submodules.
* "git submodule sync" subcommands allows you to update the origin URL
recorded in submodule directories from the toplevel .gitmodules file.
* "git svn branch" can create new branches on the other end.
* "gitweb" can use more saner PATH_INFO based URL.
(internal)
* "git hash-object" learned to lie about the path being hashed, so that
correct gitattributes processing can be done while hashing contents
stored in a temporary file.
* various callers of git-merge-recursive avoid forking it as an external
process.
* Git class defined in "Git.pm" can be subclasses a bit more easily.
* We used to link GNU regex library as a compatibility layer for some
platforms, but it turns out it is not necessary on most of them.
* Some path handling routines used fixed number of buffers used alternately
but depending on the call depth, this arrangement led to hard to track
bugs. This issue is being addressed.
Fixes since v1.6.0
------------------
All of the fixes in v1.6.0.X maintenance series are included in this
release, unless otherwise noted.
* Porcelains implemented as shell scripts were utterly confused when you
entered to a subdirectory of a work tree from sideways, following a
symbolic link (this may need to be backported to older releases later).
* Tracking symbolic links would work better on filesystems whose lstat()
returns incorrect st_size value for them.
* "git add" and "git update-index" incorrectly allowed adding S/F when S
is a tracked symlink that points at a directory D that has a path F in
it (we still need to fix a similar nonsense when S is a submodule and F
is a path in it).
* "git am" after stopping at a broken patch lost --whitespace, -C, -p and
--3way options given from the command line initially.
* "git diff --stdin" used to take two trees on a line and compared them,
but we dropped support for such a use case long time ago. This has
been resurrected.
* "git filter-branch" failed to rewrite a tag name with slashes in it.
* "git http-push" did not understand URI scheme other than opaquelocktoken
when acquiring a lock from the server (this may need to be backported to
older releases later).
* After "git rebase -p" stopped with conflicts while replaying a merge,
"git rebase --continue" did not work (may need to be backported to older
releases).
* "git revert" records relative to which parent a revert was made when
reverting a merge. Together with new documentation that explains issues
around reverting a merge and merging from the updated branch later, this
hopefully will reduce user confusion (this may need to be backported to
older releases later).
* "git rm --cached" used to allow an empty blob that was added earlier to
be removed without --force, even when the file in the work tree has
since been modified.
* "git push --tags --all $there" failed with generic usage message without
telling saying these two options are incompatible.
* "git log --author/--committer" match used to potentially match the
timestamp part, exposing internal implementation detail. Also these did
not work with --fixed-strings match at all.
* "gitweb" did not mark non-ASCII characters imported from external HTML fragments
correctly.
--
exec >/var/tmp/1
O=v1.6.1-rc3-74-gf66bc5f
echo O=$(git describe master)
git shortlog --no-merges $O..master ^maint

19
Documentation/RelNotes-1.6.2.1.txt Normal file
View File

@ -0,0 +1,19 @@
GIT v1.6.2.1 Release Notes
==========================
Fixes since v1.6.2
------------------
* .gitignore learned to handle backslash as a quoting mechanism for
comment introduction character "#".
* timestamp output in --date=relative mode used to display timestamps that
are long time ago in the default mode; it now uses "N years M months
ago", and "N years ago".
* git-add -i/-p now works with non-ASCII pathnames.
* "git hash-object -w" did not read from the configuration file from the
correct .git directory.
* git-send-email learned to correctly handle multiple Cc: addresses.

45
Documentation/RelNotes-1.6.2.2.txt Normal file
View File

@ -0,0 +1,45 @@
GIT v1.6.2.2 Release Notes
==========================
Fixes since v1.6.2.1
--------------------
* A longstanding confusing description of what --pickaxe option of
git-diff does has been clarified in the documentation.
* "git-blame -S" did not quite work near the commits that were given
on the command line correctly.
* "git diff --pickaxe-regexp" did not count overlapping matches
correctly.
* "git diff" did not feed files in work-tree representation to external
diff and textconv.
* "git-fetch" in a repository that was not cloned from anywhere said
it cannot find 'origin', which was hard to understand for new people.
* "git-format-patch --numbered-files --stdout" did not have to die of
incompatible options; it now simply ignores --numbered-files as no files
are produced anyway.
* "git-ls-files --deleted" did not work well with GIT_DIR&GIT_WORK_TREE.
* "git-read-tree A B C..." without -m option has been broken for a long
time.
* git-send-email ignored --in-reply-to when --no-thread was given.
* 'git-submodule add' did not tolerate extra slashes and ./ in the path it
accepted from the command line; it now is more lenient.
* git-svn misbehaved when the project contained a path that began with
two dashes.
* import-zips script (in contrib) did not compute the common directory
prefix correctly.
* miscompilation of negated enum constants by old gcc (2.9) affected the
codepaths to spawn subprocesses.
Many small documentation updates are included as well.

22
Documentation/RelNotes-1.6.2.3.txt Normal file
View File

@ -0,0 +1,22 @@
GIT v1.6.2.3 Release Notes
==========================
Fixes since v1.6.2.2
--------------------
* Setting an octal mode value to core.sharedrepository configuration to
restrict access to the repository to group members did not work as
advertised.
* A fairly large and trivial memory leak while rev-list shows list of
reachable objects has been identified and plugged.
* "git-commit --interactive" did not abort when underlying "git-add -i"
signaled a failure.
* git-repack (invoked from git-gc) did not work as nicely as it should in
a repository that borrows objects from neighbours via alternates
mechanism especially when some packs are marked with the ".keep" flag
to prevent them from being repacked.
Many small documentation updates are included as well.

39
Documentation/RelNotes-1.6.2.4.txt Normal file
View File

@ -0,0 +1,39 @@
GIT v1.6.2.4 Release Notes
==========================
Fixes since v1.6.2.3
--------------------
* The configuration parser had a buffer overflow while parsing an overlong
value.
* pruning reflog entries that are unreachable from the tip of the ref
during "git reflog prune" (hence "git gc") was very inefficient.
* "git-add -p" lacked a way to say "q"uit to refuse staging any hunks for
the remaining paths. You had to say "d" and then ^C.
* "git-checkout <tree-ish> <submodule>" did not update the index entry at
the named path; it now does.
* "git-fast-export" choked when seeing a tag that does not point at commit.
* "git init" segfaulted when given an overlong template location via
the --template= option.
* "git-ls-tree" and "git-diff-tree" used a pathspec correctly when
deciding to descend into a subdirectory but they did not match the
individual paths correctly. This caused pathspecs "abc/d ab" to match
"abc/0" ("abc/d" made them decide to descend into the directory "abc/",
and then "ab" incorrectly matched "abc/0" when it shouldn't).
* "git-merge-recursive" was broken when a submodule entry was involved in
a criss-cross merge situation.
Many small documentation updates are included as well.
---
exec >/var/tmp/1
echo O=$(git describe maint)
O=v1.6.2.3-38-g318b847
git shortlog --no-merges $O..maint

21
Documentation/RelNotes-1.6.2.5.txt Normal file
View File

@ -0,0 +1,21 @@
GIT v1.6.2.5 Release Notes
==========================
Fixes since v1.6.2.4
--------------------
* "git apply" mishandled if you fed a git generated patch that renames
file A to B and file B to A at the same time.
* "git diff -c -p" (and "diff --cc") did not expect to see submodule
differences and instead refused to work.
* "git grep -e '('" segfaulted, instead of diagnosing a mismatched
parentheses error.
* "git fetch" generated packs with offset-delta encoding when both ends of
the connection are capable of producing one; this cannot be read by
ancient git and the user should be able to disable this by setting
repack.usedeltabaseoffset configuration to false.

164
Documentation/RelNotes-1.6.2.txt Normal file
View File

@ -0,0 +1,164 @@
GIT v1.6.2 Release Notes
========================
With the next major release, "git push" into a branch that is
currently checked out will be refused by default. You can choose
what should happen upon such a push by setting the configuration
variable receive.denyCurrentBranch in the receiving repository.
To ease the transition plan, the receiving repository of such a
push running this release will issue a big warning when the
configuration variable is missing. Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
for more details on the reason why this change is needed and the
transition plan.
For a similar reason, "git push $there :$killed" to delete the branch
$killed in a remote repository $there, if $killed branch is the current
branch pointed at by its HEAD, gets a large warning. You can choose what
should happen upon such a push by setting the configuration variable
receive.denyDeleteCurrent in the receiving repository.
Updates since v1.6.1
--------------------
(subsystems)
* git-svn updates.
* gitweb updates, including a new patch view and RSS/Atom feed
improvements.
* (contrib/emacs) git.el now has commands for checking out a branch,
creating a branch, cherry-picking and reverting commits; vc-git.el
is not shipped with git anymore (it is part of official Emacs).
(performance)
* pack-objects autodetects the number of CPUs available and uses threaded
version.
(usability, bells and whistles)
* automatic typo correction works on aliases as well
* @{-1} is a way to refer to the last branch you were on. This is
accepted not only where an object name is expected, but anywhere
a branch name is expected and acts as if you typed the branch name.
E.g. "git branch --track mybranch @{-1}", "git merge @{-1}", and
"git rev-parse --symbolic-full-name @{-1}" would work as expected.
* When refs/remotes/origin/HEAD points at a remote tracking branch that
has been pruned away, many git operations issued warning when they
internally enumerated the refs. We now warn only when you say "origin"
to refer to that pruned branch.
* The location of .mailmap file can be configured, and its file format was
enhanced to allow mapping an incorrect e-mail field as well.
* "git add -p" learned 'g'oto action to jump directly to a hunk.
* "git add -p" learned to find a hunk with given text with '/'.
* "git add -p" optionally can be told to work with just the command letter
without Enter.
* when "git am" stops upon a patch that does not apply, it shows the
title of the offending patch.
* "git am --directory=<dir>" and "git am --reject" passes these options
to underlying "git apply".
* "git am" learned --ignore-date option.
* "git blame" aligns author names better when they are spelled in
non US-ASCII encoding.
* "git clone" now makes its best effort when cloning from an empty
repository to set up configuration variables to refer to the remote
repository.
* "git checkout -" is a shorthand for "git checkout @{-1}".
* "git cherry" defaults to whatever the current branch is tracking (if
exists) when the <upstream> argument is not given.
* "git cvsserver" can be told not to add extra "via git-CVS emulator" to
the commit log message it serves via gitcvs.commitmsgannotation
configuration.
* "git cvsserver" learned to handle 'noop' command some CVS clients seem
to expect to work.
* "git diff" learned a new option --inter-hunk-context to coalesce close
hunks together and show context between them.
* The definition of what constitutes a word for "git diff --color-words"
can be customized via gitattributes, command line or a configuration.
* "git diff" learned --patience to run "patience diff" algorithm.
* "git filter-branch" learned --prune-empty option that discards commits
that do not change the contents.
* "git fsck" now checks loose objects in alternate object stores, instead
of misreporting them as missing.
* "git gc --prune" was resurrected to allow "git gc --no-prune" and
giving non-default expiration period e.g. "git gc --prune=now".
* "git grep -w" and "git grep" for fixed strings have been optimized.
* "git mergetool" learned -y(--no-prompt) option to disable prompting.
* "git rebase -i" can transplant a history down to root to elsewhere
with --root option.
* "git reset --merge" is a new mode that works similar to the way
"git checkout" switches branches, taking the local changes while
switching to another commit.
* "git submodule update" learned --no-fetch option.
* "git tag" learned --contains that works the same way as the same option
from "git branch".
Fixes since v1.6.1
------------------
All of the fixes in v1.6.1.X maintenance series are included in this
release, unless otherwise noted.
Here are fixes that this release has, but have not been backported to
v1.6.1.X series.
* "git-add sub/file" when sub is a submodule incorrectly added the path to
the superproject.
* "git bundle" did not exclude annotated tags even when a range given
from the command line wanted to.
* "git filter-branch" unnecessarily refused to work when you had
checked out a different commit from what is recorded in the superproject
index in a submodule.
* "git filter-branch" incorrectly tried to update a nonexistent work tree
at the end when it is run in a bare repository.
* "git gc" did not work if your repository was created with an ancient git
and never had any pack files in it before.
* "git mergetool" used to ignore autocrlf and other attributes
based content rewriting.
* branch switching and merges had a silly bug that did not validate
the correct directory when making sure an existing subdirectory is
clean.
* "git -p cmd" when cmd is not a built-in one left the display in funny state
when killed in the middle.

10
Documentation/RelNotes-1.6.3.1.txt Normal file
View File

@ -0,0 +1,10 @@
GIT v1.6.3.1 Release Notes
==========================
Fixes since v1.6.3
------------------
* "git checkout -b new-branch" with a staged change in the index
incorrectly primed the in-index cache-tree, resulting a wrong tree
object to be written out of the index. This is a grave regression
since the last 1.6.2.X maintenance release.

61
Documentation/RelNotes-1.6.3.2.txt Normal file
View File

@ -0,0 +1,61 @@
GIT v1.6.3.2 Release Notes
==========================
Fixes since v1.6.3.1
--------------------
* A few codepaths picked up the first few bytes from an sha1[] by
casting the (char *) pointer to (int *); GCC 4.4 did not like this,
and aborted compilation.
* Some unlink(2) failures went undiagnosed.
* The "recursive" merge strategy misbehaved when faced rename/delete
conflicts while coming up with an intermediate merge base.
* The low-level merge algorithm did not handle a degenerate case of
merging a file with itself using itself as the common ancestor
gracefully. It should produce the file itself, but instead
produced an empty result.
* GIT_TRACE mechanism segfaulted when tracing a shell-quoted aliases.
* OpenBSD also uses st_ctimspec in "struct stat", instead of "st_ctim".
* With NO_CROSS_DIRECTORY_HARDLINKS, "make install" can be told not to
create hardlinks between $(gitexecdir)/git-$builtin_commands and
$(bindir)/git.
* command completion code in bash did not reliably detect that we are
in a bare repository.
* "git add ." in an empty directory complained that pathspec "." did not
match anything, which may be technically correct, but not useful. We
silently make it a no-op now.
* "git add -p" (and "patch" action in "git add -i") was broken when
the first hunk that adds a line at the top was split into two and
both halves are marked to be used.
* "git blame path" misbehaved at the commit where path became file
from a directory with some files in it.
* "git for-each-ref" had a segfaulting bug when dealing with a tag object
created by an ancient git.
* "git format-patch -k" still added patch numbers if format.numbered
configuration was set.
* "git grep --color ''" did not terminate. The command also had
subtle bugs with its -w option.
* http-push had a small use-after-free bug.
* "git push" was converting OFS_DELTA pack representation into less
efficient REF_DELTA representation unconditionally upon transfer,
making the transferred data unnecessarily larger.
* "git remote show origin" segfaulted when origin was still empty.
Many other general usability updates around help text, diagnostic messages
and documentation are included as well.

38
Documentation/RelNotes-1.6.3.3.txt Normal file
View File

@ -0,0 +1,38 @@
GIT v1.6.3.3 Release Notes
==========================
Fixes since v1.6.3.2
--------------------
* "git archive" running on Cygwin can get stuck in an infinite loop.
* "git daemon" did not correctly parse the initial line that carries
virtual host request information.
* "git diff --textconv" leaked memory badly when the textconv filter
errored out.
* The built-in regular expressions to pick function names to put on
hunk header lines for java and objc were very inefficiently written.
* in certain error situations git-fetch (and git-clone) on Windows didn't
detect connection abort and ended up waiting indefinitely.
* import-tars script (in contrib) did not import symbolic links correctly.
* http.c used CURLOPT_SSLKEY even on libcURL version 7.9.2, even though
it was only available starting 7.9.3.
* low-level filelevel merge driver used return value from strdup()
without checking if we ran out of memory.
* "git rebase -i" left stray closing parenthesis in its reflog message.
* "git remote show" did not show all the URLs associated with the named
remote, even though "git remote -v" did. Made them consistent by
making the former show all URLs.
* "whitespace" attribute that is set was meant to detect all errors known
to git, but it told git to ignore trailing carriage-returns.
Includes other documentation fixes.

36
Documentation/RelNotes-1.6.3.4.txt Normal file
View File

@ -0,0 +1,36 @@
GIT v1.6.3.4 Release Notes
==========================
Fixes since v1.6.3.3
--------------------
* "git add --no-ignore-errors" did not override configured
add.ignore-errors configuration.
* "git apply --whitespace=fix" did not fix trailing whitespace on an
incomplete line.
* "git branch" opened too many commit objects unnecessarily.
* "git checkout -f $commit" with a path that is a file (or a symlink) in
the work tree to a commit that has a directory at the path issued an
unnecessary error message.
* "git diff -c/--cc" was very inefficient in coalescing the removed lines
shared between parents.
* "git diff -c/--cc" showed removed lines at the beginning of a file
incorrectly.
* "git remote show nickname" did not honor configured
remote.nickname.uploadpack when inspecting the branches at the remote.
* "git request-pull" when talking to the terminal for a preview
showed some of the output in the pager.
* "git request-pull start nickname [end]" did not honor configured
remote.nickname.uploadpack when it ran git-ls-remote against the remote
repository to learn the current tip of branches.
Includes other documentation updates and minor fixes.

182
Documentation/RelNotes-1.6.3.txt Normal file
View File

@ -0,0 +1,182 @@
GIT v1.6.3 Release Notes
========================
With the next major release, "git push" into a branch that is
currently checked out will be refused by default. You can choose
what should happen upon such a push by setting the configuration
variable receive.denyCurrentBranch in the receiving repository.
To ease the transition plan, the receiving repository of such a
push running this release will issue a big warning when the
configuration variable is missing. Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
for more details on the reason why this change is needed and the
transition plan.
For a similar reason, "git push $there :$killed" to delete the branch
$killed in a remote repository $there, if $killed branch is the current
branch pointed at by its HEAD, gets a large warning. You can choose what
should happen upon such a push by setting the configuration variable
receive.denyDeleteCurrent in the receiving repository.
When the user does not tell "git push" what to push, it has always
pushed matching refs. For some people it is unexpected, and a new
configuration variable push.default has been introduced to allow
changing a different default behaviour. To advertise the new feature,
a big warning is issued if this is not configured and a git push without
arguments is attempted.
Updates since v1.6.2
--------------------
(subsystems)
* various git-svn updates.
* git-gui updates, including an update to Russian translation, and a
fix to an infinite loop when showing an empty diff.
* gitk updates, including an update to Russian translation and improved Windows
support.
(performance)
* many uses of lstat(2) in the codepath for "git checkout" have been
optimized out.
(usability, bells and whistles)
* Boolean configuration variable yes/no can be written as on/off.
* rsync:/path/to/repo can be used to run git over rsync for local
repositories. It may not be useful in practice; meant primarily for
testing.
* http transport learned to prompt and use password when fetching from or
pushing to http://user@host.xz/ URL.
* (msysgit) progress output that is sent over the sideband protocol can
be handled appropriately in Windows console.
* "--pretty=<style>" option to the log family of commands can now be
spelled as "--format=<style>". In addition, --format=%formatstring
is a short-hand for --pretty=tformat:%formatstring.
* "--oneline" is a synonym for "--pretty=oneline --abbrev-commit".
* "--graph" to the "git log" family can draw the commit ancestry graph
in colors.
* If you realize that you botched the patch when you are editing hunks
with the 'edit' action in git-add -i/-p, you can abort the editor to
tell git not to apply it.
* @{-1} is a new way to refer to the last branch you were on introduced in
1.6.2, but the initial implementation did not teach this to a few
commands. Now the syntax works with "branch -m @{-1} newname".
* git-archive learned --output=<file> option.
* git-archive takes attributes from the tree being archived; strictly
speaking, this is an incompatible behaviour change, but is a good one.
Use --worktree-attributes option to allow it to read attributes from
the work tree as before (deprecated git-tar tree command always reads
attributes from the work tree).
* git-bisect shows not just the number of remaining commits whose goodness
is unknown, but also shows the estimated number of remaining rounds.
* You can give --date=<format> option to git-blame.
* "git-branch -r" shows HEAD symref that points at a remote branch in
interest of each tracked remote repository.
* "git-branch -v -v" is a new way to get list of names for branches and the
"upstream" branch for them.
* git-config learned -e option to open an editor to edit the config file
directly.
* git-clone runs post-checkout hook when run without --no-checkout.
* git-difftool is now part of the officially supported command, primarily
maintained by David Aguilar.
* git-for-each-ref learned a new "upstream" token.
* git-format-patch can be told to use attachment with a new configuration,
format.attach.
* git-format-patch can be told to produce deep or shallow message threads.
* git-format-patch can be told to always add sign-off with a configuration
variable.
* git-format-patch learned format.headers configuration to add extra
header fields to the output. This behaviour is similar to the existing
--add-header=<header> option of the command.
* git-format-patch gives human readable names to the attached files, when
told to send patches as attachments.
* git-grep learned to highlight the found substrings in color.
* git-imap-send learned to work around Thunderbird's inability to easily
disable format=flowed with a new configuration, imap.preformattedHTML.
* git-rebase can be told to rebase the series even if your branch is a
descendant of the commit you are rebasing onto with --force-rebase
option.
* git-rebase can be told to report diffstat with the --stat option.
* Output from git-remote command has been vastly improved.
* "git remote update --prune $remote" updates from the named remote and
then prunes stale tracking branches.
* git-send-email learned --confirm option to review the Cc: list before
sending the messages out.
(developers)
* Test scripts can be run under valgrind.
* Test scripts can be run with installed git.
* Makefile learned 'coverage' option to run the test suites with
coverage tracking enabled.
* Building the manpages with docbook-xsl between 1.69.1 and 1.71.1 now
requires setting DOCBOOK_SUPPRESS_SP to work around a docbook-xsl bug.
This workaround used to be enabled by default, but causes problems
with newer versions of docbook-xsl. In addition, there are a few more
knobs you can tweak to work around issues with various versions of the
docbook-xsl package. See comments in Documentation/Makefile for details.
* Support for building and testing a subset of git on a system without a
working perl has been improved.
Fixes since v1.6.2
------------------
All of the fixes in v1.6.2.X maintenance series are included in this
release, unless otherwise noted.
Here are fixes that this release has, but have not been backported to
v1.6.2.X series.
* "git-apply" rejected a patch that swaps two files (i.e. renames A to B
and B to A at the same time). May need to be backported by cherry
picking d8c81df and then 7fac0ee).
* The initial checkout did not read the attributes from the .gitattribute
file that is being checked out.
* git-gc spent excessive amount of time to decide if an object appears
in a locally existing pack (if needed, backport by merging 69e020a).

46
Documentation/RelNotes-1.6.4.1.txt Normal file
View File

@ -0,0 +1,46 @@
GIT v1.6.4.1 Release Notes
==========================
Fixes since v1.6.4
------------------
* An unquoted value in the configuration file, when it contains more than
one whitespaces in a row, got them replaced with a single space.
* "git am" used to accept a single piece of e-mail per file (not a mbox)
as its input, but multiple input format support in v1.6.4 broke it.
Apparently many people have been depending on this feature.
* The short help text for "git filter-branch" command was a single long
line, wrapped by terminals, and was hard to read.
* The "recursive" strategy of "git merge" segfaulted when a merge has
more than one merge-bases, and merging of these merge-bases involves
a rename/rename or a rename/add conflict.
* "git pull --rebase" did not use the right fork point when the
repository has already fetched from the upstream that rewinds the
branch it is based on in an earlier fetch.
* Explain the concept of fast-forward more fully in "git push"
documentation, and hint to refer to it from an error message when the
command refuses an update to protect the user.
* The default value for pack.deltacachesize, used by "git repack", is now
256M, instead of unbounded. Otherwise a repack of a moderately sized
repository would needlessly eat into swap.
* Document how "git repack" (hence "git gc") interacts with a repository
that borrows its objects from other repositories (e.g. ones created by
"git clone -s").
* "git show" on an annotated tag lacked a delimiting blank line between
the tag itself and the contents of the object it tags.
* "git verify-pack -v" erroneously reported number of objects with too
deep delta depths as "chain length 0" objects.
* Long names of authors and committers outside US-ASCII were sometimes
incorrectly shown in "gitweb".
Other minor documentation updates are included.

32
Documentation/RelNotes-1.6.4.2.txt Normal file
View File

@ -0,0 +1,32 @@
GIT v1.6.4.2 Release Notes
==========================
Fixes since v1.6.4.1
--------------------
* --date=relative output between 1 and 5 years ago rounded the number of
years when saying X years Y months ago, instead of rounding it down.
* "git add -p" did not handle changes in executable bits correctly
(a regression around 1.6.3).
* "git apply" did not honor GNU diff's convention to mark the creation/deletion
event with UNIX epoch timestamp on missing side.
* "git checkout" incorrectly removed files in a directory pointed by a
symbolic link during a branch switch that replaces a directory with
a symbolic link.
* "git clean -d -f" happily descended into a subdirectory that is managed by a
separate git repository. It now requires two -f options for safety.
* "git fetch/push" over http transports had two rather grave bugs.
* "git format-patch --cover-letter" did not prepare the cover letter file
for use with non-ASCII strings when there are the series contributors with
non-ASCII names.
* "git pull origin branch" and "git fetch origin && git merge origin/branch"
left different merge messages in the resulting commit.
Other minor documentation updates are included.

29
Documentation/RelNotes-1.6.4.3.txt Normal file
View File

@ -0,0 +1,29 @@
GIT v1.6.4.3 Release Notes
==========================
Fixes since v1.6.4.2
--------------------
* "git clone" from an empty repository gave unnecessary error message,
even though it did everything else correctly.
* "git cvsserver" invoked git commands via "git-foo" style, which has long
been deprecated.
* "git fetch" and "git clone" had an extra sanity check to verify the
presense of the corresponding *.pack file before downloading *.idx
file by issuing a HEAD request. Github server however sometimes
gave 500 (Internal server error) response to HEAD even if a GET
request for *.pack file to the same URL would have succeeded, and broke
clone over HTTP from some of their repositories. As a workaround, this
verification has been removed (as it is not absolutely necessary).
* "git grep" did not like relative pathname to refer outside the current
directory when run from a subdirectory.
* an error message from "git push" was formatted in a very ugly way.
* "git svn" did not quote the subversion user name correctly when
running its author-prog helper program.
Other minor documentation updates are included.

26
Documentation/RelNotes-1.6.4.4.txt Normal file
View File

@ -0,0 +1,26 @@
GIT v1.6.4.4 Release Notes
==========================
Fixes since v1.6.4.4
--------------------
* The workaround for Github server that sometimes gave 500 (Internal server
error) response to HEAD requests in 1.6.4.3 introduced a regression that
caused re-fetching projects over http to segfault in certain cases due
to uninitialized pointer being freed.
* "git pull" on an unborn branch used to consider anything in the work
tree and the index discardable.
* "git diff -b/w" did not work well on the incomplete line at the end of
the file, due to an incorrect hashing of lines in the low-level xdiff
routines.
* "git checkout-index --prefix=$somewhere" used to work when $somewhere is
a symbolic link to a directory elsewhere, but v1.6.4.2 broke it.
* "git unpack-objects --strict", invoked when receive.fsckobjects
configuration is set in the receiving repository of "git push", did not
properly check the objects, especially the submodule links, it received.
Other minor documentation updates are included.

147
Documentation/RelNotes-1.6.4.txt Normal file
View File

@ -0,0 +1,147 @@
GIT v1.6.4 Release Notes
========================
With the next major release, "git push" into a branch that is
currently checked out will be refused by default. You can choose
what should happen upon such a push by setting the configuration
variable receive.denyCurrentBranch in the receiving repository.
To ease the transition plan, the receiving repository of such a
push running this release will issue a big warning when the
configuration variable is missing. Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
for more details on the reason why this change is needed and the
transition plan.
For a similar reason, "git push $there :$killed" to delete the branch
$killed in a remote repository $there, if $killed branch is the current
branch pointed at by its HEAD, gets a large warning. You can choose what
should happen upon such a push by setting the configuration variable
receive.denyDeleteCurrent in the receiving repository.
Updates since v1.6.3
--------------------
(subsystems)
* gitweb Perl style clean-up.
* git-svn updates, including a new --authors-prog option to map author
names by invoking an external program, 'git svn reset' to unwind
'git svn fetch', support for more than one branches, documenting
of the useful --minimize-url feature, new "git svn gc" command, etc.
(portability)
* We feed iconv with "UTF-8" instead of "utf8"; the former is
understood more widely. Similarly updated test scripts to use
encoding names more widely understood (e.g. use "ISO8859-1" instead
of "ISO-8859-1").
* Various portability fixes/workarounds for different vintages of
SunOS, IRIX, and Windows.
* Git-over-ssh transport on Windows supports PuTTY plink and TortoisePlink.
(performance)
* Many repeated use of lstat() are optimized out in "checkout" codepath.
* git-status (and underlying git-diff-index --cached) are optimized
to take advantage of cache-tree information in the index.
(usability, bells and whistles)
* "git add --edit" lets users edit the whole patch text to fine-tune what
is added to the index.
* "git am" accepts StGIT series file as its input.
* "git bisect skip" skips to a more randomly chosen place in the hope
to avoid testing a commit that is too close to a commit that is
already known to be untestable.
* "git cvsexportcommit" learned -k option to stop CVS keywords expansion
* "git fast-export" learned to handle history simplification more
gracefully.
* "git fast-export" learned an option --tag-of-filtered-object to handle
dangling tags resulting from history simplification more usefully.
* "git grep" learned -p option to show the location of the match using the
same context hunk marker "git diff" uses.
* https transport can optionally be told that the used client
certificate is password protected, in which case it asks the
password only once.
* "git imap-send" is IPv6 aware.
* "git log --graph" draws graphs more compactly by using horizontal lines
when able.
* "git log --decorate" shows shorter refnames by stripping well-known
refs/* prefix.
* "git push $name" honors remote.$name.pushurl if present before
using remote.$name.url. In other words, the URL used for fetching
and pushing can be different.
* "git send-email" understands quoted aliases in .mailrc files (might
have to be backported to 1.6.3.X).
* "git send-email" can fetch the sender address from the configuration
variable "sendmail.from" (and "sendmail.<identity>.from").
* "git show-branch" can color its output.
* "add" and "update" subcommands to "git submodule" learned --reference
option to use local clone with references.
* "git submodule update" learned --rebase option to update checked
out submodules by rebasing the local changes.
* "gitweb" can optionally use gravatar to adorn author/committer names.
(developers)
* A major part of the "git bisect" wrapper has moved to C.
* Formatting with the new version of AsciiDoc 8.4.1 is now supported.
Fixes since v1.6.3
------------------
All of the fixes in v1.6.3.X maintenance series are included in this
release, unless otherwise noted.
Here are fixes that this release has, but have not been backported to
v1.6.3.X series.
* "git diff-tree -r -t" used to omit new or removed directories from
the output. df533f3 (diff-tree -r -t: include added/removed
directories in the output, 2009-06-13) may need to be cherry-picked
to backport this fix.
* The way Git.pm sets up a Repository object was not friendly to callers
that chdir around. It now internally records the repository location
as an absolute path when autodetected.
* Removing a section with "git config --remove-section", when its
section header has a variable definition on the same line, lost
that variable definition.
* "git rebase -p --onto" used to always leave side branches of a merge
intact, even when both branches are subject to rewriting.
* "git repack" used to faithfully follow grafts and considered true
parents recorded in the commit object unreachable from the commit.
After such a repacking, you cannot remove grafts without corrupting
the repository.
* "git send-email" did not detect erroneous loops in alias expansion.

20
Documentation/RelNotes-1.6.5.1.txt Normal file
View File

@ -0,0 +1,20 @@
GIT v1.6.5.1 Release Notes
==========================
Fixes since v1.6.5
------------------
* An corrupt pack could make codepath to read objects into an
infinite loop.
* Download throughput display was always shown in KiB/s but on fast links
it is more appropriate to show it in MiB/s.
* "git grep -f filename" used uninitialized variable and segfaulted.
* "git clone -b branch" gave a wrong commit object name to post-checkout
hook.
* "git pull" over http did not work on msys.
Other minor documentation updates are included.

19
Documentation/RelNotes-1.6.5.2.txt Normal file
View File

@ -0,0 +1,19 @@
GIT v1.6.5.2 Release Notes
==========================
Fixes since v1.6.5.1
--------------------
* Installation of templates triggered a bug in busybox when using tar
implementation from it.
* "git add -i" incorrectly ignored paths that are already in the index
if they matched .gitignore patterns.
* "git describe --always" should have produced some output even there
were no tags in the repository, but it didn't.
* "git ls-files" when showing tracked files incorrectly paid attention
to the exclude patterns.
Other minor documentation updates are included.

63
Documentation/RelNotes-1.6.5.3.txt Normal file
View File

@ -0,0 +1,63 @@
Git v1.6.5.3 Release Notes
==========================
Fixes since v1.6.5.2
--------------------
* info/grafts file didn't ignore trailing CR at the end of lines.
* Packages generated on newer FC were unreadable by older versions of
RPM as the new default is to use stronger hash.
* output from "git blame" was unreadable when the file ended in an
incomplete line.
* "git add -i/-p" didn't handle deletion of empty files correctly.
* "git clone" takes up to two parameters, but did not complain when
given more arguments than necessary and silently ignored them.
* "git cvsimport" did not read files given as command line arguments
correctly when it is run from a subdirectory.
* "git diff --color-words -U0" didn't work correctly.
* The handling of blank lines at the end of file by "git diff/apply
--whitespace" was inconsistent with the other kinds of errors.
They are now colored, warned against, and fixed the same way as others.
* There was no way to allow blank lines at the end of file without
allowing extra blanks at the end of lines. You can use blank-at-eof
and blank-at-eol whitespace error class to specify them separately.
The old trailing-space error class is now a short-hand to set both.
* "-p" option to "git format-patch" was supposed to suppress diffstat
generation, but it was broken since 1.6.1.
* "git imap-send" did not compile cleanly with newer OpenSSL.
* "git help -a" outside of a git repository was broken.
* "git ls-files -i" was supposed to be inverse of "git ls-files" without -i
with respect to exclude patterns, but it was broken since 1.6.5.2.
* "git ls-remote" outside of a git repository over http was broken.
* "git rebase -i" gave bogus error message when the command word was
misspelled.
* "git receive-pack" that is run in response to "git push" did not run
garbage collection nor update-server-info, but in larger hosting sites,
these almost always need to be run. To help site administrators, the
command now runs "gc --auto" and "u-s-i" by setting receive.autogc
and receive.updateserverinfo configuration variables, respectively.
* Release notes spelled the package name with incorrect capitalization.
* "gitweb" did not escape non-ascii characters correctly in the URL.
* "gitweb" showed "patch" link even for merge commits.
* "gitweb" showed incorrect links for blob line numbers in pathinfo mode.
Other minor documentation updates are included.

32
Documentation/RelNotes-1.6.5.4.txt Normal file
View File

@ -0,0 +1,32 @@
Git v1.6.5.4 Release Notes
==========================
Fixes since v1.6.5.3
--------------------
* "git help" (without argument) used to check if you are in a directory
under git control. There was no breakage in behaviour per-se, but this
was unnecessary.
* "git prune-packed" gave progress output even when its standard error is
not connected to a terminal; this caused cron jobs that run it to
produce crufts.
* "git pack-objects --all-progress" is an option to ask progress output
from write-object phase _if_ progress output were to be produced, and
shouldn't have forced the progress output.
* "git apply -p<n> --directory=<elsewhere>" did not work well for a
non-default value of n.
* "git merge foo HEAD" was misparsed as an old-style invocation of the
command and produced a confusing error message. As it does not specify
any other branch to merge, it shouldn't be mistaken as such. We will
remove the old style "git merge <message> HEAD <commit>..." syntax in
future versions, but not in this release,
* "git merge -m <message> <branch>..." added the standard merge message
on its own after user-supplied message, which should have overrided the
standard one.
Other minor documentation updates are included.

49
Documentation/RelNotes-1.6.5.5.txt Normal file
View File

@ -0,0 +1,49 @@
Git v1.6.5.5 Release Notes
==========================
Fixes since v1.6.5.4
--------------------
* Manual pages can be formatted with older xmlto again.
* GREP_OPTIONS exported from user's environment could have broken
our scripted commands.
* In configuration files, a few variables that name paths can begin with
~/ and ~username/ and they are expanded as expected. This is not a
bugfix but 1.6.6 will have this and without backporting users cannot
easily use the same ~/.gitconfig across versions.
* "git diff -B -M" did the same computation to hash lines of contents
twice, and held onto memory after it has used the data in it
unnecessarily before it freed.
* "git diff -B" and "git diff --dirstat" was not counting newly added
contents correctly.
* "git format-patch revisions... -- path" issued an incorrect error
message that suggested to use "--" on the command line when path
does not exist in the current work tree (it is a separate matter if
it makes sense to limit format-patch with pathspecs like that
without using the --full-diff option).
* "git grep -F -i StRiNg" did not work as expected.
* Enumeration of available merge strategies iterated over the list of
commands in a wrong way, sometimes producing an incorrect result.
* "git shortlog" did not honor the "encoding" header embedded in the
commit object like "git log" did.
* Reading progress messages that come from the remote side while running
"git pull" is given precedence over reading the actual pack data to
prevent garbled progress message on the user's terminal.
* "git rebase" got confused when the log message began with certain
strings that looked like Subject:, Date: or From: header.
* "git reset" accidentally run in .git/ directory checked out the
work tree contents in there.
Other minor documentation updates are included.

23
Documentation/RelNotes-1.6.5.6.txt Normal file
View File

@ -0,0 +1,23 @@
Git v1.6.5.6 Release Notes
==========================
Fixes since v1.6.5.5
--------------------
* "git add -p" had a regression since v1.6.5.3 that broke deletion of
non-empty files.
* "git archive -o o.zip -- Makefile" produced an archive in o.zip
but in POSIX tar format.
* Error message given to "git pull --rebase" when the user didn't give
enough clue as to what branch to integrate with still talked about
"merging with" the branch.
* Error messages given by "git merge" when the merge resulted in a
fast-forward still were in plumbing lingo, even though in v1.6.5
we reworded messages in other cases.
* The post-upload-hook run by upload-pack in response to "git fetch" has
been removed, due to security concerns (the hook first appeared in
1.6.5).

19
Documentation/RelNotes-1.6.5.7.txt Normal file
View File

@ -0,0 +1,19 @@
Git v1.6.5.7 Release Notes
==========================
Fixes since v1.6.5.6
--------------------
* If a user specifies a color for a <slot> (i.e. a class of things to show
in a particular color) that is known only by newer versions of git
(e.g. "color.diff.func" was recently added for upcoming 1.6.6 release),
an older version of git should just ignore them. Instead we diagnosed
it as an error.
* With help.autocorrect set to non-zero value, the logic to guess typoes
in the subcommand name misfired and ran a random nonsense command.
* If a command is run with an absolute path as a pathspec inside a bare
repository, e.g. "rev-list HEAD -- /home", the code tried to run
strlen() on NULL, which is the result of get_git_work_tree(), and
segfaulted.

28
Documentation/RelNotes-1.6.5.8.txt Normal file
View File

@ -0,0 +1,28 @@
Git v1.6.5.8 Release Notes
==========================
Fixes since v1.6.5.7
--------------------
* "git count-objects" did not handle packfiles that are bigger than 4G on
platforms with 32-bit off_t.
* "git rebase -i" did not abort cleanly if it failed to launch the editor.
* "git blame" did not work well when commit lacked the author name.
* "git fast-import" choked when handling a tag that points at an object
that is not a commit.
* "git reset --hard" did not work correctly when GIT_WORK_TREE environment
variable is used to point at the root of the true work tree.
* "git grep" fed a buffer that is not NUL-terminated to underlying
regexec().
* "git checkout -m other" while on a branch that does not have any commit
segfaulted, instead of failing.
* "git branch -a other" should have diagnosed the command as an error.
Other minor documentation updates are also included.

169
Documentation/RelNotes-1.6.5.txt Normal file
View File

@ -0,0 +1,169 @@
GIT v1.6.5 Release Notes
========================
In git 1.7.0, which was planned to be the release after 1.6.5, "git
push" into a branch that is currently checked out will be refused by
default.
You can choose what should happen upon such a push by setting the
configuration variable receive.denyCurrentBranch in the receiving
repository.
Also, "git push $there :$killed" to delete the branch $killed in a remote
repository $there, when $killed branch is the current branch pointed at by
its HEAD, will be refused by default.
You can choose what should happen upon such a push by setting the
configuration variable receive.denyDeleteCurrent in the receiving
repository.
To ease the transition plan, the receiving repository of such a
push running this release will issue a big warning when the
configuration variable is missing. Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
for more details on the reason why this change is needed and the
transition plan.
Updates since v1.6.4
--------------------
(subsystems)
* various updates to gitk, git-svn and gitweb.
(portability)
* more improvements on mingw port.
* mingw will also give FRSX as the default value for the LESS
environment variable when the user does not have one.
* initial support to compile git on Windows with MSVC.
(performance)
* On major platforms, the system can be compiled to use with Linus's
block-sha1 implementation of the SHA-1 hash algorithm, which
outperforms the default fallback implementation we borrowed from
Mozilla.
* Unnecessary inefficiency in deepening of a shallow repository has
been removed.
* "git clone" does not grab objects that it does not need (i.e.
referenced only from refs outside refs/heads and refs/tags
hierarchy) anymore.
* The "git" main binary used to link with libcurl, which then dragged
in a large number of external libraries. When using basic plumbing
commands in scripts, this unnecessarily slowed things down. We now
implement http/https/ftp transfer as a separate executable as we
used to.
* "git clone" run locally hardlinks or copies the files in .git/ to
newly created repository. It used to give new mtime to copied files,
but this delayed garbage collection to trigger unnecessarily in the
cloned repository. We now preserve mtime for these files to avoid
this issue.
(usability, bells and whistles)
* Human writable date format to various options, e.g. --since=yesterday,
master@{2000.09.17}, are taught to infer some omitted input properly.
* A few programs gave verbose "advice" messages to help uninitiated
people when issuing error messages. An infrastructure to allow
users to squelch them has been introduced, and a few such messages
can be silenced now.
* refs/replace/ hierarchy is designed to be usable as a replacement
of the "grafts" mechanism, with the added advantage that it can be
transferred across repositories.
* "git am" learned to optionally ignore whitespace differences.
* "git am" handles input e-mail files that has CRLF line endings sensibly.
* "git am" learned "--scissors" option to allow you to discard early part
of an incoming e-mail.
* "git archive -o output.zip" works without being told what format to
use with an explicit "--format=zip".option.
* "git checkout", "git reset" and "git stash" learned to pick and
choose to use selected changes you made, similar to "git add -p".
* "git clone" learned a "-b" option to pick a HEAD to check out
different from the remote's default branch.
* "git clone" learned --recursive option.
* "git clone" from a local repository on a different filesystem used to
copy individual object files without preserving the old timestamp, giving
them extra lifetime in the new repository until they gc'ed.
* "git commit --dry-run $args" is a new recommended way to ask "what would
happen if I try to commit with these arguments."
* "git commit --dry-run" and "git status" shows conflicted paths in a
separate section to make them easier to spot during a merge.
* "git cvsimport" now supports password-protected pserver access even
when the password is not taken from ~/.cvspass file.
* "git fast-export" learned --no-data option that can be useful when
reordering commits and trees without touching the contents of
blobs.
* "git fast-import" has a pair of new front-end in contrib/ area.
* "git init" learned to mkdir/chdir into a directory when given an
extra argument (i.e. "git init this").
* "git instaweb" optionally can use mongoose as the web server.
* "git log --decorate" can optionally be told with --decorate=full to
give the reference name in full.
* "git merge" issued an unnecessarily scary message when it detected
that the merge may have to touch the path that the user has local
uncommitted changes to. The message has been reworded to make it
clear that the command aborted, without doing any harm.
* "git push" can be told to be --quiet.
* "git push" pays attention to url.$base.pushInsteadOf and uses a URL
that is derived from the URL used for fetching.
* informational output from "git reset" that lists the locally modified
paths is made consistent with that of "git checkout $another_branch".
* "git submodule" learned to give submodule name to scripts run with
"foreach" subcommand.
* various subcommands to "git submodule" learned --recursive option.
* "git submodule summary" learned --files option to compare the work
tree vs the commit bound at submodule path, instead of comparing
the index.
* "git upload-pack", which is the server side support for "git clone" and
"git fetch", can call a new post-upload-pack hook for statistics purposes.
(developers)
* With GIT_TEST_OPTS="--root=/p/a/t/h", tests can be run outside the
source directory; using tmpfs may give faster turnaround.
* With NO_PERL_MAKEMAKER set, DESTDIR= is now honoured, so you can
build for one location, and install into another location to tar it
up.
Fixes since v1.6.4
------------------
All of the fixes in v1.6.4.X maintenance series are included in this
release, unless otherwise noted.

37
Documentation/RelNotes-1.6.6.1.txt Normal file
View File

@ -0,0 +1,37 @@
Git v1.6.6.1 Release Notes
==========================
Fixes since v1.6.6
------------------
* "git blame" did not work well when commit lacked the author name.
* "git branch -a name" wasn't diagnosed as an error.
* "git count-objects" did not handle packfiles that are bigger than 4G on
platforms with 32-bit off_t.
* "git checkout -m other" while on a branch that does not have any commit
segfaulted, instead of failing.
* "git fast-import" choked when fed a tag that do not point at a
commit.
* "git grep" finding from work tree files could have fed garbage to
the underlying regexec(3).
* "git grep -L" didn't show empty files (they should never match, and
they should always appear in -L output as unmatching).
* "git rebase -i" did not abort cleanly if it failed to launch the editor.
* "git reset --hard" did not work correctly when GIT_WORK_TREE environment
variable is used to point at the root of the true work tree.
* http-backend was not listed in the command list in the documentation.
* Building on FreeBSD (both 7 and 8) needs OLD_ICONV set in the Makefile
* "git checkout -m some-branch" while on an unborn branch crashed.
Other minor documentation updates are included.

46
Documentation/RelNotes-1.6.6.2.txt Normal file
View File

@ -0,0 +1,46 @@
Git v1.6.6.2 Release Notes
==========================
Fixes since v1.6.6.1
--------------------
* recursive merge didn't correctly diagnose its own programming errors,
and instead caused the caller to segfault.
* The new "smart http" aware clients probed the web servers to see if
they support smart http, but did not fall back to dumb http transport
correctly with some servers.
* Time based reflog syntax e.g. "@{yesterday}" didn't diagnose a misspelled
time specification and instead assumed "@{now}".
* "git archive HEAD -- no-such-directory" produced an empty archive
without complaining.
* "git blame -L start,end -- file" misbehaved when given a start that is
larger than the number of lines in the file.
* "git checkout -m" didn't correctly call custom merge backend supplied
by the end user.
* "git config -f <file>" misbehaved when run from a subdirectory.
* "git cvsserver" didn't like having regex metacharacters (e.g. '+') in
CVSROOT environment.
* "git fast-import" did not correctly handle large blobs that may
bust the pack size limit.
* "git gui" is supposed to work even when launched from inside a .git
directory.
* "git gui" misbehaved when applying a hunk that ends with deletion.
* "git imap-send" did not honor imap.preformattedHTML as documented.
* "git log" family incorrectly showed the commit notes unconditionally by
mistake, which was especially irritating when running "git log --oneline".
* "git status" shouldn't require an write access to the repository.
Other minor documentation updates are included.

224
Documentation/RelNotes-1.6.6.txt Normal file
View File

@ -0,0 +1,224 @@
Git v1.6.6 Release Notes
========================
Notes on behaviour change
-------------------------
* In this release, "git fsck" defaults to "git fsck --full" and
checks packfiles, and because of this it will take much longer to
complete than before. If you prefer a quicker check only on loose
objects (the old default), you can say "git fsck --no-full". This
has been supported by 1.5.4 and newer versions of git, so it is
safe to write it in your script even if you use slightly older git
on some of your machines.
Preparing yourselves for compatibility issues in 1.7.0
------------------------------------------------------
In git 1.7.0, which is planned to be the release after 1.6.6, there will
be a handful of behaviour changes that will break backward compatibility.
These changes were discussed long time ago and existing behaviours have
been identified as more problematic to the userbase than keeping them for
the sake of backward compatibility.
When necessary, a transition strategy for existing users has been designed
not to force them running around setting configuration variables and
updating their scripts in order to either keep the traditional behaviour
or adjust to the new behaviour, on the day their sysadmin decides to install
the new version of git. When we switched from "git-foo" to "git foo" in
1.6.0, even though the change had been advertised and the transition
guide had been provided for a very long time, the users procrastinated
during the entire transtion period, and ended up panicking on the day
their sysadmins updated their git installation. We are trying to avoid
repeating that unpleasantness in the 1.7.0 release.
For changes decided to be in 1.7.0, commands that will be affected
have been much louder to strongly discourage such procrastination, and
they continue to be in this release. If you have been using recent
versions of git, you would have seen warnings issued when you used
features whose behaviour will change, with a clear instruction on how
to keep the existing behaviour if you want to. You hopefully are
already well prepared.
Of course, we have also been giving "this and that will change in
1.7.0; prepare yourselves" warnings in the release notes and
announcement messages for the past few releases. Let's see how well
users will fare this time.
* "git push" into a branch that is currently checked out (i.e. pointed by
HEAD in a repository that is not bare) will be refused by default.
Similarly, "git push $there :$killed" to delete the branch $killed
in a remote repository $there, when $killed branch is the current
branch pointed at by its HEAD, will be refused by default.
Setting the configuration variables receive.denyCurrentBranch and
receive.denyDeleteCurrent to 'ignore' in the receiving repository
can be used to override these safety features. Versions of git
since 1.6.2 have issued a loud warning when you tried to do these
operations without setting the configuration, so repositories of
people who still need to be able to perform such a push should
already have been future proofed.
Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
for more details on the reason why this change is needed and the
transition process that already took place so far.
* "git send-email" will not make deep threads by default when sending a
patch series with more than two messages. All messages will be sent
as a reply to the first message, i.e. cover letter. Git 1.6.6 (this
release) will issue a warning about the upcoming default change, when
it uses the traditional "deep threading" behaviour as the built-in
default. To squelch the warning but still use the "deep threading"
behaviour, give --chain-reply-to option or set sendemail.chainreplyto
to true.
It has been possible to configure send-email to send "shallow thread"
by setting sendemail.chainreplyto configuration variable to false.
The only thing 1.7.0 release will do is to change the default when
you haven't configured that variable.
* "git status" will not be "git commit --dry-run". This change does not
affect you if you run the command without pathspec.
Nobody sane found the current behaviour of "git status Makefile" useful
nor meaningful, and it confused users. "git commit --dry-run" has been
provided as a way to get the current behaviour of this command since
1.6.5.
* "git diff" traditionally treated various "ignore whitespace" options
only as a way to filter the patch output. "git diff --exit-code -b"
exited with non-zero status even if all changes were about changing the
ammount of whitespace and nothing else. and "git diff -b" showed the
"diff --git" header line for such a change without patch text.
In 1.7.0, the "ignore whitespaces" will affect the semantics of the
diff operation itself. A change that does not affect anything but
whitespaces will be reported with zero exit status when run with
--exit-code, and there will not be "diff --git" header for such a
change.
Updates since v1.6.5
--------------------
(subsystems)
* various gitk updates including use of themed widgets under Tk 8.5,
Japanese translation, a fix to a bug when running "gui blame" from
a subdirectory, etc.
* various git-gui updates including new translations, wm states fixes,
Tk bug workaround after quitting, improved heuristics to trigger gc,
etc.
* various git-svn updates.
* "git fetch" over http learned a new mode that is different from the
traditional "dumb commit walker".
(portability)
* imap-send can be built on mingw port.
(performance)
* "git diff -B" has smaller memory footprint.
(usability, bells and whistles)
* The object replace mechanism can be bypassed with --no-replace-objects
global option given to the "git" program.
* In configuration files, a few variables that name paths can begin with ~/
and ~username/ and they are expanded as expected.
* "git subcmd -h" now shows short usage help for many more subcommands.
* "git bisect reset" can reset to an arbitrary commit.
* "git checkout frotz" when there is no local branch "frotz" but there
is only one remote tracking branch "frotz" is taken as a request to
start the named branch at the corresponding remote tracking branch.
* "git commit -c/-C/--amend" can be told with a new "--reset-author" option
to ignore authorship information in the commit it is taking the message
from.
* "git describe" can be told to add "-dirty" suffix with "--dirty" option.
* "git diff" learned --submodule option to show a list of one-line logs
instead of differences between the commit object names.
* "git diff" learned to honor diff.color.func configuration to paint
function name hint printed on the hunk header "@@ -j,k +l,m @@" line
in the specified color.
* "git fetch" learned --all and --multiple options, to run fetch from
many repositories, and --prune option to remove remote tracking
branches that went stale. These make "git remote update" and "git
remote prune" less necessary (there is no plan to remove "remote
update" nor "remote prune", though).
* "git fsck" by default checks the packfiles (i.e. "--full" is the
default); you can turn it off with "git fsck --no-full".
* "git grep" can use -F (fixed strings) and -i (ignore case) together.
* import-tars contributed fast-import frontend learned more types of
compressed tarballs.
* "git instaweb" knows how to talk with mod_cgid to apache2.
* "git log --decorate" shows the location of HEAD as well.
* "git log" and "git rev-list" learned to take revs and pathspecs from
the standard input with the new "--stdin" option.
* "--pretty=format" option to "log" family of commands learned:
. to wrap text with the "%w()" specifier.
. to show reflog information with "%g[sdD]" specifier.
* "git notes" command to annotate existing commits.
* "git merge" (and "git pull") learned --ff-only option to make it fail
if the merge does not result in a fast-forward.
* "git mergetool" learned to use p4merge.
* "git rebase -i" learned "reword" that acts like "edit" but immediately
starts an editor to tweak the log message without returning control to
the shell, which is done by "edit" to give an opportunity to tweak the
contents.
* "git send-email" can be told with "--envelope-sender=auto" to use the
same address as "From:" address as the envelope sender address.
* "git send-email" will issue a warning when it defaults to the
--chain-reply-to behaviour without being told by the user and
instructs to prepare for the change of the default in 1.7.0 release.
* In "git submodule add <repository> <path>", <path> is now optional and
inferred from <repository> the same way "git clone <repository>" does.
* "git svn" learned to read SVN 1.5+ and SVK merge tickets.
* "git svn" learned to recreate empty directories tracked only by SVN.
* "gitweb" can optionally render its "blame" output incrementally (this
requires JavaScript on the client side).
* Author names shown in gitweb output are links to search commits by the
author.
Fixes since v1.6.5
------------------
All of the fixes in v1.6.5.X maintenance series are included in this
release, unless otherwise noted.

214
Documentation/RelNotes-1.7.0.txt Normal file
View File

@ -0,0 +1,214 @@
Git v1.7.0 Release Notes
========================
Notes on behaviour change
-------------------------
* "git push" into a branch that is currently checked out (i.e. pointed at by
HEAD in a repository that is not bare) is refused by default.
Similarly, "git push $there :$killed" to delete the branch $killed
in a remote repository $there, when $killed branch is the current
branch pointed at by its HEAD, will be refused by default.
Setting the configuration variables receive.denyCurrentBranch and
receive.denyDeleteCurrent to 'ignore' in the receiving repository
can be used to override these safety features.
* "git send-email" does not make deep threads by default when sending a
patch series with more than two messages. All messages will be sent
as a reply to the first message, i.e. cover letter.
It has been possible already to configure send-email to send "shallow thread"
by setting sendemail.chainreplyto configuration variable to false. The
only thing this release does is to change the default when you haven't
configured that variable.
* "git status" is not "git commit --dry-run" anymore. This change does
not affect you if you run the command without argument.
* "git diff" traditionally treated various "ignore whitespace" options
only as a way to filter the patch output. "git diff --exit-code -b"
exited with non-zero status even if all changes were about changing the
amount of whitespace and nothing else; and "git diff -b" showed the
"diff --git" header line for such a change without patch text.
In this release, the "ignore whitespaces" options affect the semantics
of the diff operation. A change that does not affect anything but
whitespaces is reported with zero exit status when run with
--exit-code, and there is no "diff --git" header for such a change.
* External diff and textconv helpers are now executed using the shell.
This makes them consistent with other programs executed by git, and
allows you to pass command-line parameters to the helpers. Any helper
paths containing spaces or other metacharacters now need to be
shell-quoted. The affected helpers are GIT_EXTERNAL_DIFF in the
environment, and diff.*.command and diff.*.textconv in the config
file.
* The --max-pack-size argument to 'git repack', 'git pack-objects', and
'git fast-import' was assuming the provided size to be expressed in MiB,
unlike the corresponding config variable and other similar options accepting
a size value. It is now expecting a size expressed in bytes, with a possible
unit suffix of 'k', 'm', or 'g'.
Updates since v1.6.6
--------------------
(subsystems)
* "git fast-import" updates; adds "option" and "feature" to detect the
mismatch between fast-import and the frontends that produce the input
stream.
* "git svn" support of subversion "merge tickets" and miscellaneous fixes.
* "gitk" and "git gui" translation updates.
* "gitweb" updates (code clean-up, load checking etc.)
(portability)
* Some more MSVC portability patches for msysgit port.
* Minimum Pthreads emulation for msysgit port.
(performance)
* More performance improvement patches for msysgit port.
(usability, bells and whistles)
* More commands learned "--quiet" and "--[no-]progress" options.
* Various commands given by the end user (e.g. diff.type.textconv,
and GIT_EDITOR) can be specified with command line arguments. E.g. it
is now possible to say "[diff "utf8doc"] textconv = nkf -w".
* "sparse checkout" feature allows only part of the work tree to be
checked out.
* HTTP transfer can use authentication scheme other than basic
(i.e./e.g. digest).
* Switching from a version of superproject that used to have a submodule
to another version of superproject that no longer has it did not remove
the submodule directory when it should (namely, when you are not
interested in the submodule at all and didn't clone/checkout).
* A new attribute conflict-marker-size can be used to change the size of
the conflict markers from the default 7; this is useful when tracked
contents (e.g. git-merge documentation) have strings that resemble the
conflict markers.
* A new syntax "<branch>@{upstream}" can be used on the command line to
substitute the name of the "upstream" of the branch. Missing branch
defaults to the current branch, so "git fetch && git merge @{upstream}"
will be equivalent to "git pull".
* "git am --resolved" has a synonym "git am --continue".
* "git branch --set-upstream" can be used to update the (surprise!) upstream,
i.e. where the branch is supposed to pull and merge from (or rebase onto).
* "git checkout A...B" is a way to detach HEAD at the merge base between
A and B.
* "git checkout -m path" to reset the work tree file back into the
conflicted state works even when you already ran "git add path" and
resolved the conflicts.
* "git commit --date='<date>'" can be used to override the author date
just like "git commit --author='<name> <email>'" can be used to
override the author identity.
* "git commit --no-status" can be used to omit the listing of the index
and the work tree status in the editor used to prepare the log message.
* "git commit" warns a bit more aggressively until you configure user.email,
whose default value almost always is not (and fundamentally cannot be)
what you want.
* "git difftool" has been extended to make it easier to integrate it
with gitk.
* "git fetch --all" can now be used in place of "git remote update".
* "git grep" does not rely on external grep anymore. It can use more than
one thread to accelerate the operation.
* "git grep" learned "--quiet" option.
* "git log" and friends learned "--glob=heads/*" syntax that is a more
flexible way to complement "--branches/--tags/--remotes".
* "git merge" learned to pass options specific to strategy-backends. E.g.
- "git merge -Xsubtree=path/to/directory" can be used to tell the subtree
strategy how much to shift the trees explicitly.
- "git merge -Xtheirs" can be used to auto-merge as much as possible,
while discarding your own changes and taking merged version in
conflicted regions.
* "git push" learned "git push origin --delete branch", a syntactic sugar
for "git push origin :branch".
* "git push" learned "git push --set-upstream origin forker:forkee" that
lets you configure your "forker" branch to later pull from "forkee"
branch at "origin".
* "git rebase --onto A...B" means the history is replayed on top of the
merge base between A and B.
* "git rebase -i" learned new action "fixup" that squashes the change
but does not affect existing log message.
* "git rebase -i" also learned --autosquash option that is useful
together with the new "fixup" action.
* "git remote" learned set-url subcommand that updates (surprise!) url
for an existing remote nickname.
* "git rerere" learned "forget path" subcommand. Together with "git
checkout -m path" it will be useful when you recorded a wrong
resolution.
* Use of "git reset --merge" has become easier when resetting away a
conflicted mess left in the work tree.
* "git rerere" had rerere.autoupdate configuration but there was no way
to countermand it from the command line; --no-rerere-autoupdate option
given to "merge", "revert", etc. fixes this.
* "git status" learned "-s(hort)" output format.
(developers)
* The infrastructure to build foreign SCM interface has been updated.
* Many more commands are now built-in.
* THREADED_DELTA_SEARCH is no more. If you build with threads, delta
compression will always take advantage of it.
Fixes since v1.6.6
------------------
All of the fixes in v1.6.6.X maintenance series are included in this
release, unless otherwise noted.
* "git branch -d branch" used to refuse deleting the branch even when
the branch is fully merged to its upstream branch if it is not merged
to the current branch. It now deletes it in such a case.
* "fiter-branch" command incorrectly said --prune-empty and --filter-commit
were incompatible; the latter should be read as --commit-filter.
* When using "git status" or asking "git diff" to compare the work tree
with something, they used to consider that a checked-out submodule with
uncommitted changes is not modified; this could cause people to forget
committing these changes in the submodule before committing in the
superproject. They now consider such a change as a modification and
"git diff" will append a "-dirty" to the work tree side when generating
patch output or when used with the --submodule option.

97
Documentation/SubmittingPatches
View File

@ -6,9 +6,13 @@ Checklist (and a short version for the impatient):
- check for unnecessary whitespace with "git diff --check"
before committing
- do not check in commented out code or unneeded files
- provide a meaningful commit message
- the first line of the commit message should be a short
description and should skip the full stop
- the body should provide a meaningful commit message, which:
- uses the imperative, present tense: "change",
not "changed" or "changes".
- includes motivation for the change, and contrasts
its implementation with previous behaviour
- if you want your work included in git.git, add a
"Signed-off-by: Your Name <you@example.com>" line to the
commit message (or just use the option "-s" when
@ -62,6 +66,14 @@ Describe the technical detail of the change(s).
If your description starts to get too long, that's a sign that you
probably need to split up your commit to finer grained pieces.
That being said, patches which plainly describe the things that
help reviewers check the patch, and future maintainers understand
the code, are the most beautiful patches. Descriptions that summarise
the point in the subject well, and describe the motivation for the
change, the approach taken by the change, and if relevant how this
differs substantially from the prior version, can be found on Usenet
archives back into the late 80's. Consider it like good Netiquette,
but for code.
Oh, another thing. I am picky about whitespaces. Make sure your
changes do not trigger errors with the sample pre-commit hook shipped
@ -71,7 +83,7 @@ run git diff --check on your changes before you commit.
(1a) Try to be nice to older C compilers
We try to support wide range of C compilers to compile
We try to support a wide range of C compilers to compile
git with. That means that you should not use C99 initializers, even
if a lot of compilers grok it.
@ -222,6 +234,9 @@ 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).
Also notice that a real name is used in the Signed-off-by: line. Please
don't hide your real name.
Some people also put extra tags at the end.
"Acked-by:" says that the patch was reviewed by the person who
@ -264,6 +279,20 @@ 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.
------------------------------------------------
Know the status of your patch after submission
* You can use Git itself to find out when your patch is merged in
master. 'git pull --rebase' will automatically skip already-applied
patches, and will let you know. This works only if you rebase on top
of the branch in which your patch has been merged (i.e. it will not
tell you if your patch is merged in pu if you rebase on top of
master).
* Read the git mailing list, the maintainer regularly posts messages
entitled "What's cooking in git.git" and "What's in git.git" giving
the status of various proposed changes.
------------------------------------------------
MUA specific hints
@ -373,9 +402,36 @@ Thunderbird
(A Large Angry SCM)
By default, Thunderbird will both wrap emails as well as flag them as
being 'format=flowed', both of which will make the resulting email unusable
by git.
Here are some hints on how to successfully submit patches inline using
Thunderbird.
There are two different approaches. One approach is to configure
Thunderbird to not mangle patches. The second approach is to use
an external editor to keep Thunderbird from mangling the patches.
Approach #1 (configuration):
This recipe is current as of Thunderbird 2.0.0.19. Three steps:
1. Configure your mail server composition as plain text
Edit...Account Settings...Composition & Addressing,
uncheck 'Compose Messages in HTML'.
2. Configure your general composition window to not wrap
Edit..Preferences..Composition, wrap plain text messages at 0
3. Disable the use of format=flowed
Edit..Preferences..Advanced..Config Editor. Search for:
mailnews.send_plaintext_flowed
toggle it to make sure it is set to 'false'.
After that is done, you should be able to compose email as you
otherwise would (cut + paste, git-format-patch | git-imap-send, etc),
and the patches should not be mangled.
Approach #2 (external editor):
This recipe appears to work with the current [*1*] Thunderbird from Suse.
The following Thunderbird extensions are needed:
@ -456,3 +512,40 @@ This should help you to submit patches inline using KMail.
5) Back in the compose window: add whatever other text you wish to the
message, complete the addressing and subject fields, and press send.
Gmail
-----
GMail does not appear to have any way to turn off line wrapping in the web
interface, so this will mangle any emails that you send. You can however
use any IMAP email client to connect to the google imap server, and forward
the emails through that. Just make sure to disable line wrapping in that
email client. Alternatively, use "git send-email" instead.
Submitting properly formatted patches via Gmail is simple now that
IMAP support is available. First, edit your ~/.gitconfig to specify your
account settings:
[imap]
folder = "[Gmail]/Drafts"
host = imaps://imap.gmail.com
user = user@gmail.com
pass = p4ssw0rd
port = 993
sslverify = false
You might need to instead use: folder = "[Google Mail]/Drafts" if you get an error
that the "Folder doesn't exist".
Next, ensure that your Gmail settings are correct. In "Settings" the
"Use Unicode (UTF-8) encoding for outgoing messages" should be checked.
Once your commits are ready to send to the mailing list, run the following
command to send the patch emails to your Gmail Drafts folder.
$ git format-patch -M --stdout origin/master | git imap-send
Go to your Gmail account, open the Drafts folder, find the patch email, fill
in the To: and CC: fields and send away!

29
Documentation/asciidoc.conf
View File

@ -7,6 +7,9 @@
# Show GIT link as: <command>(<section>); if section is defined, else just show
# the command.
[macros]
(?su)[\\]?(?P<name>linkgit):(?P<target>\S*?)\[(?P<attrlist>.*?)\]=
[attributes]
asterisk=&#42;
plus=&#43;
@ -14,6 +17,7 @@ caret=&#94;
startsb=&#91;
endsb=&#93;
tilde=&#126;
backtick=&#96;
ifdef::backend-docbook[]
[linkgit-inlinemacro]
@ -24,7 +28,7 @@ ifdef::backend-docbook[]
endif::backend-docbook[]
ifdef::backend-docbook[]
ifndef::docbook-xsl-172[]
ifndef::git-asciidoc-no-roff[]
# "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]
@ -39,7 +43,28 @@ ifdef::doctype-manpage[]
endif::doctype-manpage[]
</literallayout>
{title#}</example>
endif::docbook-xsl-172[]
endif::git-asciidoc-no-roff[]
ifdef::git-asciidoc-no-roff[]
ifdef::doctype-manpage[]
# The following two small workarounds insert a simple paragraph after screen
[listingblock]
<example><title>{title}</title>
<literallayout>
|
</literallayout><simpara></simpara>
{title#}</example>
[verseblock]
<formalpara{id? id="{id}"}><title>{title}</title><para>
{title%}<literallayout{id? id="{id}"}>
{title#}<literallayout>
|
</literallayout>
{title#}</para></formalpara>
{title%}<simpara></simpara>
endif::doctype-manpage[]
endif::git-asciidoc-no-roff[]
endif::backend-docbook[]
ifdef::doctype-manpage[]

32
Documentation/blame-options.txt
View File

@ -39,7 +39,14 @@ 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 linkgit:git-rev-list[1].
Use revisions from revs-file instead of calling linkgit:git-rev-list[1].
--reverse::
Walk history forward instead of backward. Instead of showing
the revision in which a line appeared, this shows the last
revision in which a line has existed. This requires a range of
revision like START..END where the path to blame exists in
START.
-p::
--porcelain::
@ -49,6 +56,13 @@ of lines before or after the line given by <start>.
Show the result incrementally in a format designed for
machine consumption.
--encoding=<encoding>::
Specifies the encoding used to output author names
and commit summaries. Setting it to `none` makes blame
output unconverted data. For more information see the
discussion about encoding in the linkgit:git-log[1]
manual page.
--contents <file>::
When <rev> is not specified, the command annotates the
changes starting backwards from the working tree copy.
@ -56,11 +70,19 @@ of lines before or after the line given by <start>.
tree copy has the contents of the named file (specify
`-` to make the command read from the standard input).
--date <format>::
The value is one of the following alternatives:
{relative,local,default,iso,rfc,short}. If --date is not
provided, the value of the blame.date config variable is
used. If the blame.date config variable is also not set, the
iso format is used. For more information, See the discussion
of the --date option at linkgit:git-log[1].
-M|<num>|::
Detect moving lines in the file as well. When a commit
moves a block of lines in a file (e.g. the original file
has A and then B, and the commit changes it to B and
then A), traditional 'blame' algorithm typically blames
then A), the traditional 'blame' algorithm typically blames
the lines that were moved up (i.e. B) to the parent and
assigns blame to the lines that were moved down (i.e. A)
to the child commit. With this option, both groups of lines
@ -76,8 +98,10 @@ commit.
files that were modified in the same commit. This is
useful when you reorganize your program and move code
around across files. When this option is given twice,
the command looks for copies from all other files in the
parent for the commit that creates the file in addition.
the command additionally looks for copies from other
files in the commit that creates the file. When this
option is given three times, the command additionally
looks for copies from other files in any commit.
+
<num> is optional but it is the lower bound on the number of
alphanumeric characters that git must detect as moving

30
Documentation/callouts.xsl
View File

@ -1,30 +0,0 @@
<!-- callout.xsl: converts asciidoc callouts to man page format -->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="co">
<xsl:value-of select="concat('\fB(',substring-after(@id,'-'),')\fR')"/>
</xsl:template>
<xsl:template match="calloutlist">
<xsl:text>.sp&#10;</xsl:text>
<xsl:apply-templates/>
<xsl:text>&#10;</xsl:text>
</xsl:template>
<xsl:template match="callout">
<xsl:value-of select="concat('\fB',substring-after(@arearefs,'-'),'. \fR')"/>
<xsl:apply-templates/>
<xsl:text>.br&#10;</xsl:text>
</xsl:template>
<!-- sorry, this is not about callouts, but attempts to work around
spurious .sp at the tail of the line docbook stylesheets seem to add -->
<xsl:template match="simpara">
<xsl:variable name="content">
<xsl:apply-templates/>
</xsl:variable>
<xsl:value-of select="normalize-space($content)"/>
<xsl:if test="not(ancestor::authorblurb) and
not(ancestor::personblurb)">
<xsl:text>&#10;&#10;</xsl:text>
</xsl:if>
</xsl:template>
</xsl:stylesheet>

8
Documentation/cat-texi.perl
View File

@ -18,8 +18,12 @@ close TMP;
printf '\input texinfo
@setfilename gitman.info
@documentencoding us-ascii
@node Top,,%s
@documentencoding UTF-8
@dircategory Development
@direntry
* Git Man Pages: (gitman). Manual pages for Git revision control system
@end direntry
@node Top,,, (dir)
@top Git Manual Pages
@documentlanguage en
@menu

841
Documentation/config.txt
View File

File diff suppressed because it is too large Load Diff

26
Documentation/date-formats.txt Normal file
View File

@ -0,0 +1,26 @@
DATE FORMATS
------------
The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables
ifdef::git-commit[]
and the `--date` option
endif::git-commit[]
support the following date formats:
Git internal format::
It is `<unix timestamp> <timezone offset>`, where `<unix
timestamp>` is the number of seconds since the UNIX epoch.
`<timezone offset>` is a positive or negative offset from UTC.
For example CET (which is 2 hours ahead UTC) is `+0200`.
RFC 2822::
The standard email format as described by RFC 2822, for example
`Thu, 07 Apr 2005 22:13:13 +0200`.
ISO 8601::
Time and date specified by the ISO 8601 standard, for example
`2005-04-07T22:13:13`. The parser accepts a space instead of the
`T` character as well.
+
NOTE: In addition, the date part is accepted in the following formats:
`YYYY.MM.DD`, `MM/DD/YYYY` and `DD.MM.YYYY`.

24
Documentation/diff-format.txt
View File

@ -1,4 +1,7 @@
The output format from "git-diff-index", "git-diff-tree",
Raw output format
-----------------
The raw 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
@ -16,6 +19,9 @@ git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]::
git-diff-files [<pattern>...]::
compares the index and the files on the filesystem.
The "git-diff-tree" command begins its output by printing the hash of
what is being compared. After that, all the commands print one output
line per changed file.
An output line is formatted this way:
@ -46,6 +52,22 @@ That is, from the left to the right:
. path for "dst"; only exists for C or R.
. an LF or a NUL when '-z' option is used, to terminate the record.
Possible status letters are:
- A: addition of a file
- C: copy of a file into a new one
- D: deletion of a file
- M: modification of the contents or mode of a file
- R: renaming of a file
- T: change in the type of the file
- U: file is unmerged (you must complete the merge before it can
be committed)
- X: "unknown" change type (most probably a bug, please report it)
Status letters C and R are always followed by a score (denoting the
percentage of similarity between the source and target of the move or
copy), and are the only ones to be so.
<sha1> is shown as all 0's if a file is new on the filesystem
and it is out of sync with the index.

6
Documentation/diff-generate-patch.txt
View File

@ -143,15 +143,15 @@ 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,
in the column N means that the line appears in the result,
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 ` +`).
in either file1 nor file2). Also eight other lines are the same
from file1 but do not appear in file2 (hence prefixed with `{plus}`).
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

150
Documentation/diff-options.txt
View File

@ -14,70 +14,94 @@ endif::git-format-patch[]
ifdef::git-format-patch[]
-p::
Generate patches without diffstat.
--no-stat::
Generate plain patches without any diffstats.
endif::git-format-patch[]
ifndef::git-format-patch[]
-p::
-u::
Generate patch (see section on generating patches).
{git-diff? This is the default.}
endif::git-format-patch[]
-u::
Synonym for "-p".
-U<n>::
Shorthand for "--unified=<n>".
--unified=<n>::
Generate diffs with <n> lines of context instead of
the usual three. Implies "-p".
the usual three.
ifndef::git-format-patch[]
Implies `-p`.
endif::git-format-patch[]
ifndef::git-format-patch[]
--raw::
Generate the raw format.
{git-diff-core? This is the default.}
endif::git-format-patch[]
ifndef::git-format-patch[]
--patch-with-raw::
Synonym for "-p --raw".
Synonym for `-p --raw`.
endif::git-format-patch[]
--patience::
Generate a diff using the "patience diff" algorithm.
--stat[=width[,name-width]]::
Generate a diffstat. You can override the default
output width for 80-column terminal by "--stat=width".
output width for 80-column terminal by `--stat=width`.
The width of the filename part can be controlled by
giving another width to it separated by a comma.
--numstat::
Similar to \--stat, but shows number of added and
Similar to `\--stat`, but shows number of added and
deleted lines in decimal notation and pathname without
abbreviation, to make it more machine friendly. For
binary files, outputs two `-` instead of saying
`0 0`.
--shortstat::
Output only the last line of the --stat format containing total
Output only the last line of the `--stat` format containing total
number of modified files, as well as number of added and deleted
lines.
--dirstat[=limit]::
Output only the sub-directories that are impacted by a diff,
and to what degree they are impacted. You can override the
default cut-off in percent (3) by "--dirstat=limit". If you
want to enable "cumulative" directory statistics, you can use
the "--cumulative" flag, which adds up percentages recursively
even when they have been already reported for a sub-directory.
Output the distribution of relative amount of changes (number of lines added or
removed) for each sub-directory. Directories with changes below
a cut-off percent (3% by default) are not shown. The cut-off percent
can be set with `--dirstat=limit`. Changes in a child directory is not
counted for the parent directory, unless `--cumulative` is used.
--dirstat-by-file[=limit]::
Same as `--dirstat`, but counts changed files instead of lines.
--summary::
Output a condensed summary of extended header information
such as creations, renames and mode changes.
ifndef::git-format-patch[]
--patch-with-stat::
Synonym for "-p --stat".
{git-format-patch? This is the default.}
Synonym for `-p --stat`.
endif::git-format-patch[]
ifndef::git-format-patch[]
-z::
NUL-line termination on output. This affects the --raw
output field terminator. Also output from commands such
as "git-log" will be delimited with NUL between commits.
ifdef::git-log[]
Separate the commits with NULs instead of with new newlines.
+
Also, when `--raw` or `--numstat` has been given, do not munge
pathnames and use NULs as output field terminators.
endif::git-log[]
ifndef::git-log[]
When `--raw` or `--numstat` has been given, do not munge
pathnames and use NULs as output field terminators.
endif::git-log[]
+
Without this option, each pathname output will have TAB, LF, double quotes,
and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`,
respectively, and the pathname will be enclosed in double quotes if
any of those replacements occurred.
--name-only::
Show only names of changed files.
@ -86,6 +110,13 @@ endif::git-format-patch[]
Show only names and status of changed files. See the description
of the `--diff-filter` option on what the status letters mean.
--submodule[=<format>]::
Chose the output format for submodule differences. <format> can be one of
'short' and 'log'. 'short' just shows pairs of commit names, this format
is used when this option is not given. 'log' is the default value for this
option and lists the commits in that commit range like the 'summary'
option of linkgit:git-submodule[1] does.
--color::
Show colored diff.
@ -93,35 +124,52 @@ endif::git-format-patch[]
Turn off colored diff, even when the configuration file
gives the default to color output.
--color-words::
Show colored word diff, i.e. color words which have changed.
--color-words[=<regex>]::
Show colored word diff, i.e., color words which have changed.
By default, words are separated by whitespace.
+
When a <regex> is specified, every non-overlapping match of the
<regex> is considered a word. Anything between these matches is
considered whitespace and ignored(!) for the purposes of finding
differences. You may want to append `|[^[:space:]]` to your regular
expression to make sure that it matches all non-whitespace characters.
A match that contains a newline is silently truncated(!) at the
newline.
+
The regex can also be set via a diff driver or configuration option, see
linkgit:gitattributes[1] or linkgit:git-config[1]. Giving it explicitly
overrides any diff driver or configuration setting. Diff drivers
override configuration settings.
endif::git-format-patch[]
--no-renames::
Turn off rename detection, even when the configuration
file gives the default to do so.
ifndef::git-format-patch[]
--check::
Warn if changes introduce trailing whitespace
or an indent that uses a space before a tab. Exits with
non-zero status if problems are found. Not compatible with
--exit-code.
endif::git-format-patch[]
--full-index::
Instead of the first handful characters, show full
object name of pre- and post-image blob on the "index"
line when generating a patch format output.
Instead of the first handful of characters, show the full
pre- and post-image blob object names on the "index"
line when generating patch format output.
--binary::
In addition to --full-index, output "binary diff" that
can be applied with "git apply".
In addition to `--full-index`, output a binary diff that
can be applied with `git-apply`.
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
name in diff-raw format output and diff-tree header
lines, show only handful hexdigits prefix. This is
independent of --full-index option above, which controls
lines, show only a partial prefix. This is
independent of the `--full-index` option above, which controls
the diff-patch output format. Non default number of
digits can be specified with --abbrev=<n>.
digits can be specified with `--abbrev=<n>`.
-B::
Break complete rewrite changes into pairs of delete and create.
@ -132,16 +180,19 @@ endif::git-format-patch[]
-C::
Detect copies as well as renames. See also `--find-copies-harder`.
ifndef::git-format-patch[]
--diff-filter=[ACDMRTUXB*]::
Select only files that are Added (`A`), Copied (`C`),
Deleted (`D`), Modified (`M`), Renamed (`R`), have their
type (mode) changed (`T`), are Unmerged (`U`), are
type (i.e. regular file, symlink, submodule, ...) changed (`T`),
are Unmerged (`U`), are
Unknown (`X`), or have had their pairing Broken (`B`).
Any combination of the filter characters may be used.
When `*` (All-or-none) is added to the combination, all
paths are selected if there is any file that matches
other criteria in the comparison; if there is no file
that matches other criteria, nothing is selected.
endif::git-format-patch[]
--find-copies-harder::
For performance reasons, by default, `-C` option finds copies only
@ -153,28 +204,34 @@ endif::git-format-patch[]
`-C` option has the same effect.
-l<num>::
-M and -C options require O(n^2) processing time where n
The `-M` and `-C` options require O(n^2) processing time where n
is the number of potential rename/copy targets. This
option prevents rename/copy detection from running if
the number of rename/copy targets exceeds the specified
number.
ifndef::git-format-patch[]
-S<string>::
Look for differences that contain the change in <string>.
Look for differences that introduce or remove an instance of
<string>. Note that this is different than the string simply
appearing in diff output; see the 'pickaxe' entry in
linkgit:gitdiffcore[7] for more details.
--pickaxe-all::
When -S finds a change, show all the changes in that
When `-S` finds a change, show all the changes in that
changeset, not just the files that contain the change
in <string>.
--pickaxe-regex::
Make the <string> not a plain string but an extended POSIX
regex to match.
endif::git-format-patch[]
-O<orderfile>::
Output the patch in the order specified in the
<orderfile>, which has one shell glob pattern per line.
ifndef::git-format-patch[]
-R::
Swap two inputs; that is, show differences from index or
on-disk file to tree contents.
@ -186,39 +243,40 @@ endif::git-format-patch[]
not in a subdirectory (e.g. in a bare repository), you
can name which subdirectory to make the output relative
to by giving a <path> as an argument.
--text::
Treat all files as text.
endif::git-format-patch[]
-a::
Shorthand for "--text".
--text::
Treat all files as text.
--ignore-space-at-eol::
Ignore changes in whitespace at EOL.
-b::
--ignore-space-change::
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".
-w::
--ignore-all-space::
Ignore whitespace when comparing lines. This ignores
differences even if one line has whitespace where the other
line has none.
-w::
Shorthand for "--ignore-all-space".
--inter-hunk-context=<lines>::
Show the context between diff hunks, up to the specified number
of lines, thereby fusing hunks that are close to each other.
ifndef::git-format-patch[]
--exit-code::
Make the program exit with codes similar to diff(1).
That is, it exits with 1 if there were differences and
0 means no differences.
--quiet::
Disable all output of the program. Implies --exit-code.
Disable all output of the program. Implies `--exit-code`.
endif::git-format-patch[]
--ext-diff::
Allow an external diff helper to be executed. If you set an

14
Documentation/docbook-xsl.css
View File

@ -16,6 +16,7 @@ body blockquote {
html body {
margin: 1em 5% 1em 5%;
line-height: 1.2;
font-family: sans-serif;
}
body div {
@ -128,6 +129,15 @@ body pre {
tt.literal, code.literal {
color: navy;
font-family: sans-serif;
}
code.literal:before { content: "'"; }
code.literal:after { content: "'"; }
em {
font-style: italic;
color: #064;
}
div.literallayout p {
@ -137,7 +147,6 @@ div.literallayout p {
div.literallayout {
font-family: monospace;
# margin: 0.5em 10% 0.5em 1em;
margin: 0em;
color: navy;
border: 1px solid silver;
@ -187,7 +196,8 @@ dt {
}
dt span.term {
font-style: italic;
font-style: normal;
color: navy;
}
div.variablelist dd p {

2
Documentation/everyday.txt
View File

@ -98,7 +98,7 @@ Use a tarball as a starting point for a new repository.::
------------
$ tar zxf frotz.tar.gz
$ cd frotz
$ git-init
$ git init
$ git add . <1>
$ git commit -m "import of frotz source tree."
$ git tag v2.43 <2>

70
Documentation/fetch-options.txt
View File

@ -1,11 +1,5 @@
-q::
--quiet::
Pass --quiet to git-fetch-pack and silence any other internally
used programs.
-v::
--verbose::
Be verbose.
--all::
Fetch all remotes.
-a::
--append::
@ -13,20 +7,38 @@
existing contents of `.git/FETCH_HEAD`. Without this
option old data in `.git/FETCH_HEAD` will be overwritten.
--upload-pack <upload-pack>::
When given, and the repository to fetch from is handled
by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
the command to specify non-default path for the command
run on the other end.
--depth=<depth>::
Deepen the history of a 'shallow' repository created by
`git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
by the specified number of commits.
ifndef::git-pull[]
--dry-run::
Show what would be done, without making any changes.
endif::git-pull[]
-f::
--force::
When 'git-fetch' is used with `<rbranch>:<lbranch>`
When 'git fetch' is used with `<rbranch>:<lbranch>`
refspec, it refuses to update the local branch
`<lbranch>` unless the remote branch `<rbranch>` it
fetches is a descendant of `<lbranch>`. This option
overrides that check.
-k::
--keep::
Keep downloaded pack.
ifndef::git-pull[]
--multiple::
Allow several <repository> and <group> arguments to be
specified. No <refspec>s may be specified.
--prune::
After fetching, remove any remote tracking branches which
no longer exist on the remote.
endif::git-pull[]
ifdef::git-pull[]
--no-tags::
endif::git-pull[]
@ -47,20 +59,28 @@ endif::git-pull[]
flag lets all tags and their associated objects be
downloaded.
-k::
--keep::
Keep downloaded pack.
-u::
--update-head-ok::
By default 'git-fetch' refuses to update the head which
By default 'git fetch' refuses to update the head which
corresponds to the current branch. This flag disables the
check. This is purely for the internal use for 'git-pull'
to communicate with 'git-fetch', and unless you are
check. This is purely for the internal use for 'git pull'
to communicate with 'git fetch', and unless you are
implementing your own Porcelain you are not supposed to
use it.
--depth=<depth>::
Deepen the history of a 'shallow' repository created by
`git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
by the specified number of commits.
--upload-pack <upload-pack>::
When given, and the repository to fetch from is handled
by 'git fetch-pack', '--exec=<upload-pack>' is passed to
the command to specify non-default path for the command
run on the other end.
ifndef::git-pull[]
-q::
--quiet::
Pass --quiet to git-fetch-pack and silence any other internally
used git commands.
-v::
--verbose::
Be verbose.
endif::git-pull[]

108
Documentation/git-add.txt
View File

@ -9,33 +9,37 @@ SYNOPSIS
--------
[verse]
'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
[--all | [--update | -u]] [--refresh] [--ignore-errors] [--]
<filepattern>...
[--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N]
[--refresh] [--ignore-errors] [--] [<filepattern>...]
DESCRIPTION
-----------
This command adds the current content of new or modified files to the
index, thus staging that content for inclusion in the next commit.
This command updates the index using the current content found in
the working tree, to prepare the content staged for the next commit.
It typically adds the current content of existing paths as a whole,
but with some options it can also be used to add content with
only part of the changes made to the working tree files applied, or
remove paths that do not exist in the working tree anymore.
The "index" holds a snapshot of the content of the working tree, and it
is this snapshot that is taken as the contents of the next commit. Thus
after making any changes to the working directory, and before running
the commit command, you must use the 'add' command to add any new or
the commit command, you must use the `add` command to add any new or
modified files to the index.
This command can be performed multiple times before a commit. It only
adds the content of the specified file(s) at the time the add command is
run; if you want subsequent changes included in the next commit, then
you must run 'git add' again to add the new content to the index.
you must run `git add` again to add the new content to the index.
The 'git status' command can be used to obtain a summary of which
The `git status` command can be used to obtain a summary of which
files have changes that are staged for the next commit.
The 'git add' command will not add ignored files by default. If any
ignored files were explicitly specified on the command line, 'git add'
The `git add` command will not add ignored files by default. If any
ignored files were explicitly specified on the command line, `git add`
will fail with a list of ignored files. Ignored files reached by
directory recursion or filename globbing performed by Git (quote your
globs before the shell) will be silently ignored. The 'add' command can
globs before the shell) will be silently ignored. The 'git add' command can
be used to add ignored files with the `-f` (force) option.
Please see linkgit:git-commit[1] for alternative ways to add content to a
@ -72,25 +76,51 @@ OPTIONS
-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.
Interactively choose hunks of patch between the index and the
work tree and add them to the index. This gives the user a chance
to review the difference before adding modified contents to the
index.
+
This effectively runs `add --interactive`, but bypasses the
initial command menu and directly jumps to the `patch` subcommand.
See ``Interactive mode'' for details.
-e, \--edit::
Open the diff vs. the index in an editor and let the user
edit it. After the editor was closed, adjust the hunk headers
and apply the patch to the index.
+
*NOTE*: Obviously, if you change anything else than the first character
on lines beginning with a space or a minus, the patch will no longer
apply.
-u::
--update::
Update only files that git already knows about, staging modified
content for commit and marking deleted files for removal. 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 in the
current directory and its subdirectories are updated.
Only match <filepattern> against already tracked files in
the index rather than the working tree. That means that it
will never stage new files, but that it will stage modified
new contents of tracked files and that it will remove files
from the index if the corresponding files in the working tree
have been removed.
+
If no <filepattern> is given, default to "."; in other words,
update all tracked files in the current directory and its
subdirectories.
-A::
--all::
Update files that git already knows about (same as '\--update')
and add all untracked files that are not ignored by '.gitignore'
mechanism.
Like `-u`, but match <filepattern> against files in the
working tree in addition to the index. That means that it
will find new files as well as staging modified content and
removing files that are no longer in the working tree.
-N::
--intent-to-add::
Record only the fact that the path will be added later. An entry
for the path is placed in the index with no content. This is
useful for, among other things, showing the unstaged content of
such files with `git diff` and committing them with `git commit
-a`.
--refresh::
Don't add the file(s), but only refresh their stat()
@ -110,7 +140,7 @@ OPTIONS
Configuration
-------------
The optional configuration variable 'core.excludesfile' indicates a path to a
The optional configuration variable `core.excludesfile` indicates a path to a
file containing patterns of file names to exclude from git-add, similar to
$GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to
those in info/exclude. See linkgit:gitrepository-layout[5].
@ -123,11 +153,11 @@ EXAMPLES
and its subdirectories:
+
------------
$ git add Documentation/\\*.txt
$ git add Documentation/\*.txt
------------
+
Note that the asterisk `\*` is quoted from the shell in this
example; this lets the command to include the files from
example; this lets the command include the files from
subdirectories of `Documentation/` directory.
* Considers adding content from all git-*.sh scripts:
@ -136,7 +166,7 @@ subdirectories of `Documentation/` directory.
$ git add git-*.sh
------------
+
Because this example lets shell expand the asterisk (i.e. you are
Because this example lets the shell expand the asterisk (i.e. you are
listing the files explicitly), it does not consider
`subdir/git-foo.sh`.
@ -158,7 +188,7 @@ and type return, like this:
What now> 1
------------
You also could say "s" or "sta" or "status" above as long as the
You also could say `s` or `sta` or `status` above as long as the
choice is unique.
The main command loop has 6 subcommands (plus help and quit).
@ -166,9 +196,9 @@ The main command loop has 6 subcommands (plus help and quit).
status::
This shows the change between HEAD and index (i.e. what will be
committed if you say "git commit"), and between index and
committed if you say `git commit`), and between index and
working tree files (i.e. what you could stage further before
"git commit" using "git-add") for each path. A sample output
`git commit` using `git add`) for each path. A sample output
looks like this:
+
------------
@ -189,8 +219,8 @@ one deletion).
update::
This shows the status information and gives prompt
"Update>>". When the prompt ends with double '>>', you can
This shows the status information and issues an "Update>>"
prompt. When the prompt ends with double '>>', you can
make more than one selection, concatenated with whitespace or
comma. Also you can say ranges. E.g. "2-5 7,9" to choose
2,3,4,5,7,9 from the list. If the second number in a range is
@ -229,15 +259,18 @@ add untracked::
patch::
This lets you choose one path out of 'status' like selection.
After choosing the path, it presents diff between the index
This lets you choose one path out of a 'status' like selection.
After choosing the path, it presents the diff between the index
and the working tree file and asks you if you want to stage
the change of each hunk. You can say:
y - stage this hunk
n - do not stage this hunk
q - quit, do not stage this hunk nor any of the remaining ones
a - stage this and all the remaining hunks in the file
d - do not stage this hunk nor any of the remaining hunks in the file
g - select a hunk to go to
/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
@ -254,13 +287,6 @@ diff::
This lets you review what will be committed (i.e. between
HEAD and index).
Bugs
----
The interactive mode does not work with files whose names contain
characters that need C-quoting. `core.quotepath` configuration can be
used to work this limitation around to some degree, but backslash,
double-quote and control characters will still have problems.
SEE ALSO
--------
linkgit:git-status[1]

98
Documentation/git-am.txt
View File

@ -10,10 +10,12 @@ SYNOPSIS
--------
[verse]
'git am' [--signoff] [--keep] [--utf8 | --no-utf8]
[--3way] [--interactive]
[--whitespace=<option>] [-C<n>] [-p<n>]
[--3way] [--interactive] [--committer-date-is-author-date]
[--ignore-date] [--ignore-space-change | --ignore-whitespace]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
[--reject] [-q | --quiet] [--scissors | --no-scissors]
[<mbox> | <Maildir>...]
'git am' (--skip | --resolved | --abort)
'git am' (--continue | --skip | --abort)
DESCRIPTION
-----------
@ -25,48 +27,61 @@ OPTIONS
-------
<mbox>|<Maildir>...::
The list of mailbox files to read patches from. If you do not
supply this argument, reads from the standard input. If you supply
directories, they'll be treated as Maildirs.
supply this argument, the command reads from the standard input.
If you supply directories, they will be treated as Maildirs.
-s::
--signoff::
Add `Signed-off-by:` line to the commit message, using
Add a `Signed-off-by:` line to the commit message, using
the committer identity of yourself.
-k::
--keep::
Pass `-k` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
Pass `-k` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
-c::
--scissors::
Remove everything in body before a scissors line (see
linkgit:git-mailinfo[1]).
---no-scissors::
Ignore scissors lines (see linkgit:git-mailinfo[1]).
-q::
--quiet::
Be quiet. Only print error messages.
-u::
--utf8::
Pass `-u` flag to 'git-mailinfo' (see linkgit: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
preferred encoding if it is not UTF-8).
+
This was optional in prior versions of git, but now it is the
default. You could use `--no-utf8` to override this.
default. You can use `--no-utf8` to override this.
--no-utf8::
Pass `-n` flag to 'git-mailinfo' (see
Pass `-n` flag to 'git mailinfo' (see
linkgit:git-mailinfo[1]).
-3::
--3way::
When the patch does not apply cleanly, fall back on
3-way merge, if the patch records the identity of blobs
it is supposed to apply to, and we have those blobs
3-way merge if the patch records the identity of blobs
it is supposed to apply to and we have those blobs
available locally.
--ignore-date::
--ignore-space-change::
--ignore-whitespace::
--whitespace=<option>::
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 linkgit:git-apply[1])
--directory=<dir>::
--reject::
These flags are passed to the 'git apply' (see linkgit:git-apply[1])
program that applies
the patch.
@ -74,10 +89,25 @@ default. You could use `--no-utf8` to override this.
--interactive::
Run interactively.
--committer-date-is-author-date::
By default the command records the date from the e-mail
message as the commit author date, and uses the time of
commit creation as the committer date. This allows the
user to lie about the committer date by using the same
value as the author date.
--ignore-date::
By default the command records the date from the e-mail
message as the commit author date, and uses the time of
commit creation as the committer date. This allows the
user to lie about the author date by using the same
value as the committer date.
--skip::
Skip the current patch. This is only meaningful when
restarting an aborted patch.
--continue::
-r::
--resolved::
After a patch failure (e.g. attempting to apply
@ -92,7 +122,7 @@ default. You could use `--no-utf8` to override this.
to the screen before exiting. This overrides the
standard message informing you to use `--resolved`
or `--skip` to handle the failure. This is solely
for internal use between 'git-rebase' and 'git-am'.
for internal use between 'git rebase' and 'git am'.
--abort::
Restore the original branch and abort the patching operation.
@ -101,24 +131,22 @@ DISCUSSION
----------
The commit author name is taken from the "From: " line of the
message, and commit author time is taken from the "Date: " line
message, and commit author date is taken from the "Date: " line
of the message. The "Subject: " line is used as the title of
the commit, after stripping common prefix "[PATCH <anything>]".
It is supposed to describe what the commit is about concisely as
a one line text.
The "Subject: " line is supposed to concisely describe what the
commit is about in one line of text.
The body of the message (iow, after a blank line that terminates
RFC2822 headers) can begin with "Subject: " and "From: " lines
that are different from those of the mail header, to override
the values of these fields.
"From: " and "Subject: " lines starting the body override the respective
commit author name and title values taken from the headers.
The commit message is formed by the title taken from the
"Subject: ", a blank line and the body of the message up to
where the patch begins. Excess whitespaces at the end of the
lines are automatically stripped.
where the patch begins. Excess whitespace at the end of each
line is automatically stripped.
The patch is expected to be inline, directly following the
message. Any line that is of form:
message. Any line that is of the form:
* three-dashes and end-of-line, or
* a line that begins with "diff -", or
@ -127,18 +155,18 @@ message. Any line that is of form:
is taken as the beginning of a patch, and the commit log message
is terminated before the first occurrence of such a line.
When initially invoking it, you give it names of the mailboxes
to crunch. Upon seeing the first patch that does not apply, it
aborts in the middle,. You can recover from this in one of two ways:
When initially invoking `git am`, you give it the names of the mailboxes
to process. Upon seeing the first patch that does not apply, it
aborts in the middle. You can recover from this in one of two ways:
. skip the current patch by re-running the command with '--skip'
. skip the current patch by re-running the command with the '--skip'
option.
. hand resolve the conflict in the working directory, and update
the index file to bring it in a state that the patch should
have produced. Then run the command with '--resolved' option.
the index file to bring it into a state that the patch should
have produced. Then run the command with the '--resolved' option.
The command refuses to process new mailboxes while `.git/rebase-apply`
The command refuses to process new mailboxes while the `.git/rebase-apply`
directory exists, so if you decide to start over from scratch,
run `rm -f -r .git/rebase-apply` before running the command with mailbox
names.

9
Documentation/git-annotate.txt
View File

@ -3,7 +3,7 @@ git-annotate(1)
NAME
----
git-annotate - Annotate file lines with commit info
git-annotate - Annotate file lines with commit information
SYNOPSIS
--------
@ -12,7 +12,12 @@ SYNOPSIS
DESCRIPTION
-----------
Annotates each line in the given file with information from the commit
which introduced the line. Optionally annotate from a given revision.
which introduced the line. Optionally annotates from a given revision.
The only difference between this command and linkgit:git-blame[1] is that
they use slightly different output formats, and this command exists only
for backward compatibility to support existing scripts, and provide a more
familiar command name for people coming from other SCM systems.
OPTIONS
-------

106
Documentation/git-apply.txt
View File

@ -3,28 +3,33 @@ git-apply(1)
NAME
----
git-apply - Apply a patch on a git index file and a working tree
git-apply - Apply a patch to files and/or to the index
SYNOPSIS
--------
[verse]
'git apply' [--stat] [--numstat] [--summary] [--check] [--index]
[--apply] [--no-add] [--build-fake-ancestor <file>] [-R | --reverse]
[--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse]
[--allow-binary-replacement | --binary] [--reject] [-z]
[-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached]
[--ignore-space-change | --ignore-whitespace ]
[--whitespace=<nowarn|warn|fix|error|error-all>]
[--exclude=PATH] [--directory=<root>] [--verbose] [<patch>...]
[--exclude=PATH] [--include=PATH] [--directory=<root>]
[--verbose] [<patch>...]
DESCRIPTION
-----------
Reads supplied 'diff' output and applies it on a git index file
and a work tree.
Reads the supplied diff output (i.e. "a patch") and applies it to files.
With the `--index` option the patch is also applied to the index, and
with the `--cache` option the patch is only applied to the index.
Without these options, the command applies the patch only to files,
and does not require them to be in a git repository.
OPTIONS
-------
<patch>...::
The files to read patch from. '-' can be used to read
The files to read the patch from. '-' can be used to read
from the standard input.
--stat::
@ -32,8 +37,8 @@ OPTIONS
input. Turns off "apply".
--numstat::
Similar to \--stat, but shows number of added and
deleted lines in decimal notation and pathname without
Similar to `--stat`, but shows the number of added and
deleted lines in decimal notation and the pathname without
abbreviation, to make it more machine friendly. For
binary files, outputs two `-` instead of saying
`0 0`. Turns off "apply".
@ -46,28 +51,28 @@ OPTIONS
--check::
Instead of applying the patch, see if the patch is
applicable to the current work tree and/or the index
applicable to the current working tree and/or the index
file and detects errors. Turns off "apply".
--index::
When --check is in effect, or when applying the patch
When `--check` is in effect, or when applying the patch
(which is the default when none of the options that
disables it is in effect), make sure the patch is
applicable to what the current index file records. If
the file to be patched in the work tree is not
the file to be patched in the working tree is not
up-to-date, it is flagged as an error. This flag also
causes the index file to be updated.
--cached::
Apply a patch without touching the working tree. Instead, take the
cached data, apply the patch, and store the result in the index,
without using the working tree. This implies '--index'.
Apply a patch without touching the working tree. Instead take the
cached data, apply the patch, and store the result in the index
without using the working tree. This implies `--index`.
--build-fake-ancestor <file>::
Newer 'git-diff' output has embedded 'index information'
--build-fake-ancestor=<file>::
Newer 'git diff' output has embedded 'index information'
for each blob to help identify the original version that
the patch applies to. When this flag is given, and if
the original versions of the blobs is available locally,
the original versions of the blobs are available locally,
builds a temporary index containing those blobs.
+
When a pure mode change is encountered (which has no index information),
@ -78,18 +83,20 @@ the information is read from the current index instead.
Apply the patch in reverse.
--reject::
For atomicity, 'git-apply' by default fails the whole patch and
For atomicity, 'git apply' by default fails the whole patch and
does not touch the working tree when some of the hunks
do not apply. This option makes it apply
the parts of the patch that are applicable, and leave the
rejected hunks in corresponding *.rej files.
-z::
When showing the index information, do not munge paths,
but use NUL terminated machine readable format. Without
this flag, the pathnames output will have TAB, LF, and
backslash characters replaced with `\t`, `\n`, and `\\`,
respectively.
When `--numstat` has been given, do not munge pathnames,
but use a NUL-terminated machine-readable format.
+
Without this option, each pathname output will have TAB, LF, double quotes,
and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`,
respectively, and the pathname will be enclosed in double quotes if
any of those replacements occurred.
-p<n>::
Remove <n> leading slashes from traditional diff paths. The
@ -102,19 +109,19 @@ the information is read from the current index instead.
ever ignored.
--unidiff-zero::
By default, 'git-apply' expects that the patch being
By default, 'git apply' expects that the patch being
applied is a unified diff with at least one line of context.
This provides good safety measures, but breaks down when
applying a diff generated with --unified=0. To bypass these
checks use '--unidiff-zero'.
applying a diff generated with `--unified=0`. To bypass these
checks use `--unidiff-zero`.
+
Note, for the reasons stated above usage of context-free patches are
Note, for the reasons stated above usage of context-free patches is
discouraged.
--apply::
If you use any of the options marked "Turns off
'apply'" above, 'git-apply' reads and outputs the
information you asked without actually applying the
'apply'" above, 'git apply' reads and outputs the
requested information without actually applying the
patch. Give this flag after those flags to also apply
the patch.
@ -123,7 +130,7 @@ discouraged.
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.
deletion part but not the addition part.
--allow-binary-replacement::
--binary::
@ -137,6 +144,25 @@ discouraged.
be useful when importing patchsets, where you want to exclude certain
files or directories.
--include=<path-pattern>::
Apply changes to files matching the given path pattern. This can
be useful when importing patchsets, where you want to include certain
files or directories.
+
When `--exclude` and `--include` patterns are used, they are examined in the
order they appear on the command line, and the first match determines if a
patch to each path is used. A patch to a path that does not match any
include/exclude pattern is used by default if there is no include pattern
on the command line, and ignored if there is any include pattern.
--ignore-space-change::
--ignore-whitespace::
When applying a patch, ignore changes in whitespace in context
lines if necessary.
Context lines will preserve their whitespace, and they will not
undergo whitespace fixing regardless of the value of the
`--whitespace` option. New lines will still be fixed, though.
--whitespace=<action>::
When applying a patch, detect a new or modified line that has
whitespace errors. What are considered whitespace errors is
@ -147,10 +173,10 @@ discouraged.
considered whitespace errors.
+
By default, the command outputs warning messages but applies the patch.
When `git-apply is used for statistics and not applying a
When `git-apply` is used for statistics and not applying a
patch, it defaults to `nowarn`.
+
You can use different `<action>` to control this
You can use different `<action>` values to control this
behavior:
+
* `nowarn` turns off the trailing whitespace warning.
@ -158,7 +184,7 @@ behavior:
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
used to consider only trailing whitespace characters 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.
@ -183,7 +209,7 @@ behavior:
adjusting the hunk headers appropriately).
--directory=<root>::
Prepend <root> to all filenames. If a "-p" argument was passed, too,
Prepend <root> to all filenames. If a "-p" argument was also passed,
it is applied before prepending the new root.
+
For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh`
@ -193,23 +219,27 @@ running `git apply --directory=modules/git-gui`.
Configuration
-------------
apply.ignorewhitespace::
Set to 'change' if you want changes in whitespace to be ignored by default.
Set to one of: no, none, never, false if you want changes in
whitespace to be significant.
apply.whitespace::
When no `--whitespace` flag is given from the command
line, this configuration item is used as the default.
Submodules
----------
If the patch contains any changes to submodules then 'git-apply'
If the patch contains any changes to submodules then 'git apply'
treats these changes as follows.
If --index is specified (explicitly or implicitly), then the submodule
If `--index` is specified (explicitly or implicitly), then the submodule
commits must match the index exactly for the patch to apply. If any
of the submodules are checked-out, then these check-outs are completely
ignored, i.e., they are not required to be up-to-date or clean and they
are not updated.
If --index is not specified, then the submodule commits in the patch
are ignored and only the absence of presence of the corresponding
If `--index` is not specified, then the submodule commits in the patch
are ignored and only the absence or presence of the corresponding
subdirectory is checked and (if possible) updated.
Author

12
Documentation/git-archimport.txt
View File

@ -29,17 +29,17 @@ branches that have different roots, it will refuse to run. In that case,
edit your <archive/branch> parameters to define clearly the scope of the
import.
'git-archimport' uses `tla` extensively in the background to access the
'git archimport' uses `tla` extensively in the background to access the
Arch repository.
Make sure you have a recent version of `tla` available in the path. `tla` must
know about the repositories you pass to 'git-archimport'.
know about the repositories you pass to 'git archimport'.
For the initial import, 'git-archimport' expects to find itself in an empty
For the initial import, 'git archimport' expects to find itself in an empty
directory. To follow the development of a project that uses Arch, rerun
'git-archimport' with the same parameters as the initial import to perform
'git archimport' with the same parameters as the initial import to perform
incremental imports.
While 'git-archimport' will try to create sensible branch names for the
While 'git archimport' will try to create sensible branch names for the
archives that it imports, it is also possible to specify git branch names
manually. To do so, write a git branch name after each <archive/branch>
parameter, separated by a colon. This way, you can shorten the Arch
@ -84,7 +84,7 @@ OPTIONS
-o::
Use this for compatibility with old-style branch names used by
earlier versions of 'git-archimport'. Old-style branch names
earlier versions of 'git archimport'. Old-style branch names
were category--branch, whereas new-style branch names are
archive,category--branch--version. In both cases, names given
on the command-line will override the automatically-generated

65
Documentation/git-archive.txt
View File

@ -9,7 +9,8 @@ git-archive - Create an archive of files from a named tree
SYNOPSIS
--------
[verse]
'git archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
'git archive' [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>]
[-o | --output=<file>] [--worktree-attributes]
[--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
[path...]
@ -20,21 +21,24 @@ structure for the named tree, and writes it out to the standard
output. If <prefix> is specified it is
prepended to the filenames in the archive.
'git-archive' behaves differently when given a tree ID versus when
'git archive' behaves differently when given a tree ID versus when
given a commit ID or tag ID. In the first case the current time is
used as modification time of each file in the archive. In the latter
used as the modification time of each file in the archive. In the latter
case the commit time as recorded in the referenced commit object is
used instead. Additionally the commit ID is stored in a global
extended pax header if the tar format is used; it can be extracted
using 'git-get-tar-commit-id'. In ZIP files it is stored as a file
using 'git get-tar-commit-id'. In ZIP files it is stored as a file
comment.
OPTIONS
-------
--format=<fmt>::
Format of the resulting archive: 'tar' or 'zip'. The default
is 'tar'.
Format of the resulting archive: 'tar' or 'zip'. If this option
is not given, and the output file is specified, the format is
inferred from the filename if possible (e.g. writing to "foo.zip"
makes the output to be in the zip format). Otherwise the output
format is `tar`.
-l::
--list::
@ -47,12 +51,19 @@ OPTIONS
--prefix=<prefix>/::
Prepend <prefix>/ to each filename in the archive.
-o <file>::
--output=<file>::
Write the archive to <file> instead of stdout.
--worktree-attributes::
Look for attributes in .gitattributes in working directory too.
<extra>::
This can be any options that the archiver backend understand.
This can be any options that the archiver backend understands.
See next section.
--remote=<repo>::
Instead of making a tar archive from local repository,
Instead of making a tar archive from the local repository,
retrieve a tar archive from a remote repository.
--exec=<git-upload-archive>::
@ -63,8 +74,9 @@ OPTIONS
The tree or commit to produce an archive for.
path::
If one or more paths are specified, include only these in the
archive, otherwise include all files and subdirectories.
Without an optional path parameter, all files and subdirectories
of the current working directory are included in the archive.
If one or more paths are specified, only these are included.
BACKEND EXTRA OPTIONS
---------------------
@ -88,12 +100,32 @@ tar.umask::
archiving user's umask will be used instead. See umask(2) for
details.
ATTRIBUTES
----------
export-ignore::
Files and directories with the attribute export-ignore won't be
added to archive files. See linkgit:gitattributes[5] for details.
export-subst::
If the attribute export-subst is set for a file then git will
expand several placeholders when adding this file to an archive.
See linkgit:gitattributes[5] for details.
Note that attributes are by default taken from the `.gitattributes` files
in the tree that is being archived. If you want to tweak the way the
output is generated after the fact (e.g. you committed without adding an
appropriate export-ignore in its `.gitattributes`), adjust the checked out
`.gitattributes` file as necessary and use `--work-tree-attributes`
option. Alternatively you can keep necessary attributes that should apply
while archiving any tree in your `$GIT_DIR/info/attributes` file.
EXAMPLES
--------
git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)::
Create a tar archive that contains the contents of the
latest commit on the current branch, and extracts it in
latest commit on the current branch, and extract it in the
`/var/tmp/junk` directory.
git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz::
@ -110,6 +142,17 @@ git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs
Put everything in the current head's Documentation/ directory
into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'.
git archive -o latest.zip HEAD::
Create a Zip archive that contains the contents of the latest
commit on the current branch. Note that the output format is
inferred by the extension of the output file.
SEE ALSO
--------
linkgit:gitattributes[5]
Author
------
Written by Franck Bui-Huu and Rene Scharfe.

1358
Documentation/git-bisect-lk2009.txt Normal file
View File

File diff suppressed because it is too large Load Diff

223
Documentation/git-bisect.txt
View File

@ -3,7 +3,7 @@ git-bisect(1)
NAME
----
git-bisect - Find the change that introduced a bug by binary search
git-bisect - Find by binary search the change that introduced a bug
SYNOPSIS
@ -19,14 +19,14 @@ on the subcommand:
git bisect start [<bad> [<good>...]] [--] [<paths>...]
git bisect bad [<rev>]
git bisect good [<rev>...]
git bisect skip [<rev>...]
git bisect reset [<branch>]
git bisect skip [(<rev>|<range>)...]
git bisect reset [<commit>]
git bisect visualize
git bisect replay <logfile>
git bisect log
git bisect run <cmd>...
This command uses 'git-rev-list --bisect' to help drive the
This command uses 'git rev-list --bisect' to help drive the
binary search process to find which change introduced a bug, given an
old "good" commit object name and a later "bad" commit object name.
@ -39,7 +39,8 @@ help" or "git bisect -h" to get a long usage description.
Basic bisect commands: start, bad, good
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The way you use it is:
Using the Linux kernel tree as an example, basic use of the bisect
command is as follows:
------------------------------------------------
$ git bisect start
@ -48,61 +49,74 @@ $ git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version
# tested that was good
------------------------------------------------
When you give at least one bad and one good versions, it will bisect
the revision tree and say something like:
When you have specified at least one bad and one good version, the
command bisects the revision tree and outputs something similar to
the following:
------------------------------------------------
Bisecting: 675 revisions left to test after this
------------------------------------------------
and check out the state in the middle. Now, compile that kernel, and
boot it. Now, let's say that this booted kernel works fine, then just
do
The state in the middle of the set of revisions is then checked out.
You would now compile that kernel and boot it. If the booted kernel
works correctly, you would then issue the following command:
------------------------------------------------
$ git bisect good # this one is good
------------------------------------------------
which will now say
The output of this command would be something similar to the following:
------------------------------------------------
Bisecting: 337 revisions left to test after this
------------------------------------------------
and you continue along, compiling that one, testing it, and depending
on whether it is good or bad, you say "git bisect good" or "git bisect
bad", and ask for the next bisection.
You keep repeating this process, compiling the tree, testing it, and
depending on whether it is good or bad issuing the command "git bisect good"
or "git bisect bad" to ask for the next bisection.
Until you have no more left, and you'll have been left with the first
bad kernel rev in "refs/bisect/bad".
Eventually there will be no more revisions left to bisect, and you
will have been left with the first bad kernel revision in "refs/bisect/bad".
Bisect reset
~~~~~~~~~~~~
Oh, and then after you want to reset to the original head, do a
After a bisect session, to clean up the bisection state and return to
the original HEAD, issue the following command:
------------------------------------------------
$ git bisect reset
------------------------------------------------
to get back to the original branch, instead of being on the bisection
commit ("git bisect start" will do that for you too, actually: it will
reset the bisection state).
By default, this will return your tree to the commit that was checked
out before `git bisect start`. (A new `git bisect start` will also do
that, as it cleans up the old bisection state.)
With an optional argument, you can return to a different commit
instead:
------------------------------------------------
$ git bisect reset <commit>
------------------------------------------------
For example, `git bisect reset HEAD` will leave you on the current
bisection commit and avoid switching commits at all, while `git bisect
reset bisect/bad` will check out the first bad revision.
Bisect visualize
~~~~~~~~~~~~~~~~
During the bisection process, you can say
To see the currently remaining suspects in 'gitk', issue the following
command during the bisection process:
------------
$ git bisect visualize
------------
to see the currently remaining suspects in 'gitk'. `visualize` is a bit
too long to type and `view` is provided as a synonym.
`view` may also be used as a synonym for `visualize`.
If 'DISPLAY' environment variable is not set, 'git-log' is used
instead. You can even give command line options such as `-p` and
If the 'DISPLAY' environment variable is not set, 'git log' is used
instead. You can also give command line options such as `-p` and
`--stat`.
------------
@ -112,73 +126,93 @@ $ git bisect view --stat
Bisect log and bisect replay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The good/bad input is logged, and
After having marked revisions as good or bad, issue the following
command to show what has been done so far:
------------
$ git bisect log
------------
shows what you have done so far. You can truncate its output somewhere
and save it in a file, and run
If you discover that you made a mistake in specifying the status of a
revision, you can save the output of this command to a file, edit it to
remove the incorrect entries, and then issue the following commands to
return to a corrected state:
------------
$ git bisect reset
$ git bisect replay that-file
------------
if you find later you made a mistake telling good/bad about a
revision.
Avoiding to test a commit
Avoiding testing a commit
~~~~~~~~~~~~~~~~~~~~~~~~~
If in a middle of bisect session, you know what the bisect suggested
to try next is not a good one to test (e.g. the change the commit
If, in the middle of a bisect session, you know that the next suggested
revision is not a good one to test (e.g. the change the commit
introduces is known not to work in your environment and you know it
does not have anything to do with the bug you are chasing), you may
want to find a near-by commit and try that instead.
want to find a nearby commit and try that instead.
It goes something like this:
For example:
------------
$ git bisect good/bad # previous round was good/bad.
$ git bisect good/bad # previous round was good or bad.
Bisecting: 337 revisions left to test after this
$ git bisect visualize # oops, that is uninteresting.
$ git reset --hard HEAD~3 # try 3 revs before what
$ git reset --hard HEAD~3 # try 3 revisions before what
# was suggested
------------
Then compile and test the one you chose to try. After that, tell
bisect what the result was as usual.
Then compile and test the chosen revision, and afterwards mark
the revision as good or bad in the usual manner.
Bisect skip
~~~~~~~~~~~~
Instead of choosing by yourself a nearby commit, you may just want git
to do it for you using:
Instead of choosing by yourself a nearby commit, you can ask git
to do it for you by issuing the command:
------------
$ 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.
But git may eventually be unable to tell the first bad commit among
a bad commit and one or more skipped commits.
You can even skip a range of commits, instead of just one commit,
using the "'<commit1>'..'<commit2>'" notation. For example:
------------
$ git bisect skip v2.5..v2.6
------------
This tells the bisect process that no commit after `v2.5`, up to and
including `v2.6`, should be tested.
Note that if you also want to skip the first commit of the range you
would issue the command:
------------
$ git bisect skip v2.5 v2.5..v2.6
------------
This tells the bisect process that the commits between `v2.5` included
and `v2.6` included should be skipped.
Cutting down bisection by giving more parameters to bisect start
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can further cut down the number of trials if you know what part of
the tree is involved in the problem you are tracking down, by giving
paths parameters when you say `bisect start`, like this:
You can further cut down the number of trials, if you know what part of
the tree is involved in the problem you are tracking down, by specifying
path parameters when issuing the `bisect start` command:
------------
$ git bisect start -- arch/i386 include/asm-i386
------------
If you know beforehand more than one good commits, you can narrow the
bisect space down without doing the whole tree checkout every time you
give good commits. You give the bad revision immediately after `start`
and then you give all the good revisions you have:
If you know beforehand more than one good commit, you can narrow the
bisect space down by specifying all of the good commits immediately after
the bad commit when issuing the `bisect start` command:
------------
$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
@ -190,38 +224,38 @@ Bisect run
~~~~~~~~~~
If you have a script that can tell if the current source code is good
or bad, you can automatically bisect using:
or bad, you can bisect by issuing the command:
------------
$ git bisect run my_script
$ git bisect run my_script arguments
------------
Note that the "run" script (`my_script` in the above example) should
exit with code 0 in case the current source code is good. Exit with a
Note that the script (`my_script` in the above example) should
exit with code 0 if the current source code is good, and 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".)
Any other exit code will abort the bisect process. It should be noted
that a program that terminates via "exit(-1)" leaves $? = 255, (see the
exit(3) manual page), as 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.
cannot be tested. If the 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
work around other problem this bisection is not interested in")
applied to the revision being tested.
You may often find that during a bisect session you want to have
temporary modifications (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 work around another problem this bisection is not
interested in") applied to the revision being tested.
To cope with such a situation, after the inner 'git-bisect' finds the
next revision to test, with the "run" script, you can apply that tweak
before compiling, run the real test, and after the test decides if the
revision (possibly with the needed tweaks) passed the test, rewind the
tree to the pristine state. Finally the "run" script can exit with
the status of the real test to let the "git bisect run" command loop to
determine the outcome.
To cope with such a situation, after the inner 'git bisect' finds the
next revision to test, the script can apply the patch
before compiling, run the real test, and afterwards decide if the
revision (possibly with the needed patch) passed the test and then
rewind the tree to the pristine state. Finally the script should exit
with the status of the real test to let the "git bisect run" command loop
determine the eventual outcome of the bisect session.
EXAMPLES
--------
@ -233,44 +267,60 @@ $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good
$ git bisect run make # "make" builds the app
------------
* Automatically bisect a test failure between origin and HEAD:
+
------------
$ git bisect start HEAD origin -- # HEAD is bad, origin is good
$ git bisect run make test # "make test" builds and tests
------------
* Automatically bisect a broken test suite:
+
------------
$ cat ~/test.sh
#!/bin/sh
make || exit 125 # this "skip"s broken builds
make || exit 125 # this skips broken builds
make test # "make test" runs the test suite
$ git bisect start v1.3 v1.1 -- # v1.3 is bad, v1.1 is good
$ git bisect run ~/test.sh
------------
+
Here we use a "test.sh" custom script. In this script, if "make"
fails, we "skip" the current commit.
fails, we skip the current commit.
+
It's safer to use a custom script outside the repo to prevent
It is safer to use a custom script outside the repository to prevent
interactions between the bisect, make and test processes and the
script.
+
And "make test" should "exit 0", if the test suite passes, and
"exit 1" (for example) otherwise.
"make test" should "exit 0", if the test suite passes, and
"exit 1" otherwise.
* Automatically bisect a broken test case:
+
------------
$ cat ~/test.sh
#!/bin/sh
make || exit 125 # this "skip"s broken builds
make || exit 125 # this skips broken builds
~/check_test_case.sh # does the test case passes ?
$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
$ git bisect run ~/test.sh
------------
+
Here "check_test_case.sh" should "exit 0", if the test case passes,
and "exit 1" (for example) otherwise.
Here "check_test_case.sh" should "exit 0" if the test case passes,
and "exit 1" otherwise.
+
It's safer if both "test.sh" and "check_test_case.sh" scripts are
outside the repo to prevent interactions between the bisect, make and
test processes and the scripts.
It is safer if both "test.sh" and "check_test_case.sh" scripts are
outside the repository to prevent interactions between the bisect,
make and test processes and the scripts.
* Automatically bisect a broken test suite:
+
------------
$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
$ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
------------
+
Does the same as the previous example, but on a single line.
Author
------
@ -280,6 +330,11 @@ Documentation
-------------
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
SEE ALSO
--------
link:git-bisect-lk2009.html[Fighting regressions with git bisect],
linkgit:git-blame[1].
GIT
---
Part of the linkgit:git[1] suite

72
Documentation/git-blame.txt
View File

@ -9,8 +9,8 @@ SYNOPSIS
--------
[verse]
'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
[-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
[<rev> | --contents <file>] [--] <file>
[-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
[<rev> | --contents <file> | --reverse <rev>] [--] <file>
DESCRIPTION
-----------
@ -18,10 +18,10 @@ DESCRIPTION
Annotates each line in the given file with information from the revision which
last modified the line. Optionally, start annotating from the given revision.
Also it can limit the range of lines annotated.
The command can also 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 'git-diff' or the "pickaxe"
The report does not tell you anything about lines which have been deleted or
replaced; you need to use a tool such as 'git diff' or the "pickaxe"
interface briefly mentioned in the following paragraph.
Apart from supporting file annotation, git also supports searching the
@ -48,26 +48,26 @@ include::blame-options.txt[]
lines between files (see `-C`) and lines moved within a
file (see `-M`). The first number listed is the score.
This is the number of alphanumeric characters detected
to be moved between or within files. This must be above
a certain threshold for 'git-blame' to consider those lines
as having been moved between or within files. This must be above
a certain threshold for 'git blame' to consider those lines
of code to have been moved.
-f::
--show-name::
Show filename in the original commit. By default
filename is shown if there is any line that came from a
file with different name, due to rename detection.
Show the filename in the original commit. By default
the filename is shown if there is any line that came from a
file with a different name, due to rename detection.
-n::
--show-number::
Show line number in the original commit (Default: off).
Show the line number in the original commit (Default: off).
-s::
Suppress author name and timestamp from the output.
Suppress the author name and timestamp from the output.
-w::
Ignore whitespace when comparing parent's version and
child's to find where the lines came from.
Ignore whitespace when comparing the parent's version and
the child's to find where the lines came from.
THE PORCELAIN FORMAT
@ -79,17 +79,17 @@ header at the minimum has the first line which has:
- 40-byte SHA-1 of the commit the line is attributed to;
- the line number of the line in the original file;
- the line number of the line in the final file;
- on a line that starts a group of line from a different
- on a line that starts a group of lines from a different
commit than the previous one, the number of lines in this
group. On subsequent lines this field is absent.
This header line is followed by the following information
at least once for each commit:
- author name ("author"), email ("author-mail"), time
- the author name ("author"), email ("author-mail"), time
("author-time"), and timezone ("author-tz"); similarly
for committer.
- filename in the commit the line is attributed to.
- the filename in the commit that the line is attributed to.
- the first line of the commit log message ("summary").
The contents of the actual line is output after the above
@ -100,25 +100,25 @@ header elements later.
SPECIFYING RANGES
-----------------
Unlike 'git-blame' and 'git-annotate' in older git, the extent
of annotation can be limited to both line ranges and revision
Unlike 'git blame' and 'git annotate' in older versions of git, the extent
of the annotation can be limited to both line ranges and revision
ranges. When you are interested in finding the origin for
ll. 40-60 for file `foo`, you can use `-L` option like these
lines 40-60 for file `foo`, you can use the `-L` option like so
(they mean the same thing -- both ask for 21 lines starting at
line 40):
git blame -L 40,60 foo
git blame -L 40,+21 foo
Also you can use regular expression to specify the line range.
Also you can use a regular expression to specify the line range:
git blame -L '/^sub hello {/,/^}$/' foo
would limit the annotation to the body of `hello` subroutine.
which limits the annotation to the body of the `hello` subroutine.
When you are not interested in changes older than the version
When you are not interested in changes older than version
v2.6.18, or changes older than 3 weeks, you can use revision
range specifiers similar to 'git-rev-list':
range specifiers similar to 'git rev-list':
git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo
@ -129,7 +129,7 @@ commit v2.6.18 or the most recent commit that is more than 3
weeks old in the above example) are blamed for that range
boundary commit.
A particularly useful way is to see if an added file have lines
A particularly useful way is to see if an added file has lines
created by copy-and-paste from existing files. Sometimes this
indicates that the developer was being sloppy and did not
refactor the code properly. You can first find the commit that
@ -162,26 +162,32 @@ annotated.
+
Line numbers count from 1.
. The first time that commit shows up in the stream, it has various
. The first time that a commit shows up in the stream, it has various
other information about it printed out with a one-word tag at the
beginning of each line about that "extended commit info" (author,
email, committer, dates, summary etc).
beginning of each line describing the extra commit information (author,
email, committer, dates, summary, etc.).
. Unlike Porcelain format, the filename information is always
. Unlike the Porcelain format, the filename information is always
given and terminates the entry:
"filename" <whitespace-quoted-filename-goes-here>
+
and thus it's really quite easy to parse for some line- and word-oriented
and thus it is really quite easy to parse for some line- and word-oriented
parser (which should be quite natural for most scripting languages).
+
[NOTE]
For people who do parsing: to make it more robust, just ignore any
lines in between the first and last one ("<sha1>" and "filename" lines)
where you don't recognize the tag-words (or care about that particular
lines between the first and last one ("<sha1>" and "filename" lines)
where you do not recognize the tag words (or care about that particular
one) at the beginning of the "extended information" lines. That way, if
there is ever added information (like the commit encoding or extended
commit commentary), a blame viewer won't ever care.
commit commentary), a blame viewer will not care.
MAPPING AUTHORS
---------------
include::mailmap.txt[]
SEE ALSO

119
Documentation/git-branch.txt
View File

@ -11,36 +11,34 @@ SYNOPSIS
'git branch' [--color | --no-color] [-r | -a]
[-v [--abbrev=<length> | --no-abbrev]]
[(--merged | --no-merged | --contains) [<commit>]]
'git branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
'git branch' (-d | -D) [-r] <branchname>...
DESCRIPTION
-----------
With no arguments, existing branches are listed, the current branch will
With no arguments, existing branches are listed and 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`, shows only the branches that contains the named commit
(in other words, the branches whose tip commits are descendant of the
With `--contains`, shows only the branches that contain the named commit
(in other words, the branches whose tip commits are descendants of the
named commit). With `--merged`, only branches merged into the named
commit (i.e. the branches whose tip commits are reachable from the named
commit) will be listed. With `--no-merged` only branches not merged into
the named commit will be listed. Missing <commit> argument defaults to
'HEAD' (i.e. the tip of the current branch).
the named commit will be listed. If the <commit> argument is missing it
defaults to 'HEAD' (i.e. the tip of the current branch).
In its second form, a new branch named <branchname> will be created.
It will start out with a head equal to the one given as <start-point>.
If no <start-point> is given, the branch will be created with a head
equal to that of the currently checked out branch.
The command's second form creates a new branch head named <branchname>
which points to the current 'HEAD', or <start-point> if given.
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 sets up the
branch so that 'git-pull' will appropriately merge from
branch so that 'git pull' will appropriately merge from
the remote branch. This behavior may be changed via the global
`branch.autosetupmerge` configuration flag. That setting can be
overridden by using the `--track` and `--no-track` options.
@ -57,9 +55,9 @@ 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 'git-fetch' 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.
in the remote repository or if 'git fetch' was configured not to fetch
them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a
way to clean up all obsolete remote-tracking branches.
OPTIONS
@ -76,14 +74,15 @@ OPTIONS
based sha1 expressions such as "<branchname>@\{yesterday}".
-f::
Force the creation of a new branch even if it means deleting
a branch that already exists with the same name.
--force::
Reset <branchname> to <startpoint> if <branchname> exists
already. Without `-f` 'git branch' refuses to change an existing branch.
-m::
Move/rename a branch and the corresponding reflog.
-M::
Move/rename a branch even if the new branchname already exists.
Move/rename a branch even if the new branch name already exists.
--color::
Color branches to highlight current, local, and remote branches.
@ -100,38 +99,52 @@ OPTIONS
-v::
--verbose::
Show sha1 and commit subject line for each head.
Show sha1 and commit subject line for each head, along with
relationship to upstream branch (if any). If given twice, print
the name of the upstream branch, as well.
--abbrev=<length>::
Alter minimum display length for sha1 in output listing,
default value is 7.
Alter the sha1's minimum display length in the output listing.
The default value is 7.
--no-abbrev::
Display the full sha1s in output listing rather than abbreviating them.
Display the full sha1s in the output listing rather than abbreviating them.
-t::
--track::
When creating a new branch, set up configuration so that 'git-pull'
will automatically retrieve data from the start point, which must be
a branch. Use this if you always pull from the same upstream branch
into the new branch, and if you don't want to use "git pull
<repository> <refspec>" explicitly. This behavior is the default
when the start point is a remote branch. Set the
branch.autosetupmerge configuration variable to `false` if you want
'git-checkout' and 'git-branch' to always behave as if '--no-track' were
given. Set it to `always` if you want this behavior when the
start-point is either a local or remote branch.
When creating a new branch, set up configuration to mark the
start-point branch as "upstream" from the new branch. This
configuration will tell git to show the relationship between the
two branches in `git status` and `git branch -v`. Furthermore,
it directs `git pull` without arguments to pull from the
upstream when the new branch is checked out.
+
This behavior is the default when the start point is a remote branch.
Set the branch.autosetupmerge configuration variable to `false` if you
want `git checkout` and `git branch` to always behave as if '--no-track'
were given. Set it to `always` if you want this behavior when the
start-point is either a local or remote branch.
--no-track::
Ignore the branch.autosetupmerge configuration variable.
Do not set up "upstream" configuration, even if the
branch.autosetupmerge configuration variable is true.
--set-upstream::
If specified branch does not exist yet or if '--force' has been
given, acts exactly like '--track'. Otherwise sets up configuration
like '--track' would when creating the branch, except that where
branch points to is not changed.
--contains <commit>::
Only list branches which contain the specified commit.
--merged::
Only list branches which are fully contained by HEAD.
--merged [<commit>]::
Only list branches whose tips are reachable from the
specified commit (HEAD if not specified).
--no-merged::
Do not list branches which are fully contained by HEAD.
--no-merged [<commit>]::
Only list branches whose tips are not reachable from the
specified commit (HEAD if not specified).
<branchname>::
The name of the branch to create or delete.
@ -140,22 +153,22 @@ OPTIONS
may restrict the characters allowed in a branch name.
<start-point>::
The new branch will be created with a HEAD equal to this. It may
be given as a branch name, a commit-id, or a tag. If this option
is omitted, the current branch is assumed.
The new branch head will point to this commit. It may be
given as a branch name, a commit-id, or a tag. If this
option is omitted, the current HEAD will be used instead.
<oldbranch>::
The name of an existing branch to rename.
<newbranch>::
The new name for an existing branch. The same restrictions as for
<branchname> applies.
<branchname> apply.
Examples
--------
Start development off of a known tag::
Start development from a known tag::
+
------------
$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
@ -167,7 +180,7 @@ $ git checkout my2.6.14
<1> This step and the next one could be combined into a single step with
"checkout -b my2.6.14 v2.6.14".
Delete unneeded branch::
Delete an unneeded branch::
+
------------
$ git clone git://git.kernel.org/.../git.git my.git
@ -176,21 +189,21 @@ $ git branch -d -r origin/todo origin/html origin/man <1>
$ git branch -D test <2>
------------
+
<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.
<1> Delete the remote-tracking branches "todo", "html" and "man". The next
'fetch' or 'pull' will create them again unless you configure them not to.
See linkgit:git-fetch[1].
<2> Delete the "test" branch even if the "master" branch (or whichever branch
is currently checked out) does not have all commits from the test branch.
Notes
-----
If you are creating a branch that you want to immediately checkout, it's
If you are creating a branch that you want to checkout immediately, it is
easier to use the git checkout command with its `-b` option to create
a branch and check it out with a single command.
The options `--contains`, `--merged` and `--no-merged` serves three related
The options `--contains`, `--merged` and `--no-merged` serve three related
but different purposes:
- `--contains <commit>` is used to find all branches which will need
@ -203,6 +216,14 @@ but different purposes:
- `--no-merged` is used to find branches which are candidates for merging
into HEAD, since those branches are not fully contained by HEAD.
SEE ALSO
--------
linkgit:git-check-ref-format[1],
linkgit:git-fetch[1],
linkgit:git-remote[1],
link:user-manual.html#what-is-a-branch[``Understanding history: What is
a branch?''] in the Git User's Manual.
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <gitster@pobox.com>

200
Documentation/git-bundle.txt
View File

@ -19,13 +19,13 @@ DESCRIPTION
Some workflows require that one or more branches of development on one
machine be replicated on another machine, but the two machines cannot
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
be directly connected, and therefore 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 'git-fetch' and 'git-pull'
after moving the archive by some means (i.e., by sneakernet). As no
direct connection between repositories exists, the user must specify a
another repository using 'git fetch' and 'git pull'
after moving the archive by some means (e.g., by sneakernet). As no
direct connection between the repositories exists, the user must specify a
basis for the bundle that is held by the destination repository: the
bundle assumes that all objects in the basis are already in the
destination repository.
@ -35,15 +35,15 @@ OPTIONS
create <file>::
Used to create a bundle named 'file'. This requires the
'git-rev-list' arguments to define the bundle contents.
'git rev-list' arguments to define the bundle contents.
verify <file>::
Used to check that a bundle file is valid and will apply
cleanly to the current repository. This includes checks on the
bundle format itself as well as checking that the prerequisite
commits exist and are fully linked in the current repository.
'git-bundle' prints a list of missing commits, if any, and exits
with non-zero status.
'git bundle' prints a list of missing commits, if any, and exits
with a non-zero status.
list-heads <file>::
Lists the references defined in the bundle. If followed by a
@ -51,16 +51,16 @@ list-heads <file>::
printed out.
unbundle <file>::
Passes the objects in the bundle to 'git-index-pack'
Passes the objects in the bundle to 'git index-pack'
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 'git-fetch'.
defined references. If a list of references is given, only
references matching those in the list are printed. This command is
really plumbing, intended to be called only by 'git fetch'.
[git-rev-list-args...]::
A list of arguments, acceptable to 'git-rev-parse' and
'git-rev-list', that specify the specific objects and references
to transport. For example, "master~10..master" causes the
A list of arguments, acceptable to 'git rev-parse' and
'git rev-list', that specifies the specific objects and references
to transport. For example, `master\~10..master` causes the
current master reference to be packaged along with all objects
added since its 10th ancestor commit. There is no explicit
limit to the number of references and objects that may be
@ -69,100 +69,136 @@ unbundle <file>::
[refname...]::
A list of references used to limit the references reported as
available. This is principally of use to 'git-fetch', which
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 'git-fetch-pack').
necessarily everything in the pack (in this case, 'git bundle' acts
like 'git fetch-pack').
SPECIFYING REFERENCES
---------------------
'git-bundle' will only package references that are shown by
'git-show-ref': this includes heads, tags, and remote heads. References
such as master~1 cannot be packaged, but are perfectly suitable for
'git bundle' will only package references that are shown by
'git show-ref': this includes heads, tags, and remote heads. References
such as `master\~1` cannot be packaged, but are perfectly suitable for
defining the basis. More than one reference may be packaged, and more
than one basis can be specified. The objects packaged are those not
contained in the union of the given bases. Each basis can be
specified explicitly (e.g., ^master~10), or implicitly (e.g.,
master~10..master, master --since=10.days.ago).
specified explicitly (e.g. `^master\~10`), or implicitly (e.g.
`master\~10..master`, `--since=10.days.ago master`).
It is very important that the basis used be held by the destination.
It is okay to err on the side of conservatism, causing the bundle file
to contain objects already in the destination as these are ignored
It is okay to err on the side of caution, causing the bundle file
to contain objects already in the destination, as these are ignored
when unpacking at the destination.
EXAMPLE
-------
Assume two repositories exist as R1 on machine A, and R2 on machine B.
Assume you want to transfer the history from a repository R1 on machine A
to another repository R2 on machine B.
For whatever reason, direct connection between A and B is not allowed,
but we can move data from A to B via some mechanism (CD, email, etc).
We want to update R2 with developments made on branch master in R1.
but we can move data from A to B via some mechanism (CD, email, etc.).
We want to update R2 with development made on the branch master in R1.
To create the bundle you have to specify the basis. You have some options:
To bootstrap the process, you can first create a bundle that does not have
any basis. You can use a tag to remember up to what commit you last
processed, in order to make it easy to later update the other repository
with an incremental bundle:
- Without basis.
+
This is useful when sending the whole history.
----------------
machineA$ cd R1
machineA$ git bundle create file.bundle master
machineA$ git tag -f lastR2bundle master
----------------
------------
$ git bundle create mybundle master
------------
Then you transfer file.bundle to the target machine B. If you are creating
the repository on machine B, then you can clone from the bundle as if it
were a remote repository instead of creating an empty repository and then
pulling or fetching objects from the bundle:
- Using temporally tags.
+
We set a tag in R1 (lastR2bundle) after the previous such transport,
and move it afterwards to help build the bundle.
----------------
machineB$ git clone /home/me/tmp/file.bundle R2
----------------
------------
$ git bundle create mybundle master ^lastR2bundle
$ git tag -f lastR2bundle master
------------
- Using a tag present in both repositories
------------
$ git bundle create mybundle master ^v1.0.0
------------
- A basis based on time.
------------
$ git bundle create mybundle master --since=10.days.ago
------------
- With a limit on the number of commits
------------
$ git bundle create mybundle master -n 10
------------
Then you move mybundle from A to B, and in R2 on B:
------------
$ git bundle verify mybundle
$ git fetch mybundle master:localRef
------------
With something like this in the config in R2:
This will define a remote called "origin" in the resulting repository that
lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will
have an entry like this:
------------------------
[remote "bundle"]
url = /home/me/tmp/file.bdl
[remote "origin"]
url = /home/me/tmp/file.bundle
fetch = refs/heads/*:refs/remotes/origin/*
------------------------
You can first sneakernet the bundle file to ~/tmp/file.bdl and
then these commands on machine B:
To update the resulting mine.git repository, you can fetch or pull after
replacing the bundle stored at /home/me/tmp/file.bundle with incremental
updates.
------------
$ git ls-remote bundle
$ git fetch bundle
$ git pull bundle
------------
After working some more in the original repository, you can create an
incremental bundle to update the other repository:
would treat it as if it is talking with a remote side over the
network.
----------------
machineA$ cd R1
machineA$ git bundle create file.bundle lastR2bundle..master
machineA$ git tag -f lastR2bundle master
----------------
You then transfer the bundle to the other machine to replace
/home/me/tmp/file.bundle, and pull from it.
----------------
machineB$ cd R2
machineB$ git pull
----------------
If you know up to what commit the intended recipient repository should
have the necessary objects, you can use that knowledge to specify the
basis, giving a cut-off point to limit the revisions and objects that go
in the resulting bundle. The previous example used lastR2bundle tag
for this purpose, but you can use any other options that you would give to
the linkgit:git-log[1] command. Here are more examples:
You can use a tag that is present in both:
----------------
$ git bundle create mybundle v1.0.0..master
----------------
You can use a basis based on time:
----------------
$ git bundle create mybundle --since=10.days master
----------------
You can use the number of commits:
----------------
$ git bundle create mybundle -10 master
----------------
You can run `git-bundle verify` to see if you can extract from a bundle
that was created with a basis:
----------------
$ git bundle verify mybundle
----------------
This will list what commits you must have in order to extract from the
bundle and will error out if you do not have them.
A bundle from a recipient repository's point of view is just like a
regular repository which it fetches or pulls from. You can, for example, map
references when fetching:
----------------
$ git fetch mybundle master:localRef
----------------
You can also see what references it offers.
----------------
$ git ls-remote mybundle
----------------
Author
------

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

@ -3,30 +3,30 @@ git-cat-file(1)
NAME
----
git-cat-file - Provide content or type/size information for repository objects
git-cat-file - Provide content or type and size information for repository objects
SYNOPSIS
--------
[verse]
'git cat-file' [-t | -s | -e | -p | <type>] <object>
'git cat-file' [--batch | --batch-check] < <list-of-objects>
'git cat-file' (-t | -s | -e | -p | <type>) <object>
'git cat-file' (--batch | --batch-check) < <list-of-objects>
DESCRIPTION
-----------
In the first form, provides content or type of objects in the repository. The
type is required unless '-t' or '-p' is used to find the object type, or '-s'
is used to find the object size.
In its first form, the command provides the content or the type of an object in
the repository. The type is required unless '-t' or '-p' is used to find the
object type, or '-s' is used to find the object size.
In the second form, a list of object (separated by LFs) is provided on stdin,
and the SHA1, type, and size of each object is printed on stdout.
In the second form, a list of objects (separated by linefeeds) is provided on
stdin, and the SHA1, type, and size of each object is printed on stdout.
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 linkgit:git-rev-parse[1].
the "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
-t::
Instead of the content, show the object type identified by
@ -56,8 +56,8 @@ OPTIONS
stdin. May not be combined with any other options or arguments.
--batch-check::
Print the SHA1, type, and size of each object provided on stdin. May not be
combined with any other options or arguments.
Print the SHA1, type, and size of each object provided on stdin. May not
be combined with any other options or arguments.
OUTPUT
------

65
Documentation/git-check-attr.txt
View File

@ -3,25 +3,84 @@ git-check-attr(1)
NAME
----
git-check-attr - Display gitattributes information.
git-check-attr - Display gitattributes information
SYNOPSIS
--------
[verse]
'git check-attr' attr... [--] pathname...
'git check-attr' --stdin [-z] attr... < <list-of-paths>
DESCRIPTION
-----------
For every pathname, this command will list if each attr is 'unspecified',
For every pathname, this command will list if each attribute is 'unspecified',
'set', or 'unset' as a gitattribute on that pathname.
OPTIONS
-------
--stdin::
Read file names from stdin instead of from the command-line.
-z::
Only meaningful with `--stdin`; paths are separated with a
NUL character instead of a linefeed character.
\--::
Interpret all preceding arguments as attributes, and all following
Interpret all preceding arguments as attributes and all following
arguments as path names. If not supplied, only the first argument will
be treated as an attribute.
OUTPUT
------
The output is of the form:
<path> COLON SP <attribute> COLON SP <info> LF
<path> is the path of a file being queried, <attribute> is an attribute
being queried and <info> can be either:
'unspecified';; when the attribute is not defined for the path.
'unset';; when the attribute is defined as false.
'set';; when the attribute is defined as true.
<value>;; when a value has been assigned to the attribute.
EXAMPLES
--------
In the examples, the following '.gitattributes' file is used:
---------------
*.java diff=java -crlf myAttr
NoMyAttr.java !myAttr
README caveat=unspecified
---------------
* Listing a single attribute:
---------------
$ git check-attr diff org/example/MyClass.java
org/example/MyClass.java: diff: java
---------------
* Listing multiple attributes for a file:
---------------
$ git check-attr crlf diff myAttr -- org/example/MyClass.java
org/example/MyClass.java: crlf: unset
org/example/MyClass.java: diff: java
org/example/MyClass.java: myAttr: set
---------------
* Listing an attribute for multiple files:
---------------
$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java
org/example/MyClass.java: myAttr: set
org/example/NoMyAttr.java: myAttr: unspecified
---------------
* Not all values are equally unambiguous:
---------------
$ git check-attr caveat README
README: caveat: unspecified
---------------
SEE ALSO
--------

82
Documentation/git-check-ref-format.txt
View File

@ -3,52 +3,92 @@ git-check-ref-format(1)
NAME
----
git-check-ref-format - Make sure ref name is well formed
git-check-ref-format - Ensures that a reference name is well formed
SYNOPSIS
--------
[verse]
'git check-ref-format' <refname>
'git check-ref-format' --print <refname>
'git check-ref-format' --branch <branchname-shorthand>
DESCRIPTION
-----------
Checks if a given 'refname' is acceptable, and exits non-zero if
it is not.
Checks if a given 'refname' is acceptable, and exits with a non-zero
status if it is not.
A reference is used in git to specify branches and tags. A
branch head is stored under `$GIT_DIR/refs/heads` directory, and
a tag is stored under `$GIT_DIR/refs/tags` directory. git
imposes the following rules on how refs are named:
branch head is stored under the `$GIT_DIR/refs/heads` directory, and
a tag is stored under the `$GIT_DIR/refs/tags` directory. git
imposes the following rules on how references are named:
. It can include slash `/` for hierarchical (directory)
. They can include slash `/` for hierarchical (directory)
grouping, but no slash-separated component can begin with a
dot `.`;
dot `.`.
. It cannot have two consecutive dots `..` anywhere;
. They must contain at least one `/`. This enforces the presence of a
category like `heads/`, `tags/` etc. but the actual names are not
restricted.
. It cannot have ASCII control character (i.e. bytes whose
. They cannot have two consecutive dots `..` anywhere.
. They cannot have ASCII control characters (i.e. bytes whose
values are lower than \040, or \177 `DEL`), space, tilde `~`,
caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
or open bracket `[` anywhere;
or open bracket `[` anywhere.
. It cannot end with a slash `/`.
. They cannot end with a slash `/` nor a dot `.`.
These rules makes it easy for shell script based tools to parse
refnames, pathname expansion by the shell when a refname is used
. They cannot end with the sequence `.lock`.
. They cannot contain a sequence `@{`.
. They cannot contain a `\`.
These rules make it easy for shell script based tools to parse
reference names, pathname expansion by the shell when a reference name is used
unquoted (by mistake), and also avoids ambiguities in certain
refname expressions (see linkgit:git-rev-parse[1]). Namely:
reference name expressions (see linkgit:git-rev-parse[1]):
. double-dot `..` are often used as in `ref1..ref2`, and in some
context this notation means `{caret}ref1 ref2` (i.e. not in
ref1 and in ref2).
. A double-dot `..` is often used as in `ref1..ref2`, and in some
contexts this notation means `{caret}ref1 ref2` (i.e. not in
`ref1` and in `ref2`).
. tilde `~` and caret `{caret}` are used to introduce postfix
. A tilde `~` and caret `{caret}` are used to introduce the postfix
'nth parent' and 'peel onion' operation.
. colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
. A 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
'git-cat-file': "git cat-file blob v1.3.3:refs.c".
'git cat-file': "git cat-file blob v1.3.3:refs.c".
. at-open-brace `@{` is used as a notation to access a reflog entry.
With the `--print` option, if 'refname' is acceptable, it prints the
canonicalized name of a hypothetical reference with that name. That is,
it prints 'refname' with any extra `/` characters removed.
With the `--branch` option, it expands the ``previous branch syntax''
`@{-n}`. For example, `@{-1}` is a way to refer the last branch you
were on. This option should be used by porcelains to accept this
syntax anywhere a branch name is expected, so they can act as if you
typed the branch name.
EXAMPLES
--------
* Print the name of the previous branch:
+
------------
$ git check-ref-format --branch @{-1}
------------
* Determine the reference name to use for a new branch:
+
------------
$ ref=$(git check-ref-format --print "refs/heads/$newbranch") ||
die "we do not like '$newbranch' as a branch name."
------------
GIT
---

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

@ -88,7 +88,7 @@ $ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
which will force all existing `*.h` files to be replaced with their
cached copies. If an empty command line implied "all", then this would
force-refresh everything in the index, which was not the point. But
since 'git-checkout-index' accepts --stdin it would be faster to use:
since 'git checkout-index' accepts --stdin it would be faster to use:
----------------
$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
@ -102,7 +102,7 @@ Using `--` is probably a good policy in scripts.
Using --temp or --stage=all
---------------------------
When `--temp` is used (or implied by `--stage=all`)
'git-checkout-index' will create a temporary file for each index
'git checkout-index' will create a temporary file for each index
entry being checked out. The index will not be updated with stat
information. These options can be useful if the caller needs all
stages of all unmerged entries so that the unmerged files can be
@ -147,9 +147,9 @@ To update and refresh only the files already checked out::
$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
----------------
Using 'git-checkout-index' to "export an entire tree"::
Using 'git checkout-index' to "export an entire tree"::
The prefix ability basically makes it trivial to use
'git-checkout-index' as an "export as tree" function.
'git checkout-index' as an "export as tree" function.
Just read the desired tree into the index, and do:
+
----------------

150
Documentation/git-checkout.txt
View File

@ -8,68 +8,92 @@ git-checkout - Checkout a branch or paths to the working tree
SYNOPSIS
--------
[verse]
'git checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
'git checkout' [<tree-ish>] [--] <paths>...
'git checkout' [-q] [-f] [-m] [<branch>]
'git checkout' [-q] [-f] [-m] [-b <new_branch>] [<start_point>]
'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
'git checkout' --patch [<tree-ish>] [--] [<paths>...]
DESCRIPTION
-----------
When <paths> are not given, this command switches branches by
updating the index and working tree to reflect the specified
branch, <branch>, and updating HEAD to be <branch> or, if
specified, <new_branch>. Using -b will cause <new_branch> to
be created; in this case you can use the --track or --no-track
options, which will be passed to `git branch`.
updating the index, working tree, and HEAD to reflect the specified
branch.
When <paths> are given, this command does *not* switch
If `-b` is given, a new branch is created and checked out, as if
linkgit:git-branch[1] were called; in this case you can
use the --track or --no-track options, which will be passed to `git
branch`. As a convenience, --track without `-b` implies branch
creation; see the description of --track below.
When <paths> or --patch are given, this command does *not* switch
branches. It updates the named paths in the working tree from
the index file (i.e. it runs `git checkout-index -f -u`), or
from a named commit. In
this case, the `-f` and `-b` options are meaningless and giving
either of them results in an error. <tree-ish> argument can be
the index file, or from a named <tree-ish> (most often a commit). In
this case, the `-b` and `--track` options are meaningless and giving
either of them results in an error. The <tree-ish> argument can be
used to specify a specific tree-ish (i.e. commit, tag or tree)
to update the index for the given paths before updating the
working tree.
The index may contain unmerged entries after a failed merge. By
default, if you try to check out such an entry from the index, the
checkout operation will fail and nothing will be checked out.
Using -f will ignore these unmerged entries. The contents from a
specific side of the merge can be checked out of the index by
using --ours or --theirs. With -m, changes made to the working tree
file can be discarded to recreate the original conflicted merge result.
OPTIONS
-------
-q::
--quiet::
Quiet, suppress feedback messages.
-f::
Proceed even if the index or the working tree differs
from HEAD. This is used to throw away local changes.
--force::
When switching branches, proceed even if the index or the
working tree differs from HEAD. This is used to throw away
local changes.
+
When checking out paths from the index, do not fail upon unmerged
entries; instead, unmerged entries are ignored.
--ours::
--theirs::
When checking out paths from the index, check out stage #2
('ours') or #3 ('theirs') for unmerged paths.
-b::
Create a new branch named <new_branch> and start it at
<branch>. The new branch name must pass all checks defined
by linkgit:git-check-ref-format[1]. Some of these checks
may restrict the characters allowed in a branch name.
<start_point>; see linkgit:git-branch[1] for details.
-t::
--track::
When creating a new branch, set up configuration so that 'git-pull'
will automatically retrieve data from the start point, which must be
a branch. Use this if you always pull from the same upstream branch
into the new branch, and if you don't want to use "git pull
<repository> <refspec>" explicitly. This behavior is the default
when the start point is a remote branch. Set the
branch.autosetupmerge configuration variable to `false` if you want
'git-checkout' and 'git-branch' to always behave as if '--no-track' were
given. Set it to `always` if you want this behavior when the
start-point is either a local or remote branch.
When creating a new branch, set up "upstream" configuration. See
"--track" in linkgit:git-branch[1] for details.
+
If no '-b' option is given, the name of the new branch will be
derived from the remote branch. If "remotes/" or "refs/remotes/"
is prefixed it is stripped away, and then the part up to the
next slash (which would be the nickname of the remote) is removed.
This would tell us to use "hack" as the local branch when branching
off of "origin/hack" (or "remotes/origin/hack", or even
"refs/remotes/origin/hack"). If the given name has no slash, or the above
guessing results in an empty name, the guessing is aborted. You can
explicitly give a name with '-b' in such a case.
--no-track::
Ignore the branch.autosetupmerge configuration variable.
Do not set up "upstream" configuration, even if the
branch.autosetupmerge configuration variable is true.
-l::
Create the new branch's reflog. This activates recording of
all changes made to the branch ref, enabling use of date
based sha1 expressions such as "<branchname>@\{yesterday}".
Create the new branch's reflog; see linkgit:git-branch[1] for
details.
-m::
If you have local modifications to one or more files that
--merge::
When switching branches,
if you have local modifications to one or more files that
are different between the current branch and the branch to
which you are switching, the command refuses to switch
branches in order to preserve your modifications in context.
@ -81,16 +105,49 @@ When a merge conflict happens, the index entries for conflicting
paths are left unmerged, and you need to resolve the conflicts
and mark the resolved paths with `git add` (or `git rm` if the merge
should result in deletion of the path).
+
When checking out paths from the index, this option lets you recreate
the conflicted merge in the specified paths.
--conflict=<style>::
The same as --merge option above, but changes the way the
conflicting hunks are presented, overriding the
merge.conflictstyle configuration variable. Possible values are
"merge" (default) and "diff3" (in addition to what is shown by
"merge" style, shows the original contents).
-p::
--patch::
Interactively select hunks in the difference between the
<tree-ish> (or the index, if unspecified) and the working
tree. The chosen hunks are then applied in reverse to the
working tree (and if a <tree-ish> was specified, the index).
+
This means that you can use `git checkout -p` to selectively discard
edits from your current working tree.
<branch>::
Branch to checkout; if it refers to a branch (i.e., a name that,
when prepended with "refs/heads/", is a valid ref), then that
branch is checked out. Otherwise, if it refers to a valid
commit, your HEAD becomes "detached" and you are no longer on
any branch (see below for details).
+
As a special case, the `"@\{-N\}"` syntax for the N-th last branch
checks out the branch (instead of detaching). You may also specify
`-` which is synonymous with `"@\{-1\}"`.
<new_branch>::
Name for the new branch.
<branch>::
Branch to checkout; may be any object ID that resolves to a
commit. Defaults to HEAD.
+
When this parameter names a non-branch (but still a valid commit object),
your HEAD becomes 'detached'.
<start_point>::
The name of a commit at which to start the new branch; see
linkgit:git-branch[1] for details. Defaults to HEAD.
<tree-ish>::
Tree to checkout from (when paths are given). If not specified,
the index will be used.
Detached HEAD
@ -106,12 +163,12 @@ $ git checkout v2.6.18
------------
Earlier versions of git did not allow this and asked you to
create a temporary branch using `-b` option, but starting from
create a temporary branch using the `-b` option, but starting from
version 1.5.0, the above command 'detaches' your HEAD from the
current branch and directly point at the commit named by the tag
(`v2.6.18` in the above example).
current branch and directly points at the commit named by the tag
(`v2.6.18` in the example above).
You can use usual git commands while in this state. You can use
You can use all git commands while in this state. You can use
`git reset --hard $othercommit` to further move around, for
example. You can make changes and create a new commit on top of
a detached HEAD. You can even create a merge by using `git
@ -145,8 +202,8 @@ $ git checkout hello.c <3>
------------
+
<1> switch branch
<2> take out a file out of other commit
<3> restore hello.c from HEAD of current branch
<2> take a file out of another commit
<3> restore hello.c from the index
+
If you have an unfortunate branch that is named `hello.c`, this
step would be confused as an instruction to switch to that branch.
@ -156,7 +213,7 @@ You should instead write:
$ git checkout -- hello.c
------------
. After working in a wrong branch, switching to the correct
. After working in the wrong branch, switching to the correct
branch would be done using:
+
------------
@ -164,7 +221,7 @@ $ git checkout mytopic
------------
+
However, your "wrong" branch and correct "mytopic" branch may
differ in files that you have locally modified, in which case,
differ in files that you have modified locally, in which case
the above checkout would fail like this:
+
------------
@ -190,7 +247,6 @@ the `-m` option, you would see something like this:
------------
$ git checkout -m mytopic
Auto-merging frotz
merge: warning: conflicts during merge
ERROR: Merge conflict in frotz
fatal: merge program failed
------------

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

@ -24,7 +24,7 @@ OPTIONS
-e::
--edit::
With this option, 'git-cherry-pick' will let you edit the commit
With this option, 'git cherry-pick' will let you edit the commit
message prior to committing.
-x::
@ -55,13 +55,12 @@ OPTIONS
-n::
--no-commit::
Usually the command automatically creates a commit with
a commit log message stating which commit was
cherry-picked. This flag applies the change necessary
to cherry-pick the named commit to your working tree
and the index, but does not make the commit. In addition,
when this option is used, your index does not have to match
the HEAD commit. The cherry-pick is done against the
Usually the command automatically creates a commit.
This flag applies the change necessary to cherry-pick
the named commit to your working tree and the index,
but does not make the commit. In addition, when this
option is used, your index does not have to match the
HEAD commit. The cherry-pick is done against the
beginning state of your index.
+
This is useful when cherry-picking more than one commits'

9
Documentation/git-cherry.txt
View File

@ -7,14 +7,14 @@ git-cherry - Find commits not merged upstream
SYNOPSIS
--------
'git cherry' [-v] <upstream> [<head>] [<limit>]
'git cherry' [-v] [<upstream> [<head> [<limit>]]]
DESCRIPTION
-----------
The changeset (or "diff") of each commit between the fork-point and <head>
is compared against each commit between the fork-point and <upstream>.
The commits are compared with their 'patch id', obtained from
the 'git-patch-id' program.
the 'git patch-id' program.
Every commit that doesn't exist in the <upstream> branch
has its id (sha1) reported, prefixed by a symbol. The ones that have
@ -37,8 +37,8 @@ to and including <limit> are not reported:
\__*__*__<limit>__-__+__> <head>
Because 'git-cherry' compares the changeset rather than the commit id
(sha1), you can use 'git-cherry' to find out if a commit you made locally
Because 'git cherry' compares the changeset rather than the commit id
(sha1), you can use 'git cherry' to find out if a commit you made locally
has been applied <upstream> under a different commit id. For example,
this will happen if you're feeding patches <upstream> via email rather
than pushing or pulling commits directly.
@ -51,6 +51,7 @@ OPTIONS
<upstream>::
Upstream branch to compare against.
Defaults to the first tracked remote branch, if available.
<head>::
Working branch; defaults to HEAD.

4
Documentation/git-citool.txt
View File

@ -14,9 +14,9 @@ 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 'git-commit' program.
to the less interactive 'git commit' program.
'git-citool' is actually a standard alias for `git gui citool`.
'git citool' is actually a standard alias for `git gui citool`.
See linkgit:git-gui[1] for more details.
Author

23
Documentation/git-clean.txt
View File

@ -12,22 +12,29 @@ SYNOPSIS
DESCRIPTION
-----------
Removes files unknown to git. This allows to clean the working tree
from files that are not under version control. If the '-x' option is
specified, ignored files are also removed, allowing to remove all
build products.
Cleans the working tree by recursively removing files that are not
under version control, starting from the current directory.
Normally, only files unknown to git are removed, but if the '-x'
option is specified, ignored files are also removed. This can, for
example, be useful to remove all build products.
If any optional `<path>...` arguments are given, only those paths
are affected.
OPTIONS
-------
-d::
Remove untracked directories in addition to untracked files.
If an untracked directory is managed by a different git
repository, it is not removed by default. Use -f option twice
if you really want to remove such a directory.
-f::
If the git configuration specifies clean.requireForce as true,
'git-clean' will refuse to run unless given -f or -n.
--force::
If the git configuration variable clean.requireForce is not set
to false, 'git clean' will refuse to run unless given -f or -n.
-n::
--dry-run::
@ -41,7 +48,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 'git-reset') to create a pristine
conjunction with 'git reset') to create a pristine
working directory to test a clean build.
-X::

73
Documentation/git-clone.txt
View File

@ -11,16 +11,17 @@ SYNOPSIS
[verse]
'git clone' [--template=<template_directory>]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
[--depth <depth>] [--] <repository> [<directory>]
[-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
[--depth <depth>] [--recursive] [--] <repository> [<directory>]
DESCRIPTION
-----------
Clones a repository into a newly created directory, creates
remote-tracking branches for each branch in the cloned repository
(visible using `git branch -r`), and creates and checks out an initial
branch equal to the cloned repository's currently active branch.
(visible using `git branch -r`), and creates and checks out an
initial branch that is forked from the cloned repository's
currently active branch.
After the clone, a plain `git fetch` without arguments will update
all the remote-tracking branches, and a `git pull` without
@ -38,7 +39,7 @@ OPTIONS
--local::
-l::
When the repository to clone from is on a local machine,
this flag bypasses normal "git aware" transport
this flag bypasses the normal "git aware" transport
mechanism and clones the repository by making a copy of
HEAD and everything under objects and refs directories.
The files under `.git/objects/` directory are hardlinked
@ -59,7 +60,7 @@ OPTIONS
-s::
When the repository to clone is on the local machine,
instead of using hard links, automatically setup
.git/objects/info/alternates to share the objects
`.git/objects/info/alternates` to share the objects
with the source repository. The resulting repository
starts out without any object of its own.
+
@ -68,28 +69,47 @@ it unless you understand what it does. If you clone your
repository using this option and then delete branches (or use any
other git command that makes any existing commit unreferenced) in the
source repository, some objects may become unreferenced (or dangling).
These objects may be removed by normal git operations (such as 'git-commit')
These objects may be removed by normal git operations (such as `git commit`)
which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
If these objects are removed and were referenced by the cloned repository,
then the cloned repository will become corrupt.
+
Note that running `git repack` without the `-l` option in a repository
cloned with `-s` will copy objects from the source repository into a pack
in the cloned repository, removing the disk space savings of `clone -s`.
It is safe, however, to run `git gc`, which uses the `-l` option by
default.
+
If you want to break the dependency of a repository cloned with `-s` on
its source repository, you can simply run `git repack -a` to copy all
objects from the source repository into a pack in the cloned repository.
--reference <repository>::
If the reference repository is on the local machine
automatically setup .git/objects/info/alternates to
If the reference repository is on the local machine,
automatically setup `.git/objects/info/alternates` to
obtain objects from the reference repository. Using
an already existing repository as an alternate will
require fewer objects to be copied from the repository
being cloned, reducing network and local storage costs.
+
*NOTE*: see NOTE to --shared option.
*NOTE*: see the NOTE for the `--shared` option.
--quiet::
-q::
Operate quietly. This flag is also passed to the `rsync'
Operate quietly. Progress is not reported to the standard
error stream. This flag is also passed to the `rsync'
command when given.
--verbose::
-v::
Run verbosely.
--progress::
Progress status is reported on the standard error stream
by default when it is attached to a terminal, unless -q
is specified. This flag forces progress status even if the
standard error stream is not directed to a terminal.
--no-checkout::
-n::
No checkout of HEAD is performed after the clone is complete.
@ -107,12 +127,19 @@ then the cloned repository will become corrupt.
configuration variables are created.
--mirror::
Set up a mirror of the remote repository. This implies --bare.
Set up a mirror of the remote repository. This implies `--bare`.
--origin <name>::
-o <name>::
Instead of using the remote name 'origin' to keep track
of the upstream repository, use <name> instead.
Instead of using the remote name `origin` to keep track
of the upstream repository, use `<name>`.
--branch <name>::
-b <name>::
Instead of pointing the newly created HEAD to the branch pointed
to by the cloned repository's HEAD, point to `<name>` branch
instead. In a non-bare repository, this is the branch that will
be checked out.
--upload-pack <upload-pack>::
-u <upload-pack>::
@ -134,6 +161,14 @@ then the cloned repository will become corrupt.
with a long history, and would want to send in fixes
as patches.
--recursive::
After the clone is created, initialize all submodules within,
using their default settings. This is equivalent to running
`git submodule update --init --recursive` immediately after
the clone is finished. This option is ignored if the cloned
repository does not have a worktree/checkout (i.e. if any of
`--no-checkout`/`-n`, `--bare`, or `--mirror` is given)
<repository>::
The (possibly remote) repository to clone from. See the
<<URLS,URLS>> section below for more information on specifying
@ -142,9 +177,9 @@ then the cloned repository will become corrupt.
<directory>::
The name of a new directory to clone into. The "humanish"
part of the source repository is used if no directory is
explicitly given ("repo" for "/path/to/repo.git" and "foo"
for "host.xz:foo/.git"). Cloning into an existing directory
is not allowed.
explicitly given (`repo` for `/path/to/repo.git` and `foo`
for `host.xz:foo/.git`). Cloning into an existing directory
is only allowed if the directory is empty.
:git-clone: 1
include::urls.txt[]

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

@ -70,18 +70,19 @@ is taken from the configuration items user.name and user.email, or, if not
present, system user name and fully qualified hostname.
A commit comment is read from stdin. If a changelog
entry is not provided via "<" redirection, 'git-commit-tree' will just wait
entry is not provided via "<" redirection, 'git commit-tree' will just wait
for one to be entered and terminated with ^D.
include::date-formats.txt[]
Diagnostics
-----------
You don't exist. Go away!::
The passwd(5) gecos field couldn't be read
Your parents must have hated you!::
The password(5) gecos field is longer than a giant static buffer.
The passwd(5) gecos field is longer than a giant static buffer.
Your sysadmin must hate you!::
The password(5) name field is longer than a giant static buffer.
The passwd(5) name field is longer than a giant static buffer.
Discussion
----------

92
Documentation/git-commit.txt
View File

@ -8,10 +8,11 @@ git-commit - Record changes to the repository
SYNOPSIS
--------
[verse]
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend]
[(-c | -C) <commit>] [-F <file> | -m <msg>]
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
[(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]
[--allow-empty] [--no-verify] [-e] [--author=<author>]
[--cleanup=<mode>] [--] [[-i | -o ]<file>...]
[--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]
[[-i | -o ]<file>...]
DESCRIPTION
-----------
@ -20,16 +21,17 @@ with a log message from the user describing the changes.
The content to be added can be specified in several ways:
1. by using 'git-add' to incrementally "add" changes to the
1. by using 'git add' to incrementally "add" changes to the
index before using the 'commit' command (Note: even modified
files must be "added");
2. by using 'git-rm' to remove files from the working tree
2. by using 'git rm' 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
case the commit will ignore changes staged in the index, and instead
record the current content of the listed files;
record the current content of the listed files (which must already
be known to git);
4. by using the -a switch with the 'commit' command to automatically
"add" changes from all known files (i.e. all files that are already
@ -39,15 +41,14 @@ The content to be added can be specified in several ways:
5. by using the --interactive switch with the 'commit' command to decide one
by one which files should be part of the commit, before finalizing the
operation. Currently, this is done by invoking 'git-add --interactive'.
operation. Currently, this is done by invoking 'git add --interactive'.
The 'git-status' command can be used to obtain a
The `--dry-run` option 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.
commit by giving the same set of parameters (options and paths).
If you make a commit and then find a mistake immediately after
that, you can recover from it with 'git-reset'.
that, you can recover from it with 'git reset'.
OPTIONS
@ -69,14 +70,38 @@ OPTIONS
Like '-C', but with '-c' the editor is invoked, so that
the user can further edit the commit message.
--reset-author::
When used with -C/-c/--amend options, declare that the
authorship of the resulting commit now belongs of the committer.
This also renews the author timestamp.
--short::
When doing a dry-run, give the output in the short-format. See
linkgit:git-status[1] for details. Implies `--dry-run`.
--porcelain::
When doing a dry-run, give the output in a porcelain-ready
format. See linkgit:git-status[1] for details. Implies
`--dry-run`.
-z::
When showing `short` or `porcelain` status output, terminate
entries in the status output with NUL, instead of LF. If no
format is given, implies the `--porcelain` output format.
-F <file>::
--file=<file>::
Take the commit message from the given file. Use '-' to
read the message from the standard input.
--author=<author>::
Override the author name used in the commit. Use
`A U Thor <author@example.com>` format.
Override the author name used in the commit. You can use the
standard `A U Thor <author@example.com>` format. Otherwise,
an existing commit that matches the given string and its author
name is used.
--date=<date>::
Override the author date used in the commit.
-m <msg>::
--message=<msg>::
@ -92,7 +117,8 @@ OPTIONS
-s::
--signoff::
Add Signed-off-by line at the end of the commit message.
Add Signed-off-by line by the committer at the end of the commit
log message.
-n::
--no-verify::
@ -142,6 +168,10 @@ It is a rough equivalent for:
------
but can be used to amend a merge commit.
--
+
You should understand the implications of rewriting history if you
amend a commit that has already been published. (See the "RECOVERING
FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
-i::
--include::
@ -155,10 +185,10 @@ but can be used to amend a merge commit.
Make a commit only from the paths specified on the
command line, disregarding any contents that have been
staged so far. This is the default mode of operation of
'git-commit' if any paths are given on the command line,
'git commit' if any paths are given on the command line,
in which case this option can be omitted.
If this option is specified together with '--amend', then
no paths need be specified, which can be used to amend
no paths need to be specified, which can be used to amend
the last commit without committing changes that have
already been staged.
@ -190,6 +220,22 @@ specified.
--quiet::
Suppress commit summary message.
--dry-run::
Do not create a commit, but show a list of paths that are
to be committed, paths with local changes that will be left
uncommitted and paths that are untracked.
--status::
Include the output of linkgit:git-status[1] in the commit
message template when using an editor to prepare the commit
message. Defaults to on, but can be used to override
configuration variable commit.status.
--no-status::
Do not include the output of linkgit:git-status[1] in the
commit message template when using an editor to prepare the
default commit message.
\--::
Do not interpret any more arguments as options.
@ -200,15 +246,17 @@ specified.
these files are also staged for the next commit on top
of what have been staged before.
:git-commit: 1
include::date-formats.txt[]
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 'git-add'. A file can be
called the "index" with 'git add'. 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
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
@ -264,13 +312,13 @@ $ git commit
this second commit would record the changes to `hello.c` and
`hello.h` as expected.
After a merge (initiated by 'git-merge' or 'git-pull') stops
After a merge (initiated by 'git merge' or 'git pull') 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 'git-status'
check which paths are conflicting with 'git status'
and after fixing them manually in your working tree, you would
stage the result as usual with 'git-add':
stage the result as usual with 'git add':
------------
$ git status | grep unmerged
@ -311,7 +359,7 @@ ENVIRONMENT AND CONFIGURATION VARIABLES
The editor used to edit the commit log message will be chosen from the
GIT_EDITOR environment variable, the core.editor configuration variable, the
VISUAL environment variable, or the EDITOR environment variable (in that
order).
order). See linkgit:git-var[1] for details.
HOOKS
-----

45
Documentation/git-config.txt
View File

@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git config' [<file-option>] [type] [-z|--null] name [value [value_regex]]
'git config' [<file-option>] [type] --add name value
'git config' [<file-option>] [type] --replace-all name [value [value_regex]]
'git config' [<file-option>] [type] --replace-all name value [value_regex]
'git config' [<file-option>] [type] [-z|--null] --get name [value_regex]
'git config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
'git config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
@ -22,6 +22,7 @@ SYNOPSIS
'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]
'git config' [<file-option>] -e | --edit
DESCRIPTION
-----------
@ -36,11 +37,12 @@ existing values that match the regexp are updated or unset. If
you want to handle the lines that do *not* match the regex, just
prepend a single exclamation mark in front (see also <<EXAMPLES>>).
The type specifier can be either '--int' or '--bool', which will make
'git-config' ensure that the variable(s) are of the given type and
The type specifier can be either '--int' or '--bool', to make
'git config' ensure that the variable(s) are of the given type and
convert the value to the canonical form (simple decimal number for int,
a "true" or "false" string for bool). If no type specifier is passed,
no checks or transformations are performed on the value.
a "true" or "false" string for bool), or '--path', which does some
path expansion (see '--path' below). If no type specifier is passed, no
checks or transformations are performed on the value.
The file-option can be one of '--system', '--global' or '--file'
which specify where the values will be read from or written to.
@ -68,7 +70,8 @@ OPTIONS
--add::
Adds a new line to the option without altering any existing
values. This is the same as providing '^$' as the value_regex.
values. This is the same as providing '^$' as the value_regex
in `--replace-all`.
--get::
Get the value for a given key (optionally filtered by a regex
@ -122,14 +125,25 @@ See also <<FILES>>.
List all variables set in config file.
--bool::
'git-config' will ensure that the output is "true" or "false"
'git config' will ensure that the output is "true" or "false"
--int::
'git-config' will ensure that the output is a simple
'git config' will ensure that the output is a simple
decimal number. An optional value suffix of 'k', 'm', or 'g'
in the config file will cause the value to be multiplied
by 1024, 1048576, or 1073741824 prior to output.
--bool-or-int::
'git config' will ensure that the output matches the format of
either --bool or --int, as described above.
--path::
'git-config' will expand leading '{tilde}' to the value of
'$HOME', and '{tilde}user' to the home directory for the
specified user. This option has no effect when setting the
value (but you can use 'git config bla {tilde}/' from the
command line to let your shell do the expansion).
-z::
--null::
For all options that output values and/or keys, always
@ -150,19 +164,24 @@ See also <<FILES>>.
When the color setting for `name` is undefined, the command uses
`color.ui` as fallback.
--get-color name default::
--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`.
-e::
--edit::
Opens an editor to modify the specified config file; either
'--system', '--global', or repository (default).
[[FILES]]
FILES
-----
If not set explicitly with '--file', there are three files where
'git-config' will search for configuration options:
'git config' will search for configuration options:
$GIT_DIR/config::
Repository specific configuration file. (The filename is
@ -179,12 +198,12 @@ $(prefix)/etc/gitconfig::
If no further options are given, all reading options will read all of these
files that are available. If the global or the system-wide configuration
file are not available they will be ignored. If the repository configuration
file is not available or readable, 'git-config' will exit with a non-zero
file is not available or readable, 'git config' will exit with a non-zero
error code. However, in neither case will an error message be issued.
All writing options will per default write to the repository specific
configuration file. Note that this also affects options like '--replace-all'
and '--unset'. *'git-config' will only ever change one file at a time*.
and '--unset'. *'git config' will only ever change one file at a time*.
You can override these rules either by command line options or by environment
variables. The '--global' and the '--system' options will limit the file used
@ -279,7 +298,7 @@ If you want to know all the values for a multivar, do:
% git config --get-all core.gitproxy
------------
If you like to live dangerous, you can replace *all* core.gitproxy by a
If you like to live dangerously, you can replace *all* core.gitproxy by a
new one with
------------

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

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

6
Documentation/git-cvsexportcommit.txt
View File

@ -27,7 +27,7 @@ by default.
Supports file additions, removals, and commits that affect binary files.
If the commit is a merge commit, you must tell 'git-cvsexportcommit' what
If the commit is a merge commit, you must tell 'git cvsexportcommit' what
parent the changeset should be done against.
OPTIONS
@ -63,6 +63,10 @@ OPTIONS
-u::
Update affected files from CVS repository before attempting export.
-k::
Reverse CVS keyword expansion (e.g. $Revision: 1.2.3.4$
becomes $Revision$) in working CVS checkout before applying patch.
-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

54
Documentation/git-cvsimport.txt
View File

@ -24,10 +24,13 @@ repository, or incrementally import into an existing one.
Splitting the CVS log into patch sets is done by 'cvsps'.
At least version 2.1 is required.
*WARNING:* for certain situations the import leads to incorrect results.
Please see the section <<issues,ISSUES>> for further reference.
You should *never* do any work of your own on the branches that are
created by 'git-cvsimport'. By default initial import will create and populate a
created by 'git cvsimport'. By default initial import will create and populate a
"master" branch from the CVS repository's main branch which you're free
to work with; after that, you need to 'git-merge' incremental imports, or
to work with; after that, you need to 'git merge' incremental imports, or
any CVS branches, yourself. It is advisable to specify a named remote via
-r to separate and protect the incoming branches.
@ -46,13 +49,13 @@ OPTIONS
-d <CVSROOT>::
The root of the CVS archive. May be local (a simple path) or remote;
currently, only the :local:, :ext: and :pserver: access methods
are supported. If not given, 'git-cvsimport' will try to read it
are supported. If not given, 'git cvsimport' will try to read it
from `CVS/Root`. If no such file exists, it checks for the
`CVSROOT` environment variable.
<CVS_module>::
The CVS module you want to import. Relative to <CVSROOT>.
If not given, 'git-cvsimport' tries to read it from
If not given, 'git cvsimport' tries to read it from
`CVS/Repository`.
-C <target-dir>::
@ -62,14 +65,14 @@ OPTIONS
-r <remote>::
The git remote to import this CVS repository into.
Moves all CVS branches into remotes/<remote>/<branch>
akin to the 'git-clone' "--use-separate-remote" option.
akin to the way 'git clone' uses 'origin' by default.
-o <branch-for-HEAD>::
When no remote is specified (via -r) the 'HEAD' branch
from CVS is imported to the 'origin' branch within the git
repository, as 'HEAD' already has a special meaning for git.
When a remote is specified the 'HEAD' branch is named
remotes/<remote>/master mirroring 'git-clone' behaviour.
remotes/<remote>/master mirroring 'git clone' behaviour.
Use this option if you want to import into a different
branch.
+
@ -142,17 +145,17 @@ This option can be used several times to provide several detection regexes.
---------
+
'git-cvsimport' will make it appear as those authors had
'git cvsimport' will make it appear as those authors had
their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
all along.
+
For convenience, this data is saved to `$GIT_DIR/cvs-authors`
each time the '-A' option is provided and read from that same
file each time 'git-cvsimport' is run.
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
'git-cvsexportcommit'.
'git cvsexportcommit'.
-h::
Print a short usage message and exit.
@ -164,6 +167,39 @@ If '-v' is specified, the script reports what it is doing.
Otherwise, success is indicated the Unix way, i.e. by simply exiting with
a zero exit status.
[[issues]]
ISSUES
------
Problems related to timestamps:
* If timestamps of commits in the cvs repository are not stable enough
to be used for ordering commits changes may show up in the wrong
order.
* If any files were ever "cvs import"ed more than once (e.g., import of
more than one vendor release) the HEAD contains the wrong content.
* If the timestamp order of different files cross the revision order
within the commit matching time window the order of commits may be
wrong.
Problems related to branches:
* Branches on which no commits have been made are not imported.
* All files from the branching point are added to a branch even if
never added in cvs.
* This applies to files added to the source branch *after* a daughter
branch was created: if previously no commit was made on the daughter
branch they will erroneously be added to the daughter branch in git.
Problems related to tags:
* Multiple tags on the same revision are not imported.
If you suspect that any of these issues may apply to the repository you
want to import consider using these alternative tools which proved to be
more stable in practice:
* cvs2git (part of cvs2svn), `http://cvs2svn.tigris.org`
* parsecvs, `http://cgit.freedesktop.org/~keithp/parsecvs`
Author
------

44
Documentation/git-cvsserver.txt
View File

@ -11,7 +11,7 @@ SYNOPSIS
SSH:
[verse]
export CVS_SERVER=git-cvsserver
export CVS_SERVER="git cvsserver"
'cvs' -d :ext:user@server/path/repo.git co <HEAD_name>
pserver (/etc/inetd.conf):
@ -22,7 +22,7 @@ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
Usage:
[verse]
'git cvsserver' [options] [pserver|server] [<directory> ...]
'git-cvsserver' [options] [pserver|server] [<directory> ...]
OPTIONS
-------
@ -109,7 +109,7 @@ Note: Newer CVS versions (>= 1.12.11) also support specifying
CVS_SERVER directly in CVSROOT like
------
cvs -d ":ext;CVS_SERVER=git-cvsserver:user@server/path/repo.git" co <HEAD_name>
cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>
------
This has the advantage that it will be saved in your 'CVS/Root' files and
you don't need to worry about always setting the correct environment
@ -158,7 +158,7 @@ allowing access over SSH.
--
------
export CVSROOT=:ext:user@server:/var/git/project.git
export CVS_SERVER=git-cvsserver
export CVS_SERVER="git cvsserver"
------
--
4. For SSH clients that will make commits, make sure their server-side
@ -182,10 +182,9 @@ Database Backend
----------------
'git-cvsserver' uses one database per git head (i.e. CVS module) to
store information about the repository for faster access. The
database doesn't contain any persistent data and can be completely
regenerated from the git repository at any time. The database
needs to be updated (i.e. written to) after every commit.
store information about the repository to maintain consistent
CVS revision numbers. The database needs to be
updated (i.e. written to) after every commit.
If the commit is done directly by using `git` (as opposed to
using 'git-cvsserver') the update will need to happen on the
@ -204,6 +203,18 @@ write so it might not be enough to grant the users using
'git-cvsserver' write access to the database file without granting
them write access to the directory, too.
The database can not be reliably regenerated in a
consistent form after the branch it is tracking has changed.
Example: For merged branches, 'git-cvsserver' only tracks
one branch of development, and after a 'git merge' an
incrementally updated database may track a different branch
than a database regenerated from scratch, causing inconsistent
CVS revision numbers. `git-cvsserver` has no way of knowing which
branch it would have picked if it had been run incrementally
pre-merge. So if you have to fully or partially (from old
backup) regenerate the database, you should be suspicious
of pre-existing CVS sandboxes.
You can configure the database backend with the following
configuration variables:
@ -266,6 +277,21 @@ In `dbdriver` and `dbuser` you can use the following variables:
If no name can be determined, the
numeric uid is used.
ENVIRONMENT
-----------
These variables obviate the need for command-line options in some
circumstances, allowing easier restricted usage through git-shell.
GIT_CVSSERVER_BASE_PATH takes the place of the argument to --base-path.
GIT_CVSSERVER_ROOT specifies a single-directory whitelist. The
repository must still be configured to allow access through
git-cvsserver, as described above.
When these environment variables are set, the corresponding
command-line arguments may not be used.
Eclipse CVS Client Notes
------------------------
@ -283,7 +309,7 @@ To get a checkout with the Eclipse CVS client:
Protocol notes: If you are using anonymous access via pserver, just select that.
Those using SSH access should choose the 'ext' protocol, and configure 'ext'
access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
'git-cvsserver'. Note that password support is not good when using 'ext',
"`git cvsserver`". Note that password support is not good when using 'ext',
you will definitely want to have SSH keys setup.
Alternatively, you can just use the non-standard extssh protocol that Eclipse

78
Documentation/git-daemon.txt
View File

@ -9,8 +9,9 @@ SYNOPSIS
--------
[verse]
'git daemon' [--verbose] [--syslog] [--export-all]
[--timeout=n] [--init-timeout=n] [--strict-paths]
[--base-path=path] [--user-path | --user-path=path]
[--timeout=n] [--init-timeout=n] [--max-connections=n]
[--strict-paths] [--base-path=path] [--base-path-relaxed]
[--user-path | --user-path=path]
[--interpolated-path=pathtemplate]
[--reuseaddr] [--detach] [--pid-file=file]
[--enable=service] [--disable=service]
@ -27,36 +28,36 @@ that service if it is enabled.
It verifies that the directory has the magic file "git-daemon-export-ok", and
it will refuse to export any git directory that hasn't explicitly been marked
for export this way (unless the '--export-all' parameter is specified). If you
pass some directory paths as 'git-daemon' arguments, you can further restrict
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-ls-remote' clients, which are invoked
from 'git-fetch', 'git-pull', 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.
An `upload-archive` also exists to serve 'git-archive'.
An `upload-archive` also exists to serve 'git archive'.
OPTIONS
-------
--strict-paths::
Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
"/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
'git-daemon' will refuse to start when this option is enabled and no
'git daemon' will refuse to start when this option is enabled and no
whitelist is specified.
--base-path::
--base-path=path::
Remap all the path requests as relative to the given path.
This is sort of "GIT root" - if you run 'git-daemon' with
This is sort of "GIT root" - if you run 'git daemon' with
'--base-path=/srv/git' on example.com, then if you later try to pull
'git://example.com/hello.git', 'git-daemon' will interpret the path
'git://example.com/hello.git', 'git daemon' will interpret the path
as '/srv/git/hello.git'.
--base-path-relaxed::
If --base-path is enabled and repo lookup fails, with this option
'git-daemon' will attempt to lookup without prefixing the base path.
'git daemon' will attempt to lookup without prefixing the base path.
This is useful for switching to --base-path usage, while still
allowing the old paths.
@ -80,8 +81,8 @@ OPTIONS
Incompatible with --port, --listen, --user and --group options.
--listen=host_or_ipaddr::
Listen on an a specific IP address or hostname. IP addresses can
be either an IPv4 address or an IPV6 address if supported. If IPv6
Listen on a specific IP address or hostname. IP addresses can
be either an IPv4 address or an IPv6 address if supported. If IPv6
is not supported, then --listen=hostname is also not supported and
--listen must be given an IPv4 address.
Incompatible with '--inetd' option.
@ -89,15 +90,19 @@ OPTIONS
--port=n::
Listen on an alternative port. Incompatible with '--inetd' option.
--init-timeout::
--init-timeout=n::
Timeout between the moment the connection is established and the
client request is received (typically a rather low value, since
that should be basically immediate).
--timeout::
--timeout=n::
Timeout for specific client sub-requests. This includes the time
it takes for the server to process the sub-request and time spent
waiting for next client's request.
it takes for the server to process the sub-request and the time spent
waiting for the next client's request.
--max-connections=n::
Maximum number of concurrent clients, defaults to 32. Set it to
zero for no limit.
--syslog::
Log to syslog instead of stderr. Note that this option does not imply
@ -105,9 +110,9 @@ OPTIONS
--user-path::
--user-path=path::
Allow ~user notation to be used in requests. When
Allow {tilde}user notation to be used in requests. When
specified with no parameter, requests to
git://host/~alice/foo is taken as a request to access
git://host/{tilde}alice/foo is taken as a request to access
'foo' repository in the home directory of user `alice`.
If `--user-path=path` is specified, the same request is
taken as a request to access `path/foo` repository in
@ -138,14 +143,14 @@ OPTIONS
+
Giving these options is an error when used with `--inetd`; use
the facility of inet daemon to achieve the same before spawning
'git-daemon' if needed.
'git daemon' if needed.
--enable=service::
--disable=service::
Enable/disable the service site-wide per default. Note
that a service disabled site-wide can still be enabled
per repository if it is marked overridable and the
repository enables the service with an configuration
repository enables the service with a configuration
item.
--allow-override=service::
@ -164,24 +169,24 @@ SERVICES
These services can be globally enabled/disabled using the
command line options of this command. If a finer-grained
control is desired (e.g. to allow 'git-archive' to be run
control is desired (e.g. to allow 'git archive' to be run
against only in a few selected repositories the daemon serves),
the per-repository configuration file can be used to enable or
disable them.
upload-pack::
This serves 'git-fetch-pack' and 'git-ls-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`.
upload-archive::
This serves 'git-archive --remote'. It is disabled by
This serves 'git archive --remote'. It is disabled by
default, but a repository can enable it by setting
`daemon.uploadarch` configuration item to `true`.
receive-pack::
This serves 'git-send-pack' clients, allowing anonymous
This serves 'git send-pack' clients, allowing anonymous
push. It is disabled by default, as there is _no_
authentication in the protocol (in other words, anybody
can push anything into the repository, including removal
@ -199,8 +204,8 @@ $ grep 9418 /etc/services
git 9418/tcp # Git Version Control System
------------
'git-daemon' as inetd server::
To set up 'git-daemon' as an inetd service that handles any
'git daemon' as inetd server::
To set up 'git daemon' as an inetd service that handles any
repository under the whitelisted set of directories, /pub/foo
and /pub/bar, place an entry like the following into
/etc/inetd all on one line:
@ -212,8 +217,8 @@ git 9418/tcp # Git Version Control System
------------------------------------------------
'git-daemon' as inetd server for virtual hosts::
To set up 'git-daemon' as an inetd service that handles
'git daemon' as inetd server for virtual hosts::
To set up 'git daemon' as an inetd service that handles
repositories for different virtual hosts, `www.example.com`
and `www.example.org`, place an entry like the following into
`/etc/inetd` all on one line:
@ -235,8 +240,8 @@ clients, a symlink from `/software` into the appropriate
default repository could be made as well.
'git-daemon' as regular daemon for virtual hosts::
To set up 'git-daemon' as a regular, non-inetd service that
'git daemon' as regular daemon for virtual hosts::
To set up 'git daemon' as a regular, non-inetd service that
handles repositories for multiple virtual hosts based on
their IP addresses, start the daemon like this:
+
@ -253,7 +258,7 @@ Repositories can still be accessed by hostname though, assuming
they correspond to these IP addresses.
selectively enable/disable services per repository::
To enable 'git-archive --remote' and disable 'git-fetch' against
To enable 'git archive --remote' and disable 'git fetch' against
a repository, have the following in the configuration file in the
repository (that is the file 'config' next to 'HEAD', 'refs' and
'objects').
@ -265,6 +270,15 @@ selectively enable/disable services per repository::
----------------------------------------------------------------
ENVIRONMENT
-----------
'git daemon' will set REMOTE_ADDR to the IP address of the client
that connected to it, if the IP address is available. REMOTE_ADDR will
be available in the environment of hooks called when
services are performed.
Author
------
Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki

43
Documentation/git-describe.txt
View File

@ -8,7 +8,9 @@ git-describe - Show the most recent tag that is reachable from a commit
SYNOPSIS
--------
[verse]
'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
DESCRIPTION
-----------
@ -18,19 +20,29 @@ shown. Otherwise, it suffixes the tag name with the number of
additional commits on top of the tagged object and the
abbreviated object name of the most recent commit.
By default (without --all or --tags) `git describe` only shows
annotated tags. For more information about creating annotated tags
see the -a and -s options to linkgit:git-tag[1].
OPTIONS
-------
<committish>...::
Committish object names to describe.
--dirty[=<mark>]::
Describe the working tree.
It means describe HEAD and appends <mark> (`-dirty` by
default) if the working tree is dirty.
--all::
Instead of using only the annotated tags, use any ref
found in `.git/refs/`.
found in `.git/refs/`. This option enables matching
any known branch, remote branch, or lightweight tag.
--tags::
Instead of using only the annotated tags, use any tag
found in `.git/refs/tags`.
found in `.git/refs/tags`. This option enables matching
a lightweight (non-annotated) tag.
--contains::
Instead of finding the tag that predates the commit, find
@ -38,8 +50,10 @@ OPTIONS
Automatically implies --tags.
--abbrev=<n>::
Instead of using the default 8 hexadecimal digits as the
abbreviated object name, use <n> digits.
Instead of using the default 7 hexadecimal digits as the
abbreviated object name, use <n> digits, or as many digits
as needed to form a unique object name. An <n> of 0
will suppress long format, only showing the closest tag.
--candidates=<n>::
Instead of considering only the 10 most recent tags as
@ -63,8 +77,8 @@ OPTIONS
This is useful when you want to see parts of the commit object name
in "describe" output, even when the commit in question happens to be
a tagged version. Instead of just emitting the tag name, it will
describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2
that points at object deadbeef....).
describe such a commit as v1.2-0-gdeadbee (0th commit since tag v1.2
that points at object deadbee....).
--match <pattern>::
Only consider tags matching the given pattern (can be used to avoid
@ -82,7 +96,7 @@ With something like git.git current tree, I get:
v1.0.4-14-g2414721
i.e. the current head of my "parent" branch is based on v1.0.4,
but since it has a handful commits on top of that,
but since it has a few commits on top of that,
describe has added the number of additional commits ("14") and
an abbreviated object name for the commit itself ("2414721")
at the end.
@ -92,7 +106,7 @@ of commits which would be displayed by "git log v1.0.4..parent".
The hash suffix is "-g" + 7-char abbreviation for the tip commit
of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
Doing a 'git-describe' on a tag-name will just show the tag name:
Doing a 'git describe' on a tag-name will just show the tag name:
[torvalds@g5 git]$ git describe v1.0.4
v1.0.4
@ -103,7 +117,7 @@ the output shows the reference path as well:
[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
tags/v1.0.0-21-g975b
[torvalds@g5 git]$ git describe --all HEAD^
[torvalds@g5 git]$ git describe --all --abbrev=4 HEAD^
heads/lt/describe-7-g975b
With --abbrev set to 0, the command can be used to find the
@ -112,16 +126,23 @@ closest tagname without any suffix:
[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
tags/v1.0.0
Note that the suffix you get if you type these commands today may be
longer than what Linus saw above when he ran these commands, as your
git repository may have new commits whose object names begin with
975b that did not exist back then, and "-g975b" suffix alone may not
be sufficient to disambiguate these commits.
SEARCH STRATEGY
---------------
For each committish supplied, 'git-describe' will first look for
For each committish supplied, 'git describe' will first look for
a tag which tags exactly that commit. Annotated tags will always
be preferred over lightweight tags, and tags with newer dates will
always be preferred over tags with older dates. If an exact match
is found, its name will be output and searching will stop.
If an exact match was not found, 'git-describe' will walk back
If an exact match was not found, 'git describe' will walk back
through the commit history to locate an ancestor commit which
has been tagged. The ancestor's tag will be output along with an
abbreviation of the input committish's SHA1.

10
Documentation/git-diff-files.txt
View File

@ -15,13 +15,16 @@ DESCRIPTION
Compares the files in the working tree and the index. When paths
are specified, compares only those named paths. Otherwise all
entries in the index are compared. The output format is the
same as for 'git-diff-index' and 'git-diff-tree'.
same as for 'git diff-index' and 'git diff-tree'.
OPTIONS
-------
include::diff-options.txt[]
-1 -2 -3 or --base --ours --theirs, and -0::
-1 --base::
-2 --ours::
-3 --theirs::
-0::
Diff against the "base" version, "our branch" or "their
branch" respectively. With these options, diffs for
merged entries are not shown.
@ -40,8 +43,7 @@ omit diff output for unmerged entries and just show "Unmerged".
-q::
Remain silent even on nonexistent files
Output format
-------------
include::diff-format.txt[]

22
Documentation/git-diff-index.txt
View File

@ -31,11 +31,9 @@ include::diff-options.txt[]
-m::
By default, files recorded in the index but not checked
out are reported as deleted. This flag makes
'git-diff-index' say that all non-checked-out files are up
'git diff-index' say that all non-checked-out files are up
to date.
Output format
-------------
include::diff-format.txt[]
Operating Modes
@ -50,7 +48,7 @@ Cached Mode
If '--cached' is specified, it allows you to ask:
show me the differences between HEAD and the current index
contents (the ones I'd write using 'git-write-tree')
contents (the ones I'd write using 'git write-tree')
For example, let's say that you have worked on your working directory, updated
some files in the index and are ready to commit. You want to see exactly
@ -62,7 +60,7 @@ object and compare it that way, and to do that, you just do
Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
done an `update-index` to make that effective in the index file.
`git diff-files` wouldn't show anything at all, since the index file
matches my working directory. But doing a 'git-diff-index' does:
matches my working directory. But doing a 'git diff-index' does:
torvalds@ppc970:~/git> git diff-index --cached HEAD
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
@ -71,10 +69,10 @@ matches my working directory. But doing a 'git-diff-index' does:
You can see easily that the above is a rename.
In fact, `git diff-index --cached` *should* always be entirely equivalent to
actually doing a 'git-write-tree' and comparing that. Except this one is much
actually doing a 'git write-tree' and comparing that. Except this one is much
nicer for the case where you just want to check where you are.
So doing a 'git-diff-index --cached' is basically very useful when you are
So doing a `git diff-index --cached` is basically very useful when you are
asking yourself "what have I already marked for being committed, and
what's the difference to a previous tree".
@ -82,20 +80,20 @@ Non-cached Mode
---------------
The "non-cached" mode takes a different approach, and is potentially
the more useful of the two in that what it does can't be emulated with
a 'git-write-tree' + 'git-diff-tree'. Thus that's the default mode.
a 'git write-tree' + 'git diff-tree'. Thus that's the default mode.
The non-cached version asks the question:
show me the differences between HEAD and the currently checked out
tree - index contents _and_ files that aren't up-to-date
which is obviously a very useful question too, since that tells you what
you *could* commit. Again, the output matches the 'git-diff-tree -r'
you *could* commit. Again, the output matches the 'git diff-tree -r'
output to a tee, but with a twist.
The twist is that if some file doesn't match the index, we don't have
a backing store thing for it, and we use the magic "all-zero" sha1 to
show that. So let's say that you have edited `kernel/sched.c`, but
have not actually done a 'git-update-index' on it yet - there is no
have not actually done a 'git update-index' on it yet - there is no
"object" associated with the new state, and you get:
torvalds@ppc970:~/v2.6/linux> git diff-index HEAD
@ -106,11 +104,11 @@ not up-to-date and may contain new stuff. The all-zero sha1 means that to
get the real diff, you need to look at the object in the working directory
directly rather than do an object-to-object diff.
NOTE: As with other commands of this type, 'git-diff-index' does not
NOTE: As with other commands of this type, 'git diff-index' does not
actually look at the contents of the file at all. So maybe
`kernel/sched.c` hasn't actually changed, and it's just that you
touched it. In either case, it's a note that you need to
'git-update-index' it to make the index be in sync.
'git update-index' it to make the index be in sync.
NOTE: You can have a mixture of files show up as "has been updated"
and "is still dirty in the working directory" together. You can always

34
Documentation/git-diff-tree.txt
View File

@ -20,7 +20,7 @@ Compares the content and mode of the blobs found via two tree objects.
If there is only one <tree-ish> given, the commit is compared with its parents
(see --stdin below).
Note that 'git-diff-tree' can use the tree encapsulated in a commit object.
Note that 'git diff-tree' can use the tree encapsulated in a commit object.
OPTIONS
-------
@ -43,40 +43,49 @@ include::diff-options.txt[]
show tree entry itself as well as subtrees. Implies -r.
--root::
When '--root' is specified the initial commit will be showed as a big
When '--root' is specified the initial commit will be shown as a big
creation event. This is equivalent to a diff against the NULL tree.
--stdin::
When '--stdin' is specified, the command does not take
<tree-ish> arguments from the command line. Instead, it
reads either one <commit> or a list of <commit>
separated with a single space from its standard input.
reads lines containing either two <tree>, one <commit>, or a
list of <commit> from its standard input. (Use a single space
as separator.)
+
When a single commit is given on one line of such input, it compares
the commit with its parents. The following flags further affects its
behavior. The remaining commits, when given, are used as if they are
When two trees are given, it compares the first tree with the second.
When a single commit is given, it compares the commit with its
parents. The remaining commits, when given, are used as if they are
parents of the first commit.
+
When comparing two trees, the ID of both trees (separated by a space
and terminated by a newline) is printed before the difference. When
comparing commits, the ID of the first (or only) commit, followed by a
newline, is printed.
+
The following flags further affect the behavior when comparing
commits (but not trees).
-m::
By default, 'git-diff-tree --stdin' does not show
By default, 'git diff-tree --stdin' does not show
differences for merge commits. With this flag, it shows
differences to that commit from all of its parents. See
also '-c'.
-s::
By default, 'git-diff-tree --stdin' shows differences,
By default, 'git diff-tree --stdin' shows differences,
either in machine-readable form (without '-p') or in patch
form (with '-p'). This output can be suppressed. It is
only useful with '-v' flag.
-v::
This flag causes 'git-diff-tree --stdin' to also show
This flag causes 'git diff-tree --stdin' to also show
the commit message before the differences.
include::pretty-options.txt[]
--no-commit-id::
'git-diff-tree' outputs a line with the commit ID when
'git diff-tree' outputs a line with the commit ID when
applicable. This flag suppressed the commit ID output.
-c::
@ -150,8 +159,7 @@ HEAD commits it finds, which is even more interesting.
in case you care).
Output format
-------------
include::diff-format.txt[]

8
Documentation/git-diff.txt
View File

@ -33,6 +33,7 @@ forced by --no-index.
commit relative to the named <commit>. Typically you
would want comparison with the latest commit, so if you
do not give <commit>, it defaults to HEAD.
--staged is a synonym of --cached.
'git diff' [--options] <commit> [--] [<path>...]::
@ -83,8 +84,7 @@ 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
@ -157,6 +157,10 @@ $ git diff -R <2>
rewrites (very expensive).
<2> Output diff in reverse.
SEE ALSO
--------
linkgit:git-difftool[1]::
Show changes using common diff tools
Author
------

120
Documentation/git-difftool.txt Normal file
View File

@ -0,0 +1,120 @@
git-difftool(1)
===============
NAME
----
git-difftool - Show changes using common diff tools
SYNOPSIS
--------
'git difftool' [<options>] <commit>{0,2} [--] [<path>...]
DESCRIPTION
-----------
'git difftool' is a git command that allows you to compare and edit files
between revisions using common diff tools. 'git difftool' is a frontend
to 'git diff' and accepts the same options and arguments.
OPTIONS
-------
-y::
--no-prompt::
Do not prompt before launching a diff tool.
--prompt::
Prompt before each invocation of the diff tool.
This is the default behaviour; the option is provided to
override any configuration settings.
-t <tool>::
--tool=<tool>::
Use the diff tool specified by <tool>.
Valid merge tools are:
kdiff3, kompare, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff,
ecmerge, diffuse, opendiff, p4merge and araxis.
+
If a diff tool is not specified, 'git difftool'
will use the configuration variable `diff.tool`. If the
configuration variable `diff.tool` is not set, 'git difftool'
will pick a suitable default.
+
You can explicitly provide a full path to the tool by setting the
configuration variable `difftool.<tool>.path`. For example, you
can configure the absolute path to kdiff3 by setting
`difftool.kdiff3.path`. Otherwise, 'git difftool' assumes the
tool is available in PATH.
+
Instead of running one of the known diff tools,
'git difftool' can be customized to run an alternative program
by specifying the command line to invoke in a configuration
variable `difftool.<tool>.cmd`.
+
When 'git difftool' is invoked with this tool (either through the
`-t` or `--tool` option or the `diff.tool` configuration variable)
the configured command line will be invoked with the following
variables available: `$LOCAL` is set to the name of the temporary
file containing the contents of the diff pre-image and `$REMOTE`
is set to the name of the temporary file containing the contents
of the diff post-image. `$BASE` is provided for compatibility
with custom merge tool commands and has the same value as `$LOCAL`.
-x <command>::
--extcmd=<command>::
Specify a custom command for viewing diffs.
'git-difftool' ignores the configured defaults and runs
`$command $LOCAL $REMOTE` when this option is specified.
-g::
--gui::
When 'git-difftool' is invoked with the `-g` or `--gui` option
the default diff tool will be read from the configured
`diff.guitool` variable instead of `diff.tool`.
See linkgit:git-diff[1] for the full list of supported options.
CONFIG VARIABLES
----------------
'git difftool' falls back to 'git mergetool' config variables when the
difftool equivalents have not been defined.
diff.tool::
The default diff tool to use.
diff.guitool::
The default diff tool to use when `--gui` is specified.
difftool.<tool>.path::
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
difftool.<tool>.cmd::
Specify the command to invoke the specified diff tool.
+
See the `--tool=<tool>` option above for more details.
difftool.prompt::
Prompt before each invocation of the diff tool.
SEE ALSO
--------
linkgit:git-diff[1]::
Show changes between commits, commit and working tree, etc
linkgit:git-mergetool[1]::
Run merge conflict resolution tools to resolve merge conflicts
linkgit:git-config[1]::
Get and set repository or global options
AUTHOR
------
Written by David Aguilar <davvid@gmail.com>.
Documentation
--------------
Documentation by David Aguilar and the git-list <git@vger.kernel.org>.
GIT
---
Part of the linkgit:git[1] suite

41
Documentation/git-fast-export.txt
View File

@ -13,18 +13,18 @@ SYNOPSIS
DESCRIPTION
-----------
This program dumps the given revisions in a form suitable to be piped
into 'git-fast-import'.
into 'git fast-import'.
You can use it as a human readable bundle replacement (see
You can use it as a human-readable bundle replacement (see
linkgit:git-bundle[1]), or as a kind of an interactive
'git-filter-branch'.
'git filter-branch'.
OPTIONS
-------
--progress=<n>::
Insert 'progress' statements every <n> objects, to be shown by
'git-fast-import' during import.
'git fast-import' during import.
--signed-tags=(verbatim|warn|strip|abort)::
Specify how to handle signed tags. Since any transformation
@ -36,6 +36,17 @@ 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.
--tag-of-filtered-object=(abort|drop|rewrite)::
Specify how to handle tags whose tagged object is filtered out.
Since revisions and files to export can be limited by path,
tagged objects may be filtered completely.
+
When asking to 'abort' (which is the default), this program will die
when encountering such a tag. With 'drop' it will omit such tags from
the output. With 'rewrite', if the tagged object is a commit, it will
rewrite the tag to tag an ancestor commit (via parent rewriting; see
linkgit:git-rev-list[1])
-M::
-C::
Perform move and/or copy detection, as described in the
@ -65,6 +76,26 @@ If the backend uses a similar \--import-marks file, this allows for
incremental bidirectional exporting of the repository by keeping the
marks the same across runs.
--fake-missing-tagger::
Some old repositories have tags without a tagger. The
fast-import protocol was pretty strict about that, and did not
allow that. So fake a tagger to be able to fast-import the
output.
--no-data::
Skip output of blob objects and instead refer to blobs via
their original SHA-1 hash. This is useful when rewriting the
directory structure or history of a repository without
touching the contents of individual files. Note that the
resulting stream can only be used by a repository which
already contains the necessary objects.
[git-rev-list-args...]::
A list of arguments, acceptable to 'git rev-parse' and
'git rev-list', that specifies the specific objects and references
to export. For example, `master\~10..master` causes the
current master reference to be exported along with all objects
added since its 10th ancestor commit.
EXAMPLES
--------
@ -94,7 +125,7 @@ referenced by that revision range contains the string
Limitations
-----------
Since 'git-fast-import' cannot tag trees, you will not be
Since 'git fast-import' 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.

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