microsoft
/
git
зеркало из https://github.com/microsoft/git.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность

Merge 'build-in git-mktree' 

* commit '633e3556ccbc': (5835 commits)
  build-in git-mktree
  allow -t abbreviation for --track in git branch
  gitweb: Remove function prototypes (cleanup)
  Documentation: cloning to empty directory is allowed
  Clarify kind of conflict in merge-one-file helper
  git config: clarify --add and --get-color
  archive-tar.c: squelch a type mismatch warning
  Start 1.6.4 development
  Start 1.6.3.1 maintenance series.
  GIT 1.6.3
  t4029: use sh instead of bash
  t4200: convert sed expression which operates on non-text file to perl
  t4200: remove two unnecessary lines
  t/annotate-tests.sh: avoid passing a non-newline terminated file to sed
  t4118: avoid sed invocation on file without terminating newline
  t4118: add missing '&&'
  t8005: use egrep when extended regular expressions are required
  git-clean doc: the command only affects paths under $(cwd)
  improve error message in config.c
  t4018-diff-funcname: add cpp xfuncname pattern to syntax test
  ...
This commit is contained in:
Junio C Hamano 2011-11-10 09:05:31 -08:00
Родитель cd9519bd2c 633e3556cc
Коммит 77f143bf3e
1366 изменённых файлов: 173352 добавлений и 45952 удалений
Показать статистику Скачать Patch файл Скачать Diff файл Показать все файлы Свернуть все файлы

2
.gitattributes поставляемый Normal file
Просмотреть файл

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

27
.gitignore поставляемый
Просмотреть файл

@ -1,3 +1,4 @@
GIT-BUILD-OPTIONS
GIT-CFLAGS
GIT-GUI-VARS
GIT-VERSION-FILE
@ -10,6 +11,7 @@ git-apply
git-archimport
git-archive
git-bisect
git-bisect--helper
git-blame
git-branch
git-bundle
@ -25,7 +27,6 @@ git-clone
git-commit
git-commit-tree
git-config
git-convert-objects
git-count-objects
git-cvsexportcommit
git-cvsimport
@ -35,13 +36,15 @@ 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-findtags
git-fmt-merge-msg
git-for-each-ref
git-format-patch
@ -51,6 +54,7 @@ git-gc
git-get-tar-commit-id
git-grep
git-hash-object
git-help
git-http-fetch
git-http-push
git-imap-send
@ -58,7 +62,6 @@ git-index-pack
git-init
git-init-db
git-instaweb
git-local-fetch
git-log
git-lost-found
git-ls-files
@ -76,9 +79,9 @@ git-merge-one-file
git-merge-ours
git-merge-recursive
git-merge-resolve
git-merge-stupid
git-merge-subtree
git-mergetool
git-mergetool--lib
git-mktag
git-mktree
git-name-rev
@ -110,7 +113,6 @@ git-rev-list
git-rev-parse
git-revert
git-rm
git-runstatus
git-send-email
git-send-pack
git-sh-setup
@ -120,16 +122,12 @@ git-show
git-show-branch
git-show-index
git-show-ref
git-ssh-fetch
git-ssh-pull
git-ssh-push
git-ssh-upload
git-stage
git-stash
git-status
git-stripspace
git-submodule
git-svn
git-svnimport
git-symbolic-ref
git-tag
git-tar-tree
@ -143,19 +141,23 @@ 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-absolute-path
test-chmtime
test-ctype
test-date
test-delta
test-dump-cache-tree
test-genrandom
test-match-trees
test-parse-options
test-path-utils
test-sha1
test-sigchain
common-cmds.h
*.tar.gz
*.dsc
@ -172,3 +174,6 @@ config.status
config.mak.autogen
config.mak.append
configure
tags
TAGS
cscope*

14
.mailmap
Просмотреть файл

@ -5,31 +5,43 @@
# same person appearing not to be so.
#
Alexander Gavrilov <angavrilov@gmail.com>
Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Brian M. Carlson <sandals@crustytoothpaste.ath.cx>
Chris Shoemaker <c.shoemaker@cox.net>
Dana L. How <danahow@gmail.com>
Dana L. How <how@deathvalley.cswitch.com>
Daniel Barkalow <barkalow@iabervon.org>
David D. Kilzer <ddkilzer@kilzer.net>
David Kågedal <davidk@lysator.liu.se>
David S. Miller <davem@davemloft.net>
Dirk Süsserott <newsletter@dirk.my1.cc>
Fredrik Kuivinen <freku045@student.liu.se>
H. Peter Anvin <hpa@bonde.sc.orionmulti.com>
H. Peter Anvin <hpa@tazenda.sc.orionmulti.com>
H. Peter Anvin <hpa@trantor.hos.anvin.org>
Horst H. von Brand <vonbrand@inf.utfsm.cl>
İsmail Dönmez <ismail@pardus.org.tr>
Jay Soffian <jaysoffian+git@gmail.com>
Joachim Berdal Haga <cjhaga@fys.uio.no>
Jon Loeliger <jdl@freescale.com>
Jon Seymour <jon@blackcubes.dyndns.org>
Jonathan Nieder <jrnieder@uchicago.edu>
Junio C Hamano <junio@twinsun.com>
Karl Hasselström <kha@treskal.com>
Kent Engstrom <kent@lysator.liu.se>
Lars Doelle <lars.doelle@on-line ! de>
Lars Doelle <lars.doelle@on-line.de>
Li Hong <leehong@pku.edu.cn>
Lukas Sandström <lukass@etek.chalmers.se>
Martin Langhoff <martin@catalyst.net.nz>
Michael Coleman <tutufan@gmail.com>
Michael W. Olson <mwolson@gnu.org>
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>
Philippe Bruhat <book@cpan.org>
Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
René Scharfe <rene.scharfe@lsrfire.ath.cx>
Robert Fitzsimons <robfitz@273k.net>
@ -37,9 +49,11 @@ Sam Vilain <sam@vilain.net>
Santi Béjar <sbejar@gmail.com>
Sean Estabrooks <seanlkml@sympatico.ca>
Shawn O. Pearce <spearce@spearce.org>
Steven Grimm <koreth@midwinter.com>
Theodore Ts'o <tytso@mit.edu>
Tony Luck <tony.luck@intel.com>
Uwe Kleine-König <Uwe_Zeisberger@digi.com>
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Uwe Kleine-König <uzeisberger@io.fsforth.de>
Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>

1
Documentation/.gitattributes поставляемый Normal file
Просмотреть файл

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

3
Documentation/.gitignore поставляемый
Просмотреть файл

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

134
Documentation/CodingGuidelines Normal file
Просмотреть файл

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

249
Documentation/Makefile
Просмотреть файл

@ -1,25 +1,27 @@
MAN1_TXT= \
$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard git-*.txt)) \
gitk.txt
MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt
MAN7_TXT=git.txt
gitk.txt git.txt
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 gitworkflows.txt
DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT))
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
ARTICLES = tutorial
ARTICLES += tutorial-2
ARTICLES += core-tutorial
ARTICLES += cvs-migration
ARTICLES += diffcore
ARTICLES += howto-index
ARTICLES += repository-layout
ARTICLES += hooks
DOC_HTML=$(MAN_HTML)
ARTICLES = howto-index
ARTICLES += everyday
ARTICLES += git-tools
ARTICLES += glossary
# with their own formatting rules.
SP_ARTICLES = howto/revert-branch-rebase user-manual
SP_ARTICLES = howto/revert-branch-rebase howto/using-merge-subtree user-manual
API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
SP_ARTICLES += $(API_DOCS)
SP_ARTICLES += technical/api-index
DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))
@ -29,6 +31,8 @@ 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
@ -37,21 +41,72 @@ man7dir=$(mandir)/man7
ASCIIDOC=asciidoc
ASCIIDOC_EXTRA =
ifdef ASCIIDOC8
ASCIIDOC_EXTRA += -a asciidoc7compatible
endif
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
-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
endif
ifdef 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
SHELL_PATH ?= $(SHELL)
# Shell quote;
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
#
# Please note that there is a minor bug in asciidoc.
# The version after 6.0.3 _will_ include the patch found here:
@ -61,6 +116,32 @@ DOCBOOK2X_TEXI=docbook2x-texi
# 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)
@ -72,27 +153,39 @@ man1: $(DOC_MAN1)
man5: $(DOC_MAN5)
man7: $(DOC_MAN7)
info: git.info
info: git.info gitman.info
install: man
$(INSTALL) -d -m755 $(DESTDIR)$(man1dir)
$(INSTALL) -d -m755 $(DESTDIR)$(man5dir)
$(INSTALL) -d -m755 $(DESTDIR)$(man7dir)
$(INSTALL) -m644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
$(INSTALL) -m644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
$(INSTALL) -m644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
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)
$(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
$(INSTALL) -m 644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
$(INSTALL) -m 644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
install-info: info
$(INSTALL) -d -m755 $(DESTDIR)$(infodir)
$(INSTALL) -m644 git.info $(DESTDIR)$(infodir)
$(INSTALL) -d -m 755 $(DESTDIR)$(infodir)
$(INSTALL) -m 644 git.info gitman.info $(DESTDIR)$(infodir)
if test -r $(DESTDIR)$(infodir)/dir; then \
$(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\
$(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) gitman.info ;\
else \
echo "No directory found in $(DESTDIR)$(infodir)" >&2 ; \
fi
install-pdf: pdf
$(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir)
$(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir)
install-html: html
'$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir)
../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
$(MAKE) -C ../ GIT-VERSION-FILE
$(QUIET_SUBDIR0)../ $(QUIET_SUBDIR1) GIT-VERSION-FILE
-include ../GIT-VERSION-FILE
@ -100,8 +193,8 @@ install-info: info
# Determine "include::" file references in asciidoc files.
#
doc.dep : $(wildcard *.txt) build-docdep.perl
$(RM) $@+ $@
perl ./build-docdep.perl >$@+
$(QUIET_GEN)$(RM) $@+ $@ && \
$(PERL_PATH) ./build-docdep.perl >$@+ $(QUIET_STDERR) && \
mv $@+ $@
-include doc.dep
@ -118,68 +211,106 @@ cmds_txt = cmds-ancillaryinterrogators.txt \
$(cmds_txt): cmd-list.made
cmd-list.made: cmd-list.perl $(MAN1_TXT)
$(RM) $@
perl ./cmd-list.perl
cmd-list.made: cmd-list.perl ../command-list.txt $(MAN1_TXT)
$(QUIET_GEN)$(RM) $@ && \
$(PERL_PATH) ./cmd-list.perl ../command-list.txt $(QUIET_STDERR) && \
date >$@
git.7 git.html: git.txt core-intro.txt
clean:
$(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 *.texi *.texi+ howto-index.txt howto/*.html doc.dep
$(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7
$(RM) *.texi *.texi+ *.texi++ git.info gitman.info
$(RM) howto-index.txt howto/*.html doc.dep
$(RM) technical/api-*.html technical/api-index.txt
$(RM) $(cmds_txt) *.made
%.html : %.txt
$(RM) $@+ $@
$(MAN_HTML): %.html : %.txt
$(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 callouts.xsl man $<
$(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))
$(QUIET_GEN)cd technical && '$(SHELL_PATH_SQ)' ./api-index.sh
$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt
$(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.xml
$(RM) $@ $*.texi $*.texi+
$(DOCBOOK2X_TEXI) user-manual.xml --to-stdout >$*.texi+
perl fix-texi.perl <$*.texi+ >$*.texi
$(MAKEINFO) --no-split $*.texi
$(RM) $*.texi $*.texi+
git.info: user-manual.texi
$(QUIET_MAKEINFO)$(MAKEINFO) --no-split -o $@ user-manual.texi
user-manual.texi: user-manual.xml
$(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
$(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
$(QUIET_MAKEINFO)$(MAKEINFO) --no-split --no-validate $*.texi
$(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.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) $(mandir)
quick-install: quick-install-man
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-GIT-VERSION-FILE

2
Documentation/RelNotes-1.5.2.2.txt
Просмотреть файл

@ -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.

2
Documentation/RelNotes-1.5.2.txt
Просмотреть файл

@ -36,7 +36,7 @@ Updates since v1.5.1
expansion). These conversions apply when checking files in
or out, and exporting via git-archive.
* The packfile format now optionally suports 64-bit index.
* The packfile format now optionally supports 64-bit index.
This release supports the "version 2" format of the .idx
file. This is automatically enabled when a huge packfile

58
Documentation/RelNotes-1.5.3.2.txt Normal file
Просмотреть файл

@ -0,0 +1,58 @@
GIT v1.5.3.2 Release Notes
==========================
Fixes since v1.5.3.1
--------------------
* git-push sent thin packs by default, which was not good for
the public distribution server (no point in saving transfer
while pushing; no point in making the resulting pack less
optimum).
* git-svn sometimes terminated with "Malformed network data" when
talking over svn:// protocol.
* git-send-email re-issued the same message-id about 10% of the
time if you fired off 30 messages within a single second.
* git-stash was not terminating the log message of commits it
internally creates with LF.
* git-apply failed to check the size of the patch hunk when its
beginning part matched the remainder of the preimage exactly,
even though the preimage recorded in the hunk was much larger
(therefore the patch should not have applied), leading to a
segfault.
* "git rm foo && git commit foo" complained that 'foo' needs to
be added first, instead of committing the removal, which was a
nonsense.
* git grep -c said "/dev/null: 0".
* git-add -u failed to recognize a blob whose type changed
between the index and the work tree.
* The limit to rename detection has been tightened a lot to
reduce performance problems with a huge change.
* cvsimport and svnimport barfed when the input tried to move
a tag.
* "git apply -pN" did not chop the right number of directories.
* "git svnimport" did not like SVN tags with funny characters in them.
* git-gui 0.8.3, with assorted fixes, including:
- font-chooser on X11 was unusable with large number of fonts;
- a diff that contained a deleted symlink made it barf;
- an untracked symbolic link to a directory made it fart;
- a file with % in its name made it vomit;
Documentation updates
---------------------
User manual has been somewhat restructured. I think the new
organization is much easier to read.

31
Documentation/RelNotes-1.5.3.3.txt Normal file
Просмотреть файл

@ -0,0 +1,31 @@
GIT v1.5.3.3 Release Notes
==========================
Fixes since v1.5.3.2
--------------------
* git-quiltimport did not like it when a patch described in the
series file does not exist.
* p4 importer missed executable bit in some cases.
* The default shell on some FreeBSD did not execute the
argument parsing code correctly and made git unusable.
* git-svn incorrectly spawned pager even when the user
explicitly asked not to.
* sample post-receive hook overquoted the envelope sender
value.
* git-am got confused when the patch contained a change that is
only about type and not contents.
* git-mergetool did not show our and their version of the
conflicted file when started from a subdirectory of the
project.
* git-mergetool did not pass correct options when invoking diff3.
* git-log sometimes invoked underlying "diff" machinery
unnecessarily.

35
Documentation/RelNotes-1.5.3.4.txt Normal file
Просмотреть файл

@ -0,0 +1,35 @@
GIT v1.5.3.4 Release Notes
==========================
Fixes since v1.5.3.3
--------------------
* Change to "git-ls-files" in v1.5.3.3 that was introduced to support
partial commit of removal better had a segfaulting bug, which was
diagnosed and fixed by Keith and Carl.
* Performance improvements for rename detection has been backported
from the 'master' branch.
* "git-for-each-ref --format='%(numparent)'" was not working
correctly at all, and --format='%(parent)' was not working for
merge commits.
* Sample "post-receive-hook" incorrectly sent out push
notification e-mails marked as "From: " the committer of the
commit that happened to be at the tip of the branch that was
pushed, not from the person who pushed.
* "git-remote" did not exit non-zero status upon error.
* "git-add -i" did not respond very well to EOF from tty nor
bogus input.
* "git-rebase -i" squash subcommand incorrectly made the
author of later commit the author of resulting commit,
instead of taking from the first one in the squashed series.
* "git-stash apply --index" was not documented.
* autoconfiguration learned that "ar" command is found as "gas" on
some systems.

94
Documentation/RelNotes-1.5.3.5.txt Normal file
Просмотреть файл

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

48
Documentation/RelNotes-1.5.3.6.txt Normal file
Просмотреть файл

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

45
Documentation/RelNotes-1.5.3.7.txt Normal file
Просмотреть файл

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

25
Documentation/RelNotes-1.5.3.8.txt Normal file
Просмотреть файл

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

6
Documentation/RelNotes-1.5.3.txt
Просмотреть файл

@ -86,7 +86,7 @@ Updates since v1.5.2
- "git rev-list" learned --regexp-ignore-case and
--extended-regexp options to tweak its matching logic used
for --grep fitering.
for --grep filtering.
- "git describe --contains" is a handier way to call more
obscure command "git name-rev --tags".
@ -243,7 +243,7 @@ Updates since v1.5.2
- We used to have core.legacyheaders configuration, when
set to false, allowed git to write loose objects in a format
that mimicks the format used by objects stored in packs. It
that mimics the format used by objects stored in packs. It
turns out that this was not so useful. Although we will
continue to read objects written in that format, we do not
honor that configuration anymore and create loose objects in
@ -302,7 +302,7 @@ Updates since v1.5.2
small enough delta results it creates while looking for the
best delta candidates.
- "git pack-objects" learned a new heuristcs to prefer delta
- "git pack-objects" learned a new heuristic to prefer delta
that is shallower in depth over the smallest delta
possible. This improves both overall packfile access
performance and packfile density.

17
Documentation/RelNotes-1.5.4.1.txt Normal file
Просмотреть файл

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

43
Documentation/RelNotes-1.5.4.2.txt Normal file
Просмотреть файл

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

27
Documentation/RelNotes-1.5.4.3.txt Normal file
Просмотреть файл

@ -0,0 +1,27 @@
GIT v1.5.4.3 Release Notes
==========================
Fixes since v1.5.4.2
--------------------
* RPM spec used to pull in everything with 'git'. This has been
changed so that 'git' package contains just the core parts,
and we now supply 'git-all' metapackage to slurp in everything.
This should match end user's expectation better.
* When some refs failed to update, git-push reported "failure"
which was unclear if some other refs were updated or all of
them failed atomically (the answer is the former). Reworded
the message to clarify this.
* "git clone" from a repository whose HEAD was misconfigured
did not set up the remote properly. Now it tries to do
better.
* Updated git-push documentation to clarify what "matching"
means, in order to reduce user confusion.
* Updated git-add documentation to clarify "add -u" operates in
the current subdirectory you are in, just like other commands.
* git-gui updates to work on OSX and Windows better.

66
Documentation/RelNotes-1.5.4.4.txt Normal file
Просмотреть файл

@ -0,0 +1,66 @@
GIT v1.5.4.4 Release Notes
==========================
Fixes since v1.5.4.3
--------------------
* Building and installing with an overtight umask such as 077 made
installed templates unreadable by others, while the rest of the install
are done in a way that is friendly to umask 022.
* "git cvsexportcommit -w $cvsdir" misbehaved when GIT_DIR is set to a
relative directory.
* "git http-push" had an invalid memory access that could lead it to
segfault.
* When "git rebase -i" gave control back to the user for a commit that is
marked to be edited, it just said "modify it with commit --amend",
without saying what to do to continue after modifying it. Give an
explicit instruction to run "rebase --continue" to be more helpful.
* "git send-email" in 1.5.4.3 issued a bogus empty In-Reply-To: header.
* "git bisect" showed mysterious "won't bisect on seeked tree" error message.
This was leftover from Cogito days to prevent "bisect" starting from a
cg-seeked state. We still keep the Cogito safety, but running "git bisect
start" when another bisect was in effect will clean up and start over.
* "git push" with an explicit PATH to receive-pack did not quite work if
receive-pack was not on usual PATH. We earlier fixed the same issue
with "git fetch" and upload-pack, but somehow forgot to do so in the
other direction.
* git-gui's info dialog was not displayed correctly when the user tries
to commit nothing (i.e. without staging anything).
* "git revert" did not properly fail when attempting to run with a
dirty index.
* "git merge --no-commit --no-ff <other>" incorrectly made commits.
* "git merge --squash --no-ff <other>", which is a nonsense combination
of options, was not rejected.
* "git ls-remote" and "git remote show" against an empty repository
failed, instead of just giving an empty result (regression).
* "git fast-import" did not handle a renamed path whose name needs to be
quoted, due to a bug in unquote_c_style() function.
* "git cvsexportcommit" was confused when multiple files with the same
basename needed to be pushed out in the same commit.
* "git daemon" did not send early errors to syslog.
* "git log --merge" did not work well with --left-right option.
* "git svn" prompted for client cert password every time it accessed the
server.
* The reset command in "git fast-import" data stream was documented to
end with an optional LF, but it actually required one.
* "git svn dcommit/rebase" did not honor --rewrite-root option.
Also included are a handful documentation updates.

56
Documentation/RelNotes-1.5.4.5.txt Normal file
Просмотреть файл

@ -0,0 +1,56 @@
GIT v1.5.4.5 Release Notes
==========================
Fixes since v1.5.4.4
--------------------
* "git fetch there" when the URL information came from the Cogito style
branches/there file did not update refs/heads/there (regression in
1.5.4).
* Bogus refspec configuration such as "remote.there.fetch = =" were not
detected as errors (regression in 1.5.4).
* You couldn't specify a custom editor whose path contains a whitespace
via GIT_EDITOR (and core.editor).
* The subdirectory filter to "git filter-branch" mishandled a history
where the subdirectory becomes empty and then later becomes non-empty.
* "git shortlog" gave an empty line if the original commit message was
malformed (e.g. a botched import from foreign SCM). Now it finds the
first non-empty line and uses it for better information.
* When the user fails to give a revision parameter to "git svn", an error
from the Perl interpreter was issued because the script lacked proper
error checking.
* After "git rebase" stopped due to conflicts, if the user played with
"git reset" and friends, "git rebase --abort" failed to go back to the
correct commit.
* Additional work trees prepared with git-new-workdir (in contrib/) did
not share git-svn metadata directory .git/svn with the original.
* "git-merge-recursive" did not mark addition of the same path with
different filemodes correctly as a conflict.
* "gitweb" gave malformed URL when pathinfo stype paths are in use.
* "-n" stands for "--no-tags" again for "git fetch".
* "git format-patch" did not detect the need to add 8-bit MIME header
when the user used format.header configuration.
* "rev~" revision specifier used to mean "rev", which was inconsistent
with how "rev^" worked. Now "rev~" is the same as "rev~1" (hence it
also is the same as "rev^1"), and "rev~0" is the same as "rev^0"
(i.e. it has to be a commit).
* "git quiltimport" did not grok empty lines, lines in "file -pNNN"
format to specify the prefix levels and lines with trailing comments.
* "git rebase -m" triggered pre-commit verification, which made
"rebase --continue" impossible.
As usual, it also comes with many documentation fixes and clarifications.

43
Documentation/RelNotes-1.5.4.6.txt Normal file
Просмотреть файл

@ -0,0 +1,43 @@
GIT v1.5.4.6 Release Notes
==========================
I personally do not think there is any reason anybody should want to
run v1.5.4.X series these days, because 'master' version is always
more stable than any tagged released version of git.
This is primarily to futureproof "git-shell" to accept requests
without a dash between "git" and subcommand name (e.g. "git
upload-pack") which the newer client will start to make sometime in
the future.
Fixes since v1.5.4.5
--------------------
* Command line option "-n" to "git-repack" was not correctly parsed.
* Error messages from "git-apply" when the patchfile cannot be opened
have been improved.
* Error messages from "git-bisect" when given nonsense revisions have
been improved.
* reflog syntax that uses time e.g. "HEAD@{10 seconds ago}:path" did not
stop parsing at the closing "}".
* "git rev-parse --symbolic-full-name ^master^2" printed solitary "^",
but it should print nothing.
* "git apply" did not enforce "match at the beginning" correctly.
* a path specification "a/b" in .gitattributes file should not match
"sub/a/b", but it did.
* "git log --date-order --topo-order" did not override the earlier
date-order with topo-order as expected.
* "git fast-export" did not export octopus merges correctly.
* "git archive --prefix=$path/" mishandled gitattributes.
As usual, it also comes with many documentation fixes and clarifications.

10
Documentation/RelNotes-1.5.4.7.txt Normal 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.

363
Documentation/RelNotes-1.5.4.txt
Просмотреть файл

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

44
Documentation/RelNotes-1.5.5.1.txt Normal file
Просмотреть файл

@ -0,0 +1,44 @@
GIT v1.5.5.1 Release Notes
==========================
Fixes since v1.5.5
------------------
* "git archive --prefix=$path/" mishandled gitattributes.
* "git fetch -v" that fetches into FETCH_HEAD did not report the summary
the same way as done for updating the tracking refs.
* "git svn" misbehaved when the configuration file customized the "git
log" output format using format.pretty.
* "git submodule status" leaked an unnecessary error message.
* "git log --date-order --topo-order" did not override the earlier
date-order with topo-order as expected.
* "git bisect good $this" did not check the validity of the revision
given properly.
* "url.<there>.insteadOf" did not work correctly.
* "git clean" ran inside subdirectory behaved as if the directory was
explicitly specified for removal by the end user from the top level.
* "git bisect" from a detached head leaked an unnecessary error message.
* "git bisect good $a $b" when $a is Ok but $b is bogus should have
atomically failed before marking $a as good.
* "git fmt-merge-msg" did not clean up leading empty lines from commit
log messages like "git log" family does.
* "git am" recorded a commit with empty Subject: line without
complaining.
* when given a commit log message whose first paragraph consists of
multiple lines, "git rebase" squashed it into a single line.
* "git remote add $bogus_name $url" did not complain properly.
Also comes with various documentation updates.

27
Documentation/RelNotes-1.5.5.2.txt Normal file
Просмотреть файл

@ -0,0 +1,27 @@
GIT v1.5.5.2 Release Notes
==========================
Fixes since v1.5.5.1
--------------------
* "git repack -n" was mistakenly made no-op earlier.
* "git imap-send" wanted to always have imap.host even when use of
imap.tunnel made it unnecessary.
* reflog syntax that uses time e.g. "HEAD@{10 seconds ago}:path" did not
stop parsing at the closing "}".
* "git rev-parse --symbolic-full-name ^master^2" printed solitary "^",
but it should print nothing.
* "git commit" did not detect when it failed to write tree objects.
* "git fetch" sometimes transferred too many objects unnecessarily.
* a path specification "a/b" in .gitattributes file should not match
"sub/a/b".
* various gitweb fixes.
Also comes with various documentation updates.

12
Documentation/RelNotes-1.5.5.3.txt Normal file
Просмотреть файл

@ -0,0 +1,12 @@
GIT v1.5.5.3 Release Notes
==========================
Fixes since v1.5.5.2
--------------------
* "git send-email --compose" did not notice that non-ascii contents
needed some MIME magic.
* "git fast-export" did not export octopus merges correctly.
Also comes with various documentation updates.

7
Documentation/RelNotes-1.5.5.4.txt Normal file
Просмотреть файл

@ -0,0 +1,7 @@
GIT v1.5.5.4 Release Notes
==========================
Fixes since v1.5.5.4
--------------------
* "git name-rev --all" used to segfault.

11
Documentation/RelNotes-1.5.5.5.txt Normal file
Просмотреть файл

@ -0,0 +1,11 @@
GIT v1.5.5.5 Release Notes
==========================
I personally do not think there is any reason anybody should want to
run v1.5.5.X series these days, because 'master' version is always
more stable than any tagged released version of git.
This is primarily to futureproof "git-shell" to accept requests
without a dash between "git" and subcommand name (e.g. "git
upload-pack") which the newer client will start to make sometime in
the future.

10
Documentation/RelNotes-1.5.5.6.txt Normal 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.

207
Documentation/RelNotes-1.5.5.txt Normal file
Просмотреть файл

@ -0,0 +1,207 @@
GIT v1.5.5 Release Notes
========================
Updates since v1.5.4
--------------------
(subsystems)
* Comes with git-gui 0.10.1
(portability)
* We shouldn't ask for BSD group ownership semantics by setting g+s bit
on directories on older BSD systems that refuses chmod() by non root
users. BSD semantics is the default there anyway.
* Bunch of portability improvement patches coming from an effort to port
to Solaris has been applied.
(performance)
* On platforms with suboptimal qsort(3) implementation, there
is an option to use more reasonable substitute we ship with
our software.
* New configuration variable "pack.packsizelimit" can be used
in place of command line option --max-pack-size.
* "git fetch" over the native git protocol used to make a
connection to find out the set of current remote refs and
another to actually download the pack data. We now use only
one connection for these tasks.
* "git commit" does not run lstat(2) more than necessary
anymore.
(usability, bells and whistles)
* Bash completion script (in contrib) are aware of more commands and
options.
* You can be warned when core.autocrlf conversion is applied in
such a way that results in an irreversible conversion.
* A catch-all "color.ui" configuration variable can be used to
enable coloring of all color-capable commands, instead of
individual ones such as "color.status" and "color.branch".
* The commands refused to take absolute pathnames where they
require pathnames relative to the work tree or the current
subdirectory. They now can take absolute pathnames in such a
case as long as the pathnames do not refer outside of the
work tree. E.g. "git add $(pwd)/foo" now works.
* Error messages used to be sent to stderr, only to get hidden,
when $PAGER was in use. They now are sent to stdout along
with the command output to be shown in the $PAGER.
* A pattern "foo/" in .gitignore file now matches a directory
"foo". Pattern "foo" also matches as before.
* bash completion's prompt helper function can talk about
operation in-progress (e.g. merge, rebase, etc.).
* Configuration variables "url.<usethis>.insteadof = <otherurl>" can be
used to tell "git-fetch" and "git-push" to use different URL than what
is given from the command line.
* "git add -i" behaves better even before you make an initial commit.
* "git am" refused to run from a subdirectory without a good reason.
* After "git apply --whitespace=fix" fixes whitespace errors in a patch,
a line before the fix can appear as a context or preimage line in a
later patch, causing the patch not to apply. The command now knows to
see through whitespace fixes done to context lines to successfully
apply such a patch series.
* "git branch" (and "git checkout -b") to branch from a local branch can
optionally set "branch.<name>.merge" to mark the new branch to build on
the other local branch, when "branch.autosetupmerge" is set to
"always", or when passing the command line option "--track" (this option
was ignored when branching from local branches). By default, this does
not happen when branching from a local branch.
* "git checkout" to switch to a branch that has "branch.<name>.merge" set
(i.e. marked to build on another branch) reports how much the branch
and the other branch diverged.
* When "git checkout" has to update a lot of paths, it used to be silent
for 4 seconds before it showed any progress report. It is now a bit
more impatient and starts showing progress report early.
* "git commit" learned a new hook "prepare-commit-msg" that can
inspect what is going to be committed and prepare the commit
log message template to be edited.
* "git cvsimport" can now take more than one -M options.
* "git describe" learned to limit the tags to be used for
naming with --match option.
* "git describe --contains" now barfs when the named commit
cannot be described.
* "git describe --exact-match" describes only commits that are tagged.
* "git describe --long" describes a tagged commit as $tag-0-$sha1,
instead of just showing the exact tagname.
* "git describe" warns when using a tag whose name and path contradict
with each other.
* "git diff" learned "--relative" option to limit and output paths
relative to the current directory when working in a subdirectory.
* "git diff" learned "--dirstat" option to show birds-eye-summary of
changes more concisely than "--diffstat".
* "git format-patch" learned --cover-letter option to generate a cover
letter template.
* "git gc" learned --quiet option.
* "git gc" now automatically prunes unreachable objects that are two
weeks old or older.
* "git gc --auto" can be disabled more easily by just setting gc.auto
to zero. It also tolerates more packfiles by default.
* "git grep" now knows "--name-only" is a synonym for the "-l" option.
* "git help <alias>" now reports "'git <alias>' is alias to <what>",
instead of saying "No manual entry for git-<alias>".
* "git help" can use different backends to show manual pages and this can
be configured using "man.viewer" configuration.
* "gitk" does not restore window position from $HOME/.gitk anymore (it
still restores the size).
* "git log --grep=<what>" learned "--fixed-strings" option to look for
<what> without treating it as a regular expression.
* "git gui" learned an auto-spell checking.
* "git push <somewhere> HEAD" and "git push <somewhere> +HEAD" works as
expected; they push the current branch (and only the current branch).
In addition, HEAD can be written as the value of "remote.<there>.push"
configuration variable.
* When the configuration variable "pack.threads" is set to 0, "git
repack" auto detects the number of CPUs and uses that many threads.
* "git send-email" learned to prompt for passwords
interactively.
* "git send-email" learned an easier way to suppress CC
recipients.
* "git stash" learned "pop" command, that applies the latest stash and
removes it from the stash, and "drop" command to discard the named
stash entry.
* "git submodule" learned a new subcommand "summary" to show the
symmetric difference between the HEAD version and the work tree version
of the submodule commits.
* Various "git cvsimport", "git cvsexportcommit", "git cvsserver",
"git svn" and "git p4" improvements.
(internal)
* Duplicated code between git-help and git-instaweb that
launches user's preferred browser has been refactored.
* It is now easier to write test scripts that records known
breakages.
* "git checkout" is rewritten in C.
* "git remote" is rewritten in C.
* Two conflict hunks that are separated by a very short span of common
lines are now coalesced into one larger hunk, to make the result easier
to read.
* Run-command API's use of file descriptors is documented clearer and
is more consistent now.
* diff output can be sent to FILE * that is different from stdout. This
will help reimplementing more things in C.
Fixes since v1.5.4
------------------
All of the fixes in v1.5.4 maintenance series are included in
this release, unless otherwise noted.
* "git-http-push" did not allow deletion of remote ref with the usual
"push <remote> :<branch>" syntax.
* "git-rebase --abort" did not go back to the right location if
"git-reset" was run during the "git-rebase" session.
* "git imap-send" without setting imap.host did not error out but
segfaulted.

28
Documentation/RelNotes-1.5.6.1.txt Normal file
Просмотреть файл

@ -0,0 +1,28 @@
GIT v1.5.6.1 Release Notes
==========================
Fixes since v1.5.6
------------------
* Last minute change broke loose object creation on AIX.
* (performance fix) We used to make $GIT_DIR absolute path early in the
programs but keeping it relative to the current directory internally
gives 1-3 per-cent performance boost.
* bash completion knows the new --graph option to git-log family.
* git-diff -c/--cc showed unnecessary "deletion" lines at the context
boundary.
* git-for-each-ref ignored %(object) and %(type) requests for tag
objects.
* git-merge usage had a typo.
* Rebuilding of git-svn metainfo database did not take rewriteRoot
option into account.
* Running "git-rebase --continue/--skip/--abort" before starting a
rebase gave nonsense error messages.

40
Documentation/RelNotes-1.5.6.2.txt Normal file
Просмотреть файл

@ -0,0 +1,40 @@
GIT v1.5.6.2 Release Notes
==========================
Futureproof
-----------
* "git-shell" accepts requests without a dash between "git" and
subcommand name (e.g. "git upload-pack") which the newer client will
start to make sometime in the future.
Fixes since v1.5.6.1
--------------------
* "git clone" from a remote that is named with url.insteadOf setting in
$HOME/.gitconfig did not work well.
* "git describe --long --tags" segfaulted when the described revision was
tagged with a lightweight tag.
* "git diff --check" did not report the result via its exit status
reliably.
* When remote side used to have branch 'foo' and git-fetch finds that now
it has branch 'foo/bar', it refuses to lose the existing remote tracking
branch and its reflog. The error message has been improved to suggest
pruning the remote if the user wants to proceed and get the latest set
of branches from the remote, including such 'foo/bar'.
* "git reset file" should mean the same thing as "git reset HEAD file",
but we required disambiguating -- even when "file" is not ambiguous.
* "git show" segfaulted when an annotated tag that points at another
annotated tag was given to it.
* Optimization for a large import via "git-svn" introduced in v1.5.6 had a
serious memory and temporary file leak, which made it unusable for
moderately large import.
* "git-svn" mangled remote nickname used in the configuration file
unnecessarily.

52
Documentation/RelNotes-1.5.6.3.txt Normal file
Просмотреть файл

@ -0,0 +1,52 @@
GIT v1.5.6.3 Release Notes
==========================
Fixes since v1.5.6.2
--------------------
* Setting core.sharerepository to traditional "true" value was supposed to make
the repository group writable but should not affect permission for others.
However, since 1.5.6, it was broken to drop permission for others when umask is
022, making the repository unreadable by others.
* Setting GIT_TRACE will report spawning of external process via run_command().
* Using an object with very deep delta chain pinned memory needed for extracting
intermediate base objects unnecessarily long, leading to excess memory usage.
* Bash completion script did not notice '--' marker on the command
line and tried the relatively slow "ref completion" even when
completing arguments after one.
* Registering a non-empty blob racily and then truncating the working
tree file for it confused "racy-git avoidance" logic into thinking
that the path is now unchanged.
* The section that describes attributes related to git-archive were placed
in a wrong place in the gitattributes(5) manual page.
* "git am" was not helpful to the users when it detected that the committer
information is not set up properly yet.
* "git clone" had a leftover debugging fprintf().
* "git clone -q" was not quiet enough as it used to and gave object count
and progress reports.
* "git clone" marked downloaded packfile with .keep; this could be a
good thing if the remote side is well packed but otherwise not,
especially for a project that is not really big.
* "git daemon" used to call syslog() from a signal handler, which
could raise signals of its own but generally is not reentrant. This
was fixed by restructuring the code to report syslog() after the handler
returns.
* When "git push" tries to remove a remote ref, and corresponding
tracking ref is missing, we used to report error (i.e. failure to
remove something that does not exist).
* "git mailinfo" (hence "git am") did not handle commit log messages in a
MIME multipart mail correctly.
Contains other various documentation fixes.

47
Documentation/RelNotes-1.5.6.4.txt Normal file
Просмотреть файл

@ -0,0 +1,47 @@
GIT v1.5.6.4 Release Notes
==========================
Fixes since v1.5.6.3
--------------------
* Various commands could overflow its internal buffer on a platform
with small PATH_MAX value in a repository that has contents with
long pathnames.
* There wasn't a way to make --pretty=format:%<> specifiers to honor
.mailmap name rewriting for authors and committers. Now you can with
%aN and %cN.
* Bash completion wasted too many cycles; this has been optimized to be
usable again.
* Bash completion lost ref part when completing something like "git show
pu:Makefile".
* "git-cvsserver" did not clean up its temporary working area after annotate
request.
* "git-daemon" called syslog() from its signal handler, which was a
no-no.
* "git-fetch" into an empty repository used to remind that the fetch will
be huge by saying "no common commits", but this was an unnecessary
noise; it is already known by the user anyway.
* "git-http-fetch" would have segfaulted when pack idx file retrieved
from the other side was corrupt.
* "git-index-pack" used too much memory when dealing with a deep delta chain.
* "git-mailinfo" (hence "git-am") did not correctly handle in-body [PATCH]
line to override the commit title taken from the mail Subject header.
* "git-rebase -i -p" lost parents that are not involved in the history
being rewritten.
* "git-rm" lost track of where the index file was when GIT_DIR was
specified as a relative path.
* "git-rev-list --quiet" was not quiet as advertised.
Contains other various documentation fixes.

29
Documentation/RelNotes-1.5.6.5.txt Normal file
Просмотреть файл

@ -0,0 +1,29 @@
GIT v1.5.6.5 Release Notes
==========================
Fixes since v1.5.6.4
--------------------
* "git cvsimport" used to spit out "UNKNOWN LINE..." diagnostics to stdout.
* "git commit -F filename" and "git tag -F filename" run from subdirectories
did not read the right file.
* "git init --template=" with blank "template" parameter linked files
under root directories to .git, which was a total nonsense. Instead, it
means "I do not want to use anything from the template directory".
* "git diff-tree" and other diff plumbing ignored diff.renamelimit configuration
variable when the user explicitly asked for rename detection.
* "git name-rev --name-only" did not work when "--stdin" option was in effect.
* "git show-branch" mishandled its 8th branch.
* Addition of "git update-index --ignore-submodules" that happened during
1.5.6 cycle broke "git update-index --ignore-missing".
* "git send-email" did not parse charset from an existing Content-type:
header properly.
Contains other various documentation fixes.

10
Documentation/RelNotes-1.5.6.6.txt Normal 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.

115
Documentation/RelNotes-1.5.6.txt Normal file
Просмотреть файл

@ -0,0 +1,115 @@
GIT v1.5.6 Release Notes
========================
Updates since v1.5.5
--------------------
(subsystems)
* Comes with updated gitk and git-gui.
(portability)
* git will build on AIX better than before now.
* core.ignorecase configuration variable can be used to work better on
filesystems that are not case sensitive.
* "git init" now autodetects the case sensitivity of the filesystem and
sets core.ignorecase accordingly.
* cpio is no longer used; neither "curl" binary (libcurl is still used).
(documentation)
* Many freestanding documentation pages have been converted and made
available to "git help" (aka "man git<something>") as section 7 of
the manual pages. This means bookmarks to some HTML documentation
files may need to be updated (eg "tutorial.html" became
"gittutorial.html").
(performance)
* "git clone" was rewritten in C. This will hopefully help cloning a
repository with insane number of refs.
* "git rebase --onto $there $from $branch" used to switch to the tip of
$branch only to immediately reset back to $from, smudging work tree
files unnecessarily. This has been optimized.
* Object creation codepath in "git-svn" has been optimized by enhancing
plumbing commands git-cat-file and git-hash-object.
(usability, bells and whistles)
* "git add -p" (and the "patch" subcommand of "git add -i") can choose to
apply (or not apply) mode changes independently from contents changes.
* "git bisect help" gives longer and more helpful usage information.
* "git bisect" does not use a special branch "bisect" anymore; instead, it
does its work on a detached HEAD.
* "git branch" (and "git checkout -b") can be told to set up
branch.<name>.rebase automatically, so that later you can say "git pull"
and magically cause "git pull --rebase" to happen.
* "git branch --merged" and "git branch --no-merged" can be used to list
branches that have already been merged (or not yet merged) to the
current branch.
* "git cherry-pick" and "git revert" can add a sign-off.
* "git commit" mentions the author identity when you are committing
somebody else's changes.
* "git diff/log --dirstat" output is consistent between binary and textual
changes.
* "git filter-branch" rewrites signed tags by demoting them to annotated.
* "git format-patch --no-binary" can produce a patch that lack binary
changes (i.e. cannot be used to propagate the whole changes) meant only
for reviewing.
* "git init --bare" is a synonym for "git --bare init" now.
* "git gc --auto" honors a new pre-auto-gc hook to temporarily disable it.
* "git log --pretty=tformat:<custom format>" gives a LF after each entry,
instead of giving a LF between each pair of entries which is how
"git log --pretty=format:<custom format>" works.
* "git log" and friends learned the "--graph" option to show the ancestry
graph at the left margin of the output.
* "git log" and friends can be told to use date format that is different
from the default via 'log.date' configuration variable.
* "git send-email" now can send out messages outside a git repository.
* "git send-email --compose" was made aware of rfc2047 quoting.
* "git status" can optionally include output from "git submodule
summary".
* "git svn" learned --add-author-from option to propagate the authorship
by munging the commit log message.
* new object creation and looking up in "git svn" has been optimized.
* "gitweb" can read from a system-wide configuration file.
(internal)
* "git unpack-objects" and "git receive-pack" is now more strict about
detecting breakage in the objects they receive over the wire.
Fixes since v1.5.5
------------------
All of the fixes in v1.5.5 maintenance series are included in
this release, unless otherwise noted.
And there are too numerous small fixes to otherwise note here ;-)

36
Documentation/RelNotes-1.6.0.1.txt Normal 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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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.

258
Documentation/RelNotes-1.6.0.txt Normal file
Просмотреть файл

@ -0,0 +1,258 @@
GIT v1.6.0 Release Notes
========================
User visible changes
--------------------
With the default Makefile settings, most of the programs are now
installed outside your $PATH, except for "git", "gitk" and
some server side programs that need to be accessible for technical
reasons. Invoking a git subcommand as "git-xyzzy" from the command
line has been deprecated since early 2006 (and officially announced in
1.5.4 release notes); use of them from your scripts after adding
output from "git --exec-path" to the $PATH is still supported in this
release, but users are again strongly encouraged to adjust their
scripts to use "git xyzzy" form, as we will stop installing
"git-xyzzy" hardlinks for built-in commands in later releases.
An earlier change to page "git status" output was overwhelmingly unpopular
and has been reverted.
Source changes needed for porting to MinGW environment are now all in the
main git.git codebase.
By default, packfiles created with this version uses delta-base-offset
encoding introduced in v1.4.4. Pack idx files are using version 2 that
allows larger packs and added robustness thanks to its CRC checking,
introduced in v1.5.2 and v1.4.4.5. If you want to keep your repositories
backwards compatible past these versions, set repack.useDeltaBaseOffset
to false or pack.indexVersion to 1, respectively.
We used to prevent sample hook scripts shipped in templates/ from
triggering by default by relying on the fact that we install them as
unexecutable, but on some filesystems, this approach does not work.
They are now shipped with ".sample" suffix. If you want to activate
any of these samples as-is, rename them to drop the ".sample" suffix,
instead of running "chmod +x" on them. For example, you can rename
hooks/post-update.sample to hooks/post-update to enable the sample
hook that runs update-server-info, in order to make repositories
friendly to dumb protocols (i.e. HTTP).
GIT_CONFIG, which was only documented as affecting "git config", but
actually affected all git commands, now only affects "git config".
GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
not different from GIT_CONFIG in a useful way, is removed.
The ".dotest" temporary area "git am" and "git rebase" use is now moved
inside the $GIT_DIR, to avoid mistakes of adding it to the project by
accident.
An ancient merge strategy "stupid" has been removed.
Updates since v1.5.6
--------------------
(subsystems)
* git-p4 in contrib learned "allowSubmit" configuration to control on
which branch to allow "submit" subcommand.
* git-gui learned to stage changes per-line.
(portability)
* Changes for MinGW port have been merged, thanks to Johannes Sixt and
gangs.
* Sample hook scripts shipped in templates/ are now suffixed with
*.sample.
* perl's in-place edit (-i) does not work well without backup files on Windows;
some tests are rewritten to cope with this.
(documentation)
* Updated howto/update-hook-example
* Got rid of usage of "git-foo" from the tutorial and made typography
more consistent.
* Disambiguating "--" between revs and paths is finally documented.
(performance, robustness, sanity etc.)
* index-pack used too much memory when dealing with a deep delta chain.
This has been optimized.
* reduced excessive inlining to shrink size of the "git" binary.
* verify-pack checks the object CRC when using version 2 idx files.
* When an object is corrupt in a pack, the object became unusable even
when the same object is available in a loose form, We now try harder to
fall back to these redundant objects when able. In particular, "git
repack -a -f" can be used to fix such a corruption as long as necessary
objects are available.
* Performance of "git-blame -C -C" operation is vastly improved.
* git-clone does not create refs in loose form anymore (it behaves as
if you immediately ran git-pack-refs after cloning). This will help
repositories with insanely large number of refs.
* core.fsyncobjectfiles configuration can be used to ensure that the loose
objects created will be fsync'ed (this is only useful on filesystems
that does not order data writes properly).
* "git commit-tree" plumbing can make Octopus with more than 16 parents.
"git commit" has been capable of this for quite some time.
(usability, bells and whistles)
* even more documentation pages are now accessible via "man" and "git help".
* A new environment variable GIT_CEILING_DIRECTORIES can be used to stop
the discovery process of the toplevel of working tree; this may be useful
when you are working in a slow network disk and are outside any working tree,
as bash-completion and "git help" may still need to run in these places.
* By default, stash entries never expire. Set reflogexpire in [gc
"refs/stash"] to a reasonable value to get traditional auto-expiration
behaviour back
* Longstanding latency issue with bash completion script has been
addressed. This will need to be backmerged to 'maint' later.
* pager.<cmd> configuration variable can be used to enable/disable the
default paging behaviour per command.
* "git-add -i" has a new action 'e/dit' to allow you edit the patch hunk
manually.
* git-am records the original tip of the branch in ORIG_HEAD before it
starts applying patches.
* git-apply can handle a patch that touches the same path more than once
much better than before.
* git-apply can be told not to trust the line counts recorded in the input
patch but recount, with the new --recount option.
* git-apply can be told to apply a patch to a path deeper than what the
patch records with --directory option.
* git-archive can be told to omit certain paths from its output using
export-ignore attributes.
* git-archive uses the zlib default compression level when creating
zip archive.
* git-archive's command line options --exec and --remote can take their
parameters as separate command line arguments, similar to other commands.
IOW, both "--exec=path" and "--exec path" are now supported.
* With -v option, git-branch describes the remote tracking statistics
similar to the way git-checkout reports by how many commits your branch
is ahead/behind.
* git-branch's --contains option used to always require a commit parameter
to limit the branches with; it now defaults to list branches that
contains HEAD if this parameter is omitted.
* git-branch's --merged and --no-merged option used to always limit the
branches relative to the HEAD, but they can now take an optional commit
argument that is used in place of HEAD.
* git-bundle can read the revision arguments from the standard input.
* git-cherry-pick can replay a root commit now.
* git-clone can clone from a remote whose URL would be rewritten by
configuration stored in $HOME/.gitconfig now.
* "git-clone --mirror" is a handy way to set up a bare mirror repository.
* git-cvsserver learned to respond to "cvs co -c".
* git-diff --check now checks leftover merge conflict markers.
* "git-diff -p" learned to grab a better hunk header lines in
BibTex, Pascal/Delphi, and Ruby files and also pays attention to
chapter and part boundary in TeX documents.
* When remote side used to have branch 'foo' and git-fetch finds that now
it has branch 'foo/bar', it refuses to lose the existing remote tracking
branch and its reflog. The error message has been improved to suggest
pruning the remote if the user wants to proceed and get the latest set
of branches from the remote, including such 'foo/bar'.
* fast-export learned to export and import marks file; this can be used to
interface with fast-import incrementally.
* fast-import and fast-export learned to export and import gitlinks.
* "gitk" left background process behind after being asked to dig very deep
history and the user killed the UI; the process is killed when the UI goes
away now.
* git-rebase records the original tip of branch in ORIG_HEAD before it is
rewound.
* "git rerere" can be told to update the index with auto-reused resolution
with rerere.autoupdate configuration variable.
* git-rev-parse learned $commit^! and $commit^@ notations used in "log"
family. These notations are available in gitk as well, because the gitk
command internally uses rev-parse to interpret its arguments.
* git-rev-list learned --children option to show child commits it
encountered during the traversal, instead of showing parent commits.
* git-send-mail can talk not just over SSL but over TLS now.
* git-shortlog honors custom output format specified with "--pretty=format:".
* "git-stash save" learned --keep-index option. This lets you stash away the
local changes and bring the changes staged in the index to your working
tree for examination and testing.
* git-stash also learned branch subcommand to create a new branch out of
stashed changes.
* git-status gives the remote tracking statistics similar to the way
git-checkout reports by how many commits your branch is ahead/behind.
* "git-svn dcommit" is now aware of auto-props setting the subversion user
has.
* You can tell "git status -u" to even more aggressively omit checking
untracked files with --untracked-files=no.
* Original SHA-1 value for "update-ref -d" is optional now.
* Error codes from gitweb are made more descriptive where possible, rather
than "403 forbidden" as we used to issue everywhere.
(internal)
* git-merge has been reimplemented in C.
Fixes since v1.5.6
------------------
All of the fixes in v1.5.6 maintenance series are included in
this release, unless otherwise noted.
* git-clone ignored its -u option; the fix needs to be backported to
'maint';
* git-mv used to lose the distinction between changes that are staged
and that are only in the working tree, by staging both in the index
after moving such a path.
* "git-rebase -i -p" rewrote the parents to wrong ones when amending
(either edit or squash) was involved, and did not work correctly
when fast forwarding.

59
Documentation/RelNotes-1.6.1.1.txt Normal 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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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.

12
Documentation/RelNotes-1.6.3.1.txt Normal file
Просмотреть файл

@ -0,0 +1,12 @@
GIT v1.6.3.1 Release Notes
==========================
Fixes since v1.6.3
------------------
--
exec >/var/tmp/1
O=v1.6.3
echo O=$(git describe maint)
git shortlog $O..maint

182
Documentation/RelNotes-1.6.3.txt Normal 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).

59
Documentation/RelNotes-1.6.4.txt Normal file
Просмотреть файл

@ -0,0 +1,59 @@
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.
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.3
--------------------
(subsystems)
(performance)
(usability, bells and whistles)
(developers)
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.
---
exec >/var/tmp/1
echo O=$(git describe master)
O=v1.6.3
git shortlog --no-merges $O..master ^maint

160
Documentation/SubmittingPatches
Просмотреть файл

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

36
Documentation/asciidoc.conf
Просмотреть файл

@ -1,13 +1,17 @@
## gitlink: macro
## linkgit: macro
#
# Usage: gitlink:command[manpage-section]
# Usage: linkgit:command[manpage-section]
#
# Note, {0} is the manpage section, while {target} is the command.
#
# 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;
caret=&#94;
startsb=&#91;
@ -15,7 +19,7 @@ endsb=&#93;
tilde=&#126;
ifdef::backend-docbook[]
[gitlink-inlinemacro]
[linkgit-inlinemacro]
{0%{target}}
{0#<citerefentry>}
{0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>}
@ -23,7 +27,9 @@ ifdef::backend-docbook[]
endif::backend-docbook[]
ifdef::backend-docbook[]
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]
<example><title>{title}</title>
<literallayout>
@ -36,6 +42,28 @@ ifdef::doctype-manpage[]
endif::doctype-manpage[]
</literallayout>
{title#}</example>
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[]
@ -58,6 +86,6 @@ endif::backend-docbook[]
endif::doctype-manpage[]
ifdef::backend-xhtml11[]
[gitlink-inlinemacro]
[linkgit-inlinemacro]
<a href="{target}.html">{target}{0?({0})}</a>
endif::backend-xhtml11[]

38
Documentation/blame-options.txt
Просмотреть файл

@ -39,27 +39,50 @@ of lines before or after the line given by <start>.
Show raw timestamp (Default: off).
-S <revs-file>::
Use revs from revs-file instead of calling gitlink:git-rev-list[1].
Use revisions from revs-file instead of calling linkgit:git-rev-list[1].
-p, --porcelain::
--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::
Show in a format designed for machine consumption.
--incremental::
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.
This flag makes the command pretend as if the working
tree copy has the contents of he named file (specify
tree copy has the contents of the named file (specify
`-` to make the command read from the standard input).
--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
@ -75,13 +98,14 @@ 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 all other
files in the parent for the commit that creates the file.
+
<num> is optional but it is the lower bound on the number of
alphanumeric characters that git must detect as moving
between files for it to associate those lines with the parent
commit.
-h, --help::
-h::
--help::
Show help message.

30
Documentation/callouts.xsl
Просмотреть файл

@ -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>

42
Documentation/cat-texi.perl Executable file
Просмотреть файл

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

152
Documentation/cmd-list.perl
Просмотреть файл

@ -3,7 +3,8 @@
use File::Compare qw(compare);
sub format_one {
my ($out, $name) = @_;
my ($out, $nameattr) = @_;
my ($name, $attr) = @$nameattr;
my ($state, $description);
$state = 0;
open I, '<', "$name.txt" or die "No such file $name.txt";
@ -26,8 +27,11 @@ sub format_one {
die "No description found in $name.txt";
}
if (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) {
print $out "gitlink:$name\[1\]::\n";
print $out "\t$text.\n\n";
print $out "linkgit:$name\[1\]::\n\t";
if ($attr =~ / deprecated /) {
print $out "(deprecated) ";
}
print $out "$text.\n\n";
}
else {
die "Description does not match $name: $description";
@ -35,12 +39,13 @@ sub format_one {
}
my %cmds = ();
while (<DATA>) {
for (sort <>) {
next if /^#/;
chomp;
my ($name, $cat) = /^(\S+)\s+(.*)$/;
push @{$cmds{$cat}}, $name;
my ($name, $cat, $attr) = /^(\S+)\s+(.*?)(?:\s+(.*))?$/;
$attr = '' unless defined $attr;
push @{$cmds{$cat}}, [$name, " $attr "];
}
for my $cat (qw(ancillaryinterrogators
@ -67,138 +72,3 @@ for my $cat (qw(ancillaryinterrogators
rename "$out+", "$out";
}
}
# The following list is sorted with "sort -d" to make it easier
# to find entry in the resulting git.html manual page.
__DATA__
git-add mainporcelain
git-am mainporcelain
git-annotate ancillaryinterrogators
git-apply plumbingmanipulators
git-archimport foreignscminterface
git-archive mainporcelain
git-bisect mainporcelain
git-blame ancillaryinterrogators
git-branch mainporcelain
git-bundle mainporcelain
git-cat-file plumbinginterrogators
git-check-attr purehelpers
git-checkout mainporcelain
git-checkout-index plumbingmanipulators
git-check-ref-format purehelpers
git-cherry ancillaryinterrogators
git-cherry-pick mainporcelain
git-citool mainporcelain
git-clean mainporcelain
git-clone mainporcelain
git-commit mainporcelain
git-commit-tree plumbingmanipulators
git-config ancillarymanipulators
git-convert-objects ancillarymanipulators
git-count-objects ancillaryinterrogators
git-cvsexportcommit foreignscminterface
git-cvsimport foreignscminterface
git-cvsserver foreignscminterface
git-daemon synchingrepositories
git-describe mainporcelain
git-diff mainporcelain
git-diff-files plumbinginterrogators
git-diff-index plumbinginterrogators
git-diff-tree plumbinginterrogators
git-fast-import ancillarymanipulators
git-fetch mainporcelain
git-fetch-pack synchingrepositories
git-filter-branch ancillarymanipulators
git-fmt-merge-msg purehelpers
git-for-each-ref plumbinginterrogators
git-format-patch mainporcelain
git-fsck ancillaryinterrogators
git-gc mainporcelain
git-get-tar-commit-id ancillaryinterrogators
git-grep mainporcelain
git-gui mainporcelain
git-hash-object plumbingmanipulators
git-http-fetch synchelpers
git-http-push synchelpers
git-imap-send foreignscminterface
git-index-pack plumbingmanipulators
git-init mainporcelain
git-instaweb ancillaryinterrogators
gitk mainporcelain
git-local-fetch synchingrepositories
git-log mainporcelain
git-lost-found ancillarymanipulators
git-ls-files plumbinginterrogators
git-ls-remote plumbinginterrogators
git-ls-tree plumbinginterrogators
git-mailinfo purehelpers
git-mailsplit purehelpers
git-merge mainporcelain
git-merge-base plumbinginterrogators
git-merge-file plumbingmanipulators
git-merge-index plumbingmanipulators
git-merge-one-file purehelpers
git-mergetool ancillarymanipulators
git-merge-tree ancillaryinterrogators
git-mktag plumbingmanipulators
git-mktree plumbingmanipulators
git-mv mainporcelain
git-name-rev plumbinginterrogators
git-pack-objects plumbingmanipulators
git-pack-redundant plumbinginterrogators
git-pack-refs ancillarymanipulators
git-parse-remote synchelpers
git-patch-id purehelpers
git-peek-remote purehelpers
git-prune ancillarymanipulators
git-prune-packed plumbingmanipulators
git-pull mainporcelain
git-push mainporcelain
git-quiltimport foreignscminterface
git-read-tree plumbingmanipulators
git-rebase mainporcelain
git-receive-pack synchelpers
git-reflog ancillarymanipulators
git-relink ancillarymanipulators
git-remote ancillarymanipulators
git-repack ancillarymanipulators
git-request-pull foreignscminterface
git-rerere ancillaryinterrogators
git-reset mainporcelain
git-revert mainporcelain
git-rev-list plumbinginterrogators
git-rev-parse ancillaryinterrogators
git-rm mainporcelain
git-runstatus ancillaryinterrogators
git-send-email foreignscminterface
git-send-pack synchingrepositories
git-shell synchelpers
git-shortlog mainporcelain
git-show mainporcelain
git-show-branch ancillaryinterrogators
git-show-index plumbinginterrogators
git-show-ref plumbinginterrogators
git-sh-setup purehelpers
git-ssh-fetch synchingrepositories
git-ssh-upload synchingrepositories
git-stash mainporcelain
git-status mainporcelain
git-stripspace purehelpers
git-submodule mainporcelain
git-svn foreignscminterface
git-svnimport foreignscminterface
git-symbolic-ref plumbingmanipulators
git-tag mainporcelain
git-tar-tree plumbinginterrogators
git-unpack-file plumbinginterrogators
git-unpack-objects plumbingmanipulators
git-update-index plumbingmanipulators
git-update-ref plumbingmanipulators
git-update-server-info synchingrepositories
git-upload-archive synchelpers
git-upload-pack synchelpers
git-var plumbinginterrogators
git-verify-pack plumbinginterrogators
git-verify-tag ancillaryinterrogators
git-whatchanged ancillaryinterrogators
git-write-tree plumbingmanipulators

1148
Documentation/config.txt
Просмотреть файл

Разница между файлами не показана из-за своего большого размера Загрузить разницу

592
Documentation/core-intro.txt
Просмотреть файл

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

215
Documentation/diff-format.txt
Просмотреть файл

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

161
Documentation/diff-generate-patch.txt Normal file
Просмотреть файл

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

140
Documentation/diff-options.txt
Просмотреть файл

@ -1,22 +1,44 @@
-p::
Generate patch (see section on generating patches)
// Please don't remove this comment as asciidoc behaves badly when
// the first non-empty line is ifdef/ifndef. The symptom is that
// without this comment the <git-diff-core> attribute conditionally
// defined below ends up being defined unconditionally.
// Last checked with asciidoc 7.0.2.
ifndef::git-format-patch[]
ifndef::git-diff[]
ifndef::git-log[]
:git-diff-core: 1
endif::git-log[]
endif::git-diff[]
endif::git-format-patch[]
ifdef::git-format-patch[]
-p::
Generate patches without diffstat.
endif::git-format-patch[]
ifndef::git-format-patch[]
-p::
-u::
Synonym for "-p".
Generate patch (see section on generating patches).
{git-diff? This is the default.}
endif::git-format-patch[]
-U<n>::
Shorthand for "--unified=<n>".
--unified=<n>::
Generate diffs with <n> lines of context instead of
the usual three. Implies "-p".
--raw::
Generate the raw format.
{git-diff-core? This is the default.}
--patch-with-raw::
Synonym for "-p --raw".
--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".
@ -35,12 +57,23 @@
number of modified files, as well as number of added and deleted
lines.
--dirstat[=limit]::
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.
--patch-with-stat::
Synonym for "-p --stat".
{git-format-patch? This is the default.}
-z::
NUL-line termination on output. This affects the --raw
@ -51,7 +84,8 @@
Show only names of changed files.
--name-status::
Show only names and status of changed files.
Show only names and status of changed files. See the description
of the `--diff-filter` option on what the status letters mean.
--color::
Show colored diff.
@ -60,8 +94,22 @@
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.
--no-renames::
Turn off rename detection, even when the configuration
@ -69,12 +117,14 @@
--check::
Warn if changes introduce trailing whitespace
or an indent that uses a space before a tab.
or an indent that uses a space before a tab. Exits with
non-zero status if problems are found. Not compatible with
--exit-code.
--full-index::
Instead of the first handful characters, show full
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
@ -83,7 +133,7 @@
--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
lines, show only a partial prefix. This is
independent of --full-index option above, which controls
the diff-patch output format. Non default number of
digits can be specified with --abbrev=<n>.
@ -100,7 +150,8 @@
--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
@ -125,7 +176,10 @@
number.
-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
@ -144,30 +198,36 @@
Swap two inputs; that is, show differences from index or
on-disk file to tree contents.
--relative[=<path>]::
When run from a subdirectory of the project, it can be
told to exclude changes outside the directory and show
pathnames relative to it with this option. When you are
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.
-a::
--text::
Treat all files as text.
-a::
Shorthand for "--text".
--ignore-space-at-eol::
Ignore changes in white spaces at EOL.
--ignore-space-change::
Ignore changes in amount of white space. This ignores white
space at line end, and consider all other sequences of one or
more white space characters to be equivalent.
Ignore changes in whitespace at EOL.
-b::
Shorthand for "--ignore-space-change".
--ignore-all-space::
Ignore white space when comparing lines. This ignores
difference even if one line has white space where the other
line has none.
--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.
-w::
Shorthand for "--ignore-all-space".
--ignore-all-space::
Ignore whitespace when comparing lines. This ignores
differences even if one line has whitespace where the other
line has none.
--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.
--exit-code::
Make the program exit with codes similar to diff(1).
@ -179,11 +239,23 @@
--ext-diff::
Allow an external diff helper to be executed. If you set an
external diff driver with gitlink:gitattributes(5), you need
to use this option with gitlink:git-log(1) and friends.
external diff driver with linkgit:gitattributes[5], you need
to use this option with linkgit:git-log[1] and friends.
--no-ext-diff::
Disallow external diff drivers.
--ignore-submodules::
Ignore changes to submodules in the diff generation.
--src-prefix=<prefix>::
Show the given source prefix instead of "a/".
--dst-prefix=<prefix>::
Show the given destination prefix instead of "b/".
--no-prefix::
Do not show any source or destination prefix.
For more detailed explanation on these common options, see also
link:diffcore.html[diffcore documentation].
linkgit:gitdiffcore[7].

14
Documentation/docbook-xsl.css
Просмотреть файл

@ -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 {

71
Documentation/everyday.txt
Просмотреть файл

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

50
Documentation/fetch-options.txt
Просмотреть файл

@ -1,35 +1,45 @@
-q, \--quiet::
-q::
--quiet::
Pass --quiet to git-fetch-pack and silence any other internally
used programs.
-v, \--verbose::
-v::
--verbose::
Be verbose.
-a, \--append::
-a::
--append::
Append ref names and object names of fetched refs to the
existing contents of `.git/FETCH_HEAD`. Without this
option old data in `.git/FETCH_HEAD` will be overwritten.
\--upload-pack <upload-pack>::
--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.
-f, \--force::
When `git-fetch` is used with `<rbranch>:<lbranch>`
-f::
--force::
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.
-n, \--no-tags::
By default, `git-fetch` fetches tags that point at
objects that are downloaded from the remote repository
and stores them locally. This option disables this
automatic tag following.
ifdef::git-pull[]
--no-tags::
endif::git-pull[]
ifndef::git-pull[]
-n::
--no-tags::
endif::git-pull[]
By default, tags that point at objects that are downloaded
from the remote repository are fetched and stored locally.
This option disables this automatic tag following.
-t, \--tags::
-t::
--tags::
Most of the tags are fetched automatically as branch
heads are downloaded, but tags that do not point at
objects reachable from the branch heads that are being
@ -37,18 +47,20 @@
flag lets all tags and their associated objects be
downloaded.
-k, \--keep::
-k::
--keep::
Keep downloaded pack.
-u, \--update-head-ok::
By default `git-fetch` refuses to update the head which
-u::
--update-head-ok::
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>::
--depth=<depth>::
Deepen the history of a 'shallow' repository created by
`git clone` with `--depth=<depth>` option (see gitlink:git-clone[1])
`git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
by the specified number of commits.

135
Documentation/git-add.txt
Просмотреть файл

@ -8,8 +8,9 @@ git-add - Add file contents to the index
SYNOPSIS
--------
[verse]
'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--refresh]
[--] <filepattern>...
'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
[--all | [--update | -u]] [--intent-to-add | -N]
[--refresh] [--ignore-errors] [--] <filepattern>...
DESCRIPTION
-----------
@ -37,7 +38,7 @@ directory recursion or filename globbing performed by Git (quote your
globs before the shell) will be silently ignored. The 'add' command can
be used to add ignored files with the `-f` (force) option.
Please see gitlink:git-commit[1] for alternative ways to add content to a
Please see linkgit:git-commit[1] for alternative ways to add content to a
commit.
@ -51,29 +52,64 @@ OPTIONS
directory, recursively.
-n::
--dry-run::
Don't actually add the file(s), just show if they exist.
-v::
--verbose::
Be verbose.
-f::
--force::
Allow adding otherwise ignored files.
-i, \--interactive::
-i::
--interactive::
Add modified contents in the working tree interactively to
the index.
the index. Optional path arguments may be supplied to limit
operation to a subset of the working tree. See ``Interactive
mode'' for details.
-p::
--patch::
Similar to Interactive mode but the initial command loop is
bypassed and the 'patch' subcommand is invoked using each of
the specified filepatterns before exiting.
-u::
Update only files that git already knows about. This is similar
--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 are
updated.
command line. If no paths are specified, all tracked files in the
current directory and its subdirectories are updated.
\--refresh::
-A::
--all::
Update files that git already knows about (same as '\--update')
and add all untracked files that are not ignored by '.gitignore'
mechanism.
-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()
information in the index.
--ignore-errors::
If some files could not be added because of errors indexing
them, do not abort the operation, but continue adding the
others. The command shall still exit with non-zero status.
\--::
This option can be used to separate command-line options from
the list of files, (useful when filenames might be mistaken
@ -86,26 +122,32 @@ Configuration
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 link:repository-layout.html[repository layout].
those in info/exclude. See linkgit:gitrepository-layout[5].
EXAMPLES
--------
git-add Documentation/\\*.txt::
Adds content from all `\*.txt` files under `Documentation`
directory and its subdirectories.
* Adds content from all `\*.txt` files under `Documentation` directory
and its subdirectories:
+
------------
$ 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.
git-add git-*.sh::
Considers adding content from all git-*.sh scripts.
Because this example lets shell expand the asterisk
(i.e. you are listing the files explicitly), it does not
consider `subdir/git-foo.sh`.
* Considers adding content from all git-*.sh scripts:
+
------------
$ git add git-*.sh
------------
+
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`.
Interactive mode
----------------
@ -156,12 +198,13 @@ 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. You can say '*' to choose
everything.
2,3,4,5,7,9 from the list. If the second number in a range is
omitted, all remaining patches are taken. E.g. "7-" to choose
7,8,9 from the list. You can say '*' to choose everything.
+
What you chose are then highlighted with '*',
like this:
@ -195,21 +238,25 @@ 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 - add the change from that hunk to index
n - do not add the change from that hunk to index
a - add the change from that hunk and all the rest to index
d - do not the change from that hunk nor any of the rest to index
j - do not decide on this hunk now, and view the next
undecided hunk
J - do not decide on this hunk now, and view the next hunk
k - do not decide on this hunk now, and view the previous
undecided hunk
K - do not decide on this hunk now, and view the previous hunk
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
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help
+
After deciding the fate for all hunks, if there is any hunk
that was chosen, the index is updated with the selected hunks.
@ -219,14 +266,14 @@ diff::
This lets you review what will be committed (i.e. between
HEAD and index).
See Also
SEE ALSO
--------
gitlink:git-status[1]
gitlink:git-rm[1]
gitlink:git-mv[1]
gitlink:git-commit[1]
gitlink:git-update-index[1]
linkgit:git-status[1]
linkgit:git-rm[1]
linkgit:git-reset[1]
linkgit:git-mv[1]
linkgit:git-commit[1]
linkgit:git-update-index[1]
Author
------
@ -238,4 +285,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

136
Documentation/git-am.txt
Просмотреть файл

@ -9,11 +9,13 @@ git-am - Apply a series of patches from a mailbox
SYNOPSIS
--------
[verse]
'git-am' [--signoff] [--dotest=<dir>] [--keep] [--utf8 | --no-utf8]
[--3way] [--interactive] [--binary]
[--whitespace=<option>] [-C<n>] [-p<n>]
<mbox>|<Maildir>...
'git-am' [--skip | --resolved]
'git am' [--signoff] [--keep] [--utf8 | --no-utf8]
[--3way] [--interactive] [--committer-date-is-author-date]
[--ignore-date]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
[--reject]
[<mbox> | <Maildir>...]
'git am' (--skip | --resolved | --abort)
DESCRIPTION
-----------
@ -25,62 +27,73 @@ 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
-s::
--signoff::
Add a `Signed-off-by:` line to the commit message, using
the committer identity of yourself.
-d=<dir>, --dotest=<dir>::
Instead of `.dotest` directory, use <dir> as a working
area to store extracted patches.
-k::
--keep::
Pass `-k` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
-k, --keep::
Pass `-k` flag to `git-mailinfo` (see gitlink:git-mailinfo[1]).
-u, --utf8::
Pass `-u` flag to `git-mailinfo` (see gitlink:git-mailinfo[1]).
-u::
--utf8::
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
gitlink:git-mailinfo[1]).
Pass `-n` flag to 'git-mailinfo' (see
linkgit:git-mailinfo[1]).
-3, --3way::
-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.
-b, --binary::
Pass `--allow-binary-replacement` flag to `git-apply`
(see gitlink:git-apply[1]).
--whitespace=<option>::
This flag is passed to the `git-apply` (see gitlink:git-apply[1])
-C<n>::
-p<n>::
--directory=<dir>::
--reject::
These flags are passed to the 'git-apply' (see linkgit:git-apply[1])
program that applies
the patch.
-C<n>, -p<n>::
These flags are passed to the `git-apply` (see gitlink:git-apply[1])
program that applies
the patch.
-i, --interactive::
-i::
--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.
-r, --resolved::
-r::
--resolved::
After a patch failure (e.g. attempting to apply
conflicting patch), the user has applied it by hand and
the index file stores the result of the application.
@ -93,30 +106,33 @@ 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.
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 (the rest of the
message after the blank line terminating the RFC2822 headers)
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
@ -125,31 +141,37 @@ 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 `.dotest`
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 .dotest` before running the command with mailbox
run `rm -f -r .git/rebase-apply` before running the command with mailbox
names.
Before any patches are applied, ORIG_HEAD is set to the tip of the
current branch. This is useful if you have problems with multiple
commits, like running 'git am' on the wrong branch or an error in the
commits that is more easily fixed by changing the mailbox (e.g.
errors in the "From:" lines).
SEE ALSO
--------
gitlink:git-apply[1].
linkgit:git-apply[1].
Author
------
Written by Junio C Hamano <junkio@cox.net>
Written by Junio C Hamano <gitster@pobox.com>
Documentation
--------------
@ -157,4 +179,4 @@ Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.o
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

15
Documentation/git-annotate.txt
Просмотреть файл

@ -3,16 +3,21 @@ git-annotate(1)
NAME
----
git-annotate - Annotate file lines with commit info
git-annotate - Annotate file lines with commit information
SYNOPSIS
--------
git-annotate [options] file [revision]
'git annotate' [options] file [revision]
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
-------
@ -20,7 +25,7 @@ include::blame-options.txt[]
SEE ALSO
--------
gitlink:git-blame[1]
linkgit:git-blame[1]
AUTHOR
------
@ -28,4 +33,4 @@ Written by Ryan Anderson <ryan@michonline.com>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

126
Documentation/git-apply.txt
Просмотреть файл

@ -9,22 +9,23 @@ git-apply - Apply a patch on a git index file and a working tree
SYNOPSIS
--------
[verse]
'git-apply' [--stat] [--numstat] [--summary] [--check] [--index]
[--apply] [--no-add] [--index-info] [-R | --reverse]
'git apply' [--stat] [--numstat] [--summary] [--check] [--index]
[--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse]
[--allow-binary-replacement | --binary] [--reject] [-z]
[-pNUM] [-CNUM] [--inaccurate-eof] [--cached]
[--whitespace=<nowarn|warn|error|error-all|strip>]
[--exclude=PATH] [--verbose] [<patch>...]
[-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached]
[--whitespace=<nowarn|warn|fix|error|error-all>]
[--exclude=PATH] [--include=PATH] [--directory=<root>]
[--verbose] [<patch>...]
DESCRIPTION
-----------
Reads supplied diff output and applies it on a git index file
Reads supplied 'diff' output and applies it on a git index file
and a work tree.
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 +33,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".
@ -59,22 +60,26 @@ OPTIONS
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,
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'.
--index-info::
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 version of the blob is available locally,
outputs information about them to the standard output.
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),
the information is read from the current index instead.
-R, --reverse::
-R::
--reverse::
Apply the patch in reverse.
--reject::
For atomicity, gitlink:git-apply[1] 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
@ -98,30 +103,31 @@ OPTIONS
ever ignored.
--unidiff-zero::
By default, gitlink:git-apply[1] 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'.
+
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, gitlink:git-apply[1] 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.
--no-add::
When applying a patch, ignore additions made by the
patch. This can be used to extract common part between
two files by first running `diff` on them and applying
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::
--allow-binary-replacement::
--binary::
Historically we did not allow binary patch applied
without an explicit permission from the user, and this
flag was the way to do so. Currently we always allow binary
@ -132,38 +138,70 @@ discouraged.
be useful when importing patchsets, where you want to exclude certain
files or directories.
--whitespace=<option>::
When applying a patch, detect a new or modified line
that ends with trailing whitespaces (this includes a
line that solely consists of whitespaces). By default,
the command outputs warning messages and applies the
patch.
When gitlink:git-apply[1] is used for statistics and not applying a
patch, it defaults to `nowarn`.
You can use different `<option>` to control this
behavior:
--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.
--whitespace=<action>::
When applying a patch, detect a new or modified line that has
whitespace errors. What are considered whitespace errors is
controlled by `core.whitespace` configuration. By default,
trailing whitespaces (including lines that solely consist of
whitespaces) and a space character that is immediately followed
by a tab character inside the initial indent of the line are
considered whitespace errors.
+
By default, the command outputs warning messages but applies the patch.
When `git-apply` is used for statistics and not applying a
patch, it defaults to `nowarn`.
+
You can use different `<action>` values to control this
behavior:
+
* `nowarn` turns off the trailing whitespace warning.
* `warn` outputs warnings for a few such errors, but applies the
patch (default).
patch as-is (default).
* `fix` outputs warnings for a few such errors, and applies the
patch after fixing them (`strip` is a synonym --- the tool
used to consider only trailing 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.
* `error-all` is similar to `error` but shows all errors.
* `strip` outputs warnings for a few such errors, strips out the
trailing whitespaces and applies the patch.
--inaccurate-eof::
Under certain circumstances, some versions of diff do not correctly
Under certain circumstances, some versions of 'diff' do not correctly
detect a missing new-line at the end of the file. As a result, patches
created by such diff programs do not record incomplete lines
created by such 'diff' programs do not record incomplete lines
correctly. This option adds support for applying such patches by
working around this bug.
-v, --verbose::
-v::
--verbose::
Report progress to stderr. By default, only a message about the
current patch being applied will be printed. This option will cause
additional information to be reported.
--recount::
Do not trust the line counts in the hunk headers, but infer them
by inspecting the patch (e.g. after editing the patch without
adjusting the hunk headers appropriately).
--directory=<root>::
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`
can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by
running `git apply --directory=modules/git-gui`.
Configuration
-------------
@ -173,7 +211,7 @@ apply.whitespace::
Submodules
----------
If the patch contains any changes to submodules then gitlink:git-apply[1]
If the patch contains any changes to submodules then 'git-apply'
treats these changes as follows.
If --index is specified (explicitly or implicitly), then the submodule
@ -183,7 +221,7 @@ 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
are ignored and only the absence or presence of the corresponding
subdirectory is checked and (if possible) updated.
Author
@ -196,4 +234,4 @@ Documentation by Junio C Hamano
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

16
Documentation/git-archimport.txt
Просмотреть файл

@ -9,7 +9,7 @@ git-archimport - Import an Arch repository into git
SYNOPSIS
--------
[verse]
'git-archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
'git archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
<archive/branch>[:<git-branch>] ...
DESCRIPTION
@ -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
@ -117,4 +117,4 @@ Documentation by Junio C Hamano, Martin Langhoff and the git-list <git@vger.kern
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

54
Documentation/git-archive.txt
Просмотреть файл

@ -9,18 +9,21 @@ git-archive - Create an archive of files from a named tree
SYNOPSIS
--------
[verse]
'git-archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
[--remote=<repo>] <tree-ish> [path...]
'git archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
[--output=<file>] [--worktree-attributes]
[--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
[path...]
DESCRIPTION
-----------
Creates an archive of the specified format containing the tree
structure for the named tree. If <prefix> is specified it is
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
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
@ -31,26 +34,38 @@ OPTIONS
-------
--format=<fmt>::
Format of the resulting archive: 'tar', 'zip'... The default
Format of the resulting archive: 'tar' or 'zip'. The default
is 'tar'.
--list, -l::
-l::
--list::
Show all available formats.
--verbose, -v::
-v::
--verbose::
Report progress to stderr.
--prefix=<prefix>/::
Prepend <prefix>/ to each filename in the archive.
--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>::
Used with --remote to specify the path to the
'git-upload-archive' on the remote side.
<tree-ish>::
The tree or commit to produce an archive for.
@ -80,12 +95,24 @@ 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.
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::
@ -102,6 +129,11 @@ 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/'.
SEE ALSO
--------
linkgit:gitattributes[5]
Author
------
Written by Franck Bui-Huu and Rene Scharfe.
@ -112,4 +144,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

257
Documentation/git-bisect.txt
Просмотреть файл

@ -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
@ -15,23 +15,32 @@ DESCRIPTION
The command takes various subcommands, and different options depending
on the subcommand:
git bisect help
git bisect start [<bad> [<good>...]] [--] [<paths>...]
git bisect bad <rev>
git bisect good <rev>
git bisect bad [<rev>]
git bisect good [<rev>...]
git bisect skip [(<rev>|<range>)...]
git bisect reset [<branch>]
git bisect visualize
git bisect replay <logfile>
git bisect log
git bisect run <cmd>...
This command uses 'git-rev-list --bisect' option 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.
Getting help
~~~~~~~~~~~~
Use "git bisect" to get a short usage description, and "git bisect
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
@ -40,115 +49,160 @@ $ 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
To return to the original head after a bisect session, issue the
following command:
------------------------------------------------
$ git bisect reset
------------------------------------------------
to get back to the master branch, instead of being in one of the
bisection branches ("git bisect start" will do that for you too,
actually: it will reset the bisection state, and before it does that
it checks that you're not using some old bisection branch).
This resets the tree to the original branch instead of being on the
bisection commit ("git bisect start" will also do that, as it resets
the bisection state).
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`.
`view` may also be used as a synonym for `visualize`.
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`.
------------
$ 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 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 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 --
@ -160,34 +214,103 @@ 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 and with a
code between 1 and 127 (included) in case the current source code is
bad.
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".
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.
The special exit code 125 should be used when the current source code
cannot be tested. If the script exits with this code, the current
revision will be skipped (see `git bisect skip` above).
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 "git bisect run" command loop to
know the outcome.
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, 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
--------
* Automatically bisect a broken build between v1.2 and HEAD:
+
------------
$ 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 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.
+
It is safer to use a custom script outside the repository to prevent
interactions between the bisect, make and test processes and the
script.
+
"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 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" otherwise.
+
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
------
@ -199,4 +322,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

86
Documentation/git-blame.txt
Просмотреть файл

@ -8,9 +8,9 @@ git-blame - Show what revision and author last modified each line of a file
SYNOPSIS
--------
[verse]
'git-blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
'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>
[<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 gitlink:git-diff[1] 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
@ -41,31 +41,33 @@ OPTIONS
include::blame-options.txt[]
-c::
Use the same output mode as gitlink:git-annotate[1] (Default: off).
Use the same output mode as linkgit:git-annotate[1] (Default: off).
--score-debug::
Include debugging information related to the movement of
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.
-f::
--show-name::
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).
-n::
--show-number::
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
@ -77,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
@ -98,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
@ -127,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
@ -160,36 +162,42 @@ 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
--------
gitlink:git-annotate[1]
linkgit:git-annotate[1]
AUTHOR
------
Written by Junio C Hamano <junkio@cox.net>
Written by Junio C Hamano <gitster@pobox.com>
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

136
Documentation/git-branch.txt
Просмотреть файл

@ -8,30 +8,42 @@ git-branch - List, create, or delete branches
SYNOPSIS
--------
[verse]
'git-branch' [--color | --no-color] [-r | -a]
[-v [--abbrev=<length> | --no-abbrev]]
'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git-branch' (-m | -M) [<oldbranch>] <newbranch>
'git-branch' (-d | -D) [-r] <branchname>...
'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' (-m | -M) [<oldbranch>] <newbranch>
'git branch' (-d | -D) [-r] <branchname>...
DESCRIPTION
-----------
With no arguments given a list of existing branches
will be shown, the current branch will be highlighted with an asterisk.
Option `-r` causes the remote-tracking branches to be listed,
and option `-a` shows both.
In its second form, a new branch named <branchname> will be created.
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 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. If the <commit> argument is missing it
defaults to 'HEAD' (i.e. the tip of the current branch).
In the command's 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.
When a local branch is started off a remote branch, git can setup the
branch so that gitlink:git-pull[1] will appropriately merge from that
remote branch. If this behavior is desired, it is possible to make it
the default using the global `branch.autosetupmerge` configuration
flag. Otherwise, it can be chosen per-branch using the `--track`
and `--no-track` options.
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
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.
With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.
If <oldbranch> had a corresponding reflog, it is renamed to match
@ -41,17 +53,22 @@ to happen.
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
has a reflog then the reflog will also be deleted. Use -r together with -d
to delete remote-tracking branches.
has a reflog then the reflog will also be deleted.
Use -r together with -d to delete remote-tracking branches. Note, that it
only makes sense to delete remote-tracking branches if they no longer exist
in 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
-------
-d::
Delete a branch. The branch must be fully merged.
Delete a branch. The branch must be fully merged in HEAD.
-D::
Delete a branch irrespective of its index status.
Delete a branch irrespective of its merged status.
-l::
Create the branch's reflog. This activates recording of
@ -59,14 +76,14 @@ 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.
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.
@ -82,19 +99,50 @@ OPTIONS
List both remote-tracking branches and local branches.
-v::
Show sha1 and commit subject line for each head.
--verbose::
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 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::
Do not set up "upstream" configuration, even if the
branch.autosetupmerge configuration variable is true.
--contains <commit>::
Only list branches which contain the specified commit.
--merged::
Only list branches which are fully contained by HEAD.
--no-merged::
Do not list branches which are fully contained by HEAD.
<branchname>::
The name of the branch to create or delete.
The new branch name must pass all checks defined by
gitlink:git-check-ref-format[1]. Some of these checks
linkgit:git-check-ref-format[1]. Some of these checks
may restrict the characters allowed in a branch name.
<start-point>::
@ -107,13 +155,13 @@ OPTIONS
<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
@ -125,7 +173,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
@ -134,22 +182,36 @@ $ git branch -d -r origin/todo origin/html origin/man <1>
$ git branch -D test <2>
------------
+
<1> Delete remote-tracking branches "todo", "html", "man"
<2> Delete "test" branch even if the "master" branch does not have all
commits from test branch.
<1> Delete 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` serve three related
but different purposes:
- `--contains <commit>` is used to find all branches which will need
special attention if <commit> were to be rebased or amended, since those
branches contain the specified <commit>.
- `--merged` is used to find all branches which can be safely deleted,
since those branches are fully contained by HEAD.
- `--no-merged` is used to find branches which are candidates for merging
into HEAD, since those branches are not fully contained by HEAD.
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <junkio@cox.net>
Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <gitster@pobox.com>
Documentation
--------------
@ -157,4 +219,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

179
Documentation/git-bundle.txt
Просмотреть файл

@ -9,23 +9,23 @@ git-bundle - Move objects and refs by archive
SYNOPSIS
--------
[verse]
'git-bundle' create <file> [git-rev-list args]
'git-bundle' verify <file>
'git-bundle' list-heads <file> [refname...]
'git-bundle' unbundle <file> [refname...]
'git bundle' create <file> <git-rev-list args>
'git bundle' verify <file>
'git bundle' list-heads <file> [refname...]
'git bundle' unbundle <file> [refname...]
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 gitlink:git-fetch[1] and gitlink:git-pull[1]
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
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,17 +51,16 @@ list-heads <file>::
printed out.
unbundle <file>::
Passes the objects in the bundle to gitlink:git-index-pack[1]
Passes the objects in the bundle to '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
gitlink:git-fetch[1].
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
@ -70,66 +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 gitlink:git-fetch-pack[1]).
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.
We set a tag in R1 (lastR2bundle) after the previous such transport,
and move it afterwards to help build the bundle.
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.
in R1 on A:
$ git-bundle create mybundle master ^lastR2bundle
$ git tag -f lastR2bundle master
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:
(move mybundle from A to B by some mechanism)
----------------
machineA$ cd R1
machineA$ git bundle create file.bundle master
machineA$ git tag -f lastR2bundle master
----------------
in R2 on B:
$ git-bundle verify mybundle
$ git-fetch mybundle refspec
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:
where refspec is refInBundle:localRef
----------------
machineB$ git clone /home/me/tmp/file.bundle 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:
Also, with something like this in your config:
[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:
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
------
@ -137,4 +206,4 @@ Written by Mark Levedahl <mdl123@verizon.net>
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

52
Documentation/git-cat-file.txt
Просмотреть файл

@ -3,25 +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
--------
'git-cat-file' [-t | -s | -e | -p | <type>] <object>
[verse]
'git cat-file' [-t | -s | -e | -p | <type>] <object>
'git cat-file' [--batch | --batch-check] < <list-of-objects>
DESCRIPTION
-----------
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 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 gitlink: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
@ -46,6 +51,14 @@ OPTIONS
or to ask for a "blob" with <object> being a tag object that
points at it.
--batch::
Print the SHA1, type, size, and contents of each object provided on
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.
OUTPUT
------
If '-t' is specified, one of the <type>.
@ -56,9 +69,30 @@ If '-e' is specified, no output.
If '-p' is specified, the contents of <object> are pretty-printed.
Otherwise the raw (though uncompressed) contents of the <object> will
be returned.
If <type> is specified, the raw (though uncompressed) contents of the <object>
will be returned.
If '--batch' is specified, output of the following form is printed for each
object specified on stdin:
------------
<sha1> SP <type> SP <size> LF
<contents> LF
------------
If '--batch-check' is specified, output of the following form is printed for
each object specified on stdin:
------------
<sha1> SP <type> SP <size> LF
------------
For both '--batch' and '--batch-check', output of the following form is printed
for each object specified on stdin that does not exist in the repository:
------------
<object> SP missing LF
------------
Author
------
@ -70,4 +104,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

76
Documentation/git-check-attr.txt
Просмотреть файл

@ -3,29 +3,93 @@ git-check-attr(1)
NAME
----
git-check-attr - Display gitattributes information.
git-check-attr - Display gitattributes information
SYNOPSIS
--------
'git-check-attr' attr... [--] pathname...
[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
--------
linkgit:gitattributes[5].
Author
------
Written by Junio C Hamano <junkio@cox.net>
Written by Junio C Hamano <gitster@pobox.com>
Documentation
--------------
@ -33,4 +97,4 @@ Documentation by James Bowes.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

64
Documentation/git-check-ref-format.txt
Просмотреть файл

@ -3,53 +3,71 @@ 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
--------
'git-check-ref-format' <refname>
[verse]
'git check-ref-format' <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 cannot have two consecutive dots `..` anywhere.
. It cannot have ASCII control character (i.e. bytes whose
. 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 `@{`.
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 gitlink: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
gitlink:git-cat-file[1] "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 `--branch` option, it expands a branch name shorthand and
prints the name of the branch the shorthand refers to.
EXAMPLE
-------
git check-ref-format --branch @{-1}::
Print the name of the previous branch.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

45
Documentation/git-checkout-index.txt
Просмотреть файл

@ -9,7 +9,7 @@ git-checkout-index - Copy files from the index to the working tree
SYNOPSIS
--------
[verse]
'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
'git checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
[--stage=<number>|all]
[--temp]
[-z] [--stdin]
@ -22,21 +22,26 @@ Will copy all files listed from the index to the working directory
OPTIONS
-------
-u|--index::
-u::
--index::
update stat information for the checked out entries in
the index file.
-q|--quiet::
-q::
--quiet::
be quiet if files exist or are not in the index
-f|--force::
-f::
--force::
forces overwrite of existing files
-a|--all::
-a::
--all::
checks out all files in the index. Cannot be used
together with explicit filenames.
-n|--no-create::
-n::
--no-create::
Don't checkout new files, only refresh files already checked
out.
@ -68,25 +73,25 @@ OPTIONS
The order of the flags used to matter, but not anymore.
Just doing `git-checkout-index` does nothing. You probably meant
`git-checkout-index -a`. And if you want to force it, you want
`git-checkout-index -f -a`.
Just doing `git checkout-index` does nothing. You probably meant
`git checkout-index -a`. And if you want to force it, you want
`git checkout-index -f -a`.
Intuitiveness is not the goal here. Repeatability is. The reason for
the "no arguments means no work" behavior is that from scripts you are
supposed to be able to do:
----------------
$ find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --
$ 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
$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
----------------
The `--` is just a good idea when you know the rest will be filenames;
@ -97,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
@ -139,19 +144,19 @@ EXAMPLES
To update and refresh only the files already checked out::
+
----------------
$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
$ 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:
+
----------------
$ git-checkout-index --prefix=git-export-dir/ -a
$ git checkout-index --prefix=git-export-dir/ -a
----------------
+
`git-checkout-index` will "export" the index into the specified
`git checkout-index` will "export" the index into the specified
directory.
+
The final "/" is important. The exported name is literally just
@ -161,7 +166,7 @@ following example.
Export files with a prefix::
+
----------------
$ git-checkout-index --prefix=.merged- Makefile
$ git checkout-index --prefix=.merged- Makefile
----------------
+
This will check out the currently cached copy of `Makefile`
@ -181,4 +186,4 @@ Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

141
Documentation/git-checkout.txt
Просмотреть файл

@ -3,34 +3,44 @@ git-checkout(1)
NAME
----
git-checkout - Checkout and switch to a branch
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>...
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.
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> 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
-------
@ -38,36 +48,49 @@ OPTIONS
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.
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 gitlink: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 -b is given and a branch is created off a remote branch,
set up configuration so that git-pull will automatically
retrieve data from the remote branch. Set the
branch.autosetupmerge configuration variable to true if you
want git-checkout and git-branch to always behave as if
'--track' were given.
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::
When -b is given and a branch is created off a remote branch,
set up configuration so that git-pull will not retrieve data
from the remote branch, ignoring the branch.autosetupmerge
configuration variable.
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.
@ -79,16 +102,39 @@ 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).
<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
@ -104,13 +150,13 @@ $ 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
`git-reset --hard $othercommit` to further move around, for
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
merge $othercommit`.
@ -143,8 +189,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.
@ -154,7 +200,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:
+
------------
@ -162,7 +208,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:
+
------------
@ -188,7 +234,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
------------
@ -214,4 +259,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

58
Documentation/git-cherry-pick.txt
Просмотреть файл

@ -7,7 +7,7 @@ git-cherry-pick - Apply the change introduced by an existing commit
SYNOPSIS
--------
'git-cherry-pick' [--edit] [-n] [-x] <commit>
'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
DESCRIPTION
-----------
@ -19,19 +19,21 @@ OPTIONS
-------
<commit>::
Commit to cherry-pick.
For a more complete list of ways to spell commits, see
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
For a more complete list of ways to spell commits, see the
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
-e|--edit::
With this option, `git-cherry-pick` will let you edit the commit
message prior committing.
-e::
--edit::
With this option, 'git-cherry-pick' will let you edit the commit
message prior to committing.
-x::
Cause the command to append which commit was
cherry-picked after the original commit message when
making a commit. Do not use this option if you are
cherry-picking from your private branch because the
information is useless to the recipient. If on the
When recording the commit, append to the original commit
message a note that indicates which commit this change
was cherry-picked from. Append the note only for cherry
picks without conflicts. Do not use this option if
you are cherry-picking from your private branch because
the information is useless to the recipient. If on the
other hand you are cherry-picking between two publicly
visible branches (e.g. backporting a fix to a
maintenance branch for an older release from a
@ -43,23 +45,35 @@ OPTIONS
described above, and `-r` was to disable it. Now the
default is not to do `-x` so this option is a no-op.
-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,
-m parent-number::
--mainline parent-number::
Usually you cannot cherry-pick a merge because you do not know which
side of the merge should be considered the mainline. This
option specifies the parent number (starting from 1) of
the mainline and allows cherry-pick to replay the change
relative to the specified parent.
-n::
--no-commit::
Usually the command automatically creates a commit.
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 working tree does not have to match
the HEAD commit. The cherry-pick is done against the
beginning state of your working tree.
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'
effect to your working tree in a row.
effect to your index in a row.
-s::
--signoff::
Add Signed-off-by line at the end of the commit message.
Author
------
Written by Junio C Hamano <junkio@cox.net>
Written by Junio C Hamano <gitster@pobox.com>
Documentation
--------------
@ -67,4 +81,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

17
Documentation/git-cherry.txt
Просмотреть файл

@ -7,12 +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.
Every commit that doesn't exist in the <upstream> branch
has its id (sha1) reported, prefixed by a symbol. The ones that have
@ -35,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.
@ -49,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.
@ -56,9 +59,13 @@ OPTIONS
<limit>::
Do not report commits up to (and including) limit.
SEE ALSO
--------
linkgit:git-patch-id[1]
Author
------
Written by Junio C Hamano <junkio@cox.net>
Written by Junio C Hamano <gitster@pobox.com>
Documentation
--------------
@ -66,4 +73,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

8
Documentation/git-citool.txt
Просмотреть файл

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

25
Documentation/git-clean.txt
Просмотреть файл

@ -8,17 +8,20 @@ git-clean - Remove untracked files from the working tree
SYNOPSIS
--------
[verse]
'git-clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...
'git clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <path>...
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.
When optional `<paths>...` arguments are given, the paths
affected are further limited to those that match them.
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
-------
@ -27,19 +30,21 @@ OPTIONS
-f::
If the git configuration specifies clean.requireForce as true,
git-clean will refuse to run unless given -f or -n.
'git-clean' will refuse to run unless given -f or -n.
-n::
--dry-run::
Don't actually remove anything, just show what would be done.
-q::
--quiet::
Be quiet, only report errors, but not the files that are
successfully removed.
-x::
Don't use the ignore rules. This allows removing all untracked
files, including build products. This can be used (possibly in
conjunction with gitlink:git-reset[1]) to create a pristine
conjunction with 'git-reset') to create a pristine
working directory to test a clean build.
-X::
@ -54,4 +59,4 @@ Written by Pavel Roskin <proski@gnu.org>
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

52
Documentation/git-clone.txt
Просмотреть файл

@ -9,10 +9,10 @@ git-clone - Clone a repository into a new directory
SYNOPSIS
--------
[verse]
'git-clone' [--template=<template_directory>]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
'git clone' [--template=<template_directory>]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
[--depth <depth>] <repository> [<directory>]
[--depth <depth>] [--] <repository> [<directory>]
DESCRIPTION
-----------
@ -62,19 +62,38 @@ OPTIONS
.git/objects/info/alternates to share the objects
with the source repository. The resulting repository
starts out without any object of its own.
+
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand what it does. If you clone your
repository using this option 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')
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.
--reference <repository>::
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 less objects to be copied from the repository
require fewer objects to be copied from the repository
being cloned, reducing network and local storage costs.
+
*NOTE*: see NOTE to --shared option.
--quiet::
-q::
Operate quietly. This flag is passed to "rsync" and
"git-fetch-pack" commands when given.
Operate quietly. This flag is also passed to the `rsync'
command when given.
--verbose::
-v::
Display the progressbar, even in case the standard output is not
a terminal.
--no-checkout::
-n::
@ -92,16 +111,18 @@ OPTIONS
used, neither remote-tracking branches nor the related
configuration variables are created.
--mirror::
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.
of the upstream repository, use <name>.
--upload-pack <upload-pack>::
-u <upload-pack>::
When given, and the repository to clone from is handled
by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
the command to specify non-default path for the command
When given, and the repository to clone from is accessed
via ssh, this specifies a non-default path for the command
run on the other end.
--template=<template_directory>::
@ -111,11 +132,11 @@ OPTIONS
--depth <depth>::
Create a 'shallow' clone with a history truncated to the
specified number of revs. A shallow repository has
specified number of revisions. A shallow repository has a
number of limitations (you cannot clone or fetch from
it, nor push from nor into it), but is adequate if you
want to only look at near the tip of a large project
with a long history, and would want to send in a fixes
are only interested in the recent history of a large project
with a long history, and would want to send in fixes
as patches.
<repository>::
@ -128,8 +149,9 @@ OPTIONS
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.
is only allowed if the directory is empty.
:git-clone: 1
include::urls.txt[]
Examples
@ -190,4 +212,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

26
Documentation/git-commit-tree.txt
Просмотреть файл

@ -8,20 +8,20 @@ git-commit-tree - Create a new commit object
SYNOPSIS
--------
'git-commit-tree' <tree> [-p <parent commit>]\* < changelog
'git commit-tree' <tree> [-p <parent commit>]\* < changelog
DESCRIPTION
-----------
This is usually not what an end user wants to run directly. See
gitlink:git-commit[1] instead.
linkgit:git-commit[1] instead.
Creates a new commit object based on the provided tree object and
emits the new commit object id on stdout. If no parent is given then
it is considered to be an initial tree.
emits the new commit object id on stdout.
A commit object usually has 1 parent (a commit after a change) or up
to 16 parents. More than one parent represents a merge of branches
that led to them.
A commit object may have any number of parents. With exactly one
parent, it is an ordinary commit. Having more than one parent makes
the commit a merge between several lines of history. Initial (root)
commits have no parents.
While a tree represents a particular directory state of a working
directory, a commit represents that state in "time", and explains how
@ -70,7 +70,7 @@ 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.
@ -79,18 +79,18 @@ 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
----------
include::i18n.txt[]
See Also
SEE ALSO
--------
gitlink:git-write-tree[1]
linkgit:git-write-tree[1]
Author
@ -103,4 +103,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

174
Documentation/git-commit.txt
Просмотреть файл

@ -8,28 +8,29 @@ git-commit - Record changes to the repository
SYNOPSIS
--------
[verse]
'git-commit' [-a | --interactive] [-s] [-v] [-u]
[(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
[--no-verify] [-e] [--author <author>]
[--] [[-i | -o ]<file>...]
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend]
[(-c | -C) <commit>] [-F <file> | -m <msg>]
[--allow-empty] [--no-verify] [-e] [--author=<author>]
[--cleanup=<mode>] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
Use 'git commit' to store the current contents of the index in a new
commit along with a log message describing the changes you have made.
Stores the current contents of the index in a new commit along
with a log message from the user describing the changes.
The content to be added can be specified in several ways:
1. by using gitlink:git-add[1] to incrementally "add" changes to the
1. by using 'git-add' to incrementally "add" changes to the
index before using the 'commit' command (Note: even modified
files must be "added");
2. by using gitlink:git-rm[1] to remove files from the working tree
2. by using '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,64 +40,93 @@ 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 gitlink:git-status[1] command can be used to obtain a
The 'git-status' command can be used to obtain a
summary of what is included by any of the above for the next
commit by giving the same set of parameters you would give to
this command.
If you make a commit and then found a mistake immediately after
that, you can recover from it with gitlink:git-reset[1].
If you make a commit and then find a mistake immediately after
that, you can recover from it with 'git-reset'.
OPTIONS
-------
-a|--all::
-a::
--all::
Tell the command to automatically stage files that have
been modified and deleted, but new files you have not
told git about are not affected.
-c or -C <commit>::
Take existing commit object, and reuse the log message
-C <commit>::
--reuse-message=<commit>::
Take an existing commit object, and reuse the log message
and the authorship information (including the timestamp)
when creating the commit. With '-C', the editor is not
invoked; with '-c' the user can further edit the commit
message.
when creating the commit.
-c <commit>::
--reedit-message=<commit>::
Like '-C', but with '-c' the editor is invoked, so that
the user can further edit the commit message.
-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.
--author=<author>::
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.
-m <msg>|--message=<msg>::
-m <msg>::
--message=<msg>::
Use the given <msg> as the commit message.
-t <file>|--template=<file>::
-t <file>::
--template=<file>::
Use the contents of the given file as the initial version
of the commit message. The editor is invoked and you can
make subsequent changes. If a message is specified using
the `-m` or `-F` options, this option has no effect. This
overrides the `commit.template` configuration variable.
-s|--signoff::
Add Signed-off-by line at the end of the commit message.
-s::
--signoff::
Add Signed-off-by line by the committer at the end of the commit
log message.
-n::
--no-verify::
This option bypasses the pre-commit hook.
See also link:hooks.html[hooks].
This option bypasses the pre-commit and commit-msg hooks.
See also linkgit:githooks[5].
-e|--edit::
--allow-empty::
Usually recording a commit that has the exact same tree as its
sole parent commit is a mistake, and the command prevents you
from making such a commit. This option bypasses the safety, and
is primarily for use by foreign scm interface scripts.
--cleanup=<mode>::
This option sets how the commit message is cleaned up.
The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
and 'default'. The 'default' mode will strip leading and
trailing empty lines and #commentary from the commit message
only if the message is to be edited. Otherwise only whitespace
removed. The 'verbatim' mode does not change message at all,
'whitespace' removes just leading/trailing whitespace lines
and 'strip' removes both whitespace and commentary.
-e::
--edit::
The message taken from file with `-F`, command line with
`-m`, and from file with `-C` are usually used as the
commit log message unmodified. This option lets you
further edit the message taken from these sources.
--amend::
Used to amend the tip of the current branch. Prepare the tree
object you would want to replace the latest commit as usual
(this includes the usual -i/-o and explicit paths), and the
@ -116,27 +146,56 @@ 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::
-i::
--include::
Before making a commit out of staged contents so far,
stage the contents of paths given on the command line
as well. This is usually not what you want unless you
are concluding a conflicted merge.
-u|--untracked-files::
Show all untracked files, also those in uninteresting
directories, in the "Untracked files:" section of commit
message template. Without this option only its name and
a trailing slash are displayed for each untracked
directory.
-o::
--only::
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,
in which case this option can be omitted.
If this option is specified together with '--amend', then
no paths need to be specified, which can be used to amend
the last commit without committing changes that have
already been staged.
-v|--verbose::
-u[<mode>]::
--untracked-files[=<mode>]::
Show untracked files (Default: 'all').
+
The mode parameter is optional, and is used to specify
the handling of untracked files. The possible options are:
+
--
- 'no' - Show no untracked files
- 'normal' - Shows untracked files and directories
- 'all' - Also shows individual files in untracked directories.
--
+
See linkgit:git-config[1] for configuration variable
used to change the default for when the option is not
specified.
-v::
--verbose::
Show unified diff between the HEAD commit and what
would be committed at the bottom of the commit message
template. Note that this diff output doesn't have its
lines prefixed with '#'.
-q|--quiet::
-q::
--quiet::
Suppress commit summary message.
\--::
@ -154,10 +213,13 @@ EXAMPLES
--------
When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
called the "index" with gitlink:git-add[1]. Removal
of a file is staged with gitlink:git-rm[1]. After building the
state to be committed incrementally with these commands, `git
commit` (without any pathname parameter) is used to record what
called the "index" with '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
this file from participating in the next commit. After building
the state to be committed incrementally with these commands,
`git commit` (without any pathname parameter) is used to record what
has been staged so far. This is the most basic form of the
command. An example:
@ -210,13 +272,13 @@ $ git commit
this second commit would record the changes to `hello.c` and
`hello.h` as expected.
After a merge (initiated by either gitlink:git-merge[1] or
gitlink:git-pull[1]) stops because of conflicts, cleanly merged
After a merge (initiated by '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 gitlink:git-status[1]
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 gitlink:git-add[1]:
stage the result as usual with 'git-add':
------------
$ git status | grep unmerged
@ -261,25 +323,25 @@ order).
HOOKS
-----
This command can run `commit-msg`, `pre-commit`, and
`post-commit` hooks. See link:hooks.html[hooks] for more
This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
and `post-commit` hooks. See linkgit:githooks[5] for more
information.
SEE ALSO
--------
gitlink:git-add[1],
gitlink:git-rm[1],
gitlink:git-mv[1],
gitlink:git-merge[1],
gitlink:git-commit-tree[1]
linkgit:git-add[1],
linkgit:git-rm[1],
linkgit:git-mv[1],
linkgit:git-merge[1],
linkgit:git-commit-tree[1]
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and
Junio C Hamano <junkio@cox.net>
Junio C Hamano <gitster@pobox.com>
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

101
Documentation/git-config.txt
Просмотреть файл

@ -9,17 +9,20 @@ git-config - Get and set repository or global options
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] [-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]
'git-config' [<file-option>] --unset name [value_regex]
'git-config' [<file-option>] --unset-all name [value_regex]
'git-config' [<file-option>] --rename-section old_name new_name
'git-config' [<file-option>] --remove-section name
'git-config' [<file-option>] [-z|--null] -l | --list
'git config' [<file-option>] [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] [-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]
'git config' [<file-option>] --unset name [value_regex]
'git config' [<file-option>] --unset-all name [value_regex]
'git config' [<file-option>] --rename-section old_name new_name
'git config' [<file-option>] --remove-section name
'git config' [<file-option>] [-z|--null] -l | --list
'git config' [<file-option>] --get-color name [default]
'git config' [<file-option>] --get-colorbool name [stdout-is-tty]
'git config' [<file-option>] -e | --edit
DESCRIPTION
-----------
@ -66,7 +69,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
@ -99,7 +103,8 @@ rather than from all available files.
+
See also <<FILES>>.
-f config-file, --file config-file::
-f config-file::
--file config-file::
Use the given config file instead of the one specified by GIT_CONFIG.
--remove-section::
@ -114,35 +119,63 @@ See also <<FILES>>.
--unset-all::
Remove all lines matching the key from config file.
-l, --list::
-l::
--list::
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.
-z, --null::
--bool-or-int::
'git-config' will ensure that the output matches the format of
either --bool or --int, as described above.
-z::
--null::
For all options that output values and/or keys, always
end values with with the null character (instead of a
end values with the null character (instead of a
newline). Use newline instead as a delimiter between
key and value. This allows for secure parsing of the
output without getting confused e.g. by values that
contain line breaks.
--get-colorbool name [stdout-is-tty]::
Find the color setting for `name` (e.g. `color.diff`) and output
"true" or "false". `stdout-is-tty` should be either "true" or
"false", and is taken into account when configuration says
"auto". If `stdout-is-tty` is missing, then checks the standard
output of the command itself, and exits with status 0 if color
is to be used, or exits with status 1 otherwise.
When the color setting for `name` is undefined, the command uses
`color.ui` as fallback.
--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/config::
$GIT_DIR/config::
Repository specific configuration file. (The filename is
of course relative to the repository root, not the working
directory.)
@ -157,23 +190,18 @@ $(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
to the global or system-wide file respectively. The GIT_CONFIG environment
variable has a similar effect, but you can specify any filename you want.
The GIT_CONFIG_LOCAL environment variable on the other hand only changes
the name used instead of the repository configuration file. The global and
the system-wide configuration files will still be read. (For writing options
this will obviously result in the same behavior as using GIT_CONFIG.)
ENVIRONMENT
-----------
@ -183,10 +211,6 @@ GIT_CONFIG::
Using the "--global" option forces this to ~/.gitconfig. Using the
"--system" option forces this to $(prefix)/etc/gitconfig.
GIT_CONFIG_LOCAL::
Take the configuration from the given file instead if .git/config.
Still read the global and the system-wide configuration files, though.
See also <<FILES>>.
@ -209,7 +233,7 @@ Given a .git/config like this:
; Our diff algorithm
[diff]
external = "/usr/local/bin/gnu-diff -u"
external = /usr/local/bin/diff-wrapper
renames = true
; Proxy settings
@ -266,7 +290,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
------------
@ -292,6 +316,15 @@ To add a new proxy, without altering any of the existing ones, use
% git config core.gitproxy '"proxy-command" for example.com'
------------
An example to use customized color from the configuration in your
script:
------------
#!/bin/sh
WS=$(git config --get-color color.diff.whitespace "blue reverse")
RESET=$(git config --get-color "" "reset")
echo "${WS}your whitespace color or blue reverse${RESET}"
------------
include::config.txt[]
@ -306,4 +339,4 @@ Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.ker
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

12
Documentation/git-count-objects.txt
Просмотреть файл

@ -7,7 +7,7 @@ git-count-objects - Count unpacked number of objects and their disk consumption
SYNOPSIS
--------
'git-count-objects' [-v]
'git count-objects' [-v]
DESCRIPTION
-----------
@ -18,15 +18,17 @@ them, to help you decide when it is a good time to repack.
OPTIONS
-------
-v::
--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
------
Written by Junio C Hamano <junkio@cox.net>
Written by Junio C Hamano <gitster@pobox.com>
Documentation
--------------
@ -34,4 +36,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

46
Documentation/git-cvsexportcommit.txt
Просмотреть файл

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

74
Documentation/git-cvsimport.txt
Просмотреть файл

@ -9,7 +9,7 @@ git-cvsimport - Salvage your data out of another SCM people love to hate
SYNOPSIS
--------
[verse]
'git-cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
'git cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
[-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
[-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
[-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
@ -24,13 +24,22 @@ 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.
If you intend to set up a shared public repository that all developers can
read/write, or if you want to use linkgit:git-cvsserver[1], then you
probably want to make a bare clone of the imported repository,
and use the clone as the shared repository.
See linkgit:gitcvs-migration[7].
OPTIONS
-------
@ -40,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>::
@ -56,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.
+
@ -102,13 +111,17 @@ If you need to pass multiple options, separate them with a comma.
-m::
Attempt to detect merges based on the commit message. This option
will enable default regexes that try to capture the name source
will enable default regexes that try to capture the source
branch name from the commit message.
-M <regex>::
Attempt to detect merges based on the commit message with a custom
regex. It can be used with '-m' to also see the default regexes.
You must escape forward slashes.
regex. It can be used with '-m' to enable the default regexes
as well. You must escape forward slashes.
+
The regex must capture the source branch name in $1.
+
This option can be used several times to provide several detection regexes.
-S <regex>::
Skip paths matching the regex.
@ -132,17 +145,17 @@ If you need to pass multiple options, separate them with a comma.
---------
+
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
gitlink:git-cvsexportcommit[1].
'git-cvsexportcommit'.
-h::
Print a short usage message and exit.
@ -154,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
------
@ -166,4 +212,4 @@ Documentation by Matthias Urlichs <smurf@smurf.noris.de>.
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[1] suite

Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше