diff options
Diffstat (limited to 'Documentation')
313 files changed, 19593 insertions, 4720 deletions
diff --git a/Documentation/.gitignore b/Documentation/.gitignore index d62aebd84..2c8b2d612 100644 --- a/Documentation/.gitignore +++ b/Documentation/.gitignore @@ -9,4 +9,5 @@ gitman.info howto-index.txt doc.dep cmds-*.txt +mergetools-*.txt manpage-base-url.xsl diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index fe1c1e5bc..ef67b53f7 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -1,5 +1,5 @@ Like other projects, we also have some guidelines to keep to the -code. For git in general, three rough rules are: +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." @@ -18,11 +18,12 @@ code. For git in general, three rough rules are: judgement call, the decision based more on real world constraints people face than what the paper standard says. +Make your code readable and sensible, and don't try to be clever. 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 +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). @@ -35,10 +36,22 @@ For shell scripts specifically (not exhaustive): - Case arms are indented at the same depth as case and esac lines. + - Redirection operators should be written with space before, but no + space after them. In other words, write 'echo test >"$file"' + instead of 'echo test> $file' or 'echo test > $file'. Note that + even though it is not required by POSIX to double-quote the + redirection target in a variable (as shown above), our code does so + because some versions of bash issue a warning without the quotes. + - 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. + - If you want to find out if a command is available on the user's + $PATH, you should use 'type <command>', instead of 'which <command>'. + The output of 'which' is not machine parseable and its exit code + is not reliable across platforms. + - We use POSIX compliant parameter substitutions and avoid bashisms; namely: @@ -64,11 +77,19 @@ For shell scripts specifically (not exhaustive): - We do not use Process Substitution <(list) or >(list). + - Do not write control structures on a single line with semicolon. + "then" should be on the next line for if statements, and "do" + should be on the next line for "while" and "for". + - We prefer "test" over "[ ... ]". - We do not write the noiseword "function" in front of shell functions. + - We prefer a space between the function name and the parentheses. The + opening "{" should also be on the same line. + E.g.: my_function () { + - As to use of grep, stick to a subset of BRE (namely, no \{m,n\}, [::], [==], nor [..]) for portability. @@ -81,6 +102,10 @@ For shell scripts specifically (not exhaustive): are ERE elements not BRE (note that \? and \+ are not even part of BRE -- making them accessible from BRE is a GNU extension). + - Use Git's gettext wrappers in git-sh-i18n to make the user + interface translatable. See "Marking strings for translation" in + po/README. + For C programs: - We use tabs to indent, and interpret tabs as taking up to @@ -88,6 +113,14 @@ For C programs: - We try to keep to at most 80 characters per line. + - We try to support a wide range of C compilers to compile Git with, + including old ones. That means that you should not use C99 + initializers, even if a lot of compilers grok it. + + - Variables have to be declared at the beginning of the block. + + - NULL pointers shall be written as NULL, not as 0. + - 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 @@ -112,6 +145,14 @@ For C programs: they were describing changes. Often splitting a function into two makes the intention of the code much clearer. + - Multi-line comments include their delimiters on separate lines from + the text. E.g. + + /* + * A very long + * multi-line comment. + */ + - Double negation is often harder to understand than no negation at all. @@ -132,25 +173,98 @@ For C programs: - 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 + 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 + - 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 + 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). + repositories to Git). - When we pass <string, length> pair to functions, we should try to pass them in that order. + - Use Git's gettext wrappers to make the user interface + translatable. See "Marking strings for translation" in po/README. + +For Perl programs: + + - Most of the C guidelines above apply. + + - We try to support Perl 5.8 and later ("use Perl 5.008"). + + - use strict and use warnings are strongly preferred. + + - Don't overuse statement modifiers unless using them makes the + result easier to follow. + + ... do something ... + do_this() unless (condition); + ... do something else ... + + is more readable than: + + ... do something ... + unless (condition) { + do_this(); + } + ... do something else ... + + *only* when the condition is so rare that do_this() will be almost + always called. + + - We try to avoid assignments inside "if ()" conditions. + + - Learn and use Git.pm if you need that functionality. + + - For Emacs, it's useful to put the following in + GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode: + + ;; note the first part is useful for C editing, too + ((nil . ((indent-tabs-mode . t) + (tab-width . 8) + (fill-column . 80))) + (cperl-mode . ((cperl-indent-level . 8) + (cperl-extra-newline-before-brace . nil) + (cperl-merge-trailing-else . t)))) + +For Python scripts: + + - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/). + + - As a minimum, we aim to be compatible with Python 2.6 and 2.7. + + - Where required libraries do not restrict us to Python 2, we try to + also be compatible with Python 3.1 and later. + + - When you must differentiate between Unicode literals and byte string + literals, it is OK to use the 'b' prefix. Even though the Python + documentation for version 2.6 does not mention this prefix, it has + been supported since version 2.6.0. + Writing Documentation: + Most (if not all) of the documentation pages are written in the + AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and + processed into HTML and manpages (e.g. git.html and git.1 in the + same directory). + + The documentation liberally mixes US and UK English (en_US/UK) + norms for spelling and grammar, which is somewhat unfortunate. + In an ideal world, it would have been better if it consistently + used only one and not the other, and we would have picked en_US + (if you wish to correct the English of some of the existing + documentation, please see the documentation-related advice in the + Documentation/SubmittingPatches file). + Every user-visible change should be reflected in the documentation. The same general rule as for code applies -- imitate the existing - conventions. A few commented examples follow to provide reference - when writing or modifying command usage strings and synopsis sections - in the manual pages: + conventions. + + A few commented examples follow to provide reference when writing or + modifying command usage strings and synopsis sections in the manual + pages: Placeholders are spelled in lowercase and enclosed in angle brackets: <file> @@ -195,3 +309,34 @@ Writing Documentation: valid usage. "*" has its own pair of brackets, because it can (optionally) be specified only when one or more of the letters is also provided. + + A note on notation: + Use 'git' (all lowercase) when talking about commands i.e. something + the user would type into a shell and use 'Git' (uppercase first letter) + when talking about the version control system and its properties. + + A few commented examples follow to provide reference when writing or + modifying paragraphs or option/command explanations that contain options + or commands: + + Literal examples (e.g. use of command-line options, command names, and + configuration variables) are typeset in monospace, and if you can use + `backticks around word phrases`, do so. + `--pretty=oneline` + `git rev-list` + `remote.pushdefault` + + Word phrases enclosed in `backtick characters` are rendered literally + and will not be further expanded. The use of `backticks` to achieve the + previous rule means that literal examples should not use AsciiDoc + escapes. + Correct: + `--pretty=oneline` + Incorrect: + `\--pretty=oneline` + + If some place in the documentation needs to typeset a command usage + example with inline substitutions, it is fine to use +monospaced and + inline substituted text+ instead of `monospaced literal text`, and with + the former, the part that should not get substituted must be + quoted/escaped. diff --git a/Documentation/Makefile b/Documentation/Makefile index 18c71d763..fc6b2cf9e 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -1,59 +1,114 @@ -MAN1_TXT= \ - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ - $(wildcard 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 gitrevisions.txt gitworkflows.txt +# Guard against environment variables +MAN1_TXT = +MAN5_TXT = +MAN7_TXT = +TECH_DOCS = +ARTICLES = +SP_ARTICLES = + +MAN1_TXT += $(filter-out \ + $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ + $(wildcard git-*.txt)) +MAN1_TXT += git.txt +MAN1_TXT += gitk.txt +MAN1_TXT += gitremote-helpers.txt +MAN1_TXT += gitweb.txt + +MAN5_TXT += gitattributes.txt +MAN5_TXT += githooks.txt +MAN5_TXT += gitignore.txt +MAN5_TXT += gitmodules.txt +MAN5_TXT += gitrepository-layout.txt +MAN5_TXT += gitweb.conf.txt + +MAN7_TXT += gitcli.txt +MAN7_TXT += gitcore-tutorial.txt +MAN7_TXT += gitcredentials.txt +MAN7_TXT += gitcvs-migration.txt +MAN7_TXT += gitdiffcore.txt +MAN7_TXT += gitglossary.txt +MAN7_TXT += gitnamespaces.txt +MAN7_TXT += gitrevisions.txt +MAN7_TXT += gittutorial-2.txt +MAN7_TXT += gittutorial.txt +MAN7_TXT += gitworkflows.txt MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) -MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT)) -MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT)) +MAN_XML = $(patsubst %.txt,%.xml,$(MAN_TXT)) +MAN_HTML = $(patsubst %.txt,%.html,$(MAN_TXT)) -DOC_HTML=$(MAN_HTML) +OBSOLETE_HTML = git-remote-helpers.html +DOC_HTML = $(MAN_HTML) $(OBSOLETE_HTML) -ARTICLES = howto-index +ARTICLES += howto-index ARTICLES += everyday ARTICLES += git-tools ARTICLES += git-bisect-lk2009 # with their own formatting rules. -SP_ARTICLES = howto/revert-branch-rebase howto/using-merge-subtree user-manual +SP_ARTICLES += user-manual +SP_ARTICLES += howto/new-command +SP_ARTICLES += howto/revert-branch-rebase +SP_ARTICLES += howto/using-merge-subtree +SP_ARTICLES += howto/using-signed-tag-in-pull-request +SP_ARTICLES += howto/use-git-daemon +SP_ARTICLES += howto/update-hook-example +SP_ARTICLES += howto/setup-git-server-over-http +SP_ARTICLES += howto/separating-topic-branches +SP_ARTICLES += howto/revert-a-faulty-merge +SP_ARTICLES += howto/recover-corrupted-blob-object +SP_ARTICLES += howto/recover-corrupted-object-harder +SP_ARTICLES += howto/rebuild-from-update-hook +SP_ARTICLES += howto/rebase-from-internal-branch +SP_ARTICLES += howto/maintain-git API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) SP_ARTICLES += $(API_DOCS) + +TECH_DOCS += technical/http-protocol +TECH_DOCS += technical/index-format +TECH_DOCS += technical/pack-format +TECH_DOCS += technical/pack-heuristics +TECH_DOCS += technical/pack-protocol +TECH_DOCS += technical/protocol-capabilities +TECH_DOCS += technical/protocol-common +TECH_DOCS += technical/racy-git +TECH_DOCS += technical/send-pack-pipeline +TECH_DOCS += technical/shallow +TECH_DOCS += technical/trivial-merge +SP_ARTICLES += $(TECH_DOCS) SP_ARTICLES += technical/api-index DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES)) -DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT)) -DOC_MAN5=$(patsubst %.txt,%.5,$(MAN5_TXT)) -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 -man7dir=$(mandir)/man7 -# DESTDIR= - -ASCIIDOC=asciidoc +DOC_MAN1 = $(patsubst %.txt,%.1,$(MAN1_TXT)) +DOC_MAN5 = $(patsubst %.txt,%.5,$(MAN5_TXT)) +DOC_MAN7 = $(patsubst %.txt,%.7,$(MAN7_TXT)) + +prefix ?= $(HOME) +bindir ?= $(prefix)/bin +htmldir ?= $(prefix)/share/doc/git-doc +infodir ?= $(prefix)/share/info +pdfdir ?= $(prefix)/share/doc/git-doc +mandir ?= $(prefix)/share/man +man1dir = $(mandir)/man1 +man5dir = $(mandir)/man5 +man7dir = $(mandir)/man7 +# DESTDIR = + +ASCIIDOC = asciidoc ASCIIDOC_EXTRA = MANPAGE_XSL = manpage-normal.xsl +XMLTO = xmlto XMLTO_EXTRA = -INSTALL?=install +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 +MAN_REPO = ../../git-manpages +HTML_REPO = ../../git-htmldocs + +MAKEINFO = makeinfo +INSTALL_INFO = install-info +DOCBOOK2X_TEXI = docbook2x-texi +DBLATEX = dblatex +ASCIIDOC_DBLATEX_DIR = /etc/asciidoc/dblatex ifndef PERL_PATH PERL_PATH = /usr/bin/perl endif @@ -62,12 +117,6 @@ endif -include ../config.mak # -# For asciidoc ... -# -7.1.2, set ASCIIDOC7 -# 8.0-, no extra settings are needed -# - -# # For docbook-xsl ... # -1.68.1, no extra settings are needed? # 1.69.0, set ASCIIDOC_ROFF? @@ -77,9 +126,6 @@ endif # 1.73.0-, no extra settings are needed # -ifndef ASCIIDOC7 -ASCIIDOC_EXTRA += -a asciidoc7compatible -a no-inline-literal -endif ifdef DOCBOOK_XSL_172 ASCIIDOC_EXTRA += -a git-asciidoc-no-roff MANPAGE_XSL = manpage-1.72.xsl @@ -120,14 +166,15 @@ 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: -# http://marc.theaimsgroup.com/?l=git&m=111558757202243&w=2 -# -# Until that version is released you may have to apply the patch -# yourself - yes, all 6 characters of it! -# +ifdef DEFAULT_PAGER +DEFAULT_PAGER_SQ = $(subst ','\'',$(DEFAULT_PAGER)) +ASCIIDOC_EXTRA += -a 'git-default-pager=$(DEFAULT_PAGER_SQ)' +endif + +ifdef DEFAULT_EDITOR +DEFAULT_EDITOR_SQ = $(subst ','\'',$(DEFAULT_EDITOR)) +ASCIIDOC_EXTRA += -a 'git-default-editor=$(DEFAULT_EDITOR_SQ)' +endif QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir QUIET_SUBDIR1 = @@ -159,8 +206,6 @@ all: html man html: $(DOC_HTML) -$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7): asciidoc.conf - man: man1 man5 man7 man1: $(DOC_MAN1) man5: $(DOC_MAN5) @@ -205,7 +250,11 @@ install-html: html # # Determine "include::" file references in asciidoc files. # -doc.dep : $(wildcard *.txt) build-docdep.perl +docdep_prereqs = \ + mergetools-list.made $(mergetools_txt) \ + cmd-list.made $(cmds_txt) + +doc.dep : $(docdep_prereqs) $(wildcard *.txt) build-docdep.perl $(QUIET_GEN)$(RM) $@+ $@ && \ $(PERL_PATH) ./build-docdep.perl >$@+ $(QUIET_STDERR) && \ mv $@+ $@ @@ -229,29 +278,49 @@ cmd-list.made: cmd-list.perl ../command-list.txt $(MAN1_TXT) $(PERL_PATH) ./cmd-list.perl ../command-list.txt $(QUIET_STDERR) && \ date >$@ +mergetools_txt = mergetools-diff.txt mergetools-merge.txt + +$(mergetools_txt): mergetools-list.made + +mergetools-list.made: ../git-mergetool--lib.sh $(wildcard ../mergetools/*) + $(QUIET_GEN)$(RM) $@ && \ + $(SHELL_PATH) -c 'MERGE_TOOLS_DIR=../mergetools && \ + . ../git-mergetool--lib.sh && \ + show_tool_names can_diff "* " || :' >mergetools-diff.txt && \ + $(SHELL_PATH) -c 'MERGE_TOOLS_DIR=../mergetools && \ + . ../git-mergetool--lib.sh && \ + show_tool_names can_merge "* " || :' >mergetools-merge.txt && \ + date >$@ + clean: $(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 $(RM) *.texi *.texi+ *.texi++ git.info gitman.info $(RM) *.pdf $(RM) howto-index.txt howto/*.html doc.dep - $(RM) technical/api-*.html technical/api-index.txt - $(RM) $(cmds_txt) *.made + $(RM) technical/*.html technical/api-index.txt + $(RM) $(cmds_txt) $(mergetools_txt) *.made $(RM) manpage-base-url.xsl -$(MAN_HTML): %.html : %.txt +$(MAN_HTML): %.html : %.txt asciidoc.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ mv $@+ $@ +$(OBSOLETE_HTML): %.html : %.txto asciidoc.conf + $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ + $(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ + $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ + mv $@+ $@ + manpage-base-url.xsl: manpage-base-url.xsl.in sed "s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|" $< > $@ %.1 %.5 %.7 : %.xml manpage-base-url.xsl $(QUIET_XMLTO)$(RM) $@ && \ - xmlto -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $< + $(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $< -%.xml : %.txt +%.xml : %.txt asciidoc.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ $(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ @@ -259,14 +328,15 @@ manpage-base-url.xsl: manpage-base-url.xsl.in user-manual.xml: user-manual.txt user-manual.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b docbook -d book -o $@+ $< && \ + $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b docbook -d article -o $@+ $< && \ mv $@+ $@ 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 +technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../ +$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt asciidoc.conf $(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt @@ -290,7 +360,7 @@ user-manual.texi: user-manual.xml 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 $< && \ + $(DBLATEX) -o $@+ -p $(ASCIIDOC_DBLATEX_DIR)/asciidoc-dblatex.xsl -s $(ASCIIDOC_DBLATEX_DIR)/asciidoc-dblatex.sty $< && \ mv $@+ $@ gitman.texi: $(MAN_XML) cat-texi.perl @@ -311,7 +381,7 @@ $(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml howto-index.txt: howto-index.sh $(wildcard howto/*.txt) $(QUIET_GEN)$(RM) $@+ $@ && \ - '$(SHELL_PATH_SQ)' ./howto-index.sh $(wildcard howto/*.txt) >$@+ && \ + '$(SHELL_PATH_SQ)' ./howto-index.sh $(sort $(wildcard howto/*.txt)) >$@+ && \ mv $@+ $@ $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt @@ -319,6 +389,7 @@ $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt WEBDOC_DEST = /pub/software/scm/git/docs +howto/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ sed -e '1,/^$$/d' $< | $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 - >$@+ && \ @@ -327,12 +398,26 @@ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt install-webdoc : html '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(WEBDOC_DEST) +# You must have a clone of 'git-htmldocs' and 'git-manpages' repositories +# next to the 'git' repository itself for the following to work. + quick-install: quick-install-man -quick-install-man: - '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir) +require-manrepo:: + @if test ! -d $(MAN_REPO); \ + then echo "git-manpages repository must exist at $(MAN_REPO)"; exit 1; fi + +quick-install-man: require-manrepo + '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(MAN_REPO) $(DESTDIR)$(mandir) + +require-htmlrepo:: + @if test ! -d $(HTML_REPO); \ + then echo "git-htmldocs repository must exist at $(HTML_REPO)"; exit 1; fi + +quick-install-html: require-htmlrepo + '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REPO) $(DESTDIR)$(htmldir) -quick-install-html: - '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir) +print-man1: + @for i in $(MAN1_TXT); do echo $$i; done .PHONY: FORCE diff --git a/Documentation/RelNotes/1.5.2.1.txt b/Documentation/RelNotes/1.5.2.1.txt index ebf20e22a..d41984df0 100644 --- a/Documentation/RelNotes/1.5.2.1.txt +++ b/Documentation/RelNotes/1.5.2.1.txt @@ -45,9 +45,3 @@ Fixes since v1.5.2 - git-fastimport --import-marks was broken; fixed. - A lot of documentation updates, clarifications and fixes. - --- -exec >/var/tmp/1 -O=v1.5.2-65-g996e2d6 -echo O=`git describe refs/heads/maint` -git shortlog --no-merges $O..refs/heads/maint diff --git a/Documentation/RelNotes/1.6.0.2.txt b/Documentation/RelNotes/1.6.0.2.txt index e1e24b329..7d8fb85e1 100644 --- a/Documentation/RelNotes/1.6.0.2.txt +++ b/Documentation/RelNotes/1.6.0.2.txt @@ -79,9 +79,3 @@ Fixes since v1.6.0.1 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 diff --git a/Documentation/RelNotes/1.6.1.3.txt b/Documentation/RelNotes/1.6.1.3.txt index 6f0bde156..cd08d8174 100644 --- a/Documentation/RelNotes/1.6.1.3.txt +++ b/Documentation/RelNotes/1.6.1.3.txt @@ -26,7 +26,3 @@ Fixes since v1.6.1.2 * 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.. diff --git a/Documentation/RelNotes/1.6.1.4.txt b/Documentation/RelNotes/1.6.1.4.txt index 0ce6316d7..ccbad794c 100644 --- a/Documentation/RelNotes/1.6.1.4.txt +++ b/Documentation/RelNotes/1.6.1.4.txt @@ -39,6 +39,3 @@ Fixes since v1.6.1.3 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.. diff --git a/Documentation/RelNotes/1.6.1.txt b/Documentation/RelNotes/1.6.1.txt index adb7ccab0..7b152a6fd 100644 --- a/Documentation/RelNotes/1.6.1.txt +++ b/Documentation/RelNotes/1.6.1.txt @@ -278,9 +278,3 @@ release, unless otherwise noted. * "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 diff --git a/Documentation/RelNotes/1.7.10.1.txt b/Documentation/RelNotes/1.7.10.1.txt new file mode 100644 index 000000000..be68524cf --- /dev/null +++ b/Documentation/RelNotes/1.7.10.1.txt @@ -0,0 +1,78 @@ +Git v1.7.10.1 Release Notes +=========================== + +Additions since v1.7.10 +----------------------- + +Localization message files for Danish and German have been added. + + +Fixes since v1.7.10 +------------------- + + * "git add -p" is not designed to deal with unmerged paths but did + not exclude them and tried to apply funny patches only to fail. + + * "git blame" started missing quite a few changes from the origin + since we stopped using the diff minimization by default in v1.7.2 + era. + + * When PATH contains an unreadable directory, alias expansion code + did not kick in, and failed with an error that said "git-subcmd" + was not found. + + * "git clean -d -f" (not "-d -f -f") is supposed to protect nested + working trees of independent git repositories that exist in the + current project working tree from getting removed, but the + protection applied only to such working trees that are at the + top-level of the current project by mistake. + + * "git commit --author=$name" did not tell the name that was being + recorded in the resulting commit to hooks, even though it does do + so when the end user overrode the authorship via the + "GIT_AUTHOR_NAME" environment variable. + + * When "git commit --template F" errors out because the user did not + touch the message, it claimed that it aborts due to "empty + message", which was utterly wrong. + + * The regexp configured with diff.wordregex was incorrectly reused + across files. + + * An age-old corner case bug in combine diff (only triggered with -U0 + and the hunk at the beginning of the file needs to be shown) has + been fixed. + + * Rename detection logic used to match two empty files as renames + during merge-recursive, leading to unnatural mismerges. + + * The parser in "fast-import" did not diagnose ":9" style references + that is not followed by required SP/LF as an error. + + * When "git fetch" encounters repositories with too many references, + the command line of "fetch-pack" that is run by a helper + e.g. remote-curl, may fail to hold all of them. Now such an + internal invocation can feed the references through the standard + input of "fetch-pack". + + * "git fetch" that recurses into submodules on demand did not check + if it needs to go into submodules when non branches (most notably, + tags) are fetched. + + * "log -p --graph" used with "--stat" had a few formatting error. + + * Running "notes merge --commit" failed to perform correctly when run + from any directory inside $GIT_DIR/. When "notes merge" stops with + conflicts, $GIT_DIR/NOTES_MERGE_WORKTREE is the place a user edits + to resolve it. + + * The 'push to upstream' implementation was broken in some corner + cases. "git push $there" without refspec, when the current branch + is set to push to a remote different from $there, used to push to + $there using the upstream information to a remote unreleated to + $there. + + * Giving "--continue" to a conflicted "rebase -i" session skipped a + commit that only results in changes to submodules. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.10.2.txt b/Documentation/RelNotes/1.7.10.2.txt new file mode 100644 index 000000000..7a7e9d6fd --- /dev/null +++ b/Documentation/RelNotes/1.7.10.2.txt @@ -0,0 +1,85 @@ +Git v1.7.10.2 Release Notes +=========================== + +Fixes since v1.7.10.1 +--------------------- + + * The test scaffolding for git-daemon was flaky. + + * The test scaffolding for fast-import was flaky. + + * The filesystem boundary was not correctly reported when .git directory + discovery stopped at a mount point. + + * HTTP transport that requires authentication did not work correctly when + multiple connections are used simultaneously. + + * Minor memory leak during unpack_trees (hence "merge" and "checkout" + to check out another branch) has been plugged. + + * In the older days, the header "Conflicts:" in "cherry-pick" and "merge" + was separated by a blank line from the list of paths that follow for + readability, but when "merge" was rewritten in C, we lost it by + mistake. Remove the newline from "cherry-pick" to make them match + again. + + * The command line parser choked "git cherry-pick $name" when $name can + be both revision name and a pathname, even though $name can never be a + path in the context of the command. + + * The "include.path" facility in the configuration mechanism added in + 1.7.10 forgot to interpret "~/path" and "~user/path" as it should. + + * "git config --rename-section" to rename an existing section into a + bogus one did not check the new name. + + * The "diff --no-index" codepath used limited-length buffers, risking + pathnames getting truncated. Update it to use the strbuf API. + + * The report from "git fetch" said "new branch" even for a non branch + ref. + + * The http-backend (the server side of the smart http transfer) used + to overwrite GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL with the + value obtained from REMOTE_USER unconditionally, making it + impossible for the server side site-specific customization to use + different identity sources to affect the names logged. It now uses + REMOTE_USER only as a fallback value. + + * "log --graph" was not very friendly with "--stat" option and its + output had line breaks at wrong places. + + * Octopus merge strategy did not reduce heads that are recorded in the + final commit correctly. + + * "git push" over smart-http lost progress output a few releases ago; + this release resurrects it. + + * The error and advice messages given by "git push" when it fails due + to non-ff were not very helpful to new users; it has been broken + into three cases, and each is given a separate advice message. + + * The insn sheet given by "rebase -i" did not make it clear that the + insn lines can be re-ordered to affect the order of the commits in + the resulting history. + + * "git repack" used to write out unreachable objects as loose objects + when repacking, even if such loose objects will immediately pruned + due to its age. + + * A contrib script "rerere-train" did not work out of the box unless + user futzed with her $PATH. + + * "git rev-parse --show-prefix" used to emit nothing when run at the + top-level of the working tree, but now it gives a blank line. + + * The i18n of error message "git stash save" was not properly done. + + * "git submodule" used a sed script that some platforms mishandled. + + * When using a Perl script on a system where "perl" found on user's + $PATH could be ancient or otherwise broken, we allow builders to + specify the path to a good copy of Perl with $PERL_PATH. The + gitweb test forgot to use that Perl when running its test. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.10.3.txt b/Documentation/RelNotes/1.7.10.3.txt new file mode 100644 index 000000000..703fbf1d6 --- /dev/null +++ b/Documentation/RelNotes/1.7.10.3.txt @@ -0,0 +1,43 @@ +Git v1.7.10.3 Release Notes +=========================== + +Fixes since v1.7.10.2 +--------------------- + + * The message file for German translation has been updated a bit. + + * Running "git checkout" on an unborn branch used to corrupt HEAD. + + * When checking out another commit from an already detached state, we + used to report all commits that are not reachable from any of the + refs as lossage, but some of them might be reachable from the new + HEAD, and there is no need to warn about them. + + * Some time ago, "git clone" lost the progress output for its + "checkout" phase; when run without any "--quiet" option, it should + give progress to the lengthy operation. + + * The directory path used in "git diff --no-index", when it recurses + down, was broken with a recent update after v1.7.10.1 release. + + * "log -z --pretty=tformat:..." did not terminate each record with + NUL. The fix is not entirely correct when the output also asks for + --patch and/or --stat, though. + + * The DWIM behaviour for "log --pretty=format:%gd -g" was somewhat + broken and gave undue precedence to configured log.date, causing + "git stash list" to show "stash@{time stamp string}". + + * "git status --porcelain" ignored "--branch" option by mistake. The + output for "git status --branch -z" was also incorrect and did not + terminate the record for the current branch name with NUL as asked. + + * When a submodule repository uses alternate object store mechanism, + some commands that were started from the superproject did not + notice it and failed with "No such object" errors. The subcommands + of "git submodule" command that recursed into the submodule in a + separate process were OK; only the ones that cheated and peeked + directly into the submodule's repository from the primary process + were affected. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.10.4.txt b/Documentation/RelNotes/1.7.10.4.txt new file mode 100644 index 000000000..326670df6 --- /dev/null +++ b/Documentation/RelNotes/1.7.10.4.txt @@ -0,0 +1,29 @@ +Git v1.7.10.4 Release Notes +=========================== + +Fixes since v1.7.10.3 +--------------------- + + * The message file for Swedish translation has been updated a bit. + + * A name taken from mailmap was copied into an internal buffer + incorrectly and could overun the buffer if it is too long. + + * A malformed commit object that has a header line chomped in the + middle could kill git with a NULL pointer dereference. + + * An author/committer name that is a single character was mishandled + as an invalid name by mistake. + + * The progress indicator for a large "git checkout" was sent to + stderr even if it is not a terminal. + + * "git grep -e '$pattern'", unlike the case where the patterns are + read from a file, did not treat individual lines in the given + pattern argument as separate regular expressions as it should. + + * When "git rebase" was given a bad commit to replay the history on, + its error message did not correctly give the command line argument + it had trouble parsing. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.10.5.txt b/Documentation/RelNotes/1.7.10.5.txt new file mode 100644 index 000000000..4db1770e3 --- /dev/null +++ b/Documentation/RelNotes/1.7.10.5.txt @@ -0,0 +1,12 @@ +Git v1.7.10.5 Release Notes +=========================== + +Fixes since v1.7.10.4 +--------------------- + + * "git fast-export" did not give a readable error message when the + same mark erroneously appeared twice in the --import-marks input. + + * "git rebase -p" used to pay attention to rebase.autosquash which + was wrong. "git rebase -p -i" should, but "git rebase -p" by + itself should not. diff --git a/Documentation/RelNotes/1.7.10.txt b/Documentation/RelNotes/1.7.10.txt new file mode 100644 index 000000000..58100bf04 --- /dev/null +++ b/Documentation/RelNotes/1.7.10.txt @@ -0,0 +1,219 @@ +Git v1.7.10 Release Notes +========================= + +Compatibility Notes +------------------- + + * From this release on, the "git merge" command in an interactive + session will start an editor when it automatically resolves the + merge for the user to explain the resulting commit, just like the + "git commit" command does when it wasn't given a commit message. + + If you have a script that runs "git merge" and keeps its standard + input and output attached to the user's terminal, and if you do not + want the user to explain the resulting merge commits, you can + export GIT_MERGE_AUTOEDIT environment variable set to "no", like + this: + + #!/bin/sh + GIT_MERGE_AUTOEDIT=no + export GIT_MERGE_AUTOEDIT + + to disable this behavior (if you want your users to explain their + merge commits, you do not have to do anything). Alternatively, you + can give the "--no-edit" option to individual invocations of the + "git merge" command if you know everybody who uses your script has + Git v1.7.8 or newer. + + * The "--binary/-b" options to "git am" have been a no-op for quite a + while and were deprecated in mid 2008 (v1.6.0). When you give these + options to "git am", it will now warn and ask you not to use them. + + * When you do not tell which branches and tags to push to the "git + push" command in any way, the command used "matching refs" rule to + update remote branches and tags with branches and tags with the + same name you locally have. In future versions of Git, this will + change to push out only your current branch according to either the + "upstream" or the "current" rule. Although "upstream" may be more + powerful once the user understands Git better, the semantics + "current" gives is simpler and easier to understand for beginners + and may be a safer and better default option. We haven't decided + yet which one to switch to. + + +Updates since v1.7.9 +-------------------- + +UI, Workflows & Features + + * various "gitk" updates. + - show the path to the top level directory in the window title + - update preference edit dialog + - display file list correctly when directories are given on command line + - make "git-describe" output in the log message into a clickable link + - avoid matching the UNIX timestamp part when searching all fields + - give preference to symbolic font names like sans & monospace + - allow comparing two commits using a mark + - "gitk" honors log.showroot configuration. + + * Teams for localizing the messages from the Porcelain layer of + commands are starting to form, thanks to Jiang Xin who volunteered + to be the localization coordinator. Translated messages for + simplified Chinese, Swedish and Portuguese are available. + + * The configuration mechanism learned an "include" facility; an + assignment to the include.path pseudo-variable causes the named + file to be included in-place when Git looks up configuration + variables. + + * A content filter (clean/smudge) used to be just a way to make the + recorded contents "more useful", and allowed to fail; a filter can + now optionally be marked as "required". + + * Options whose names begin with "--no-" (e.g. the "--no-verify" + option of the "git commit" command) can be negated by omitting + "no-" from its name, e.g. "git commit --verify". + + * "git am" learned to pass "-b" option to underlying "git mailinfo", so + that a bracketed string other than "PATCH" at the beginning can be kept. + + * "git clone" learned "--single-branch" option to limit cloning to a + single branch (surprise!); tags that do not point into the history + of the branch are not fetched. + + * "git clone" learned to detach the HEAD in the resulting repository + when the user specifies a tag with "--branch" (e.g., "--branch=v1.0"). + Clone also learned to print the usual "detached HEAD" advice in such + a case, similar to "git checkout v1.0". + + * When showing a patch while ignoring whitespace changes, the context + lines are taken from the postimage, in order to make it easier to + view the output. + + * "git diff --stat" learned to adjust the width of the output on + wider terminals, and give more columns to pathnames as needed. + + * "diff-highlight" filter (in contrib/) was updated to produce more + aesthetically pleasing output. + + * "fsck" learned "--no-dangling" option to omit dangling object + information. + + * "git log -G" and "git log -S" learned to pay attention to the "-i" + option. With "-i", "log -G" ignores the case when finding patch + hunks that introduce or remove a string that matches the given + pattern. Similarly with "-i", "log -S" ignores the case when + finding the commit the given block of text appears or disappears + from the file. + + * "git merge" in an interactive session learned to spawn the editor + by default to let the user edit the auto-generated merge message, + to encourage people to explain their merges better. Legacy scripts + can export GIT_MERGE_AUTOEDIT=no to retain the historical behavior. + Both "git merge" and "git pull" can be given --no-edit from the + command line to accept the auto-generated merge message. + + * The advice message given when the user didn't give enough clue on + what to merge to "git pull" and "git merge" has been updated to + be more concise and easier to understand. + + * "git push" learned the "--prune" option, similar to "git fetch". + + * The whole directory that houses a top-level superproject managed by + "git submodule" can be moved to another place. + + * "git symbolic-ref" learned the "--short" option to abbreviate the + refname it shows unambiguously. + + * "git tag --list" can be given "--points-at <object>" to limit its + output to those that point at the given object. + + * "gitweb" allows intermediate entries in the directory hierarchy + that leads to a project to be clicked, which in turn shows the + list of projects inside that directory. + + * "gitweb" learned to read various pieces of information for the + repositories lazily, instead of reading everything that could be + needed (including the ones that are not necessary for a specific + task). + + * Project search in "gitweb" shows the substring that matched in the + project name and description highlighted. + + * HTTP transport learned to authenticate with a proxy if needed. + + * A new script "diffall" is added to contrib/; it drives an + external tool to perform a directory diff of two Git revisions + in one go, unlike "difftool" that compares one file at a time. + +Foreign Interface + + * Improved handling of views, labels and branches in "git-p4" (in contrib). + + * "git-p4" (in contrib) suffered from unnecessary merge conflicts when + p4 expanded the embedded $RCS$-like keywords; it can be now told to + unexpand them. + + * Some "git-svn" updates. + + * "vcs-svn"/"svn-fe" learned to read dumps with svn-deltas and + support incremental imports. + + * "git difftool/mergetool" learned to drive DeltaWalker. + +Performance + + * Unnecessary calls to parse_object() "git upload-pack" makes in + response to "git fetch", have been eliminated, to help performance + in repositories with excessive number of refs. + +Internal Implementation (please report possible regressions) + + * Recursive call chains in "git index-pack" to deal with long delta + chains have been flattened, to reduce the stack footprint. + + * Use of add_extra_ref() API is now gone, to make it possible to + cleanly restructure the overall refs API. + + * The command line parser of "git pack-objects" now uses parse-options + API. + + * The test suite supports the new "test_pause" helper function. + + * Parallel to the test suite, there is a beginning of performance + benchmarking framework. + + * t/Makefile is adjusted to prevent newer versions of GNU make from + running tests in seemingly random order. + + * The code to check if a path points at a file beyond a symbolic link + has been restructured to be thread-safe. + + * When pruning directories that has become empty during "git prune" + and "git prune-packed", call closedir() that iterates over a + directory before rmdir() it. + +Also contains minor documentation updates and code clean-ups. + + +Fixes since v1.7.9 +------------------ + +Unless otherwise noted, all the fixes since v1.7.9 in the maintenance +releases are contained in this release (see release notes to them for +details). + + * Build with NO_PERL_MAKEMAKER was broken and Git::I18N did not work + with versions of Perl older than 5.8.3. + (merge 5eb660e ab/perl-i18n later to maint). + + * "git tag -s" honored "gpg.program" configuration variable since + 1.7.9, but "git tag -v" and "git verify-tag" didn't. + (merge a2c2506 az/verify-tag-use-gpg-config later to maint). + + * "configure" script learned to take "--with-sane-tool-path" from the + command line to record SANE_TOOL_PATH (used to avoid broken platform + tools in /usr/bin) in config.mak.autogen. This may be useful for + people on Solaris who have saner tools outside /usr/xpg[46]/bin. + + * zsh port of bash completion script needed another workaround. diff --git a/Documentation/RelNotes/1.7.11.1.txt b/Documentation/RelNotes/1.7.11.1.txt new file mode 100644 index 000000000..577eccaac --- /dev/null +++ b/Documentation/RelNotes/1.7.11.1.txt @@ -0,0 +1,9 @@ +Git v1.7.11.1 Release Notes +=========================== + +Fixes since v1.7.11 +------------------- + + * The cross links in the HTML version of manual pages were broken. + +Also contains minor typofixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.11.2.txt b/Documentation/RelNotes/1.7.11.2.txt new file mode 100644 index 000000000..f0cfd02d6 --- /dev/null +++ b/Documentation/RelNotes/1.7.11.2.txt @@ -0,0 +1,53 @@ +Git v1.7.11.2 Release Notes +=========================== + +Fixes since v1.7.11.1 +--------------------- + + * On Cygwin, the platform pread(2) is not thread safe, just like our + own compat/ emulation, and cannot be used in the index-pack + program. Makefile variable NO_THREAD_SAFE_PREAD can be defined to + avoid use of this function in a threaded program. + + * "git add" allows adding a regular file to the path where a + submodule used to exist, but "git update-index" does not allow an + equivalent operation to Porcelain writers. + + * "git archive" incorrectly computed the header checksum; the symptom + was observed only when using pathnames with hi-bit set. + + * "git blame" did not try to make sure that the abbreviated commit + object names in its output are unique. + + * Running "git bundle verify" on a bundle that records a complete + history said "it requires these 0 commits". + + * "git clone --single-branch" to clone a single branch did not limit + the cloning to the specified branch. + + * "git diff --no-index" did not correctly handle relative paths and + did not correctly give exit codes when run under "--quiet" option. + + * "git diff --no-index" did not work with pagers correctly. + + * "git diff COPYING HEAD:COPYING" gave a nonsense error message that + claimed that the tree-ish HEAD did not have COPYING in it. + + * When "git log" gets "--simplify-merges/by-decoration" together with + "--first-parent", the combination of these options makes the + simplification logic to use in-core commit objects that haven't + been examined for relevance, either producing incorrect result or + taking too long to produce any output. Teach the simplification + logic to ignore commits that the first-parent traversal logic + ignored when both are in effect to work around the issue. + + * "git ls-files --exclude=t -i" did not consider anything under t/ as + excluded, as it did not pay attention to exclusion of leading paths + while walking the index. Other two users of excluded() are also + updated. + + * "git request-pull $url dev" when the tip of "dev" branch was tagged + with "ext4-for-linus" used the contents from the tag in the output + but still asked the "dev" branch to be pulled, not the tag. + +Also contains minor typofixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.11.3.txt b/Documentation/RelNotes/1.7.11.3.txt new file mode 100644 index 000000000..64494f89d --- /dev/null +++ b/Documentation/RelNotes/1.7.11.3.txt @@ -0,0 +1,53 @@ +Git v1.7.11.3 Release Notes +=========================== + +Fixes since v1.7.11.3 +--------------------- + + * The error message from "git push $there :bogo" (and its equivalent + "git push $there --delete bogo") mentioned that we tried and failed + to guess what ref is being deleted based on the LHS of the refspec, + which we don't. + + * A handful of files and directories we create had tighter than + necessary permission bits when the user wanted to have group + writability (e.g. by setting "umask 002"). + + * "commit --amend" used to refuse amending a commit with an empty log + message, with or without "--allow-empty-message". + + * "git commit --amend --only --" was meant to allow "Clever" people to + rewrite the commit message without making any change even when they + have already changes for the next commit added to their index, but + it never worked as advertised since it was introduced in 1.3.0 era. + + * Even though the index can record pathnames longer than 1<<12 bytes, + in some places we were not comparing them in full, potentially + replacing index entries instead of adding. + + * "git show"'s auto-walking behaviour was an unreliable and + unpredictable hack; it now behaves just like "git log" does when it + walks. + + * "git diff", "git status" and anything that internally uses the + comparison machinery was utterly broken when the difference + involved a file with "-" as its name. This was due to the way "git + diff --no-index" was incorrectly bolted on to the system, making + any comparison that involves a file "-" at the root level + incorrectly read from the standard input. + + * We did not have test to make sure "git rebase" without extra options + filters out an empty commit in the original history. + + * "git fast-export" produced an input stream for fast-import without + properly quoting pathnames when they contain SPs in them. + + * "git checkout --detach", when you are still on an unborn branch, + should be forbidden, but it wasn't. + + * Some implementations of Perl terminates "lines" with CRLF even when + the script is operating on just a sequence of bytes. Make sure to + use "$PERL_PATH", the version of Perl the user told Git to use, in + our tests to avoid unnecessary breakages in tests. + +Also contains minor typofixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.11.4.txt b/Documentation/RelNotes/1.7.11.4.txt new file mode 100644 index 000000000..3a640c2d4 --- /dev/null +++ b/Documentation/RelNotes/1.7.11.4.txt @@ -0,0 +1,31 @@ +Git v1.7.11.4 Release Notes +=========================== + +Fixes since v1.7.11.3 +--------------------- + + * "$GIT_DIR/COMMIT_EDITMSG" file that is used to hold the commit log + message user edits was not documented. + + * The advise() function did not use varargs correctly to format + its message. + + * When "git am" failed, old timers knew to check .git/rebase-apply/patch + to see what went wrong, but we never told the users about it. + + * "git commit-tree" learned a more natural "-p <parent> <tree>" order + of arguments long time ago, but recently forgot it by mistake. + + * "git diff --no-ext-diff" did not output anything for a typechange + filepair when GIT_EXTERNAL_DIFF is in effect. + + * In 1.7.9 era, we taught "git rebase" about the raw timestamp format + but we did not teach the same trick to "filter-branch", which rolled + a similar logic on its own. + + * When "git submodule add" clones a submodule repository, it can get + confused where to store the resulting submodule repository in the + superproject's .git/ directory when there is a symbolic link in the + path to the current directory. + +Also contains minor typofixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.11.5.txt b/Documentation/RelNotes/1.7.11.5.txt new file mode 100644 index 000000000..0a2ed855c --- /dev/null +++ b/Documentation/RelNotes/1.7.11.5.txt @@ -0,0 +1,36 @@ +Git v1.7.11.5 Release Notes +=========================== + +Fixes since v1.7.11.4 +--------------------- + + * The Makefile rule to create assembly output (primarily for + debugging purposes) did not create it next to the source. + + * The code to avoid mistaken attempt to add the object directory + itself as its own alternate could read beyond end of a string while + comparison. + + * On some architectures, "block-sha1" did not compile correctly + when compilers inferred alignment guarantees from our source we + did not intend to make. + + * When talking to a remote running ssh on IPv6 enabled host, whose + address is spelled as "[HOST]:PORT", we did not parse the address + correctly and failed to connect. + + * git-blame.el (in compat/) have been updated to use Elisp more + correctly. + + * "git checkout <branchname>" to come back from a detached HEAD state + incorrectly computed reachability of the detached HEAD, resulting + in unnecessary warnings. + + * "git mergetool" did not support --tool-help option to give the list + of supported backends, like "git difftool" does. + + * "git grep" stopped spawning an external "grep" long time ago, but a + duplicated test to check internal and external "grep" was left + behind. + +Also contains minor typofixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.11.6.txt b/Documentation/RelNotes/1.7.11.6.txt new file mode 100644 index 000000000..ba7d3c396 --- /dev/null +++ b/Documentation/RelNotes/1.7.11.6.txt @@ -0,0 +1,84 @@ +Git v1.7.11.6 Release Notes +=========================== + +Fixes since v1.7.11.5 +--------------------- + + * "ciabot" script (in contrib/) has been updated with extensive + documentation. + + * "git foo" errored out with "Not a directory" when the user had a + non-directory on $PATH, and worse yet it masked an alias "foo" from + running. + + * When the user exports a non-default IFS without HT, scripts that + rely on being able to parse "ls-files -s | while read a b c..." + started to fail. Protect them from such a misconfiguration. + + * When the user gives an argument that can be taken as both a + revision name and a pathname without disambiguating with "--", we + used to give a help message "Use '--' to separate". The message + has been clarified to show where that '--' goes on the command + line. + + * Documentation for the configuration file format had a confusing + example. + + * Older parts of the documentation described as if having a regular + file in .git/refs/ hierarchy were the only way to have branches and + tags, which is not true for quite some time. + + * It was generally understood that "--long-option"s to many of our + subcommands can be abbreviated to the unique prefix, but it was not + easy to find it described for new readers of the documentation set. + + * The "--topo-order", "--date-order" (and the lack of either means + the default order) options to "rev-list" and "log" family of + commands were poorly described in the documentation. + + * "git commit --amend" let the user edit the log message and then + died when the human-readable committer name was given + insufficiently by getpwent(3). + + * The exit status code from "git config" was way overspecified while + being incorrect. The implementation has been updated to give the + documented status for a case that was documented, and introduce a + new code for "all other errors". + + * The output from "git diff -B" for a file that ends with an + incomplete line did not put "\ No newline..." on a line of its own. + + * "git diff" had a confusion between taking data from a path in the + working tree and taking data from an object that happens to have + name 0{40} recorded in a tree. + + * The "--rebase" option to "git pull" can be abbreviated to "-r", + but we didn't document it. + + * When "git push" triggered the automatic gc on the receiving end, a + message from "git prune" that said it was removing cruft leaked to + the standard output, breaking the communication protocol. + + * The reflog entries left by "git rebase" and "git rebase -i" were + inconsistent (the interactive one gave an abbreviated object name). + + * "git send-email" did not unquote encoded words that appear on the + header correctly, and lost "_" from strings. + + * "git stash apply/pop" did not trigger "rerere" upon conflicts + unlike other mergy operations. + + * "git submodule <cmd> path" did not error out when the path to the + submodule was misspelt. + + * "git submodule update -f" did not update paths in the working tree + that has local changes. + (merge 01d4721 sz/submodule-force-update later to maint). + + * "gitweb" when used with PATH_INFO failed to notice directories with + SP (and other characters that need URL-style quoting) in them. + + * Fallback 'getpass' implementation made unportable use of stdio API. + + * A utility shell function test_seq has been added as a replacement + for the 'seq' utility found on some platforms. diff --git a/Documentation/RelNotes/1.7.11.7.txt b/Documentation/RelNotes/1.7.11.7.txt new file mode 100644 index 000000000..e7e79d999 --- /dev/null +++ b/Documentation/RelNotes/1.7.11.7.txt @@ -0,0 +1,46 @@ +Git v1.7.11.7 Release Notes +=========================== + +Fixes since v1.7.11.6 +--------------------- + + * The synopsis said "checkout [-B branch]" to make it clear the + branch name is a parameter to the option, but the heading for the + option description was "-B::", not "-B branch::", making the + documentation misleading. + + * Git ships with a fall-back regexp implementation for platforms with + buggy regexp library, but it was easy for people to keep using their + platform regexp. A new test has been added to check this. + + * "git apply -p0" did not parse pathnames on "diff --git" line + correctly. This caused patches that had pathnames in no other + places to be mistakenly rejected (most notably, binary patch that + does not rename nor change mode). Textual patches, renames or mode + changes have preimage and postimage pathnames in different places + in a form that can be parsed unambiguously and did not suffer from + this problem. + + * After "gitk" showed the contents of a tag, neither "Reread + references" nor "Reload" did not update what is shown as the + contents of it, when the user overwrote the tag with "git tag -f". + + * "git for-each-ref" did not currectly support more than one --sort + option. + + * "git log .." errored out saying it is both rev range and a path + when there is no disambiguating "--" is on the command line. + Update the command line parser to interpret ".." as a path in such + a case. + + * Pushing to smart HTTP server with recent Git fails without having + the username in the URL to force authentication, if the server is + configured to allow GET anonymously, while requiring authentication + for POST. + + * "git show --format='%ci'" did not give timestamp correctly for + commits created without human readable name on "committer" line. + (merge e27ddb6 jc/maint-ident-missing-human-name later to maint). + + * "git show --quiet" ought to be a synonym for "git show -s", but + wasn't. diff --git a/Documentation/RelNotes/1.7.11.txt b/Documentation/RelNotes/1.7.11.txt new file mode 100644 index 000000000..15b954ca4 --- /dev/null +++ b/Documentation/RelNotes/1.7.11.txt @@ -0,0 +1,139 @@ +Git v1.7.11 Release Notes +========================= + +Updates since v1.7.10 +--------------------- + +UI, Workflows & Features + + * A new mode for push, "simple", which is a cross between "current" + and "upstream", has been introduced. "git push" without any refspec + will push the current branch out to the same name at the remote + repository only when it is set to track the branch with the same + name over there. The plan is to make this mode the new default + value when push.default is not configured. + + * A couple of commands learned the "--column" option to produce + columnar output. + + * A third-party tool "git subtree" is distributed in contrib/ + + * A remote helper that acts as a proxy and caches ssl session for the + https:// transport is added to the contrib/ area. + + * Error messages given when @{u} is used for a branch without its + upstream configured have been clarified. + + * Even with the "-q"uiet option, "checkout" used to report setting up + tracking. Also "branch" learned the "-q"uiet option to squelch + informational message. + + * Your build platform may support hardlinks but you may prefer not to + use them, e.g. when installing to DESTDIR to make a tarball and + untarring on a filesystem that has poor support for hardlinks. + There is a Makefile option NO_INSTALL_HARDLINKS for you. + + * The smart-http backend used to always override GIT_COMMITTER_* + variables with REMOTE_USER and REMOTE_ADDR, but these variables are + now preserved when set. + + * "git am" learned the "--include" option, which is an opposite of + existing the "--exclude" option. + + * When "git am -3" needs to fall back to an application of the patch + to a synthesized preimage followed by a 3-way merge, the paths that + needed such treatment are now reported to the end user, so that the + result in them can be eyeballed with extra care. + + * The output from "diff/log --stat" used to always allocate 4 columns + to show the number of modified lines, but not anymore. + + * "git difftool" learned the "--dir-diff" option to spawn external + diff tools that can compare two directory hierarchies at a time + after populating two temporary directories, instead of running an + instance of the external tool once per a file pair. + + * The "fmt-merge-msg" command learned to list the primary contributors + involved in the side topic you are merging in a comment in the merge + commit template. + + * "git rebase" learned to optionally keep commits that do not + introduce any change in the original history. + + * "git push --recurse-submodules" learned to optionally look into the + histories of submodules bound to the superproject and push them + out. + + * A 'snapshot' request to "gitweb" honors If-Modified-Since: header, + based on the commit date. + + * "gitweb" learned to highlight the patch it outputs even more. + +Foreign Interface + + * "git svn" used to die with unwanted SIGPIPE when talking with an HTTP + server that uses keep-alive. + + * "git svn" learned to use platform specific authentication + providers, e.g. gnome-keyring, kwallet, etc. + + * "git p4" has been moved out of the contrib/ area and has seen more + work on importing labels as tags from (and exporting tags as labels + to) p4. + +Performance and Internal Implementation (please report possible regressions) + + * Bash completion script (in contrib/) have been cleaned up to make + future work on it simpler. + + * An experimental "version 4" format of the index file has been + introduced to reduce on-disk footprint and I/O overhead. + + * "git archive" learned to produce its output without reading the + blob object it writes out in memory in its entirety. + + * "git index-pack" that runs when fetching or pushing objects to + complete the packfile on the receiving end learned to use multiple + threads to do its job when available. + + * The code to compute hash values for lines used by the internal diff + engine was optimized on little-endian machines, using the same + trick the kernel folks came up with. + + * "git apply" had some memory leaks plugged. + + * Setting up a revision traversal with many starting points was + inefficient as these were placed in a date-order priority queue + one-by-one. Now they are collected in the queue unordered first, + and sorted immediately before getting used. + + * More lower-level commands learned to use the streaming API to read + from the object store without keeping everything in core. + + * The weighting parameters to suggestion command name typo have been + tweaked, so that "git tags" will suggest "tag?" and not "stage?". + + * Because "sh" on the user's PATH may be utterly broken on some + systems, run-command API now uses SHELL_PATH, not /bin/sh, when + spawning an external command (not applicable to Windows port). + + * The API to iterate over the refs/ hierarchy has been tweaked to + allow walking only a subset of it more efficiently. + +Also contains minor documentation updates and code clean-ups. + + +Fixes since v1.7.10 +------------------- + +Unless otherwise noted, all the fixes since v1.7.10 in the maintenance +releases are contained in this release (see release notes to them for +details). + + * "git submodule init" used to report "registered for path ..." + even for submodules that were registered earlier. + (cherry-pick c1c259e jl/submodule-report-new-path-once later to maint). + + * "git diff --stat" used to fully count a binary file with modified + execution bits whose contents is unmodified, which was not quite + right. diff --git a/Documentation/RelNotes/1.7.12.1.txt b/Documentation/RelNotes/1.7.12.1.txt new file mode 100644 index 000000000..b8f04af19 --- /dev/null +++ b/Documentation/RelNotes/1.7.12.1.txt @@ -0,0 +1,134 @@ +Git 1.7.12.1 Release Notes +========================== + +Fixes since v1.7.12 +------------------- + + * "git apply -p0" did not parse pathnames on "diff --git" line + correctly. This caused patches that had pathnames in no other + places to be mistakenly rejected (most notably, binary patch that + does not rename nor change mode). Textual patches, renames or mode + changes have preimage and postimage pathnames in different places + in a form that can be parsed unambiguously and did not suffer from + this problem. + + * "git cherry-pick A C B" used to replay changes in A and then B and + then C if these three commits had committer timestamps in that + order, which is not what the user who said "A C B" naturally + expects. + + * "git commit --amend" let the user edit the log message and then + died when the human-readable committer name was given + insufficiently by getpwent(3). + + * Some capabilities were asked by fetch-pack even when upload-pack + did not advertise that they are available. fetch-pack has been + fixed not to do so. + + * "git diff" had a confusion between taking data from a path in the + working tree and taking data from an object that happens to have + name 0{40} recorded in a tree. + + * "git for-each-ref" did not correctly support more than one --sort + option. + + * "git log .." errored out saying it is both rev range and a path + when there is no disambiguating "--" is on the command line. + Update the command line parser to interpret ".." as a path in such + a case. + + * The "--topo-order", "--date-order" (and the lack of either means + the default order) options to "rev-list" and "log" family of + commands were poorly described in the documentation. + + * "git prune" without "-v" used to warn about leftover temporary + files (which is an indication of an earlier aborted operation). + + * Pushing to smart HTTP server with recent Git fails without having + the username in the URL to force authentication, if the server is + configured to allow GET anonymously, while requiring authentication + for POST. + + * The reflog entries left by "git rebase" and "git rebase -i" were + inconsistent (the interactive one gave an abbreviated object name). + + * When "git push" triggered the automatic gc on the receiving end, a + message from "git prune" that said it was removing cruft leaked to + the standard output, breaking the communication protocol. + + * "git show --quiet" ought to be a synonym for "git show -s", but + wasn't. + + * "git show --format='%ci'" did not give timestamp correctly for + commits created without human readable name on "committer" line. + + * "git send-email" did not unquote encoded words that appear on the + header correctly, and lost "_" from strings. + + * The interactive prompt "git send-email" gives was error prone. It + asked "What e-mail address do you want to use?" with the address it + guessed (correctly) the user would want to use in its prompt, + tempting the user to say "y". But the response was taken as "No, + please use 'y' as the e-mail address instead", which is most + certainly not what the user meant. + + * "gitweb" when used with PATH_INFO failed to notice directories with + SP (and other characters that need URL-style quoting) in them. + + * When the user gives an argument that can be taken as both a + revision name and a pathname without disambiguating with "--", we + used to give a help message "Use '--' to separate". The message + has been clarified to show where that '--' goes on the command + line. + + * When the user exports a non-default IFS without HT, scripts that + rely on being able to parse "ls-files -s | while read a b c..." + started to fail. Protect them from such a misconfiguration. + + * The attribute system may be asked for a path that itself or its + leading directories no longer exists in the working tree, and it is + fine if we cannot open .gitattribute file in such a case. Failure + to open per-directory .gitattributes with error status other than + ENOENT and ENOTDIR should be diagnosed, but it wasn't. + + * After "gitk" showed the contents of a tag, neither "Reread + references" nor "Reload" did not update what is shown as the + contents of it, when the user overwrote the tag with "git tag -f". + + * "ciabot" script (in contrib/) has been updated with extensive + documentation. + + * "git-jump" script (in contrib/) did not work well when + diff.noprefix or diff.mnemonicprefix is in effect. + + * Older parts of the documentation described as if having a regular + file in .git/refs/ hierarchy were the only way to have branches and + tags, which is not true for quite some time. + + * A utility shell function test_seq has been added as a replacement + for the 'seq' utility found on some platforms. + + * Compatibility wrapper to learn the maximum number of file + descriptors we can open around sysconf(_SC_OPEN_MAX) and + getrlimit(RLIMIT_NO_FILE) has been introduced for portability. + + * We used curl_easy_strerror() without checking version of cURL, + breaking the build for versions before curl 7.12.0. + + * Code to work around MacOS X UTF-8 gotcha has been cleaned up. + + * Fallback 'getpass' implementation made unportable use of stdio API. + + * The "--rebase" option to "git pull" can be abbreviated to "-r", + but we didn't document it. + + * It was generally understood that "--long-option"s to many of our + subcommands can be abbreviated to the unique prefix, but it was not + easy to find it described for new readers of the documentation set. + + * The synopsis said "checkout [-B branch]" to make it clear the + branch name is a parameter to the option, but the heading for the + option description was "-B::", not "-B branch::", making the + documentation misleading. + +Also contains numerous documentation updates. diff --git a/Documentation/RelNotes/1.7.12.2.txt b/Documentation/RelNotes/1.7.12.2.txt new file mode 100644 index 000000000..69255745e --- /dev/null +++ b/Documentation/RelNotes/1.7.12.2.txt @@ -0,0 +1,40 @@ +Git 1.7.12.2 Release Notes +========================== + +Fixes since v1.7.12.1 +--------------------- + + * When "git am" is fed an input that has multiple "Content-type: ..." + header, it did not grok charset= attribute correctly. + + * Even during a conflicted merge, "git blame $path" always meant to + blame uncommitted changes to the "working tree" version; make it + more useful by showing cleanly merged parts as coming from the other + branch that is being merged. + + * "git blame MAKEFILE" run in a history that has "Makefile" but not + "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got + confused on a case insensitive filesystem and failed to do so. + + * "git fetch --all", when passed "--no-tags", did not honor the + "--no-tags" option while fetching from individual remotes (the same + issue existed with "--tags", but combination "--all --tags" makes + much less sense than "--all --no-tags"). + + * "git log/diff/format-patch --stat" showed the "N line(s) added" + comment in user's locale and caused careless submitters to send + patches with such a line in them to projects whose project language + is not their language, mildly irritating others. Localization to + the line has been disabled for now. + + * "git log --all-match --grep=A --grep=B" ought to show commits that + mention both A and B, but when these three options are used with + --author or --committer, it showed commits that mention either A or + B (or both) instead. + + * The subcommand to remove the definition of a remote in "git remote" + was named "rm" even though all other subcommands were spelled out. + Introduce "git remote remove" to remove confusion, and keep "rm" as + a backward compatible synonym. + +Also contains a handful of documentation updates. diff --git a/Documentation/RelNotes/1.7.12.3.txt b/Documentation/RelNotes/1.7.12.3.txt new file mode 100644 index 000000000..ecda427a3 --- /dev/null +++ b/Documentation/RelNotes/1.7.12.3.txt @@ -0,0 +1,34 @@ +Git 1.7.12.3 Release Notes +========================== + +Fixes since v1.7.12.2 +--------------------- + + * "git am" mishandled a patch attached as application/octet-stream + (e.g. not text/*); Content-Transfer-Encoding (e.g. base64) was not + honored correctly. + + * It was unclear in the documentation for "git blame" that it is + unnecessary for users to use the "--follow" option. + + * A repository created with "git clone --single" had its fetch + refspecs set up just like a clone without "--single", leading the + subsequent "git fetch" to slurp all the other branches, defeating + the whole point of specifying "only this branch". + + * "git fetch" over http had an old workaround for an unlikely server + misconfiguration; it turns out that this hurts debuggability of the + configuration in general, and has been reverted. + + * "git fetch" over http advertised that it supports "deflate", which + is much less common, and did not advertise the more common "gzip" on + its Accept-Encoding header. + + * "git receive-pack" (the counterpart to "git push") did not give + progress output while processing objects it received to the puser + when run over the smart-http protocol. + + * "git status" honored the ignore=dirty settings in .gitmodules but + "git commit" didn't. + +Also contains a handful of documentation updates. diff --git a/Documentation/RelNotes/1.7.12.4.txt b/Documentation/RelNotes/1.7.12.4.txt new file mode 100644 index 000000000..c6da3cc93 --- /dev/null +++ b/Documentation/RelNotes/1.7.12.4.txt @@ -0,0 +1,23 @@ +Git 1.7.12.4 Release Notes +========================== + +Fixes since v1.7.12.3 +--------------------- + + * "git fetch" over the dumb-http revision walker could segfault when + curl's multi interface was used. + + * It was possible to give specific paths for "asciidoc" and other + tools in the documentation toolchain, but not for "xmlto". + + * "gitweb" did not give the correct committer timezone in its feed + output due to a typo. + + * The "-Xours" (and similarly -Xtheirs) backend option to "git + merge -s recursive" was ignored for binary files. Now it is + honored. + + * The "binary" synthetic attribute made "diff" to treat the path as + binary, but not "merge". + +Also contains many documentation updates. diff --git a/Documentation/RelNotes/1.7.12.txt b/Documentation/RelNotes/1.7.12.txt new file mode 100644 index 000000000..010d8c7de --- /dev/null +++ b/Documentation/RelNotes/1.7.12.txt @@ -0,0 +1,136 @@ +Git v1.7.12 Release Notes +========================= + +Updates since v1.7.11 +--------------------- + +UI, Workflows & Features + + * Git can be told to normalize pathnames it read from readdir(3) and + all arguments it got from the command line into precomposed UTF-8 + (assuming that they come as decomposed UTF-8), in order to work + around issues on Mac OS. + + I think there still are other places that need conversion + (e.g. paths that are read from stdin for some commands), but this + should be a good first step in the right direction. + + * Per-user $HOME/.gitconfig file can optionally be stored in + $HOME/.config/git/config instead, which is in line with XDG. + + * The value of core.attributesfile and core.excludesfile default to + $HOME/.config/git/attributes and $HOME/.config/git/ignore respectively + when these files exist. + + * Logic to disambiguate abbreviated object names have been taught to + take advantage of object types that are expected in the context, + e.g. XXXXXX in the "git describe" output v1.2.3-gXXXXXX must be a + commit object, not a blob nor a tree. This will help us prolong + the lifetime of abbreviated object names. + + * "git apply" learned to wiggle the base version and perform three-way + merge when a patch does not exactly apply to the version you have. + + * Scripted Porcelain writers now have access to the credential API via + the "git credential" plumbing command. + + * "git help" used to always default to "man" format even on platforms + where "man" viewer is not widely available. + + * "git clone --local $path" started its life as an experiment to + optionally use link/copy when cloning a repository on the disk, but + we didn't deprecate it after we made the option a no-op to always + use the optimization. The command learned "--no-local" option to + turn this off, as a more explicit alternative over use of file:// + URL. + + * "git fetch" and friends used to say "remote side hung up + unexpectedly" when they failed to get response they expect from the + other side, but one common reason why they don't get expected + response is that the remote repository does not exist or cannot be + read. The error message in this case was updated to give better + hints to the user. + + * "git help -w $cmd" can show HTML version of documentation for + "git-$cmd" by setting help.htmlpath to somewhere other than the + default location where the build procedure installs them locally; + the variable can even point at a http:// URL. + + * "git rebase [-i] --root $tip" can now be used to rewrite all the + history leading to "$tip" down to the root commit. + + * "git rebase -i" learned "-x <cmd>" to insert "exec <cmd>" after + each commit in the resulting history. + + * "git status" gives finer classification to various states of paths + in conflicted state and offer advice messages in its output. + + * "git submodule" learned to deal with nested submodule structure + where a module is contained within a module whose origin is + specified as a relative URL to its superproject's origin. + + * A rather heavy-ish "git completion" script has been split to create + a separate "git prompting" script, to help lazy-autoloading of the + completion part while making prompting part always available. + + * "gitweb" pays attention to various forms of credits that are + similar to "Signed-off-by:" lines in the commit objects and + highlights them accordingly. + + +Foreign Interface + + * "mediawiki" remote helper (in contrib/) learned to handle file + attachments. + + * "git p4" now uses "Jobs:" and "p4 move" when appropriate. + + * vcs-svn has been updated to clean-up compilation, lift 32-bit + limitations, etc. + + +Performance, Internal Implementation, etc. (please report possible regressions) + + * Some tests showed false failures caused by a bug in ecryptofs. + + * We no longer use AsciiDoc7 syntax in our documentation and favor a + more modern style. + + * "git am --rebasing" codepath was taught to grab authorship, log + message and the patch text directly out of existing commits. This + will help rebasing commits that have confusing "diff" output in + their log messages. + + * "git index-pack" and "git pack-objects" use streaming API to read + from the object store to avoid having to hold a large blob object + in-core while they are doing their thing. + + * Code to match paths with exclude patterns learned to avoid calling + fnmatch() by comparing fixed leading substring literally when + possible. + + * "git log -n 1 -- rarely-touched-path" was spending unnecessary + cycles after showing the first change to find the next one, only to + discard it. + + * "git svn" got a large-looking code reorganization at the last + minute before the code freeze. + + +Also contains minor documentation updates and code clean-ups. + + +Fixes since v1.7.11 +------------------- + +Unless otherwise noted, all the fixes since v1.7.11 in the maintenance +releases are contained in this release (see release notes to them for +details). + + * "git submodule add" was confused when the superproject did not have + its repository in its usual place in the working tree and GIT_DIR + and GIT_WORK_TREE was used to access it. + + * "git commit --amend" let the user edit the log message and then died + when the human-readable committer name was given insufficiently by + getpwent(3). diff --git a/Documentation/RelNotes/1.7.5.4.txt b/Documentation/RelNotes/1.7.5.4.txt index cf3f455ce..7796df3fe 100644 --- a/Documentation/RelNotes/1.7.5.4.txt +++ b/Documentation/RelNotes/1.7.5.4.txt @@ -5,7 +5,7 @@ Fixes since v1.7.5.3 -------------------- * The single-key mode of "git add -p" was easily fooled into thinking - that it was told to add everthing ('a') when up-arrow was pressed by + that it was told to add everything ('a') when up-arrow was pressed by mistake. * Setting a git command that uses custom configuration via "-c var=val" diff --git a/Documentation/RelNotes/1.7.7.1.txt b/Documentation/RelNotes/1.7.7.1.txt new file mode 100644 index 000000000..ac9b838e2 --- /dev/null +++ b/Documentation/RelNotes/1.7.7.1.txt @@ -0,0 +1,60 @@ +Git v1.7.7.1 Release Notes +========================== + +Fixes since v1.7.7 +------------------ + + * On some BSD systems, adding +s bit on directories is detrimental + (it is not necessary on BSD to begin with). "git init --shared" + has been updated to take this into account without extra makefile + settings on platforms the Makefile knows about. + + * After incorrectly written third-party tools store a tag object in + HEAD, git diagnosed it as a repository corruption and refused to + proceed in order to avoid spreading the damage. We now gracefully + recover from such a situation by pretending as if the commit that + is pointed at by the tag were in HEAD. + + * "git apply --whitespace=error" did not bother to report the exact + line number in the patch that introduced new blank lines at the end + of the file. + + * "git apply --index" did not check corrupted patch. + + * "git checkout $tree $directory/" resurrected paths locally removed or + modified only in the working tree in $directory/ that did not appear + in $directory of the given $tree. They should have been kept intact. + + * "git diff $tree $path" used to apply the pathspec at the output stage, + reading the whole tree, wasting resources. + + * The code to check for updated submodules during a "git fetch" of the + superproject had an unnecessary quadratic loop. + + * "git fetch" from a large bundle did not enable the progress output. + + * When "git fsck --lost-and-found" found that an empty blob object in the + object store is unreachable, it incorrectly reported an error after + writing the lost blob out successfully. + + * "git filter-branch" did not refresh the index before checking that the + working tree was clean. + + * "git grep $tree" when run with multiple threads had an unsafe access to + the object database that should have been protected with mutex. + + * The "--ancestry-path" option to "git log" and friends misbehaved in a + history with complex criss-cross merges and showed an uninteresting + side history as well. + + * Test t1304 assumed LOGNAME is always set, which may not be true on + some systems. + + * Tests with --valgrind failed to find "mergetool" scriptlets. + + * "git patch-id" miscomputed the patch-id in a patch that has a line longer + than 1kB. + + * When an "exec" insn failed after modifying the index and/or the working + tree during "rebase -i", we now check and warn that the changes need to + be cleaned up. diff --git a/Documentation/RelNotes/1.7.7.2.txt b/Documentation/RelNotes/1.7.7.2.txt new file mode 100644 index 000000000..e6bbef2f0 --- /dev/null +++ b/Documentation/RelNotes/1.7.7.2.txt @@ -0,0 +1,44 @@ +Git v1.7.7.2 Release Notes +========================== + +Fixes since v1.7.7.1 +-------------------- + + * We used to drop error messages from libcurl on certain kinds of + errors. + + * Error report from smart HTTP transport, when the connection was + broken in the middle of a transfer, showed a useless message on + a corrupt packet. + + * "git fetch --prune" was unsafe when used with refspecs from the + command line. + + * The attribute mechanism did not use case insensitive match when + core.ignorecase was set. + + * "git bisect" did not notice when it failed to update the working tree + to the next commit to be tested. + + * "git config --bool --get-regexp" failed to separate the variable name + and its value "true" when the variable is defined without "= true". + + * "git remote rename $a $b" were not careful to match the remote name + against $a (i.e. source side of the remote nickname). + + * "git mergetool" did not use its arguments as pathspec, but as a path to + the file that may not even have any conflict. + + * "git diff --[num]stat" used to use the number of lines of context + different from the default, potentially giving different results from + "git diff | diffstat" and confusing the users. + + * "git pull" and "git rebase" did not work well even when GIT_WORK_TREE is + set correctly with GIT_DIR if the current directory is outside the working + tree. + + * "git send-email" did not honor the configured hostname when restarting + the HELO/EHLO exchange after switching TLS on. + + * "gitweb" used to produce a non-working link while showing the contents + of a blob, when JavaScript actions are enabled. diff --git a/Documentation/RelNotes/1.7.7.3.txt b/Documentation/RelNotes/1.7.7.3.txt new file mode 100644 index 000000000..09301f095 --- /dev/null +++ b/Documentation/RelNotes/1.7.7.3.txt @@ -0,0 +1,19 @@ +Git v1.7.7.3 Release Notes +========================== + +Fixes since v1.7.7.2 +-------------------- + + * Adjust the "quick-install-doc" procedures as preformatted + html/manpage are no longer in the source repository. + + * The logic to optimize the locality of the data in a pack introduced in + 1.7.7 was grossly inefficient. + + * The logic to filter out forked projects in the project list in + "gitweb" was broken for some time. + + * "git branch -m/-M" advertised to update RENAME_REF ref in the + commit log message that introduced the feature but not anywhere in + the documentation, and never did update such a ref anyway. This + undocumented misfeature that did not exist has been excised. diff --git a/Documentation/RelNotes/1.7.7.4.txt b/Documentation/RelNotes/1.7.7.4.txt new file mode 100644 index 000000000..e5234485e --- /dev/null +++ b/Documentation/RelNotes/1.7.7.4.txt @@ -0,0 +1,14 @@ +Git v1.7.7.4 Release Notes +========================== + +Fixes since v1.7.7.3 +-------------------- + + * A few header dependencies were missing from the Makefile. + + * Some newer parts of the code used C99 __VA_ARGS__ while we still + try to cater to older compilers. + + * "git name-rev --all" tried to name all _objects_, naturally failing to + describe many blobs and trees, instead of showing only commits as + advertised in its documentation. diff --git a/Documentation/RelNotes/1.7.7.5.txt b/Documentation/RelNotes/1.7.7.5.txt new file mode 100644 index 000000000..7b0931987 --- /dev/null +++ b/Documentation/RelNotes/1.7.7.5.txt @@ -0,0 +1,14 @@ +Git v1.7.7.5 Release Notes +========================== + +Fixes since v1.7.7.4 +-------------------- + + * After fetching from a remote that has very long refname, the reporting + output could have corrupted by overrunning a static buffer. + + * "git checkout" and "git merge" treated in-tree .gitignore and exclude + file in $GIT_DIR/info/ directory inconsistently when deciding which + untracked files are ignored and expendable. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.7.6.txt b/Documentation/RelNotes/1.7.7.6.txt new file mode 100644 index 000000000..8df606d45 --- /dev/null +++ b/Documentation/RelNotes/1.7.7.6.txt @@ -0,0 +1,20 @@ +Git v1.7.7.6 Release Notes +========================== + +Fixes since v1.7.7.5 +-------------------- + + * The code to look up attributes for paths reused entries from a wrong + directory when two paths in question are in adjacent directories and + the name of the one directory is a prefix of the other. + + * A wildcard that matches deeper hierarchy given to the "diff-index" command, + e.g. "git diff-index HEAD -- '*.txt'", incorrectly reported additions of + matching files even when there is no change. + + * When producing a "thin pack" (primarily used in bundles and smart + HTTP transfers) out of a fully packed repository, we unnecessarily + avoided sending recent objects as a delta against objects we know + the other side has. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.7.7.txt b/Documentation/RelNotes/1.7.7.7.txt new file mode 100644 index 000000000..e79118d06 --- /dev/null +++ b/Documentation/RelNotes/1.7.7.7.txt @@ -0,0 +1,13 @@ +Git v1.7.7.7 Release Notes +========================== + +Fixes since v1.7.7.6 +-------------------- + + * An error message from 'git bundle' had an unmatched single quote pair in it. + + * 'git diff --histogram' option was not described. + + * 'git imap-send' carried an unused dead code. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.7.txt b/Documentation/RelNotes/1.7.7.txt new file mode 100644 index 000000000..7655cccfa --- /dev/null +++ b/Documentation/RelNotes/1.7.7.txt @@ -0,0 +1,134 @@ +Git v1.7.7 Release Notes +======================== + +Updates since v1.7.6 +-------------------- + + * The scripting part of the codebase is getting prepared for i18n/l10n. + + * Interix, Cygwin and Minix ports got updated. + + * Various updates to git-p4 (in contrib/), fast-import, and git-svn. + + * Gitweb learned to read from /etc/gitweb-common.conf when it exists, + before reading from gitweb_config.perl or from /etc/gitweb.conf + (this last one is read only when per-repository gitweb_config.perl + does not exist). + + * Various codepaths that invoked zlib deflate/inflate assumed that these + functions can compress or uncompress more than 4GB data in one call on + platforms with 64-bit long, which has been corrected. + + * Git now recognizes loose objects written by other implementations that + use a non-standard window size for zlib deflation (e.g. Agit running on + Android with 4kb window). We used to reject anything that was not + deflated with 32kb window. + + * Interaction between the use of pager and coloring of the output has + been improved, especially when a command that is not built-in was + involved. + + * "git am" learned to pass the "--exclude=<path>" option through to underlying + "git apply". + + * You can now feed many empty lines before feeding an mbox file to + "git am". + + * "git archive" can be told to pass the output to gzip compression and + produce "archive.tar.gz". + + * "git bisect" can be used in a bare repository (provided that the test + you perform per each iteration does not need a working tree, of + course). + + * The length of abbreviated object names in "git branch -v" output + now honors the core.abbrev configuration variable. + + * "git check-attr" can take relative paths from the command line. + + * "git check-attr" learned an "--all" option to list the attributes for a + given path. + + * "git checkout" (both the code to update the files upon checking out a + different branch and the code to checkout a specific set of files) learned + to stream the data from object store when possible, without having to + read the entire contents of a file into memory first. An earlier round + of this code that is not in any released version had a large leak but + now it has been plugged. + + * "git clone" can now take a "--config key=value" option to set the + repository configuration options that affect the initial checkout. + + * "git commit <paths>..." now lets you feed relative pathspecs that + refer to outside your current subdirectory. + + * "git diff --stat" learned a --stat-count option to limit the output of + a diffstat report. + + * "git diff" learned a "--histogram" option to use a different diff + generation machinery stolen from jgit, which might give better + performance. + + * "git diff" had a weird worst case behaviour that can be triggered + when comparing files with potentially many places that could match. + + * "git fetch", "git push" and friends no longer show connection + errors for addresses that couldn't be connected to when at least one + address succeeds (this is arguably a regression but a deliberate + one). + + * "git grep" learned "--break" and "--heading" options, to let users mimic + the output format of "ack". + + * "git grep" learned a "-W" option that shows wider context using the same + logic used by "git diff" to determine the hunk header. + + * Invoking the low-level "git http-fetch" without "-a" option (which + git itself never did---normal users should not have to worry about + this) is now deprecated. + + * The "--decorate" option to "git log" and its family learned to + highlight grafted and replaced commits. + + * "git rebase master topci" no longer spews usage hints after giving + the "fatal: no such branch: topci" error message. + + * The recursive merge strategy implementation got a fairly large + fix for many corner cases that may rarely happen in real world + projects (it has been verified that none of the 16000+ merges in + the Linux kernel history back to v2.6.12 is affected with the + corner case bugs this update fixes). + + * "git stash" learned an "--include-untracked option". + + * "git submodule update" used to stop at the first error updating a + submodule; it now goes on to update other submodules that can be + updated, and reports the ones with errors at the end. + + * "git push" can be told with the "--recurse-submodules=check" option to + refuse pushing of the supermodule, if any of its submodules' + commits hasn't been pushed out to their remotes. + + * "git upload-pack" and "git receive-pack" learned to pretend that only a + subset of the refs exist in a repository. This may help a site to + put many tiny repositories into one repository (this would not be + useful for larger repositories as repacking would be problematic). + + * "git verify-pack" has been rewritten to use the "index-pack" machinery + that is more efficient in reading objects in packfiles. + + * test scripts for gitweb tried to run even when CGI-related perl modules + are not installed; they now exit early when the latter are unavailable. + +Also contains various documentation updates and minor miscellaneous +changes. + + +Fixes since v1.7.6 +------------------ + +Unless otherwise noted, all fixes in the 1.7.6.X maintenance track are +included in this release. + + * "git branch -m" and "git checkout -b" incorrectly allowed the tip + of the branch that is currently checked out updated. diff --git a/Documentation/RelNotes/1.7.8.1.txt b/Documentation/RelNotes/1.7.8.1.txt new file mode 100644 index 000000000..33dc948b9 --- /dev/null +++ b/Documentation/RelNotes/1.7.8.1.txt @@ -0,0 +1,38 @@ +Git v1.7.8.1 Release Notes +========================== + +Fixes since v1.7.8 +------------------ + + * In some codepaths (notably, checkout and merge), the ignore patterns + recorded in $GIT_DIR/info/exclude were not honored. They now are. + + * "git apply --check" did not error out when given an empty input + without any patch. + + * "git archive" mistakenly allowed remote clients to ask for commits + that are not at the tip of any ref. + + * "git checkout" and "git merge" treated in-tree .gitignore and exclude + file in $GIT_DIR/info/ directory inconsistently when deciding which + untracked files are ignored and expendable. + + * LF-to-CRLF streaming filter used when checking out a large-ish blob + fell into an infinite loop with a rare input. + + * The function header pattern for files with "diff=cpp" attribute did + not consider "type *funcname(type param1,..." as the beginning of a + function. + + * The error message from "git diff" and "git status" when they fail + to inspect changes in submodules did not report which submodule they + had trouble with. + + * After fetching from a remote that has very long refname, the reporting + output could have corrupted by overrunning a static buffer. + + * "git pack-objects" avoids creating cyclic dependencies among deltas + when seeing a broken packfile that records the same object in both + the deflated form and as a delta. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.8.2.txt b/Documentation/RelNotes/1.7.8.2.txt new file mode 100644 index 000000000..b9c66aa1b --- /dev/null +++ b/Documentation/RelNotes/1.7.8.2.txt @@ -0,0 +1,71 @@ +Git v1.7.8.2 Release Notes +========================== + +Fixes since v1.7.8.1 +-------------------- + + * Porcelain commands like "git reset" did not distinguish deletions + and type-changes from ordinary modification, and reported them with + the same 'M' moniker. They now use 'D' (for deletion) and 'T' (for + type-change) to match "git status -s" and "git diff --name-status". + + * The configuration file parser used for sizes (e.g. bigFileThreshold) + did not correctly interpret 'g' suffix. + + * The replacement implementation for snprintf used on platforms with + native snprintf that is broken did not use va_copy correctly. + + * LF-to-CRLF streaming filter replaced all LF with CRLF, which might + be technically correct but not friendly to people who are trying + to recover from earlier mistakes of using CRLF in the repository + data in the first place. It now refrains from doing so for LF that + follows a CR. + + * git native connection going over TCP (not over SSH) did not set + SO_KEEPALIVE option which failed to receive link layer errors. + + * "git branch -m <current branch> HEAD" is an obvious no-op but was not + allowed. + + * "git checkout -m" did not recreate the conflicted state in a "both + sides added, without any common ancestor version" conflict + situation. + + * "git cherry-pick $commit" (not a range) created an unnecessary + sequencer state and interfered with valid workflow to use the + command during a session to cherry-pick multiple commits. + + * You could make "git commit" segfault by giving the "--no-message" + option. + + * "fast-import" did not correctly update an existing notes tree, + possibly corrupting the fan-out. + + * "git fetch-pack" accepted unqualified refs that do not begin with + refs/ by mistake and compensated it by matching the refspec with + tail-match, which was doubly wrong. This broke fetching from a + repository with a funny named ref "refs/foo/refs/heads/master" and a + 'master' branch with "git fetch-pack refs/heads/master", as the + command incorrectly considered the former a "match". + + * "git log --follow" did not honor the rename threshold score given + with the -M option (e.g. "-M50%"). + + * "git mv" gave suboptimal error/warning messages when it overwrites + target files. It also did not pay attention to "-v" option. + + * Authenticated "git push" over dumb HTTP were broken with a recent + change and failed without asking for password when username is + given. + + * "git push" to an empty repository over HTTP were broken with a + recent change to the ref handling. + + * "git push -v" forgot how to be verbose by mistake. It now properly + becomes verbose when asked to. + + * When a "reword" action in "git rebase -i" failed to run "commit --amend", + we did not give the control back to the user to resolve the situation, and + instead kept the original commit log message. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.8.3.txt b/Documentation/RelNotes/1.7.8.3.txt new file mode 100644 index 000000000..a92714c14 --- /dev/null +++ b/Documentation/RelNotes/1.7.8.3.txt @@ -0,0 +1,16 @@ +Git v1.7.8.3 Release Notes +========================== + +Fixes since v1.7.8.2 +-------------------- + + * Attempt to fetch from an empty file pretending it to be a bundle did + not error out correctly. + + * gitweb did not correctly fall back to configured $fallback_encoding + that is not 'latin1'. + + * "git clone --depth $n" did not catch a non-number given as $n as an + error. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.8.4.txt b/Documentation/RelNotes/1.7.8.4.txt new file mode 100644 index 000000000..9bebdbf13 --- /dev/null +++ b/Documentation/RelNotes/1.7.8.4.txt @@ -0,0 +1,23 @@ +Git v1.7.8.4 Release Notes +========================== + +Fixes since v1.7.8.3 +-------------------- + + * The code to look up attributes for paths reused entries from a wrong + directory when two paths in question are in adjacent directories and + the name of the one directory is a prefix of the other. + + * A wildcard that matches deeper hierarchy given to the "diff-index" command, + e.g. "git diff-index HEAD -- '*.txt'", incorrectly reported additions of + matching files even when there is no change. + + * When producing a "thin pack" (primarily used in bundles and smart + HTTP transfers) out of a fully packed repository, we unnecessarily + avoided sending recent objects as a delta against objects we know + the other side has. + + * "git send-email" did not properly treat sendemail.multiedit as a + boolean (e.g. setting it to "false" did not turn it off). + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.8.5.txt b/Documentation/RelNotes/1.7.8.5.txt new file mode 100644 index 000000000..011fd2a42 --- /dev/null +++ b/Documentation/RelNotes/1.7.8.5.txt @@ -0,0 +1,19 @@ +Git v1.7.8.5 Release Notes +========================== + +Fixes since v1.7.8.4 +-------------------- + + * Dependency on our thread-utils.h header file was missing for + objects that depend on it in the Makefile. + + * "git am" when fed an empty file did not correctly finish reading it + when it attempts to guess the input format. + + * "git grep -P" (when PCRE is enabled in the build) did not match the + beginning and the end of the line correctly with ^ and $. + + * "git rebase -m" tried to run "git notes copy" needlessly when + nothing was rewritten. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.8.6.txt b/Documentation/RelNotes/1.7.8.6.txt new file mode 100644 index 000000000..d9bf2b741 --- /dev/null +++ b/Documentation/RelNotes/1.7.8.6.txt @@ -0,0 +1,22 @@ +Git v1.7.8.6 Release Notes +========================== + +Fixes since v1.7.8.5 +-------------------- + + * An error message from 'git bundle' had an unmatched single quote pair in it. + + * 'git diff --histogram' option was not described. + + * Documentation for 'git rev-list' had minor formatting errors. + + * 'git imap-send' carried an unused dead code. + + * The way 'git fetch' implemented its connectivity check over + received objects was overly pessimistic, and wasted a lot of + cycles. + + * Various minor backports of fixes from the 'master' and the 'maint' + branch. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.8.txt b/Documentation/RelNotes/1.7.8.txt new file mode 100644 index 000000000..249311361 --- /dev/null +++ b/Documentation/RelNotes/1.7.8.txt @@ -0,0 +1,161 @@ +Git v1.7.8 Release Notes +======================== + +Updates since v1.7.7 +-------------------- + + * Some git-svn, git-gui, git-p4 (in contrib) and msysgit updates. + + * Updates to bash completion scripts. + + * The build procedure has been taught to take advantage of computed + dependency automatically when the compiler supports it. + + * The date parser now accepts timezone designators that lack minutes + part and also has a colon between "hh:mm". + + * The contents of the /etc/mailname file, if exists, is used as the + default value of the hostname part of the committer/author e-mail. + + * "git am" learned how to read from patches generated by Hg. + + * "git archive" talking with a remote repository can report errors + from the remote side in a more informative way. + + * "git branch" learned an explicit --list option to ask for branches + listed, optionally with a glob matching pattern to limit its output. + + * "git check-attr" learned "--cached" option to look at .gitattributes + files from the index, not from the working tree. + + * Variants of "git cherry-pick" and "git revert" that take multiple + commits learned to "--continue" and "--abort". + + * "git daemon" gives more human readable error messages to clients + using ERR packets when appropriate. + + * Errors at the network layer is logged by "git daemon". + + * "git diff" learned "--minimal" option to spend extra cycles to come + up with a minimal patch output. + + * "git diff" learned "--function-context" option to show the whole + function as context that was affected by a change. + + * "git difftool" can be told to skip launching the tool for a path by + answering 'n' to its prompt. + + * "git fetch" learned to honor transfer.fsckobjects configuration to + validate the objects that were received from the other end, just like + "git receive-pack" (the receiving end of "git push") does. + + * "git fetch" makes sure that the set of objects it received from the + other end actually completes the history before updating the refs. + "git receive-pack" (the receiving end of "git push") learned to do the + same. + + * "git fetch" learned that fetching/cloning from a regular file on the + filesystem is not necessarily a request to unpack a bundle file; the + file could be ".git" with "gitdir: <path>" in it. + + * "git for-each-ref" learned "%(contents:subject)", "%(contents:body)" + and "%(contents:signature)". The last one is useful for signed tags. + + * "git grep" used to incorrectly pay attention to .gitignore files + scattered in the directory it was working in even when "--no-index" + option was used. It no longer does this. The "--exclude-standard" + option needs to be given to explicitly activate the ignore + mechanism. + + * "git grep" learned "--untracked" option, where given patterns are + searched in untracked (but not ignored) files as well as tracked + files in the working tree, so that matches in new but not yet + added files do not get missed. + + * The recursive merge backend no longer looks for meaningless + existing merges in submodules unless in the outermost merge. + + * "git log" and friends learned "--children" option. + + * "git ls-remote" learned to respond to "-h"(elp) requests. + + * "mediawiki" remote helper can interact with (surprise!) MediaWiki + with "git fetch" & "git push". + + * "git merge" learned the "--edit" option to allow users to edit the + merge commit log message. + + * "git rebase -i" can be told to use special purpose editor suitable + only for its insn sheet via sequence.editor configuration variable. + + * "git send-email" learned to respond to "-h"(elp) requests. + + * "git send-email" allows the value given to sendemail.aliasfile to begin + with "~/" to refer to the $HOME directory. + + * "git send-email" forces use of Authen::SASL::Perl to work around + issues between Authen::SASL::Cyrus and AUTH PLAIN/LOGIN. + + * "git stash" learned "--include-untracked" option to stash away + untracked/ignored cruft from the working tree. + + * "git submodule clone" does not leak an error message to the UI + level unnecessarily anymore. + + * "git submodule update" learned to honor "none" as the value for + submodule.<name>.update to specify that the named submodule should + not be checked out by default. + + * When populating a new submodule directory with "git submodule init", + the $GIT_DIR metainformation directory for submodules is created inside + $GIT_DIR/modules/<name>/ directory of the superproject and referenced + via the gitfile mechanism. This is to make it possible to switch + between commits in the superproject that has and does not have the + submodule in the tree without re-cloning. + + * "gitweb" leaked unescaped control characters from syntax hiliter + outputs. + + * "gitweb" can be told to give custom string at the end of the HTML + HEAD element. + + * "gitweb" now has its own manual pages. + + +Also contains other documentation updates and minor code cleanups. + + +Fixes since v1.7.7 +------------------ + +Unless otherwise noted, all fixes in the 1.7.7.X maintenance track are +included in this release. + + * HTTP transport did not use pushurl correctly, and also did not tell + what host it is trying to authenticate with when asking for + credentials. + (merge deba493 jk/http-auth later to maint). + + * "git blame" was aborted if started from an uncommitted content and + the path had the textconv filter in effect. + (merge 8518088 ss/blame-textconv-fake-working-tree later to maint). + + * Adding many refs to the local repository in one go (e.g. "git fetch" + that fetches many tags) and looking up a ref by name in a repository + with too many refs were unnecessarily slow. + (merge 17d68a54d jp/get-ref-dir-unsorted later to maint). + + * Report from "git commit" on untracked files was confused under + core.ignorecase option. + (merge 395c7356 jk/name-hash-dirent later to maint). + + * "git merge" did not understand ":/<pattern>" as a way to name a commit. + + " "git push" on the receiving end used to call post-receive and post-update + hooks for attempted removal of non-existing refs. + (merge 160b81ed ph/push-to-delete-nothing later to maint). + + * Help text for "git remote set-url" and "git remote set-branches" + were misspelled. + (merge c49904e fc/remote-seturl-usage-fix later to maint). + (merge 656cdf0 jc/remote-setbranches-usage-fix later to maint). diff --git a/Documentation/RelNotes/1.7.9.1.txt b/Documentation/RelNotes/1.7.9.1.txt new file mode 100644 index 000000000..6957183db --- /dev/null +++ b/Documentation/RelNotes/1.7.9.1.txt @@ -0,0 +1,63 @@ +Git v1.7.9.1 Release Notes +========================== + +Fixes since v1.7.9 +------------------ + + * The makefile allowed environment variable X seep into it result in + command names suffixed with unnecessary strings. + + * The set of included header files in compat/inet-{ntop,pton} + wrappers was updated for Windows some time ago, but in a way that + broke Solaris build. + + * rpmbuild noticed an unpackaged but installed *.mo file and failed. + + * Subprocesses spawned from various git programs were often left running + to completion even when the top-level process was killed. + + * "git add -e" learned not to show a diff for an otherwise unmodified + submodule that only has uncommitted local changes in the patch + prepared by for the user to edit. + + * Typo in "git branch --edit-description my-tpoic" was not diagnosed. + + * Using "git grep -l/-L" together with options -W or --break may not + make much sense as the output is to only count the number of hits + and there is no place for file breaks, but the latter options made + "-l/-L" to miscount the hits. + + * "git log --first-parent $pathspec" did not stay on the first parent + chain and veered into side branch from which the whole change to the + specified paths came. + + * "git merge --no-edit $tag" failed to honor the --no-edit option. + + * "git merge --ff-only $tag" failed because it cannot record the + required mergetag without creating a merge, but this is so common + operation for branch that is used _only_ to follow the upstream, so + it was changed to allow fast-forwarding without recording the mergetag. + + * "git mergetool" now gives an empty file as the common base version + to the backend when dealing with the "both sides added, differently" + case. + + * "git push -q" was not sufficiently quiet. + + * When "git push" fails to update any refs, the client side did not + report an error correctly to the end user. + + * "rebase" and "commit --amend" failed to work on commits with ancient + timestamps near year 1970. + + * When asking for a tag to be pulled, "request-pull" did not show the + name of the tag prefixed with "tags/", which would have helped older + clients. + + * "git submodule add $path" forgot to recompute the name to be stored + in .gitmodules when the submodule at $path was once added to the + superproject and already initialized. + + * Many small corner case bugs on "git tag -n" was corrected. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.9.2.txt b/Documentation/RelNotes/1.7.9.2.txt new file mode 100644 index 000000000..e500da75d --- /dev/null +++ b/Documentation/RelNotes/1.7.9.2.txt @@ -0,0 +1,69 @@ +Git v1.7.9.2 Release Notes +========================== + +Fixes since v1.7.9.1 +-------------------- + + * Bash completion script (in contrib/) did not like a pattern that + begins with a dash to be passed to __git_ps1 helper function. + + * Adaptation of the bash completion script (in contrib/) for zsh + incorrectly listed all subcommands when "git <TAB><TAB>" was given + to ask for list of porcelain subcommands. + + * The build procedure for profile-directed optimized binary was not + working very well. + + * Some systems need to explicitly link -lcharset to get locale_charset(). + + * t5541 ignored user-supplied port number used for HTTP server testing. + + * The error message emitted when we see an empty loose object was + not phrased correctly. + + * The code to ask for password did not fall back to the terminal + input when GIT_ASKPASS is set but does not work (e.g. lack of X + with GUI askpass helper). + + * We failed to give the true terminal width to any subcommand when + they are invoked with the pager, i.e. "git -p cmd". + + * map_user() was not rewriting its output correctly, which resulted + in the user visible symptom that "git blame -e" sometimes showed + excess '>' at the end of email addresses. + + * "git checkout -b" did not allow switching out of an unborn branch. + + * When you have both .../foo and .../foo.git, "git clone .../foo" did not + favor the former but the latter. + + * "git commit" refused to create a commit when entries added with + "add -N" remained in the index, without telling Git what their content + in the next commit should be. We should have created the commit without + these paths. + + * "git diff --stat" said "files", "insertions", and "deletions" even + when it is showing one "file", one "insertion" or one "deletion". + + * The output from "git diff --stat" for two paths that have the same + amount of changes showed graph bars of different length due to the + way we handled rounding errors. + + * "git grep" did not pay attention to -diff (hence -binary) attribute. + + * The transport programs (fetch, push, clone)ignored --no-progress + and showed progress when sending their output to a terminal. + + * Sometimes error status detected by a check in an earlier phase of + "git receive-pack" (the other end of "git push") was lost by later + checks, resulting in false indication of success. + + * "git rev-list --verify" sometimes skipped verification depending on + the phase of the moon, which dates back to 1.7.8.x series. + + * Search box in "gitweb" did not accept non-ASCII characters correctly. + + * Search interface of "gitweb" did not show multiple matches in the same file + correctly. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.9.3.txt b/Documentation/RelNotes/1.7.9.3.txt new file mode 100644 index 000000000..91c65012f --- /dev/null +++ b/Documentation/RelNotes/1.7.9.3.txt @@ -0,0 +1,51 @@ +Git v1.7.9.3 Release Notes +========================== + +Fixes since v1.7.9.2 +-------------------- + + * "git p4" (in contrib/) submit the changes to a wrong place when the + "--use-client-spec" option is set. + + * The config.mak.autogen generated by optional autoconf support tried + to link the binary with -lintl even when libintl.h is missing from + the system. + + * When the filter driver exits before reading the content before the + main git process writes the contents to be filtered to the pipe to + it, the latter could be killed with SIGPIPE instead of ignoring + such an event as an error. + + * "git add --refresh <pathspec>" used to warn about unmerged paths + outside the given pathspec. + + * The bulk check-in codepath in "git add" streamed contents that + needs smudge/clean filters without running them, instead of punting + and delegating to the codepath to run filters after slurping + everything to core. + + * "git branch --with $that" assumed incorrectly that the user will never + ask the question with nonsense value in $that. + + * "git bundle create" produced a corrupt bundle file upon seeing + commits with excessively long subject line. + + * When a remote helper exits before reading the blank line from the + main git process to signal the end of commands, the latter could be + killed with SIGPIPE. Instead we should ignore such event as a + non-error. + + * The commit log template given with "git merge --edit" did not have + a short instructive text like what "git commit" gives. + + * "git rev-list --verify-objects -q" omitted the extra verification + it needs to do over "git rev-list --objects -q" by mistake. + + * "gitweb" used to drop warnings in the log file when "heads" view is + accessed in a repository whose HEAD does not point at a valid + branch. + + * An invalid regular expression pattern given by an end user made + "gitweb" to return garbled response. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.9.4.txt b/Documentation/RelNotes/1.7.9.4.txt new file mode 100644 index 000000000..e5217a188 --- /dev/null +++ b/Documentation/RelNotes/1.7.9.4.txt @@ -0,0 +1,24 @@ +Git v1.7.9.4 Release Notes +========================== + +Fixes since v1.7.9.3 +-------------------- + + * The code to synthesize the fake ancestor tree used by 3-way merge + fallback in "git am" was not prepared to read a patch created with + a non-standard -p<num> value. + + * "git bundle" did not record boundary commits correctly when there + are many of them. + + * "git diff-index" and its friends at the plumbing level showed the + "diff --git" header and nothing else for a path whose cached stat + info is dirty without actual difference when asked to produce a + patch. This was a longstanding bug that we could have fixed long + time ago. + + * "gitweb" did use quotemeta() to prepare search string when asked to + do a fixed-string project search, but did not use it by mistake and + used the user-supplied string instead. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.9.5.txt b/Documentation/RelNotes/1.7.9.5.txt new file mode 100644 index 000000000..95cc2bbf2 --- /dev/null +++ b/Documentation/RelNotes/1.7.9.5.txt @@ -0,0 +1,23 @@ +Git v1.7.9.5 Release Notes +========================== + +Fixes since v1.7.9.4 +-------------------- + + * When "git config" diagnoses an error in a configuration file and + shows the line number for the offending line, it miscounted if the + error was at the end of line. + + * "git fast-import" accepted "ls" command with an empty path by + mistake. + + * Various new-ish output decoration modes of "git grep" were not + documented in the manual's synopsis section. + + * The "remaining" subcommand to "git rerere" was not documented. + + * "gitweb" used to drop warnings in the log file when "heads" view is + accessed in a repository whose HEAD does not point at a valid + branch. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.9.6.txt b/Documentation/RelNotes/1.7.9.6.txt new file mode 100644 index 000000000..74bf8825e --- /dev/null +++ b/Documentation/RelNotes/1.7.9.6.txt @@ -0,0 +1,12 @@ +Git v1.7.9.6 Release Notes +========================== + +Fixes since v1.7.9.5 +-------------------- + + * "git merge $tag" to merge an annotated tag always opens the editor + during an interactive edit session. v1.7.10 series introduced an + environment variable GIT_MERGE_AUTOEDIT to help older scripts decline + this behaviour, but the maintenance track should also support it. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.9.7.txt b/Documentation/RelNotes/1.7.9.7.txt new file mode 100644 index 000000000..59667d0f2 --- /dev/null +++ b/Documentation/RelNotes/1.7.9.7.txt @@ -0,0 +1,13 @@ +Git v1.7.9.7 Release Notes +========================== + +Fixes since v1.7.9.6 +-------------------- + + * An error message from 'git bundle' had an unmatched single quote pair in it. + + * The way 'git fetch' implemented its connectivity check over + received objects was overly pessimistic, and wasted a lot of + cycles. + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.9.txt b/Documentation/RelNotes/1.7.9.txt new file mode 100644 index 000000000..95320aad5 --- /dev/null +++ b/Documentation/RelNotes/1.7.9.txt @@ -0,0 +1,112 @@ +Git v1.7.9 Release Notes +======================== + +Updates since v1.7.8 +-------------------- + + * gitk updates accumulated since early 2011. + + * git-gui updated to 0.16.0. + + * git-p4 (in contrib/) updates. + + * Git uses gettext to translate its most common interface messages + into the user's language if translations are available and the + locale is appropriately set. Distributors can drop new PO files + in po/ to add new translations. + + * The code to handle username/password for HTTP transactions used in + "git push" & "git fetch" learned to talk "credential API" to + external programs to cache or store them, to allow integration with + platform native keychain mechanisms. + + * The input prompts in the terminal use our own getpass() replacement + when possible. HTTP transactions used to ask for the username without + echoing back what was typed, but with this change you will see it as + you type. + + * The internals of "revert/cherry-pick" have been tweaked to prepare + building more generic "sequencer" on top of the implementation that + drives them. + + * "git rev-parse FETCH_HEAD" after "git fetch" without specifying + what to fetch from the command line will now show the commit that + would be merged if the command were "git pull". + + * "git add" learned to stream large files directly into a packfile + instead of writing them into individual loose object files. + + * "git checkout -B <current branch> <elsewhere>" is a more intuitive + way to spell "git reset --keep <elsewhere>". + + * "git checkout" and "git merge" learned "--no-overwrite-ignore" option + to tell Git that untracked and ignored files are not expendable. + + * "git commit --amend" learned "--no-edit" option to say that the + user is amending the tree being recorded, without updating the + commit log message. + + * "git commit" and "git reset" re-learned the optimization to prime + the cache-tree information in the index, which makes it faster to + write a tree object out after the index entries are updated. + + * "git commit" detects and rejects an attempt to stuff NUL byte in + the commit log message. + + * "git commit" learned "-S" to GPG-sign the commit; this can be shown + with the "--show-signature" option to "git log". + + * fsck and prune are relatively lengthy operations that still go + silent while making the end-user wait. They learned to give progress + output like other slow operations. + + * The set of built-in function-header patterns for various languages + knows MATLAB. + + * "git log --format='<format>'" learned new %g[nNeE] specifiers to + show information from the reflog entries when walking the reflog + (i.e. with "-g"). + + * "git pull" can be used to fetch and merge an annotated/signed tag, + instead of the tip of a topic branch. The GPG signature from the + signed tag is recorded in the resulting merge commit for later + auditing. + + * "git log" learned "--show-signature" option to show the signed tag + that was merged that is embedded in the merge commit. It also can + show the signature made on the commit with "git commit -S". + + * "git branch --edit-description" can be used to add descriptive text + to explain what a topic branch is about. + + * "git fmt-merge-msg" learned to take the branch description into + account when preparing a merge summary that "git merge" records + when merging a local branch. + + * "git request-pull" has been updated to convey more information + useful for integrators to decide if a topic is worth merging and + what is pulled is indeed what the requestor asked to pull, + including: + + - the tip of the branch being requested to be merged; + - the branch description describing what the topic is about; + - the contents of the annotated tag, when requesting to pull a tag. + + * "git pull" learned to notice 'pull.rebase' configuration variable, + which serves as a global fallback for setting 'branch.<name>.rebase' + configuration variable per branch. + + * "git tag" learned "--cleanup" option to control how the whitespaces + and empty lines in tag message are cleaned up. + + * "gitweb" learned to show side-by-side diff. + +Also contains minor documentation updates and code clean-ups. + + +Fixes since v1.7.8 +------------------ + +Unless otherwise noted, all the fixes since v1.7.8 in the maintenance +releases are contained in this release (see release notes to them for +details). diff --git a/Documentation/RelNotes/1.8.0.1.txt b/Documentation/RelNotes/1.8.0.1.txt new file mode 100644 index 000000000..1f372fa0b --- /dev/null +++ b/Documentation/RelNotes/1.8.0.1.txt @@ -0,0 +1,64 @@ +Git v1.8.0.1 Release Notes +========================== + +Fixes since v1.8.0 +------------------ + + * The configuration parser had an unnecessary hardcoded limit on + variable names that was not checked consistently. + + * The "say" function in the test scaffolding incorrectly allowed + "echo" to interpret "\a" as if it were a C-string asking for a + BEL output. + + * "git mergetool" feeds /dev/null as a common ancestor when dealing + with an add/add conflict, but p4merge backend cannot handle + it. Work it around by passing a temporary empty file. + + * "git log -F -E --grep='<ere>'" failed to use the given <ere> + pattern as extended regular expression, and instead looked for the + string literally. + + * "git grep -e pattern <tree>" asked the attribute system to read + "<tree>:.gitattributes" file in the working tree, which was + nonsense. + + * A symbolic ref refs/heads/SYM was not correctly removed with "git + branch -d SYM"; the command removed the ref pointed by SYM + instead. + + * Earlier we fixed documentation to hyphenate "remote-tracking branch" + to clarify that these are not a remote entity, but unhyphenated + spelling snuck in to a few places since then. + + * "git pull --rebase" run while the HEAD is detached tried to find + the upstream branch of the detached HEAD (which by definition + does not exist) and emitted unnecessary error messages. + + * The refs/replace hierarchy was not mentioned in the + repository-layout docs. + + * Sometimes curl_multi_timeout() function suggested a wrong timeout + value when there is no file descriptors to wait on and the http + transport ended up sleeping for minutes in select(2) system call. + A workaround has been added for this. + + * Various rfc2047 quoting issues around a non-ASCII name on the + From: line in the output from format-patch have been corrected. + + * "git diff -G<pattern>" did not honor textconv filter when looking + for changes. + + * Bash completion script (in contrib/) did not correctly complete a + lazy "git checkout $name_of_remote_tracking_branch_that_is_unique" + command line. + + * RSS feed from "gitweb" had a xss hole in its title output. + + * "git config --path $key" segfaulted on "[section] key" (a boolean + "true" spelled without "=", not "[section] key = true"). + + * "git checkout -b foo" while on an unborn branch did not say + "Switched to a new branch 'foo'" like other cases. + +Also contains other minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.8.0.2.txt b/Documentation/RelNotes/1.8.0.2.txt new file mode 100644 index 000000000..8497e051d --- /dev/null +++ b/Documentation/RelNotes/1.8.0.2.txt @@ -0,0 +1,34 @@ +Git v1.8.0.2 Release Notes +========================== + +Fixes since v1.8.0.1 +-------------------- + + * Various codepaths have workaround for a common misconfiguration to + spell "UTF-8" as "utf8", but it was not used uniformly. Most + notably, mailinfo (which is used by "git am") lacked this support. + + * We failed to mention a file without any content change but whose + permission bit was modified, or (worse yet) a new file without any + content in the "git diff --stat" output. + + * When "--stat-count" hides a diffstat for binary contents, the total + number of added and removed lines at the bottom was computed + incorrectly. + + * When "--stat-count" hides a diffstat for unmerged paths, the total + number of affected files at the bottom of the "diff --stat" output + was computed incorrectly. + + * "diff --shortstat" miscounted the total number of affected files + when there were unmerged paths. + + * "git p4" used to try expanding malformed "$keyword$" that spans + across multiple lines. + + * "git update-ref -d --deref SYM" to delete a ref through a symbolic + ref that points to it did not remove it correctly. + + * Syntax highlighting in "gitweb" was not quite working. + +Also contains other minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.8.0.3.txt b/Documentation/RelNotes/1.8.0.3.txt new file mode 100644 index 000000000..92b1e4b36 --- /dev/null +++ b/Documentation/RelNotes/1.8.0.3.txt @@ -0,0 +1,14 @@ +Git v1.8.0.3 Release Notes +========================== + +Fixes since v1.8.0.2 +-------------------- + + * "git log -p -S<string>" did not apply the textconv filter while + looking for the <string>. + + * In the documentation, some invalid example e-mail addresses were + formatted into mailto: links. + +Also contains many documentation updates backported from the 'master' +branch that is preparing for the upcoming 1.8.1 release. diff --git a/Documentation/RelNotes/1.8.0.txt b/Documentation/RelNotes/1.8.0.txt new file mode 100644 index 000000000..43883c14f --- /dev/null +++ b/Documentation/RelNotes/1.8.0.txt @@ -0,0 +1,267 @@ +Git v1.8.0 Release Notes +======================== + +Backward compatibility notes +---------------------------- + +In the next major release (not *this* one), we will change the +behavior of the "git push" command. + +When "git push [$there]" does not say what to push, we have used the +traditional "matching" semantics so far (all your branches were sent +to the remote as long as there already are branches of the same name +over there). We will use the "simple" semantics that pushes the +current branch to the branch with the same name, only when the current +branch is set to integrate with that remote branch. There is a user +preference configuration variable "push.default" to change this, and +"git push" will warn about the upcoming change until you set this +variable in this release. + +"git branch --set-upstream" is deprecated and may be removed in a +relatively distant future. "git branch [-u|--set-upstream-to]" has +been introduced with a saner order of arguments. + + +Updates since v1.7.12 +--------------------- + +UI, Workflows & Features + + * A credential helper for Win32 to allow access to the keychain of + the logged-in user has been added. + + * An initial port to HP NonStop. + + * A credential helper to allow access to the Gnome keyring has been + added. + + * When "git am" sanitizes the "Subject:" line, we strip the prefix from + "Re: subject" and also from a less common "re: subject", but left + the even less common "RE: subject" intact. Now we strip that too. + + * It was tempting to say "git branch --set-upstream origin/master", + but that tells Git to arrange the local branch "origin/master" to + integrate with the currently checked out branch, which is highly + unlikely what the user meant. The option is deprecated; use the + new "--set-upstream-to" (with a short-and-sweet "-u") option + instead. + + * "git cherry-pick" learned the "--allow-empty-message" option to + allow it to replay a commit without any log message. + + * After "git cherry-pick -s" gave control back to the user asking + help to resolve conflicts, concluding "git commit" used to need to + be run with "-s" if the user wants to sign it off; now the command + leaves the sign-off line in the log template. + + * "git daemon" learned the "--access-hook" option to allow an + external command to decline service based on the client address, + repository path, etc. + + * "git difftool --dir-diff" learned to use symbolic links to prepare + a temporary copy of the working tree when available. + + * "git grep" learned to use a non-standard pattern type by default if + a configuration variable tells it to. + + * Accumulated updates to "git gui" has been merged. + + * "git log -g" learned the "--grep-reflog=<pattern>" option to limit + its output to commits with a reflog message that matches the given + pattern. + + * "git merge-base" learned the "--is-ancestor A B" option to tell if A is + an ancestor of B. The result is indicated by its exit status code. + + * "git mergetool" now allows users to override the actual command used + with the mergetool.$name.cmd configuration variable even for built-in + mergetool backends. + + * "git rebase -i" learned the "--edit-todo" option to open an editor + to edit the instruction sheet. + + +Foreign Interface + + * "git svn" has been updated to work with SVN 1.7. + + * "git p4" learned the "--conflicts" option to specify what to do when + encountering a conflict during "p4 submit". + + +Performance, Internal Implementation, etc. + + * Git ships with a fall-back regexp implementation for platforms with + buggy regexp library, but it was easy for people to keep using their + platform regexp by mistake. A new test has been added to check this. + + * The "check-docs" build target has been updated and greatly + simplified. + + * The test suite is run under MALLOC_CHECK_ when running with a glibc + that supports the feature. + + * The documentation in the TeXinfo format was using indented output + for materials meant to be examples that are better typeset in + monospace. + + * Compatibility wrapper around some mkdir(2) implementations that + reject parameters with trailing slash has been introduced. + + * Compatibility wrapper for systems that lack usable setitimer() has + been added. + + * The option parsing of "git checkout" had error checking, dwim and + defaulting missing options, all mixed in the code, and issuing an + appropriate error message with useful context was getting harder. + The code has been reorganized to allow giving a proper diagnosis + when the user says "git checkout -b -t foo bar" (e.g. "-t" is not a + good name for a branch). + + * Many internal uses of a "git merge-base" equivalent were only to see + if one commit fast-forwards to the other, which did not need the + full set of merge bases to be computed. They have been updated to + use less expensive checks. + + * The heuristics to detect and silently convert latin1 to utf8 when + we were told to use utf-8 in the log message has been transplanted + from "mailinfo" to "commit" and "commit-tree". + + * Messages given by "git <subcommand> -h" from many subcommands have + been marked for translation. + + +Also contains minor documentation updates and code clean-ups. + + +Fixes since v1.7.12 +------------------- + +Unless otherwise noted, all the fixes since v1.7.12 in the +maintenance track are contained in this release (see release notes +to them for details). + + * The attribute system may be asked for a path that itself or its + leading directories no longer exists in the working tree, and it is + fine if we cannot open .gitattribute file in such a case. Failure + to open per-directory .gitattributes with error status other than + ENOENT and ENOTDIR should be diagnosed, but it wasn't. + + * When looking for $HOME/.gitconfig etc., it is OK if we cannot read + them because they do not exist, but we did not diagnose existing + files that we cannot read. + + * When "git am" is fed an input that has multiple "Content-type: ..." + header, it did not grok charset= attribute correctly. + + * "git am" mishandled a patch attached as application/octet-stream + (e.g. not text/*); Content-Transfer-Encoding (e.g. base64) was not + honored correctly. + + * "git blame MAKEFILE" run in a history that has "Makefile" but not + "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got + confused on a case insensitive filesystem and failed to do so. + + * Even during a conflicted merge, "git blame $path" always meant to + blame uncommitted changes to the "working tree" version; make it + more useful by showing cleanly merged parts as coming from the other + branch that is being merged. + + * It was unclear in the documentation for "git blame" that it is + unnecessary for users to use the "--follow" option. + + * Output from "git branch -v" contains "(no branch)" that could be + localized, but the code to align it along with the names of + branches was counting in bytes, not in display columns. + + * "git cherry-pick A C B" used to replay changes in A and then B and + then C if these three commits had committer timestamps in that + order, which is not what the user who said "A C B" naturally + expects. + + * A repository created with "git clone --single" had its fetch + refspecs set up just like a clone without "--single", leading the + subsequent "git fetch" to slurp all the other branches, defeating + the whole point of specifying "only this branch". + + * Documentation talked about "first line of commit log" when it meant + the title of the commit. The description was clarified by defining + how the title is decided and rewording the casual mention of "first + line" to "title". + + * "git cvsimport" did not thoroughly cleanse tag names that it + inferred from the names of the tags it obtained from CVS, which + caused "git tag" to barf and stop the import in the middle. + + * Earlier we made the diffstat summary line that shows the number of + lines added/deleted localizable, but it was found irritating having + to see them in various languages on a list whose discussion language + is English, and this change has been reverted. + + * "git fetch --all", when passed "--no-tags", did not honor the + "--no-tags" option while fetching from individual remotes (the same + issue existed with "--tags", but the combination "--all --tags" makes + much less sense than "--all --no-tags"). + + * "git fetch" over http had an old workaround for an unlikely server + misconfiguration; it turns out that this hurts debuggability of the + configuration in general, and has been reverted. + + * "git fetch" over http advertised that it supports "deflate", which + is much less common, and did not advertise the more common "gzip" on + its Accept-Encoding header. + + * "git fetch" over the dumb-http revision walker could segfault when + curl's multi interface was used. + + * "git gc --auto" notified the user that auto-packing has triggered + even under the "--quiet" option. + + * After "gitk" showed the contents of a tag, neither "Reread + references" nor "Reload" updated what is shown as the + contents of it when the user overwrote the tag with "git tag -f". + + * "git log --all-match --grep=A --grep=B" ought to show commits that + mention both A and B, but when these three options are used with + --author or --committer, it showed commits that mention either A or + B (or both) instead. + + * The "-Xours" backend option to "git merge -s recursive" was ignored + for binary files. + + * "git p4", when "--use-client-spec" and "--detect-branches" are used + together, misdetected branches. + + * "git receive-pack" (the counterpart to "git push") did not give + progress output while processing objects it received to the puser + when run over the smart-http protocol. + + * When you misspell the command name you give to the "exec" action in + the "git rebase -i" instruction sheet you were told that 'rebase' is not a + git subcommand from "git rebase --continue". + + * The subcommand in "git remote" to remove a defined remote was + "rm" and the command did not take a fully-spelled "remove". + + * The interactive prompt that "git send-email" gives was error prone. It + asked "What e-mail address do you want to use?" with the address it + guessed (correctly) the user would want to use in its prompt, + tempting the user to say "y". But the response was taken as "No, + please use 'y' as the e-mail address instead", which is most + certainly not what the user meant. + + * "git show --format='%ci'" did not give the timestamp correctly for + commits created without human readable name on the "committer" line. + + * "git show --quiet" ought to be a synonym for "git show -s", but + wasn't. + + * "git submodule frotz" was not diagnosed as "frotz" being an unknown + subcommand to "git submodule"; the user instead got a complaint + that "git submodule status" was run with an unknown path "frotz". + + * "git status" honored the ignore=dirty settings in .gitmodules but + "git commit" didn't. + + * "gitweb" did not give the correct committer timezone in its feed + output due to a typo. diff --git a/Documentation/RelNotes/1.8.1.1.txt b/Documentation/RelNotes/1.8.1.1.txt new file mode 100644 index 000000000..6cde07ba2 --- /dev/null +++ b/Documentation/RelNotes/1.8.1.1.txt @@ -0,0 +1,87 @@ +Git 1.8.1.1 Release Notes +========================= + +Fixes since v1.8.1 +------------------ + + * The attribute mechanism didn't allow limiting attributes to be + applied to only a single directory itself with "path/" like the + exclude mechanism does. + + * When attempting to read the XDG-style $HOME/.config/git/config and + finding that $HOME/.config/git is a file, we gave a wrong error + message, instead of treating the case as "a custom config file does + not exist there" and moving on. + + * After failing to create a temporary file using mkstemp(), failing + pathname was not reported correctly on some platforms. + + * http transport was wrong to ask for the username when the + authentication is done by certificate identity. + + * The behaviour visible to the end users was confusing, when they + attempt to kill a process spawned in the editor that was in turn + launched by Git with SIGINT (or SIGQUIT), as Git would catch that + signal and die. We ignore these signals now. + + * A child process that was killed by a signal (e.g. SIGINT) was + reported in an inconsistent way depending on how the process was + spawned by us, with or without a shell in between. + + * After "git add -N" and then writing a tree object out of the + index, the cache-tree data structure got corrupted. + + * "git apply" misbehaved when fixing whitespace breakages by removing + excess trailing blank lines in some corner cases. + + * A tar archive created by "git archive" recorded a directory in a + way that made NetBSD's implementation of "tar" sometimes unhappy. + + * When "git clone --separate-git-dir=$over_there" is interrupted, it + failed to remove the real location of the $GIT_DIR it created. + This was most visible when interrupting a submodule update. + + * "git fetch --mirror" and fetch that uses other forms of refspec + with wildcard used to attempt to update a symbolic ref that match + the wildcard on the receiving end, which made little sense (the + real ref that is pointed at by the symbolic ref would be updated + anyway). Symbolic refs no longer are affected by such a fetch. + + * The "log --graph" codepath fell into infinite loop in some + corner cases. + + * "git merge" started calling prepare-commit-msg hook like "git + commit" does some time ago, but forgot to pay attention to the exit + status of the hook. + + * "git pack-refs" that ran in parallel to another process that + created new refs had a race that can lose new ones. + + * When a line to be wrapped has a solid run of non space characters + whose length exactly is the wrap width, "git shortlog -w" failed + to add a newline after such a line. + + * The way "git svn" asked for password using SSH_ASKPASS and + GIT_ASKPASS was not in line with the rest of the system. + + * "gitweb", when sorting by age to show repositories with new + activities first, used to sort repositories with absolutely + nothing in it early, which was not very useful. + + * "gitweb", when sorting by age to show repositories with new + activities first, used to sort repositories with absolutely + nothing in it early, which was not very useful. + + * When autoconf is used, any build on a different commit always ran + "config.status --recheck" even when unnecessary. + + * Some scripted programs written in Python did not get updated when + PYTHON_PATH changed. + + * We have been carrying a translated and long-unmaintained copy of an + old version of the tutorial; removed. + + * Portability issues in many self-test scripts have been addressed. + + +Also contains other minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.8.1.2.txt b/Documentation/RelNotes/1.8.1.2.txt new file mode 100644 index 000000000..5ab7b1890 --- /dev/null +++ b/Documentation/RelNotes/1.8.1.2.txt @@ -0,0 +1,25 @@ +Git 1.8.1.2 Release Notes +========================= + +Fixes since v1.8.1.1 +-------------------- + + * An element on GIT_CEILING_DIRECTORIES list that does not name the + real path to a directory (i.e. a symbolic link) could have caused + the GIT_DIR discovery logic to escape the ceiling. + + * Command line completion for "tcsh" emitted an unwanted space + after completing a single directory name. + + * Command line completion leaked an unnecessary error message while + looking for possible matches with paths in <tree-ish>. + + * "git archive" did not record uncompressed size in the header when + streaming a zip archive, which confused some implementations of unzip. + + * When users spelled "cc:" in lowercase in the fake "header" in the + trailer part, "git send-email" failed to pick up the addresses from + there. As e-mail headers field names are case insensitive, this + script should follow suit and treat "cc:" and "Cc:" the same way. + +Also contains various documentation fixes. diff --git a/Documentation/RelNotes/1.8.1.3.txt b/Documentation/RelNotes/1.8.1.3.txt new file mode 100644 index 000000000..681cb35c0 --- /dev/null +++ b/Documentation/RelNotes/1.8.1.3.txt @@ -0,0 +1,47 @@ +Git 1.8.1.3 Release Notes +========================= + +Fixes since v1.8.1.2 +-------------------- + + * The attribute mechanism didn't allow limiting attributes to be + applied to only a single directory itself with "path/" like the + exclude mechanism does. The fix for this in 1.8.1.2 had + performance degradations. + + * Command line completion code was inadvertently made incompatible with + older versions of bash by using a newer array notation. + + * Scripts to test bash completion was inherently flaky as it was + affected by whatever random things the user may have on $PATH. + + * A fix was added to the build procedure to work around buggy + versions of ccache broke the auto-generation of dependencies, which + unfortunately is still relevant because some people use ancient + distros. + + * We used to stuff "user@" and then append what we read from + /etc/mailname to come up with a default e-mail ident, but a bug + lost the "user@" part. + + * "git am" did not parse datestamp correctly from Hg generated patch, + when it is run in a locale outside C (or en). + + * Attempt to "branch --edit-description" an existing branch, while + being on a detached HEAD, errored out. + + * "git cherry-pick" did not replay a root commit to an unborn branch. + + * We forgot to close the file descriptor reading from "gpg" output, + killing "git log --show-signature" on a long history. + + * "git rebase --preserve-merges" lost empty merges in recent versions + of Git. + + * Rebasing the history of superproject with change in the submodule + has been broken since v1.7.12. + + * A failure to push due to non-ff while on an unborn branch + dereferenced a NULL pointer when showing an error message. + +Also contains various documentation fixes. diff --git a/Documentation/RelNotes/1.8.1.4.txt b/Documentation/RelNotes/1.8.1.4.txt new file mode 100644 index 000000000..22af1d164 --- /dev/null +++ b/Documentation/RelNotes/1.8.1.4.txt @@ -0,0 +1,11 @@ +Git 1.8.1.4 Release Notes +========================= + +Fixes since v1.8.1.3 +-------------------- + + * "git imap-send" talking over imaps:// did make sure it received a + valid certificate from the other end, but did not check if the + certificate matched the host it thought it was talking to. + +Also contains various documentation fixes. diff --git a/Documentation/RelNotes/1.8.1.5.txt b/Documentation/RelNotes/1.8.1.5.txt new file mode 100644 index 000000000..efa68aef2 --- /dev/null +++ b/Documentation/RelNotes/1.8.1.5.txt @@ -0,0 +1,47 @@ +Git 1.8.1.5 Release Notes +========================= + +Fixes since v1.8.1.4 +-------------------- + + * Given a string with a multi-byte character that begins with '-' on + the command line where an option is expected, the option parser + used just one byte of the unknown letter when reporting an error. + + * In v1.8.1, the attribute parser was tightened too restrictive to + error out upon seeing an entry that begins with an ! (exclamation), + which may confuse users to expect a "negative match", which does + not exist. This has been demoted to a warning; such an entry is + still ignored. + + * "git apply --summary" has been taught to make sure the similarity + value shown in its output is sensible, even when the input had a + bogus value. + + * "git clean" showed what it was going to do, but sometimes ended + up finding that it was not allowed to do so, which resulted in a + confusing output (e.g. after saying that it will remove an + untracked directory, it found an embedded git repository there + which it is not allowed to remove). It now performs the actions + and then reports the outcome more faithfully. + + * "git clone" used to allow --bare and --separate-git-dir=$there + options at the same time, which was nonsensical. + + * "git cvsimport" mishandled timestamps at DST boundary. + + * We used to have an arbitrary 32 limit for combined diff input, + resulting in incorrect number of leading colons shown when showing + the "--raw --cc" output. + + * The smart HTTP clients forgot to verify the content-type that comes + back from the server side to make sure that the request is being + handled properly. + + * "git help remote-helpers" failed to find the documentation. + + * "gitweb" pages served over HTTPS, when configured to show picon or + gravatar, referred to these external resources to be fetched via + HTTP, resulting in mixed contents warning in browsers. + +Also contains various documentation fixes. diff --git a/Documentation/RelNotes/1.8.1.6.txt b/Documentation/RelNotes/1.8.1.6.txt new file mode 100644 index 000000000..c15cf2e80 --- /dev/null +++ b/Documentation/RelNotes/1.8.1.6.txt @@ -0,0 +1,39 @@ +Git 1.8.1.6 Release Notes +========================= + +Fixes since v1.8.1.5 +-------------------- + + * An earlier change to the attribute system introduced at v1.8.1.2 by + mistake stopped a pattern "dir" (without trailing slash) from + matching a directory "dir" (it only wanted to allow pattern "dir/" + to also match). + + * The code to keep track of what directory names are known to Git on + platforms with case insensitive filesystems can get confused upon a + hash collision between these pathnames and looped forever. + + * When the "--prefix" option is used to "checkout-index", the code + did not pick the correct output filter based on the attribute + setting. + + * Annotated tags outside refs/tags/ hierarchy were not advertised + correctly to the ls-remote and fetch with recent version of Git. + + * The logic used by "git diff -M --stat" to shorten the names of + files before and after a rename did not work correctly when the + common prefix and suffix between the two filenames overlapped. + + * "git update-index -h" did not do the usual "-h(elp)" thing. + + * perl/Git.pm::cat_blob slurped everything in core only to write it + out to a file descriptor, which was not a very smart thing to do. + + * The SSL peer verification done by "git imap-send" did not ask for + Server Name Indication (RFC 4366), failing to connect SSL/TLS + sites that serve multiple hostnames on a single IP. + + * "git bundle verify" did not say "records a complete history" for a + bundle that does not have any prerequisites. + +Also contains various documentation fixes. diff --git a/Documentation/RelNotes/1.8.1.txt b/Documentation/RelNotes/1.8.1.txt new file mode 100644 index 000000000..d6f955592 --- /dev/null +++ b/Documentation/RelNotes/1.8.1.txt @@ -0,0 +1,241 @@ +Git v1.8.1 Release Notes +======================== + +Backward compatibility notes +---------------------------- + +In the next major release (not *this* one), we will change the +behavior of the "git push" command. + +When "git push [$there]" does not say what to push, we have used the +traditional "matching" semantics so far (all your branches were sent +to the remote as long as there already are branches of the same name +over there). We will use the "simple" semantics that pushes the +current branch to the branch with the same name, only when the current +branch is set to integrate with that remote branch. There is a user +preference configuration variable "push.default" to change this, and +"git push" will warn about the upcoming change until you set this +variable in this release. + +"git branch --set-upstream" is deprecated and may be removed in a +relatively distant future. "git branch [-u|--set-upstream-to]" has +been introduced with a saner order of arguments to replace it. + + +Updates since v1.8.0 +-------------------- + +UI, Workflows & Features + + * Command-line completion scripts for tcsh and zsh have been added. + + * "git-prompt" scriptlet (in contrib/completion) can be told to paint + pieces of the hints in the prompt string in colors. + + * Some documentation pages that used to ship only in the plain text + format are now formatted in HTML as well. + + * We used to have a workaround for a bug in ancient "less" that + causes it to exit without any output when the terminal is resized. + The bug has been fixed in "less" version 406 (June 2007), and the + workaround has been removed in this release. + + * When "git checkout" checks out a branch, it tells the user how far + behind (or ahead) the new branch is relative to the remote tracking + branch it builds upon. The message now also advises how to sync + them up by pushing or pulling. This can be disabled with the + advice.statusHints configuration variable. + + * "git config --get" used to diagnose presence of multiple + definitions of the same variable in the same configuration file as + an error, but it now applies the "last one wins" rule used by the + internal configuration logic. Strictly speaking, this may be an + API regression but it is expected that nobody will notice it in + practice. + + * A new configuration variable "diff.context" can be used to + give the default number of context lines in the patch output, to + override the hardcoded default of 3 lines. + + * "git format-patch" learned the "--notes=<ref>" option to give + notes for the commit after the three-dash lines in its output. + + * "git log -p -S<string>" now looks for the <string> after applying + the textconv filter (if defined); earlier it inspected the contents + of the blobs without filtering. + + * "git log --grep=<pcre>" learned to honor the "grep.patterntype" + configuration set to "perl". + + * "git replace -d <object>" now interprets <object> as an extended + SHA-1 (e.g. HEAD~4 is allowed), instead of only accepting full hex + object name. + + * "git rm $submodule" used to punt on removing a submodule working + tree to avoid losing the repository embedded in it. Because + recent git uses a mechanism to separate the submodule repository + from the submodule working tree, "git rm" learned to detect this + case and removes the submodule working tree when it is safe to do so. + + * "git send-email" used to prompt for the sender address, even when + the committer identity is well specified (e.g. via user.name and + user.email configuration variables). The command no longer gives + this prompt when not necessary. + + * "git send-email" did not allow non-address garbage strings to + appear after addresses on Cc: lines in the patch files (and when + told to pick them up to find more recipients), e.g. + + Cc: Stable Kernel <stable@k.org> # for v3.2 and up + + The command now strips " # for v3.2 and up" part before adding the + remainder of this line to the list of recipients. + + * "git submodule add" learned to add a new submodule at the same + path as the path where an unrelated submodule was bound to in an + existing revision via the "--name" option. + + * "git submodule sync" learned the "--recursive" option. + + * "diff.submodule" configuration variable can be used to give custom + default value to the "git diff --submodule" option. + + * "git symbolic-ref" learned the "-d $symref" option to delete the + named symbolic ref, which is more intuitive way to spell it than + "update-ref -d --no-deref $symref". + + +Foreign Interface + + * "git cvsimport" can be told to record timezones (other than GMT) + per-author via its author info file. + + * The remote helper interface to interact with subversion + repositories (one of the GSoC 2012 projects) has been merged. + + * A new remote-helper interface for Mercurial has been added to + contrib/remote-helpers. + + * The documentation for git(1) was pointing at a page at an external + site for the list of authors that no longer existed. The link has + been updated to point at an alternative site. + + +Performance, Internal Implementation, etc. + + * Compilation on Cygwin with newer header files are supported now. + + * A couple of low-level implementation updates on MinGW. + + * The logic to generate the initial advertisement from "upload-pack" + (i.e. what is invoked by "git fetch" on the other side of the + connection) to list what refs are available in the repository has + been optimized. + + * The logic to find set of attributes that match a given path has + been optimized. + + * Use preloadindex in "git diff-index" and "git update-index", which + has a nice speedup on systems with slow stat calls (and even on + Linux). + + +Also contains minor documentation updates and code clean-ups. + + +Fixes since v1.8.0 +------------------ + +Unless otherwise noted, all the fixes since v1.8.0 in the maintenance +track are contained in this release (see release notes to them for +details). + + * The configuration parser had an unnecessary hardcoded limit on + variable names that was not checked consistently. + + * The "say" function in the test scaffolding incorrectly allowed + "echo" to interpret "\a" as if it were a C-string asking for a + BEL output. + + * "git mergetool" feeds /dev/null as a common ancestor when dealing + with an add/add conflict, but p4merge backend cannot handle + it. Work it around by passing a temporary empty file. + + * "git log -F -E --grep='<ere>'" failed to use the given <ere> + pattern as extended regular expression, and instead looked for the + string literally. + + * "git grep -e pattern <tree>" asked the attribute system to read + "<tree>:.gitattributes" file in the working tree, which was + nonsense. + + * A symbolic ref refs/heads/SYM was not correctly removed with "git + branch -d SYM"; the command removed the ref pointed by SYM + instead. + + * Update "remote tracking branch" in the documentation to + "remote-tracking branch". + + * "git pull --rebase" run while the HEAD is detached tried to find + the upstream branch of the detached HEAD (which by definition + does not exist) and emitted unnecessary error messages. + + * The refs/replace hierarchy was not mentioned in the + repository-layout docs. + + * Various rfc2047 quoting issues around a non-ASCII name on the + From: line in the output from format-patch have been corrected. + + * Sometimes curl_multi_timeout() function suggested a wrong timeout + value when there is no file descriptor to wait on and the http + transport ended up sleeping for minutes in select(2) system call. + A workaround has been added for this. + + * For a fetch refspec (or the result of applying wildcard on one), + we always want the RHS to map to something inside "refs/" + hierarchy, but the logic to check it was not exactly right. + (merge 5c08c1f jc/maint-fetch-tighten-refname-check later to maint). + + * "git diff -G<pattern>" did not honor textconv filter when looking + for changes. + + * Some HTTP servers ask for auth only during the actual packing phase + (not in ls-remote phase); this is not really a recommended + configuration, but the clients used to fail to authenticate with + such servers. + (merge 2e736fd jk/maint-http-half-auth-fetch later to maint). + + * "git p4" used to try expanding malformed "$keyword$" that spans + across multiple lines. + + * Syntax highlighting in "gitweb" was not quite working. + + * RSS feed from "gitweb" had a xss hole in its title output. + + * "git config --path $key" segfaulted on "[section] key" (a boolean + "true" spelled without "=", not "[section] key = true"). + + * "git checkout -b foo" while on an unborn branch did not say + "Switched to a new branch 'foo'" like other cases. + + * Various codepaths have workaround for a common misconfiguration to + spell "UTF-8" as "utf8", but it was not used uniformly. Most + notably, mailinfo (which is used by "git am") lacked this support. + + * We failed to mention a file without any content change but whose + permission bit was modified, or (worse yet) a new file without any + content in the "git diff --stat" output. + + * When "--stat-count" hides a diffstat for binary contents, the total + number of added and removed lines at the bottom was computed + incorrectly. + + * When "--stat-count" hides a diffstat for unmerged paths, the total + number of affected files at the bottom of the "diff --stat" output + was computed incorrectly. + + * "diff --shortstat" miscounted the total number of affected files + when there were unmerged paths. + + * "update-ref -d --deref SYM" to delete a ref through a symbolic ref + that points to it did not remove it correctly. diff --git a/Documentation/RelNotes/1.8.2.1.txt b/Documentation/RelNotes/1.8.2.1.txt new file mode 100644 index 000000000..769a6fc06 --- /dev/null +++ b/Documentation/RelNotes/1.8.2.1.txt @@ -0,0 +1,115 @@ +Git v1.8.2.1 Release Notes +========================== + +Fixes since v1.8.2 +------------------ + + * An earlier change to the attribute system introduced at v1.8.1.2 by + mistake stopped a pattern "dir" (without trailing slash) from + matching a directory "dir" (it only wanted to allow pattern "dir/" + to also match). + + * Verification of signed tags were not done correctly when not in C + or en/US locale. + + * 'git commit -m "$msg"' used to add an extra newline even when + $msg already ended with one. + + * The "--match=<pattern>" option of "git describe", when used with + "--all" to allow refs that are not annotated tags to be used as a + base of description, did not restrict the output from the command + to those that match the given pattern. + + * An aliased command spawned from a bare repository that does not say + it is bare with "core.bare = yes" is treated as non-bare by mistake. + + * When "format-patch" quoted a non-ascii strings on the header files, + it incorrectly applied rfc2047 and chopped a single character in + the middle of it. + + * "git archive" reports a failure when asked to create an archive out + of an empty tree. It would be more intuitive to give an empty + archive back in such a case. + + * "git tag -f <tag>" always said "Updated tag '<tag>'" even when + creating a new tag (i.e. not overwriting nor updating). + + * "git cmd -- ':(top'" was not diagnosed as an invalid syntax, and + instead the parser kept reading beyond the end of the string. + + * Annotated tags outside refs/tags/ hierarchy were not advertised + correctly to the ls-remote and fetch with recent version of Git. + + * The code to keep track of what directory names are known to Git on + platforms with case insensitive filesystems can get confused upon a + hash collision between these pathnames and looped forever. + + * The logic used by "git diff -M --stat" to shorten the names of + files before and after a rename did not work correctly when the + common prefix and suffix between the two filenames overlapped. + + * "git submodule update", when recursed into sub-submodules, did not + accumulate the prefix paths. + + * "git am $maildir/" applied messages in an unexpected order; sort + filenames read from the maildir/ in a way that is more likely to + sort messages in the order the writing MUA meant to, by sorting + numeric segment in numeric order and non-numeric segment in + alphabetical order. + + * When export-subst is used, "zip" output recorded incorrect + size of the file. + + * Some platforms and users spell UTF-8 differently; retry with the + most official "UTF-8" when the system does not understand the + user-supplied encoding name that are the common alternative + spellings of UTF-8. + + * "git branch" did not bother to check nonsense command line + parameters and issue errors in many cases. + + * "git update-index -h" did not do the usual "-h(elp)" thing. + + * perl/Git.pm::cat_blob slurped everything in core only to write it + out to a file descriptor, which was not a very smart thing to do. + + * The SSL peer verification done by "git imap-send" did not ask for + Server Name Indication (RFC 4366), failing to connect SSL/TLS + sites that serve multiple hostnames on a single IP. + + * "git index-pack" had a buffer-overflow while preparing an + informational message when the translated version of it was too + long. + + * Clarify in the documentation "what" gets pushed to "where" when the + command line to "git push" does not say these explicitly. + + * In "git reflog expire", REACHABLE bit was not cleared from the + correct objects. + + * The "--color=<when>" argument to the commands in the diff family + was described poorly. + + * The arguments given to pre-rebase hook were not documented. + + * The v4 index format was not documented. + + * The "--match=<pattern>" argument "git describe" takes uses glob + pattern but it wasn't obvious from the documentation. + + * Some sources failed to compile on systems that lack NI_MAXHOST in + their system header (e.g. z/OS). + + * Add an example use of "--env-filter" in "filter-branch" + documentation. + + * "git bundle verify" did not say "records a complete history" for a + bundle that does not have any prerequisites. + + * In the v1.8.0 era, we changed symbols that do not have to be global + to file scope static, but a few functions in graph.c were used by + CGit from sideways bypassing the entry points of the API the + in-tree users use. + + * "git merge-tree" had a typo in the logic to detect d/f conflicts, + which caused it to segfault in some cases. diff --git a/Documentation/RelNotes/1.8.2.2.txt b/Documentation/RelNotes/1.8.2.2.txt new file mode 100644 index 000000000..708df1ae1 --- /dev/null +++ b/Documentation/RelNotes/1.8.2.2.txt @@ -0,0 +1,61 @@ +Git v1.8.2.2 Release Notes +========================== + +Fixes since v1.8.2.1 +-------------------- + + * Zsh completion forgot that '%' character used to signal untracked + files needs to be escaped with another '%'. + + * A commit object whose author or committer ident are malformed + crashed some code that trusted that a name, an email and an + timestamp can always be found in it. + + * The new core.commentchar configuration was not applied to a few + places. + + * "git pull --rebase" did not pass "-v/-q" options to underlying + "git rebase". + + * When receive-pack detects error in the pack header it received in + order to decide which of unpack-objects or index-pack to run, it + returned without closing the error stream, which led to a hang + sideband thread. + + * "git diff --diff-algorithm=algo" was understood by the command line + parser, but "git diff --diff-algorithm algo" was not. + + * "git log -S/-G" started paying attention to textconv filter, but + there was no way to disable this. Make it honor --no-textconv + option. + + * "git merge $(git rev-parse v1.8.2)" behaved quite differently from + "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did + not pay much attention to the annotated tag payload. Make the code + notice the type of the tag object, in addition to the dwim_ref() + based classification the current code uses (i.e. the name appears + in refs/tags/) to decide when to special case merging of tags. + + * "git cherry-pick" and "git revert" can take more than one commit + on the command line these days, but it was not mentioned on the usage + text. + + * Perl scripts like "git-svn" closed (not redirecting to /dev/null) + the standard error stream, which is not a very smart thing to do. + Later open may return file descriptor #2 for unrelated purpose, and + error reporting code may write into them. + + * "git apply --whitespace=fix" was not prepared to see a line getting + longer after fixing whitespaces (e.g. tab-in-indent aka Python). + + * "git diff/log --cc" did not work well with options that ignore + whitespace changes. + + * Documentation on setting up a http server that requires + authentication only on the push but not fetch has been clarified. + + * A few bugfixes to "git rerere" working on corner case merge + conflicts have been applied. + + * "git bundle" did not like a bundle created using a commit without + any message as its one of the prerequisites. diff --git a/Documentation/RelNotes/1.8.2.3.txt b/Documentation/RelNotes/1.8.2.3.txt new file mode 100644 index 000000000..613948251 --- /dev/null +++ b/Documentation/RelNotes/1.8.2.3.txt @@ -0,0 +1,19 @@ +Git v1.8.2.3 Release Notes +========================== + +Fixes since v1.8.2.2 +-------------------- + + * "rev-list --stdin" and friends kept bogus pointers into the input + buffer around as human readable object names. This was not a + huge problem but was exposed by a new change that uses these + names in error output. + + * When "git difftool" drove "kdiff3", it mistakenly passed --auto + option that was meant while resolving merge conflicts. + + * "git remote add" command did not diagnose extra command line + arguments as an error and silently ignored them. + +Also contains a handful of trivial code clean-ups, documentation +updates, updates to the test suite, etc. diff --git a/Documentation/RelNotes/1.8.2.txt b/Documentation/RelNotes/1.8.2.txt new file mode 100644 index 000000000..fc606ae11 --- /dev/null +++ b/Documentation/RelNotes/1.8.2.txt @@ -0,0 +1,495 @@ +Git v1.8.2 Release Notes +======================== + +Backward compatibility notes (this release) +------------------------------------------- + +"git push $there tag v1.2.3" used to allow replacing a tag v1.2.3 +that already exists in the repository $there, if the rewritten tag +you are pushing points at a commit that is a descendant of a commit +that the old tag v1.2.3 points at. This was found to be error prone +and starting with this release, any attempt to update an existing +ref under refs/tags/ hierarchy will fail, without "--force". + +When "git add -u" and "git add -A" that does not specify what paths +to add on the command line is run from inside a subdirectory, the +scope of the operation has always been limited to the subdirectory. +Many users found this counter-intuitive, given that "git commit -a" +and other commands operate on the entire tree regardless of where you +are. In this release, these commands give a warning message that +suggests the users to use "git add -u/-A ." when they want to limit +the scope to the current directory; doing so will squelch the message, +while training their fingers. + + +Backward compatibility notes (for Git 2.0) +------------------------------------------ + +When "git push [$there]" does not say what to push, we have used the +traditional "matching" semantics so far (all your branches were sent +to the remote as long as there already are branches of the same name +over there). In Git 2.0, the default will change to the "simple" +semantics that pushes the current branch to the branch with the same +name, only when the current branch is set to integrate with that +remote branch. There is a user preference configuration variable +"push.default" to change this. If you are an old-timer who is used +to the "matching" semantics, you can set it to "matching" to keep the +traditional behaviour. If you want to live in the future early, +you can set it to "simple" today without waiting for Git 2.0. + +When "git add -u" and "git add -A", that does not specify what paths +to add on the command line is run from inside a subdirectory, these +commands will operate on the entire tree in Git 2.0 for consistency +with "git commit -a" and other commands. Because there will be no +mechanism to make "git add -u" behave as if "git add -u .", it is +important for those who are used to "git add -u" (without pathspec) +updating the index only for paths in the current subdirectory to start +training their fingers to explicitly say "git add -u ." when they mean +it before Git 2.0 comes. + + +Updates since v1.8.1 +-------------------- + +UI, Workflows & Features + + * Initial ports to QNX and z/OS UNIX System Services have started. + + * Output from the tests is coloured using "green is okay, yellow is + questionable, red is bad and blue is informative" scheme. + + * Mention of "GIT/Git/git" in the documentation have been updated to + be more uniform and consistent. The name of the system and the + concept it embodies is "Git"; the command the users type is "git". + All-caps "GIT" was merely a way to imitate "Git" typeset in small + caps in our ASCII text only documentation and to be avoided. + + * The completion script (in contrib/completion) used to let the + default completer to suggest pathnames, which gave too many + irrelevant choices (e.g. "git add" would not want to add an + unmodified path). It learnt to use a more git-aware logic to + enumerate only relevant ones. + + * In bare repositories, "git shortlog" and other commands now read + mailmap files from the tip of the history, to help running these + tools in server settings. + + * Color specifiers, e.g. "%C(blue)Hello%C(reset)", used in the + "--format=" option of "git log" and friends can be disabled when + the output is not sent to a terminal by prefixing them with + "auto,", e.g. "%C(auto,blue)Hello%C(auto,reset)". + + * Scripts can ask Git that wildcard patterns in pathspecs they give do + not have any significance, i.e. take them as literal strings. + + * The patterns in .gitignore and .gitattributes files can have **/, + as a pattern that matches 0 or more levels of subdirectory. + E.g. "foo/**/bar" matches "bar" in "foo" itself or in a + subdirectory of "foo". + + * When giving arguments without "--" disambiguation, object names + that come earlier on the command line must not be interpretable as + pathspecs and pathspecs that come later on the command line must + not be interpretable as object names. This disambiguation rule has + been tweaked so that ":/" (no other string before or after) is + always interpreted as a pathspec; "git cmd -- :/" is no longer + needed, you can just say "git cmd :/". + + * Various "hint" lines Git gives when it asks the user to edit + messages in the editor are commented out with '#' by default. The + core.commentchar configuration variable can be used to customize + this '#' to a different character. + + * "git add -u" and "git add -A" without pathspec issues warning to + make users aware that they are only operating on paths inside the + subdirectory they are in. Use ":/" (everything from the top) or + "." (everything from the $cwd) to disambiguate. + + * "git blame" (and "git diff") learned the "--no-follow" option. + + * "git branch" now rejects some nonsense combinations of command line + arguments (e.g. giving more than one branch name to rename) with + more case-specific error messages. + + * "git check-ignore" command to help debugging .gitignore files has + been added. + + * "git cherry-pick" can be used to replay a root commit to an unborn + branch. + + * "git commit" can be told to use --cleanup=whitespace by setting the + configuration variable commit.cleanup to 'whitespace'. + + * "git diff" and other Porcelain commands can be told to use a + non-standard algorithm by setting diff.algorithm configuration + variable. + + * "git fetch --mirror" and fetch that uses other forms of refspec + with wildcard used to attempt to update a symbolic ref that match + the wildcard on the receiving end, which made little sense (the + real ref that is pointed at by the symbolic ref would be updated + anyway). Symbolic refs no longer are affected by such a fetch. + + * "git format-patch" now detects more cases in which a whole branch + is being exported, and uses the description for the branch, when + asked to write a cover letter for the series. + + * "git format-patch" learned "-v $count" option, and prepends a + string "v$count-" to the names of its output files, and also + automatically sets the subject prefix to "PATCH v$count". This + allows patches from rerolled series to be stored under different + names and makes it easier to reuse cover letter messages. + + * "git log" and friends can be told with --use-mailmap option to + rewrite the names and email addresses of people using the mailmap + mechanism. + + * "git log --cc --graph" now shows the combined diff output with the + ancestry graph. + + * "git log --grep=<pattern>" honors i18n.logoutputencoding to look + for the pattern after fixing the log message to the specified + encoding. + + * "git mergetool" and "git difftool" learned to list the available + tool backends in a more consistent manner. + + * "git mergetool" is aware of TortoiseGitMerge now and uses it over + TortoiseMerge when available. + + * "git push" now requires "-f" to update a tag, even if it is a + fast-forward, as tags are meant to be fixed points. + + * Error messages from "git push" when it stops to prevent remote refs + from getting overwritten by mistake have been improved to explain + various situations separately. + + * "git push" will stop without doing anything if the new "pre-push" + hook exists and exits with a failure. + + * When "git rebase" fails to generate patches to be applied (e.g. due + to oom), it failed to detect the failure and instead behaved as if + there were nothing to do. A workaround to use a temporary file has + been applied, but we probably would want to revisit this later, as + it hurts the common case of not failing at all. + + * Input and preconditions to "git reset" has been loosened where + appropriate. "git reset $fromtree Makefile" requires $fromtree to + be any tree (it used to require it to be a commit), for example. + "git reset" (without options or parameters) used to error out when + you do not have any commits in your history, but it now gives you + an empty index (to match non-existent commit you are not even on). + + * "git status" says what branch is being bisected or rebased when + able, not just "bisecting" or "rebasing". + + * "git submodule" started learning a new mode to integrate with the + tip of the remote branch (as opposed to integrating with the commit + recorded in the superproject's gitlink). + + * "git upload-pack" which implements the service "ls-remote" and + "fetch" talk to can be told to hide ref hierarchies the server + side internally uses (and that clients have no business learning + about) with transfer.hiderefs configuration. + + +Foreign Interface + + * "git fast-export" has been updated for its use in the context of + the remote helper interface. + + * A new remote helper to interact with bzr has been added to contrib/. + + * "git p4" got various bugfixes around its branch handling. It is + also made usable with Python 2.4/2.5. In addition, its various + portability issues for Cygwin have been addressed. + + * The remote helper to interact with Hg in contrib/ has seen a few + fixes. + + +Performance, Internal Implementation, etc. + + * "git fsck" has been taught to be pickier about entries in tree + objects that should not be there, e.g. ".", ".git", and "..". + + * Matching paths with common forms of pathspecs that contain wildcard + characters has been optimized further. + + * We stopped paying attention to $GIT_CONFIG environment that points + at a single configuration file from any command other than "git config" + quite a while ago, but "git clone" internally set, exported, and + then unexported the variable during its operation unnecessarily. + + * "git reset" internals has been reworked and should be faster in + general. We tried to be careful not to break any behaviour but + there could be corner cases, especially when running the command + from a conflicted state, that we may have missed. + + * The implementation of "imap-send" has been updated to reuse xml + quoting code from http-push codepath, and lost a lot of unused + code. + + * There is a simple-minded checker for the test scripts in t/ + directory to catch most common mistakes (it is not enabled by + default). + + * You can build with USE_WILDMATCH=YesPlease to use a replacement + implementation of pattern matching logic used for pathname-like + things, e.g. refnames and paths in the repository. This new + implementation is not expected change the existing behaviour of Git + in this release, except for "git for-each-ref" where you can now + say "refs/**/master" and match with both refs/heads/master and + refs/remotes/origin/master. We plan to use this new implementation + in wider places (e.g. "git ls-files '**/Makefile' may find Makefile + at the top-level, and "git log '**/t*.sh'" may find commits that + touch a shell script whose name begins with "t" at any level) in + future versions of Git, but we are not there yet. By building with + USE_WILDMATCH, using the resulting Git daily and reporting when you + find breakages, you can help us get closer to that goal. + + * Some reimplementations of Git do not write all the stat info back + to the index due to their implementation limitations (e.g. jgit). + A configuration option can tell Git to ignore changes to most of + the stat fields and only pay attention to mtime and size, which + these implementations can reliably update. This can be used to + avoid excessive revalidation of contents. + + * Some platforms ship with old version of expat where xmlparse.h + needs to be included instead of expat.h; the build procedure has + been taught about this. + + * "make clean" on platforms that cannot compute header dependencies + on the fly did not work with implementations of "rm" that do not + like an empty argument list. + +Also contains minor documentation updates and code clean-ups. + + +Fixes since v1.8.1 +------------------ + +Unless otherwise noted, all the fixes since v1.8.1 in the maintenance +track are contained in this release (see release notes to them for +details). + + * An element on GIT_CEILING_DIRECTORIES list that does not name the + real path to a directory (i.e. a symbolic link) could have caused + the GIT_DIR discovery logic to escape the ceiling. + + * When attempting to read the XDG-style $HOME/.config/git/config and + finding that $HOME/.config/git is a file, we gave a wrong error + message, instead of treating the case as "a custom config file does + not exist there" and moving on. + + * The behaviour visible to the end users was confusing, when they + attempt to kill a process spawned in the editor that was in turn + launched by Git with SIGINT (or SIGQUIT), as Git would catch that + signal and die. We ignore these signals now. + (merge 0398fc34 pf/editor-ignore-sigint later to maint). + + * A child process that was killed by a signal (e.g. SIGINT) was + reported in an inconsistent way depending on how the process was + spawned by us, with or without a shell in between. + + * After failing to create a temporary file using mkstemp(), failing + pathname was not reported correctly on some platforms. + + * We used to stuff "user@" and then append what we read from + /etc/mailname to come up with a default e-mail ident, but a bug + lost the "user@" part. + + * The attribute mechanism didn't allow limiting attributes to be + applied to only a single directory itself with "path/" like the + exclude mechanism does. The initial implementation of this that + was merged to 'maint' and 1.8.1.2 was with a severe performance + degradations and needs to merge a fix-up topic. + + * The smart HTTP clients forgot to verify the content-type that comes + back from the server side to make sure that the request is being + handled properly. + + * "git am" did not parse datestamp correctly from Hg generated patch, + when it is run in a locale outside C (or en). + + * "git apply" misbehaved when fixing whitespace breakages by removing + excess trailing blank lines. + + * "git apply --summary" has been taught to make sure the similarity + value shown in its output is sensible, even when the input had a + bogus value. + + * A tar archive created by "git archive" recorded a directory in a + way that made NetBSD's implementation of "tar" sometimes unhappy. + + * "git archive" did not record uncompressed size in the header when + streaming a zip archive, which confused some implementations of unzip. + + * "git archive" did not parse configuration values in tar.* namespace + correctly. + (merge b3873c3 jk/config-parsing-cleanup later to maint). + + * Attempt to "branch --edit-description" an existing branch, while + being on a detached HEAD, errored out. + + * "git clean" showed what it was going to do, but sometimes end up + finding that it was not allowed to do so, which resulted in a + confusing output (e.g. after saying that it will remove an + untracked directory, it found an embedded git repository there + which it is not allowed to remove). It now performs the actions + and then reports the outcome more faithfully. + + * When "git clone --separate-git-dir=$over_there" is interrupted, it + failed to remove the real location of the $GIT_DIR it created. + This was most visible when interrupting a submodule update. + + * "git cvsimport" mishandled timestamps at DST boundary. + + * We used to have an arbitrary 32 limit for combined diff input, + resulting in incorrect number of leading colons shown when showing + the "--raw --cc" output. + + * "git fetch --depth" was broken in at least three ways. The + resulting history was deeper than specified by one commit, it was + unclear how to wipe the shallowness of the repository with the + command, and documentation was misleading. + (merge cfb70e1 nd/fetch-depth-is-broken later to maint). + + * "git log --all -p" that walked refs/notes/textconv/ ref can later + try to use the textconv data incorrectly after it gets freed. + + * We forgot to close the file descriptor reading from "gpg" output, + killing "git log --show-signature" on a long history. + + * The way "git svn" asked for password using SSH_ASKPASS and + GIT_ASKPASS was not in line with the rest of the system. + + * The --graph code fell into infinite loop when asked to do what the + code did not expect. + + * http transport was wrong to ask for the username when the + authentication is done by certificate identity. + + * "git pack-refs" that ran in parallel to another process that + created new refs had a nasty race. + + * Rebasing the history of superproject with change in the submodule + has been broken since v1.7.12. + + * After "git add -N" and then writing a tree object out of the + index, the cache-tree data structure got corrupted. + + * "git clone" used to allow --bare and --separate-git-dir=$there + options at the same time, which was nonsensical. + + * "git rebase --preserve-merges" lost empty merges in recent versions + of Git. + + * "git merge --no-edit" computed who were involved in the work done + on the side branch, even though that information is to be discarded + without getting seen in the editor. + + * "git merge" started calling prepare-commit-msg hook like "git + commit" does some time ago, but forgot to pay attention to the exit + status of the hook. + + * A failure to push due to non-ff while on an unborn branch + dereferenced a NULL pointer when showing an error message. + + * When users spell "cc:" in lowercase in the fake "header" in the + trailer part, "git send-email" failed to pick up the addresses from + there. As e-mail headers field names are case insensitive, this + script should follow suit and treat "cc:" and "Cc:" the same way. + + * Output from "git status --ignored" showed an unexpected interaction + with "--untracked". + + * "gitweb", when sorting by age to show repositories with new + activities first, used to sort repositories with absolutely + nothing in it early, which was not very useful. + + * "gitweb"'s code to sanitize control characters before passing it to + "highlight" filter lost known-to-be-safe control characters by + mistake. + + * "gitweb" pages served over HTTPS, when configured to show picon or + gravatar, referred to these external resources to be fetched via + HTTP, resulting in mixed contents warning in browsers. + + * When a line to be wrapped has a solid run of non space characters + whose length exactly is the wrap width, "git shortlog -w" failed + to add a newline after such a line. + + * Command line completion leaked an unnecessary error message while + looking for possible matches with paths in <tree-ish>. + + * Command line completion for "tcsh" emitted an unwanted space + after completing a single directory name. + + * Command line completion code was inadvertently made incompatible with + older versions of bash by using a newer array notation. + + * "git push" was taught to refuse updating the branch that is + currently checked out long time ago, but the user manual was left + stale. + (merge 50995ed wk/man-deny-current-branch-is-default-these-days later to maint). + + * Some shells do not behave correctly when IFS is unset; work it + around by explicitly setting it to the default value. + + * Some scripted programs written in Python did not get updated when + PYTHON_PATH changed. + (cherry-pick 96a4647fca54031974cd6ad1 later to maint). + + * When autoconf is used, any build on a different commit always ran + "config.status --recheck" even when unnecessary. + + * A fix was added to the build procedure to work around buggy + versions of ccache broke the auto-generation of dependencies, which + unfortunately is still relevant because some people use ancient + distros. + + * The autoconf subsystem passed --mandir down to generated + config.mak.autogen but forgot to do the same for --htmldir. + (merge 55d9bf0 ct/autoconf-htmldir later to maint). + + * A change made on v1.8.1.x maintenance track had a nasty regression + to break the build when autoconf is used. + (merge 7f1b697 jn/less-reconfigure later to maint). + + * We have been carrying a translated and long-unmaintained copy of an + old version of the tutorial; removed. + + * t0050 had tests expecting failures from a bug that was fixed some + time ago. + + * t4014, t9502 and t0200 tests had various portability issues that + broke on OpenBSD. + + * t9020 and t3600 tests had various portability issues. + + * t9200 runs "cvs init" on a directory that already exists, but a + platform can configure this fail for the current user (e.g. you + need to be in the cvsadmin group on NetBSD 6.0). + + * t9020 and t9810 had a few non-portable shell script construct. + + * Scripts to test bash completion was inherently flaky as it was + affected by whatever random things the user may have on $PATH. + + * An element on GIT_CEILING_DIRECTORIES could be a "logical" pathname + that uses a symbolic link to point at somewhere else (e.g. /home/me + that points at /net/host/export/home/me, and the latter directory + is automounted). Earlier when Git saw such a pathname e.g. /home/me + on this environment variable, the "ceiling" mechanism did not take + effect. With this release (the fix has also been merged to the + v1.8.1.x maintenance series), elements on GIT_CEILING_DIRECTORIES + are by default checked for such aliasing coming from symbolic + links. As this needs to actually resolve symbolic links for each + element on the GIT_CEILING_DIRECTORIES, you can disable this + mechanism for some elements by listing them after an empty element + on the GIT_CEILING_DIRECTORIES. e.g. Setting /home/me::/home/him to + GIT_CEILING_DIRECTORIES makes Git resolve symbolic links in + /home/me when checking if the current directory is under /home/me, + but does not do so for /home/him. + (merge 7ec30aa mh/maint-ceil-absolute later to maint). diff --git a/Documentation/RelNotes/1.8.3.1.txt b/Documentation/RelNotes/1.8.3.1.txt new file mode 100644 index 000000000..fc3ea185a --- /dev/null +++ b/Documentation/RelNotes/1.8.3.1.txt @@ -0,0 +1,14 @@ +Git v1.8.3.1 Release Notes +======================== + +Fixes since v1.8.3 +------------------ + + * When $HOME is misconfigured to point at an unreadable directory, we + used to complain and die. The check has been loosened. + + * Handling of negative exclude pattern for directories "!dir" was + broken in the update to v1.8.3. + +Also contains a handful of trivial code clean-ups, documentation +updates, updates to the test suite, etc. diff --git a/Documentation/RelNotes/1.8.3.2.txt b/Documentation/RelNotes/1.8.3.2.txt new file mode 100644 index 000000000..26ae142c3 --- /dev/null +++ b/Documentation/RelNotes/1.8.3.2.txt @@ -0,0 +1,59 @@ +Git v1.8.3.2 Release Notes +========================== + +Fixes since v1.8.3.1 +-------------------- + + * Cloning with "git clone --depth N" while fetch.fsckobjects (or + transfer.fsckobjects) is set to true did not tell the cut-off + points of the shallow history to the process that validates the + objects and the history received, causing the validation to fail. + + * "git checkout foo" DWIMs the intended "upstream" and turns it into + "git checkout -t -b foo remotes/origin/foo". This codepath has been + updated to correctly take existing remote definitions into account. + + * "git fetch" into a shallow repository from a repository that does + not know about the shallow boundary commits (e.g. a different fork + from the repository the current shallow repository was cloned from) + did not work correctly. + + * "git subtree" (in contrib/) had one codepath with loose error + checks to lose data at the remote side. + + * "git log --ancestry-path A...B" did not work as expected, as it did + not pay attention to the fact that the merge base between A and B + was the bottom of the range being specified. + + * "git diff -c -p" was not showing a deleted line from a hunk when + another hunk immediately begins where the earlier one ends. + + * "git merge @{-1}~22" was rewritten to "git merge frotz@{1}~22" + incorrectly when your previous branch was "frotz" (it should be + rewritten to "git merge frotz~22" instead). + + * "git commit --allow-empty-message -m ''" should not start an + editor. + + * "git push --[no-]verify" was not documented. + + * An entry for "file://" scheme in the enumeration of URL types Git + can take in the HTML documentation was made into a clickable link + by mistake. + + * zsh prompt script that borrowed from bash prompt script did not + work due to slight differences in array variable notation between + these two shells. + + * The bash prompt code (in contrib/) displayed the name of the branch + being rebased when "rebase -i/-m/-p" modes are in use, but not the + plain vanilla "rebase". + + * "git push $there HEAD:branch" did not resolve HEAD early enough, so + it was easy to flip it around while push is still going on and push + out a branch that the user did not originally intended when the + command was started. + + * "difftool --dir-diff" did not copy back changes made by the + end-user in the diff tool backend to the working tree in some + cases. diff --git a/Documentation/RelNotes/1.8.3.3.txt b/Documentation/RelNotes/1.8.3.3.txt new file mode 100644 index 000000000..9ba4f4da0 --- /dev/null +++ b/Documentation/RelNotes/1.8.3.3.txt @@ -0,0 +1,47 @@ +Git v1.8.3.3 Release Notes +========================== + +Fixes since v1.8.3.2 +-------------------- + + * "git apply" parsed patches that add new files, generated by programs + other than Git, incorrectly. This is an old breakage in v1.7.11. + + * Older cURL wanted piece of memory we call it with to be stable, but + we updated the auth material after handing it to a call. + + * "git pull" into nothing trashed "local changes" that were in the + index. + + * Many "git submodule" operations did not work on a submodule at a + path whose name is not in ASCII. + + * "cherry-pick" had a small leak in its error codepath. + + * Logic used by git-send-email to suppress cc mishandled names like + "A U. Thor" <author@example.xz>, where the human readable part + needs to be quoted (the user input may not have the double quotes + around the name, and comparison was done between quoted and + unquoted strings). It also mishandled names that need RFC2047 + quoting. + + * "gitweb" forgot to clear a global variable $search_regexp upon each + request, mistakenly carrying over the previous search to a new one + when used as a persistent CGI. + + * The wildmatch engine did not honor WM_CASEFOLD option correctly. + + * "git log -c --follow $path" segfaulted upon hitting the commit that + renamed the $path being followed. + + * When a reflog notation is used for implicit "current branch", + e.g. "git log @{u}", we did not say which branch and worse said + "branch ''" in the error messages. + + * Mac OS X does not like to write(2) more than INT_MAX number of + bytes; work it around by chopping write(2) into smaller pieces. + + * Newer MacOS X encourages the programs to compile and link with + their CommonCrypto, not with OpenSSL. + +Also contains various minor documentation updates. diff --git a/Documentation/RelNotes/1.8.3.4.txt b/Documentation/RelNotes/1.8.3.4.txt new file mode 100644 index 000000000..56f106e26 --- /dev/null +++ b/Documentation/RelNotes/1.8.3.4.txt @@ -0,0 +1,20 @@ +Git v1.8.3.4 Release Notes +========================== + +This update is mostly to propagate documentation fixes and test +updates from the master front back to the maintenance track. + +Fixes since v1.8.3.3 +-------------------- + + * The bisect log listed incorrect commits when bisection ends with + only skipped ones. + + * The test coverage framework was left broken for some time. + + * The test suite for HTTP transport did not run with Apache 2.4. + + * "git diff" used to fail when core.safecrlf is set and the working + tree contents had mixed CRLF/LF line endings. Committing such a + content must be prohibited, but "git diff" should help the user to + locate and fix such problems without failing. diff --git a/Documentation/RelNotes/1.8.3.txt b/Documentation/RelNotes/1.8.3.txt new file mode 100644 index 000000000..ead568e7f --- /dev/null +++ b/Documentation/RelNotes/1.8.3.txt @@ -0,0 +1,436 @@ +Git v1.8.3 Release Notes +======================== + +Backward compatibility notes (for Git 2.0) +------------------------------------------ + +When "git push [$there]" does not say what to push, we have used the +traditional "matching" semantics so far (all your branches were sent +to the remote as long as there already are branches of the same name +over there). In Git 2.0, the default will change to the "simple" +semantics that pushes only the current branch to the branch with the same +name, and only when the current branch is set to integrate with that +remote branch. Use the user preference configuration variable +"push.default" to change this. If you are an old-timer who is used +to the "matching" semantics, you can set the variable to "matching" +to keep the traditional behaviour. If you want to live in the future +early, you can set it to "simple" today without waiting for Git 2.0. + +When "git add -u" (and "git add -A") is run inside a subdirectory and +does not specify which paths to add on the command line, it +will operate on the entire tree in Git 2.0 for consistency +with "git commit -a" and other commands. There will be no +mechanism to make plain "git add -u" behave like "git add -u .". +Current users of "git add -u" (without a pathspec) should start +training their fingers to explicitly say "git add -u ." +before Git 2.0 comes. A warning is issued when these commands are +run without a pathspec and when you have local changes outside the +current directory, because the behaviour in Git 2.0 will be different +from today's version in such a situation. + +In Git 2.0, "git add <path>" will behave as "git add -A <path>", so +that "git add dir/" will notice paths you removed from the directory +and record the removal. Versions before Git 2.0, including this +release, will keep ignoring removals, but the users who rely on this +behaviour are encouraged to start using "git add --ignore-removal <path>" +now before 2.0 is released. + + +Updates since v1.8.2 +-------------------- + +Foreign interface + + * remote-hg and remote-bzr helpers (in contrib/ since v1.8.2) have + been updated; especially, the latter has been done in an + accelerated schedule (read: we may not have merged to this release + if we were following the usual "cook sufficiently in next before + unleashing it to the world" workflow) in order to help Emacs folks, + whose primary SCM seems to be stagnating. + + +UI, Workflows & Features + + * A handful of updates applied to gitk, including an addition of + "revert" action, showing dates in tags in a nicer way, making + colors configurable, and support for -G'pickaxe' search. + + * The prompt string generator (in contrib/completion/) learned to + show how many changes there are in total and how many have been + replayed during a "git rebase" session. + + * "git branch --vv" learned to paint the name of the branch it + integrates with in a different color (color.branch.upstream, + which defaults to blue). + + * In a sparsely populated working tree, "git checkout <pathspec>" no + longer unmarks paths that match the given pathspec that were + originally ignored with "--sparse" (use --ignore-skip-worktree-bits + option to resurrect these paths out of the index if you really want + to). + + * "git log --format" specifier learned %C(auto) token that tells Git + to use color when interpolating %d (decoration), %h (short commit + object name), etc. for terminal output. + + * "git bisect" leaves the final outcome as a comment in its bisect + log file. + + * "git clone --reference" can now refer to a gitfile "textual symlink" + that points at the real location of the repository. + + * "git count-objects" learned "--human-readable" aka "-H" option to + show various large numbers in Ki/Mi/GiB scaled as necessary. + + * "git cherry-pick $blob" and "git cherry-pick $tree" are nonsense, + and a more readable error message e.g. "can't cherry-pick a tree" + is given (we used to say "expected exactly one commit"). + + * The "--annotate" option to "git send-email" can be turned on (or + off) by default with sendemail.annotate configuration variable (you + can use --no-annotate from the command line to override it). + + * The "--cover-letter" option to "git format-patch" can be turned on + (or off) by default with format.coverLetter configuration + variable. By setting it to 'auto', you can turn it on only for a + series with two or more patches. + + * The bash completion support (in contrib/) learned that cherry-pick + takes a few more options than it already knew about. + + * "git help" learned "-g" option to show the list of guides just like + list of commands are given with "-a". + + * A triangular "pull from one place, push to another place" workflow + is supported better by new remote.pushdefault (overrides the + "origin" thing) and branch.*.pushremote (overrides the + branch.*.remote) configuration variables. + + * "git status" learned to report that you are in the middle of a + revert session, just like it does for a cherry-pick and a bisect + session. + + * The handling by "git branch --set-upstream-to" against various forms + of erroneous inputs was suboptimal and has been improved. + + * When the interactive access to git-shell is not enabled, it issues + a message meant to help the system administrator to enable it. An + explicit way has been added to issue custom messages to refuse an + access over the network to help the end users who connect to the + service expecting an interactive shell. + + * In addition to the case where the user edits the log message with + the "e)dit" option of "am -i", replace the "Applying: this patch" + message with the final log message contents after applymsg hook + munges it. + + * "git status" suggests users to look into using --untracked=no option + when it takes too long. + + * "git status" shows a bit more information during a rebase/bisect + session. + + * "git fetch" learned to fetch a commit at the tip of an unadvertised + ref by specifying a raw object name from the command line when the + server side supports this feature. + + * Output from "git log --graph" works better with submodule log + output now. + + * "git count-objects -v" learned to report leftover temporary + packfiles and other garbage in the object store. + + * A new read-only credential helper (in contrib/) to interact with + the .netrc/.authinfo files has been added. + + * "git send-email" can be used with the credential helper system. + + * There was no Porcelain way to say "I no longer am interested in + this submodule", once you express your interest in a submodule with + "submodule init". "submodule deinit" is the way to do so. + + * "git pull --rebase" learned to pass "-v/-q" options to underlying + "git rebase". + + * The new "--follow-tags" option tells "git push" to push relevant + annotated tags when pushing branches out. + + * "git merge" and "git pull" can optionally be told to inspect and + reject when merging a commit that does not carry a trusted GPG + signature. + + * "git mergetool" now feeds files to the "p4merge" backend in the + order that matches the p4 convention, where "theirs" is usually + shown on the left side, which is the opposite from what other backends + expect. + + * "show/log" now honors gpg.program configuration just like other + parts of the code that use GnuPG. + + * "git log" that shows the difference between the parent and the + child has been optimized somewhat. + + * "git difftool" allows the user to write into the temporary files + being shown; if the user makes changes to the working tree at the + same time, it now refrains from overwriting the copy in the working + tree and leaves the temporary file so that changes can be merged + manually. + + * There was no good way to ask "I have a random string that came from + outside world. I want to turn it into a 40-hex object name while + making sure such an object exists". A new peeling suffix ^{object} + can be used for that purpose, together with "rev-parse --verify". + + +Performance, Internal Implementation, etc. + + * Updates for building under msvc. + + * A handful of issues in the code that traverses the working tree to find + untracked and/or ignored files have been fixed, and the general + codepath involved in "status -u" and "clean" have been cleaned up + and optimized. + + * The stack footprint of some codepaths that access an object from a + pack has been shrunk. + + * The logic to coalesce the same lines removed from the parents in + the output from "diff -c/--cc" has been updated, but with O(n^2) + complexity, so this might turn out to be undesirable. + + * The code to enforce permission bits on files in $GIT_DIR/ for + shared repositories has been simplified. + + * A few codepaths know how much data they need to put in the + hashtables they use when they start, but still began with small tables + and repeatedly grew and rehashed them. + + * The API to walk reflog entries from the latest to older, which was + necessary for operations such as "git checkout -", was cumbersome + to use correctly and also inefficient. + + * Codepaths that inspect log-message-to-be and decide when to add a + new Signed-off-by line in various commands have been consolidated. + + * The pkt-line API, implementation and its callers have been cleaned + up to make them more robust. + + * The Cygwin port has a faster-but-lying lstat(2) emulation whose + incorrectness does not matter in practice except for a few + codepaths, and setting permission bits on directories is a codepath + that needs to use a more correct one. + + * "git checkout" had repeated pathspec matches on the same paths, + which have been consolidated. Also a bug in "git checkout dir/" + that is started from an unmerged index has been fixed. + + * A few bugfixes to "git rerere" working on corner case merge + conflicts have been applied. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v1.8.2 +------------------ + +Unless otherwise noted, all the fixes since v1.8.2 in the maintenance +track are contained in this release (see release notes to them for +details). + + * Recent versions of File::Temp (used by "git svn") started blowing + up when its tempfile sub is called as a class method; updated the + callsite to call it as a plain vanilla function to fix it. + (merge eafc2dd hb/git-pm-tempfile later to maint). + + * Various subcommands of "git remote" simply ignored extraneous + command line arguments instead of diagnosing them as errors. + + * When receive-pack detects an error in the pack header it received in + order to decide which of unpack-objects or index-pack to run, it + returned without closing the error stream, which led to a hung + sideband thread. + + * Zsh completion forgot that the '%' character used to signal untracked + files needs to be escaped with another '%'. + + * A commit object whose author or committer ident are malformed + crashed some code that trusted that a name, an email and a + timestamp can always be found in it. + + * When "upload-pack" fails while generating a pack in response to + "git fetch" (or "git clone"), the receiving side had + a programming error that triggered the die handler + recursively. + + * "rev-list --stdin" and friends kept bogus pointers into the input + buffer around as human readable object names. This was not a huge + problem but was exposed by a new change that uses these names in + error output. + + * Smart-capable HTTP servers were not restricted via the + GIT_NAMESPACE mechanism when talking with commit-walking clients, + like they are when talking with smart HTTP clients. + (merge 6130f86 jk/http-dumb-namespaces later to maint). + + * "git merge-tree" did not omit a merge result that is identical to + the "our" side in certain cases. + (merge aacecc3 jk/merge-tree-added-identically later to maint). + + * Perl scripts like "git-svn" closed (instead of redirecting to /dev/null) + the standard error stream, which is not a very smart thing to do. + A later open may return file descriptor #2 for an unrelated purpose, and + error reporting code may write into it. + + * "git show-branch" was not prepared to show a very long run of + ancestor operators e.g. foobar^2~2^2^2^2...^2~4 correctly. + + * "git diff --diff-algorithm algo" is also understood as "git diff + --diff-algorithm=algo". + + * The new core.commentchar configuration was not applied in a few + places. + + * "git bundle" erroneously bailed out when parsing a valid bundle + containing a prerequisite commit without a commit message. + + * "git log -S/-G" started paying attention to textconv filter, but + there was no way to disable this. Make it honor the --no-textconv + option. + + * When used with the "-d temporary-directory" option, "git filter-branch" + failed to come back to the original working tree to perform the + final clean-up procedure. + + * "git merge $(git rev-parse v1.8.2)" behaved quite differently from + "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did + not pay much attention to the annotated tag payload. Make the code + notice the type of the tag object, in addition to the dwim_ref() + based classification the current code uses (i.e. the name appears + in refs/tags/) to decide when to special-case tag merging. + + * Fix a 1.8.1.x regression that stopped matching "dir" (without a + trailing slash) to a directory "dir". + + * "git apply --whitespace=fix" was not prepared to see a line getting + longer after fixing whitespaces (e.g. tab-in-indent aka Python). + + * The prompt string generator (in contrib/completion/) did not notice + when we are in a middle of a "git revert" session. + + * "submodule summary --summary-limit" option did not support the + "--option=value" form. + + * "index-pack --fix-thin" used an uninitialized value to compute + the delta depths of objects it appends to the resulting pack. + + * "index-pack --verify-stat" used a few counters outside the protection + of a mutex, possibly showing incorrect numbers. + + * The code to keep track of what directory names are known to Git on + platforms with case insensitive filesystems could get confused upon a + hash collision between these pathnames and would loop forever. + + * Annotated tags outside the refs/tags/ hierarchy were not advertised + correctly to ls-remote and fetch with recent versions of Git. + + * Recent optimizations broke shallow clones. + + * "git cmd -- ':(top'" was not diagnosed as an invalid syntax, and + instead the parser kept reading beyond the end of the string. + + * "git tag -f <tag>" always said "Updated tag '<tag>'" even when + creating a new tag (i.e. neither overwriting nor updating). + + * "git p4" did not behave well when the path to the root of the P4 + client was not its real path. + (merge bbd8486 pw/p4-symlinked-root later to maint). + + * "git archive" reported a failure when asked to create an archive out + of an empty tree. It is more intuitive to give an empty + archive back in such a case. + + * When "format-patch" quoted a non-ascii string in header files, + it incorrectly applied rfc2047 and chopped a single character in + the middle of the string. + + * An aliased command spawned from a bare repository that does not say + it is bare with "core.bare = yes" was treated as non-bare by mistake. + + * In "git reflog expire", the REACHABLE bit was not cleared from the + correct objects. + + * The logic used by "git diff -M --stat" to shorten the names of + files before and after a rename did not work correctly when the + common prefix and suffix between the two filenames overlapped. + + * The "--match=<pattern>" option of "git describe", when used with + "--all" to allow refs that are not annotated tags to be a + base of description, did not restrict the output from the command + to those refs that match the given pattern. + + * Clarify in the documentation "what" gets pushed to "where" when the + command line to "git push" does not say these explicitly. + + * The "--color=<when>" argument to the commands in the diff family + was described poorly. + + * The arguments given to the pre-rebase hook were not documented. + + * The v4 index format was not documented. + + * The "--match=<pattern>" argument "git describe" takes uses glob + pattern but it wasn't obvious from the documentation. + + * Some sources failed to compile on systems that lack NI_MAXHOST in + their system header (e.g. z/OS). + + * Add an example use of "--env-filter" in "filter-branch" + documentation. + + * "git bundle verify" did not say "records a complete history" for a + bundle that does not have any prerequisites. + + * In the v1.8.0 era, we changed symbols that do not have to be global + to file scope static, but a few functions in graph.c were used by + CGit sideways, bypassing the entry points of the API the + in-tree users use. + + * "git update-index -h" did not do the usual "-h(elp)" thing. + + * "git index-pack" had a buffer-overflow while preparing an + informational message when the translated version of it was too + long. + + * 'git commit -m "$msg"' used to add an extra newline even when + $msg already ended with one. + + * The SSL peer verification done by "git imap-send" did not ask for + Server Name Indication (RFC 4366), failing to connect to SSL/TLS + sites that serve multiple hostnames on a single IP. + + * perl/Git.pm::cat_blob slurped everything in core only to write it + out to a file descriptor, which was not a very smart thing to do. + + * "git branch" did not bother to check nonsense command line + parameters. It now issues errors in many cases. + + * Verification of signed tags was not done correctly when not in C + or en/US locale. + + * Some platforms and users spell UTF-8 differently; retry with the + most official "UTF-8" when the system does not understand the + user-supplied encoding name that is a common alternative + spelling of UTF-8. + + * When export-subst is used, "zip" output recorded an incorrect + size of the file. + + * "git am $maildir/" applied messages in an unexpected order; sort + filenames read from the maildir/ in a way that is more likely to + sort the messages in the order the writing MUA meant to, by sorting + numeric segments in numeric order and non-numeric segments in + alphabetical order. + + * "git submodule update", when recursed into sub-submodules, did not + accumulate the prefix paths. diff --git a/Documentation/RelNotes/1.8.4.1.txt b/Documentation/RelNotes/1.8.4.1.txt new file mode 100644 index 000000000..3aa25a274 --- /dev/null +++ b/Documentation/RelNotes/1.8.4.1.txt @@ -0,0 +1,71 @@ +Git v1.8.4.1 Release Notes +======================== + +Fixes since v1.8.4 +------------------ + + * Some old versions of bash do not grok some constructs like + 'printf -v varname' which the prompt and completion code started + to use recently. The completion and prompt scripts have been + adjusted to work better with these old versions of bash. + + * In FreeBSD's and NetBSD's "sh", a return in a dot script in a + function returns from the function, not only in the dot script, + breaking "git rebase" on these platforms (regression introduced + in 1.8.4-rc1). + + * "git rebase -i" and other scripted commands were feeding a + random, data dependant error message to 'echo' and expecting it + to come out literally. + + * Setting the "submodule.<name>.path" variable to the empty + "true" caused the configuration parser to segfault. + + * Output from "git log --full-diff -- <pathspec>" looked strange + because comparison was done with the previous ancestor that + touched the specified <pathspec>, causing the patches for paths + outside the pathspec to show more than the single commit has + changed. + + * The auto-tag-following code in "git fetch" tries to reuse the + same transport twice when the serving end does not cooperate and + does not give tags that point to commits that are asked for as + part of the primary transfer. Unfortunately, Git-aware transport + helper interface is not designed to be used more than once, hence + this did not work over smart-http transfer. Fixed. + + * Send a large request to read(2)/write(2) as a smaller but still + reasonably large chunks, which would improve the latency when the + operation needs to be killed and incidentally works around broken + 64-bit systems that cannot take a 2GB write or read in one go. + + * A ".mailmap" file that ends with an incomplete line, when read + from a blob, was not handled properly. + + * The recent "short-cut clone connectivity check" topic broke a + shallow repository when a fetch operation tries to auto-follow + tags. + + * When send-email comes up with an error message to die with upon + failure to start an SSL session, it tried to read the error + string from a wrong place. + + * A call to xread() was used without a loop to cope with short + read in the codepath to stream large blobs to a pack. + + * On platforms with fgetc() and friends defined as macros, the + configuration parser did not compile. + + * New versions of MediaWiki introduced a new API for returning + more than 500 results in response to a query, which would cause + the MediaWiki remote helper to go into an infinite loop. + + * Subversion's serf access method (the only one available in + Subversion 1.8) for http and https URLs in skelta mode tells its + caller to open multiple files at a time, which made "git svn + fetch" complain that "Temp file with moniker 'svn_delta' already + in use" instead of fetching. + + +Also contains a handful of trivial code clean-ups, documentation +updates, updates to the test suite, etc. diff --git a/Documentation/RelNotes/1.8.4.2.txt b/Documentation/RelNotes/1.8.4.2.txt new file mode 100644 index 000000000..9adccb1ef --- /dev/null +++ b/Documentation/RelNotes/1.8.4.2.txt @@ -0,0 +1,77 @@ +Git v1.8.4.2 Release Notes +======================== + +Fixes since v1.8.4.1 +-------------------- + + * "git clone" gave some progress messages to the standard output, not + to the standard error, and did not allow suppressing them with the + "--no-progress" option. + + * "format-patch --from=<whom>" forgot to omit unnecessary in-body + from line, i.e. when <whom> is the same as the real author. + + * "git shortlog" used to choke and die when there is a malformed + commit (e.g. missing authors); it now simply ignore such a commit + and keeps going. + + * "git merge-recursive" did not parse its "--diff-algorithm=" command + line option correctly. + + * "git branch --track" had a minor regression in v1.8.3.2 and later + that made it impossible to base your local work on anything but a + local branch of the upstream repository you are tracking from. + + * "git ls-files -k" needs to crawl only the part of the working tree + that may overlap the paths in the index to find killed files, but + shared code with the logic to find all the untracked files, which + made it unnecessarily inefficient. + + * When there is no sufficient overlap between old and new history + during a "git fetch" into a shallow repository, objects that the + sending side knows the receiving end has were unnecessarily sent. + + * When running "fetch -q", a long silence while the sender side + computes the set of objects to send can be mistaken by proxies as + dropped connection. The server side has been taught to send a + small empty messages to keep the connection alive. + + * When the webserver responds with "405 Method Not Allowed", "git + http-backend" should tell the client what methods are allowed with + the "Allow" header. + + * "git cvsserver" computed the permission mode bits incorrectly for + executable files. + + * The implementation of "add -i" has a crippling code to work around + ActiveState Perl limitation but it by mistake also triggered on Git + for Windows where MSYS perl is used. + + * We made sure that we notice the user-supplied GIT_DIR is actually a + gitfile, but did not do the same when the default ".git" is a + gitfile. + + * When an object is not found after checking the packfiles and then + loose object directory, read_sha1_file() re-checks the packfiles to + prevent racing with a concurrent repacker; teach the same logic to + has_sha1_file(). + + * "git commit --author=$name", when $name is not in the canonical + "A. U. Thor <au.thor@example.xz>" format, looks for a matching name + from existing history, but did not consult mailmap to grab the + preferred author name. + + * The commit object names in the insn sheet that was prepared at the + beginning of "rebase -i" session can become ambiguous as the + rebasing progresses and the repository gains more commits. Make + sure the internal record is kept with full 40-hex object names. + + * "git rebase --preserve-merges" internally used the merge machinery + and as a side effect, left merge summary message in the log, but + when rebasing, there should not be a need for merge summary. + + * "git rebase -i" forgot that the comment character can be + configurable while reading its insn sheet. + +Also contains a handful of trivial code clean-ups, documentation +updates, updates to the test suite, etc. diff --git a/Documentation/RelNotes/1.8.4.3.txt b/Documentation/RelNotes/1.8.4.3.txt new file mode 100644 index 000000000..03f3d1775 --- /dev/null +++ b/Documentation/RelNotes/1.8.4.3.txt @@ -0,0 +1,54 @@ +Git v1.8.4.3 Release Notes +======================== + +Fixes since v1.8.4.2 +-------------------- + + * The interaction between use of Perl in our test suite and NO_PERL + has been clarified a bit. + + * A fast-import stream expresses a pathname with funny characters by + quoting them in C style; remote-hg remote helper (in contrib/) + forgot to unquote such a path. + + * One long-standing flaw in the pack transfer protocol used by "git + clone" was that there was no way to tell the other end which branch + "HEAD" points at, and the receiving end needed to guess. A new + capability has been defined in the pack protocol to convey this + information so that cloning from a repository with more than one + branches pointing at the same commit where the HEAD is at now + reliably sets the initial branch in the resulting repository. + + * We did not handle cases where http transport gets redirected during + the authorization request (e.g. from http:// to https://). + + * "git rev-list --objects ^v1.0^ v1.0" gave v1.0 tag itself in the + output, but "git rev-list --objects v1.0^..v1.0" did not. + + * The fall-back parsing of commit objects with broken author or + committer lines were less robust than ideal in picking up the + timestamps. + + * Bash prompting code to deal with an SVN remote as an upstream + were coded in a way not supported by older Bash versions (3.x). + + * "git checkout topic", when there is not yet a local "topic" branch + but there is a unique remote-tracking branch for a remote "topic" + branch, pretended as if "git checkout -t -b topic remote/$r/topic" + (for that unique remote $r) was run. This hack however was not + implemented for "git checkout topic --". + + * Coloring around octopus merges in "log --graph" output was screwy. + + * We did not generate HTML version of documentation to "git subtree" + in contrib/. + + * The synopsis section of "git unpack-objects" documentation has been + clarified a bit. + + * An ancient How-To on serving Git repositories on an HTTP server + lacked a warning that it has been mostly superseded with more + modern way. + +Also contains a handful of trivial code clean-ups, documentation +updates, updates to the test suite, etc. diff --git a/Documentation/RelNotes/1.8.4.4.txt b/Documentation/RelNotes/1.8.4.4.txt new file mode 100644 index 000000000..7bc4c5dcc --- /dev/null +++ b/Documentation/RelNotes/1.8.4.4.txt @@ -0,0 +1,10 @@ +Git v1.8.4.4 Release Notes +======================== + +Fixes since v1.8.4.3 +-------------------- + + * The fix in v1.8.4.3 to the pack transfer protocol to propagate + the target of symbolic refs broke "git clone/git fetch" from a + repository with too many symbolic refs. As a hotfix/workaround, + we transfer only the information on HEAD. diff --git a/Documentation/RelNotes/1.8.4.5.txt b/Documentation/RelNotes/1.8.4.5.txt new file mode 100644 index 000000000..215bd1a7a --- /dev/null +++ b/Documentation/RelNotes/1.8.4.5.txt @@ -0,0 +1,13 @@ +Git v1.8.4.5 Release Notes +========================== + +Fixes since v1.8.4.4 +-------------------- + + * Recent update to remote-hg that attempted to make it work better + with non ASCII pathnames fed Unicode strings to the underlying Hg + API, which was wrong. + + * "git submodule init" copied "submodule.$name.update" settings from + .gitmodules to .git/config without making sure if the suggested + value was sensible. diff --git a/Documentation/RelNotes/1.8.4.txt b/Documentation/RelNotes/1.8.4.txt new file mode 100644 index 000000000..02f681b71 --- /dev/null +++ b/Documentation/RelNotes/1.8.4.txt @@ -0,0 +1,486 @@ +Git v1.8.4 Release Notes +======================== + +Backward compatibility notes (for Git 2.0) +------------------------------------------ + +When "git push [$there]" does not say what to push, we have used the +traditional "matching" semantics so far (all your branches were sent +to the remote as long as there already are branches of the same name +over there). In Git 2.0, the default will change to the "simple" +semantics that pushes: + + - only the current branch to the branch with the same name, and only + when the current branch is set to integrate with that remote + branch, if you are pushing to the same remote as you fetch from; or + + - only the current branch to the branch with the same name, if you + are pushing to a remote that is not where you usually fetch from. + +Use the user preference configuration variable "push.default" to +change this. If you are an old-timer who is used to the "matching" +semantics, you can set the variable to "matching" to keep the +traditional behaviour. If you want to live in the future early, you +can set it to "simple" today without waiting for Git 2.0. + +When "git add -u" (and "git add -A") is run inside a subdirectory and +does not specify which paths to add on the command line, it +will operate on the entire tree in Git 2.0 for consistency +with "git commit -a" and other commands. There will be no +mechanism to make plain "git add -u" behave like "git add -u .". +Current users of "git add -u" (without a pathspec) should start +training their fingers to explicitly say "git add -u ." +before Git 2.0 comes. A warning is issued when these commands are +run without a pathspec and when you have local changes outside the +current directory, because the behaviour in Git 2.0 will be different +from today's version in such a situation. + +In Git 2.0, "git add <path>" will behave as "git add -A <path>", so +that "git add dir/" will notice paths you removed from the directory +and record the removal. Versions before Git 2.0, including this +release, will keep ignoring removals, but the users who rely on this +behaviour are encouraged to start using "git add --ignore-removal <path>" +now before 2.0 is released. + + +Updates since v1.8.3 +-------------------- + +Foreign interfaces, subsystems and ports. + + * Cygwin port has been updated for more recent Cygwin 1.7. + + * "git rebase -i" now honors --strategy and -X options. + + * Git-gui has been updated to its 0.18.0 version. + + * MediaWiki remote helper (in contrib/) has been updated to use the + credential helper interface from Git.pm. + + * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that + this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it + ahead. + + * The credential helper to talk to keychain on OS X (in contrib/) has + been updated to kick in not just when talking http/https but also + imap(s) and smtp. + + * Remote transport helper has been updated to report errors and + maintain ref hierarchy used to keep track of its own state better. + + * With "export" remote-helper protocol, (1) a push that tries to + update a remote ref whose name is different from the pushing side + does not work yet, and (2) the helper may not know how to do + --dry-run; these problematic cases are disabled for now. + + * git-remote-hg/bzr (in contrib/) updates. + + * git-remote-mw (in contrib/) hints users to check the certificate, + when https:// connection failed. + + * git-remote-mw (in contrib/) adds a command to allow previewing the + contents locally before pushing it out, when working with a + MediaWiki remote. + + +UI, Workflows & Features + + * Sample "post-receive-email" hook script got an enhanced replacement + "multimail" (in contrib/). + + * Also in contrib/ is a new "contacts" script that runs "git blame" + to find out the people who may be interested in a set of changes. + + * "git clean" command learned an interactive mode. + + * The "--head" option to "git show-ref" was only to add "HEAD" to the + list of candidate refs to be filtered by the usual rules + (e.g. "--heads" that only show refs under refs/heads). The meaning + of the option has been changed to always show "HEAD" regardless of + what filtering will be applied to any other ref. + + This is a backward incompatible change and might cause breakages to + people's existing scripts. + + * "git show -s" was less discoverable than it should have been. It + now has a natural synonym "git show --no-patch". + + * "git check-mailmap" is a new command that lets you map usernames + and e-mail addresses through the mailmap mechanism, just like many + built-in commands do. + + * "git name-rev" learned to name an annotated tag object back to its + tagname; "git name-rev $(git rev-parse v1.0.0)" gives "tags/v1.0.0", + for example. + + * "git cat-file --batch-check=<format>" is added, primarily to allow + on-disk footprint of objects in packfiles (often they are a lot + smaller than their true size, when expressed as deltas) to be + reported. + + * "git rebase [-i]" used to leave just "rebase" as its reflog messages + for some operations. They have been reworded to be more informative. + + * In addition to the choice from "rebase, merge, or checkout-detach", + "submodule update" can allow a custom command to be used in to + update the working tree of submodules via the "submodule.*.update" + configuration variable. + + * "git submodule update" can optionally clone the submodule + repositories shallowly. + + * "git format-patch" learned "--from[=whom]" option, which sets the + "From: " header to the specified person (or the person who runs the + command, if "=whom" part is missing) and move the original author + information to an in-body From: header as necessary. + + * The configuration variable "merge.ff" was cleary a tri-state to + choose one from "favor fast-forward when possible", "always create + a merge even when the history could fast-forward" and "do not + create any merge, only update when the history fast-forwards", but + the command line parser did not implement the usual convention of + "last one wins, and command line overrides the configuration" + correctly. + + * "gitweb" learned to optionally place extra links that point at the + levels higher than the Gitweb pages themselves in the breadcrumbs, + so that it can be used as part of a larger installation. + + * "git log --format=" now honors i18n.logoutputencoding configuration + variable. + + * The "push.default=simple" mode of "git push" has been updated to + behave like "current" without requiring a remote tracking + information, when you push to a remote that is different from where + you fetch from (i.e. a triangular workflow). + + * Having multiple "fixup!" on a line in the rebase instruction sheet + did not work very well with "git rebase -i --autosquash". + + * "git log" learned the "--author-date-order" option, with which the + output is topologically sorted and commits in parallel histories + are shown intermixed together based on the author timestamp. + + * Various subcommands of "git submodule" refused to run from anywhere + other than the top of the working tree of the superproject, but + they have been taught to let you run from a subdirectory. + + * "git diff" learned a mode that ignores hunks whose change consists + only of additions and removals of blank lines, which is the same as + "diff -B" (ignore blank lines) of GNU diff. + + * "git rm" gives a single message followed by list of paths to report + multiple paths that cannot be removed. + + * "git rebase" can be told with ":/look for this string" syntax commits + to replay the changes onto and where the work to be replayed begins. + + * Many tutorials teach users to set "color.ui" to "auto" as the first + thing after you set "user.name/email" to introduce yourselves to + Git. Now the variable defaults to "auto". + + * On Cygwin, "cygstart" is now recognised as a possible way to start + a web browser (used in "help -w" and "instaweb" among others). + + * "git status" learned status.branch and status.short configuration + variables to use --branch and --short options by default (override + with --no-branch and --no-short options from the command line). + + * "git cmd <name>", when <name> happens to be a 40-hex string, + directly uses the 40-hex string as an object name, even if a ref + "refs/<some hierarchy>/<name>" exists. This disambiguation order + is unlikely to change, but we should warn about the ambiguity just + like we warn when more than one refs/ hierarchies share the same + name. + + * "git rebase" learned "--[no-]autostash" option to save local + changes instead of refusing to run (to which people's normal + response was to stash them and re-run). This introduced a corner + case breakage to "git am --abort" but it has been fixed. + + * "check-ignore" (new feature since 1.8.2) has been updated to work + more like "check-attr" over bidi-pipes. + + * "git describe" learned "--first-parent" option to limit its closest + tagged commit search to the first-parent chain. + + * "git merge foo" that might have meant "git merge origin/foo" is + diagnosed with a more informative error message. + + * "git log -L<line>,<range>:<filename>" has been added. This may + still have leaks and rough edges, though. + + * We used the approxidate() parser for "--expire=<timestamp>" options + of various commands, but it is better to treat --expire=all and + --expire=now a bit more specially than using the current timestamp. + "git gc" and "git reflog" have been updated with a new parsing + function for expiry dates. + + * Updates to completion (both bash and zsh) helpers. + + * The behaviour of the "--chain-reply-to" option of "git send-email" + have changed at 1.7.0, and we added a warning/advice message to + help users adjust to the new behaviour back then, but we kept it + around for too long. The message has finally been removed. + + * "git fetch origin master" unlike "git fetch origin" or "git fetch" + did not update "refs/remotes/origin/master"; this was an early + design decision to keep the update of remote tracking branches + predictable, but in practice it turns out that people find it more + convenient to opportunistically update them whenever we have a + chance, and we have been updating them when we run "git push" which + already breaks the original "predictability" anyway. + + * The configuration variable core.checkstat was advertised in the + documentation but the code expected core.statinfo instead. + For now, we accept both core.checkstat and core.statinfo, but the + latter will be removed in the longer term. + + +Performance, Internal Implementation, etc. + + * On Cygwin, we used to use our own lstat(2) emulation that is + allegedly faster than the platform one in codepaths where some of + the information it returns did not matter, but it started to bite + us in a few codepaths where the trick it uses to cheat does show + breakages. This emulation has been removed and we use the native + lstat(2) emulation supplied by Cygwin now. + + * The function attributes extensions are used to catch mistakes in + use of our own variadic functions that use NULL sentinel at the end + (i.e. like execl(3)) and format strings (i.e. like printf(3)). + + * The code to allow configuration data to be read from in-tree blob + objects is in. This may help working in a bare repository and + submodule updates. + + * Fetching between repositories with many refs employed O(n^2) + algorithm to match up the common objects, which has been corrected. + + * The original way to specify remote repository using .git/branches/ + used to have a nifty feature. The code to support the feature was + still in a function but the caller was changed not to call it 5 + years ago, breaking that feature and leaving the supporting code + unreachable. The dead code has been removed. + + * "git pack-refs" that races with new ref creation or deletion have + been susceptible to lossage of refs under right conditions, which + has been tightened up. + + * We read loose and packed references in two steps, but after + deciding to read a loose ref but before actually opening it to read + it, another process racing with us can unlink it, which would cause + us to barf. The codepath has been updated to retry when such a + race is detected, instead of outright failing. + + * Uses of the platform fnmatch(3) function (many places in the code, + matching pathspec, .gitignore and .gitattributes to name a few) + have been replaced with wildmatch, allowing "foo/**/bar" that would + match foo/bar, foo/a/bar, foo/a/b/bar, etc. + + * Memory ownership and lifetime rules for what for-each-ref feeds to + its callbacks have been clarified (in short, "you do not own it, so + make a copy if you want to keep it"). + + * The revision traversal logic to improve culling of irrelevant + parents while traversing a mergy history has been updated. + + * Some leaks in unpack-trees (used in merge, cherry-pick and other + codepaths) have been plugged. + + * The codepath to read from marks files in fast-import/export did not + have to accept anything but 40-hex representation of the object + name. Further, fast-export did not need full in-core object + representation to have parsed wen reading from them. These + codepaths have been optimized by taking advantage of these access + patterns. + + * Object lookup logic, when the object hashtable starts to become + crowded, has been optimized. + + * When TEST_OUTPUT_DIRECTORY setting is used, it was handled somewhat + inconsistently between the test framework and t/Makefile, and logic + to summarize the results looked at a wrong place. + + * "git clone" uses a lighter-weight implementation when making sure + that the history behind refs are complete. + + * Many warnings from sparse source checker in compat/ area has been + squelched. + + * The code to reading and updating packed-refs file has been updated, + correcting corner case bugs. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v1.8.3 +------------------ + +Unless otherwise noted, all the fixes since v1.8.3 in the maintenance +track are contained in this release (see release notes to them for +details). + + * Newer Net::SMTP::SSL module does not want the user programs to use + the default behaviour to let server certificate go without + verification, so by default enable the verification with a + mechanism to turn it off if needed. + (merge 35035bb rr/send-email-ssl-verify later to maint). + + * When "git" is spawned in such a way that any of the low 3 file + descriptors is closed, our first open() may yield file descriptor 2, + and writing error message to it would screw things up in a big way. + (merge a11c396 tr/protect-low-3-fds later to maint). + + * The mailmap mechanism unnecessarily downcased the e-mail addresses + in the output, and also ignored the human name when it is a single + character name. + (merge bd23794 jc/mailmap-case-insensitivity later to maint). + + * In two places we did not check return value (expected to be a file + descriptor) correctly. + (merge a77f106 tr/fd-gotcha-fixes later to maint). + + * Logic to auto-detect character encodings in the commit log message + did not reject overlong and invalid UTF-8 characters. + (merge 81050ac bc/commit-invalid-utf8 later to maint). + + * Pass port number as a separate argument when "send-email" initializes + Net::SMTP, instead of as a part of the hostname, i.e. host:port. + This allows GSSAPI codepath to match with the hostname given. + (merge 1a741bf bc/send-email-use-port-as-separate-param later to maint). + + * "git diff" refused to even show difference when core.safecrlf is + set to true (i.e. error out) and there are offending lines in the + working tree files. + (merge 5430bb2 jc/maint-diff-core-safecrlf later to maint). + + * A test that should have failed but didn't revealed a bug that needs + to be corrected. + (merge 94d75d1 jc/t1512-fix later to maint). + + * An overlong path to a .git directory may have overflown the + temporary path buffer used to create a name for lockfiles. + (merge 2fbd4f9 mh/maint-lockfile-overflow later to maint). + + * Invocations of "git checkout" used internally by "git rebase" were + counted as "checkout", and affected later "git checkout -" to the + the user to an unexpected place. + (merge 3bed291 rr/rebase-checkout-reflog later to maint). + + * The configuration variable column.ui was poorly documented. + (merge 5e62cc1 rr/column-doc later to maint). + + * "git name-rev --refs=tags/v*" were forbidden, which was a bit + inconvenient (you had to give a pattern to match refs fully, like + --refs=refs/tags/v*). + (merge 98c5c4a nk/name-rev-abbreviated-refs later to maint). + + * "git apply" parsed patches that add new files, generated by + programs other than Git, incorrectly. This is an old breakage in + v1.7.11 and will need to be merged down to the maintenance tracks. + + * Older cURL wanted piece of memory we call it with to be stable, but + we updated the auth material after handing it to a call. + + * "git pull" into nothing trashed "local changes" that were in the + index, and this avoids it. + + * Many "git submodule" operations do not work on a submodule at a + path whose name is not in ASCII. + + * "cherry-pick" had a small leak in an error codepath. + + * Logic used by git-send-email to suppress cc mishandled names like + "A U. Thor" <author@example.xz>, where the human readable part + needs to be quoted (the user input may not have the double quotes + around the name, and comparison was done between quoted and + unquoted strings). It also mishandled names that need RFC2047 + quoting. + + * Call to discard_cache/discard_index (used when we use different + contents of the index in-core, in many operations like commit, + apply, and merge) used to leak memory that held the array of index + entries, which has been plugged. + (merge a0fc4db rs/discard-index-discard-array later to maint). + + * "gitweb" forgot to clear a global variable $search_regexp upon each + request, mistakenly carrying over the previous search to a new one + when used as a persistent CGI. + + * The wildmatch engine did not honor WM_CASEFOLD option correctly. + + * "git log -c --follow $path" segfaulted upon hitting the commit that + renamed the $path being followed. + + * When a reflog notation is used for implicit "current branch", we + did not say which branch and worse said "branch ''". + + * "difftool --dir-diff" did not copy back changes made by the + end-user in the diff tool backend to the working tree in some + cases. + + * "git push $there HEAD:branch" did not resolve HEAD early enough, so + it was easy to flip it around while push is still going on and push + out a branch that the user did not originally intended when the + command was started. + + * The bash prompt code (in contrib/) displayed the name of the branch + being rebased when "rebase -i/-m/-p" modes are in use, but not the + plain vanilla "rebase". + + * Handling of negative exclude pattern for directories "!dir" was + broken in the update to v1.8.3. + + * zsh prompt script that borrowed from bash prompt script did not + work due to slight differences in array variable notation between + these two shells. + + * An entry for "file://" scheme in the enumeration of URL types Git + can take in the HTML documentation was made into a clickable link + by mistake. + + * "git push --[no-]verify" was not documented. + + * Stop installing the git-remote-testpy script that is only used for + testing. + + * "git commit --allow-empty-message -m ''" should not start an + editor. + + * "git merge @{-1}~22" was rewritten to "git merge frotz@{1}~22" + incorrectly when your previous branch was "frotz" (it should be + rewritten to "git merge frotz~22" instead). + + * "git diff -c -p" was not showing a deleted line from a hunk when + another hunk immediately begins where the earlier one ends. + + * "git log --ancestry-path A...B" did not work as expected, as it did + not pay attention to the fact that the merge base between A and B + was the bottom of the range being specified. + + * Mac OS X does not like to write(2) more than INT_MAX number of + bytes; work it around by chopping write(2) into smaller pieces. + + * Newer MacOS X encourages the programs to compile and link with + their CommonCrypto, not with OpenSSL. + + * "git clone foo/bar:baz" cannot be a request to clone from a remote + over git-over-ssh specified in the scp style. This case is now + detected and clones from a local repository at "foo/bar:baz". + + * When $HOME is misconfigured to point at an unreadable directory, we + used to complain and die. Loosen the check. + + * "git subtree" (in contrib/) had one codepath with loose error + checks to lose data at the remote side. + + * "git fetch" into a shallow repository from a repository that does + not know about the shallow boundary commits (e.g. a different fork + from the repository the current shallow repository was cloned from) + did not work correctly. + + * "git checkout foo" DWIMs the intended "upstream" and turns it into + "git checkout -t -b foo remotes/origin/foo". This codepath has been + updated to correctly take existing remote definitions into account. diff --git a/Documentation/RelNotes/1.8.5.1.txt b/Documentation/RelNotes/1.8.5.1.txt new file mode 100644 index 000000000..7236aaf23 --- /dev/null +++ b/Documentation/RelNotes/1.8.5.1.txt @@ -0,0 +1,9 @@ +Git v1.8.5.1 Release Notes +========================== + +Fixes since v1.8.5 +------------------ + + * "git submodule init" copied "submodule.$name.update" settings from + .gitmodules to .git/config without making sure if the suggested + value was sensible. diff --git a/Documentation/RelNotes/1.8.5.2.txt b/Documentation/RelNotes/1.8.5.2.txt new file mode 100644 index 000000000..3ac4984f1 --- /dev/null +++ b/Documentation/RelNotes/1.8.5.2.txt @@ -0,0 +1,20 @@ +Git v1.8.5.2 Release Notes +========================== + +Fixes since v1.8.5.1 +-------------------- + + * "git diff -- ':(icase)makefile'" was unnecessarily rejected at the + command line parser. + + * "git cat-file --batch-check=ok" did not check the existence of + the named object. + + * "git am --abort" sometimes complained about not being able to write + a tree with an 0{40} object in it. + + * Two processes creating loose objects at the same time could have + failed unnecessarily when the name of their new objects started + with the same byte value, due to a race condition. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/1.8.5.3.txt b/Documentation/RelNotes/1.8.5.3.txt new file mode 100644 index 000000000..3de2dd0f1 --- /dev/null +++ b/Documentation/RelNotes/1.8.5.3.txt @@ -0,0 +1,27 @@ +Git v1.8.5.3 Release Notes +========================== + +Fixes since v1.8.5.2 +-------------------- + + * The "--[no-]informative-errors" options to "git daemon" were parsed + a bit too loosely, allowing any other string after these option + names. + + * A "gc" process running as a different user should be able to stop a + new "gc" process from starting. + + * An earlier "clean-up" introduced an unnecessary memory leak to the + credential subsystem. + + * "git mv A B/", when B does not exist as a directory, should error + out, but it didn't. + + * "git rev-parse <revs> -- <paths>" did not implement the usual + disambiguation rules the commands in the "git log" family used in + the same way. + + * "git cat-file --batch=", an admittedly useless command, did not + behave very well. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/1.8.5.4.txt b/Documentation/RelNotes/1.8.5.4.txt new file mode 100644 index 000000000..d18c40389 --- /dev/null +++ b/Documentation/RelNotes/1.8.5.4.txt @@ -0,0 +1,48 @@ +Git v1.8.5.4 Release Notes +========================== + +Fixes since v1.8.5.3 +-------------------- + + * "git fetch --depth=0" was a no-op, and was silently ignored. + Diagnose it as an error. + + * Remote repository URL expressed in scp-style host:path notation are + parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks + to connect to user's home directory on host at address ::1. + + * SSL-related options were not passed correctly to underlying socket + layer in "git send-email". + + * "git commit -v" appends the patch to the log message before + editing, and then removes the patch when the editor returned + control. However, the patch was not stripped correctly when the + first modified path was a submodule. + + * "git mv A B/", when B does not exist as a directory, should error + out, but it didn't. + + * When we figure out how many file descriptors to allocate for + keeping packfiles open, a system with non-working getrlimit() could + cause us to die(), but because we make this call only to get a + rough estimate of how many is available and we do not even attempt + to use up all file descriptors available ourselves, it is nicer to + fall back to a reasonable low value rather than dying. + + * "git log --decorate" did not handle a tag pointed by another tag + nicely. + + * "git add -A" (no other arguments) in a totally empty working tree + used to emit an error. + + * There is no reason to have a hardcoded upper limit of the number of + parents for an octopus merge, created via the graft mechanism, but + there was. + + * The implementation of 'git stash $cmd "stash@{...}"' did not quote + the stash argument properly and left it split at IFS whitespace. + + * The documentation to "git pull" hinted there is an "-m" option + because it incorrectly shared the documentation with "git merge". + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/1.8.5.5.txt b/Documentation/RelNotes/1.8.5.5.txt new file mode 100644 index 000000000..9191ce948 --- /dev/null +++ b/Documentation/RelNotes/1.8.5.5.txt @@ -0,0 +1,37 @@ +Git v1.8.5.5 Release Notes +========================== + +Fixes since v1.8.5.4 +-------------------- + + * The pathspec matching code, while comparing two trees (e.g. "git + diff A B -- path1 path2") was too aggressive and failed to match + some paths when multiple pathspecs were involved. + + * "git repack --max-pack-size=8g" stopped being parsed correctly when + the command was reimplemented in C. + + * A recent update to "git send-email" broke platforms where + /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path + (e.g. Fedora rawhide). + + * A handful of bugs around interpreting $branch@{upstream} notation + and its lookalike, when $branch part has interesting characters, + e.g. "@", and ":", have been fixed. + + * "git clone" would fail to clone from a repository that has a ref + directly under "refs/", e.g. "refs/stash", because different + validation paths do different things on such a refname. Loosen the + client side's validation to allow such a ref. + + * "git log --left-right A...B" lost the "leftness" of commits + reachable from A when A is a tag as a side effect of a recent + bugfix. This is a regression in 1.8.4.x series. + + * "git merge-base --octopus" used to leave cleaning up suboptimal + result to the caller, but now it does the clean-up itself. + + * "git mv A B/", when B does not exist as a directory, should error + out, but it didn't. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/1.8.5.txt b/Documentation/RelNotes/1.8.5.txt new file mode 100644 index 000000000..602df0cac --- /dev/null +++ b/Documentation/RelNotes/1.8.5.txt @@ -0,0 +1,456 @@ +Git v1.8.5 Release Notes +======================== + +Backward compatibility notes (for Git 2.0) +------------------------------------------ + +When "git push [$there]" does not say what to push, we have used the +traditional "matching" semantics so far (all your branches were sent +to the remote as long as there already are branches of the same name +over there). In Git 2.0, the default will change to the "simple" +semantics, which pushes: + + - only the current branch to the branch with the same name, and only + when the current branch is set to integrate with that remote + branch, if you are pushing to the same remote as you fetch from; or + + - only the current branch to the branch with the same name, if you + are pushing to a remote that is not where you usually fetch from. + +Use the user preference configuration variable "push.default" to +change this. If you are an old-timer who is used to the "matching" +semantics, you can set the variable to "matching" to keep the +traditional behaviour. If you want to live in the future early, you +can set it to "simple" today without waiting for Git 2.0. + +When "git add -u" (and "git add -A") is run inside a subdirectory and +does not specify which paths to add on the command line, it +will operate on the entire tree in Git 2.0 for consistency +with "git commit -a" and other commands. There will be no +mechanism to make plain "git add -u" behave like "git add -u .". +Current users of "git add -u" (without a pathspec) should start +training their fingers to explicitly say "git add -u ." +before Git 2.0 comes. A warning is issued when these commands are +run without a pathspec and when you have local changes outside the +current directory, because the behaviour in Git 2.0 will be different +from today's version in such a situation. + +In Git 2.0, "git add <path>" will behave as "git add -A <path>", so +that "git add dir/" will notice paths you removed from the directory +and record the removal. Versions before Git 2.0, including this +release, will keep ignoring removals, but the users who rely on this +behaviour are encouraged to start using "git add --ignore-removal <path>" +now before 2.0 is released. + +The default prefix for "git svn" will change in Git 2.0. For a long +time, "git svn" created its remote-tracking branches directly under +refs/remotes, but it will place them under refs/remotes/origin/ unless +it is told otherwise with its --prefix option. + + +Updates since v1.8.4 +-------------------- + +Foreign interfaces, subsystems and ports. + + * "git-svn" has been taught to use the serf library, which is the + only option SVN 1.8.0 offers us when talking the HTTP protocol. + + * "git-svn" talking over an https:// connection using the serf library + dumped core due to a bug in the serf library that SVN uses. Work + around it on our side, even though the SVN side is being fixed. + + * On MacOS X, we detected if the filesystem needs the "pre-composed + unicode strings" workaround, but did not automatically enable it. + Now we do. + + * remote-hg remote helper misbehaved when interacting with a local Hg + repository relative to the home directory, e.g. "clone hg::~/there". + + * imap-send ported to OS X uses Apple's security framework instead of + OpenSSL's. + + * "git fast-import" treats an empty path given to "ls" as the root of + the tree. + + +UI, Workflows & Features + + * xdg-open can be used as a browser backend for "git web-browse" + (hence to show "git help -w" output), when available. + + * "git grep" and "git show" pay attention to the "--textconv" option + when these commands are told to operate on blob objects (e.g. "git + grep -e pattern --textconv HEAD:Makefile"). + + * "git replace" helper no longer allows an object to be replaced with + another object of a different type to avoid confusion (you can + still manually craft such a replacement using "git update-ref", as an + escape hatch). + + * "git status" no longer prints the dirty status information of + submodules for which submodule.$name.ignore is set to "all". + + * "git rebase -i" honours core.abbrev when preparing the insn sheet + for editing. + + * "git status" during a cherry-pick shows which original commit is + being picked. + + * Instead of typing four capital letters "HEAD", you can say "@" now, + e.g. "git log @". + + * "git check-ignore" follows the same rule as "git add" and "git + status" in that the ignore/exclude mechanism does not take effect + on paths that are already tracked. With the "--no-index" option, it + can be used to diagnose which paths that should have been ignored + have been mistakenly added to the index. + + * Some irrelevant "advice" messages that are shared with "git status" + output have been removed from the commit log template. + + * "update-refs" learned a "--stdin" option to read multiple update + requests and perform them in an all-or-none fashion. + + * Just like "make -C <directory>", "git -C <directory> ..." tells Git + to go there before doing anything else. + + * Just like "git checkout -" knows to check out, and "git merge -" + knows to merge, the branch you were previously on, "git cherry-pick" + now understands "git cherry-pick -" to pick from the previous + branch. + + * "git status" now omits the prefix to make its output a comment in a + commit log editor, which is not necessary for human consumption. + Scripts that parse the output of "git status" are advised to use + "git status --porcelain" instead, as its format is stable and easier + to parse. + + * The ref syntax "foo^{tag}" (with the literal string "{tag}") peels a + tag ref to itself, i.e. it's a no-op., and fails if + "foo" is not a tag. "git rev-parse --verify v1.0^{tag}" is + a more convenient way than "test $(git cat-file -t v1.0) = tag" to + check if v1.0 is a tag. + + * "git branch -v -v" (and "git status") did not distinguish among a + branch that is not based on any other branch, a branch that is in + sync with its upstream branch, and a branch that is configured with an + upstream branch that no longer exists. + + * Earlier we started rejecting any attempt to add the 0{40} object name to + the index and to tree objects, but it sometimes is necessary to + allow this to be able to use tools like filter-branch to correct such + broken tree objects. "filter-branch" can again be used to do this. + + * "git config" did not provide a way to set or access numbers larger + than a native "int" on the platform; it now provides 64-bit signed + integers on all platforms. + + * "git pull --rebase" always chose to do the bog-standard flattening + rebase. You can tell it to run "rebase --preserve-merges" with + "git pull --rebase=preserve" or by + setting "pull.rebase" configuration to "preserve". + + * "git push --no-thin" actually disables the "thin pack transfer" + optimization. + + * Magic pathspecs like ":(icase)makefile" (matches both Makefile + and makefile) and ":(glob)foo/**/bar" (matches "bar" in "foo" + and any subdirectory of "foo") can be used in more places. + + * The "http.*" variables can now be specified for individual URLs. + For example, + + [http] + sslVerify = true + [http "https://weak.example.com/"] + sslVerify = false + + would flip http.sslVerify off only when talking to that specific + site. + + * "git mv A B" when moving a submodule has been taught to + relocate the submodule's working tree and to adjust the paths in the + .gitmodules file. + + * "git blame" can now take more than one -L option to discover the + origin of multiple blocks of lines. + + * The http transport clients can optionally ask to save cookies + with the http.savecookies configuration variable. + + * "git push" learned a more fine grained control over a blunt + "--force" when requesting a non-fast-forward update with the + "--force-with-lease=<refname>:<expected object name>" option. + + * "git diff --diff-filter=<classes of changes>" can now take + lowercase letters (e.g. "--diff-filter=d") to mean "show + everything but these classes". "git diff-files -q" is now a + deprecated synonym for "git diff-files --diff-filter=d". + + * "git fetch" (hence "git pull" as well) learned to check + "fetch.prune" and "remote.*.prune" configuration variables and + to behave as if the "--prune" command line option was given. + + * "git check-ignore -z" applied the NUL termination to both its input + (with --stdin) and its output, but "git check-attr -z" ignored the + option on the output side. Make both honor -z on the input and + output side the same way. + + * "git whatchanged" may still be used by old timers, but mention of + it in documents meant for new users will only waste readers' time + wondering what the difference is between it and "git log". Make it + less prominent in the general part of the documentation and explain + that it is merely a "git log" with different default behaviour in + its own document. + + +Performance, Internal Implementation, etc. + + * "git for-each-ref" when asking for merely the object name does not + have to parse the object pointed at by the refs; the codepath has + been optimized. + + * The HTTP transport will try to use TCP keepalive when able. + + * "git repack" is now written in C. + + * Build procedure for MSVC has been updated. + + * If a build-time fallback is set to "cat" instead of "less", we + should apply the same "no subprocess or pipe" optimization as we + apply to user-supplied GIT_PAGER=cat. + + * Many commands use a --dashed-option as an operation mode selector + (e.g. "git tag --delete") that excludes other operation modes + (e.g. "git tag --delete --verify" is nonsense) and that cannot be + negated (e.g. "git tag --no-delete" is nonsense). The parse-options + API learned a new OPT_CMDMODE macro to make it easier to implement + such a set of options. + + * OPT_BOOLEAN() in the parse-options API was misdesigned to be "counting + up" but many subcommands expect it to behave as "on/off". Update + them to use OPT_BOOL() which is a proper boolean. + + * "git gc" exits early without doing any work when it detects + that another instance of itself is already running. + + * Under memory pressure and/or file descriptor pressure, we used to + close pack windows that are not used and also closed filehandles to + open but unused packfiles. These are now controlled separately + to better cope with the load. + +Also contains various documentation updates and code clean-ups. + + +Fixes since v1.8.4 +------------------ + +Unless otherwise noted, all the fixes since v1.8.4 in the maintenance +track are contained in this release (see the maintenance releases' notes for +details). + + * An ancient How-To on serving Git repositories on an HTTP server + lacked a warning that it has been mostly superseded with a more + modern way. + (merge 6d52bc3 sc/doc-howto-dumb-http later to maint). + + * The interaction between the use of Perl in our test suite and NO_PERL + has been clarified a bit. + (merge f8fc0ee jn/test-prereq-perl-doc later to maint). + + * The synopsis section of the "git unpack-objects" documentation has been + clarified a bit. + (merge 61e2e22 vd/doc-unpack-objects later to maint). + + * We did not generate the HTML version of the documentation to "git subtree" + in contrib/. + (merge 95c62fb jk/subtree-install-fix later to maint). + + * A fast-import stream expresses a pathname with funny characters by + quoting them in C style; the remote-hg remote helper forgot to unquote + such a path. + (merge 1136265 ap/remote-hg-unquote-cquote later to maint). + + * "git reset -p HEAD" has a codepath to special-case it to behave + differently from resetting to contents of other commits, but a + recent change broke it. + + * Coloring around octopus merges in "log --graph" output was screwy. + (merge 339c17b hn/log-graph-color-octopus later to maint). + + * "git checkout topic", when there is not yet a local "topic" branch + but there is a unique remote-tracking branch for a remote "topic" + branch, pretended as if "git checkout -t -b topic remote/$r/topic" + (for that unique remote $r) was run. This hack however was not + implemented for "git checkout topic --". + (merge bca3969 mm/checkout-auto-track-fix later to maint). + + * One long-standing flaw in the pack transfer protocol used by "git + clone" was that there was no way to tell the other end which branch + "HEAD" points at, and the receiving end needed to guess. A new + capability has been defined in the pack protocol to convey this + information so that cloning from a repository with more than one + branch pointing at the same commit where the HEAD is at now + reliably sets the initial branch in the resulting repository. + (merge 360a326 jc/upload-pack-send-symref later to maint). + + * We did not handle cases where the http transport gets redirected during + the authorization request (e.g. from http:// to https://). + (merge 70900ed jk/http-auth-redirects later to maint). + + * Bash prompting code to deal with an SVN remote as an upstream + was coded in a way unsupported by older Bash versions (3.x). + (merge 52ec889 sg/prompt-svn-remote-fix later to maint). + + * The fall-back parsing of commit objects with broken author or + committer lines was less robust than ideal in picking up the + timestamps. + (merge 03818a4 jk/split-broken-ident later to maint). + + * "git rev-list --objects ^v1.0^ v1.0" gave the v1.0 tag itself in the + output, but "git rev-list --objects v1.0^..v1.0" did not. + (merge 895c5ba jc/revision-range-unpeel later to maint). + + * "git clone" wrote some progress messages to standard output, not + to standard error, and did not suppress them with the + --no-progress option. + (merge 643f918 jk/clone-progress-to-stderr later to maint). + + * "format-patch --from=<whom>" forgot to omit an unnecessary in-body + from line, i.e. when <whom> is the same as the real author. + (merge 662cc30 jk/format-patch-from later to maint). + + * "git shortlog" used to choke and die when there is a malformed + commit (e.g. missing authors); it now simply ignores such a commit + and keeps going. + (merge cd4f09e jk/shortlog-tolerate-broken-commit later to maint). + + * "git merge-recursive" did not parse its "--diff-algorithm=" command + line option correctly. + (merge 6562928 jk/diff-algo later to maint). + + * When running "fetch -q", a long silence while the sender side + computes the set of objects to send can be mistaken by proxies as + dropped connection. The server side has been taught to send a + small empty messages to keep the connection alive. + (merge 115dedd jk/upload-pack-keepalive later to maint). + + * "git rebase" had a portability regression in v1.8.4 that triggered a + bug in some BSD shell implementations. + (merge 99855dd mm/rebase-continue-freebsd-WB later to maint). + + * "git branch --track" had a minor regression in v1.8.3.2 and later + that made it impossible to base your local work on anything but a + local branch of the upstream repository you are tracking. + (merge b0f49ff jh/checkout-auto-tracking later to maint). + + * When the web server responds with "405 Method Not Allowed", "git + http-backend" should tell the client what methods are allowed with + the "Allow" header. + (merge 9247be0 bc/http-backend-allow-405 later to maint). + + * When there is no sufficient overlap between old and new history + during a "git fetch" into a shallow repository, objects that the + sending side knows the receiving end has were unnecessarily sent. + (merge f21d2a7 nd/fetch-into-shallow later to maint). + + * "git cvsserver" computed the permission mode bits incorrectly for + executable files. + (merge 1b48d56 jc/cvsserver-perm-bit-fix later to maint). + + * When send-email obtains an error message to die with upon + failure to start an SSL session, it tried to read the error string + from a wrong place. + (merge 6cb0c88 bc/send-email-ssl-die-message-fix later to maint). + + * The implementation of "add -i" has some crippling code to work around an + ActiveState Perl limitation but it by mistake also triggered on Git + for Windows where MSYS perl is used. + (merge df17e77 js/add-i-mingw later to maint). + + * We made sure that we notice when the user-supplied GIT_DIR is actually a + gitfile, but did not do the same when the default ".git" is a + gitfile. + (merge 487a2b7 nd/git-dir-pointing-at-gitfile later to maint). + + * When an object is not found after checking the packfiles and the + loose object directory, read_sha1_file() re-checks the packfiles to + prevent racing with a concurrent repacker; teach the same logic to + has_sha1_file(). + (merge 45e8a74 jk/has-sha1-file-retry-packed later to maint). + + * "git commit --author=$name", when $name is not in the canonical + "A. U. Thor <au.thor@example.xz>" format, looks for a matching name + from existing history, but did not consult mailmap to grab the + preferred author name. + (merge ea16794 ap/commit-author-mailmap later to maint). + + * "git ls-files -k" needs to crawl only the part of the working tree + that may overlap the paths in the index to find killed files, but + shared code with the logic to find all the untracked files, which + made it unnecessarily inefficient. + (merge 680be04 jc/ls-files-killed-optim later to maint). + + * The shortened commit object names in the insn sheet that is prepared at the + beginning of a "rebase -i" session can become ambiguous as the + rebasing progresses and the repository gains more commits. Make + sure the internal record is kept with full 40-hex object names. + (merge 75c6976 es/rebase-i-no-abbrev later to maint). + + * "git rebase --preserve-merges" internally used the merge machinery + and as a side effect left the merge summary message in the log, but + when rebasing there is no need for the merge summary. + (merge a9f739c rt/rebase-p-no-merge-summary later to maint). + + * A call to xread() was used without a loop around it to cope with short + reads in the codepath to stream new contents to a pack. + (merge e92527c js/xread-in-full later to maint). + + * "git rebase -i" forgot that the comment character is + configurable while reading its insn sheet. + (merge 7bca7af es/rebase-i-respect-core-commentchar later to maint). + + * The mailmap support code read past the allocated buffer when the + mailmap file ended with an incomplete line. + (merge f972a16 jk/mailmap-incomplete-line later to maint). + + * We used to send a large request to read(2)/write(2) as a single + system call, which was bad from the latency point of view when + the operation needs to be killed, and also triggered an error on + broken 64-bit systems that refuse to read or write more than 2GB + in one go. + (merge a487916 sp/clip-read-write-to-8mb later to maint). + + * "git fetch" that auto-followed tags incorrectly reused the + connection with Git-aware transport helper (like the sample "ext::" + helper shipped with Git). + (merge 0f73f8b jc/transport-do-not-use-connect-twice-in-fetch later to maint). + + * "git log --full-diff -- <pathspec>" showed a huge diff for paths + outside the given <pathspec> for each commit, instead of showing + the change relative to the parent of the commit. "git reflog -p" + had a similar problem. + (merge 838f9a1 tr/log-full-diff-keep-true-parents later to maint). + + * Setting a submodule.*.path configuration variable to true (without + giving "= value") caused Git to segfault. + (merge 4b05440 jl/some-submodule-config-are-not-boolean later to maint). + + * "git rebase -i" (there could be others, as the root cause is pretty + generic) fed a random, data dependent string to 'echo' and + expected it to come out literally, corrupting its error message. + (merge 89b0230 mm/no-shell-escape-in-die-message later to maint). + + * Some people still use rather old versions of bash, which cannot + grok some constructs like 'printf -v varname' which the prompt and + completion code started to use recently. + (merge a44aa69 bc/completion-for-bash-3.0 later to maint). + + * Code to read configuration from a blob object did not compile on + platforms with fgetc() etc. implemented as macros. + (merge 49d6cfa hv/config-from-blob later to maint-1.8.3). + + * The recent "short-cut clone connectivity check" topic broke a + shallow repository when a fetch operation tries to auto-follow tags. + (merge 6da8bdc nd/fetch-pack-shallow-fix later to maint-1.8.3). diff --git a/Documentation/RelNotes/1.9.0.txt b/Documentation/RelNotes/1.9.0.txt new file mode 100644 index 000000000..752d79127 --- /dev/null +++ b/Documentation/RelNotes/1.9.0.txt @@ -0,0 +1,345 @@ +Git v1.9.0 Release Notes +======================== + +Backward compatibility notes +---------------------------- + +"git submodule foreach $cmd $args" used to treat "$cmd $args" the same +way "ssh" did, concatenating them into a single string and letting the +shell unquote. Careless users who forget to sufficiently quote $args +get their argument split at $IFS whitespaces by the shell, and got +unexpected results due to this. Starting from this release, the +command line is passed directly to the shell, if it has an argument. + +Read-only support for experimental loose-object format, in which users +could optionally choose to write their loose objects for a short +while between v1.4.3 and v1.5.3 era, has been dropped. + +The meanings of the "--tags" option to "git fetch" has changed; the +command fetches tags _in addition to_ what is fetched by the same +command line without the option. + +The way "git push $there $what" interprets the $what part given on the +command line, when it does not have a colon that explicitly tells us +what ref at the $there repository is to be updated, has been enhanced. + +A handful of ancient commands that have long been deprecated are +finally gone (repo-config, tar-tree, lost-found, and peek-remote). + + +Backward compatibility notes (for Git 2.0.0) +-------------------------------------------- + +When "git push [$there]" does not say what to push, we have used the +traditional "matching" semantics so far (all your branches were sent +to the remote as long as there already are branches of the same name +over there). In Git 2.0, the default will change to the "simple" +semantics, which pushes: + + - only the current branch to the branch with the same name, and only + when the current branch is set to integrate with that remote + branch, if you are pushing to the same remote as you fetch from; or + + - only the current branch to the branch with the same name, if you + are pushing to a remote that is not where you usually fetch from. + +Use the user preference configuration variable "push.default" to +change this. If you are an old-timer who is used to the "matching" +semantics, you can set the variable to "matching" to keep the +traditional behaviour. If you want to live in the future early, you +can set it to "simple" today without waiting for Git 2.0. + +When "git add -u" (and "git add -A") is run inside a subdirectory and +does not specify which paths to add on the command line, it +will operate on the entire tree in Git 2.0 for consistency +with "git commit -a" and other commands. There will be no +mechanism to make plain "git add -u" behave like "git add -u .". +Current users of "git add -u" (without a pathspec) should start +training their fingers to explicitly say "git add -u ." +before Git 2.0 comes. A warning is issued when these commands are +run without a pathspec and when you have local changes outside the +current directory, because the behaviour in Git 2.0 will be different +from today's version in such a situation. + +In Git 2.0, "git add <path>" will behave as "git add -A <path>", so +that "git add dir/" will notice paths you removed from the directory +and record the removal. Versions before Git 2.0, including this +release, will keep ignoring removals, but the users who rely on this +behaviour are encouraged to start using "git add --ignore-removal <path>" +now before 2.0 is released. + +The default prefix for "git svn" will change in Git 2.0. For a long +time, "git svn" created its remote-tracking branches directly under +refs/remotes, but it will place them under refs/remotes/origin/ unless +it is told otherwise with its --prefix option. + + +Updates since v1.8.5 +-------------------- + +Foreign interfaces, subsystems and ports. + + * The HTTP transport, when talking GSS-Negotiate, uses "100 + Continue" response to avoid having to rewind and resend a large + payload, which may not be always doable. + + * Various bugfixes to remote-bzr and remote-hg (in contrib/). + + * The build procedure is aware of MirBSD now. + + * Various "git p4", "git svn" and "gitk" updates. + + +UI, Workflows & Features + + * Fetching from a shallowly-cloned repository used to be forbidden, + primarily because the codepaths involved were not carefully vetted + and we did not bother supporting such usage. This release attempts + to allow object transfer out of a shallowly-cloned repository in a + more controlled way (i.e. the receiver becomes a shallow repository + with a truncated history). + + * Just like we give a reasonable default for "less" via the LESS + environment variable, we now specify a reasonable default for "lv" + via the "LV" environment variable when spawning the pager. + + * Two-level configuration variable names in "branch.*" and "remote.*" + hierarchies, whose variables are predominantly three-level, were + not completed by hitting a <TAB> in bash and zsh completions. + + * Fetching a 'frotz' branch with "git fetch", while a 'frotz/nitfol' + remote-tracking branch from an earlier fetch was still there, would + error out, primarily because the command was not told that it is + allowed to lose any information on our side. "git fetch --prune" + now can be used to remove 'frotz/nitfol' to make room for fetching and + storing the 'frotz' remote-tracking branch. + + * "diff.orderfile=<file>" configuration variable can be used to + pretend as if the "-O<file>" option were given from the command + line of "git diff", etc. + + * The negative pathspec syntax allows "git log -- . ':!dir'" to tell + us "I am interested in everything but 'dir' directory". + + * "git difftool" shows how many different paths there are in total, + and how many of them have been shown so far, to indicate progress. + + * "git push origin master" used to push our 'master' branch to update + the 'master' branch at the 'origin' repository. This has been + enhanced to use the same ref mapping "git push origin" would use to + determine what ref at the 'origin' to be updated with our 'master'. + For example, with this configuration + + [remote "origin"] + push = refs/heads/*:refs/review/* + + that would cause "git push origin" to push out our local branches + to corresponding refs under refs/review/ hierarchy at 'origin', + "git push origin master" would update 'refs/review/master' over + there. Alternatively, if push.default is set to 'upstream' and our + 'master' is set to integrate with 'topic' from the 'origin' branch, + running "git push origin" while on our 'master' would update their + 'topic' branch, and running "git push origin master" while on any + of our branches does the same. + + * "gitweb" learned to treat ref hierarchies other than refs/heads as + if they are additional branch namespaces (e.g. refs/changes/ in + Gerrit). + + * "git for-each-ref --format=..." learned a few formatting directives; + e.g. "%(color:red)%(HEAD)%(color:reset) %(refname:short) %(subject)". + + * The command string given to "git submodule foreach" is passed + directly to the shell, without being eval'ed. This is a backward + incompatible change that may break existing users. + + * "git log" and friends learned the "--exclude=<glob>" option, to + allow people to say "list history of all branches except those that + match this pattern" with "git log --exclude='*/*' --branches". + + * "git rev-parse --parseopt" learned a new "--stuck-long" option to + help scripts parse options with an optional parameter. + + * The "--tags" option to "git fetch" no longer tells the command to + fetch _only_ the tags. It instead fetches tags _in addition to_ + what are fetched by the same command line without the option. + + +Performance, Internal Implementation, etc. + + * When parsing a 40-hex string into the object name, the string is + checked to see if it can be interpreted as a ref so that a warning + can be given for ambiguity. The code kicked in even when the + core.warnambiguousrefs is set to false to squelch this warning, in + which case the cycles spent to look at the ref namespace were an + expensive no-op, as the result was discarded without being used. + + * The naming convention of the packfiles has been updated; it used to + be based on the enumeration of names of the objects that are + contained in the pack, but now it also depends on how the packed + result is represented---packing the same set of objects using + different settings (or delta order) would produce a pack with + different name. + + * "git diff --no-index" mode used to unnecessarily attempt to read + the index when there is one. + + * The deprecated parse-options macro OPT_BOOLEAN has been removed; + use OPT_BOOL or OPT_COUNTUP in new code. + + * A few duplicate implementations of prefix/suffix string comparison + functions have been unified to starts_with() and ends_with(). + + * The new PERLLIB_EXTRA makefile variable can be used to specify + additional directories Perl modules (e.g. the ones necessary to run + git-svn) are installed on the platform when building. + + * "git merge-base" learned the "--fork-point" mode, that implements + the same logic used in "git pull --rebase" to find a suitable fork + point out of the reflog entries for the remote-tracking branch the + work has been based on. "git rebase" has the same logic that can be + triggered with the "--fork-point" option. + + * A third-party "receive-pack" (the responder to "git push") can + advertise the "no-thin" capability to tell "git push" not to use + the thin-pack optimization. Our receive-pack has always been + capable of accepting and fattening a thin-pack, and will continue + not to ask "git push" to use a non-thin pack. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v1.8.5 +------------------ + +Unless otherwise noted, all the fixes since v1.8.5 in the maintenance +track are contained in this release (see the maintenance releases' notes +for details). + + * The pathspec matching code, while comparing two trees (e.g. "git + diff A B -- path1 path2") was too aggressive and failed to match + some paths when multiple pathspecs were involved. + + * "git repack --max-pack-size=8g" stopped being parsed correctly when + the command was reimplemented in C. + + * An earlier update in v1.8.4.x to "git rev-list --objects" with + negative ref had a performance regression. + (merge 200abe7 jk/mark-edges-uninteresting later to maint). + + * A recent update to "git send-email" broke platforms where + /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path + (e.g. Fedora rawhide). + + * A handful of bugs around interpreting $branch@{upstream} notation + and its lookalike, when $branch part has interesting characters, + e.g. "@", and ":", have been fixed. + + * "git clone" would fail to clone from a repository that has a ref + directly under "refs/", e.g. "refs/stash", because different + validation paths do different things on such a refname. Loosen the + client side's validation to allow such a ref. + + * "git log --left-right A...B" lost the "leftness" of commits + reachable from A when A is a tag as a side effect of a recent + bugfix. This is a regression in 1.8.4.x series. + + * documentations to "git pull" hinted there is an "-m" option because + it incorrectly shared the documentation with "git merge". + + * "git diff A B submod" and "git diff A B submod/" ought to have done + the same for a submodule "submod", but didn't. + + * "git clone $origin foo\bar\baz" on Windows failed to create the + leading directories (i.e. a moral-equivalent of "mkdir -p"). + + * "submodule.*.update=checkout", when propagated from .gitmodules to + .git/config, turned into a "submodule.*.update=none", which did not + make much sense. + (merge efa8fd7 fp/submodule-checkout-mode later to maint). + + * The implementation of 'git stash $cmd "stash@{...}"' did not quote + the stash argument properly and left it split at IFS whitespace. + + * The "--[no-]informative-errors" options to "git daemon" were parsed + a bit too loosely, allowing any other string after these option + names. + + * There is no reason to have a hardcoded upper limit for the number of + parents of an octopus merge, created via the graft mechanism, but + there was. + + * The basic test used to leave unnecessary trash directories in the + t/ directory. + (merge 738a8be jk/test-framework-updates later to maint). + + * "git merge-base --octopus" used to leave cleaning up suboptimal + result to the caller, but now it does the clean-up itself. + + * A "gc" process running as a different user should be able to stop a + new "gc" process from starting, but it didn't. + + * An earlier "clean-up" introduced an unnecessary memory leak. + + * "git add -A" (no other arguments) in a totally empty working tree + used to emit an error. + + * "git log --decorate" did not handle a tag pointed by another tag + nicely. + + * When we figure out how many file descriptors to allocate for + keeping packfiles open, a system with non-working getrlimit() could + cause us to die(), but because we make this call only to get a + rough estimate of how many are available and we do not even attempt + to use up all available file descriptors ourselves, it is nicer to + fall back to a reasonable low value rather than dying. + + * read_sha1_file(), that is the workhorse to read the contents given + an object name, honoured object replacements, but there was no + corresponding mechanism to sha1_object_info() that was used to + obtain the metainfo (e.g. type & size) about the object. This led + callers to weird inconsistencies. + (merge 663a856 cc/replace-object-info later to maint). + + * "git cat-file --batch=", an admittedly useless command, did not + behave very well. + + * "git rev-parse <revs> -- <paths>" did not implement the usual + disambiguation rules the commands in the "git log" family used in + the same way. + + * "git mv A B/", when B does not exist as a directory, should error + out, but it didn't. + + * A workaround to an old bug in glibc prior to glibc 2.17 has been + retired; this would remove a side effect of the workaround that + corrupts system error messages in non-C locales. + + * SSL-related options were not passed correctly to underlying socket + layer in "git send-email". + + * "git commit -v" appends the patch to the log message before + editing, and then removes the patch when the editor returned + control. However, the patch was not stripped correctly when the + first modified path was a submodule. + + * "git fetch --depth=0" was a no-op, and was silently ignored. + Diagnose it as an error. + + * Remote repository URLs expressed in scp-style host:path notation are + parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks + to connect to user's home directory on host at address ::1. + + * "git diff -- ':(icase)makefile'" was unnecessarily rejected at the + command line parser. + + * "git cat-file --batch-check=ok" did not check the existence of + the named object. + + * "git am --abort" sometimes complained about not being able to write + a tree with an 0{40} object in it. + + * Two processes creating loose objects at the same time could have + failed unnecessarily when the name of their new objects started + with the same byte value, due to a race condition. diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 0dbf2c984..e6d46edbe 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -1,65 +1,5 @@ -Checklist (and a short version for the impatient): - - Commits: - - - make commits of logical units - - check for unnecessary whitespace with "git diff --check" - before committing - - do not check in commented out code or unneeded files - - the first line of the commit message should be a short - description (50 characters is the soft limit, see DISCUSSION - in git-commit(1)), and should skip the full stop - - the body should provide a meaningful commit message, which: - . explains the problem the change tries to solve, iow, what - is wrong with the current code without the change. - . justifies the way the change solves the problem, iow, why - the result with the change is better. - . alternate solutions considered but discarded, if any. - - describe changes in imperative mood, e.g. "make xyzzy do frotz" - instead of "[This patch] makes xyzzy do frotz" or "[I] changed - xyzzy to do frotz", as if you are giving orders to the codebase - to change its behaviour. - - try to make sure your explanation can be understood without - external resources. Instead of giving a URL to a mailing list - archive, summarize the relevant points of the discussion. - - add a "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 - - make sure that you have tests for the bug you are fixing - - make sure that the test suite passes after your commit - - Patch: - - - use "git format-patch -M" to create the patch - - do not PGP sign your patch - - do not attach your patch, but read in the mail - body, unless you cannot teach your mailer to - leave the formatting of the patch alone. - - be careful doing cut & paste into your mailer, not to - corrupt whitespaces. - - provide additional information (which is unsuitable for - the commit message) between the "---" and the diffstat - - 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. - - see below for instructions specific to your mailer - -Long version: - -I started reading over the SubmittingPatches document for Linux -kernel, primarily because I wanted to have a document similar to -it for the core GIT to make sure people understand what they are -doing when they write "Signed-off-by" line. - -But the patch submission requirements are a lot more relaxed -here on the technical/contents front, because the core GIT is -thousand times smaller ;-). So here is only the relevant bits. +Here are some guidelines for people who want to contribute their code +to this software. (0) Decide what to base your work on. @@ -86,6 +26,10 @@ change is relevant to. wait until some of the dependent topics graduate to 'master', and rebase your work. + - Some parts of the system have dedicated maintainers with their own + repositories (see the section "Subsystems" below). Changes to + these parts should be based on their trees. + To find the tip of a topic branch, run "git log --first-parent master..pu" and look for the merge commit. The second parent of this commit is the tip of the topic branch. @@ -113,49 +57,101 @@ change, the approach taken by the change, and if relevant how this differs substantially from the prior version, are all good things to have. -Oh, another thing. I am picky about whitespaces. Make sure your +Make sure that you have tests for the bug you are fixing. + +When adding a new feature, make sure that you have new tests to show +the feature triggers the new behaviour when it should, and to show the +feature does not trigger when it shouldn't. Also make sure that the +test suite passes after your commit. Do not forget to update the +documentation to describe the updated behaviour. + +Speaking of the documentation, it is currently a liberal mixture of US +and UK English norms for spelling and grammar, which is somewhat +unfortunate. A huge patch that touches the files all over the place +only to correct the inconsistency is not welcome, though. Potential +clashes with other changes that can result from such a patch are not +worth it. We prefer to gradually reconcile the inconsistencies in +favor of US English, with small and easily digestible patches, as a +side effect of doing some other real work in the vicinity (e.g. +rewriting a paragraph for clarity, while turning en_UK spelling to +en_US). Obvious typographical fixes are much more welcomed ("teh -> +"the"), preferably submitted as independent patches separate from +other documentation changes. + +Oh, another thing. We are picky about whitespaces. Make sure your changes do not trigger errors with the sample pre-commit hook shipped in templates/hooks--pre-commit. To help ensure this does not happen, run git diff --check on your changes before you commit. -(1a) Try to be nice to older C compilers +(2) Describe your changes well. + +The first line of the commit message should be a short description (50 +characters is the soft limit, see DISCUSSION in git-commit(1)), and +should skip the full stop. It is also conventional in most cases to +prefix the first line with "area: " where the area is a filename or +identifier for the general area of the code being modified, e.g. + + . archive: ustar header checksum is computed unsigned + . git-cherry-pick.txt: clarify the use of revision range notation + +If in doubt which identifier to use, run "git log --no-merges" on the +files you are modifying to see the current conventions. + +The body should provide a meaningful commit message, which: + + . explains the problem the change tries to solve, iow, what is wrong + with the current code without the change. -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. + . justifies the way the change solves the problem, iow, why the + result with the change is better. -Also, variables have to be declared at the beginning of the block -(you can check this with gcc, using the -Wdeclaration-after-statement -option). + . alternate solutions considered but discarded, if any. -Another thing: NULL pointers shall be written as NULL, not as 0. +Describe your changes in imperative mood, e.g. "make xyzzy do frotz" +instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy +to do frotz", as if you are giving orders to the codebase to change +its behaviour. Try to make sure your explanation can be understood +without external resources. Instead of giving a URL to a mailing list +archive, summarize the relevant points of the discussion. -(2) Generate your patch using git tools out of your commits. +(3) Generate your patch using Git tools out of your commits. -git based diff tools generate unidiff which is the preferred format. +Git based diff tools generate unidiff which is the preferred format. You do not have to be afraid to use -M option to "git diff" or "git format-patch", if your patch involves file renames. The receiving end can handle them just fine. -Please make sure your patch does not include any extra files -which do not belong in a patch submission. Make sure to review +Please make sure your patch does not add commented out debugging code, +or include any extra files which do not relate to what your patch +is trying to achieve. Make sure to review your patch after generating it, to ensure accuracy. Before sending out, please make sure it cleanly applies to the "master" branch head. If you are preparing a work based on "next" branch, that is fine, but please mark it as such. -(3) Sending your patches. +(4) Sending your patches. -People on the git mailing list need to be able to read and +People on the Git mailing list need to be able to read and comment on the changes you are submitting. It is important for a developer to be able to "quote" your changes, using standard e-mail tools, so that they may comment on specific portions of -your code. For this reason, all patches should be submitted -"inline". WARNING: Be wary of your MUAs word-wrap +your code. For this reason, each patch should be submitted +"inline" in a separate message. + +Multiple related patches should be grouped into their own e-mail +thread to help readers find all parts of the series. To that end, +send them as replies to either an additional "cover letter" message +(see below), the first patch, or the respective preceding patch. + +If your log message (including your name on the +Signed-off-by line) is not writable in ASCII, make sure that +you send off a message in the correct encoding. + +WARNING: Be wary of your MUAs word-wrap corrupting your patch. Do not cut-n-paste your patch; you can lose tabs that way if you are not careful. @@ -179,7 +175,8 @@ message starts, you can put a "From: " line to name that person. You often want to add additional explanation about the patch, other than the commit message itself. Place such "cover letter" -material between the three dash lines and the diffstat. +material between the three dash lines and the diffstat. Git-notes +can also be inserted using the `--notes` option. Do not attach the patch as a MIME attachment, compressed or not. Do not let your e-mail client send quoted-printable. Do not let @@ -207,23 +204,29 @@ patch, format it as "multipart/signed", not a text/plain message that starts with '-----BEGIN PGP SIGNED MESSAGE-----'. That is not a text/plain, it's something else. -Unless your patch is a very trivial and an obviously correct one, -first send it with "To:" set to the mailing list, with "cc:" listing +Send your patch with "To:" set to the mailing list, with "cc:" listing people who are involved in the area you are touching (the output from "git blame $path" and "git shortlog --no-merges $path" would help to -identify them), to solicit comments and reviews. After the list -reached a consensus that it is a good idea to apply the patch, re-send -it with "To:" set to the maintainer and optionally "cc:" the list for -inclusion. Do not forget to add trailers such as "Acked-by:", -"Reviewed-by:" and "Tested-by:" after your "Signed-off-by:" line as -necessary. +identify them), to solicit comments and reviews. + +After the list reached a consensus that it is a good idea to apply the +patch, re-send it with "To:" set to the maintainer [*1*] and "cc:" the +list [*2*] for inclusion. + +Do not forget to add trailers such as "Acked-by:", "Reviewed-by:" and +"Tested-by:" lines as necessary to credit people who helped your +patch. + [Addresses] + *1* The current maintainer: gitster@pobox.com + *2* The mailing list: git@vger.kernel.org -(4) Sign your work + +(5) Sign your work To improve tracking of who did what, we've borrowed the "sign-off" procedure from the Linux kernel project on patches -that are being emailed around. Although core GIT is a lot +that are being emailed around. Although core Git is a lot smaller project it is a good discipline to follow it. The sign-off is a simple line at the end of the explanation for @@ -261,7 +264,7 @@ then you just add a line saying Signed-off-by: Random J Developer <random@developer.example.org> -This line can be automatically added by git if you run the git-commit +This line can be automatically added by Git if you run the git-commit command with the -s option. Notice that you can place your own Signed-off-by: line when @@ -290,6 +293,26 @@ You can also create your own tag or use one that's in common usage such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:". ------------------------------------------------ +Subsystems with dedicated maintainers + +Some parts of the system have dedicated maintainers with their own +repositories. + + - git-gui/ comes from git-gui project, maintained by Pat Thoyts: + + git://repo.or.cz/git-gui.git + + - gitk-git/ comes from Paul Mackerras's gitk project: + + git://ozlabs.org/~paulus/gitk + + - po/ comes from the localization coordinator, Jiang Xin: + + https://github.com/git-l10n/git-po/ + +Patches to these parts should be based on their trees. + +------------------------------------------------ An ideal patch flow Here is an ideal patch flow for this project the current maintainer @@ -334,7 +357,7 @@ Know the status of your patch after submission tell you if your patch is merged in pu if you rebase on top of master). -* Read the git mailing list, the maintainer regularly posts messages +* Read the Git mailing list, the maintainer regularly posts messages entitled "What's cooking in git.git" and "What's in git.git" giving the status of various proposed changes. diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf index aea8627be..2c16c536b 100644 --- a/Documentation/asciidoc.conf +++ b/Documentation/asciidoc.conf @@ -4,7 +4,7 @@ # # Note, {0} is the manpage section, while {target} is the command. # -# Show GIT link as: <command>(<section>); if section is defined, else just show +# Show Git link as: <command>(<section>); if section is defined, else just show # the command. [macros] @@ -36,7 +36,7 @@ ifndef::git-asciidoc-no-roff[] # v1.72 breaks with this because it replaces dots not in roff requests. [listingblock] <example><title>{title}</title> -<literallayout> +<literallayout class="monospaced"> ifdef::doctype-manpage[] .ft C endif::doctype-manpage[] @@ -53,7 +53,7 @@ ifdef::doctype-manpage[] # The following two small workarounds insert a simple paragraph after screen [listingblock] <example><title>{title}</title> -<literallayout> +<literallayout class="monospaced"> | </literallayout><simpara></simpara> {title#}</example> @@ -90,6 +90,8 @@ endif::backend-docbook[] endif::doctype-manpage[] ifdef::backend-xhtml11[] +[attributes] +git-relative-html-prefix= [linkgit-inlinemacro] -<a href="{target}.html">{target}{0?({0})}</a> +<a href="{git-relative-html-prefix}{target}.html">{target}{0?({0})}</a> endif::backend-xhtml11[] diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt index e76195ac9..0cebc4f69 100644 --- a/Documentation/blame-options.txt +++ b/Documentation/blame-options.txt @@ -10,27 +10,14 @@ Include additional statistics at the end of blame output. -L <start>,<end>:: - Annotate only the given line range. <start> and <end> can take - one of these forms: - - - number -+ -If <start> or <end> is a number, it specifies an -absolute line number (lines count from 1). -+ - -- /regex/ -+ -This form will use the first line matching the given -POSIX regex. If <end> is a regex, it will search -starting at the line given by <start>. -+ - -- +offset or -offset +-L :<regex>:: + Annotate only the given line range. May be specified multiple times. + Overlapping ranges are allowed. + -This is only valid for <end> and will specify a number -of lines before or after the line given by <start>. +<start> and <end> are optional. ``-L <start>'' or ``-L <start>,'' spans from +<start> to end of file. ``-L ,<end>'' spans from start of file to <end>. + +include::line-range-format.txt[] -l:: Show long rev (Default: off). @@ -95,7 +82,7 @@ of lines before or after the line given by <start>. running extra passes of inspection. + <num> is optional but it is the lower bound on the number of -alphanumeric characters that git must detect as moving/copying +alphanumeric characters that Git must detect as moving/copying within a file for it to associate those lines with the parent commit. The default value is 20. @@ -110,12 +97,11 @@ commit. The default value is 20. looks for copies from other files in any commit. + <num> is optional but it is the lower bound on the number of -alphanumeric characters that git must detect as moving/copying +alphanumeric characters that Git must detect as moving/copying between files for it to associate those lines with the parent commit. And the default value is 40. If there are more than one `-C` options given, the <num> argument of the last `-C` will take effect. -h:: ---help:: Show help message. diff --git a/Documentation/cat-texi.perl b/Documentation/cat-texi.perl index 828ec6255..87437f8a9 100755 --- a/Documentation/cat-texi.perl +++ b/Documentation/cat-texi.perl @@ -12,6 +12,7 @@ while (<STDIN>) { push @menu, $1; } s/\(\@pxref{\[(URLS|REMOTES)\]}\)//; + s/\@anchor\{[^{}]*\}//g; print TMP; } close TMP; diff --git a/Documentation/config.txt b/Documentation/config.txt index 27b57d226..7eec74695 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1,19 +1,20 @@ CONFIGURATION FILE ------------------ -The git configuration file contains a number of variables that affect -the git command's behavior. The `.git/config` file in each repository +The Git configuration file contains a number of variables that affect +the Git commands' behavior. The `.git/config` file in each repository is used to store the configuration for that repository, and `$HOME/.gitconfig` is used to store a per-user configuration as fallback values for the `.git/config` file. The file `/etc/gitconfig` can be used to store a system-wide default configuration. -The configuration variables are used by both the git plumbing +The configuration variables are used by both the Git plumbing and the porcelains. The variables are divided into sections, wherein the fully qualified variable name of the variable itself is the last dot-separated segment and the section name is everything before the last -dot. The variable names are case-insensitive and only alphanumeric -characters are allowed. Some variables may appear multiple times. +dot. The variable names are case-insensitive, allow only alphanumeric +characters and `-`, and must start with an alphabetic character. Some +variables may appear multiple times. Syntax ~~~~~~ @@ -45,17 +46,19 @@ lines. Variables may belong directly to a section or to a given subsection. You can have `[section]` if you have `[section "subsection"]`, but you don't need to. -There is also a case insensitive alternative `[section.subsection]` syntax. -In this syntax, subsection names follow the same restrictions as for section -names. +There is also a deprecated `[section.subsection]` syntax. With this +syntax, the subsection name is converted to lower-case and is also +compared case sensitively. These subsection names follow the same +restrictions as section names. All the other lines (and the remainder of the line after the section header) are recognized as setting variables, in the form 'name = value'. If there is no equal sign on the line, the entire line is taken as 'name' and the variable is recognized as boolean "true". -The variable names are case-insensitive and only alphanumeric -characters and `-` are allowed. There can be more than one value -for a given variable; we say then that variable is multivalued. +The variable names are case-insensitive, allow only alphanumeric characters +and `-`, and must start with an alphabetic character. There can be more +than one value for a given variable; we say then that the variable is +multivalued. Leading and trailing whitespace in a variable value is discarded. Internal whitespace within a variable value is retained verbatim. @@ -83,6 +86,19 @@ customary UNIX fashion. Some variables may require a special value format. +Includes +~~~~~~~~ + +You can include one config file from another by setting the special +`include.path` variable to the name of the file to be included. The +included file is expanded immediately, as if its contents had been +found at the location of the include directive. If the value of the +`include.path` variable is a relative path, the path is considered to be +relative to the configuration file in which the include directive was +found. The value of `include.path` is subject to tilde expansion: `~/` +is expanded to the value of `$HOME`, and `~user/` to the specified +user's home directory. See below for examples. + Example ~~~~~~~ @@ -105,6 +121,11 @@ Example gitProxy="ssh" for "kernel.org" gitProxy=default-proxy ; for the rest + [include] + path = /path/to/foo.inc ; include by absolute path + path = foo ; expand "foo" relative to the current file + path = ~/foo ; expand "foo" in your $HOME directory + Variables ~~~~~~~~~ @@ -114,62 +135,89 @@ in the appropriate manual page. You will find a description of non-core porcelain configuration variables in the respective porcelain documentation. advice.*:: - When set to 'true', display the given optional help message. - When set to 'false', do not display. The configuration variables - are: + These variables control various optional help messages designed to + aid new users. All 'advice.*' variables default to 'true', and you + can tell Git that you do not need help by setting these to 'false': + -- - pushNonFastForward:: - Advice shown when linkgit:git-push[1] refuses - non-fast-forward refs. Default: true. + pushUpdateRejected:: + Set this variable to 'false' if you want to disable + 'pushNonFFCurrent', 'pushNonFFDefault', + 'pushNonFFMatching', 'pushAlreadyExists', + 'pushFetchFirst', and 'pushNeedsForce' + simultaneously. + pushNonFFCurrent:: + Advice shown when linkgit:git-push[1] fails due to a + non-fast-forward update to the current branch. + pushNonFFDefault:: + Advice to set 'push.default' to 'upstream' or 'current' + when you ran linkgit:git-push[1] and pushed 'matching + refs' by default (i.e. you did not provide an explicit + refspec, and no 'push.default' configuration was set) + and it resulted in a non-fast-forward error. + pushNonFFMatching:: + Advice shown when you ran linkgit:git-push[1] and pushed + 'matching refs' explicitly (i.e. you used ':', or + specified a refspec that isn't your current branch) and + it resulted in a non-fast-forward error. + pushAlreadyExists:: + Shown when linkgit:git-push[1] rejects an update that + does not qualify for fast-forwarding (e.g., a tag.) + pushFetchFirst:: + Shown when linkgit:git-push[1] rejects an update that + tries to overwrite a remote ref that points at an + object we do not have. + pushNeedsForce:: + Shown when linkgit:git-push[1] rejects an update that + tries to overwrite a remote ref that points at an + object that is not a commit-ish, or make the remote + ref point at an object that is not a commit-ish. statusHints:: - Directions on how to stage/unstage/add shown in the - output of linkgit:git-status[1] and the template shown - when writing commit messages. Default: true. + Show directions on how to proceed from the current + state in the output of linkgit:git-status[1], in + the template shown when writing commit messages in + linkgit:git-commit[1], and in the help message shown + by linkgit:git-checkout[1] when switching branch. + statusUoption:: + Advise to consider using the `-u` option to linkgit:git-status[1] + when the command takes more than 2 seconds to enumerate untracked + files. commitBeforeMerge:: Advice shown when linkgit:git-merge[1] refuses to merge to avoid overwriting local changes. - Default: true. resolveConflict:: - Advices shown by various commands when conflicts + Advice shown by various commands when conflicts prevent the operation from being performed. - Default: true. implicitIdentity:: Advice on how to set your identity configuration when your information is guessed from the system username and - domain name. Default: true. - + domain name. detachedHead:: - Advice shown when you used linkgit::git-checkout[1] to + Advice shown when you used linkgit:git-checkout[1] to move to the detach HEAD state, to instruct how to create - a local branch after the fact. Default: true. + a local branch after the fact. + amWorkDir:: + Advice that shows the location of the patch file when + linkgit:git-am[1] fails to apply it. + rmHints:: + In case of failure in the output of linkgit:git-rm[1], + show directions on how to proceed from the current state. -- core.fileMode:: If false, the executable bit differences between the index and - the working copy are ignored; useful on broken filesystems like FAT. + the working tree are ignored; useful on broken filesystems like FAT. See linkgit:git-update-index[1]. + The default is true, except linkgit:git-clone[1] or linkgit:git-init[1] will probe and set core.fileMode false if appropriate when the repository is created. -core.ignoreCygwinFSTricks:: - This option is only used by Cygwin implementation of Git. If false, - the Cygwin stat() and lstat() functions are used. This may be useful - if your repository consists of a few separate directories joined in - one hierarchy using Cygwin mount. If true, Git uses native Win32 API - whenever it is possible and falls back to Cygwin functions only to - handle symbol links. The native mode is more than twice faster than - normal Cygwin l/stat() functions. True by default, unless core.filemode - is true, in which case ignoreCygwinFSTricks is ignored as Cygwin's - POSIX emulation is required to support core.filemode. - core.ignorecase:: If true, this option enables various workarounds to enable - git to work better on filesystems that are not case sensitive, + Git to work better on filesystems that are not case sensitive, like FAT. For example, if a directory listing finds - "makefile" when git expects "Makefile", git will assume + "makefile" when Git expects "Makefile", Git will assume it is really the same file, and continue to remember it as "Makefile". + @@ -177,13 +225,28 @@ The default is false, except linkgit:git-clone[1] or linkgit:git-init[1] will probe and set core.ignorecase true if appropriate when the repository is created. +core.precomposeunicode:: + This option is only used by Mac OS implementation of Git. + When core.precomposeunicode=true, Git reverts the unicode decomposition + of filenames done by Mac OS. This is useful when sharing a repository + between Mac OS and Linux or Windows. + (Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7). + When false, file names are handled fully transparent by Git, + which is backward compatible with older versions of Git. + core.trustctime:: If false, the ctime differences between the index and the - working copy are ignored; useful when the inode change time + working tree are ignored; useful when the inode change time is regularly modified by something outside Git (file system crawlers and some backup systems). See linkgit:git-update-index[1]. True by default. +core.checkstat:: + Determines which stat fields to match between the index + and work tree. The user can set this to 'default' or + 'minimal'. Default (or explicitly 'default'), is to check + all fields, including the sub-second part of mtime and ctime. + core.quotepath:: The commands that output paths (e.g. 'ls-files', 'diff'), when not given the `-z` option, will quote @@ -205,20 +268,20 @@ core.eol:: conversion. core.safecrlf:: - If true, makes git check if converting `CRLF` is reversible when + If true, makes Git check if converting `CRLF` is reversible when end-of-line conversion is active. Git will verify if a command modifies a file in the work tree either directly or indirectly. For example, committing a file followed by checking out the same file should yield the original file in the work tree. If this is not the case for the current setting of - `core.autocrlf`, git will reject the file. The variable can - be set to "warn", in which case git will only warn about an + `core.autocrlf`, Git will reject the file. The variable can + be set to "warn", in which case Git will only warn about an irreversible conversion but continue the operation. + CRLF conversion bears a slight chance of corrupting data. -When it is enabled, git will convert CRLF to LF during commit and LF to +When it is enabled, Git will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and -CRLF before the commit cannot be recreated by git. For text +CRLF before the commit cannot be recreated by Git. For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository. But for binary files that are accidentally classified as text the @@ -228,7 +291,7 @@ If you recognize such corruption early you can easily fix it by setting the conversion type explicitly in .gitattributes. Right after committing you still have the original file in your work tree and this file is not yet corrupted. You can explicitly tell -git that this file is binary and git will handle the file +Git that this file is binary and Git will handle the file appropriately. + Unfortunately, the desired effect of cleaning up text files with @@ -273,7 +336,7 @@ is created. core.gitProxy:: A "proxy command" to execute (as 'command host port') instead of establishing direct connection to the remote server when - using the git protocol for fetching. If the variable value is + using the Git protocol for fetching. If the variable value is in the "COMMAND for DOMAIN" format, the command is applied only on hostnames ending with the specified domain string. This variable may be set multiple times and is matched in the given order; @@ -292,7 +355,7 @@ core.ignoreStat:: If true, commands which modify both the working tree and the index will mark the updated paths with the "assume unchanged" bit in the index. These marked files are then assumed to stay unchanged in the - working copy, until you mark them otherwise manually - Git will not + working tree, until you mark them otherwise manually - Git will not detect the file changes by lstat() calls. This is useful on systems where those are very slow, such as Microsoft Windows. See linkgit:git-update-index[1]. @@ -332,7 +395,7 @@ Note that this variable is honored even when set in a configuration file in a ".git" subdirectory of a directory and its value differs from the latter directory (e.g. "/path/to/.git/config" has core.worktree set to "/different/path"), which is most likely a -misconfiguration. Running git commands in the "/path/to" directory will +misconfiguration. Running Git commands in the "/path/to" directory will still use "/different/path" as the root of the work tree and can cause confusion unless you know what you are doing (e.g. you are creating a read-only snapshot of the same index to a location different from the @@ -341,7 +404,7 @@ repository's usual working tree). core.logAllRefUpdates:: Enable the reflog. Updates to a ref <ref> is logged to the file "$GIT_DIR/logs/<ref>", by appending the new and old - SHA1, the date/time and the reason of the update, but + SHA-1, the date/time and the reason of the update, but only when the file exists. If this configuration variable is set to true, missing "$GIT_DIR/logs/<ref>" file is automatically created for branch heads (i.e. under @@ -364,7 +427,7 @@ core.sharedRepository:: several users in a group (making sure all the files and objects are group-writable). When 'all' (or 'world' or 'everybody'), the repository will be readable by all users, additionally to being - group-shareable. When 'umask' (or 'false'), git will use permissions + group-shareable. When 'umask' (or 'false'), Git will use permissions reported by umask(2). When '0xxx', where '0xxx' is an octal number, files in the repository will have this mode value. '0xxx' will override user's umask value (whereas the other options will only override @@ -375,8 +438,8 @@ core.sharedRepository:: See linkgit:git-init[1]. False by default. core.warnAmbiguousRefs:: - If true, git will warn you if the ref name you passed it is ambiguous - and might match multiple refs in the .git/refs/ tree. True by default. + If true, Git will warn you if the ref name you passed it is ambiguous + and might match multiple refs in the repository. True by default. core.compression:: An integer -1..9, indicating a default compression level. @@ -447,10 +510,12 @@ Common unit suffixes of 'k', 'm', or 'g' are supported. core.excludesfile:: In addition to '.gitignore' (per-directory) and - '.git/info/exclude', git looks into this file for patterns - of files which are not meant to be tracked. "{tilde}/" is expanded - to the value of `$HOME` and "{tilde}user/" to the specified user's - home directory. See linkgit:gitignore[5]. + '.git/info/exclude', Git looks into this file for patterns + of files which are not meant to be tracked. "`~/`" is expanded + to the value of `$HOME` and "`~user/`" to the specified user's + home directory. Its default value is $XDG_CONFIG_HOME/git/ignore. + If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore + is used instead. See linkgit:gitignore[5]. core.askpass:: Some commands (e.g. svn and http interfaces) that interactively @@ -463,9 +528,11 @@ core.askpass:: core.attributesfile:: In addition to '.gitattributes' (per-directory) and - '.git/info/attributes', git looks into this file for attributes + '.git/info/attributes', Git looks into this file for attributes (see linkgit:gitattributes[5]). Path expansions are made the same - way as for `core.excludesfile`. + way as for `core.excludesfile`. Its default value is + $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME is either not + set or empty, $HOME/.config/git/attributes is used instead. core.editor:: Commands such as `commit` and `tag` that lets you edit @@ -473,23 +540,37 @@ core.editor:: variable when it is set, and the environment variable `GIT_EDITOR` is not set. See linkgit:git-var[1]. +core.commentchar:: + Commands such as `commit` and `tag` that lets you edit + messages consider a line that begins with this character + commented, and removes them after the editor returns + (default '#'). + +sequence.editor:: + Text editor used by `git rebase -i` for editing the rebase instruction file. + The value is meant to be interpreted by the shell when it is used. + It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable. + When not configured the default commit message editor is used instead. + core.pager:: - The command that git will use to paginate output. Can - be overridden with the `GIT_PAGER` environment - variable. Note that git sets the `LESS` environment - variable to `FRSX` if it is unset when it runs the - pager. One can change these settings by setting the - `LESS` variable to some other value. Alternately, - these settings can be overridden on a project or - global basis by setting the `core.pager` option. - Setting `core.pager` has no affect on the `LESS` - environment variable behaviour above, so if you want - to override git's default settings this way, you need - to be explicit. For example, to disable the S option - in a backward compatible manner, set `core.pager` - to `less -+$LESS -FRX`. This will be passed to the - shell by git, which will translate the final command to - `LESS=FRSX less -+FRSX -FRX`. + Text viewer for use by Git commands (e.g., 'less'). The value + is meant to be interpreted by the shell. The order of preference + is the `$GIT_PAGER` environment variable, then `core.pager` + configuration, then `$PAGER`, and then the default chosen at + compile time (usually 'less'). ++ +When the `LESS` environment variable is unset, Git sets it to `FRSX` +(if `LESS` environment variable is set, Git does not change it at +all). If you want to selectively override Git's default setting +for `LESS`, you can set `core.pager` to e.g. `less -+S`. This will +be passed to the shell by Git, which will translate the final +command to `LESS=FRSX less -+S`. The environment tells the command +to set the `S` option to chop long lines but the command line +resets it to the default to fold long lines. ++ +Likewise, when the `LV` environment variable is unset, Git sets it +to `-c`. You can override this setting by exporting `LV` with +another value or setting `core.pager` to `lv +c`. core.whitespace:: A comma separated list of common whitespace problems to @@ -503,8 +584,9 @@ core.whitespace:: * `space-before-tab` treats a space character that appears immediately before a tab character in the initial indent part of the line as an error (enabled by default). -* `indent-with-non-tab` treats a line that is indented with 8 or more - space characters as an error (not enabled by default). +* `indent-with-non-tab` treats a line that is indented with space + characters instead of the equivalent tabs as an error (not enabled by + default). * `tab-in-indent` treats a tab character in the initial indent part of the line as an error (not enabled by default). * `blank-at-eof` treats blank lines added at the end of file as an error @@ -516,7 +598,7 @@ core.whitespace:: does not trigger if the character before such a carriage-return is not a whitespace (not enabled by default). * `tabwidth=<n>` tells how many character positions a tab occupies; this - is relevant for `indent-with-non-tab` and when git fixes `tab-in-indent` + is relevant for `indent-with-non-tab` and when Git fixes `tab-in-indent` errors. The default tab width is 8. Allowed values are 1 to 63. core.fsyncobjectfiles:: @@ -532,7 +614,7 @@ core.preloadindex:: + This can speed up operations like 'git diff' and 'git status' especially on filesystems like NFS that have weak caching semantics and thus -relatively high IO latencies. With this set to 'true', git will do the +relatively high IO latencies. With this set to 'true', Git will do the index comparison to the filesystem data in parallel, allowing overlapping IO's. @@ -568,9 +650,9 @@ add.ignore-errors:: add.ignoreErrors:: Tells 'git add' to continue adding files when some files cannot be added due to indexing errors. Equivalent to the '--ignore-errors' - option of linkgit:git-add[1]. Older versions of git accept only + option of linkgit:git-add[1]. Older versions of Git accept only `add.ignore-errors`, which does not follow the usual naming - convention for configuration variables. Newer versions of git + convention for configuration variables. Newer versions of Git honor `add.ignoreErrors` as well. alias.*:: @@ -578,7 +660,7 @@ alias.*:: after defining "alias.last = cat-file commit HEAD", the invocation "git last" is equivalent to "git cat-file commit HEAD". To avoid confusion and troubles with script usage, aliases that - hide existing git commands are ignored. Arguments are split by + hide existing Git commands are ignored. Arguments are split by spaces, the usual shell quoting and escaping is supported. quote pair and a backslash can be used to quote them. + @@ -625,7 +707,7 @@ branch.autosetupmerge:: branch.autosetuprebase:: When a new branch is created with 'git branch' or 'git checkout' - that tracks another branch, this variable tells git to set + that tracks another branch, this variable tells Git to set up pull to rebase instead of merge (see "branch.<name>.rebase"). When `never`, rebase is never automatically set to true. When `local`, rebase is set to true for tracked branches of @@ -639,9 +721,24 @@ branch.autosetuprebase:: This option defaults to never. branch.<name>.remote:: - When in branch <name>, it tells 'git fetch' and 'git push' which - remote to fetch from/push to. It defaults to `origin` if no remote is - configured. `origin` is also used if you are not on any branch. + When on branch <name>, it tells 'git fetch' and 'git push' + which remote to fetch from/push to. The remote to push to + may be overridden with `remote.pushdefault` (for all branches). + The remote to push to, for the current branch, may be further + overridden by `branch.<name>.pushremote`. If no remote is + configured, or if you are not on any branch, it defaults to + `origin` for fetching and `remote.pushdefault` for pushing. + Additionally, `.` (a period) is the current local repository + (a dot-repository), see `branch.<name>.merge`'s final note below. + +branch.<name>.pushremote:: + When on branch <name>, it overrides `branch.<name>.remote` for + pushing. It also overrides `remote.pushdefault` for pushing + from branch <name>. When you pull from one place (e.g. your + upstream) and push to another place (e.g. your own publishing + repository), you would want to set `remote.pushdefault` to + specify the remote to push to for all branches, and use this + option to override it for a specific branch. branch.<name>.merge:: Defines, together with branch.<name>.remote, the upstream branch @@ -658,8 +755,8 @@ branch.<name>.merge:: Specify multiple values to get an octopus merge. If you wish to setup 'git pull' so that it merges into <name> from another branch in the local repository, you can point - branch.<name>.merge to the desired branch, and use the special setting - `.` (a period) for branch.<name>.remote. + branch.<name>.merge to the desired branch, and use the relative path + setting `.` (a period) for branch.<name>.remote. branch.<name>.mergeoptions:: Sets default options for merging into branch <name>. The syntax and @@ -670,10 +767,22 @@ branch.<name>.mergeoptions:: branch.<name>.rebase:: When true, rebase the branch <name> on top of the fetched branch, instead of merging the default branch from the default remote when - "git pull" is run. - *NOTE*: this is a possibly dangerous operation; do *not* use - it unless you understand the implications (see linkgit:git-rebase[1] - for details). + "git pull" is run. See "pull.rebase" for doing this in a non + branch-specific manner. ++ + When preserve, also pass `--preserve-merges` along to 'git rebase' + so that locally committed merge commits will not be flattened + by running 'git pull'. ++ +*NOTE*: this is a possibly dangerous operation; do *not* use +it unless you understand the implications (see linkgit:git-rebase[1] +for details). + +branch.<name>.description:: + Branch description, can be edited with + `git branch --edit-description`. Branch description is + automatically added in the format-patch cover letter or + request-pull summary. browser.<tool>.cmd:: Specify the command to invoke the specified browser. The @@ -686,8 +795,8 @@ browser.<tool>.path:: working repository in gitweb (see linkgit:git-instaweb[1]). clean.requireForce:: - A boolean to make git-clean do nothing unless given -f - or -n. Defaults to true. + A boolean to make git-clean do nothing unless given -f, + -i or -n. Defaults to true. color.branch:: A boolean to enable/disable color in the output of @@ -698,7 +807,8 @@ color.branch:: color.branch.<slot>:: Use customized color for branch coloration. `<slot>` is one of `current` (the current branch), `local` (a local branch), - `remote` (a remote-tracking branch in refs/remotes/), `plain` (other + `remote` (a remote-tracking branch in refs/remotes/), + `upstream` (upstream tracking branch), `plain` (other refs). + The value for these configuration variables is a list of colors (at most @@ -766,16 +876,17 @@ The values of these variables may be specified as in color.branch.<slot>. color.interactive:: When set to `always`, always use colors for interactive prompts - and displays (such as those used by "git-add --interactive"). - When false (or `never`), never. When set to `true` or `auto`, use - colors only when the output is to the terminal. Defaults to false. + and displays (such as those used by "git-add --interactive" and + "git-clean --interactive"). When false (or `never`), never. + When set to `true` or `auto`, use colors only when the output is + to the terminal. Defaults to false. color.interactive.<slot>:: - Use customized color for 'git add --interactive' - output. `<slot>` may be `prompt`, `header`, `help` or `error`, for - four distinct types of normal output from interactive - commands. The values of these variables may be specified as - in color.branch.<slot>. + Use customized color for 'git add --interactive' and 'git clean + --interactive' output. `<slot>` may be `prompt`, `header`, `help` + or `error`, for four distinct types of normal output from + interactive commands. The values of these variables may be + specified as in color.branch.<slot>. color.pager:: A boolean to enable/disable colored output when the pager is in @@ -798,7 +909,7 @@ color.status.<slot>:: one of `header` (the header text of the status message), `added` or `updated` (files which are added but not committed), `changed` (files which are changed but not added in the index), - `untracked` (files which are not tracked by git), + `untracked` (files which are not tracked by Git), `branch` (the current branch), or `nobranch` (the color the 'no branch' warning is shown in, defaulting to red). The values of these variables may be specified as in @@ -809,11 +920,85 @@ color.ui:: as `color.diff` and `color.grep` that control the use of color per command family. Its scope will expand as more commands learn configuration to set a default for the `--color` option. Set it - to `always` if you want all output not intended for machine - consumption to use color, to `true` or `auto` if you want such - output to use color when written to the terminal, or to `false` or - `never` if you prefer git commands not to use color unless enabled - explicitly with some other configuration or the `--color` option. + to `false` or `never` if you prefer Git commands not to use + color unless enabled explicitly with some other configuration + or the `--color` option. Set it to `always` if you want all + output not intended for machine consumption to use color, to + `true` or `auto` (this is the default since Git 1.8.4) if you + want such output to use color when written to the terminal. + +column.ui:: + Specify whether supported commands should output in columns. + This variable consists of a list of tokens separated by spaces + or commas: ++ +These options control when the feature should be enabled +(defaults to 'never'): ++ +-- +`always`;; + always show in columns +`never`;; + never show in columns +`auto`;; + show in columns if the output is to the terminal +-- ++ +These options control layout (defaults to 'column'). Setting any +of these implies 'always' if none of 'always', 'never', or 'auto' are +specified. ++ +-- +`column`;; + fill columns before rows +`row`;; + fill rows before columns +`plain`;; + show in one column +-- ++ +Finally, these options can be combined with a layout option (defaults +to 'nodense'): ++ +-- +`dense`;; + make unequal size columns to utilize more space +`nodense`;; + make equal size columns +-- + +column.branch:: + Specify whether to output branch listing in `git branch` in columns. + See `column.ui` for details. + +column.clean:: + Specify the layout when list items in `git clean -i`, which always + shows files and directories in columns. See `column.ui` for details. + +column.status:: + Specify whether to output untracked files in `git status` in columns. + See `column.ui` for details. + +column.tag:: + Specify whether to output tag listing in `git tag` in columns. + See `column.ui` for details. + +commit.cleanup:: + This setting overrides the default of the `--cleanup` option in + `git commit`. See linkgit:git-commit[1] for details. Changing the + default can be useful when you always want to keep lines that begin + with comment character `#` in your log message, in which case you + would do `git config commit.cleanup whitespace` (note that you will + have to remove the help lines that begin with `#` in the commit log + template yourself, if you do this). + +commit.gpgsign:: + + A boolean to specify whether all commits should be GPG signed. + Use of this option when doing operations such as rebase can + result in a large number of commits being signed. It may be + convenient to use an agent to avoid typing your GPG passphrase + several times. commit.status:: A boolean to enable/disable inclusion of status information in the @@ -822,9 +1007,32 @@ commit.status:: commit.template:: Specify a file to use as the template for new commit messages. - "{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the + "`~/`" is expanded to the value of `$HOME` and "`~user/`" to the specified user's home directory. +credential.helper:: + Specify an external helper to be called when a username or + password credential is needed; the helper may consult external + storage to avoid prompting the user for the credentials. See + linkgit:gitcredentials[7] for details. + +credential.useHttpPath:: + When acquiring credentials, consider the "path" component of an http + or https URL to be important. Defaults to false. See + linkgit:gitcredentials[7] for more information. + +credential.username:: + If no username is set for a network authentication, use this username + by default. See credential.<context>.* below, and + linkgit:gitcredentials[7]. + +credential.<url>.*:: + Any of the credential.* options above can be applied selectively to + some credentials. For example "credential.https://example.com.username" + would set the default username only for https connections to + example.com. See linkgit:gitcredentials[7] for details on how URLs are + matched. + include::diff-config.txt[] difftool.<tool>.path:: @@ -842,12 +1050,6 @@ difftool.<tool>.cmd:: difftool.prompt:: Prompt before each invocation of the diff tool. -diff.wordRegex:: - A POSIX Extended Regular Expression used to determine what is a "word" - when performing word-by-word difference calculations. Character - sequences that match the regular expression are "words", all other - characters are *ignorable* whitespace. - fetch.recurseSubmodules:: This option can be either set to a boolean value or to 'on-demand'. Setting it to a boolean changes the behavior of fetch and pull to @@ -857,8 +1059,15 @@ fetch.recurseSubmodules:: when its superproject retrieves a commit that updates the submodule's reference. +fetch.fsckObjects:: + If it is set to true, git-fetch-pack will check all fetched + objects. It will abort in the case of a malformed object or a + broken link. The result of an abort are only dangling objects. + Defaults to false. If not set, the value of `transfer.fsckObjects` + is used instead. + fetch.unpackLimit:: - If the number of objects fetched over the git native + If the number of objects fetched over the Git native transfer is below this limit, then the objects will be unpacked into loose object files. However if the number of received objects equals or @@ -868,6 +1077,10 @@ fetch.unpackLimit:: especially on slow filesystems. If not set, the value of `transfer.unpackLimit` is used instead. +fetch.prune:: + If true, fetch will automatically behave as if the `--prune` + option was given on the command line. See also `remote.<name>.prune`. + format.attach:: Enable multipart/mixed attachments as the default for 'format-patch'. The value can also be a double quoted string @@ -898,7 +1111,7 @@ format.subjectprefix:: format.signature:: The default for format-patch is to output a signature containing - the git version number. Use this variable to change that default. + the Git version number. Use this variable to change that default. Set this variable to the empty string ("") to suppress signature generation. @@ -917,17 +1130,22 @@ format.thread:: a boolean value, or `shallow` or `deep`. `shallow` threading makes every mail a reply to the head of the series, where the head is chosen from the cover letter, the - `\--in-reply-to`, and the first patch mail, in this order. + `--in-reply-to`, and the first patch mail, in this order. `deep` threading makes every mail a reply to the previous one. A true boolean value is the same as `shallow`, and a false value disables threading. format.signoff:: - A boolean value which lets you enable the `-s/--signoff` option of - format-patch by default. *Note:* Adding the Signed-off-by: line to a - patch should be a conscious act and means that you certify you have - the rights to submit this work under the same open source license. - Please see the 'SubmittingPatches' document for further discussion. + A boolean value which lets you enable the `-s/--signoff` option of + format-patch by default. *Note:* Adding the Signed-off-by: line to a + patch should be a conscious act and means that you certify you have + the rights to submit this work under the same open source license. + Please see the 'SubmittingPatches' document for further discussion. + +format.coverLetter:: + A boolean that controls whether to generate a cover-letter when + format-patch is invoked, but in addition can be set to "auto", to + generate a cover-letter only when there's more than one patch. filter.<driver>.clean:: The command which is used to convert the content of a worktree @@ -1011,7 +1229,7 @@ gitcvs.logfile:: gitcvs.usecrlfattr:: If true, the server will look up the end-of-line conversion attributes for files to determine the '-k' modes to use. If - the attributes force git to treat a file as text, + the attributes force Git to treat a file as text, the '-k' mode will be left blank so CVS clients will treat it as text. If they suppress text conversion, the file will be set with '-kb' mode, which suppresses any newline munging @@ -1031,7 +1249,7 @@ gitcvs.allbinary:: gitcvs.dbname:: Database used by git-cvsserver to cache revision information - derived from the git repository. The exact meaning depends on the + derived from the Git repository. The exact meaning depends on the used database driver, for SQLite (which is the default driver) this is a filename. Supports variable substitution (see linkgit:git-cvsserver[1] for details). May not contain semicolons (`;`). @@ -1039,7 +1257,7 @@ gitcvs.dbname:: gitcvs.dbdriver:: Used Perl DBI driver. You can specify any available driver - for this here, but it might not work. git-cvsserver is tested + for this here, but it might not work. git-cvsserver is tested with 'DBD::SQLite', reported to work with 'DBD::Pg', and reported *not* to work with 'DBD::mysql'. Experimental feature. May not contain double colons (`:`). Default: 'SQLite'. @@ -1064,11 +1282,47 @@ All gitcvs variables except for 'gitcvs.usecrlfattr' and is one of "ext" and "pserver") to make them apply only for the given access method. +gitweb.category:: +gitweb.description:: +gitweb.owner:: +gitweb.url:: + See linkgit:gitweb[1] for description. + +gitweb.avatar:: +gitweb.blame:: +gitweb.grep:: +gitweb.highlight:: +gitweb.patches:: +gitweb.pickaxe:: +gitweb.remote_heads:: +gitweb.showsizes:: +gitweb.snapshot:: + See linkgit:gitweb.conf[5] for description. + grep.lineNumber:: If set to true, enable '-n' option by default. +grep.patternType:: + Set the default matching behavior. Using a value of 'basic', 'extended', + 'fixed', or 'perl' will enable the '--basic-regexp', '--extended-regexp', + '--fixed-strings', or '--perl-regexp' option accordingly, while the + value 'default' will return to the default matching behavior. + grep.extendedRegexp:: - If set to true, enable '--extended-regexp' option by default. + If set to true, enable '--extended-regexp' option by default. This + option is ignored when the 'grep.patternType' option is set to a value + other than 'default'. + +gpg.program:: + Use this custom program instead of "gpg" found on $PATH when + making or verifying a PGP signature. The program must support the + same command line interface as GPG, namely, to verify a detached + signature, "gpg --verify $file - <$signature" is run, and the + program is expected to signal a good signature by exiting with + code 0, and to generate an ascii-armored detached signature, the + standard input of "gpg -bsau $key" is fed with the contents to be + signed, and the program is expected to send the result to its + standard output. gui.commitmsgwidth:: Defines how wide the commit message window is in the @@ -1193,10 +1447,29 @@ help.autocorrect:: value is 0 - the command will be just shown but not executed. This is the default. +help.htmlpath:: + Specify the path where the HTML documentation resides. File system paths + and URLs are supported. HTML pages will be prefixed with this path when + help is displayed in the 'web' format. This defaults to the documentation + path of your Git installation. + http.proxy:: - Override the HTTP proxy, normally configured using the 'http_proxy' - environment variable (see linkgit:curl[1]). This can be overridden - on a per-remote basis; see remote.<name>.proxy + Override the HTTP proxy, normally configured using the 'http_proxy', + 'https_proxy', and 'all_proxy' environment variables (see + `curl(1)`). This can be overridden on a per-remote basis; see + remote.<name>.proxy + +http.cookiefile:: + File containing previously stored cookie lines which should be used + in the Git http session, if they match the server. The file format + of the file to read cookies from should be plain HTTP headers or + the Netscape/Mozilla cookie file format (see linkgit:curl[1]). + NOTE that the file specified with http.cookiefile is only used as + input unless http.saveCookies is set. + +http.savecookies:: + If set, store cookies received during requests to the file specified by + http.cookiefile. Has no effect if http.cookiefile is unset. http.sslVerify:: Whether to verify the SSL certificate when fetching or pushing @@ -1214,7 +1487,7 @@ http.sslKey:: variable. http.sslCertPasswordProtected:: - Enable git's password prompt for the SSL certificate. Otherwise + Enable Git's password prompt for the SSL certificate. Otherwise OpenSSL will prompt the user, possibly many times, if the certificate or private key is encrypted. Can be overridden by the 'GIT_SSL_CERT_PASSWORD_PROTECTED' environment variable. @@ -1229,6 +1502,14 @@ http.sslCAPath:: with when fetching or pushing over HTTPS. Can be overridden by the 'GIT_SSL_CAPATH' environment variable. +http.sslTry:: + Attempt to use AUTH SSL/TLS and encrypted data transfers + when connecting via regular FTP protocol. This might be needed + if the FTP server requires it for security reasons or you wish + to connect securely whenever remote FTP server supports it. + Default is false since it might trigger certificate verification + errors on misconfigured servers. + http.maxRequests:: How many HTTP requests to launch in parallel. Can be overridden by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5. @@ -1261,15 +1542,60 @@ http.noEPSV:: http.useragent:: The HTTP USER_AGENT string presented to an HTTP server. The default - value represents the version of the client git such as git/1.7.1. + value represents the version of the client Git such as git/1.7.1. This option allows you to override this value to a more common value such as Mozilla/4.0. This may be necessary, for instance, if connecting through a firewall that restricts HTTP connections to a set of common USER_AGENT strings (but not including those like git/1.7.1). Can be overridden by the 'GIT_HTTP_USER_AGENT' environment variable. +http.<url>.*:: + Any of the http.* options above can be applied selectively to some urls. + For a config key to match a URL, each element of the config key is + compared to that of the URL, in the following order: ++ +-- +. Scheme (e.g., `https` in `https://example.com/`). This field + must match exactly between the config key and the URL. + +. Host/domain name (e.g., `example.com` in `https://example.com/`). + This field must match exactly between the config key and the URL. + +. Port number (e.g., `8080` in `http://example.com:8080/`). + This field must match exactly between the config key and the URL. + Omitted port numbers are automatically converted to the correct + default for the scheme before matching. + +. Path (e.g., `repo.git` in `https://example.com/repo.git`). The + path field of the config key must match the path field of the URL + either exactly or as a prefix of slash-delimited path elements. This means + a config key with path `foo/` matches URL path `foo/bar`. A prefix can only + match on a slash (`/`) boundary. Longer matches take precedence (so a config + key with path `foo/bar` is a better match to URL path `foo/bar` than a config + key with just path `foo/`). + +. User name (e.g., `user` in `https://user@example.com/repo.git`). If + the config key has a user name it must match the user name in the + URL exactly. If the config key does not have a user name, that + config key will match a URL with any user name (including none), + but at a lower precedence than a config key with a user name. +-- ++ +The list above is ordered by decreasing precedence; a URL that matches +a config key's path is preferred to one that matches its user name. For example, +if the URL is `https://user@example.com/foo/bar` a config key match of +`https://example.com/foo` will be preferred over a config key match of +`https://user@example.com`. ++ +All URLs are normalized before attempting any matching (the password part, +if embedded in the URL, is always ignored for matching purposes) so that +equivalent urls that are simply spelled differently will match properly. +Environment variable settings always override any matches. The urls that are +matched against are those given directly to Git commands. This means any URLs +visited as a result of a redirection do not participate in matching. + i18n.commitEncoding:: - Character encoding the commit messages are stored in; git itself + Character encoding the commit messages are stored in; Git itself does not care per se, but this information is necessary e.g. when importing commits from emails or in the gitk graphical history browser (and possibly at other places in the future or in other @@ -1311,7 +1637,7 @@ instaweb.port:: interactive.singlekey:: In interactive commands, allow the user to provide one-letter input with a single key (i.e., without hitting enter). - Currently this is used by the `\--patch` mode of + Currently this is used by the `--patch` mode of linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1], linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this setting is silently ignored if portable keystroke input @@ -1319,13 +1645,13 @@ interactive.singlekey:: log.abbrevCommit:: If true, makes linkgit:git-log[1], linkgit:git-show[1], and - linkgit:git-whatchanged[1] assume `\--abbrev-commit`. You may - override this option with `\--no-abbrev-commit`. + linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may + override this option with `--no-abbrev-commit`. log.date:: Set the default date-time mode for the 'log' command. Setting a value for log.date is similar to using 'git log''s - `\--date` option. Possible values are `relative`, `local`, + `--date` option. Possible values are `relative`, `local`, `default`, `iso`, `rfc`, and `short`; see linkgit:git-log[1] for details. @@ -1342,6 +1668,10 @@ log.showroot:: Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which normally hide the root commit will now show it. True by default. +log.mailmap:: + If true, makes linkgit:git-log[1], linkgit:git-show[1], and + linkgit:git-whatchanged[1] assume `--use-mailmap`. + mailmap.file:: The location of an augmenting mailmap file. The default mailmap, located in the root of the repository, is loaded @@ -1350,6 +1680,14 @@ mailmap.file:: subdirectory, or somewhere outside of the repository itself. See linkgit:git-shortlog[1] and linkgit:git-blame[1]. +mailmap.blob:: + Like `mailmap.file`, but consider the value as a reference to a + blob in the repository. If both `mailmap.file` and + `mailmap.blob` are given, both are parsed, with entries from + `mailmap.file` taking precedence. In a bare repository, this + defaults to `HEAD:.mailmap`. In a non-bare repository, it + defaults to empty. + man.viewer:: Specify the programs that may be used to display help in the 'man' format. See linkgit:git-help[1]. @@ -1395,7 +1733,7 @@ mergetool.keepBackup:: `true` (i.e. keep the backup files). mergetool.keepTemporaries:: - When invoking a custom merge tool, git uses a set of temporary + When invoking a custom merge tool, Git uses a set of temporary files to pass to the tool. If the tool returns an error and this variable is set to `true`, then these temporary files will be preserved, otherwise they will be removed after the tool has @@ -1423,7 +1761,7 @@ displayed. notes.rewrite.<command>:: When rewriting commits with <command> (currently `amend` or - `rebase`) and this variable is set to `true`, git + `rebase`) and this variable is set to `true`, Git automatically copies your notes from the original to the rewritten commit. Defaults to `true`, but see "notes.rewriteRef" below. @@ -1503,7 +1841,7 @@ pack.threads:: warning. This is meant to reduce packing time on multiprocessor machines. The required amount of memory for the delta search window is however multiplied by the number of threads. - Specifying 0 will cause git to auto-detect the number of CPU's + Specifying 0 will cause Git to auto-detect the number of CPU's and set the number of threads accordingly. pack.indexVersion:: @@ -1515,18 +1853,18 @@ pack.indexVersion:: and this config option ignored whenever the corresponding pack is larger than 2 GB. + -If you have an old git that does not understand the version 2 `{asterisk}.idx` file, +If you have an old Git that does not understand the version 2 `*.idx` file, cloning or fetching over a non native protocol (e.g. "http" and "rsync") -that will copy both `{asterisk}.pack` file and corresponding `{asterisk}.idx` file from the +that will copy both `*.pack` file and corresponding `*.idx` file from the other side may give you a repository that cannot be accessed with your -older version of git. If the `{asterisk}.pack` file is smaller than 2 GB, however, +older version of Git. If the `*.pack` file is smaller than 2 GB, however, you can use linkgit:git-index-pack[1] on the *.pack file to regenerate -the `{asterisk}.idx` file. +the `*.idx` file. pack.packSizeLimit:: The maximum size of a pack. This setting only affects packing to a file when repacking, i.e. the git:// protocol - is unaffected. It can be overridden by the `\--max-pack-size` + is unaffected. It can be overridden by the `--max-pack-size` option of linkgit:git-repack[1]. The minimum size allowed is limited to 1 MiB. The default is unlimited. Common unit suffixes of 'k', 'm', or 'g' are @@ -1534,10 +1872,10 @@ pack.packSizeLimit:: pager.<cmd>:: If the value is boolean, turns on or off pagination of the - output of a particular git subcommand when writing to a tty. + output of a particular Git subcommand when writing to a tty. Otherwise, turns on pagination for the subcommand using the - pager specified by the value of `pager.<cmd>`. If `\--paginate` - or `\--no-pager` is specified on the command line, it takes + pager specified by the value of `pager.<cmd>`. If `--paginate` + or `--no-pager` is specified on the command line, it takes precedence over this option. To disable pagination for all commands, set `core.pager` or `GIT_PAGER` to `cat`. @@ -1545,12 +1883,36 @@ pretty.<name>:: Alias for a --pretty= format string, as specified in linkgit:git-log[1]. Any aliases defined here can be used just as the built-in pretty formats could. For example, - running `git config pretty.changelog "format:{asterisk} %H %s"` + running `git config pretty.changelog "format:* %H %s"` would cause the invocation `git log --pretty=changelog` - to be equivalent to running `git log "--pretty=format:{asterisk} %H %s"`. + to be equivalent to running `git log "--pretty=format:* %H %s"`. Note that an alias with the same name as a built-in format will be silently ignored. +pull.ff:: + By default, Git does not create an extra merge commit when merging + a commit that is a descendant of the current commit. Instead, the + tip of the current branch is fast-forwarded. When set to `false`, + this variable tells Git to create an extra merge commit in such + a case (equivalent to giving the `--no-ff` option from the command + line). When set to `only`, only such fast-forward merges are + allowed (equivalent to giving the `--ff-only` option from the + command line). + +pull.rebase:: + When true, rebase branches on top of the fetched branch, instead + of merging the default branch from the default remote when "git + pull" is run. See "branch.<name>.rebase" for setting this on a + per-branch basis. ++ + When preserve, also pass `--preserve-merges` along to 'git rebase' + so that locally committed merge commits will not be flattened + by running 'git pull'. ++ +*NOTE*: this is a possibly dangerous operation; do *not* use +it unless you understand the implications (see linkgit:git-rebase[1] +for details). + pull.octopus:: The default merge strategy to use when pulling multiple branches at once. @@ -1559,18 +1921,59 @@ pull.twohead:: The default merge strategy to use when pulling a single branch. push.default:: - Defines the action git push should take if no refspec is given - on the command line, no refspec is configured in the remote, and - no refspec is implied by any of the options given on the command - line. Possible values are: + Defines the action `git push` should take if no refspec is + explicitly given. Different values are well-suited for + specific workflows; for instance, in a purely central workflow + (i.e. the fetch source is equal to the push destination), + `upstream` is probably what you want. Possible values are: + -* `nothing` - do not push anything. -* `matching` - push all matching branches. - All branches having the same name in both ends are considered to be - matching. This is the default. -* `upstream` - push the current branch to its upstream branch. -* `tracking` - deprecated synonym for `upstream`. -* `current` - push the current branch to a branch of the same name. +-- + +* `nothing` - do not push anything (error out) unless a refspec is + explicitly given. This is primarily meant for people who want to + avoid mistakes by always being explicit. + +* `current` - push the current branch to update a branch with the same + name on the receiving end. Works in both central and non-central + workflows. + +* `upstream` - push the current branch back to the branch whose + changes are usually integrated into the current branch (which is + called `@{upstream}`). This mode only makes sense if you are + pushing to the same repository you would normally pull from + (i.e. central workflow). + +* `simple` - in centralized workflow, work like `upstream` with an + added safety to refuse to push if the upstream branch's name is + different from the local one. ++ +When pushing to a remote that is different from the remote you normally +pull from, work as `current`. This is the safest option and is suited +for beginners. ++ +This mode will become the default in Git 2.0. + +* `matching` - push all branches having the same name on both ends. + This makes the repository you are pushing to remember the set of + branches that will be pushed out (e.g. if you always push 'maint' + and 'master' there and no other branches, the repository you push + to will have these two branches, and your local 'maint' and + 'master' will be pushed there). ++ +To use this mode effectively, you have to make sure _all_ the +branches you would push out are ready to be pushed out before +running 'git push', as the whole point of this mode is to allow you +to push all of the branches in one go. If you usually finish work +on only one branch and push out the result, while other branches are +unfinished, this mode is not for you. Also this mode is not +suitable for pushing into a shared central repository, as other +people may add new branches there, or update the tip of existing +branches outside your control. ++ +This is currently the default, but Git 2.0 will change the default +to `simple`. + +-- rebase.stat:: Whether to show a diffstat of what changed upstream since the last @@ -1579,6 +1982,14 @@ rebase.stat:: rebase.autosquash:: If set to true enable '--autosquash' option by default. +rebase.autostash:: + When set to true, automatically create a temporary stash + before the operation begins, and apply it after the operation + ends. This means that you can run rebase on a dirty worktree. + However, use with care: the final stash application after a + successful rebase might result in non-trivial conflicts. + Defaults to false. + receive.autogc:: By default, git-receive-pack will run "git-gc --auto" after receiving data from git-push and updating refs. You can stop @@ -1588,7 +1999,8 @@ receive.fsckObjects:: If it is set to true, git-receive-pack will check all received objects. It will abort in the case of a malformed object or a broken link. The result of an abort are only dangling objects. - Defaults to false. + Defaults to false. If not set, the value of `transfer.fsckObjects` + is used instead. receive.unpackLimit:: If the number of objects received in a push is below this @@ -1623,10 +2035,28 @@ receive.denyNonFastForwards:: even if that push is forced. This configuration variable is set when initializing a shared repository. +receive.hiderefs:: + String(s) `receive-pack` uses to decide which refs to omit + from its initial advertisement. Use more than one + definitions to specify multiple prefix strings. A ref that + are under the hierarchies listed on the value of this + variable is excluded, and is hidden when responding to `git + push`, and an attempt to update or delete a hidden ref by + `git push` is rejected. + receive.updateserverinfo:: If set to true, git-receive-pack will run git-update-server-info after receiving data from git-push and updating refs. +receive.shallowupdate:: + If set to true, .git/shallow can be updated when new refs + require new shallow roots. Otherwise those refs are rejected. + +remote.pushdefault:: + The remote to push to by default. Overrides + `branch.<name>.remote` for all branches, and is overridden by + `branch.<name>.pushremote` for specific branches. + remote.<name>.url:: The URL of a remote repository. See linkgit:git-fetch[1] or linkgit:git-push[1]. @@ -1649,7 +2079,7 @@ remote.<name>.push:: remote.<name>.mirror:: If true, pushing to this remote will automatically behave - as if the `\--mirror` option was given on the command line. + as if the `--mirror` option was given on the command line. remote.<name>.skipDefaultUpdate:: If true, this remote will be skipped by default when updating @@ -1678,9 +2108,15 @@ remote.<name>.tagopt:: linkgit:git-fetch[1]. remote.<name>.vcs:: - Setting this to a value <vcs> will cause git to interact with + Setting this to a value <vcs> will cause Git to interact with the remote with the git-remote-<vcs> helper. +remote.<name>.prune:: + When set to true, fetching from this remote by default will also + remove any remote-tracking references that no longer exist on the + remote (as if the `--prune` option was given on the command line). + Overrides `fetch.prune` settings, if any. + remotes.<group>:: The list of remotes which are fetched by "git remote update <group>". See linkgit:git-remote[1]. @@ -1688,9 +2124,9 @@ remotes.<group>:: repack.usedeltabaseoffset:: By default, linkgit:git-repack[1] creates packs that use delta-base offset. If you need to share your repository with - git older than version 1.4.4, either directly or via a dumb + Git older than version 1.4.4, either directly or via a dumb protocol such as http, then you need to set this option to - "false" and repack. Access from old git versions over the + "false" and repack. Access from old Git versions over the native protocol are unaffected by this option. rerere.autoupdate:: @@ -1719,6 +2155,10 @@ sendemail.smtpencryption:: sendemail.smtpssl:: Deprecated alias for 'sendemail.smtpencryption = ssl'. +sendemail.smtpsslcertpath:: + Path to ca-certificates (either a directory or a single file). + Set it to an empty string to disable certificate verification. + sendemail.<identity>.*:: Identity-specific versions of the 'sendemail.*' parameters found below, taking precedence over those when the this @@ -1727,6 +2167,7 @@ sendemail.<identity>.*:: sendemail.aliasesfile:: sendemail.aliasfiletype:: +sendemail.annotate:: sendemail.bcc:: sendemail.cc:: sendemail.cccmd:: @@ -1759,9 +2200,24 @@ showbranch.default:: status.relativePaths:: By default, linkgit:git-status[1] shows paths relative to the current directory. Setting this variable to `false` shows paths - relative to the repository root (this was the default for git + relative to the repository root (this was the default for Git prior to v1.5.4). +status.short:: + Set to true to enable --short by default in linkgit:git-status[1]. + The option --no-short takes precedence over this variable. + +status.branch:: + Set to true to enable --branch by default in linkgit:git-status[1]. + The option --no-branch takes precedence over this variable. + +status.displayCommentPrefix:: + If set to true, linkgit:git-status[1] will insert a comment + prefix before each output line (starting with + `core.commentChar`, i.e. `#` by default). This was the + behavior of linkgit:git-status[1] in Git 1.8.4 and previous. + Defaults to false. + status.showUntrackedFiles:: By default, linkgit:git-status[1] and linkgit:git-commit[1] show files which are not currently tracked by Git. Directories which @@ -1786,7 +2242,14 @@ status.submodulesummary:: If this is set to a non zero number or true (identical to -1 or an unlimited number), the submodule summary will be enabled and a summary of commits for modified submodules will be shown (see - --summary-limit option of linkgit:git-submodule[1]). + --summary-limit option of linkgit:git-submodule[1]). Please note + that the summary output command will be suppressed for all + submodules when `diff.ignoreSubmodules` is set to 'all' or only + for those submodules where `submodule.<name>.ignore=all`. To + also view the summary for ignored submodules you can either use + the --ignore-submodules=dirty command line option or the 'git + submodule summary' command, which shows a similar output but does + not honor these settings. submodule.<name>.path:: submodule.<name>.url:: @@ -1797,6 +2260,12 @@ submodule.<name>.update:: URL and other values found in the `.gitmodules` file. See linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. +submodule.<name>.branch:: + The remote branch name for a submodule, used by `git submodule + update --remote`. Set this option to override the value found in + the `.gitmodules` file. See linkgit:git-submodule[1] and + linkgit:gitmodules[5] for details. + submodule.<name>.fetchRecurseSubmodules:: This option can be used to control recursive fetching of this submodule. It can be overridden by using the --[no-]recurse-submodules @@ -1815,7 +2284,8 @@ submodule.<name>.ignore:: submodules that have untracked files in their work tree as changed. This setting overrides any setting made in .gitmodules for this submodule, both settings can be overridden on the command line by using the - "--ignore-submodules" option. + "--ignore-submodules" option. The 'git submodule' commands are not + affected by this setting. tar.umask:: This variable can be used to restrict the permission bits of @@ -1824,18 +2294,54 @@ tar.umask:: archiving user's umask will be used instead. See umask(2) and linkgit:git-archive[1]. +transfer.fsckObjects:: + When `fetch.fsckObjects` or `receive.fsckObjects` are + not set, the value of this variable is used instead. + Defaults to false. + +transfer.hiderefs:: + This variable can be used to set both `receive.hiderefs` + and `uploadpack.hiderefs` at the same time to the same + values. See entries for these other variables. + transfer.unpackLimit:: When `fetch.unpackLimit` or `receive.unpackLimit` are not set, the value of this variable is used instead. The default value is 100. +uploadpack.hiderefs:: + String(s) `upload-pack` uses to decide which refs to omit + from its initial advertisement. Use more than one + definitions to specify multiple prefix strings. A ref that + are under the hierarchies listed on the value of this + variable is excluded, and is hidden from `git ls-remote`, + `git fetch`, etc. An attempt to fetch a hidden ref by `git + fetch` will fail. See also `uploadpack.allowtipsha1inwant`. + +uploadpack.allowtipsha1inwant:: + When `uploadpack.hiderefs` is in effect, allow `upload-pack` + to accept a fetch request that asks for an object at the tip + of a hidden ref (by default, such a request is rejected). + see also `uploadpack.hiderefs`. + +uploadpack.keepalive:: + When `upload-pack` has started `pack-objects`, there may be a + quiet period while `pack-objects` prepares the pack. Normally + it would output progress information, but if `--quiet` was used + for the fetch, `pack-objects` will output nothing at all until + the pack data begins. Some clients and networks may consider + the server to be hung and give up. Setting this option instructs + `upload-pack` to send an empty keepalive packet every + `uploadpack.keepalive` seconds. Setting this option to 0 + disables keepalive packets entirely. The default is 5 seconds. + url.<base>.insteadOf:: Any URL that starts with this value will be rewritten to start, instead, with <base>. In cases where some site serves a large number of repositories, and serves them with multiple access methods, and some users need to use different access methods, this feature allows people to specify any of the - equivalent URLs and have git automatically rewrite the URL to + equivalent URLs and have Git automatically rewrite the URL to the best alternative for the particular user, even for a never-before-seen repository on the site. When more than one insteadOf strings match a given URL, the longest match is used. @@ -1846,11 +2352,11 @@ url.<base>.pushInsteadOf:: resulting URL will be pushed to. In cases where some site serves a large number of repositories, and serves them with multiple access methods, some of which do not allow push, this feature - allows people to specify a pull-only URL and have git + allows people to specify a pull-only URL and have Git automatically use an appropriate URL to push, even for a never-before-seen repository on the site. When more than one pushInsteadOf strings match a given URL, the longest match is - used. If a remote has an explicit pushurl, git will ignore this + used. If a remote has an explicit pushurl, Git will ignore this setting for that remote. user.email:: @@ -1864,11 +2370,11 @@ user.name:: environment variables. See linkgit:git-commit-tree[1]. user.signingkey:: - If linkgit:git-tag[1] is not selecting the key you want it to - automatically when creating a signed tag, you can override the - default selection with this variable. This option is passed - unchanged to gpg's --local-user parameter, so you may specify a key - using any method that gpg supports. + If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the + key you want it to automatically when creating a signed tag or + commit, you can override the default selection with this variable. + This option is passed unchanged to gpg's --local-user parameter, + so you may specify a key using any method that gpg supports. web.browser:: Specify a web browser that may be used by some commands. diff --git a/Documentation/date-formats.txt b/Documentation/date-formats.txt index c000f08a9..ccd1fc812 100644 --- a/Documentation/date-formats.txt +++ b/Documentation/date-formats.txt @@ -8,9 +8,9 @@ endif::git-commit[] support the following date formats: Git internal format:: - It is `<unix timestamp> <timezone offset>`, where `<unix + It is `<unix timestamp> <time zone offset>`, where `<unix timestamp>` is the number of seconds since the UNIX epoch. - `<timezone offset>` is a positive or negative offset from UTC. + `<time zone offset>` is a positive or negative offset from UTC. For example CET (which is 2 hours ahead UTC) is `+0200`. RFC 2822:: diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt index 1aed79e7d..f07b4513e 100644 --- a/Documentation/diff-config.txt +++ b/Documentation/diff-config.txt @@ -52,6 +52,14 @@ directories with less than 10% of the total amount of changed files, and accumulating child directory counts in the parent directories: `files,10,cumulative`. +diff.statGraphWidth:: + Limit the width of the graph part in --stat output. If set, applies + to all commands generating --stat output except format-patch. + +diff.context:: + Generate diffs with <n> lines of context instead of the default + of 3. This value is overridden by the -U option. + diff.external:: If this config variable is set, diff generation is not performed using the internal diff machinery, but using the @@ -65,7 +73,11 @@ diff.ignoreSubmodules:: Sets the default value of --ignore-submodules. Note that this affects only 'git diff' Porcelain, and not lower level 'diff' commands such as 'git diff-files'. 'git checkout' also honors - this setting when reporting uncommitted changes. + this setting when reporting uncommitted changes. Setting it to + 'all' disables the submodule summary normally shown by 'git commit' + and 'git status' when 'status.submodulesummary' is set unless it is + overridden by using the --ignore-submodules command line option. + The 'git submodule' commands are not affected by this setting. diff.mnemonicprefix:: If set, 'git diff' uses a prefix pair that is different from the @@ -86,12 +98,17 @@ diff.mnemonicprefix:: diff.noprefix:: If set, 'git diff' does not show any source or destination prefix. +diff.orderfile:: + File indicating how to order files within a diff, using + one shell glob pattern per line. + Can be overridden by the '-O' option to linkgit:git-diff[1]. + diff.renameLimit:: The number of files to consider when performing the copy/rename detection; equivalent to the 'git diff' option '-l'. diff.renames:: - Tells git to detect renames. If set to any boolean value, it + Tells Git to detect renames. If set to any boolean value, it will enable basic rename detection. If set to "copies" or "copy", it will detect copies, as well. @@ -99,6 +116,19 @@ diff.suppressBlankEmpty:: A boolean to inhibit the standard behavior of printing a space before each empty output line. Defaults to false. +diff.submodule:: + Specify the format in which differences in submodules are + shown. The "log" format lists the commits in the range like + linkgit:git-submodule[1] `summary` does. The "short" format + format just shows the names of the commits at the beginning + and end of the range. Defaults to short. + +diff.wordRegex:: + A POSIX Extended Regular Expression used to determine what is a "word" + when performing word-by-word difference calculations. Character + sequences that match the regular expression are "words", all other + characters are *ignorable* whitespace. + diff.<driver>.command:: The custom diff driver command. See linkgit:gitattributes[5] for details. @@ -128,9 +158,27 @@ diff.<driver>.cachetextconv:: conversion outputs. See linkgit:gitattributes[5] for details. diff.tool:: - The diff tool to be used by linkgit:git-difftool[1]. This - option overrides `merge.tool`, and has the same valid built-in - values as `merge.tool` minus "tortoisemerge" and plus - "kompare". Any other value is treated as a custom diff tool, - and there must be a corresponding `difftool.<tool>.cmd` - option. + Controls which diff tool is used by linkgit:git-difftool[1]. + This variable overrides the value configured in `merge.tool`. + The list below shows the valid built-in values. + Any other value is treated as a custom diff tool and requires + that a corresponding difftool.<tool>.cmd variable is defined. + +include::mergetools-diff.txt[] + +diff.algorithm:: + Choose a diff algorithm. The variants are as follows: ++ +-- +`default`, `myers`;; + The basic greedy diff algorithm. Currently, this is the default. +`minimal`;; + Spend extra time to make sure the smallest possible diff is + produced. +`patience`;; + Use "patience diff" algorithm when generating patches. +`histogram`;; + This algorithm extends the patience algorithm to "support + low-occurrence common elements". +-- ++ diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt index c57460c03..55f499a16 100644 --- a/Documentation/diff-generate-patch.txt +++ b/Documentation/diff-generate-patch.txt @@ -175,7 +175,7 @@ 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}`). +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 diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 659de6f12..9b37b2a10 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -26,6 +26,11 @@ ifndef::git-format-patch[] {git-diff? This is the default.} endif::git-format-patch[] +-s:: +--no-patch:: + Suppress diff output. Useful for commands like `git show` that + show the patch by default, or to cancel the effect of `--patch`. + -U<n>:: --unified=<n>:: Generate diffs with <n> lines of context instead of @@ -45,17 +50,56 @@ ifndef::git-format-patch[] Synonym for `-p --raw`. endif::git-format-patch[] +--minimal:: + Spend extra time to make sure the smallest possible + diff is produced. + --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>`. - The width of the filename part can be controlled by - giving another width to it separated by a comma. +--histogram:: + Generate a diff using the "histogram diff" algorithm. + +--diff-algorithm={patience|minimal|histogram|myers}:: + Choose a diff algorithm. The variants are as follows: ++ +-- +`default`, `myers`;; + The basic greedy diff algorithm. Currently, this is the default. +`minimal`;; + Spend extra time to make sure the smallest possible diff is + produced. +`patience`;; + Use "patience diff" algorithm when generating patches. +`histogram`;; + This algorithm extends the patience algorithm to "support + low-occurrence common elements". +-- ++ +For instance, if you configured diff.algorithm variable to a +non-default value and want to use the default one, then you +have to use `--diff-algorithm=default` option. + +--stat[=<width>[,<name-width>[,<count>]]]:: + Generate a diffstat. By default, as much space as necessary + will be used for the filename part, and the rest for the graph + part. Maximum width defaults to terminal width, or 80 columns + if not connected to a terminal, and can be overridden by + `<width>`. The width of the filename part can be limited by + giving another width `<name-width>` after a comma. The width + of the graph part can be limited by using + `--stat-graph-width=<width>` (affects all commands generating + a stat graph) or by setting `diff.statGraphWidth=<width>` + (does not affect `git format-patch`). + By giving a third parameter `<count>`, you can limit the + output to the first `<count>` lines, followed by `...` if + there are more. ++ +These parameters can also be set individually with `--stat-width=<width>`, +`--stat-name-width=<name-width>` and `--stat-count=<count>`. --numstat:: - Similar to `\--stat`, but shows number of added and + Similar to `--stat`, but shows number of added and deleted lines in decimal notation and pathname without abbreviation, to make it more machine friendly. For binary files, outputs two `-` instead of saying @@ -146,16 +190,18 @@ any of those replacements occurred. of the `--diff-filter` option on what the status letters mean. --submodule[=<format>]:: - Chose the output format for submodule differences. <format> can be one of - 'short' and 'log'. 'short' just shows pairs of commit names, this format - is used when this option is not given. 'log' is the default value for this - option and lists the commits in that commit range like the 'summary' - option of linkgit:git-submodule[1] does. + Specify how differences in submodules are shown. When `--submodule` + or `--submodule=log` is given, the 'log' format is used. This format lists + the commits in the range like linkgit:git-submodule[1] `summary` does. + Omitting the `--submodule` option or specifying `--submodule=short`, + uses the 'short' format. This format just shows the names of the commits + at the beginning and end of the range. Can be tweaked via the + `diff.submodule` configuration variable. --color[=<when>]:: Show colored diff. - The value must be `always` (the default for `<when>`), `never`, or `auto`. - The default value is `never`. + `--color` (i.e. without '=<when>') is the same as `--color=always`. + '<when>' can be one of `always`, `never`, or `auto`. ifdef::git-diff[] It can be changed by the `color.ui` and `color.diff` configuration settings. @@ -262,7 +308,7 @@ few lines that happen to match textually as the context, but as a single deletion of everything old followed by a single insertion of everything new, and the number `m` controls this aspect of the -B option (defaults to 60%). `-B/70%` specifies that less than 30% of the -original should remain in the result for git to consider it a total +original should remain in the result for Git to consider it a total rewrite (i.e. otherwise the resulting patch will be a series of deletion and insertion mixed together with context lines). + @@ -286,9 +332,13 @@ ifdef::git-log[] endif::git-log[] If `n` is specified, it is a threshold on the similarity index (i.e. amount of addition/deletions compared to the - file's size). For example, `-M90%` means git should consider a + file's size). For example, `-M90%` means Git should consider a delete/add pair to be a rename if more than 90% of the file - hasn't changed. + hasn't changed. Without a `%` sign, the number is to be read as + a fraction, with a decimal point before it. I.e., `-M5` becomes + 0.5, and is thus the same as `-M50%`. Similarly, `-M05` is + the same as `-M5%`. To limit detection to exact renames, use + `-M100%`. The default similarity index is 50%. -C[<n>]:: --find-copies[=<n>]:: @@ -338,14 +388,36 @@ ifndef::git-format-patch[] that matches other criteria, nothing is selected. -S<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. + Look for differences that change the number of occurrences of + the specified string (i.e. addition/deletion) in a file. + Intended for the scripter's use. ++ +It is useful when you're looking for an exact block of code (like a +struct), and want to know the history of that block since it first +came into being: use the feature iteratively to feed the interesting +block in the preimage back into `-S`, and keep going until you get the +very first version of the block. -G<regex>:: - Look for differences whose added or removed line matches - the given <regex>. + Look for differences whose patch text contains added/removed + lines that match <regex>. ++ +To illustrate the difference between `-S<regex> --pickaxe-regex` and +`-G<regex>`, consider a commit with the following diff in the same +file: ++ +---- ++ return !regexec(regexp, two->ptr, 1, ®match, 0); +... +- hit = !regexec(regexp, mf2.ptr, 1, ®match, 0); +---- ++ +While `git log -G"regexec\(regexp"` will show this commit, `git log +-S"regexec\(regexp" --pickaxe-regex` will not (because the number of +occurrences of that string did not change). ++ +See the 'pickaxe' entry in linkgit:gitdiffcore[7] for more +information. --pickaxe-all:: When `-S` or `-G` finds a change, show all the changes in that @@ -353,13 +425,16 @@ ifndef::git-format-patch[] in <string>. --pickaxe-regex:: - Make the <string> not a plain string but an extended POSIX - regex to match. + Treat the <string> given to `-S` as an extended POSIX regular + expression to match. endif::git-format-patch[] -O<orderfile>:: Output the patch in the order specified in the <orderfile>, which has one shell glob pattern per line. + This overrides the `diff.orderfile` configuration variable + (see linkgit:git-config[1]). To cancel `diff.orderfile`, + use `-O/dev/null`. ifndef::git-format-patch[] -R:: @@ -394,11 +469,19 @@ endif::git-format-patch[] differences even if one line has whitespace where the other line has none. +--ignore-blank-lines:: + Ignore changes whose lines are all blank. + --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. +-W:: +--function-context:: + Show whole surrounding functions of changes. + ifndef::git-format-patch[] +ifndef::git-log[] --exit-code:: Make the program exit with codes similar to diff(1). That is, it exits with 1 if there were differences and @@ -406,6 +489,7 @@ ifndef::git-format-patch[] --quiet:: Disable all output of the program. Implies `--exit-code`. +endif::git-log[] endif::git-format-patch[] --ext-diff:: @@ -429,7 +513,7 @@ endif::git-format-patch[] --ignore-submodules[=<when>]:: Ignore changes to submodules in the diff generation. <when> can be - either "none", "untracked", "dirty" or "all", which is the default + either "none", "untracked", "dirty" or "all", which is the default. Using "none" will consider the submodule modified when it either contains untracked or modified files or its HEAD differs from the commit recorded in the superproject and can be used to override any settings of the diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index ae413e52a..2a18c1f6f 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -1,4 +1,4 @@ -Everyday GIT With 20 Commands Or So +Everyday Git With 20 Commands Or So =================================== <<Individual Developer (Standalone)>> commands are essential for @@ -12,7 +12,7 @@ commands in addition to the above. <<Repository Administration>> commands are for system administrators who are responsible for the care and feeding -of git repositories. +of Git repositories. Individual Developer (Standalone)[[Individual Developer (Standalone)]] @@ -87,7 +87,7 @@ $ git log v2.43.. curses/ <12> + <1> create a new topic branch. <2> revert your botched changes in `curses/ux_audio_oss.c`. -<3> you need to tell git if you added a new file; removal and +<3> you need to tell Git if you added a new file; removal and modification will be caught if you do `git commit -a` later. <4> to see what changes you are committing. <5> commit everything as you have tested, with your sign-off. @@ -98,8 +98,8 @@ you originally wrote. <9> switch to the master branch. <10> merge a topic branch into your master branch. <11> review commit logs; other forms to limit output can be -combined and include `\--max-count=10` (show 10 commits), -`\--until=2005-12-10`, etc. +combined and include `--max-count=10` (show 10 commits), +`--until=2005-12-10`, etc. <12> view only the changes that touch what's in `curses/` directory, since `v2.43` tag. @@ -229,7 +229,7 @@ commands in addition to the ones needed by participants. Examples ~~~~~~~~ -My typical GIT day.:: +My typical Git day.:: + ------------ $ git status <1> @@ -304,7 +304,7 @@ and maintain access to the repository by developers. * 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 +link:howto/update-hook-example.html[update hook howto] has a good example of managing a shared central repository. @@ -332,7 +332,7 @@ Run git-daemon to serve /pub/scm from xinetd.:: ------------ $ cat /etc/xinetd.d/git-daemon # default: off -# description: The git server offers access to git repositories +# description: The Git server offers access to Git repositories service git { disable = no diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 39d326abc..92c68c3fd 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -8,9 +8,24 @@ option old data in `.git/FETCH_HEAD` will be overwritten. --depth=<depth>:: - Deepen the history of a 'shallow' repository created by + Deepen or shorten the history of a 'shallow' repository created by `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1]) - by the specified number of commits. + to the specified number of commits from the tip of each remote + branch history. Tags for the deepened commits are not fetched. + +--unshallow:: + If the source repository is complete, convert a shallow + repository to a complete one, removing all the limitations + imposed by shallow repositories. ++ +If the source repository is shallow, fetch as much as possible so that +the current repository has the same history as the source repository. + +--update-shallow:: + By default when fetching from a shallow repository, + `git fetch` refuses refs that require updating + .git/shallow. This option updates .git/shallow and accept such + refs. ifndef::git-pull[] --dry-run:: @@ -36,17 +51,20 @@ ifndef::git-pull[] -p:: --prune:: - After fetching, remove any remote-tracking branches which - no longer exist on the remote. + After fetching, remove any remote-tracking references that no + longer exist on the remote. Tags are not subject to pruning + if they are fetched only because of the default tag + auto-following or due to a --tags option. However, if tags + are fetched due to an explicit refspec (either on the command + line or in the remote configuration, for example if the remote + was cloned with the --mirror option), then they are also + subject to pruning. endif::git-pull[] -ifdef::git-pull[] ---no-tags:: -endif::git-pull[] ifndef::git-pull[] -n:: ---no-tags:: endif::git-pull[] +--no-tags:: 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. The default @@ -56,14 +74,12 @@ endif::git-pull[] ifndef::git-pull[] -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 - tracked will not be fetched by this mechanism. This - flag lets all tags and their associated objects be - downloaded. The default behavior for a remote may be - specified with the remote.<name>.tagopt setting. See - linkgit:git-config[1]. + Fetch all tags from the remote (i.e., fetch remote tags + `refs/tags/*` into local tags with the same name), in addition + to whatever else would otherwise be fetched. Using this + option alone does not subject tags to pruning, even if --prune + is used (though tags may be pruned anyway if they are also the + destination of an explicit refspec; see '--prune'). --recurse-submodules[=yes|on-demand|no]:: This option controls if and under what conditions new commits of diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 9c1d39572..48754cbc6 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -9,9 +9,9 @@ SYNOPSIS -------- [verse] 'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p] - [--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N] - [--refresh] [--ignore-errors] [--ignore-missing] [--] - [<filepattern>...] + [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] + [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] + [--] [<pathspec>...] DESCRIPTION ----------- @@ -49,7 +49,7 @@ commit. OPTIONS ------- -<filepattern>...:: +<pathspec>...:: Files to add content from. Fileglobs (e.g. `*.c`) can be given to add all matching files. Also a leading directory name (e.g. `dir` to add `dir/file1` @@ -100,23 +100,40 @@ apply to the index. See EDITING PATCHES below. -u:: --update:: - Only match <filepattern> against already tracked files in - the index rather than the working tree. That means that it - will never stage new files, but that it will stage modified - new contents of tracked files and that it will remove files - from the index if the corresponding files in the working tree - have been removed. + Update the index just where it already has an entry matching + <pathspec>. This removes as well as modifies index entries to + match the working tree, but adds no new files. + -If no <filepattern> is given, default to "."; in other words, -update all tracked files in the current directory and its -subdirectories. +If no <pathspec> is given, the current version of Git defaults to +"."; in other words, update all tracked files in the current directory +and its subdirectories. This default will change in a future version +of Git, hence the form without <pathspec> should not be used. -A:: --all:: - Like `-u`, but match <filepattern> against files in the - working tree in addition to the index. That means that it - will find new files as well as staging modified content and - removing files that are no longer in the working tree. +--no-ignore-removal:: + Update the index not only where the working tree has a file + matching <pathspec> but also where the index already has an + entry. This adds, modifies, and removes index entries to + match the working tree. ++ +If no <pathspec> is given, the current version of Git defaults to +"."; in other words, update all files in the current directory +and its subdirectories. This default will change in a future version +of Git, hence the form without <pathspec> should not be used. + +--no-all:: +--ignore-removal:: + Update the index by adding new files that are unknown to the + index and files modified in the working tree, but ignore + files that have been removed from the working tree. This + option is a no-op when no <pathspec> is used. ++ +This option is primarily to help the current users of Git, whose +"git add <pathspec>..." ignores removed files. In future versions +of Git, "git add <pathspec>..." will be a synonym to "git add -A +<pathspec>..." and "git add --ignore-removal <pathspec>..." will behave like +today's "git add <pathspec>...", ignoring removed files. -N:: --intent-to-add:: @@ -155,7 +172,7 @@ 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 linkgit:gitrepository-layout[5]. +those in info/exclude. See linkgit:gitignore[5]. EXAMPLES diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index 6b1b5af64..54d8461d6 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -9,11 +9,12 @@ git-am - Apply a series of patches from a mailbox SYNOPSIS -------- [verse] -'git am' [--signoff] [--keep] [--keep-cr | --no-keep-cr] [--utf8 | --no-utf8] +'git am' [--signoff] [--keep] [--[no-]keep-cr] [--[no-]utf8] [--3way] [--interactive] [--committer-date-is-author-date] [--ignore-date] [--ignore-space-change | --ignore-whitespace] [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>] - [--reject] [-q | --quiet] [--scissors | --no-scissors] + [--exclude=<path>] [--include=<path>] [--reject] [-q | --quiet] + [--[no-]scissors] [(<mbox> | <Maildir>)...] 'git am' (--continue | --skip | --abort) @@ -39,8 +40,10 @@ OPTIONS --keep:: Pass `-k` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]). ---keep-cr:: ---no-keep-cr:: +--keep-non-patch:: + Pass `-b` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]). + +--[no-]keep-cr:: With `--keep-cr`, call 'git mailsplit' (see linkgit:git-mailsplit[1]) with the same option, to prevent it from stripping CR at the end of lines. `am.keepcr` configuration variable can be used to specify the @@ -87,6 +90,8 @@ default. You can use `--no-utf8` to override this. -C<n>:: -p<n>:: --directory=<dir>:: +--exclude=<path>:: +--include=<path>:: --reject:: These flags are passed to the 'git apply' (see linkgit:git-apply[1]) program that applies @@ -127,7 +132,7 @@ default. You can use `--no-utf8` to override this. --resolvemsg=<msg>:: When a patch failure occurs, <msg> will be printed to the screen before exiting. This overrides the - standard message informing you to use `--resolved` + standard message informing you to use `--continue` or `--skip` to handle the failure. This is solely for internal use between 'git rebase' and 'git am'. @@ -171,7 +176,7 @@ aborts in the middle. You can recover from this in one of two ways: . hand resolve the conflict in the working directory, and update the index file to bring it into a state that the patch should - have produced. Then run the command with the '--resolved' option. + have produced. Then run the command with the '--continue' option. The command refuses to process new mailboxes until the current operation is finished, so if you decide to start over from scratch, diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt index afd2c9ae5..f60532794 100644 --- a/Documentation/git-apply.txt +++ b/Documentation/git-apply.txt @@ -9,7 +9,7 @@ git-apply - Apply a patch to files and/or to the index SYNOPSIS -------- [verse] -'git apply' [--stat] [--numstat] [--summary] [--check] [--index] +'git apply' [--stat] [--numstat] [--summary] [--check] [--index] [--3way] [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse] [--allow-binary-replacement | --binary] [--reject] [-z] [-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached] @@ -24,7 +24,7 @@ Reads the supplied diff output (i.e. "a patch") and applies it to files. With the `--index` option the patch is also applied to the index, and with the `--cached` option the patch is only applied to the index. Without these options, the command applies the patch only to files, -and does not require them to be in a git repository. +and does not require them to be in a Git repository. This command applies the patch but does not create a commit. Use linkgit:git-am[1] to create commits from patches generated by @@ -72,6 +72,15 @@ OPTIONS cached data, apply the patch, and store the result in the index without using the working tree. This implies `--index`. +-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 available locally, possibly leaving the + conflict markers in the files in the working tree for the user to + resolve. This option implies the `--index` option, and is incompatible + with the `--reject` and the `--cached` options. + --build-fake-ancestor=<file>:: Newer 'git diff' output has embedded 'index information' for each blob to help identify the original version that @@ -189,7 +198,7 @@ behavior: * `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). + 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. diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt index f4504ba9b..163b9f6f4 100644 --- a/Documentation/git-archimport.txt +++ b/Documentation/git-archimport.txt @@ -3,7 +3,7 @@ git-archimport(1) NAME ---- -git-archimport - Import an Arch repository into git +git-archimport - Import an Arch repository into Git SYNOPSIS @@ -40,13 +40,13 @@ directory. To follow the development of a project that uses Arch, rerun incremental imports. 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> +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 -branch names and convert Arch jargon to git jargon, for example mapping a +branch names and convert Arch jargon to Git jargon, for example mapping a "PROJECT{litdd}devo{litdd}VERSION" branch to "master". -Associating multiple Arch branches to one git branch is possible; the +Associating multiple Arch branches to one Git branch is possible; the result will make the most sense only if no commits are made to the first branch, after the second branch is created. Still, this is useful to convert Arch repositories that had been rotated periodically. @@ -54,14 +54,14 @@ convert Arch repositories that had been rotated periodically. MERGES ------ -Patch merge data from Arch is used to mark merges in git as well. git +Patch merge data from Arch is used to mark merges in Git as well. Git does not care much about tracking patches, and only considers a merge when a branch incorporates all the commits since the point they forked. The end result -is that git will have a good idea of how far branches have diverged. So the +is that Git will have a good idea of how far branches have diverged. So the import process does lose some patch-trading metadata. Fortunately, when you try and merge branches imported from Arch, -git will find a good merge base, and it has a good chance of identifying +Git will find a good merge base, and it has a good chance of identifying patches that have been traded out-of-sequence between the branches. OPTIONS diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt index 9c750e244..b97aaab4e 100644 --- a/Documentation/git-archive.txt +++ b/Documentation/git-archive.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git archive' [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>] - [-o | --output=<file>] [--worktree-attributes] + [-o <file> | --output=<file>] [--worktree-attributes] [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish> [<path>...] @@ -56,7 +56,8 @@ OPTIONS Write the archive to <file> instead of stdout. --worktree-attributes:: - Look for attributes in .gitattributes in working directory too. + Look for attributes in .gitattributes files in the working tree + as well (see <<ATTRIBUTES>>). <extra>:: This can be any options that the archiver backend understands. @@ -101,6 +102,26 @@ tar.umask:: details. If `--remote` is used then only the configuration of the remote repository takes effect. +tar.<format>.command:: + This variable specifies a shell command through which the tar + output generated by `git archive` should be piped. The command + is executed using the shell with the generated tar file on its + standard input, and should produce the final output on its + standard output. Any compression-level options will be passed + to the command (e.g., "-9"). An output file with the same + extension as `<format>` will be use this format if no other + format is given. ++ +The "tar.gz" and "tgz" formats are defined automatically and default to +`gzip -cn`. You may override them with custom commands. + +tar.<format>.remote:: + If true, enable `<format>` for use by remote clients via + linkgit:git-upload-archive[1]. Defaults to false for + user-defined formats, but true for the "tar.gz" and "tgz" + formats. + +[[ATTRIBUTES]] ATTRIBUTES ---------- @@ -109,7 +130,7 @@ export-ignore:: 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 + 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. @@ -123,32 +144,46 @@ while archiving any tree in your `$GIT_DIR/info/attributes` file. EXAMPLES -------- -git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -):: +`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 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:: +`git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz`:: Create a compressed tarball for v1.4.0 release. -git archive --format=tar --prefix=git-1.4.0/ v1.4.0{caret}\{tree\} | gzip >git-1.4.0.tar.gz:: +`git archive --format=tar.gz --prefix=git-1.4.0/ v1.4.0 >git-1.4.0.tar.gz`:: + + Same as above, but using the builtin tar.gz handling. + +`git archive --prefix=git-1.4.0/ -o git-1.4.0.tar.gz v1.4.0`:: + + Same as above, but the format is inferred from the output file. + +`git archive --format=tar --prefix=git-1.4.0/ v1.4.0^{tree} | gzip >git-1.4.0.tar.gz`:: Create a compressed tarball for v1.4.0 release, but without a global extended pax header. -git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip:: +`git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip`:: Put everything in the current head's Documentation/ directory into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'. -git archive -o latest.zip HEAD:: +`git archive -o latest.zip HEAD`:: Create a Zip archive that contains the contents of the latest commit on the current branch. Note that the output format is inferred by the extension of the output file. +`git config tar.tar.xz.command "xz -c"`:: + + Configure a "tar.xz" format for making LZMA-compressed tarfiles. + You can use it specifying `--format=tar.xz`, or by creating an + output file like `-o foo.tar.xz`. + SEE ALSO -------- diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt index 8a2ba3790..afeb86c6c 100644 --- a/Documentation/git-bisect-lk2009.txt +++ b/Documentation/git-bisect-lk2009.txt @@ -224,7 +224,7 @@ Note that the example that we will use is really a toy example, we will be looking for the first commit that has a version like "2.6.26-something", that is the commit that has a "SUBLEVEL = 26" line in the top level Makefile. This is a toy example because there are -better ways to find this commit with git than using "git bisect" (for +better ways to find this commit with Git than using "git bisect" (for example "git blame" or "git log -S<string>"). Driving a bisection manually @@ -257,7 +257,7 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +:100644 100644 5cf82581... 4492984e... M Makefile ------------- At this point we can see what the commit does, check it out (if it's @@ -331,7 +331,7 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +:100644 100644 5cf82581... 4492984e... M Makefile bisect run success ------------- @@ -455,7 +455,7 @@ So only the W and B commits will be kept. Because commits X and Y will have been removed by rules a) and b) respectively, and because commits G are removed by rule b) too. -Note for git users, that it is equivalent as keeping only the commit +Note for Git users, that it is equivalent as keeping only the commit given by: ------------- @@ -710,8 +710,8 @@ Skip algorithm discussed After step 7) (in the skip algorithm), we could check if the second commit has been skipped and return it if it is not the case. And in fact that was the algorithm we used from when "git bisect skip" was -developed in git version 1.5.4 (released on February 1st 2008) until -git version 1.6.4 (released July 29th 2009). +developed in Git version 1.5.4 (released on February 1st 2008) until +Git version 1.6.4 (released July 29th 2009). But Ingo Molnar and H. Peter Anvin (another well known linux kernel developer) both complained that sometimes the best bisection points @@ -1025,10 +1025,10 @@ And here is what Andreas said about this work-flow <<5>>: _____________ To give some hard figures, we used to have an average report-to-fix cycle of 142.6 hours (according to our somewhat weird bug-tracker -which just measures wall-clock time). Since we moved to git, we've +which just measures wall-clock time). Since we moved to Git, we've lowered that to 16.2 hours. Primarily because we can stay on top of the bug fixing now, and because everyone's jockeying to get to fix -bugs (we're quite proud of how lazy we are to let git find the bugs +bugs (we're quite proud of how lazy we are to let Git find the bugs for us). Each new release results in ~40% fewer bugs (almost certainly due to how we now feel about writing tests). _____________ @@ -1228,9 +1228,9 @@ commits in already released history, for example to change the commit message or the author. And it can also be used instead of git "grafts" to link a repository with another old repository. -In fact it's this last feature that "sold" it to the git community, so -it is now in the "master" branch of git's git repository and it should -be released in git 1.6.5 in October or November 2009. +In fact it's this last feature that "sold" it to the Git community, so +it is now in the "master" branch of Git's Git repository and it should +be released in Git 1.6.5 in October or November 2009. One problem with "git replace" is that currently it stores all the replacements refs in "refs/replace/", but it would be perhaps better @@ -1320,11 +1320,11 @@ So git bisect is unconditional goodness - and feel free to quote that ;-) _____________ -Acknowledgements +Acknowledgments ---------------- Many thanks to Junio Hamano for his help in reviewing this paper, for -reviewing the patches I sent to the git mailing list, for discussing +reviewing the patches I sent to the Git mailing list, for discussing some ideas and helping me improve them, for improving "git bisect" a lot and for his awesome work in maintaining and developing Git. @@ -1337,7 +1337,7 @@ Many thanks to Linus Torvalds for inventing, developing and evangelizing "git bisect", Git and Linux. Many thanks to the many other great people who helped one way or -another when I worked on git, especially to Andreas Ericsson, Johannes +another when I worked on Git, especially to Andreas Ericsson, Johannes Schindelin, H. Peter Anvin, Daniel Barkalow, Bill Lear, John Hawley, Shawn O. Pierce, Jeff King, Sam Vilain, Jon Seymour. diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index ab60a1847..f986c5cb3 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -17,7 +17,7 @@ The command takes various subcommands, and different options depending on the subcommand: git bisect help - git bisect start [<bad> [<good>...]] [--] [<paths>...] + git bisect start [--no-checkout] [<bad> [<good>...]] [--] [<paths>...] git bisect bad [<rev>] git bisect good [<rev>...] git bisect skip [(<rev>|<range>)...] @@ -83,7 +83,7 @@ Bisect reset ~~~~~~~~~~~~ After a bisect session, to clean up the bisection state and return to -the original HEAD, issue the following command: +the original HEAD (i.e., to quit bisecting), issue the following command: ------------------------------------------------ $ git bisect reset @@ -169,14 +169,14 @@ the revision as good or bad in the usual manner. Bisect skip ~~~~~~~~~~~~ -Instead of choosing by yourself a nearby commit, you can ask git +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 git may eventually be unable to tell the first bad commit among +But Git may eventually be unable to tell the first bad commit among a bad commit and one or more skipped commits. You can even skip a range of commits, instead of just one commit, @@ -263,6 +263,19 @@ 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. +OPTIONS +------- +--no-checkout:: ++ +Do not checkout the new working tree at each iteration of the bisection +process. Instead just update a special reference named 'BISECT_HEAD' to make +it point to the commit that should be tested. ++ +This option may be useful when the test you would perform in each step +does not require a checked out tree. ++ +If the repository is bare, `--no-checkout` is assumed. + EXAMPLES -------- @@ -271,6 +284,7 @@ EXAMPLES ------------ $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good $ git bisect run make # "make" builds the app +$ git bisect reset # quit the bisect session ------------ * Automatically bisect a test failure between origin and HEAD: @@ -278,6 +292,7 @@ $ git bisect run make # "make" builds the app ------------ $ git bisect start HEAD origin -- # HEAD is bad, origin is good $ git bisect run make test # "make test" builds and tests +$ git bisect reset # quit the bisect session ------------ * Automatically bisect a broken test case: @@ -289,6 +304,7 @@ make || exit 125 # this skips broken builds ~/check_test_case.sh # does the test case pass? $ git bisect start HEAD HEAD~10 -- # culprit is among the last 10 $ git bisect run ~/test.sh +$ git bisect reset # quit the bisect session ------------ + Here we use a "test.sh" custom script. In this script, if "make" @@ -338,11 +354,32 @@ use `git cherry-pick` instead of `git merge`.) ------------ $ git bisect start HEAD HEAD~10 -- # culprit is among the last 10 $ git bisect run sh -c "make || exit 125; ~/check_test_case.sh" +$ git bisect reset # quit the bisect session ------------ + This shows that you can do without a run script if you write the test on a single line. +* Locate a good region of the object graph in a damaged repository ++ +------------ +$ git bisect start HEAD <known-good-commit> [ <boundary-commit> ... ] --no-checkout +$ git bisect run sh -c ' + GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) && + git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ && + git pack-objects --stdout >/dev/null <tmp.$$ + rc=$? + rm -f tmp.$$ + test $rc = 0' + +$ git bisect reset # quit the bisect session +------------ ++ +In this case, when 'git bisect run' finishes, bisect/bad will refer to a commit that +has at least one parent whose reachable graph is fully traversable in the sense +required by 'git pack objects'. + + SEE ALSO -------- link:git-bisect-lk2009.html[Fighting regressions with git bisect], diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index 951691423..8e70a6184 100644 --- a/Documentation/git-blame.txt +++ b/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] [-e] [-p] [-w] [--incremental] [-L n,m] - [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>] [--abbrev=<n>] - [<rev> | --contents <file> | --reverse <rev>] [--] <file> +'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental] + [-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>] + [--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>] [--] <file> DESCRIPTION ----------- @@ -18,13 +18,20 @@ 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. -The command can also limit the range of lines annotated. +When specified one or more times, `-L` restricts annotation to the requested +lines. + +The origin of lines is automatically followed across whole-file +renames (currently there is no option to turn the rename-following +off). To follow lines moved from one file to another, or to follow +lines that were copied and pasted from another file, etc., see the +`-C` and `-M` options. 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 +Apart from supporting file annotation, Git also supports searching the development history for when a code snippet occurred in a change. This makes it possible to track when a code snippet was added to a file, moved or copied between files, and eventually deleted or replaced. It works by searching for @@ -96,7 +103,7 @@ This header line is followed by the following information at least once for each commit: - the author name ("author"), email ("author-mail"), time - ("author-time"), and timezone ("author-tz"); similarly + ("author-time"), and time zone ("author-tz"); similarly for committer. - the filename in the commit that the line is attributed to. - the first line of the commit log message ("summary"). @@ -124,7 +131,10 @@ SPECIFYING RANGES 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 +ranges. The `-L` option, which limits annotation to a range of lines, may be +specified multiple times. + +When you are interested in finding the origin for 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): @@ -160,7 +170,7 @@ introduced the file with: git log --diff-filter=A --pretty=short -- foo and then annotate the change between the commit and its -parents, using `commit{caret}!` notation: +parents, using `commit^!` notation: git blame -C -C -f $commit^! -- foo diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index c50f18982..311b33674 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -9,18 +9,28 @@ SYNOPSIS -------- [verse] 'git branch' [--color[=<when>] | --no-color] [-r | -a] - [-v [--abbrev=<length> | --no-abbrev]] - [(--merged | --no-merged | --contains) [<commit>]] + [--list] [-v [--abbrev=<length> | --no-abbrev]] + [--column[=<options>] | --no-column] + [(--merged | --no-merged | --contains) [<commit>]] [<pattern>...] 'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>] +'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>] +'git branch' --unset-upstream [<branchname>] 'git branch' (-m | -M) [<oldbranch>] <newbranch> 'git branch' (-d | -D) [-r] <branchname>... +'git branch' --edit-description [<branchname>] DESCRIPTION ----------- -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. +If `--list` is given, or if there are no non-option arguments, existing +branches are listed; the current branch will be highlighted with an +asterisk. Option `-r` causes the remote-tracking branches to be listed, +and option `-a` shows both local and remote branches. If a `<pattern>` +is given, it is used as a shell wildcard to restrict the output to +matching branches. If multiple patterns are given, a branch is shown if +it matches any of the patterns. Note that when providing a +`<pattern>`, you must use `--list`; otherwise the command is interpreted +as branch creation. With `--contains`, shows only the branches that contain the named commit (in other words, the branches whose tip commits are descendants of the @@ -37,14 +47,15 @@ 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-tracking branch, git sets up the -branch so that 'git pull' will appropriately merge from +When a local branch is started off a remote-tracking branch, Git sets up the +branch (specifically the `branch.<name>.remote` and `branch.<name>.merge` +configuration entries) so that 'git pull' will appropriately merge from the remote-tracking 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, and -changed later using `git branch --set-upstream`. +changed later using `git branch --set-upstream-to`. -With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>. +With a `-m` or `-M` option, <oldbranch> will be renamed to <newbranch>. If <oldbranch> had a corresponding reflog, it is renamed to match <newbranch>, and a reflog entry is created to remember the branch renaming. If <newbranch> exists, -M must be used to force the rename @@ -54,7 +65,7 @@ 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. Note, that it +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 @@ -64,6 +75,7 @@ way to clean up all obsolete remote-tracking branches. OPTIONS ------- -d:: +--delete:: Delete a branch. The branch must be fully merged in its upstream branch, or in `HEAD` if no upstream was set with `--track` or `--set-upstream`. @@ -72,6 +84,7 @@ OPTIONS Delete a branch irrespective of its merged status. -l:: +--create-reflog:: Create the 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}". @@ -84,6 +97,7 @@ OPTIONS already. Without `-f` 'git branch' refuses to change an existing branch. -m:: +--move:: Move/rename a branch and the corresponding reflog. -M:: @@ -99,28 +113,52 @@ OPTIONS default to color output. Same as `--color=never`. +--column[=<options>]:: +--no-column:: + Display branch listing in columns. See configuration variable + column.branch for option syntax.`--column` and `--no-column` + without options are equivalent to 'always' and 'never' respectively. ++ +This option is only applicable in non-verbose mode. + -r:: +--remotes:: List or delete (if used with -d) the remote-tracking branches. -a:: +--all:: List both remote-tracking branches and local branches. +--list:: + Activate the list mode. `git branch <pattern>` would try to create a branch, + use `git branch --list <pattern>` to list matching branches. + -v:: +-vv:: --verbose:: - Show sha1 and commit subject line for each head, along with + When in list mode, + 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. + the name of the upstream branch, as well (see also `git remote + show <remote>`). + +-q:: +--quiet:: + Be more quiet when creating or deleting a branch, suppressing + non-error messages. --abbrev=<length>:: Alter the sha1's minimum display length in the output listing. - The default value is 7. + The default value is 7 and can be overridden by the `core.abbrev` + config option. --no-abbrev:: 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 + When creating a new branch, set up `branch.<name>.remote` and + `branch.<name>.merge` configuration entries 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, @@ -138,21 +176,36 @@ start-point is either a local or remote-tracking branch. branch.autosetupmerge configuration variable is true. --set-upstream:: - If specified branch does not exist yet or if '--force' has been - given, acts exactly like '--track'. Otherwise sets up configuration - like '--track' would when creating the branch, except that where + If specified branch does not exist yet or if `--force` has been + given, acts exactly like `--track`. Otherwise sets up configuration + like `--track` would when creating the branch, except that where branch points to is not changed. ---contains <commit>:: - Only list branches which contain the specified commit. +-u <upstream>:: +--set-upstream-to=<upstream>:: + Set up <branchname>'s tracking information so <upstream> is + considered <branchname>'s upstream branch. If no <branchname> + is specified, then it defaults to the current branch. + +--unset-upstream:: + Remove the upstream information for <branchname>. If no branch + is specified it defaults to the current branch. + +--edit-description:: + Open an editor and edit the text to explain what the branch is + for, to be used by various other commands (e.g. `request-pull`). + +--contains [<commit>]:: + Only list branches which contain the specified commit (HEAD + if not specified). Implies `--list`. --merged [<commit>]:: Only list branches whose tips are reachable from the - specified commit (HEAD if not specified). + specified commit (HEAD if not specified). Implies `--list`. --no-merged [<commit>]:: Only list branches whose tips are not reachable from the - specified commit (HEAD if not specified). + specified commit (HEAD if not specified). Implies `--list`. <branchname>:: The name of the branch to create or delete. diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt index 92b01ec25..0417562eb 100644 --- a/Documentation/git-bundle.txt +++ b/Documentation/git-bundle.txt @@ -19,7 +19,7 @@ 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, and therefore the interactive git protocols (git, +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 @@ -61,7 +61,7 @@ unbundle <file>:: A list of arguments, acceptable to 'git rev-parse' and 'git rev-list' (and containing a named ref, see SPECIFYING REFERENCES below), that specifies the specific objects and references - to transport. For example, `master{tilde}10..master` causes the + 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 @@ -80,12 +80,12 @@ 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{tilde}1` cannot be packaged, but are perfectly suitable for +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{tilde}10`), or implicitly (e.g. -`master{tilde}10..master`, `--since=10.days.ago master`). +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 caution, causing the bundle file @@ -112,13 +112,12 @@ machineA$ git bundle create file.bundle master machineA$ git tag -f lastR2bundle master ---------------- -Then you transfer file.bundle to the target machine B. If you are creating -the repository on machine B, then you can clone from the bundle as if it -were a remote repository instead of creating an empty repository and then -pulling or fetching objects from the bundle: +Then you transfer file.bundle to the target machine B. Because this +bundle does not require any existing object to be extracted, you can +create a new repository on machine B by cloning from it: ---------------- -machineB$ git clone /home/me/tmp/file.bundle R2 +machineB$ git clone -b master /home/me/tmp/file.bundle R2 ---------------- This will define a remote called "origin" in the resulting repository that diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt index 2fb95bbd1..f6a16f430 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -20,7 +20,7 @@ object type, or '-s' is used to find the object size, or '--textconv' is used (which implies type "blob"). 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. +stdin, and the SHA-1, type, and size of each object is printed on stdout. OPTIONS ------- @@ -54,16 +54,20 @@ OPTIONS --textconv:: Show the content as transformed by a textconv filter. In this case, - <object> has be of the form <treeish>:<path>, or :<path> in order + <object> has be of the form <tree-ish>:<path>, or :<path> in order to apply the filter to the content recorded in the index at <path>. --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=<format>:: + Print object information and contents for each object provided + on stdin. May not be combined with any other options or arguments. + See the section `BATCH OUTPUT` below for details. --batch-check:: - Print the SHA1, type, and size of each object provided on stdin. May not - be combined with any other options or arguments. +--batch-check=<format>:: + Print object information for each object provided on stdin. May + not be combined with any other options or arguments. See the + section `BATCH OUTPUT` below for details. OUTPUT ------ @@ -78,28 +82,87 @@ If '-p' is specified, the contents of <object> are pretty-printed. 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: +BATCH OUTPUT +------------ + +If `--batch` or `--batch-check` is given, `cat-file` will read objects +from stdin, one per line, and print information about them. By default, +the whole line is considered as an object, as if it were fed to +linkgit:git-rev-parse[1]. + +You can specify the information shown for each object by using a custom +`<format>`. The `<format>` is copied literally to stdout for each +object, with placeholders of the form `%(atom)` expanded, followed by a +newline. The available atoms are: + +`objectname`:: + The 40-hex object name of the object. + +`objecttype`:: + The type of of the object (the same as `cat-file -t` reports). + +`objectsize`:: + The size, in bytes, of the object (the same as `cat-file -s` + reports). + +`objectsize:disk`:: + The size, in bytes, that the object takes up on disk. See the + note about on-disk sizes in the `CAVEATS` section below. + +`deltabase`:: + If the object is stored as a delta on-disk, this expands to the + 40-hex sha1 of the delta base object. Otherwise, expands to the + null sha1 (40 zeroes). See `CAVEATS` below. + +`rest`:: + If this atom is used in the output string, input lines are split + at the first whitespace boundary. All characters before that + whitespace are considered to be the object name; characters + after that first run of whitespace (i.e., the "rest" of the + line) are output in place of the `%(rest)` atom. + +If no format is specified, the default format is `%(objectname) +%(objecttype) %(objectsize)`. + +If `--batch` is specified, the object information is followed by the +object contents (consisting of `%(objectsize)` bytes), followed by a +newline. + +For example, `--batch` without a custom format would produce: ------------ <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: +Whereas `--batch-check='%(objectname) %(objecttype)'` would produce: ------------ -<sha1> SP <type> SP <size> LF +<sha1> SP <type> 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: +If a name is specified on stdin that cannot be resolved to an object in +the repository, then `cat-file` will ignore any custom format and print: ------------ <object> SP missing LF ------------ + +CAVEATS +------- + +Note that the sizes of objects on disk are reported accurately, but care +should be taken in drawing conclusions about which refs or objects are +responsible for disk usage. The size of a packed non-delta object may be +much larger than the size of objects which delta against it, but the +choice of which object is the base and which is the delta is arbitrary +and is subject to change during a repack. + +Note also that multiple copies of an object may be present in the object +database; in this case, it is undefined which copy's size or delta base +will be reported. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt index 30eca6cee..00e2aa2df 100644 --- a/Documentation/git-check-attr.txt +++ b/Documentation/git-check-attr.txt @@ -9,8 +9,8 @@ git-check-attr - Display gitattributes information SYNOPSIS -------- [verse] -'git check-attr' attr... [--] pathname... -'git check-attr' --stdin [-z] attr... < <list-of-paths> +'git check-attr' [-a | --all | attr...] [--] pathname... +'git check-attr' --stdin [-z] [-a | --all | attr...] < <list-of-paths> DESCRIPTION ----------- @@ -19,17 +19,29 @@ For every pathname, this command will list if each attribute is 'unspecified', OPTIONS ------- +-a, --all:: + List all attributes that are associated with the specified + paths. If this option is used, then 'unspecified' attributes + will not be included in the output. + +--cached:: + Consider `.gitattributes` in the index only, ignoring the working tree. + --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. + The output format is modified to be machine-parseable. + If `--stdin` is also given, input paths are separated + with a NUL character instead of a linefeed character. \--:: 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. + arguments as path names. + +If none of `--stdin`, `--all`, or `--` is used, the first argument +will be treated as an attribute and the rest of the arguments as +pathnames. OUTPUT ------ @@ -37,6 +49,10 @@ OUTPUT The output is of the form: <path> COLON SP <attribute> COLON SP <info> LF +unless `-z` is in effect, in which case NUL is used as delimiter: +<path> NUL <attribute> NUL <info> NUL + + <path> is the path of a file being queried, <attribute> is an attribute being queried and <info> can be either: @@ -45,6 +61,11 @@ being queried and <info> can be either: 'set';; when the attribute is defined as true. <value>;; when a value has been assigned to the attribute. +Buffering happens as documented under the `GIT_FLUSH` option in +linkgit:git[1]. The caller is responsible for avoiding deadlocks +caused by overfilling an input buffer or reading from an empty output +buffer. + EXAMPLES -------- @@ -69,6 +90,13 @@ org/example/MyClass.java: diff: java org/example/MyClass.java: myAttr: set --------------- +* Listing all attributes for a file: +--------------- +$ git check-attr --all -- org/example/MyClass.java +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 diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt new file mode 100644 index 000000000..ee2e09170 --- /dev/null +++ b/Documentation/git-check-ignore.txt @@ -0,0 +1,116 @@ +git-check-ignore(1) +=================== + +NAME +---- +git-check-ignore - Debug gitignore / exclude files + + +SYNOPSIS +-------- +[verse] +'git check-ignore' [options] pathname... +'git check-ignore' [options] --stdin < <list-of-paths> + +DESCRIPTION +----------- + +For each pathname given via the command-line or from a file via +`--stdin`, show the pattern from .gitignore (or other input files to +the exclude mechanism) that decides if the pathname is excluded or +included. Later patterns within a file take precedence over earlier +ones. + +OPTIONS +------- +-q, --quiet:: + Don't output anything, just set exit status. This is only + valid with a single pathname. + +-v, --verbose:: + Also output details about the matching pattern (if any) + for each given pathname. + +--stdin:: + Read file names from stdin instead of from the command-line. + +-z:: + The output format is modified to be machine-parseable (see + below). If `--stdin` is also given, input paths are separated + with a NUL character instead of a linefeed character. + +-n, --non-matching:: + Show given paths which don't match any pattern. This only + makes sense when `--verbose` is enabled, otherwise it would + not be possible to distinguish between paths which match a + pattern and those which don't. + +--no-index:: + Don't look in the index when undertaking the checks. This can + be used to debug why a path became tracked by e.g. `git add .` + and was not ignored by the rules as expected by the user or when + developing patterns including negation to match a path previously + added with `git add -f`. + +OUTPUT +------ + +By default, any of the given pathnames which match an ignore pattern +will be output, one per line. If no pattern matches a given path, +nothing will be output for that path; this means that path will not be +ignored. + +If `--verbose` is specified, the output is a series of lines of the form: + +<source> <COLON> <linenum> <COLON> <pattern> <HT> <pathname> + +<pathname> is the path of a file being queried, <pattern> is the +matching pattern, <source> is the pattern's source file, and <linenum> +is the line number of the pattern within that source. If the pattern +contained a `!` prefix or `/` suffix, it will be preserved in the +output. <source> will be an absolute path when referring to the file +configured by `core.excludesfile`, or relative to the repository root +when referring to `.git/info/exclude` or a per-directory exclude file. + +If `-z` is specified, the pathnames in the output are delimited by the +null character; if `--verbose` is also specified then null characters +are also used instead of colons and hard tabs: + +<source> <NULL> <linenum> <NULL> <pattern> <NULL> <pathname> <NULL> + +If `-n` or `--non-matching` are specified, non-matching pathnames will +also be output, in which case all fields in each output record except +for <pathname> will be empty. This can be useful when running +non-interactively, so that files can be incrementally streamed to +STDIN of a long-running check-ignore process, and for each of these +files, STDOUT will indicate whether that file matched a pattern or +not. (Without this option, it would be impossible to tell whether the +absence of output for a given file meant that it didn't match any +pattern, or that the output hadn't been generated yet.) + +Buffering happens as documented under the `GIT_FLUSH` option in +linkgit:git[1]. The caller is responsible for avoiding deadlocks +caused by overfilling an input buffer or reading from an empty output +buffer. + +EXIT STATUS +----------- + +0:: + One or more of the provided paths is ignored. + +1:: + None of the provided paths are ignored. + +128:: + A fatal error was encountered. + +SEE ALSO +-------- +linkgit:gitignore[5] +linkgit:gitconfig[5] +linkgit:git-ls-files[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-check-mailmap.txt b/Documentation/git-check-mailmap.txt new file mode 100644 index 000000000..39028ee1a --- /dev/null +++ b/Documentation/git-check-mailmap.txt @@ -0,0 +1,47 @@ +git-check-mailmap(1) +==================== + +NAME +---- +git-check-mailmap - Show canonical names and email addresses of contacts + + +SYNOPSIS +-------- +[verse] +'git check-mailmap' [options] <contact>... + + +DESCRIPTION +----------- + +For each ``Name $$<user@host>$$'' or ``$$<user@host>$$'' from the command-line +or standard input (when using `--stdin`), look up the person's canonical name +and email address (see "Mapping Authors" below). If found, print them; +otherwise print the input as-is. + + +OPTIONS +------- +--stdin:: + Read contacts, one per line, from the standard input after exhausting + contacts provided on the command-line. + + +OUTPUT +------ + +For each contact, a single line is output, terminated by a newline. If the +name is provided or known to the 'mailmap', ``Name $$<user@host>$$'' is +printed; otherwise only ``$$<user@host>$$'' is printed. + + +MAPPING AUTHORS +--------------- + +include::mailmap.txt[] + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index c9fdf84a0..fc02959ba 100644 --- a/Documentation/git-check-ref-format.txt +++ b/Documentation/git-check-ref-format.txt @@ -8,8 +8,9 @@ git-check-ref-format - Ensures that a reference name is well formed SYNOPSIS -------- [verse] -'git check-ref-format' <refname> -'git check-ref-format' --print <refname> +'git check-ref-format' [--normalize] + [--[no-]allow-onelevel] [--refspec-pattern] + <refname> 'git check-ref-format' --branch <branchname-shorthand> DESCRIPTION @@ -17,36 +18,44 @@ DESCRIPTION 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 +A reference is used in Git to specify branches and tags. A branch head is stored in the `refs/heads` hierarchy, while a tag is stored in the `refs/tags` hierarchy of the ref namespace (typically in `$GIT_DIR/refs/heads` and `$GIT_DIR/refs/tags` directories or, as entries in file `$GIT_DIR/packed-refs` if refs are packed by `git gc`). -git imposes the following rules on how references are named: +Git imposes the following rules on how references are named: . They can include slash `/` for hierarchical (directory) grouping, but no slash-separated component can begin with a - dot `.`. + dot `.` or end with the sequence `.lock`. . They must contain at least one `/`. This enforces the presence of a category like `heads/`, `tags/` etc. but the actual names are not - restricted. + restricted. If the `--allow-onelevel` option is used, this rule + is waived. . They cannot have two consecutive dots `..` anywhere. . They cannot have ASCII control characters (i.e. bytes whose values are lower than \040, or \177 `DEL`), space, tilde `~`, - caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`, - or open bracket `[` anywhere. + caret `^`, or colon `:` anywhere. -. They cannot end with a slash `/` nor a dot `.`. +. They cannot have question-mark `?`, asterisk `*`, or open + bracket `[` anywhere. See the `--refspec-pattern` option below for + an exception to this rule. -. They cannot end with the sequence `.lock`. +. They cannot begin or end with a slash `/` or contain multiple + consecutive slashes (see the `--normalize` option below for an + exception to this rule) + +. They cannot end with a dot `.`. . They cannot contain a sequence `@{`. +. They cannot be the single character `@`. + . They cannot contain a `\`. These rules make it easy for shell script based tools to parse @@ -55,10 +64,10 @@ unquoted (by mistake), and also avoids ambiguities in certain reference name expressions (see linkgit:gitrevisions[7]): . A double-dot `..` is often used as in `ref1..ref2`, and in some - contexts this notation means `{caret}ref1 ref2` (i.e. not in + contexts this notation means `^ref1 ref2` (i.e. not in `ref1` and in `ref2`). -. A tilde `~` and caret `{caret}` are used to introduce the postfix +. A tilde `~` and caret `^` are used to introduce the postfix 'nth parent' and 'peel onion' operation. . A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s @@ -68,16 +77,35 @@ reference name expressions (see linkgit:gitrevisions[7]): . at-open-brace `@{` is used as a notation to access a reflog entry. -With the `--print` option, if 'refname' is acceptable, it prints the -canonicalized name of a hypothetical reference with that name. That is, -it prints 'refname' with any extra `/` characters removed. - With the `--branch` option, it expands the ``previous branch syntax'' `@{-n}`. For example, `@{-1}` is a way to refer the last branch you were on. This option should be used by porcelains to accept this syntax anywhere a branch name is expected, so they can act as if you typed the branch name. +OPTIONS +------- +--[no-]allow-onelevel:: + Controls whether one-level refnames are accepted (i.e., + refnames that do not contain multiple `/`-separated + components). The default is `--no-allow-onelevel`. + +--refspec-pattern:: + Interpret <refname> as a reference name pattern for a refspec + (as used with remote repositories). If this option is + enabled, <refname> is allowed to contain a single `*` + in place of a one full pathname component (e.g., + `foo/*/bar` but not `foo/bar*`). + +--normalize:: + Normalize 'refname' by removing any leading slash (`/`) + characters and collapsing runs of adjacent slashes between + name components into a single slash. Iff the normalized + refname is valid then print it to standard output and exit + with a status of 0. (`--print` is a deprecated way to spell + `--normalize`.) + + EXAMPLES -------- @@ -90,7 +118,7 @@ $ git check-ref-format --branch @{-1} * Determine the reference name to use for a new branch: + ------------ -$ ref=$(git check-ref-format --print "refs/heads/$newbranch") || +$ ref=$(git check-ref-format --normalize "refs/heads/$newbranch") || die "we do not like '$newbranch' as a branch name." ------------ diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index c0a96e6c1..33ad2adf5 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -9,7 +9,8 @@ SYNOPSIS -------- [verse] 'git checkout' [-q] [-f] [-m] [<branch>] -'git checkout' [-q] [-f] [-m] [--detach] [<commit>] +'git checkout' [-q] [-f] [-m] --detach [<branch>] +'git checkout' [-q] [-f] [-m] [--detach] <commit> 'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>] 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>... 'git checkout' [-p|--patch] [<tree-ish>] [--] [<paths>...] @@ -21,18 +22,34 @@ or the specified tree. If no paths are given, 'git checkout' will also update `HEAD` to set the specified branch as the current branch. -'git checkout' [<branch>]:: +'git checkout' <branch>:: + To prepare for working on <branch>, switch to it by updating + the index and the files in the working tree, and by pointing + HEAD at the branch. Local modifications to the files in the + working tree are kept, so that they can be committed to the + <branch>. ++ +If <branch> is not found but there does exist a tracking branch in +exactly one remote (call it <remote>) with a matching name, treat as +equivalent to ++ +------------ +$ git checkout -b <branch> --track <remote>/<branch> +------------ ++ +You could omit <branch>, in which case the command degenerates to +"check out the current branch", which is a glorified no-op with a +rather expensive side-effects to show only the tracking information, +if exists, for the current branch. + 'git checkout' -b|-B <new_branch> [<start point>]:: -'git checkout' [--detach] [<commit>]:: - This form switches branches by updating the index, working - tree, and HEAD to reflect the specified branch or commit. -+ -If `-b` is given, a new branch is created as if linkgit:git-branch[1] -were called and then checked out; 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. + Specifying `-b` causes a new branch to be created as if + linkgit:git-branch[1] were called and then checked out. 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. + If `-B` is given, <new_branch> is created if it doesn't exist; otherwise, it is reset. This is the transactional equivalent of @@ -45,6 +62,22 @@ $ git checkout <branch> that is to say, the branch is not reset/created unless "git checkout" is successful. +'git checkout' --detach [<branch>]:: +'git checkout' [--detach] <commit>:: + + Prepare to work on top of <commit>, by detaching HEAD at it + (see "DETACHED HEAD" section), and updating the index and the + files in the working tree. Local modifications to the files + in the working tree are kept, so that the resulting working + tree will be the state recorded in the commit plus the local + modifications. ++ +When the <commit> argument is a branch name, the `--detach` option can +be used to detach HEAD at the tip of the branch (`git checkout +<branch>` would check out that branch without detaching HEAD). ++ +Omitting <branch> detaches HEAD at the tip of the current branch. + 'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...:: When <paths> or `--patch` are given, 'git checkout' does *not* @@ -84,11 +117,11 @@ entries; instead, unmerged entries are ignored. When checking out paths from the index, check out stage #2 ('ours') or #3 ('theirs') for unmerged paths. --b:: +-b <new_branch>:: Create a new branch named <new_branch> and start it at <start_point>; see linkgit:git-branch[1] for details. --B:: +-B <new_branch>:: Creates the branch <new_branch> and start it at <start_point>; if it already exists, then reset it to <start_point>. This is equivalent to running "git branch" with "-f"; see @@ -100,9 +133,9 @@ entries; instead, unmerged entries are ignored. "--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-tracking 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. +derived from the remote-tracking branch, by looking at the local part of +the refspec configured for the corresponding remote, and then stripping +the initial part up to the "*". 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 @@ -124,7 +157,7 @@ explicitly give a name with '-b' in such a case. <commit> is not a branch name. See the "DETACHED HEAD" section below for details. ---orphan:: +--orphan <new_branch>:: Create a new 'orphan' branch, named <new_branch>, started from <start_point> and switch to it. The first commit made on this new branch will have no parents and it will be the root of a new @@ -149,6 +182,12 @@ branch by running "git rm -rf ." from the top level of the working tree. Afterwards you will be ready to prepare your new files, repopulating the working tree, by copying them from elsewhere, extracting a tarball, etc. +--ignore-skip-worktree-bits:: + In sparse checkout mode, `git checkout -- <paths>` would + update only entries matched by <paths> and sparse patterns + in $GIT_DIR/info/sparse-checkout. This option ignores + the sparse patterns and adds back any files in <paths>. + -m:: --merge:: When switching branches, @@ -184,7 +223,7 @@ the conflicted merge in the specified paths. + This means that you can use `git checkout -p` to selectively discard edits from your current working tree. See the ``Interactive Mode'' -section of linkgit:git-add[1] to learn how to operate the `\--patch` mode. +section of linkgit:git-add[1] to learn how to operate the `--patch` mode. <branch>:: Branch to checkout; if it refers to a branch (i.e., a name that, @@ -193,11 +232,11 @@ section of linkgit:git-add[1] to learn how to operate the `\--patch` mode. 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\}"`. +As a special case, the `"@{-N}"` syntax for the N-th last branch/commit +checks out branches (instead of detaching). You may also specify +`-` which is synonymous with `"@{-1}"`. + -As a further special case, you may use `"A\...B"` as a shortcut for the +As a further special case, you may use `"A...B"` as a shortcut for the merge base of `A` and `B` if there is exactly one merge base. You can leave out at most one of `A` and `B`, in which case it defaults to `HEAD`. @@ -302,7 +341,7 @@ a---b---c---d branch 'master' (refers to commit 'd') tag 'v2.0' (refers to commit 'b') ------------ -In fact, we can perform all the normal git operations. But, let's look +In fact, we can perform all the normal Git operations. But, let's look at what happens when we then checkout master: ------------ @@ -319,7 +358,7 @@ a---b---c---d branch 'master' (refers to commit 'd') It is important to realize that at this point nothing refers to commit 'f'. Eventually commit 'f' (and by extension commit 'e') will be deleted -by the routine git garbage collection process, unless we create a reference +by the routine Git garbage collection process, unless we create a reference before that happens. If we have not yet moved away from commit 'f', any of these will create a reference to it: @@ -367,6 +406,18 @@ $ git checkout hello.c <3> <2> take a file out of another commit <3> restore hello.c from the index + +If you want to check out _all_ C source files out of the index, +you can say ++ +------------ +$ git checkout -- '*.c' +------------ ++ +Note the quotes around `*.c`. The file `hello.c` will also be +checked out, even though it is no longer in the working tree, +because the file globbing is used to match entries in the index +(not in the working tree by the shell). ++ If you have an unfortunate branch that is named `hello.c`, this step would be confused as an instruction to switch to that branch. You should instead write: diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index 6c9c2cb38..c205d2363 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -9,6 +9,9 @@ SYNOPSIS -------- [verse] 'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>... +'git cherry-pick' --continue +'git cherry-pick' --quit +'git cherry-pick' --abort DESCRIPTION ----------- @@ -44,7 +47,9 @@ OPTIONS linkgit:gitrevisions[7]. Sets of commits can be passed but no traversal is done by default, as if the '--no-walk' option was specified, see - linkgit:git-rev-list[1]. + linkgit:git-rev-list[1]. Note that specifying a range will + feed all <commit>... arguments to a single revision walk + (see a later example that uses 'maint master..next'). -e:: --edit:: @@ -100,6 +105,30 @@ effect to your index in a row. cherry-pick'ed commit, then a fast forward to this commit will be performed. +--allow-empty:: + By default, cherry-picking an empty commit will fail, + indicating that an explicit invocation of `git commit + --allow-empty` is required. This option overrides that + behavior, allowing empty commits to be preserved automatically + in a cherry-pick. Note that when "--ff" is in effect, empty + commits that meet the "fast-forward" requirement will be kept + even without this option. Note also, that use of this option only + keeps commits that were initially empty (i.e. the commit recorded the + same tree as its parent). Commits which are made empty due to a + previous commit are dropped. To force the inclusion of those commits + use `--keep-redundant-commits`. + +--allow-empty-message:: + By default, cherry-picking a commit with an empty message will fail. + This option overrides that behaviour, allowing commits with empty + messages to be cherry picked. + +--keep-redundant-commits:: + If a commit being cherry picked duplicates a commit already in the + current history, it will become empty. By default these + redundant commits are ignored. This option overrides that behavior and + creates an empty commit object. Implies `--allow-empty`. + --strategy=<strategy>:: Use the given merge strategy. Should only be used once. See the MERGE STRATEGIES section in linkgit:git-merge[1] @@ -110,33 +139,46 @@ effect to your index in a row. Pass the merge strategy-specific option through to the merge strategy. See linkgit:git-merge[1] for details. +SEQUENCER SUBCOMMANDS +--------------------- +include::sequencer.txt[] + EXAMPLES -------- -git cherry-pick master:: +`git cherry-pick master`:: Apply the change introduced by the commit at the tip of the master branch and create a new commit with this change. -git cherry-pick ..master:: -git cherry-pick ^HEAD master:: +`git cherry-pick ..master`:: +`git cherry-pick ^HEAD master`:: Apply the changes introduced by all commits that are ancestors of master but not of HEAD to produce new commits. -git cherry-pick master{tilde}4 master{tilde}2:: +`git cherry-pick maint next ^master`:: +`git cherry-pick maint master..next`:: + + Apply the changes introduced by all commits that are + ancestors of maint or next, but not master or any of its + ancestors. Note that the latter does not mean `maint` and + everything between `master` and `next`; specifically, + `maint` will not be used if it is included in `master`. + +`git cherry-pick master~4 master~2`:: Apply the changes introduced by the fifth and third last commits pointed to by master and create 2 new commits with these changes. -git cherry-pick -n master~1 next:: +`git cherry-pick -n master~1 next`:: Apply to the working tree and the index the changes introduced by the second last commit pointed to by master and by the last commit pointed to by next, but do not create any commit with these changes. -git cherry-pick --ff ..next:: +`git cherry-pick --ff ..next`:: If history is linear and HEAD is an ancestor of next, update the working tree and advance the HEAD pointer to match next. @@ -144,7 +186,7 @@ git cherry-pick --ff ..next:: are in next but not HEAD to the current branch, creating a new commit for each new change. -git rev-list --reverse master \-- README | git cherry-pick -n --stdin:: +`git rev-list --reverse master -- README | git cherry-pick -n --stdin`:: Apply the changes introduced by all commits on the master branch that touched README to the working tree and index, diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt index f6c19c734..0ea921a59 100644 --- a/Documentation/git-cherry.txt +++ b/Documentation/git-cherry.txt @@ -3,7 +3,7 @@ git-cherry(1) NAME ---- -git-cherry - Find commits not merged upstream +git-cherry - Find commits yet to be applied to upstream SYNOPSIS -------- @@ -12,47 +12,26 @@ SYNOPSIS 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. +Determine whether there are commits in `<head>..<upstream>` that are +equivalent to those in the range `<limit>..<head>`. -Every commit that doesn't exist in the <upstream> branch -has its id (sha1) reported, prefixed by a symbol. The ones that have -equivalent change already -in the <upstream> branch are prefixed with a minus (-) sign, and those -that only exist in the <head> branch are prefixed with a plus (+) symbol: - - __*__*__*__*__> <upstream> - / - fork-point - \__+__+__-__+__+__-__+__> <head> - - -If a <limit> has been given then the commits along the <head> branch up -to and including <limit> are not reported: - - __*__*__*__*__> <upstream> - / - fork-point - \__*__*__<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 -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. +The equivalence test is based on the diff, after removing whitespace +and line numbers. git-cherry therefore detects when commits have been +"copied" by means of linkgit:git-cherry-pick[1], linkgit:git-am[1] or +linkgit:git-rebase[1]. +Outputs the SHA1 of every commit in `<limit>..<head>`, prefixed with +`-` for commits that have an equivalent in <upstream>, and `+` for +commits that do not. OPTIONS ------- -v:: - Verbose. + Show the commit subjects next to the SHA1s. <upstream>:: - Upstream branch to compare against. - Defaults to the first tracked remote branch, if available. + Upstream branch to search for equivalent commits. + Defaults to the upstream branch of HEAD. <head>:: Working branch; defaults to HEAD. @@ -60,6 +39,103 @@ OPTIONS <limit>:: Do not report commits up to (and including) limit. +EXAMPLES +-------- + +Patch workflows +~~~~~~~~~~~~~~~ + +git-cherry is frequently used in patch-based workflows (see +linkgit:gitworkflows[7]) to determine if a series of patches has been +applied by the upstream maintainer. In such a workflow you might +create and send a topic branch like this: + +------------ +$ git checkout -b topic origin/master +# work and create some commits +$ git format-patch origin/master +$ git send-email ... 00* +------------ + +Later, you can see whether your changes have been applied by saying +(still on `topic`): + +------------ +$ git fetch # update your notion of origin/master +$ git cherry -v +------------ + +Concrete example +~~~~~~~~~~~~~~~~ + +In a situation where topic consisted of three commits, and the +maintainer applied two of them, the situation might look like: + +------------ +$ git log --graph --oneline --decorate --boundary origin/master...topic +* 7654321 (origin/master) upstream tip commit +[... snip some other commits ...] +* cccc111 cherry-pick of C +* aaaa111 cherry-pick of A +[... snip a lot more that has happened ...] +| * cccc000 (topic) commit C +| * bbbb000 commit B +| * aaaa000 commit A +|/ +o 1234567 branch point +------------ + +In such cases, git-cherry shows a concise summary of what has yet to +be applied: + +------------ +$ git cherry origin/master topic +- cccc000... commit C ++ bbbb000... commit B +- aaaa000... commit A +------------ + +Here, we see that the commits A and C (marked with `-`) can be +dropped from your `topic` branch when you rebase it on top of +`origin/master`, while the commit B (marked with `+`) still needs to +be kept so that it will be sent to be applied to `origin/master`. + + +Using a limit +~~~~~~~~~~~~~ + +The optional <limit> is useful in cases where your topic is based on +other work that is not in upstream. Expanding on the previous +example, this might look like: + +------------ +$ git log --graph --oneline --decorate --boundary origin/master...topic +* 7654321 (origin/master) upstream tip commit +[... snip some other commits ...] +* cccc111 cherry-pick of C +* aaaa111 cherry-pick of A +[... snip a lot more that has happened ...] +| * cccc000 (topic) commit C +| * bbbb000 commit B +| * aaaa000 commit A +| * 0000fff (base) unpublished stuff F +[... snip ...] +| * 0000aaa unpublished stuff A +|/ +o 1234567 merge-base between upstream and topic +------------ + +By specifying `base` as the limit, you can avoid listing commits +between `base` and `topic`: + +------------ +$ git cherry origin/master topic base +- cccc000... commit C ++ bbbb000... commit B +- aaaa000... commit A +------------ + + SEE ALSO -------- linkgit:git-patch-id[1] diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt index 974e04ef1..89979228b 100644 --- a/Documentation/git-clean.txt +++ b/Documentation/git-clean.txt @@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree SYNOPSIS -------- [verse] -'git clean' [-d] [-f] [-n] [-q] [-e <pattern>] [-x | -X] [--] <path>... +'git clean' [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] <path>... DESCRIPTION ----------- @@ -16,7 +16,7 @@ DESCRIPTION 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' +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. @@ -27,14 +27,20 @@ OPTIONS ------- -d:: Remove untracked directories in addition to untracked files. - If an untracked directory is managed by a different git + If an untracked directory is managed by a different Git repository, it is not removed by default. Use -f option twice if you really want to remove such a directory. -f:: --force:: - If the git configuration variable clean.requireForce is not set - to false, 'git clean' will refuse to run unless given -f or -n. + If the Git configuration variable clean.requireForce is not set + to false, 'git clean' will refuse to run unless given -f, -n or + -i. + +-i:: +--interactive:: + Show what would be done and clean files interactively. See + ``Interactive mode'' for details. -n:: --dry-run:: @@ -47,20 +53,87 @@ OPTIONS -e <pattern>:: --exclude=<pattern>:: - Specify special exceptions to not be cleaned. Each <pattern> is - the same form as in $GIT_DIR/info/excludes and this option can be - given multiple times. + In addition to those found in .gitignore (per directory) and + $GIT_DIR/info/exclude, also consider these patterns to be in the + set of the ignore rules in effect. -x:: - Don't use the ignore rules. This allows removing all untracked + Don't use the standard ignore rules read from .gitignore (per + directory) and $GIT_DIR/info/exclude, but do still use the ignore + rules given with `-e` options. This allows removing all untracked files, including build products. This can be used (possibly in conjunction with 'git reset') to create a pristine working directory to test a clean build. -X:: - Remove only files ignored by git. This may be useful to rebuild + Remove only files ignored by Git. This may be useful to rebuild everything from scratch, but keep manually created files. +Interactive mode +---------------- +When the command enters the interactive mode, it shows the +files and directories to be cleaned, and goes into its +interactive command loop. + +The command loop shows the list of subcommands available, and +gives a prompt "What now> ". In general, when the prompt ends +with a single '>', you can pick only one of the choices given +and type return, like this: + +------------ + *** Commands *** + 1: clean 2: filter by pattern 3: select by numbers + 4: ask each 5: quit 6: help + What now> 1 +------------ + +You also could say `c` or `clean` above as long as the choice is unique. + +The main command loop has 6 subcommands. + +clean:: + + Start cleaning files and directories, and then quit. + +filter by pattern:: + + This shows the files and directories to be deleted and issues an + "Input ignore patterns>>" prompt. You can input space-seperated + patterns to exclude files and directories from deletion. + E.g. "*.c *.h" will excludes files end with ".c" and ".h" from + deletion. When you are satisfied with the filtered result, press + ENTER (empty) back to the main menu. + +select by numbers:: + + This shows the files and directories to be deleted and issues an + "Select items to delete>>" prompt. When the prompt ends with double + '>>' like this, you can make more than one selection, concatenated + with whitespace or comma. Also you can say ranges. E.g. "2-5 7,9" + to choose 2,3,4,5,7,9 from the list. If the second number in a + range is omitted, all remaining items are selected. E.g. "7-" to + choose 7,8,9 from the list. You can say '*' to choose everything. + Also when you are satisfied with the filtered result, press ENTER + (empty) back to the main menu. + +ask each:: + + This will start to clean, and you must confirm one by one in order + to delete items. Please note that this action is not as efficient + as the above two actions. + +quit:: + + This lets you quit without do cleaning. + +help:: + + Show brief usage of interactive git-clean. + +SEE ALSO +-------- +linkgit:gitignore[5] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index b093e4549..bf3dac0ce 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -13,7 +13,8 @@ SYNOPSIS [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] [--separate-git-dir <git dir>] - [--depth <depth>] [--recursive|--recurse-submodules] [--] <repository> + [--depth <depth>] [--[no-]single-branch] + [--recursive | --recurse-submodules] [--] <repository> [<directory>] DESCRIPTION @@ -28,7 +29,8 @@ currently active branch. After the clone, a plain `git fetch` without arguments will update all the remote-tracking branches, and a `git pull` without arguments will in addition merge the remote master branch into the -current master branch, if any. +current master branch, if any (this is untrue when "--single-branch" +is given; see below). This default configuration is achieved by creating references to the remote branch heads under `refs/remotes/origin` and @@ -41,17 +43,22 @@ OPTIONS --local:: -l:: When the repository to clone from is on a local machine, - this flag bypasses the normal "git aware" transport + this flag bypasses the normal "Git aware" transport mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under `.git/objects/` directory are hardlinked - to save space when possible. This is now the default when - the source repository is specified with `/path/to/repo` - syntax, so it essentially is a no-op option. To force - copying instead of hardlinking (which may be desirable - if you are trying to make a back-up of your repository), - but still avoid the usual "git aware" transport - mechanism, `--no-hardlinks` can be used. + to save space when possible. ++ +If the repository is specified as a local path (e.g., `/path/to/repo`), +this is the default, and --local is essentially a no-op. If the +repository is specified as a URL, then this flag is ignored (and we +never use the local optimizations). Specifying `--no-local` will +override the default when `/path/to/repo` is given, using the regular +Git transport instead. ++ +To force copying instead of hardlinking (which may be desirable if you +are trying to make a back-up of your repository), but still avoid the +usual "Git aware" transport mechanism, `--no-hardlinks` can be used. --no-hardlinks:: Optimize the cloning process from a repository on a @@ -69,9 +76,9 @@ OPTIONS *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 +other Git command that makes any existing commit unreferenced) in the source repository, some objects may become unreferenced (or dangling). -These objects may be removed by normal git operations (such as `git commit`) +These objects may be removed by normal Git operations (such as `git commit`) which automatically call `git gc --auto`. (See linkgit:git-gc[1].) If these objects are removed and were referenced by the cloned repository, then the cloned repository will become corrupt. @@ -118,7 +125,7 @@ objects from the source repository into a pack in the cloned repository. No checkout of HEAD is performed after the clone is complete. --bare:: - Make a 'bare' GIT repository. That is, instead of + Make a 'bare' Git repository. That is, instead of creating `<directory>` and placing the administrative files in `<directory>/.git`, make the `<directory>` itself the `$GIT_DIR`. This obviously implies the `-n` @@ -148,6 +155,8 @@ objects from the source repository into a pack in the cloned repository. to by the cloned repository's HEAD, point to `<name>` branch instead. In a non-bare repository, this is the branch that will be checked out. + `--branch` can also take tags and detaches the HEAD at that commit + in the resulting repository. --upload-pack <upload-pack>:: -u <upload-pack>:: @@ -159,14 +168,33 @@ objects from the source repository into a pack in the cloned repository. Specify the directory from which templates will be used; (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) +--config <key>=<value>:: +-c <key>=<value>:: + Set a configuration variable in the newly-created repository; + this takes effect immediately after the repository is + initialized, but before the remote history is fetched or any + files checked out. The key is in the same format as expected by + linkgit:git-config[1] (e.g., `core.eol=true`). If multiple + values are given for the same key, each value will be written to + the config file. This makes it safe, for example, to add + additional fetch refspecs to the origin remote. + --depth <depth>:: Create a 'shallow' clone with a history truncated to the - 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 - are only interested in the recent history of a large project - with a long history, and would want to send in fixes - as patches. + specified number of revisions. + +--[no-]single-branch:: + Clone only the history leading to the tip of a single branch, + either specified by the `--branch` option or the primary + branch remote's `HEAD` points at. When creating a shallow + clone with the `--depth` option, this is the default, unless + `--no-single-branch` is given to fetch the histories near the + tips of all branches. + Further fetches into the resulting repository will only update the + remote-tracking branch for the branch this option was used for the + initial cloning. If the HEAD at the remote did not point at any + branch when `--single-branch` clone was made, no remote-tracking + branch is created. --recursive:: --recurse-submodules:: @@ -180,8 +208,8 @@ objects from the source repository into a pack in the cloned repository. --separate-git-dir=<git dir>:: Instead of placing the cloned repository where it is supposed to be, place the cloned repository at the specified directory, - then make a filesytem-agnostic git symbolic link to there. - The result is git repository can be separated from working + then make a filesystem-agnostic Git symbolic link to there. + The result is Git repository can be separated from working tree. @@ -206,8 +234,8 @@ Examples * Clone from upstream: + ------------ -$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 -$ cd my2.6 +$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux +$ cd my-linux $ make ------------ @@ -224,10 +252,10 @@ $ git show-branch * Clone from upstream while borrowing from an existing local directory: + ------------ -$ git clone --reference my2.6 \ - git://git.kernel.org/pub/scm/.../linux-2.7 \ - my2.7 -$ cd my2.7 +$ git clone --reference /git/linux.git \ + git://git.kernel.org/pub/scm/.../linux.git \ + my-linux +$ cd my-linux ------------ @@ -238,13 +266,6 @@ $ git clone --bare -l /home/proj/.git /pub/scm/proj.git ------------ -* Create a repository on the kernel.org machine that borrows from Linus: -+ ------------- -$ git clone --bare -l -s /pub/scm/.../torvalds/linux-2.6.git \ - /pub/scm/.../me/subsys-2.6.git ------------- - GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-column.txt b/Documentation/git-column.txt new file mode 100644 index 000000000..03d18465d --- /dev/null +++ b/Documentation/git-column.txt @@ -0,0 +1,48 @@ +git-column(1) +============= + +NAME +---- +git-column - Display data in columns + +SYNOPSIS +-------- +[verse] +'git column' [--command=<name>] [--[raw-]mode=<mode>] [--width=<width>] + [--indent=<string>] [--nl=<string>] [--padding=<n>] + +DESCRIPTION +----------- +This command formats its input into multiple columns. + +OPTIONS +------- +--command=<name>:: + Look up layout mode using configuration variable column.<name> and + column.ui. + +--mode=<mode>:: + Specify layout mode. See configuration variable column.ui for option + syntax. + +--raw-mode=<n>:: + Same as --mode but take mode encoded as a number. This is mainly used + by other commands that have already parsed layout mode. + +--width=<width>:: + Specify the terminal width. By default 'git column' will detect the + terminal width, or fall back to 80 if it is unable to do so. + +--indent=<string>:: + String to be printed at the beginning of each line. + +--nl=<N>:: + String to be printed at the end of each line, + including newline character. + +--padding=<N>:: + The number of spaces between columns. One space by default. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt index 0fdb82ee8..a469eab06 100644 --- a/Documentation/git-commit-tree.txt +++ b/Documentation/git-commit-tree.txt @@ -9,7 +9,10 @@ git-commit-tree - Create a new commit object SYNOPSIS -------- [verse] -'git commit-tree' <tree> [(-p <parent commit>)...] < changelog +'git commit-tree' <tree> [(-p <parent>)...] < changelog +'git commit-tree' [(-p <parent>)...] [-S[<keyid>]] [(-m <message>)...] + [(-F <file>)...] <tree> + DESCRIPTION ----------- @@ -17,7 +20,8 @@ This is usually not what an end user wants to run directly. See 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. +emits the new commit object id on stdout. The log message is read +from the standard input, unless `-m` or `-F` options are given. A commit object may have any number of parents. With exactly one parent, it is an ordinary commit. Having more than one parent makes @@ -28,7 +32,7 @@ While a tree represents a particular directory state of a working directory, a commit represents that state in "time", and explains how to get there. -Normally a commit would identify a new "HEAD" state, and while git +Normally a commit would identify 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 that is pointed at by `.git/HEAD`, so that we can always see what the last committed @@ -39,9 +43,25 @@ OPTIONS <tree>:: An existing tree object --p <parent commit>:: +-p <parent>:: Each '-p' indicates the id of a parent commit object. +-m <message>:: + A paragraph in the commit log message. This can be given more than + once and each <message> becomes its own paragraph. + +-F <file>:: + Read the commit log message from the given file. Use `-` to read + from the standard input. + +-S[<keyid>]:: +--gpg-sign[=<keyid>]:: + GPG-sign commit. + +--no-gpg-sign:: + Countermand `commit.gpgsign` configuration variable that is + set to force each and every commit to be signed. + Commit Information ------------------ @@ -62,13 +82,15 @@ if set: GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL GIT_COMMITTER_DATE - EMAIL (nb "<", ">" and "\n"s are stripped) In case (some of) these environment variables are not set, the information is taken from the configuration items user.name and user.email, or, if not -present, system user name and fully qualified hostname. +present, the environment variable EMAIL, or, if that is not set, +system user name and the hostname used for outgoing mail (taken +from `/etc/mailname` and falling back to the fully qualified hostname when +that file does not exist). A commit comment is read from stdin. If a changelog entry is not provided via "<" redirection, 'git commit-tree' will just wait @@ -76,20 +98,15 @@ for one to be entered and terminated with ^D. include::date-formats.txt[] -Diagnostics ------------ -You don't exist. Go away!:: - The passwd(5) gecos field couldn't be read -Your parents must have hated you!:: - The passwd(5) gecos field is longer than a giant static buffer. -Your sysadmin must hate you!:: - The passwd(5) name field is longer than a giant static buffer. - Discussion ---------- include::i18n.txt[] +FILES +----- +/etc/mailname + SEE ALSO -------- linkgit:git-write-tree[1] diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 5cc84a139..7c42e9cab 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -12,8 +12,8 @@ SYNOPSIS [--dry-run] [(-c | -C | --fixup | --squash) <commit>] [-F <file> | -m <msg>] [--reset-author] [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=<author>] - [--date=<date>] [--cleanup=<mode>] [--status | --no-status] - [-i | -o] [--] [<file>...] + [--date=<date>] [--cleanup=<mode>] [--[no-]status] + [-i | -o] [-S[<keyid>]] [--] [<file>...] DESCRIPTION ----------- @@ -32,7 +32,7 @@ The content to be added can be specified in several ways: 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 (which must already - be known to git); + 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 @@ -42,7 +42,7 @@ The content to be added can be specified in several ways: 5. by using the --interactive or --patch switches with the 'commit' command to decide one by one which files or hunks should be part of the commit, - before finalizing the operation. See the ``Interactive Mode`` section of + before finalizing the operation. See the ``Interactive Mode'' section of linkgit:git-add[1] to learn how to operate these modes. The `--dry-run` option can be used to obtain a @@ -59,7 +59,7 @@ OPTIONS --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. + told Git about are not affected. -p:: --patch:: @@ -101,12 +101,20 @@ OPTIONS When doing a dry-run, give the output in the short-format. See linkgit:git-status[1] for details. Implies `--dry-run`. +--branch:: + Show the branch and tracking info even in short-format. + --porcelain:: When doing a dry-run, give the output in a porcelain-ready format. See linkgit:git-status[1] for details. Implies `--dry-run`. +--long:: + When doing a dry-run, give the output in a the long-format. + Implies `--dry-run`. + -z:: +--null:: When showing `short` or `porcelain` status output, terminate entries in the status output with NUL, instead of LF. If no format is given, implies the `--porcelain` output format. @@ -129,14 +137,19 @@ OPTIONS -m <msg>:: --message=<msg>:: Use the given <msg> as the commit message. + If multiple `-m` options are given, their values are + concatenated as separate paragraphs. -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. + When editing the commit message, start the editor with the + contents in the given file. The `commit.template` configuration + variable is often used to give this option implicitly to the + command. This mechanism can be used by projects that want to + guide participants with some hints on what to write in the message + in what order. If the user exits the editor without editing the + message, the commit is aborted. This has no effect when a message + is given by other means, e.g. with the `-m` or `-F` options. -s:: --signoff:: @@ -161,31 +174,48 @@ OPTIONS linkgit:git-commit-tree[1]. --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. + This option determines how the supplied commit message should be + cleaned up before committing. The '<mode>' can be `strip`, + `whitespace`, `verbatim`, or `default`. ++ +-- +strip:: + Strip leading and trailing empty lines, trailing whitespace, and + #commentary and collapse consecutive empty lines. +whitespace:: + Same as `strip` except #commentary is not removed. +verbatim:: + Do not change the message at all. +default:: + Same as `strip` if the message is to be edited. + Otherwise `whitespace`. +-- ++ +The default can be changed by the 'commit.cleanup' configuration +variable (see linkgit:git-config[1]). -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 + `-m`, and from commit object with `-C` are usually used as + the commit log message unmodified. This option lets you further edit the message taken from these sources. +--no-edit:: + Use the selected commit message without launching an editor. + For example, `git commit --amend --no-edit` amends a commit + without changing its commit message. + --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 - commit log editor is seeded with the commit message from the - tip of the current branch. The commit you create replaces the - current tip -- if it was a merge, it will have the parents of - the current tip as parents -- so the current top commit is - discarded. + Replace the tip of the current branch by creating a new + commit. The recorded tree is prepared as usual (including + the effect of the `-i` and `-o` options and explicit + pathspec), and the message from the original commit is used + as the starting point, instead of an empty message, when no + other message is specified from the command line via options + such as `-m`, `-F`, `-c`, etc. The new commit has the same + parents and author as the current one (the `--reset-author` + option can countermand this). + -- It is a rough equivalent for: @@ -202,6 +232,9 @@ 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].) +--no-post-rewrite:: + Bypass the post-rewrite hook. + -i:: --include:: Before making a commit out of staged contents so far, @@ -265,6 +298,14 @@ configuration variable documented in linkgit:git-config[1]. commit message template when using an editor to prepare the default commit message. +-S[<keyid>]:: +--gpg-sign[=<keyid>]:: + GPG-sign commit. + +--no-gpg-sign:: + Countermand `commit.gpgsign` configuration variable that is + set to force each and every commit to be signed. + \--:: Do not interpret any more arguments as options. @@ -284,7 +325,7 @@ When recording your own work, the contents of modified files in your working tree are temporarily stored to a staging area called the "index" with 'git add'. A file can be reverted back, only in the index but not in the working tree, -to that of the last commit with `git reset HEAD \-- <file>`, +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, @@ -378,8 +419,10 @@ DISCUSSION Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. -Tools that turn commits into email, for example, use the first line -on the Subject: line and the rest of the commit in the body. +The text up to the first blank line in a commit message is treated +as the commit title, and that title is used throughout Git. +For example, linkgit:git-format-patch[1] turns a commit into email, and it uses +the title on the Subject line and the rest of the commit in the body. include::i18n.txt[] @@ -396,6 +439,15 @@ This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`, and `post-commit` hooks. See linkgit:githooks[5] for more information. +FILES +----- + +`$GIT_DIR/COMMIT_EDITMSG`:: + This file contains the commit message of a commit in progress. + If `git commit` exits due to an error before creating a commit, + any commit message that has been provided by the user (e.g., in + an editor session) will be available in this file, but will be + overwritten by the next invocation of `git commit`. SEE ALSO -------- diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index e7ecf5d80..e9917b89a 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -15,6 +15,7 @@ SYNOPSIS '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>] [type] [-z|--null] --get-urlmatch name URL '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 @@ -44,22 +45,26 @@ a "true" or "false" string for bool), or '--path', which does some path expansion (see '--path' below). If no type specifier is passed, no checks or transformations are performed on the value. -The file-option can be one of '--system', '--global' or '--file' -which specify where the values will be read from or written to. -The default is to assume the config file of the current repository, -.git/config unless defined otherwise with GIT_DIR and GIT_CONFIG -(see <<FILES>>). +When reading, the values are read from the system, global and +repository local configuration files by default, and options +'--system', '--global', '--local' and '--file <filename>' can be +used to tell the command to read from only that location (see <<FILES>>). -This command will fail (with exit code ret) if: +When writing, the new value is written to the repository local +configuration file by default, and options '--system', '--global', +'--file <filename>' can be used to tell the command to write to +that location (you can say '--local' but that is the default). + +This command will fail with non-zero status upon error. Some exit +codes are: . The config file is invalid (ret=3), . can not write to the config file (ret=4), . no section or name was provided (ret=2), . the section or key is invalid (ret=1), . you try to unset an option which does not exist (ret=5), -. you try to unset/set an option for which multiple lines match (ret=5), -. you try to use an invalid regexp (ret=6), or -. you use '--global' option without $HOME being properly set (ret=128). +. you try to unset/set an option for which multiple lines match (ret=5), or +. you try to use an invalid regexp (ret=6). On success, the command returns the exit code 0. @@ -78,38 +83,68 @@ OPTIONS --get:: Get the value for a given key (optionally filtered by a regex matching the value). Returns error code 1 if the key was not - found and error code 2 if multiple key values were found. + found and the last value if multiple key values were found. --get-all:: Like get, but does not fail if the number of values for the key is not exactly one. --get-regexp:: - Like --get-all, but interprets the name as a regular expression. - Also outputs the key names. + Like --get-all, but interprets the name as a regular expression and + writes out the key names. Regular expression matching is currently + case-sensitive and done against a canonicalized version of the key + in which section and variable names are lowercased, but subsection + names are not. + +--get-urlmatch name URL:: + When given a two-part name section.key, the value for + section.<url>.key whose <url> part matches the best to the + given URL is returned (if no such key exists, the value for + section.key is used as a fallback). When given just the + section as name, do so for all the keys in the section and + list them. --global:: - For writing options: write to global ~/.gitconfig file rather than - the repository .git/config. + For writing options: write to global `~/.gitconfig` file + rather than the repository `.git/config`, write to + `$XDG_CONFIG_HOME/git/config` file if this file exists and the + `~/.gitconfig` file doesn't. + -For reading options: read only from global ~/.gitconfig rather than -from all available files. +For reading options: read only from global `~/.gitconfig` and from +`$XDG_CONFIG_HOME/git/config` rather than from all available files. + See also <<FILES>>. --system:: - For writing options: write to system-wide $(prefix)/etc/gitconfig - rather than the repository .git/config. + For writing options: write to system-wide + `$(prefix)/etc/gitconfig` rather than the repository + `.git/config`. + -For reading options: read only from system-wide $(prefix)/etc/gitconfig +For reading options: read only from system-wide `$(prefix)/etc/gitconfig` rather than from all available files. + See also <<FILES>>. +--local:: + For writing options: write to the repository `.git/config` file. + This is the default behavior. ++ +For reading options: read only from the repository `.git/config` rather than +from all available files. ++ +See also <<FILES>>. + -f config-file:: --file config-file:: Use the given config file instead of the one specified by GIT_CONFIG. +--blob blob:: + Similar to '--file' but use the given blob instead of a file. E.g. + you can use 'master:.gitmodules' to read values from the file + '.gitmodules' in the master branch. See "SPECIFYING REVISIONS" + section in linkgit:gitrevisions[7] for a more complete list of + ways to spell blob names. + --remove-section:: Remove the given section from the configuration file. @@ -178,24 +213,34 @@ See also <<FILES>>. Opens an editor to modify the specified config file; either '--system', '--global', or repository (default). +--[no-]includes:: + Respect `include.*` directives in config files when looking up + values. Defaults to on. + [[FILES]] FILES ----- -If not set explicitly with '--file', there are three files where +If not set explicitly with '--file', there are four files where 'git config' will search for configuration options: -$GIT_DIR/config:: - Repository specific configuration file. (The filename is - of course relative to the repository root, not the working - directory.) +$(prefix)/etc/gitconfig:: + System-wide configuration file. + +$XDG_CONFIG_HOME/git/config:: + Second user-specific configuration file. If $XDG_CONFIG_HOME is not set + or empty, `$HOME/.config/git/config` will be used. Any single-valued + variable set in this file will be overwritten by whatever is in + `~/.gitconfig`. It is a good idea not to create this file if + you sometimes use older versions of Git, as support for this + file was added fairly recently. ~/.gitconfig:: User-specific configuration file. Also called "global" configuration file. -$(prefix)/etc/gitconfig:: - System-wide configuration file. +$GIT_DIR/config:: + Repository specific configuration file. 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 @@ -203,6 +248,10 @@ 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 error code. However, in neither case will an error message be issued. +The files are read in the order given above, with last value found taking +precedence over values read earlier. When multiple values are taken then all +values of a key from all files will be used. + 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*. @@ -221,6 +270,10 @@ GIT_CONFIG:: Using the "--global" option forces this to ~/.gitconfig. Using the "--system" option forces this to $(prefix)/etc/gitconfig. +GIT_CONFIG_NOSYSTEM:: + Whether to skip reading settings from the system-wide + $(prefix)/etc/gitconfig file. See linkgit:git[1] for details. + See also <<FILES>>. @@ -248,9 +301,16 @@ Given a .git/config like this: ; Proxy settings [core] - gitproxy="proxy-command" for kernel.org + gitproxy=proxy-command for kernel.org gitproxy=default-proxy ; for all the rest + ; HTTP + [http] + sslVerify + [http "https://weak.example.com"] + sslVerify = false + cookieFile = /tmp/cookie.txt + you can set the filemode to true with ------------ @@ -323,7 +383,7 @@ To actually match only values with an exclamation mark, you have to To add a new proxy, without altering any of the existing ones, use ------------ -% git config core.gitproxy '"proxy-command" for example.com' +% git config --add core.gitproxy '"proxy-command" for example.com' ------------ An example to use customized color from the configuration in your @@ -336,6 +396,19 @@ RESET=$(git config --get-color "" "reset") echo "${WS}your whitespace color or blue reverse${RESET}" ------------ +For URLs in `https://weak.example.com`, `http.sslVerify` is set to +false, while it is set to `true` for all others: + +------------ +% git config --bool --get-urlmatch http.sslverify https://good.example.com +true +% git config --bool --get-urlmatch http.sslverify https://weak.example.com +false +% git config --get-urlmatch http https://weak.example.com +http.cookiefile /tmp/cookie.txt +http.sslverify false +------------ + include::config.txt[] GIT diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt index 23c80cea6..b300e846f 100644 --- a/Documentation/git-count-objects.txt +++ b/Documentation/git-count-objects.txt @@ -8,7 +8,7 @@ git-count-objects - Count unpacked number of objects and their disk consumption SYNOPSIS -------- [verse] -'git count-objects' [-v] +'git count-objects' [-v] [-H | --human-readable] DESCRIPTION ----------- @@ -20,11 +20,29 @@ 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, disk space consumed by those packs, - and number of objects that can be removed by running - `git prune-packed`. + Report in more detail: ++ +count: the number of loose objects ++ +size: disk space consumed by loose objects, in KiB (unless -H is specified) ++ +in-pack: the number of in-pack objects ++ +size-pack: disk space consumed by the packs, in KiB (unless -H is specified) ++ +prune-packable: the number of loose objects that are also present in +the packs. These objects could be pruned using `git prune-packed`. ++ +garbage: the number of files in object database that are not valid +loose objects nor valid packs ++ +size-garbage: disk space consumed by garbage files, in KiB (unless -H is +specified) + +-H:: +--human-readable:: + +Print sizes in human readable format GIT --- diff --git a/Documentation/git-credential-cache--daemon.txt b/Documentation/git-credential-cache--daemon.txt new file mode 100644 index 000000000..d15db42d4 --- /dev/null +++ b/Documentation/git-credential-cache--daemon.txt @@ -0,0 +1,26 @@ +git-credential-cache--daemon(1) +=============================== + +NAME +---- +git-credential-cache--daemon - Temporarily store user credentials in memory + +SYNOPSIS +-------- +[verse] +git credential-cache--daemon <socket> + +DESCRIPTION +----------- + +NOTE: You probably don't want to invoke this command yourself; it is +started automatically when you use linkgit:git-credential-cache[1]. + +This command listens on the Unix domain socket specified by `<socket>` +for `git-credential-cache` clients. Clients may store and retrieve +credentials. Each credential is held for a timeout specified by the +client; once no credentials are held, the daemon exits. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-credential-cache.txt b/Documentation/git-credential-cache.txt new file mode 100644 index 000000000..89b730632 --- /dev/null +++ b/Documentation/git-credential-cache.txt @@ -0,0 +1,77 @@ +git-credential-cache(1) +======================= + +NAME +---- +git-credential-cache - Helper to temporarily store passwords in memory + +SYNOPSIS +-------- +----------------------------- +git config credential.helper 'cache [options]' +----------------------------- + +DESCRIPTION +----------- + +This command caches credentials in memory for use by future Git +programs. The stored credentials never touch the disk, and are forgotten +after a configurable timeout. The cache is accessible over a Unix +domain socket, restricted to the current user by filesystem permissions. + +You probably don't want to invoke this command directly; it is meant to +be used as a credential helper by other parts of Git. See +linkgit:gitcredentials[7] or `EXAMPLES` below. + +OPTIONS +------- + +--timeout <seconds>:: + + Number of seconds to cache credentials (default: 900). + +--socket <path>:: + + Use `<path>` to contact a running cache daemon (or start a new + cache daemon if one is not started). Defaults to + `~/.git-credential-cache/socket`. If your home directory is on a + network-mounted filesystem, you may need to change this to a + local filesystem. + +CONTROLLING THE DAEMON +---------------------- + +If you would like the daemon to exit early, forgetting all cached +credentials before their timeout, you can issue an `exit` action: + +-------------------------------------- +git credential-cache exit +-------------------------------------- + +EXAMPLES +-------- + +The point of this helper is to reduce the number of times you must type +your username or password. For example: + +------------------------------------ +$ git config credential.helper cache +$ git push http://example.com/repo.git +Username: <type your username> +Password: <type your password> + +[work for 5 more minutes] +$ git push http://example.com/repo.git +[your credentials are used automatically] +------------------------------------ + +You can provide options via the credential.helper configuration +variable (this example drops the cache time to 5 minutes): + +------------------------------------------------------- +$ git config credential.helper 'cache --timeout=300' +------------------------------------------------------- + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-credential-store.txt b/Documentation/git-credential-store.txt new file mode 100644 index 000000000..8481cae70 --- /dev/null +++ b/Documentation/git-credential-store.txt @@ -0,0 +1,75 @@ +git-credential-store(1) +======================= + +NAME +---- +git-credential-store - Helper to store credentials on disk + +SYNOPSIS +-------- +------------------- +git config credential.helper 'store [options]' +------------------- + +DESCRIPTION +----------- + +NOTE: Using this helper will store your passwords unencrypted on disk, +protected only by filesystem permissions. If this is not an acceptable +security tradeoff, try linkgit:git-credential-cache[1], or find a helper +that integrates with secure storage provided by your operating system. + +This command stores credentials indefinitely on disk for use by future +Git programs. + +You probably don't want to invoke this command directly; it is meant to +be used as a credential helper by other parts of git. See +linkgit:gitcredentials[7] or `EXAMPLES` below. + +OPTIONS +------- + +--store=<path>:: + + Use `<path>` to store credentials. The file will have its + filesystem permissions set to prevent other users on the system + from reading it, but will not be encrypted or otherwise + protected. Defaults to `~/.git-credentials`. + +EXAMPLES +-------- + +The point of this helper is to reduce the number of times you must type +your username or password. For example: + +------------------------------------------ +$ git config credential.helper store +$ git push http://example.com/repo.git +Username: <type your username> +Password: <type your password> + +[several days later] +$ git push http://example.com/repo.git +[your credentials are used automatically] +------------------------------------------ + +STORAGE FORMAT +-------------- + +The `.git-credentials` file is stored in plaintext. Each credential is +stored on its own line as a URL like: + +------------------------------ +https://user:pass@example.com +------------------------------ + +When Git needs authentication for a particular URL context, +credential-store will consider that context a pattern to match against +each entry in the credentials file. If the protocol, hostname, and +username (if we already have one) match, then the password is returned +to Git. See the discussion of configuration in linkgit:gitcredentials[7] +for more information. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt new file mode 100644 index 000000000..b21144037 --- /dev/null +++ b/Documentation/git-credential.txt @@ -0,0 +1,154 @@ +git-credential(1) +================= + +NAME +---- +git-credential - Retrieve and store user credentials + +SYNOPSIS +-------- +------------------ +git credential <fill|approve|reject> +------------------ + +DESCRIPTION +----------- + +Git has an internal interface for storing and retrieving credentials +from system-specific helpers, as well as prompting the user for +usernames and passwords. The git-credential command exposes this +interface to scripts which may want to retrieve, store, or prompt for +credentials in the same manner as Git. The design of this scriptable +interface models the internal C API; see +link:technical/api-credentials.html[the Git credential API] for more +background on the concepts. + +git-credential takes an "action" option on the command-line (one of +`fill`, `approve`, or `reject`) and reads a credential description +on stdin (see <<IOFMT,INPUT/OUTPUT FORMAT>>). + +If the action is `fill`, git-credential will attempt to add "username" +and "password" attributes to the description by reading config files, +by contacting any configured credential helpers, or by prompting the +user. The username and password attributes of the credential +description are then printed to stdout together with the attributes +already provided. + +If the action is `approve`, git-credential will send the description +to any configured credential helpers, which may store the credential +for later use. + +If the action is `reject`, git-credential will send the description to +any configured credential helpers, which may erase any stored +credential matching the description. + +If the action is `approve` or `reject`, no output should be emitted. + +TYPICAL USE OF GIT CREDENTIAL +----------------------------- + +An application using git-credential will typically use `git +credential` following these steps: + + 1. Generate a credential description based on the context. ++ +For example, if we want a password for +`https://example.com/foo.git`, we might generate the following +credential description (don't forget the blank line at the end; it +tells `git credential` that the application finished feeding all the +information it has): + + protocol=https + host=example.com + path=foo.git + + 2. Ask git-credential to give us a username and password for this + description. This is done by running `git credential fill`, + feeding the description from step (1) to its standard input. The complete + credential description (including the credential per se, i.e. the + login and password) will be produced on standard output, like: + + protocol=https + host=example.com + username=bob + password=secr3t ++ +In most cases, this means the attributes given in the input will be +repeated in the output, but Git may also modify the credential +description, for example by removing the `path` attribute when the +protocol is HTTP(s) and `credential.useHttpPath` is false. ++ +If the `git credential` knew about the password, this step may +not have involved the user actually typing this password (the +user may have typed a password to unlock the keychain instead, +or no user interaction was done if the keychain was already +unlocked) before it returned `password=secr3t`. + + 3. Use the credential (e.g., access the URL with the username and + password from step (2)), and see if it's accepted. + + 4. Report on the success or failure of the password. If the + credential allowed the operation to complete successfully, then + it can be marked with an "approve" action to tell `git + credential` to reuse it in its next invocation. If the credential + was rejected during the operation, use the "reject" action so + that `git credential` will ask for a new password in its next + invocation. In either case, `git credential` should be fed with + the credential description obtained from step (2) (which also + contain the ones provided in step (1)). + +[[IOFMT]] +INPUT/OUTPUT FORMAT +------------------- + +`git credential` reads and/or writes (depending on the action used) +credential information in its standard input/output. This information +can correspond either to keys for which `git credential` will obtain +the login/password information (e.g. host, protocol, path), or to the +actual credential data to be obtained (login/password). + +The credential is split into a set of named attributes, with one +attribute per line. Each attribute is +specified by a key-value pair, separated by an `=` (equals) sign, +followed by a newline. The key may contain any bytes except `=`, +newline, or NUL. The value may contain any bytes except newline or NUL. +In both cases, all bytes are treated as-is (i.e., there is no quoting, +and one cannot transmit a value with newline or NUL in it). The list of +attributes is terminated by a blank line or end-of-file. +Git understands the following attributes: + +`protocol`:: + + The protocol over which the credential will be used (e.g., + `https`). + +`host`:: + + The remote hostname for a network credential. + +`path`:: + + The path with which the credential will be used. E.g., for + accessing a remote https repository, this will be the + repository's path on the server. + +`username`:: + + The credential's username, if we already have one (e.g., from a + URL, from the user, or from a previously run helper). + +`password`:: + + The credential's password, if we are asking it to be stored. + +`url`:: + + When this special attribute is read by `git credential`, the + value is parsed as a URL and treated as if its constituent parts + were read (e.g., `url=https://example.com` would behave as if + `protocol=https` and `host=example.com` had been provided). This + can help callers avoid parsing URLs themselves. Note that any + components which are missing from the URL (e.g., there is no + username in the example above) will be set to empty; if you want + to provide a URL and override some attributes, provide the URL + attribute first, followed by any overrides. diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt index 7f79cec3f..00154b6c8 100644 --- a/Documentation/git-cvsexportcommit.txt +++ b/Documentation/git-cvsexportcommit.txt @@ -15,8 +15,8 @@ SYNOPSIS DESCRIPTION ----------- -Exports a commit from GIT to a CVS checkout, making it easier -to merge patches from a git repository into a CVS repository. +Exports a commit from Git to a CVS checkout, making it easier +to merge patches from a Git repository into a CVS repository. 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 @@ -71,7 +71,7 @@ OPTIONS -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 + current directory is within a Git repository. The default is the value of 'cvsexportcommit.cvsdir'. -W:: diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index 6695ab3b4..2df995396 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -18,7 +18,13 @@ SYNOPSIS DESCRIPTION ----------- -Imports a CVS repository into git. It will either create a new +*WARNING:* `git cvsimport` uses cvsps version 2, which is considered +deprecated; it does not work with cvsps version 3 and later. If you are +performing a one-shot import of a CVS repository consider using +link:http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or +link:https://github.com/BartMassey/parsecvs[parsecvs]. + +Imports a CVS repository into Git. It will either create a new repository, or incrementally import into an existing one. Splitting the CVS log into patch sets is done by 'cvsps'. @@ -59,18 +65,18 @@ OPTIONS `CVS/Repository`. -C <target-dir>:: - The git repository to import to. If the directory doesn't + The Git repository to import to. If the directory doesn't exist, it will be created. Default is the current directory. -r <remote>:: - The git remote to import this CVS repository into. + The Git remote to import this CVS repository into. Moves all CVS branches into remotes/<remote>/<branch> 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. + 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. Use this option if you want to import into a different @@ -137,17 +143,19 @@ This option can be used several times to provide several detection regexes. -A <author-conv-file>:: CVS by default uses the Unix username when writing its commit logs. Using this option and an author-conv-file - in this format + maps the name recorded in CVS to author name, e-mail and + optional time zone: + --------- exon=Andreas Ericsson <ae@op5.se> - spawn=Simon Pawn <spawn@frog-pond.org> + spawn=Simon Pawn <spawn@frog-pond.org> America/Chicago --------- + 'git cvsimport' will make it appear as those authors had their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly -all along. +all along. If a time zone is specified, GIT_AUTHOR_DATE will +have the corresponding offset applied. + For convenience, this data is saved to `$GIT_DIR/cvs-authors` each time the '-A' option is provided and read from that same @@ -211,11 +219,9 @@ 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: +want to imort, consider using cvs2git: -* cvs2git (part of cvs2svn), `http://cvs2svn.tigris.org` -* parsecvs, `http://cgit.freedesktop.org/~keithp/parsecvs` +* cvs2git (part of cvs2svn), `http://subversion.apache.org/` GIT --- diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt index 827bc988e..472f5cbd0 100644 --- a/Documentation/git-cvsserver.txt +++ b/Documentation/git-cvsserver.txt @@ -3,7 +3,7 @@ git-cvsserver(1) NAME ---- -git-cvsserver - A CVS server emulator for git +git-cvsserver - A CVS server emulator for Git SYNOPSIS -------- @@ -60,7 +60,7 @@ unless '--export-all' was given, too. DESCRIPTION ----------- -This application is a CVS emulation layer for git. +This application is a CVS emulation layer for Git. It is highly functional. However, not all methods are implemented, and for those methods that are implemented, @@ -72,9 +72,9 @@ plugin. Most functionality works fine with both of these clients. LIMITATIONS ----------- -CVS clients cannot tag, branch or perform GIT merges. +CVS clients cannot tag, branch or perform Git merges. -'git-cvsserver' maps GIT branches to CVS modules. This is very different +'git-cvsserver' maps Git branches to CVS modules. This is very different from what most CVS users would expect since in CVS modules usually represent one or more directories. @@ -130,7 +130,7 @@ Then provide your password via the pserver method, for example: ------ cvs -d:pserver:someuser:somepassword <at> server/path/repo.git co <HEAD_name> ------ -No special setup is needed for SSH access, other than having GIT tools +No special setup is needed for SSH access, other than having Git tools in the PATH. If you have clients that do not accept the CVS_SERVER environment variable, you can rename 'git-cvsserver' to `cvs`. @@ -160,9 +160,9 @@ with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean Note: you need to ensure each user that is going to invoke 'git-cvsserver' has write access to the log file and to the database (see <<dbbackend,Database Backend>>. If you want to offer write access over -SSH, the users of course also need write access to the git repository itself. +SSH, the users of course also need write access to the Git repository itself. -You also need to ensure that each repository is "bare" (without a git index +You also need to ensure that each repository is "bare" (without a Git index file) for `cvs commit` to work. See linkgit:gitcvs-migration[7]. [[configaccessmethod]] @@ -181,7 +181,7 @@ allowing access over SSH. 3. If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command, automatically saving it in your 'CVS/Root' files, then you need to set them explicitly in your environment. CVSROOT should be set as per normal, but the - directory should point at the appropriate git repo. As above, for SSH clients + directory should point at the appropriate Git repo. As above, for SSH clients _not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'. + -- @@ -197,7 +197,7 @@ allowing access over SSH. shell is bash, .bashrc may be a reasonable alternative. 5. Clients should now be able to check out the project. Use the CVS 'module' - name to indicate what GIT 'head' you want to check out. This also sets the + name to indicate what Git 'head' you want to check out. This also sets the name of your newly checked-out directory, unless you tell it otherwise with `-d <dir_name>`. For example, this checks out 'master' branch to the `project-master` directory: @@ -210,7 +210,7 @@ allowing access over SSH. Database Backend ---------------- -'git-cvsserver' uses one database per git head (i.e. CVS module) to +'git-cvsserver' uses one database per Git head (i.e. CVS module) to store information about the repository to maintain consistent CVS revision numbers. The database needs to be updated (i.e. written to) after every commit. @@ -225,7 +225,7 @@ the pserver method), 'git-cvsserver' should have write access to the database to work reliably (otherwise you need to make sure that the database is up-to-date any time 'git-cvsserver' is executed). -By default it uses SQLite databases in the git directory, named +By default it uses SQLite databases in the Git directory, named `gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates temporary files in the same directory as the database file on write so it might not be enough to grant the users using @@ -252,7 +252,7 @@ Configuring database backend 'git-cvsserver' uses the Perl DBI module. Please also read its documentation if changing these variables, especially -about `DBI\->connect()`. +about `DBI->connect()`. gitcvs.dbname:: Database name. The exact meaning depends on the @@ -291,14 +291,14 @@ Variable substitution In `dbdriver` and `dbuser` you can use the following variables: %G:: - git directory name + Git directory name %g:: - git directory name, where all characters except for + Git directory name, where all characters except for alpha-numeric ones, `.`, and `-` are replaced with `_` (this should make it easier to use the directory name in a filename if wanted) %m:: - CVS module/git head name + CVS module/Git head name %a:: access method (one of "ext" or "pserver") %u:: @@ -359,6 +359,43 @@ Operations supported All the operations required for normal use are supported, including checkout, diff, status, update, log, add, remove, commit. + +Most CVS command arguments that read CVS tags or revision numbers +(typically -r) work, and also support any git refspec +(tag, branch, commit ID, etc). +However, CVS revision numbers for non-default branches are not well +emulated, and cvs log does not show tags or branches at +all. (Non-main-branch CVS revision numbers superficially resemble CVS +revision numbers, but they actually encode a git commit ID directly, +rather than represent the number of revisions since the branch point.) + +Note that there are two ways to checkout a particular branch. +As described elsewhere on this page, the "module" parameter +of cvs checkout is interpreted as a branch name, and it becomes +the main branch. It remains the main branch for a given sandbox +even if you temporarily make another branch sticky with +cvs update -r. Alternatively, the -r argument can indicate +some other branch to actually checkout, even though the module +is still the "main" branch. Tradeoffs (as currently +implemented): Each new "module" creates a new database on disk with +a history for the given module, and after the database is created, +operations against that main branch are fast. Or alternatively, +-r doesn't take any extra disk space, but may be significantly slower for +many operations, like cvs update. + +If you want to refer to a git refspec that has characters that are +not allowed by CVS, you have two options. First, it may just work +to supply the git refspec directly to the appropriate CVS -r argument; +some CVS clients don't seem to do much sanity checking of the argument. +Second, if that fails, you can use a special character escape mechanism +that only uses characters that are valid in CVS tags. A sequence +of 4 or 5 characters of the form (underscore (`"_"`), dash (`"-"`), +one or two characters, and dash (`"-"`)) can encode various characters based +on the one or two letters: `"s"` for slash (`"/"`), `"p"` for +period (`"."`), `"u"` for underscore (`"_"`), or two hexadecimal digits +for any byte value at all (typically an ASCII number, or perhaps a part +of a UTF-8 encoded character). + Legacy monitoring operations are not supported (edit, watch and related). Exports and tagging (tags and branches) are not supported at this stage. diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt index ebd13be72..223f73152 100644 --- a/Documentation/git-daemon.txt +++ b/Documentation/git-daemon.txt @@ -3,7 +3,7 @@ git-daemon(1) NAME ---- -git-daemon - A really simple server for git repositories +git-daemon - A really simple server for Git repositories SYNOPSIS -------- @@ -16,17 +16,20 @@ SYNOPSIS [--reuseaddr] [--detach] [--pid-file=<file>] [--enable=<service>] [--disable=<service>] [--allow-override=<service>] [--forbid-override=<service>] - [--inetd | [--listen=<host_or_ipaddr>] [--port=<n>] [--user=<user> [--group=<group>]] + [--access-hook=<path>] [--[no-]informative-errors] + [--inetd | + [--listen=<host_or_ipaddr>] [--port=<n>] + [--user=<user> [--group=<group>]]] [<directory>...] DESCRIPTION ----------- -A really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT" +A really simple TCP Git daemon that normally listens on port "DEFAULT_GIT_PORT" aka 9418. It waits for a connection asking for a service, and will serve that service if it is enabled. It verifies that the directory has the magic file "git-daemon-export-ok", and -it will refuse to export any git directory that hasn't explicitly been marked +it will refuse to export any Git directory that hasn't explicitly been marked for export this way (unless the '--export-all' parameter is specified). If you pass some directory paths as 'git daemon' arguments, you can further restrict the offers to a whitelist comprising of those. @@ -36,7 +39,7 @@ By default, only `upload-pack` service is enabled, which serves from 'git fetch', 'git pull', and 'git clone'. This is ideally suited for read-only updates, i.e., pulling from -git repositories. +Git repositories. An `upload-archive` also exists to serve 'git archive'. @@ -50,7 +53,7 @@ OPTIONS --base-path=<path>:: Remap all the path requests as relative to the given path. - This is sort of "GIT root" - if you run 'git daemon' with + This is sort of "Git root" - if you run 'git daemon' with '--base-path=/srv/git' on example.com, then if you later try to pull 'git://example.com/hello.git', 'git daemon' will interpret the path as '/srv/git/hello.git'. @@ -72,7 +75,7 @@ OPTIONS whitelist. --export-all:: - Allow pulling from all directories that look like GIT repositories + Allow pulling from all directories that look like Git repositories (have the 'objects' and 'refs' subdirectories), even if they do not have the 'git-daemon-export-ok' file. @@ -93,14 +96,14 @@ OPTIONS Listen on an alternative port. Incompatible with '--inetd' option. --init-timeout=<n>:: - Timeout between the moment the connection is established and the - client request is received (typically a rather low value, since + Timeout (in seconds) between the moment the connection is established + and the client request is received (typically a rather low value, since that should be basically immediate). --timeout=<n>:: - Timeout for specific client sub-requests. This includes the time - it takes for the server to process the sub-request and the time spent - waiting for the next client's request. + Timeout (in seconds) for specific client sub-requests. This includes + the time it takes for the server to process the sub-request and the + time spent waiting for the next client's request. --max-connections=<n>:: Maximum number of concurrent clients, defaults to 32. Set it to @@ -146,6 +149,13 @@ OPTIONS Giving these options is an error when used with `--inetd`; use the facility of inet daemon to achieve the same before spawning 'git daemon' if needed. ++ +Like many programs that switch user id, the daemon does not reset +environment variables such as `$HOME` when it runs git programs, +e.g. `upload-pack` and `receive-pack`. When using this option, you +may also want to set and export `HOME` to point at the home +directory of `<user>` before starting the daemon, and make sure any +Git configuration files in that directory are readable by `<user>`. --enable=<service>:: --disable=<service>:: @@ -161,6 +171,30 @@ the facility of inet daemon to achieve the same before spawning repository configuration. By default, all the services are overridable. +--[no-]informative-errors:: + When informative errors are turned on, git-daemon will report + more verbose errors to the client, differentiating conditions + like "no such repository" from "repository not exported". This + is more convenient for clients, but may leak information about + the existence of unexported repositories. When informative + errors are not enabled, all errors report "access denied" to the + client. The default is --no-informative-errors. + +--access-hook=<path>:: + Every time a client connects, first run an external command + specified by the <path> with service name (e.g. "upload-pack"), + path to the repository, hostname (%H), canonical hostname + (%CH), ip address (%IP), and tcp port (%P) as its command line + arguments. The external command can decide to decline the + service by exiting with a non-zero status (or to allow it by + exiting with a zero status). It can also look at the $REMOTE_ADDR + and $REMOTE_PORT environment variables to learn about the + requestor when making this decision. ++ +The external command can optionally write a single line to its +standard output to be sent to the requestor as an error message when +it declines the service. + <directory>:: A directory to add to the whitelist of allowed directories. Unless --strict-paths is specified this will also include subdirectories @@ -194,7 +228,7 @@ receive-pack:: can push anything into the repository, including removal of refs). This is solely meant for a closed LAN setting where everybody is friendly. This service can be - enabled by `daemon.receivepack` configuration item to + enabled by setting `daemon.receivepack` configuration item to `true`. EXAMPLES diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt index 039cce2e9..d20ca402a 100644 --- a/Documentation/git-describe.txt +++ b/Documentation/git-describe.txt @@ -9,7 +9,7 @@ git-describe - Show the most recent tag that is reachable from a commit SYNOPSIS -------- [verse] -'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>... +'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <commit-ish>... 'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>] DESCRIPTION @@ -26,8 +26,8 @@ see the -a and -s options to linkgit:git-tag[1]. OPTIONS ------- -<committish>...:: - Committish object names to describe. +<commit-ish>...:: + Commit-ish object names to describe. --dirty[=<mark>]:: Describe the working tree. @@ -36,12 +36,12 @@ OPTIONS --all:: Instead of using only the annotated tags, use any ref - found in `.git/refs/`. This option enables matching + found in `refs/` namespace. This option enables matching any known branch, remote-tracking branch, or lightweight tag. --tags:: Instead of using only the annotated tags, use any tag - found in `.git/refs/tags`. This option enables matching + found in `refs/tags` namespace. This option enables matching a lightweight (non-annotated) tag. --contains:: @@ -57,7 +57,7 @@ OPTIONS --candidates=<n>:: Instead of considering only the 10 most recent tags as - candidates to describe the input committish consider + candidates to describe the input commit-ish consider up to <n> candidates. Increasing <n> above 10 will take slightly longer but may produce a more accurate result. An <n> of 0 will cause only exact matches to be output. @@ -81,12 +81,18 @@ OPTIONS that points at object deadbee....). --match <pattern>:: - Only consider tags matching the given pattern (can be used to avoid - leaking private tags made from the repository). + Only consider tags matching the given `glob(7)` pattern, + excluding the "refs/tags/" prefix. This can be used to avoid + leaking private tags from the repository. --always:: Show uniquely abbreviated commit object as fallback. +--first-parent:: + Follow only the first parent commit upon seeing a merge commit. + This is useful when you wish to not match tags on branches merged + in the history of the target commit. + EXAMPLES -------- @@ -131,7 +137,7 @@ closest tagname without any suffix: Note that the suffix you get if you type these commands today may be longer than what Linus saw above when he ran these commands, as your -git repository may have new commits whose object names begin with +Git repository may have new commits whose object names begin with 975b that did not exist back then, and "-g975b" suffix alone may not be sufficient to disambiguate these commits. @@ -139,7 +145,7 @@ be sufficient to disambiguate these commits. SEARCH STRATEGY --------------- -For each committish supplied, 'git describe' will first look for +For each commit-ish supplied, 'git describe' will first look for a tag which tags exactly that commit. Annotated tags will always be preferred over lightweight tags, and tags with newer dates will always be preferred over tags with older dates. If an exact match @@ -148,10 +154,12 @@ is found, its name will be output and searching will stop. If an exact match was not found, 'git describe' will walk back through the commit history to locate an ancestor commit which has been tagged. The ancestor's tag will be output along with an -abbreviation of the input committish's SHA1. +abbreviation of the input commit-ish's SHA-1. If '--first-parent' was +specified then the walk will only consider the first parent of each +commit. If multiple tags were found during the walk then the tag which -has the fewest commits different from the input committish will be +has the fewest commits different from the input commit-ish will be selected and output. Here fewest commits different is defined as the number of commits which would be shown by `git log tag..input` will be the smallest number of commits possible. diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt index c0b7c581a..a86cf62e6 100644 --- a/Documentation/git-diff-index.txt +++ b/Documentation/git-diff-index.txt @@ -3,7 +3,7 @@ git-diff-index(1) NAME ---- -git-diff-index - Compares content and mode of blobs between the index and repository +git-diff-index - Compare a tree to the working tree or index SYNOPSIS @@ -13,11 +13,11 @@ SYNOPSIS DESCRIPTION ----------- -Compares the content and mode of the blobs found via a tree -object with the content of the current index and, optionally -ignoring the stat state of the file on disk. When paths are -specified, compares only those named paths. Otherwise all -entries in the index are compared. +Compares the content and mode of the blobs found in a tree object +with the corresponding tracked files in the working tree, or with the +corresponding paths in the index. When <path> arguments are present, +compares only paths matching those patterns. Otherwise all tracked +files are compared. OPTIONS ------- diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index f8d081911..56fb7e532 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -12,25 +12,31 @@ SYNOPSIS 'git diff' [options] [<commit>] [--] [<path>...] 'git diff' [options] --cached [<commit>] [--] [<path>...] 'git diff' [options] <commit> <commit> [--] [<path>...] +'git diff' [options] <blob> <blob> 'git diff' [options] [--no-index] [--] <path> <path> DESCRIPTION ----------- Show changes between the working tree and the index or a tree, changes -between the index and a tree, changes between two trees, or changes -between two files on disk. +between the index and a tree, changes between two trees, changes between +two blob objects, or changes between two files on disk. 'git diff' [--options] [--] [<path>...]:: This form is to view the changes you made relative to the index (staging area for the next commit). In other - words, the differences are what you _could_ tell git to + words, the differences are what you _could_ tell Git to further add to the index but you still haven't. You can stage these changes by using linkgit:git-add[1]. -+ -If exactly two paths are given and at least one points outside -the current repository, 'git diff' will compare the two files / -directories. This behavior can be forced by --no-index. + +'git diff' --no-index [--options] [--] [<path>...]:: + + This form is to compare the given two paths on the + filesystem. You can omit the `--no-index` option when + running the command in a working tree controlled by Git and + at least one of the paths points outside the working tree, + or when running the command outside a working tree + controlled by Git. 'git diff' [--options] --cached [<commit>] [--] [<path>...]:: @@ -38,7 +44,7 @@ directories. This behavior can be forced by --no-index. commit relative to the named <commit>. Typically you would want comparison with the latest commit, so if you do not give <commit>, it defaults to HEAD. - If HEAD does not exist (e.g. unborned branches) and + If HEAD does not exist (e.g. unborn branches) and <commit> is not given, it shows all staged changes. --staged is a synonym of --cached. @@ -72,8 +78,7 @@ directories. This behavior can be forced by --no-index. Just in case if you are doing something exotic, it should be noted that all of the <commit> in the above description, except in the last two forms that use ".." notations, can be any -<tree>. The third form ('git diff <commit> <commit>') can also -be used to compare two <blob> objects. +<tree>. For a more complete list of ways to spell <commit>, see "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7]. @@ -82,6 +87,11 @@ and the range notations ("<commit>..<commit>" and "<commit>\...<commit>") do not mean a range as defined in the "SPECIFYING RANGES" section in linkgit:gitrevisions[7]. +'git diff' [options] <blob> <blob>:: + + This form is to view the differences between the raw + contents of two blob objects. + OPTIONS ------- :git-diff: 1 diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt index a03515f1e..11887e63a 100644 --- a/Documentation/git-difftool.txt +++ b/Documentation/git-difftool.txt @@ -12,13 +12,19 @@ SYNOPSIS DESCRIPTION ----------- -'git difftool' is a git command that allows you to compare and edit files +'git difftool' is a Git command that allows you to compare and edit files between revisions using common diff tools. 'git difftool' is a frontend to 'git diff' and accepts the same options and arguments. See linkgit:git-diff[1]. OPTIONS ------- +-d:: +--dir-diff:: + Copy the modified files to a temporary location and perform + a directory diff on them. This mode never prompts before + launching the diff tool. + -y:: --no-prompt:: Do not prompt before launching a diff tool. @@ -30,10 +36,9 @@ OPTIONS -t <tool>:: --tool=<tool>:: - Use the diff tool specified by <tool>. - Valid merge tools are: - araxis, bc3, diffuse, emerge, ecmerge, gvimdiff, kdiff3, - kompare, meld, opendiff, p4merge, tkdiff, vimdiff and xxdiff. + Use the diff tool specified by <tool>. Valid values include + emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help` + for the list of valid <tool> settings. + If a diff tool is not specified, 'git difftool' will use the configuration variable `diff.tool`. If the @@ -61,6 +66,18 @@ of the diff post-image. `$MERGED` is the name of the file which is being compared. `$BASE` is provided for compatibility with custom merge tool commands and has the same value as `$MERGED`. +--tool-help:: + Print a list of diff tools that may be used with `--tool`. + +--[no-]symlinks:: + 'git difftool''s default behavior is create symlinks to the + working tree when run in `--dir-diff` mode and the right-hand + side of the comparison yields the same content as the file in + the working tree. ++ +Specifying `--no-symlinks` instructs 'git difftool' to create copies +instead. `--no-symlinks` is the default on Windows. + -x <command>:: --extcmd=<command>:: Specify a custom command for viewing diffs. diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt index a29ac021d..85f1f30fd 100644 --- a/Documentation/git-fast-export.txt +++ b/Documentation/git-fast-export.txt @@ -27,15 +27,17 @@ OPTIONS Insert 'progress' statements every <n> objects, to be shown by 'git fast-import' during import. ---signed-tags=(verbatim|warn|strip|abort):: +--signed-tags=(verbatim|warn|warn-strip|strip|abort):: Specify how to handle signed tags. Since any transformation after the export can change the tag names (which can also happen when excluding revisions) the signatures will not match. + When asking to 'abort' (which is the default), this program will die -when encountering a signed tag. With 'strip', the tags will be made -unsigned, with 'verbatim', they will be silently exported -and with 'warn', they will be exported, but you will see a warning. +when encountering a signed tag. With 'strip', the tags will silently +be made unsigned, with 'warn-strip' they will be made unsigned but a +warning will be displayed, with 'verbatim', they will be silently +exported and with 'warn', they will be exported, but you will see a +warning. --tag-of-filtered-object=(abort|drop|rewrite):: Specify how to handle tags whose tagged object is filtered out. @@ -66,6 +68,8 @@ produced incorrect results if you gave these options. incremental runs. As <file> is only opened and truncated at completion, the same path can also be safely given to \--import-marks. + The file will not be written if no new object has been + marked/exported. --import-marks=<file>:: Before processing any input, load the marks specified in @@ -83,6 +87,10 @@ marks the same across runs. allow that. So fake a tagger to be able to fast-import the output. +--use-done-feature:: + Start the stream with a 'feature done' stanza, and terminate + it with a 'done' command. + --no-data:: Skip output of blob objects and instead refer to blobs via their original SHA-1 hash. This is useful when rewriting the @@ -98,11 +106,11 @@ marks the same across runs. different from the commit's first parent). [<git-rev-list-args>...]:: - A list of arguments, acceptable to 'git rev-parse' and - 'git rev-list', that specifies the specific objects and references - to export. For example, `master{tilde}10..master` causes the - current master reference to be exported along with all objects - added since its 10th ancestor commit. + A list of arguments, acceptable to 'git rev-parse' and + 'git rev-list', that specifies the specific objects and references + to export. For example, `master~10..master` causes the + current master reference to be exported along with all objects + added since its 10th ancestor commit. EXAMPLES -------- @@ -133,7 +141,7 @@ Limitations ----------- Since 'git fast-import' cannot tag trees, you will not be -able to export the linux-2.6.git repository completely, as it contains +able to export the linux.git repository completely, as it contains a tag referencing a tree instead of a commit. GIT diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 95e480ef7..fd22a9a0c 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -33,34 +33,46 @@ the frontend program in use. OPTIONS ------- ---date-format=<fmt>:: - Specify the type of dates the frontend will supply to - fast-import within `author`, `committer` and `tagger` commands. - See ``Date Formats'' below for details about which formats - are supported, and their syntax. --force:: Force updating modified existing branches, even if doing so would cause commits to be lost (as the new commit does not contain the old commit). ---max-pack-size=<n>:: - Maximum size of each output packfile. - The default is unlimited. +--quiet:: + Disable all non-fatal output, making fast-import silent when it + is successful. This option disables the output shown by + \--stats. ---big-file-threshold=<n>:: - Maximum size of a blob that fast-import will attempt to - create a delta for, expressed in bytes. The default is 512m - (512 MiB). Some importers may wish to lower this on systems - with constrained memory. +--stats:: + Display some basic statistics about the objects fast-import has + created, the packfiles they were stored into, and the + memory used by fast-import during this run. Showing this output + is currently the default, but can be disabled with \--quiet. ---depth=<n>:: - Maximum delta depth, for blob and tree deltification. - Default is 10. +Options for Frontends +~~~~~~~~~~~~~~~~~~~~~ ---active-branches=<n>:: - Maximum number of branches to maintain active at once. - See ``Memory Utilization'' below for details. Default is 5. +--cat-blob-fd=<fd>:: + Write responses to `cat-blob` and `ls` queries to the + file descriptor <fd> instead of `stdout`. Allows `progress` + output intended for the end-user to be separated from other + output. + +--date-format=<fmt>:: + Specify the type of dates the frontend will supply to + fast-import within `author`, `committer` and `tagger` commands. + See ``Date Formats'' below for details about which formats + are supported, and their syntax. + +--done:: + Terminate with error if there is no `done` command at the end of + the stream. This option might be useful for detecting errors + that cause the frontend to terminate before it has started to + write a stream. + +Locations of Marks Files +~~~~~~~~~~~~~~~~~~~~~~~~ --export-marks=<file>:: Dumps the internal marks table to <file> when complete. @@ -83,24 +95,33 @@ OPTIONS Like --import-marks but instead of erroring out, silently skips the file if it does not exist. ---relative-marks:: +--[no-]relative-marks:: After specifying --relative-marks the paths specified with --import-marks= and --export-marks= are relative to an internal directory in the current repository. In git-fast-import this means that the paths are relative to the .git/info/fast-import directory. However, other importers may use a different location. ++ +Relative and non-relative marks may be combined by interweaving +--(no-)-relative-marks with the --(import|export)-marks= options. ---no-relative-marks:: - Negates a previous --relative-marks. Allows for combining - relative and non-relative marks by interweaving - --(no-)-relative-marks with the --(import|export)-marks= - options. +Performance and Compression Tuning +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---cat-blob-fd=<fd>:: - Specify the file descriptor that will be written to - when the `cat-blob` command is encountered in the stream. - The default behaviour is to write to `stdout`. +--active-branches=<n>:: + Maximum number of branches to maintain active at once. + See ``Memory Utilization'' below for details. Default is 5. + +--big-file-threshold=<n>:: + Maximum size of a blob that fast-import will attempt to + create a delta for, expressed in bytes. The default is 512m + (512 MiB). Some importers may wish to lower this on systems + with constrained memory. + +--depth=<n>:: + Maximum delta depth, for blob and tree deltification. + Default is 10. --export-pack-edges=<file>:: After creating a packfile, print a line of data to @@ -111,16 +132,9 @@ OPTIONS as these commits can be used as edge points during calls to 'git pack-objects'. ---quiet:: - Disable all non-fatal output, making fast-import silent when it - is successful. This option disables the output shown by - \--stats. - ---stats:: - Display some basic statistics about the objects fast-import has - created, the packfiles they were stored into, and the - memory used by fast-import during this run. Showing this output - is currently the default, but can be disabled with \--quiet. +--max-pack-size=<n>:: + Maximum size of each output packfile. + The default is unlimited. Performance @@ -237,7 +251,7 @@ advisement to help formatting routines display the timestamp. If the local offset is not available in the source material, use ``+0000'', or the most common local offset. For example many organizations have a CVS repository which has only ever been accessed -by users who are located in the same location and timezone. In this +by users who are located in the same location and time zone. In this case a reasonable offset from UTC could be assumed. + Unlike the `rfc2822` format, this format is very strict. Any @@ -257,7 +271,7 @@ the malformed string. There are also some types of malformed strings which Git will parse wrong, and yet consider valid. Seriously malformed strings will be rejected. + -Unlike the `raw` format above, the timezone/UTC offset information +Unlike the `raw` format above, the time zone/UTC offset information contained in an RFC 2822 date string is used to adjust the date value to UTC prior to storage. Therefore it is important that this information be as accurate as possible. @@ -273,13 +287,13 @@ format, or its format is easily convertible to it, as there is no ambiguity in parsing. `now`:: - Always use the current time and timezone. The literal + Always use the current time and time zone. The literal `now` must always be supplied for `<when>`. + -This is a toy format. The current time and timezone of this system +This is a toy format. The current time and time zone of this system is always copied into the identity string at the time it is being created by fast-import. There is no way to specify a different time or -timezone. +time zone. + This particular format is supplied as it's short to implement and may be useful to a process that wants to create a new commit @@ -331,6 +345,11 @@ and control the current import process. More detailed discussion standard output. This command is optional and is not needed to perform an import. +`done`:: + Marks the end of the stream. This command is optional + unless the `done` feature was requested using the + `--done` command line option or `feature done` command. + `cat-blob`:: Causes fast-import to print a blob in 'cat-file --batch' format to the file descriptor set with `--cat-blob-fd` or @@ -342,8 +361,8 @@ and control the current import process. More detailed discussion `--cat-blob-fd` or `stdout` if unspecified. `feature`:: - Require that fast-import supports the specified feature, or - abort if it does not. + Enable the specified feature. This requires that fast-import + supports the specified feature, and aborts if it does not. `option`:: Specify any of the options listed under OPTIONS that do not @@ -361,8 +380,8 @@ change to the project. ('author' (SP <name>)? SP LT <email> GT SP <when> LF)? 'committer' (SP <name>)? SP LT <email> GT SP <when> LF data - ('from' SP <committish> LF)? - ('merge' SP <committish> LF)? + ('from' SP <commit-ish> LF)? + ('merge' SP <commit-ish> LF)? (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)* LF? .... @@ -411,11 +430,11 @@ they made it. Here `<name>` is the person's display name (for example ``Com M Itter'') and `<email>` is the person's email address -(``cm@example.com''). `LT` and `GT` are the literal less-than (\x3c) +(``\cm@example.com''). `LT` and `GT` are the literal less-than (\x3c) and greater-than (\x3e) symbols. These are required to delimit the email address from the other fields in the line. Note that -`<name>` is free-form and may contain any sequence of bytes, except -`LT` and `LF`. It is typically UTF-8 encoded. +`<name>` and `<email>` are free-form and may contain any sequence +of bytes, except `LT`, `GT` and `LF`. `<name>` is typically UTF-8 encoded. The time of the change is specified by `<when>` using the date format that was selected by the \--date-format=<fmt> command line option. @@ -426,7 +445,9 @@ their syntax. ^^^^^^ The `from` command is used to specify the commit to initialize this branch from. This revision will be the first ancestor of the -new commit. +new commit. The state of the tree built at this commit will begin +with the state at the `from` commit, and be altered by the content +modifications in this commit. Omitting the `from` command in the first commit of a new branch will cause fast-import to create that commit with no ancestor. This @@ -439,9 +460,9 @@ as the current commit on that branch is automatically assumed to be the first ancestor of the new commit. As `LF` is not valid in a Git refname or SHA-1 expression, no -quoting or escaping syntax is supported within `<committish>`. +quoting or escaping syntax is supported within `<commit-ish>`. -Here `<committish>` is any of the following: +Here `<commit-ish>` is any of the following: * The name of an existing branch already in fast-import's internal branch table. If fast-import doesn't know the name, it's treated as a SHA-1 @@ -467,16 +488,18 @@ current branch value should be written as: ---- from refs/heads/branch^0 ---- -The `{caret}0` suffix is necessary as fast-import does not permit a branch to +The `^0` suffix is necessary as fast-import does not permit a branch to start from itself, and the branch is created in memory before the -`from` command is even read from the input. Adding `{caret}0` will force +`from` command is even read from the input. Adding `^0` will force fast-import to resolve the commit through Git's revision parsing library, rather than its internal branch table, thereby loading in the existing value of the branch. `merge` ^^^^^^^ -Includes one additional ancestor commit. If the `from` command is +Includes one additional ancestor commit. The additional ancestry +link does not change the way the tree state is built at this commit. +If the `from` command is omitted when creating a new branch, the first `merge` commit will be the first ancestor of the current commit, and the branch will start out with no files. An unlimited number of `merge` commands per @@ -486,7 +509,7 @@ additional ancestors (forming a 16-way merge). For this reason it is suggested that frontends do not use more than 15 `merge` commands per commit; 16, if starting a new, empty branch. -Here `<committish>` is any of the commit specification expressions +Here `<commit-ish>` is any of the commit specification expressions also accepted by `from` (see above). `filemodify` @@ -542,8 +565,12 @@ A `<path>` string must use UNIX-style directory separators (forward slash `/`), may contain any byte other than `LF`, and must not start with double quote (`"`). -If an `LF` or double quote must be encoded into `<path>` shell-style -quoting should be used, e.g. `"path/with\n and \" in it"`. +A path can use C-style string quoting; this is accepted in all cases +and mandatory if the filename starts with double quote or contains +`LF`. In C-style quoting, the complete name should be surrounded with +double quotes, and any `LF`, backslash, or double quote characters +must be escaped by preceding them with a backslash (e.g., +`"path/with\n, \\ and \" in it"`). The value of `<path>` must be in canonical form. That is it must not: @@ -650,8 +677,8 @@ paths for a commit are encouraged to do so. `notemodify` ^^^^^^^^^^^^ Included in a `commit` `<notes_ref>` command to add a new note -annotating a `<committish>` or change this annotation contents. -Internally it is similar to filemodify 100644 on `<committish>` +annotating a `<commit-ish>` or change this annotation contents. +Internally it is similar to filemodify 100644 on `<commit-ish>` path (maybe split into subdirectories). It's not advised to use any other commands to write to the `<notes_ref>` tree except `filedeleteall` to delete all existing notes in this tree. @@ -664,7 +691,7 @@ External data format:: commit that is to be annotated. + .... - 'N' SP <dataref> SP <committish> LF + 'N' SP <dataref> SP <commit-ish> LF .... + Here `<dataref>` can be either a mark reference (`:<idnum>`) @@ -677,13 +704,13 @@ Inline data format:: command. + .... - 'N' SP 'inline' SP <committish> LF + 'N' SP 'inline' SP <commit-ish> LF data .... + See below for a detailed description of the `data` command. -In both formats `<committish>` is any of the commit specification +In both formats `<commit-ish>` is any of the commit specification expressions also accepted by `from` (see above). `mark` @@ -714,7 +741,7 @@ lightweight (non-annotated) tags see the `reset` command below. .... 'tag' SP <name> LF - 'from' SP <committish> LF + 'from' SP <commit-ish> LF 'tagger' (SP <name>)? SP LT <email> GT SP <when> LF data .... @@ -759,11 +786,11 @@ branch from an existing commit without creating a new commit. .... 'reset' SP <ref> LF - ('from' SP <committish> LF)? + ('from' SP <commit-ish> LF)? LF? .... -For a detailed description of `<ref>` and `<committish>` see above +For a detailed description of `<ref>` and `<commit-ish>` see above under `commit` and `from`. The `LF` after the command is optional (it used to be required). @@ -931,6 +958,9 @@ This command can be used anywhere in the stream that comments are accepted. In particular, the `cat-blob` command can be used in the middle of a commit but not in the middle of a `data` command. +See ``Responses To Commands'' below for details about how to read +this output safely. + `ls` ~~~~ Prints information about the object at a path to a file descriptor @@ -964,7 +994,7 @@ Reading from a named tree:: See `filemodify` above for a detailed description of `<path>`. -Output uses the same format as `git ls-tree <tree> {litdd} <path>`: +Output uses the same format as `git ls-tree <tree> -- <path>`: ==== <mode> SP ('blob' | 'tree' | 'commit') SP <dataref> HT <path> LF @@ -980,6 +1010,9 @@ instead report missing SP <path> LF ==== +See ``Responses To Commands'' below for details about how to read +this output safely. + `feature` ~~~~~~~~~ Require that fast-import supports the specified feature, or abort if @@ -1001,10 +1034,14 @@ force:: (see OPTIONS, above). import-marks:: +import-marks-if-exists:: Like --import-marks except in two respects: first, only one - "feature import-marks" command is allowed per stream; - second, an --import-marks= command-line option overrides - any "feature import-marks" command in the stream. + "feature import-marks" or "feature import-marks-if-exists" + command is allowed per stream; second, an --import-marks= + or --import-marks-if-exists command-line option overrides + any of these "feature" commands in the stream; third, + "feature import-marks-if-exists" like a corresponding + command-line option silently skips a nonexistent file. cat-blob:: ls:: @@ -1021,6 +1058,13 @@ notes:: Versions of fast-import not supporting notes will exit with a message indicating so. +done:: + Error out if the stream ends without a 'done' command. + Without this feature, errors causing the frontend to end + abruptly at a convenient point in the stream can go + undetected. This may occur, for example, if an import + front end dies in mid-operation without emitting SIGTERM + or SIGKILL at its subordinate git fast-import instance. `option` ~~~~~~~~ @@ -1050,6 +1094,44 @@ not be passed as option: * cat-blob-fd * force +`done` +~~~~~~ +If the `done` feature is not in use, treated as if EOF was read. +This can be used to tell fast-import to finish early. + +If the `--done` command line option or `feature done` command is +in use, the `done` command is mandatory and marks the end of the +stream. + +Responses To Commands +--------------------- +New objects written by fast-import are not available immediately. +Most fast-import commands have no visible effect until the next +checkpoint (or completion). The frontend can send commands to +fill fast-import's input pipe without worrying about how quickly +they will take effect, which improves performance by simplifying +scheduling. + +For some frontends, though, it is useful to be able to read back +data from the current repository as it is being updated (for +example when the source material describes objects in terms of +patches to be applied to previously imported objects). This can +be accomplished by connecting the frontend and fast-import via +bidirectional pipes: + +==== + mkfifo fast-import-output + frontend <fast-import-output | + git fast-import >fast-import-output +==== + +A frontend set up this way can use `progress`, `ls`, and `cat-blob` +commands to read information from the import in progress. + +To avoid deadlock, such frontends must completely consume any +pending output from `progress`, `ls`, and `cat-blob` before +performing writes to fast-import that might block. + Crash Reports ------------- If fast-import is supplied invalid input it will terminate with a diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index ed1bdaacd..93b506794 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -9,7 +9,10 @@ git-fetch-pack - Receive missing objects from another repository SYNOPSIS -------- [verse] -'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...] +'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] + [--upload-pack=<git-upload-pack>] + [--depth=<n>] [--no-progress] + [-v] <repository> [<refs>...] DESCRIPTION ----------- @@ -32,6 +35,16 @@ OPTIONS --all:: Fetch all remote refs. +--stdin:: + Take the list of refs from stdin, one per line. If there + are refs specified on the command line in addition to this + option, then the refs from stdin are processed after those + on the command line. ++ +If '--stateless-rpc' is specified together with this option then +the list of refs must be in packet format (pkt-line). Each ref must +be in a separate packet, and the list must end with a flush packet. + -q:: --quiet:: Pass '-q' flag to 'git unpack-objects'; this makes the @@ -71,26 +84,31 @@ OPTIONS --depth=<n>:: Limit fetching to ancestor-chains not longer than n. + 'git-upload-pack' treats the special depth 2147483647 as + infinite even if there is an ancestor-chain that long. --no-progress:: Do not show the progress. +--check-self-contained-and-connected:: + Output "connectivity-ok" if the received pack is + self-contained and connected. + -v:: Run verbosely. -<host>:: - A remote host that houses the repository. When this - part is specified, 'git-upload-pack' is invoked via - ssh. - -<directory>:: - The repository to sync from. +<repository>:: + The URL to the remote repository. <refs>...:: The remote heads to update from. This is relative to $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When unspecified, update from all heads the remote side has. +SEE ALSO +-------- +linkgit:git-fetch[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index b41d7c1de..5809aa4eb 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -24,19 +24,22 @@ The ref names and their object names of fetched refs are stored in `.git/FETCH_HEAD`. This information is left for a later merge operation done by 'git merge'. -When <refspec> stores the fetched result in remote-tracking branches, -the tags that point at these branches are automatically -followed. This is done by first fetching from the remote using -the given <refspec>s, and if the repository has objects that are -pointed by remote tags that it does not yet have, then fetch -those missing tags. If the other end has tags that point at -branches you are not interested in, you will not get them. +By default, tags are auto-followed. This means that when fetching +from a remote, any tags on the remote that point to objects that exist +in the local repository are fetched. The effect is to fetch tags that +point at branches that you are interested in. This default behavior +can be changed by using the --tags or --no-tags options, by +configuring remote.<name>.tagopt, or by using a refspec that fetches +tags explicitly. 'git fetch' can fetch from either a single named repository, or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file. (See linkgit:git-config[1]). +When no remote is specified, by default the `origin` remote will be used, +unless there's an upstream branch configured for the current branch. + OPTIONS ------- include::fetch-options.txt[] @@ -80,7 +83,7 @@ Using --recurse-submodules can only fetch new commits in already checked out submodules right now. When e.g. upstream added a new submodule in the just fetched commits of the superproject the submodule itself can not be fetched, making it impossible to check out that submodule later without -having to do a fetch again. This is expected to be fixed in a future git +having to do a fetch again. This is expected to be fixed in a future Git version. SEE ALSO diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 0f2f11738..2eba62717 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -18,7 +18,7 @@ SYNOPSIS DESCRIPTION ----------- -Lets you rewrite git revision history by rewriting the branches mentioned +Lets you rewrite Git revision history by rewriting the branches mentioned in the <rev-list options>, applying custom filters on each revision. Those filters can modify each tree (e.g. removing a file or running a perl rewrite on all files) or information about each commit. @@ -29,10 +29,11 @@ The command will only rewrite the _positive_ refs mentioned in the command line (e.g. if you pass 'a..b', only 'b' will be rewritten). If you specify no filters, the commits will be recommitted without any changes, which would normally have no effect. Nevertheless, this may be -useful in the future for compensating for some git bugs or such, +useful in the future for compensating for some Git bugs or such, therefore such a usage is permitted. -*NOTE*: This command honors `.git/info/grafts` and `.git/refs/replace/`. +*NOTE*: This command honors `.git/info/grafts` file and refs in +the `refs/replace/` namespace. If you have any grafts or replacement refs defined, running this command will make them permanent. @@ -63,8 +64,11 @@ argument is always evaluated in the shell context using the 'eval' command Prior to that, the $GIT_COMMIT environment variable will be set to contain the id of the commit being rewritten. Also, GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, -and GIT_COMMITTER_DATE are set according to the current commit. The values -of these variables after the filters have run, are used for the new commit. +and GIT_COMMITTER_DATE are taken from the current commit and exported to +the environment, in order to affect the author and committer identities of +the replacement commit created by linkgit:git-commit-tree[1] after the +filters have run. + If any evaluation of <command> returns a non-zero exit status, the whole operation will be aborted. @@ -96,8 +100,8 @@ OPTIONS --index-filter <command>:: This is the filter for rewriting the index. It is similar to the tree filter but does not check out the tree, which makes it much - faster. Frequently used with `git rm \--cached - \--ignore-unmatch ...`, see EXAMPLES below. For hairy + faster. Frequently used with `git rm --cached + --ignore-unmatch ...`, see EXAMPLES below. For hairy cases, see linkgit:git-update-index[1]. --parent-filter <command>:: @@ -222,11 +226,11 @@ However, if the file is absent from the tree of some commit, a simple `rm filename` will fail for that tree and commit. Thus you may instead want to use `rm -f filename` as the script. -Using `\--index-filter` with 'git rm' yields a significantly faster +Using `--index-filter` with 'git rm' yields a significantly faster version. Like with using `rm filename`, `git rm --cached filename` will fail if the file is absent from the tree of a commit. If you want to "completely forget" a file, it does not matter when it entered -history, so we also add `\--ignore-unmatch`: +history, so we also add `--ignore-unmatch`: -------------------------------------------------------------------------- git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD @@ -242,8 +246,8 @@ git filter-branch --subdirectory-filter foodir -- --all ------------------------------------------------------- Thus you can, e.g., turn a library subdirectory into a repository of -its own. Note the `\--` that separates 'filter-branch' options from -revision options, and the `\--all` to rewrite all branches and tags. +its own. Note the `--` that separates 'filter-branch' options from +revision options, and the `--all` to rewrite all branches and tags. To set a commit (which typically is at the tip of another history) to be the parent of the current initial commit, in @@ -303,6 +307,11 @@ committed a merge between P1 and P2, it will be propagated properly and all children of the merge will become merge commits with P1,P2 as their parents instead of the merge commit. +*NOTE* the changes introduced by the commits, and which are not reverted +by subsequent commits, will still be in the rewritten branch. If you want +to throw out _changes_ together with the commits, you should use the +interactive mode of 'git rebase'. + You can rewrite the commit log messages using `--msg-filter`. For example, 'git svn-id' strings in a repository created by 'git svn' can be removed this way: @@ -313,11 +322,6 @@ git filter-branch --msg-filter ' ' ------------------------------------------------------- -To restrict rewriting to only part of the history, specify a revision -range in addition to the new branch name. The new branch name will -point to the top-most revision that a 'git rev-list' of this range -will print. - If you need to add 'Acked-by' lines to, say, the last 10 commits (none of which is a merge), use this command: @@ -328,11 +332,30 @@ git filter-branch --msg-filter ' ' HEAD~10..HEAD -------------------------------------------------------- -*NOTE* the changes introduced by the commits, and which are not reverted -by subsequent commits, will still be in the rewritten branch. If you want -to throw out _changes_ together with the commits, you should use the -interactive mode of 'git rebase'. +The `--env-filter` option can be used to modify committer and/or author +identity. For example, if you found out that your commits have the wrong +identity due to a misconfigured user.email, you can make a correction, +before publishing the project, like this: + +-------------------------------------------------------- +git filter-branch --env-filter ' + if test "$GIT_AUTHOR_EMAIL" = "root@localhost" + then + GIT_AUTHOR_EMAIL=john@example.com + export GIT_AUTHOR_EMAIL + fi + if test "$GIT_COMMITTER_EMAIL" = "root@localhost" + then + GIT_COMMITTER_EMAIL=john@example.com + export GIT_COMMITTER_EMAIL + fi +' -- --all +-------------------------------------------------------- +To restrict rewriting to only part of the history, specify a revision +range in addition to the new branch name. The new branch name will +point to the top-most revision that a 'git rev-list' of this range +will print. Consider this history: @@ -370,24 +393,24 @@ git filter-branch --index-filter \ Checklist for Shrinking a Repository ------------------------------------ -git-filter-branch is often used to get rid of a subset of files, -usually with some combination of `\--index-filter` and -`\--subdirectory-filter`. People expect the resulting repository to +git-filter-branch can be used to get rid of a subset of files, +usually with some combination of `--index-filter` and +`--subdirectory-filter`. People expect the resulting repository to be smaller than the original, but you need a few more steps to -actually make it smaller, because git tries hard not to lose your +actually make it smaller, because Git tries hard not to lose your objects until you tell it to. First make sure that: * You really removed all variants of a filename, if a blob was moved - over its lifetime. `git log \--name-only \--follow \--all \-- - filename` can help you find renames. + over its lifetime. `git log --name-only --follow --all -- filename` + can help you find renames. -* You really filtered all refs: use `\--tag-name-filter cat \-- - \--all` when calling git-filter-branch. +* You really filtered all refs: use `--tag-name-filter cat -- --all` + when calling git-filter-branch. Then there are two ways to get a smaller repository. A safer way is to clone, that keeps your original intact. -* Clone it with `git clone +++file:///path/to/repo+++`. The clone +* Clone it with `git clone file:///path/to/repo`. The clone will not have the removed objects. See linkgit:git-clone[1]. (Note that cloning with a plain path just hardlinks everything!) @@ -397,14 +420,45 @@ approach, so *make a backup* or go back to cloning it. You have been warned. * Remove the original refs backed up by git-filter-branch: say `git - for-each-ref \--format="%(refname)" refs/original/ | xargs -n 1 git + for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d`. -* Expire all reflogs with `git reflog expire \--expire=now \--all`. +* Expire all reflogs with `git reflog expire --expire=now --all`. -* Garbage collect all unreferenced objects with `git gc \--prune=now` +* Garbage collect all unreferenced objects with `git gc --prune=now` (or if your git-gc is not new enough to support arguments to - `\--prune`, use `git repack -ad; git prune` instead). + `--prune`, use `git repack -ad; git prune` instead). + +Notes +----- + +git-filter-branch allows you to make complex shell-scripted rewrites +of your Git history, but you probably don't need this flexibility if +you're simply _removing unwanted data_ like large files or passwords. +For those operations you may want to consider +link:http://rtyley.github.io/bfg-repo-cleaner/[The BFG Repo-Cleaner], +a JVM-based alternative to git-filter-branch, typically at least +10-50x faster for those use-cases, and with quite different +characteristics: + +* Any particular version of a file is cleaned exactly _once_. The BFG, + unlike git-filter-branch, does not give you the opportunity to + handle a file differently based on where or when it was committed + within your history. This constraint gives the core performance + benefit of The BFG, and is well-suited to the task of cleansing bad + data - you don't care _where_ the bad data is, you just want it + _gone_. + +* By default The BFG takes full advantage of multi-core machines, + cleansing commit file-trees in parallel. git-filter-branch cleans + commits sequentially (ie in a single-threaded manner), though it + _is_ possible to write filters that include their own parallellism, + in the scripts executed against each commit. + +* The link:http://rtyley.github.io/bfg-repo-cleaner/#examples[command options] + are much more restrictive than git-filter branch, and dedicated just + to the tasks of removing unwanted data- e.g: + `--strip-blobs-bigger-than 1M`. GIT --- diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt index 32aff954a..bb1232a52 100644 --- a/Documentation/git-fmt-merge-msg.txt +++ b/Documentation/git-fmt-merge-msg.txt @@ -35,8 +35,7 @@ OPTIONS Do not list one-line descriptions from the actual commits being merged. ---summary:: ---no-summary:: +--[no-]summary:: Synonyms to --log and --no-log; these are deprecated and will be removed in the future. @@ -53,6 +52,11 @@ OPTIONS CONFIGURATION ------------- +merge.branchdesc:: + In addition to branch names, populate the log message with + the branch description text associated with them. Defaults + to false. + merge.log:: In addition to branch names, populate the log message with at most the specified number of one-line descriptions from the diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 152e695c8..42408752d 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -91,7 +91,19 @@ objectname:: upstream:: The name of a local ref which can be considered ``upstream'' from the displayed ref. Respects `:short` in the same way as - `refname` above. + `refname` above. Additionally respects `:track` to show + "[ahead N, behind M]" and `:trackshort` to show the terse + version: ">" (ahead), "<" (behind), "<>" (ahead and behind), + or "=" (in sync). Has no effect if the ref does not have + tracking information associated with it. + +HEAD:: + '*' if HEAD matches current ref (the checked out branch), ' ' + otherwise. + +color:: + Change output color. Followed by `:<colorname>`, where names + are described in `color.branch.*`. In addition to the above, for commit and tag objects, the header field names (`tree`, `parent`, `object`, `type`, and `tag`) can @@ -101,9 +113,11 @@ Fields that have name-email-date tuple as its value (`author`, `committer`, and `tagger`) can be suffixed with `name`, `email`, and `date` to extract the named component. -The first line of the message in a commit and tag object is -`subject`, the remaining lines are `body`. The whole message -is `contents`. +The complete message in a commit and tag object is `contents`. +Its first line is `contents:subject`, where subject is the concatenation +of all lines of the commit message up to the first blank line. The next +line is 'contents:body', where body is all of the lines after the first +blank line. Finally, the optional GPG signature is `contents:signature`. For sorting purposes, fields with numeric values sort in numeric order (`objectsize`, `authordate`, `committerdate`, `taggerdate`). @@ -115,7 +129,7 @@ returns an empty string instead. As a special case for the date-type fields, you may specify a format for the date by adding one of `:default`, `:relative`, `:short`, `:local`, -`:iso8601` or `:rfc2822` to the end of the fieldname; e.g. +`:iso8601`, `:rfc2822` or `:raw` to the end of the fieldname; e.g. `%(taggerdate:relative)`. @@ -205,13 +219,9 @@ eval=`git for-each-ref --shell --format="$fmt" \ eval "$eval" ------------ -Author ------- -Written by Junio C Hamano <gitster@pobox.com>. - -Documentation -------------- -Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. +SEE ALSO +-------- +linkgit:git-show-ref[1] GIT --- diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index d13c9b23f..5c0a4ab2d 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -18,9 +18,9 @@ SYNOPSIS [--start-number <n>] [--numbered-files] [--in-reply-to=Message-Id] [--suffix=.<sfx>] [--ignore-if-in-upstream] - [--subject-prefix=Subject-Prefix] + [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) <n>] [--to=<email>] [--cc=<email>] - [--cover-letter] [--quiet] + [--[no-]cover-letter] [--quiet] [--notes[=<ref>]] [<common diff options>] [ <since> | <revision range> ] @@ -45,7 +45,7 @@ There are two ways to specify which commits to operate on. The first rule takes precedence in the case of a single <commit>. To apply the second rule, i.e., format everything since the beginning of history up until <commit>, use the '\--root' option: `git format-patch -\--root <commit>`. If you want to format only <commit> itself, you +--root <commit>`. If you want to format only <commit> itself, you can do this with `git format-patch -1 <commit>`. By default, each output file is numbered sequentially from 1, and uses the @@ -58,10 +58,13 @@ output, unless the `--stdout` option is specified. If `-o` is specified, output files are created in <dir>. Otherwise they are created in the current working directory. -By default, the subject of a single patch is "[PATCH] First Line" and -the subject when multiple patches are output is "[PATCH n/m] First -Line". To force 1/1 to be added for a single patch, use `-n`. To omit -patch numbers from the subject, use `-N`. +By default, the subject of a single patch is "[PATCH] " followed by +the concatenation of lines from the commit message up to the first blank +line (see the DISCUSSION section of linkgit:git-commit[1]). + +When multiple patches are output, the subject prefix will instead be +"[PATCH n/m] ". To force 1/1 to be added for a single patch, use `-n`. +To omit patch numbers from the subject, use `-N`. If given `--thread`, `git-format-patch` will generate `In-Reply-To` and `References` headers to make the second and subsequent patch mails appear @@ -134,7 +137,7 @@ include::diff-options.txt[] The optional <style> argument can be either `shallow` or `deep`. 'shallow' threading makes every mail a reply to the head of the series, where the head is chosen from the cover letter, the -`\--in-reply-to`, and the first patch mail, in this order. 'deep' +`--in-reply-to`, and the first patch mail, in this order. 'deep' threading makes every mail a reply to the previous one. + The default is `--no-thread`, unless the 'format.thread' configuration @@ -163,28 +166,71 @@ will want to ensure that threading is disabled for `git send-email`. allows for useful naming of a patch series, and can be combined with the `--numbered` option. +-v <n>:: +--reroll-count=<n>:: + Mark the series as the <n>-th iteration of the topic. The + output filenames have `v<n>` pretended to them, and the + subject prefix ("PATCH" by default, but configurable via the + `--subject-prefix` option) has ` v<n>` appended to it. E.g. + `--reroll-count=4` may produce `v4-0001-add-makefile.patch` + file that has "Subject: [PATCH v4 1/20] Add makefile" in it. + --to=<email>:: Add a `To:` header to the email headers. This is in addition to any configured headers, and may be used multiple times. + The negated form `--no-to` discards all `To:` headers added so + far (from config or command line). --cc=<email>:: Add a `Cc:` header to the email headers. This is in addition to any configured headers, and may be used multiple times. + The negated form `--no-cc` discards all `Cc:` headers added so + far (from config or command line). + +--from:: +--from=<ident>:: + Use `ident` in the `From:` header of each commit email. If the + author ident of the commit is not textually identical to the + provided `ident`, place a `From:` header in the body of the + message with the original author. If no `ident` is given, use + the committer ident. ++ +Note that this option is only useful if you are actually sending the +emails and want to identify yourself as the sender, but retain the +original author (and `git am` will correctly pick up the in-body +header). Note also that `git send-email` already handles this +transformation for you, and this option should not be used if you are +feeding the result to `git send-email`. --add-header=<header>:: Add an arbitrary header to the email headers. This is in addition to any configured headers, and may be used multiple times. - For example, `--add-header="Organization: git-foo"` + For example, `--add-header="Organization: git-foo"`. + The negated form `--no-add-header` discards *all* (`To:`, + `Cc:`, and custom) headers added so far from config or command + line. ---cover-letter:: +--[no-]cover-letter:: In addition to the patches, generate a cover letter file containing the shortlog and the overall diffstat. You can fill in a description in the file before sending it out. +--notes[=<ref>]:: + Append the notes (see linkgit:git-notes[1]) for the commit + after the three-dash line. ++ +The expected use case of this is to write supporting explanation for +the commit that does not belong to the commit log message proper, +and include it with the patch submission. While one can simply write +these explanations after `format-patch` has run but before sending, +keeping them as Git notes allows them to be maintained between versions +of the patch series (but see the discussion of the `notes.rewrite` +configuration options in linkgit:git-notes[1] to use this workflow). + --[no]-signature=<signature>:: Add a signature to each message produced. Per RFC 3676 the signature is separated from the body by a line with '-- ' on it. If the - signature option is omitted the signature defaults to the git version + signature option is omitted the signature defaults to the Git version number. --suffix=.<sfx>:: @@ -196,6 +242,7 @@ will want to ensure that threading is disabled for `git send-email`. Note that the leading character does not have to be a dot; for example, you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`. +-q:: --quiet:: Do not print the names of the generated files to standard output. @@ -229,6 +276,7 @@ attachments, and sign off patches with configuration variables. cc = <email> attach [ = mime-boundary-string ] signoff = true + coverletter = auto ------------ @@ -358,7 +406,7 @@ Thunderbird ~~~~~~~~~~~ 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. +resulting email unusable by Git. There are three different approaches: use an add-on to turn off line wraps, configure Thunderbird to not mangle patches, or use @@ -390,7 +438,8 @@ Edit..Preferences..Composition, wrap plain text messages at 0 In Thunderbird 3: Edit..Preferences..Advanced..Config Editor. Search for "mail.wrap_long_lines". -Toggle it to make sure it is set to `false`. +Toggle it to make sure it is set to `false`. Also, search for +"mailnews.wraplength" and set the value to 0. 3. Disable the use of format=flowed: Edit..Preferences..Advanced..Config Editor. Search for @@ -494,8 +543,8 @@ $ git format-patch -M -B origin Additionally, it detects and handles renames and complete rewrites intelligently to produce a renaming patch. A renaming patch reduces the amount of text output, and generally makes it easier to review. -Note that non-git "patch" programs won't understand renaming patches, so -use it only when you know the recipient uses git to apply your patch. +Note that non-Git "patch" programs won't understand renaming patches, so +use it only when you know the recipient uses Git to apply your patch. * Extract three topmost commits from the current branch and format them as e-mailable patches: diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt index a2a508dc2..25c431d3c 100644 --- a/Documentation/git-fsck.txt +++ b/Documentation/git-fsck.txt @@ -10,7 +10,8 @@ SYNOPSIS -------- [verse] 'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] - [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*] + [--[no-]full] [--strict] [--verbose] [--lost-found] + [--[no-]dangling] [--[no-]progress] [<object>*] DESCRIPTION ----------- @@ -22,13 +23,17 @@ OPTIONS An object to treat as the head of an unreachability trace. + If no objects are given, 'git fsck' defaults to using the -index file, all SHA1 references in .git/refs/*, and all reflogs (unless ---no-reflogs is given) as heads. +index file, all SHA-1 references in `refs` namespace, and all reflogs +(unless --no-reflogs is given) as heads. --unreachable:: Print out objects that exist but that aren't reachable from any of the reference nodes. +--[no-]dangling:: + Print objects that exist but that are never 'directly' used (default). + `--no-dangling` can be used to omit this information from the output. + --root:: Report root nodes. @@ -50,7 +55,7 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless ($GIT_DIR/objects), but also the ones found in alternate object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES or $GIT_DIR/objects/info/alternates, - and in packed git archives found in $GIT_DIR/objects/pack + and in packed Git archives found in $GIT_DIR/objects/pack and corresponding pack subdirectories in alternate object pools. This is now default; you can turn it off with --no-full. @@ -58,8 +63,8 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless --strict:: Enable more strict checking, namely to catch a file mode recorded with g+w bit set, which was created by older - versions of git. Existing repositories, including the - Linux kernel, git itself, and sparse repository have old + versions of Git. Existing repositories, including the + Linux kernel, Git itself, and sparse repository have old objects that triggers this check, but it is recommended to check new projects with this flag. @@ -72,30 +77,27 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless a blob, the contents are written into the file, rather than its object name. -It tests SHA1 and general object sanity, and it does full tracking of -the resulting reachability and everything else. It prints out any -corruption it finds (missing or bad objects), and if you use the -'--unreachable' flag it will also print out objects that exist but -that aren't reachable from any of the specified head nodes. - -So for example +--[no-]progress:: + Progress status is reported on the standard error stream by + default when it is attached to a terminal, unless + --no-progress or --verbose is specified. --progress forces + progress status even if the standard error stream is not + directed to a terminal. - git fsck --unreachable HEAD \ - $(git for-each-ref --format="%(objectname)" refs/heads) +DISCUSSION +---------- -will do quite a _lot_ of verification on the tree. There are a few -extra validity tests to be added (make sure that tree objects are -sorted properly etc), but on the whole if 'git fsck' is happy, you -do have a valid tree. +git-fsck tests SHA-1 and general object sanity, and it does full tracking +of the resulting reachability and everything else. It prints out any +corruption it finds (missing or bad objects), and if you use the +'--unreachable' flag it will also print out objects that exist but that +aren't reachable from any of the specified head nodes (or the default +set, as mentioned above). Any corrupt objects you will have to find in backups or other archives (i.e., you can just remove them and do an 'rsync' with some other site in the hopes that somebody else has the object you have corrupted). -Of course, "valid tree" doesn't mean that it wasn't generated by some -evil person, and the end result might be crap. git is a revision -tracking system, not a quality assurance system ;) - Extracted Diagnostics --------------------- diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index 815afcb92..e158a3b31 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -9,7 +9,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository SYNOPSIS -------- [verse] -'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] +'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force] DESCRIPTION ----------- @@ -62,8 +62,9 @@ automatic consolidation of packs. --prune=<date>:: Prune loose objects older than date (default is 2 weeks ago, - overridable by the config variable `gc.pruneExpire`). This - option is on by default. + overridable by the config variable `gc.pruneExpire`). + --prune=all prunes loose objects regardless of their age. + --prune is on by default. --no-prune:: Do not prune any loose objects. @@ -71,6 +72,10 @@ automatic consolidation of packs. --quiet:: Suppress all progress reports. +--force:: + Force `git gc` to run even if there may be another `git gc` + instance running on this repository. + Configuration ------------- @@ -84,7 +89,7 @@ The optional configuration variable 'gc.reflogExpireUnreachable' can be set to indicate how long historical reflog entries which are not part of the current branch should remain available in this repository. These types of entries are generally created as -a result of using `git commit \--amend` or `git rebase` and are the +a result of using `git commit --amend` or `git rebase` and are the commits prior to the amend or rebase occurring. Since these changes are not part of the current project most users will want to expire them sooner. This option defaults to '30 days'. diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt index e150c77cf..f83733490 100644 --- a/Documentation/git-grep.txt +++ b/Documentation/git-grep.txt @@ -9,7 +9,7 @@ git-grep - Print lines matching a pattern SYNOPSIS -------- [verse] -'git grep' [-a | --text] [-I] [-i | --ignore-case] [-w | --word-regexp] +'git grep' [-a | --text] [-I] [--textconv] [-i | --ignore-case] [-w | --word-regexp] [-v | --invert-match] [-h|-H] [--full-name] [-E | --extended-regexp] [-G | --basic-regexp] [-P | --perl-regexp] @@ -20,16 +20,20 @@ SYNOPSIS [-c | --count] [--all-match] [-q | --quiet] [--max-depth <depth>] [--color[=<when>] | --no-color] + [--break] [--heading] [-p | --show-function] [-A <post-context>] [-B <pre-context>] [-C <context>] + [-W | --function-context] [-f <file>] [-e] <pattern> [--and|--or|--not|(|)|-e <pattern>...] - [--cached | --no-index | <tree>...] + [ [--[no-]exclude-standard] [--cached | --no-index | --untracked] | <tree>...] [--] [<pathspec>...] DESCRIPTION ----------- Look for specified patterns in the tracked files in the work tree, blobs -registered in the index file, or blobs in given tree objects. +registered in the index file, or blobs in given tree objects. Patterns +are lists of one or more search expressions separated by newline +characters. An empty string as search expression matches all lines. CONFIGURATION @@ -38,8 +42,16 @@ CONFIGURATION grep.lineNumber:: If set to true, enable '-n' option by default. +grep.patternType:: + Set the default matching behavior. Using a value of 'basic', 'extended', + 'fixed', or 'perl' will enable the '--basic-regexp', '--extended-regexp', + '--fixed-strings', or '--perl-regexp' option accordingly, while the + value 'default' will return to the default matching behavior. + grep.extendedRegexp:: - If set to true, enable '--extended-regexp' option by default. + If set to true, enable '--extended-regexp' option by default. This + option is ignored when the 'grep.patternType' option is set to a value + other than 'default'. OPTIONS @@ -49,12 +61,32 @@ OPTIONS blobs registered in the index file. --no-index:: - Search files in the current directory, not just those tracked by git. + Search files in the current directory that is not managed by Git. + +--untracked:: + In addition to searching in the tracked files in the working + tree, search also in untracked files. + +--no-exclude-standard:: + Also search in ignored files by not honoring the `.gitignore` + mechanism. Only useful with `--untracked`. + +--exclude-standard:: + Do not pay attention to ignored files specified via the `.gitignore` + mechanism. Only useful when searching files in the current directory + with `--no-index`. -a:: --text:: Process binary files as if they were text. +--textconv:: + Honor textconv filter settings. + +--no-textconv:: + Do not honor textconv filter settings. + This is the default. + -i:: --ignore-case:: Ignore case differences between the patterns and the @@ -66,6 +98,9 @@ OPTIONS --max-depth <depth>:: For each <pathspec> given on command line, descend at most <depth> levels of directories. A negative value means no limit. + This option is ignored if <pathspec> contains active wildcards. + In other words if "a*" matches a directory named "a*", + "*" is matched literally so --max-depth is still effective. -w:: --word-regexp:: @@ -148,14 +183,12 @@ OPTIONS gives the default to color output. Same as `--color=never`. --[ABC] <context>:: - Show `context` trailing (`A` -- after), or leading (`B` - -- before), or both (`C` -- context) lines, and place a - line containing `--` between contiguous groups of - matches. +--break:: + Print an empty line between matches from different files. --<num>:: - A shortcut for specifying `-C<num>`. +--heading:: + Show the filename above the matches in that file instead of + at the start of each shown line. -p:: --show-function:: @@ -165,6 +198,29 @@ OPTIONS patch hunk headers (see 'Defining a custom hunk-header' in linkgit:gitattributes[5]). +-<num>:: +-C <num>:: +--context <num>:: + Show <num> leading and trailing lines, and place a line + containing `--` between contiguous groups of matches. + +-A <num>:: +--after-context <num>:: + Show <num> trailing lines, and place a line containing + `--` between contiguous groups of matches. + +-B <num>:: +--before-context <num>:: + Show <num> leading lines, and place a line containing + `--` between contiguous groups of matches. + +-W:: +--function-context:: + Show the surrounding text from the previous line containing a + function name up to the one before the next function name, + effectively showing the whole function in which the match was + found. + -f <file>:: Read patterns from <file>, one per line. @@ -208,15 +264,15 @@ OPTIONS Examples -------- -git grep {apostrophe}time_t{apostrophe} \-- {apostrophe}*.[ch]{apostrophe}:: +`git grep 'time_t' -- '*.[ch]'`:: Looks for `time_t` in all tracked .c and .h files in the working directory and its subdirectories. -git grep -e {apostrophe}#define{apostrophe} --and \( -e MAX_PATH -e PATH_MAX \):: +`git grep -e '#define' --and \( -e MAX_PATH -e PATH_MAX \)`:: Looks for a line that has `#define` and either `MAX_PATH` or `PATH_MAX`. -git grep --all-match -e NODE -e Unexpected:: +`git grep --all-match -e NODE -e Unexpected`:: Looks for a line that has `NODE` or `Unexpected` in files that have lines that match both. diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt index 18f713b67..8144527ae 100644 --- a/Documentation/git-gui.txt +++ b/Documentation/git-gui.txt @@ -50,7 +50,7 @@ version:: Examples -------- -git gui blame Makefile:: +`git gui blame Makefile`:: Show the contents of the file 'Makefile' in the current working directory, and provide annotations for both the @@ -59,41 +59,41 @@ git gui blame Makefile:: uncommitted changes (if any) are explicitly attributed to 'Not Yet Committed'. -git gui blame v0.99.8 Makefile:: +`git gui blame v0.99.8 Makefile`:: Show the contents of 'Makefile' in revision 'v0.99.8' and provide annotations for each line. Unlike the above example the file is read from the object database and not the working directory. -git gui blame --line=100 Makefile:: +`git gui blame --line=100 Makefile`:: Loads annotations as described above and automatically scrolls the view to center on line '100'. -git gui citool:: +`git gui citool`:: Make one commit and return to the shell when it is complete. This command returns a non-zero exit code if the window was closed in any way other than by making a commit. -git gui citool --amend:: +`git gui citool --amend`:: Automatically enter the 'Amend Last Commit' mode of the interface. -git gui citool --nocommit:: +`git gui citool --nocommit`:: Behave as normal citool, but instead of making a commit simply terminate with a zero exit code. It still checks that the index does not contain any unmerged entries, so you can use it as a GUI version of linkgit:git-mergetool[1] -git citool:: +`git citool`:: Same as `git gui citool` (above). -git gui browser maint:: +`git gui browser maint`:: Show a browser for the tree of the 'maint' branch. Files selected in the browser can be viewed with the internal @@ -102,7 +102,7 @@ git gui browser maint:: SEE ALSO -------- linkgit:gitk[1]:: - The git repository browser. Shows branches, commit history + The Git repository browser. Shows branches, commit history and file differences. gitk is the utility started by 'git gui''s Repository Visualize actions. diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt index 4b0a502e8..02c1f1268 100644 --- a/Documentation/git-hash-object.txt +++ b/Documentation/git-hash-object.txt @@ -40,7 +40,7 @@ OPTIONS --path:: Hash object as it were located at the given path. The location of file does not directly influence on the hash value, but path is - used to determine what git filters should be applied to the object + used to determine what Git filters should be applied to the object before it can be placed to the object database, and, as result of applying filters, the actual blob put into the object database may differ from the given file. This option is mainly useful for hashing diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt index 9e0b3f681..b21e9d79b 100644 --- a/Documentation/git-help.txt +++ b/Documentation/git-help.txt @@ -3,36 +3,50 @@ git-help(1) NAME ---- -git-help - display help information about git +git-help - Display help information about Git SYNOPSIS -------- [verse] -'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND] +'git help' [-a|--all] [-g|--guide] + [-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE] DESCRIPTION ----------- -With no options and no COMMAND given, the synopsis of the 'git' -command and a list of the most commonly used git commands are printed +With no options and no COMMAND or GUIDE given, the synopsis of the 'git' +command and a list of the most commonly used Git commands are printed on the standard output. -If the option '--all' or '-a' is given, then all available commands are +If the option '--all' or '-a' is given, all available commands are printed on the standard output. -If a git command is named, a manual page for that command is brought -up. The 'man' program is used by default for this purpose, but this -can be overridden by other options or configuration variables. +If the option '--guide' or '-g' is given, a list of the useful +Git guides is also printed on the standard output. + +If a command, or a guide, is given, a manual page for that command or +guide is brought up. The 'man' program is used by default for this +purpose, but this can be overridden by other options or configuration +variables. Note that `git --help ...` is identical to `git help ...` because the former is internally converted into the latter. +To display the linkgit:git[1] man page, use `git help git`. + +This page can be displayed with 'git help help' or `git help --help` + OPTIONS ------- -a:: --all:: Prints all the available commands on the standard output. This - option supersedes any other option. + option overrides any given command or guide name. + +-g:: +--guides:: + Prints a list of useful guides on the standard output. This + option overrides any given command or guide name. -i:: --info:: diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt index 277d9e141..e8c13f60a 100644 --- a/Documentation/git-http-backend.txt +++ b/Documentation/git-http-backend.txt @@ -19,7 +19,7 @@ and the backwards-compatible dumb HTTP protocol, as well as clients pushing using the smart HTTP protocol. It verifies that the directory has the magic file -"git-daemon-export-ok", and it will refuse to export any git directory +"git-daemon-export-ok", and it will refuse to export any Git directory that hasn't explicitly been marked for export this way (unless the GIT_HTTP_EXPORT_ALL environmental variable is set). @@ -80,7 +80,30 @@ ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/ ---------------------------------------------------------------- + To enable anonymous read access but authenticated write access, -require authorization with a LocationMatch directive: +require authorization for both the initial ref advertisement (which we +detect as a push via the service parameter in the query string), and the +receive-pack invocation itself: ++ +---------------------------------------------------------------- +RewriteCond %{QUERY_STRING} service=git-receive-pack [OR] +RewriteCond %{REQUEST_URI} /git-receive-pack$ +RewriteRule ^/git/ - [E=AUTHREQUIRED:yes] + +<LocationMatch "^/git/"> + Order Deny,Allow + Deny from env=AUTHREQUIRED + + AuthType Basic + AuthName "Git Access" + Require group committers + Satisfy Any + ... +</LocationMatch> +---------------------------------------------------------------- ++ +If you do not have `mod_rewrite` available to match against the query +string, it is sufficient to just protect `git-receive-pack` itself, +like: + ---------------------------------------------------------------- <LocationMatch "^/git/.*/git-receive-pack$"> @@ -91,6 +114,15 @@ require authorization with a LocationMatch directive: </LocationMatch> ---------------------------------------------------------------- + +In this mode, the server will not request authentication until the +client actually starts the object negotiation phase of the push, rather +than during the initial contact. For this reason, you must also enable +the `http.receivepack` config option in any repositories that should +accept a push. The default behavior, if `http.receivepack` is not set, +is to reject any pushes by unauthenticated users; the initial request +will therefore report `403 Forbidden` to the client, without even giving +an opportunity for authentication. ++ To require authentication for both reads and writes, use a Location directive around the repository, or one of its parent directories: + @@ -119,6 +151,14 @@ ScriptAliasMatch \ ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/ ---------------------------------------------------------------- ++ +To serve multiple repositories from different linkgit:gitnamespaces[7] in a +single repository: ++ +---------------------------------------------------------------- +SetEnvIf Request_URI "^/git/([^/]*)" GIT_NAMESPACE=$1 +ScriptAliasMatch ^/git/[^/]*(.*) /usr/libexec/git-core/git-http-backend/storage.git$1 +---------------------------------------------------------------- Accelerated static Apache 2.x:: Similar to the above, but Apache can be used to return static @@ -150,6 +190,54 @@ ScriptAliasMatch \ ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/ ---------------------------------------------------------------- +Lighttpd:: + Ensure that `mod_cgi`, `mod_alias, `mod_auth`, `mod_setenv` are + loaded, then set `GIT_PROJECT_ROOT` appropriately and redirect + all requests to the CGI: ++ +---------------------------------------------------------------- +alias.url += ( "/git" => "/usr/lib/git-core/git-http-backend" ) +$HTTP["url"] =~ "^/git" { + cgi.assign = ("" => "") + setenv.add-environment = ( + "GIT_PROJECT_ROOT" => "/var/www/git", + "GIT_HTTP_EXPORT_ALL" => "" + ) +} +---------------------------------------------------------------- ++ +To enable anonymous read access but authenticated write access: ++ +---------------------------------------------------------------- +$HTTP["querystring"] =~ "service=git-receive-pack" { + include "git-auth.conf" +} +$HTTP["url"] =~ "^/git/.*/git-receive-pack$" { + include "git-auth.conf" +} +---------------------------------------------------------------- ++ +where `git-auth.conf` looks something like: ++ +---------------------------------------------------------------- +auth.require = ( + "/" => ( + "method" => "basic", + "realm" => "Git Access", + "require" => "valid-user" + ) +) +# ...and set up auth.backend here +---------------------------------------------------------------- ++ +To require authentication for both reads and writes: ++ +---------------------------------------------------------------- +$HTTP["url"] =~ "^/git/private" { + include "git-auth.conf" +} +---------------------------------------------------------------- + ENVIRONMENT ----------- @@ -175,14 +263,6 @@ identifying information of the remote user who performed the push. All CGI environment variables are available to each of the hooks invoked by the 'git-receive-pack'. -Author ------- -Written by Shawn O. Pearce <spearce@spearce.org>. - -Documentation --------------- -Documentation by Shawn O. Pearce <spearce@spearce.org>. - GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-http-fetch.txt b/Documentation/git-http-fetch.txt index 4d4207386..21a33d2c4 100644 --- a/Documentation/git-http-fetch.txt +++ b/Documentation/git-http-fetch.txt @@ -3,7 +3,7 @@ git-http-fetch(1) NAME ---- -git-http-fetch - Download from a remote git repository via HTTP +git-http-fetch - Download from a remote Git repository via HTTP SYNOPSIS @@ -13,7 +13,10 @@ SYNOPSIS DESCRIPTION ----------- -Downloads a remote git repository via HTTP. +Downloads a remote Git repository via HTTP. + +*NOTE*: use of this command without -a is deprecated. The -a +behaviour will become the default in a future release. OPTIONS ------- diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt index 909687fed..7a4e05552 100644 --- a/Documentation/git-index-pack.txt +++ b/Documentation/git-index-pack.txt @@ -19,7 +19,7 @@ DESCRIPTION Reads a packed archive (.pack) from the specified file, and builds a pack index file (.idx) for it. The packed archive together with the pack index can then be placed in the -objects/pack/ directory of a git repository. +objects/pack/ directory of a Git repository. OPTIONS @@ -39,7 +39,7 @@ OPTIONS When this flag is provided, the pack is read from stdin instead and a copy is then written to <pack-file>. If <pack-file> is not specified, the pack is written to - objects/pack/ directory of the current git repository with + objects/pack/ directory of the current Git repository with a default name determined from the pack content. If <pack-file> is not specified consider using --keep to prevent a race condition between this process and @@ -74,12 +74,25 @@ OPTIONS --strict:: Die, if the pack contains broken objects or links. +--check-self-contained-and-connected:: + Die if the pack contains broken links. For internal use only. + +--threads=<n>:: + Specifies the number of threads to spawn when resolving + deltas. This requires that index-pack be compiled with + pthreads otherwise this option is ignored with a warning. + This is meant to reduce packing time on multiprocessor + machines. The required amount of memory for the delta search + window is however multiplied by the number of threads. + Specifying 0 will cause Git to auto-detect the number of CPU's + and use maximum 3 threads. + Note ---- Once the index has been created, the list of object names is sorted -and the SHA1 hash of that list is printed to stdout. If --stdin was +and the SHA-1 hash of that list is printed to stdout. If --stdin was also used then this is prefixed by either "pack\t", or "keep\t" if a new .keep file was successfully created. This is useful to remove a .keep file used as a lock to prevent the race with 'git repack' diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt index a21e34678..648a6cd78 100644 --- a/Documentation/git-init-db.txt +++ b/Documentation/git-init-db.txt @@ -3,7 +3,7 @@ git-init-db(1) NAME ---- -git-init-db - Creates an empty git repository +git-init-db - Creates an empty Git repository SYNOPSIS diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index 9ac2bbaa5..afd721e3a 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -3,7 +3,7 @@ git-init(1) NAME ---- -git-init - Create an empty git repository or reinitialize an existing one +git-init - Create an empty Git repository or reinitialize an existing one SYNOPSIS @@ -17,7 +17,7 @@ SYNOPSIS DESCRIPTION ----------- -This command creates an empty git repository - basically a `.git` +This command creates an empty Git repository - basically a `.git` directory with subdirectories for `objects`, `refs/heads`, `refs/tags`, and template files. An initial `HEAD` file that references the HEAD of the master branch is also created. @@ -58,19 +58,19 @@ DIRECTORY" section below.) --separate-git-dir=<git dir>:: Instead of initializing the repository where it is supposed to be, -place a filesytem-agnostic git symbolic link there, pointing to the -specified git path, and initialize a git repository at the path. The -result is git repository can be separated from working tree. If this +place a filesytem-agnostic Git symbolic link there, pointing to the +specified path, and initialize a Git repository at the path. The +result is Git repository can be separated from working tree. If this is reinitialization, the repository will be moved to the specified path. --shared[=(false|true|umask|group|all|world|everybody|0xxx)]:: -Specify that the git repository is to be shared amongst several users. This +Specify that the Git repository is to be shared amongst several users. This allows users belonging to the same group to push into that repository. When specified, the config variable "core.sharedRepository" is set so that files and directories under `$GIT_DIR` are created with the -requested permissions. When not specified, git will use permissions reported +requested permissions. When not specified, Git will use permissions reported by umask(2). The option can have the following values, defaulting to 'group' if no value @@ -130,7 +130,7 @@ The suggested patterns and hook files are all modifiable and extensible. EXAMPLES -------- -Start a new git repository for an existing code base:: +Start a new Git repository for an existing code base:: + ---------------- $ cd /path/to/my/codebase diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt index 08f85ba04..f3eef510f 100644 --- a/Documentation/git-instaweb.txt +++ b/Documentation/git-instaweb.txt @@ -51,8 +51,8 @@ OPTIONS start:: --start:: - Start the httpd instance and exit. This does not generate - any of the configuration files for spawning a new instance. + Start the httpd instance and exit. Regenerate configuration files + as necessary for spawning a new instance. stop:: --stop:: @@ -62,8 +62,8 @@ stop:: restart:: --restart:: - Restart the httpd instance and exit. This does not generate - any of the configuration files for spawning a new instance. + Restart the httpd instance and exit. Regenerate configuration files + as necessary for spawning a new instance. CONFIGURATION ------------- @@ -84,6 +84,10 @@ If the configuration variable 'instaweb.browser' is not set, 'web.browser' will be used instead if it is defined. See linkgit:git-web{litdd}browse[1] for more information about this. +SEE ALSO +-------- +linkgit:gitweb[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 771a3565b..1f7bc67d6 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -9,32 +9,21 @@ git-log - Show commit logs SYNOPSIS -------- [verse] -'git log' [<options>] [<since>..<until>] [[\--] <path>...] +'git log' [<options>] [<revision range>] [[\--] <path>...] DESCRIPTION ----------- Shows the commit logs. -The command takes options applicable to the 'git rev-list' +The command takes options applicable to the `git rev-list` command to control what is shown and how, and options applicable to -the 'git diff-*' commands to control how the changes +the `git diff-*` commands to control how the changes each commit introduces are shown. OPTIONS ------- --<n>:: - Limits the number of commits to show. - Note that this is a commit limiting option, see below. - -<since>..<until>:: - Show only commits between the named two commits. When - either <since> or <until> is omitted, it defaults to - `HEAD`, i.e. the tip of the current branch. - For a more complete list of ways to spell <since> - and <until>, see linkgit:gitrevisions[7]. - --follow:: Continue listing the history of a file beyond renames (works only for a single file). @@ -51,37 +40,61 @@ OPTIONS Print out the ref name given on the command line by which each commit was reached. +--use-mailmap:: + Use mailmap file to map author and committer names and email + addresses to canonical real names and email addresses. See + linkgit:git-shortlog[1]. + --full-diff:: - Without this flag, "git log -p <path>..." shows commits that + Without this flag, `git log -p <path>...` shows commits that touch the specified paths, and diffs about the same specified paths. With this, the full diff is shown for commits that touch the specified paths; this means that "<path>..." limits only commits, and doesn't limit diff for those commits. + Note that this affects all diff-based output types, e.g. those -produced by --stat etc. +produced by `--stat`, etc. --log-size:: - Before the log message print out its size in bytes. Intended - mainly for porcelain tools consumption. If git is unable to - produce a valid value size is set to zero. - Note that only message is considered, if also a diff is shown - its size is not included. + Include a line ``log size <number>'' in the output for each commit, + where <number> is the length of that commit's message in bytes. + Intended to speed up tools that read log messages from `git log` + output by allowing them to allocate space in advance. + +-L <start>,<end>:<file>:: +-L :<regex>:<file>:: + Trace the evolution of the line range given by "<start>,<end>" + (or the funcname regex <regex>) within the <file>. You may + not give any pathspec limiters. This is currently limited to + a walk starting from a single revision, i.e., you may only + give zero or one positive revision arguments. + You can specify this option more than once. ++ +include::line-range-format.txt[] + +<revision range>:: + Show only commits in the specified revision range. When no + <revision range> is specified, it defaults to `HEAD` (i.e. the + whole history leading to the current commit). `origin..HEAD` + specifies all the commits reachable from the current commit + (i.e. `HEAD`), but not from `origin`. For a complete list of + ways to spell <revision range>, see the 'Specifying Ranges' + section of linkgit:gitrevisions[7]. [\--] <path>...:: Show only commits that are enough to explain how the files - that match the specified paths came to be. See "History - Simplification" below for details and other simplification + that match the specified paths came to be. See 'History + Simplification' below for details and other simplification modes. + -To prevent confusion with options and branch names, paths may need to -be prefixed with "\-- " to separate them from options or refnames. +Paths may need to be prefixed with ``\-- '' to separate them from +options or the revision range, when confusion arises. include::rev-list-options.txt[] include::pretty-formats.txt[] -Common diff options +COMMON DIFF OPTIONS ------------------- :git-log: 1 @@ -89,73 +102,81 @@ include::diff-options.txt[] include::diff-generate-patch.txt[] -Examples +EXAMPLES -------- -git log --no-merges:: +`git log --no-merges`:: Show the whole commit history, but skip any merges -git log v2.6.12.. include/scsi drivers/scsi:: +`git log v2.6.12.. include/scsi drivers/scsi`:: Show all commits since version 'v2.6.12' that changed any file - in the include/scsi or drivers/scsi subdirectories + in the `include/scsi` or `drivers/scsi` subdirectories -git log --since="2 weeks ago" \-- gitk:: +`git log --since="2 weeks ago" -- gitk`:: Show the changes during the last two weeks to the file 'gitk'. - The "--" is necessary to avoid confusion with the *branch* named + The ``--'' is necessary to avoid confusion with the *branch* named 'gitk' -git log --name-status release..test:: +`git log --name-status release..test`:: Show the commits that are in the "test" branch but not yet in the "release" branch, along with the list of paths each commit modifies. -git log --follow builtin-rev-list.c:: +`git log --follow builtin/rev-list.c`:: - Shows the commits that changed builtin-rev-list.c, including + Shows the commits that changed `builtin/rev-list.c`, including those commits that occurred before the file was given its present name. -git log --branches --not --remotes=origin:: +`git log --branches --not --remotes=origin`:: Shows all commits that are in any of local branches but not in any of remote-tracking branches for 'origin' (what you have that origin doesn't). -git log master --not --remotes=*/master:: +`git log master --not --remotes=*/master`:: Shows all commits that are in local master but not in any remote repository master branches. -git log -p -m --first-parent:: +`git log -p -m --first-parent`:: Shows the history including change diffs, but only from the - "main branch" perspective, skipping commits that come from merged + ``main branch'' perspective, skipping commits that come from merged branches, and showing full diffs of changes introduced by the merges. This makes sense only when following a strict policy of merging all topic branches when staying on a single integration branch. +`git log -L '/int main/',/^}/:main.c`:: + + Shows how the function `main()` in the file `main.c` evolved + over time. + +`git log -3`:: + + Limits the number of commits to show to 3. -Discussion +DISCUSSION ---------- include::i18n.txt[] -Configuration +CONFIGURATION ------------- See linkgit:git-config[1] for core variables and linkgit:git-diff[1] for settings related to diff generation. format.pretty:: - Default for the `--format` option. (See "PRETTY FORMATS" above.) - Defaults to "medium". + Default for the `--format` option. (See 'Pretty Formats' above.) + Defaults to `medium`. i18n.logOutputEncoding:: - Encoding to use when displaying logs. (See "Discussion", above.) - Defaults to the value of `i18n.commitEncoding` if set, UTF-8 + Encoding to use when displaying logs. (See 'Discussion' above.) + Defaults to the value of `i18n.commitEncoding` if set, and UTF-8 otherwise. log.date:: @@ -164,18 +185,18 @@ log.date:: dates like `Sat May 8 19:35:34 2010 -0500`. log.showroot:: - If `false`, 'git log' and related commands will not treat the + If `false`, `git log` and related commands will not treat the initial commit as a big creation event. Any root commits in `git log -p` output would be shown without a diff attached. The default is `true`. -mailmap.file:: +mailmap.*:: See linkgit:git-shortlog[1]. notes.displayRef:: Which refs, in addition to the default set by `core.notesRef` or 'GIT_NOTES_REF', to read notes from when showing commit - messages with the 'log' family of commands. See + messages with the `log` family of commands. See linkgit:git-notes[1]. + May be an unabbreviated ref name or a glob and may be specified diff --git a/Documentation/git-lost-found.txt b/Documentation/git-lost-found.txt deleted file mode 100644 index c406a1100..000000000 --- a/Documentation/git-lost-found.txt +++ /dev/null @@ -1,73 +0,0 @@ -git-lost-found(1) -================= - -NAME ----- -git-lost-found - Recover lost refs that luckily have not yet been pruned - -SYNOPSIS --------- -[verse] -'git lost-found' - -DESCRIPTION ------------ - -*NOTE*: this command is deprecated. Use linkgit:git-fsck[1] with -the option '--lost-found' instead. - -Finds dangling commits and tags from the object database, and -creates refs to them in the .git/lost-found/ directory. Commits and -tags that dereference to commits are stored in .git/lost-found/commit, -and other objects are stored in .git/lost-found/other. - - -OUTPUT ------- -Prints to standard output the object names and one-line descriptions -of any commits or tags found. - -EXAMPLE -------- - -Suppose you run 'git tag -f' and mistype the tag to overwrite. -The ref to your tag is overwritten, but until you run 'git -prune', the tag itself is still there. - ------------- -$ git lost-found -[1ef2b196d909eed523d4f3c9bf54b78cdd6843c6] GIT 0.99.9c -... ------------- - -Also you can use gitk to browse how any tags found relate to each -other. - ------------- -$ gitk $(cd .git/lost-found/commit && echo ??*) ------------- - -After making sure you know which the object is the tag you are looking -for, you can reconnect it to your regular .git/refs hierarchy. - ------------- -$ git cat-file -t 1ef2b196 -tag -$ git cat-file tag 1ef2b196 -object fa41bbce8e38c67a218415de6cfa510c7e50032a -type commit -tag v0.99.9c -tagger Junio C Hamano <junkio@cox.net> 1131059594 -0800 - -GIT 0.99.9c - -This contains the following changes from the "master" branch, since -... -$ git update-ref refs/tags/not-lost-anymore 1ef2b196 -$ git rev-parse not-lost-anymore -1ef2b196d909eed523d4f3c9bf54b78cdd6843c6 ------------- - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt index 4b2829281..c0856a6e0 100644 --- a/Documentation/git-ls-files.txt +++ b/Documentation/git-ls-files.txt @@ -92,7 +92,7 @@ OPTIONS directory and its subdirectories in <file>. --exclude-standard:: - Add the standard git exclusions: .git/info/exclude, .gitignore + Add the standard Git exclusions: .git/info/exclude, .gitignore in each directory, and the user's global exclusion file. --error-unmatch:: @@ -164,7 +164,7 @@ which case it outputs: 'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine detailed information on unmerged paths. -For an unmerged path, instead of recording a single mode/SHA1 pair, +For an unmerged path, instead of recording a single mode/SHA-1 pair, the index records up to three such pairs; one from tree O in stage 1, A in stage 2, and B in stage 3. This information can be used by the user (or the porcelain) to see what should eventually be recorded at the diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 7a9b86a58..2e22915eb 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -42,10 +42,15 @@ OPTIONS it successfully talked with the remote repository, whether it found any matching refs. +--get-url:: + Expand the URL of the given remote repository taking into account any + "url.<base>.insteadOf" config setting (See linkgit:git-config[1]) and + exit without talking to the remote. + <repository>:: - Location of the repository. The shorthand defined in - $GIT_DIR/branches/ can be used. Use "." (dot) to list references in - the local repository. + The "remote" repository to query. This parameter can be + either a URL or the name of a remote (see the GIT URLS and + REMOTES sections of linkgit:git-fetch[1]). <refs>...:: When unspecified, all references, after filtering done @@ -65,9 +70,8 @@ EXAMPLES $ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc 5fe978a5381f1fbad26a80e682ddd2a401966740 refs/heads/master c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/pu - b1d096f2926c4e37c9c0b6a7bf2119bedaa277cb refs/heads/rc - $ echo http://www.kernel.org/pub/scm/git/git.git >.git/branches/public - $ git ls-remote --tags public v\* + $ git remote add korg http://www.kernel.org/pub/scm/git/git.git + $ git ls-remote --tags korg v\* d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99 f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1 c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2 diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt index 51dc32574..164a3c6ed 100644 --- a/Documentation/git-mailinfo.txt +++ b/Documentation/git-mailinfo.txt @@ -9,7 +9,7 @@ git-mailinfo - Extracts patch and authorship from a single e-mail message SYNOPSIS -------- [verse] -'git mailinfo' [-k|-b] [-u | --encoding=<encoding> | -n] [--scissors] <msg> <patch> +'git mailinfo' [-k|-b] [-u | --encoding=<encoding> | -n] [--[no-]scissors] <msg> <patch> DESCRIPTION @@ -25,13 +25,24 @@ command directly. See linkgit:git-am[1] instead. OPTIONS ------- -k:: - Usually the program 'cleans up' the Subject: header line - to extract the title line for the commit log message, - among which (1) remove 'Re:' or 're:', (2) leading - whitespaces, (3) '[' up to ']', typically '[PATCH]', and - then prepends "[PATCH] ". This flag forbids this - munging, and is most useful when used to read back - 'git format-patch -k' output. + Usually the program removes email cruft from the Subject: + header line to extract the title line for the commit log + message. This option prevents this munging, and is most + useful when used to read back 'git format-patch -k' output. ++ +Specifically, the following are removed until none of them remain: ++ +-- +* Leading and trailing whitespace. + +* Leading `Re:`, `re:`, and `:`. + +* Leading bracketed strings (between `[` and `]`, usually + `[PATCH]`). +-- ++ +Finally, runs of whitespace are normalized to a single ASCII space +character. -b:: When -k is not in effect, all leading strings bracketed with '[' diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt index b295bf833..808426faa 100644 --- a/Documentation/git-merge-base.txt +++ b/Documentation/git-merge-base.txt @@ -11,7 +11,9 @@ SYNOPSIS [verse] 'git merge-base' [-a|--all] <commit> <commit>... 'git merge-base' [-a|--all] --octopus <commit>... +'git merge-base' --is-ancestor <commit> <commit> 'git merge-base' --independent <commit>... +'git merge-base' --fork-point <ref> [<commit>] DESCRIPTION ----------- @@ -23,8 +25,8 @@ that does not have any better common ancestor is a 'best common ancestor', i.e. a 'merge base'. Note that there can be more than one merge base for a pair of commits. -OPERATION MODE --------------- +OPERATION MODES +--------------- As the most common special case, specifying only two commits on the command line means computing the merge base between the given two commits. @@ -50,6 +52,20 @@ from linkgit:git-show-branch[1] when used with the `--merge-base` option. from any other. This mimics the behavior of 'git show-branch --independent'. +--is-ancestor:: + Check if the first <commit> is an ancestor of the second <commit>, + and exit with status 0 if true, or with status 1 if not. + Errors are signaled by a non-zero status that is not 1. + +--fork-point:: + Find the point at which a branch (or any history that leads + to <commit>) forked from another branch (or any reference) + <ref>. This does not just look for the common ancestor of + the two commits, but also takes into account the reflog of + <ref> to see if the history leading to <commit> forked from + an earlier incarnation of the branch <ref> (see discussion + on this mode below). + OPTIONS ------- -a:: @@ -110,6 +126,52 @@ both '1' and '2' are merge-bases of A and B. Neither one is better than the other (both are 'best' merge bases). When the `--all` option is not given, it is unspecified which best one is output. +A common idiom to check "fast-forward-ness" between two commits A +and B is (or at least used to be) to compute the merge base between +A and B, and check if it is the same as A, in which case, A is an +ancestor of B. You will see this idiom used often in older scripts. + + A=$(git rev-parse --verify A) + if test "$A" = "$(git merge-base A B)" + then + ... A is an ancestor of B ... + fi + +In modern git, you can say this in a more direct way: + + if git merge-base --is-ancestor A B + then + ... A is an ancestor of B ... + fi + +instead. + +Discussion on fork-point mode +----------------------------- + +After working on the `topic` branch created with `git checkout -b +topic origin/master`, the history of remote-tracking branch +`origin/master` may have been rewound and rebuilt, leading to a +history of this shape: + + o---B1 + / + ---o---o---B2--o---o---o---B (origin/master) + \ + B3 + \ + Derived (topic) + +where `origin/master` used to point at commits B3, B2, B1 and now it +points at B, and your `topic` branch was started on top of it back +when `origin/master` was at B3. This mode uses the reflog of +`origin/master` to find B3 as the fork point, so that the `topic` +can be rebased on top of the updated `origin/master` by: + + $ fork_point=$(git merge-base --fork-point origin/master topic) + $ git rebase --onto origin/master $fork_point topic + + See also -------- linkgit:git-rev-list[1], diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt index 635c66956..d2fc12ec7 100644 --- a/Documentation/git-merge-file.txt +++ b/Documentation/git-merge-file.txt @@ -11,7 +11,7 @@ SYNOPSIS [verse] 'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]] [--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>] - <current-file> <base-file> <other-file> + [--[no-]diff3] <current-file> <base-file> <other-file> DESCRIPTION @@ -66,6 +66,9 @@ OPTIONS -q:: Quiet; do not warn about conflicts. +--diff3:: + Show conflicts in "diff3" style. + --ours:: --theirs:: --union:: @@ -76,12 +79,12 @@ OPTIONS EXAMPLES -------- -git merge-file README.my README README.upstream:: +`git merge-file README.my README README.upstream`:: combines the changes of README.my and README.upstream since README, tries to merge them and writes the result into README.my. -git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345:: +`git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345`:: merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels `a` and `c` instead of `tmp/a123` and `tmp/c345`. diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt index e0df1b334..02676fb39 100644 --- a/Documentation/git-merge-index.txt +++ b/Documentation/git-merge-index.txt @@ -14,7 +14,7 @@ SYNOPSIS DESCRIPTION ----------- This looks up the <file>(s) in the index and, if there are any merge -entries, passes the SHA1 hash for those files as arguments 1, 2, 3 (empty +entries, passes the SHA-1 hash for those files as arguments 1, 2, 3 (empty argument if no file), and <file> as argument 4. File modes for the three files are passed as arguments 5, 6 and 7. @@ -41,13 +41,13 @@ If 'git merge-index' is called with multiple <file>s (or -a) then it processes them in turn only stopping if merge returns a non-zero exit code. -Typically this is run with a script calling git's imitation of +Typically this is run with a script calling Git's imitation of the 'merge' command from the RCS package. A sample script called 'git merge-one-file' is included in the distribution. -ALERT ALERT ALERT! The git "merge object order" is different from the +ALERT ALERT ALERT! The Git "merge object order" is different from the RCS 'merge' program merge object order. In the above ordering, the original is first. But the argument order to the 3-way merge program 'merge' is to have the original in the middle. Don't ask me why. diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt index c5f84b649..58731c194 100644 --- a/Documentation/git-merge-tree.txt +++ b/Documentation/git-merge-tree.txt @@ -13,7 +13,7 @@ SYNOPSIS DESCRIPTION ----------- -Reads three treeish, and output trivial merge results and +Reads three tree-ish, and output trivial merge results and conflicting stages to the standard output. This is similar to what three-way 'git read-tree -m' does, but instead of storing the results in the index, the command outputs the entries to the diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index e2e6aba17..439545926 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -9,8 +9,8 @@ git-merge - Join two or more development histories together SYNOPSIS -------- [verse] -'git merge' [-n] [--stat] [--no-commit] [--squash] - [-s <strategy>] [-X <strategy-option>] +'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] + [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [--[no-]rerere-autoupdate] [-m <msg>] [<commit>...] 'git merge' <msg> HEAD <commit>... 'git merge' --abort @@ -56,8 +56,8 @@ especially if those changes were further modified after the merge was started), 'git merge --abort' will in some cases be unable to reconstruct the original (pre-merge) changes. Therefore: -*Warning*: Running 'git merge' with uncommitted changes is -discouraged: while possible, it leaves you in a state that is hard to +*Warning*: Running 'git merge' with non-trivial uncommitted changes is +discouraged: while possible, it may leave you in a state that is hard to back out of in the case of a conflict. @@ -65,6 +65,10 @@ OPTIONS ------- include::merge-options.txt[] +-S[<keyid>]:: +--gpg-sign[=<keyid>]:: + GPG-sign the resulting merge commit. + -m <msg>:: Set the commit message to be used for the merge commit (in case one is created). @@ -76,8 +80,7 @@ The 'git fmt-merge-msg' command can be used to give a good default for automated 'git merge' invocations. ---rerere-autoupdate:: ---no-rerere-autoupdate:: +--[no-]rerere-autoupdate:: Allow the rerere mechanism to update the index with the result of auto-conflict resolution if possible. @@ -99,7 +102,7 @@ commit or stash your changes before running 'git merge'. more than two parents (affectionately called an Octopus merge). + If no commit is given from the command line, and if `merge.defaultToUpstream` -configuration variable is set, merge the remote tracking branches +configuration variable is set, merge the remote-tracking branches that the current branch is configured to use as its upstream. See also the configuration section of this manual page. @@ -170,6 +173,30 @@ happens: If you tried a merge which resulted in complex conflicts and want to start over, you can recover with `git merge --abort`. +MERGING TAG +----------- + +When merging an annotated (and possibly signed) tag, Git always +creates a merge commit even if a fast-forward merge is possible, and +the commit message template is prepared with the tag message. +Additionally, if the tag is signed, the signature check is reported +as a comment in the message template. See also linkgit:git-tag[1]. + +When you want to just integrate with the work leading to the commit +that happens to be tagged, e.g. synchronizing with an upstream +release point, you may not want to make an unnecessary merge commit. + +In such a case, you can "unwrap" the tag yourself before feeding it +to `git merge`, or pass `--ff-only` when you do not have any work on +your own. e.g. + +---- +git fetch origin +git merge v1.2.3^0 +git merge --ff-only v1.2.3 +---- + + HOW CONFLICTS ARE PRESENTED --------------------------- @@ -178,10 +205,10 @@ of the merge. Among the changes made to the common ancestor's version, non-overlapping ones (that is, you changed an area of the file while the other side left that area intact, or vice versa) are incorporated in the final result verbatim. When both sides made changes to the same area, -however, git cannot randomly pick one side over the other, and asks you to +however, Git cannot randomly pick one side over the other, and asks you to resolve it by leaving what both sides did to that area. -By default, git uses the same style as that is used by "merge" program +By default, Git uses the same style as the one used by the "merge" program from the RCS suite to present such a conflicted hunk, like this: ------------ diff --git a/Documentation/git-mergetool--lib.txt b/Documentation/git-mergetool--lib.txt index f98a41b87..055550b2b 100644 --- a/Documentation/git-mergetool--lib.txt +++ b/Documentation/git-mergetool--lib.txt @@ -3,7 +3,7 @@ git-mergetool{litdd}lib(1) NAME ---- -git-mergetool--lib - Common git merge tool shell scriptlets +git-mergetool--lib - Common Git merge tool shell scriptlets SYNOPSIS -------- @@ -19,7 +19,7 @@ Porcelain-ish scripts and/or are writing new ones. The 'git-mergetool{litdd}lib' scriptlet is designed to be sourced (using `.`) by other shell scripts to set up functions for working -with git merge tools. +with Git merge tools. Before sourcing 'git-mergetool{litdd}lib', your script must set `TOOL_MODE` to define the operation mode for the functions listed below. diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt index 2a49de7cf..07137f252 100644 --- a/Documentation/git-mergetool.txt +++ b/Documentation/git-mergetool.txt @@ -8,7 +8,7 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts SYNOPSIS -------- [verse] -'git mergetool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<file>...] +'git mergetool' [--tool=<tool>] [-y | --[no-]prompt] [<file>...] DESCRIPTION ----------- @@ -27,9 +27,9 @@ OPTIONS -t <tool>:: --tool=<tool>:: Use the merge resolution program specified by <tool>. - Valid merge tools are: - araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kdiff3, - meld, opendiff, p4merge, tkdiff, tortoisemerge, vimdiff and xxdiff. + Valid values include emerge, gvimdiff, kdiff3, + meld, vimdiff, and tortoisemerge. Run `git mergetool --tool-help` + for the list of valid <tool> settings. + If a merge resolution program is not specified, 'git mergetool' will use the configuration variable `merge.tool`. If the @@ -64,6 +64,9 @@ variable `mergetool.<tool>.trustExitCode` can be set to `true`. Otherwise, 'git mergetool' will prompt the user to indicate the success of the resolution after the custom tool has exited. +--tool-help:: + Print a list of merge tools that may be used with `--tool`. + -y:: --no-prompt:: Don't prompt before each invocation of the merge resolution diff --git a/Documentation/git-mktag.txt b/Documentation/git-mktag.txt index 65e167a5c..3ca158b05 100644 --- a/Documentation/git-mktag.txt +++ b/Documentation/git-mktag.txt @@ -28,9 +28,9 @@ A tag signature file has a very simple fixed format: four lines of tagger <tagger> followed by some 'optional' free-form message (some tags created -by older git may not have `tagger` line). The message, when +by older Git may not have `tagger` line). The message, when exists, is separated by a blank line from the header. The -message part may contain a signature that git itself doesn't +message part may contain a signature that Git itself doesn't care about, but that can be verified with gpg. GIT diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt index b8db37396..e4531325c 100644 --- a/Documentation/git-mv.txt +++ b/Documentation/git-mv.txt @@ -13,10 +13,10 @@ SYNOPSIS DESCRIPTION ----------- -This script is used to move or rename a file, directory or symlink. +Move or rename a file, directory or symlink. - git mv [-f] [-n] <source> <destination> - git mv [-f] [-n] [-k] <source> ... <destination directory> + git mv [-v] [-f] [-n] [-k] <source> <destination> + git mv [-v] [-f] [-n] [-k] <source> ... <destination directory> In the first form, it renames <source>, which must exist and be either a file, symlink or directory, to <destination>. @@ -34,12 +34,36 @@ OPTIONS -k:: Skip move or rename actions which would lead to an error condition. An error happens when a source is neither existing nor - controlled by GIT, or when it would overwrite an existing + controlled by Git, or when it would overwrite an existing file unless '-f' is given. -n:: --dry-run:: Do nothing; only show what would happen +-v:: +--verbose:: + Report the names of files as they are moved. + +SUBMODULES +---------- +Moving a submodule using a gitfile (which means they were cloned +with a Git version 1.7.8 or newer) will update the gitfile and +core.worktree setting to make the submodule work in the new location. +It also will attempt to update the submodule.<name>.path setting in +the linkgit:gitmodules[5] file and stage that file (unless -n is used). + +BUGS +---- +Each time a superproject update moves a populated submodule (e.g. when +switching between commits before and after the move) a stale submodule +checkout will remain in the old location and an empty directory will +appear in the new location. To populate the submodule again in the new +location the user will have to run "git submodule update" +afterwards. Removing the old directory is only safe when it uses a +gitfile, as otherwise the history of the submodule will be deleted +too. Both steps will be obsolete when recursive submodule update has +been implemented. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt index ad1d1468c..ca28fb8e2 100644 --- a/Documentation/git-name-rev.txt +++ b/Documentation/git-name-rev.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git name-rev' [--tags] [--refs=<pattern>] - ( --all | --stdin | <committish>... ) + ( --all | --stdin | <commit-ish>... ) DESCRIPTION ----------- @@ -25,14 +25,17 @@ OPTIONS Do not use branch names, but only tags to name the commits --refs=<pattern>:: - Only use refs whose names match a given shell pattern. + Only use refs whose names match a given shell pattern. The pattern + can be one of branch name, tag name or fully qualified ref name. --all:: List all commits reachable from all refs --stdin:: - Read from stdin, append "(<rev_name>)" to all sha1's of nameable - commits, and pass to stdout + Transform stdin by substituting all the 40-character SHA-1 + hexes (say $hex) with "$hex ($rev_name)". When used with + --name-only, substitute with "$rev_name", omitting $hex + altogether. Intended for the scripter's use. --name-only:: Instead of printing both the SHA-1 and the name, print only diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index 6a187f2e2..84bb0fecb 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -39,6 +39,10 @@ message stored in the commit object, the notes are indented like the message, after an unindented line saying "Notes (<refname>):" (or "Notes:" for `refs/notes/commits`). +Notes can also be added to patches prepared with `git format-patch` by +using the `--notes` option. Such notes are added as a patch commentary +after a three dash separator line. + To change which notes are shown by 'git log', see the "notes.displayRef" configuration in linkgit:git-log[1]. @@ -70,7 +74,7 @@ copy:: second object). This subcommand is equivalent to: `git notes add [-f] -C $(git notes list <from-object>) <to-object>` + -In `\--stdin` mode, take lines in the format +In `--stdin` mode, take lines in the format + ---------- <from-object> SP <to-object> [ SP <rest> ] LF @@ -142,8 +146,9 @@ OPTIONS -C <object>:: --reuse-message=<object>:: - Take the note message from the given blob object (for - example, another note). + Take the given blob object (for example, another note) as the + note message. (Use `git notes copy <object>` instead to + copy notes between objects.) -c <object>:: --reedit-message=<object>:: @@ -285,6 +290,8 @@ $ blob=$(git hash-object -w a.out) $ git notes --ref=built add -C "$blob" HEAD ------------ +(You cannot simply use `git notes --ref=built add -F a.out HEAD` +because that is not binary-safe.) Of course, it doesn't make much sense to display non-text-format notes with 'git log', so if you use such notes, you'll probably need to write some special-purpose tools to do something useful with them. @@ -368,16 +375,6 @@ does not match any refs is silently ignored. If not set in the environment, the list of notes to copy depends on the `notes.rewrite.<command>` and `notes.rewriteRef` settings. - -Author ------- -Written by Johannes Schindelin <johannes.schindelin@gmx.de> and -Johan Herland <johan@herland.net> - -Documentation -------------- -Documentation by Johannes Schindelin and Johan Herland - GIT --- Part of the linkgit:git[7] suite diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt new file mode 100644 index 000000000..6ab5f9497 --- /dev/null +++ b/Documentation/git-p4.txt @@ -0,0 +1,574 @@ +git-p4(1) +========= + +NAME +---- +git-p4 - Import from and submit to Perforce repositories + + +SYNOPSIS +-------- +[verse] +'git p4 clone' [<sync options>] [<clone options>] <p4 depot path>... +'git p4 sync' [<sync options>] [<p4 depot path>...] +'git p4 rebase' +'git p4 submit' [<submit options>] [<master branch name>] + + +DESCRIPTION +----------- +This command provides a way to interact with p4 repositories +using Git. + +Create a new Git repository from an existing p4 repository using +'git p4 clone', giving it one or more p4 depot paths. Incorporate +new commits from p4 changes with 'git p4 sync'. The 'sync' command +is also used to include new branches from other p4 depot paths. +Submit Git changes back to p4 using 'git p4 submit'. The command +'git p4 rebase' does a sync plus rebases the current branch onto +the updated p4 remote branch. + + +EXAMPLE +------- +* Clone a repository: ++ +------------ +$ git p4 clone //depot/path/project +------------ + +* Do some work in the newly created Git repository: ++ +------------ +$ cd project +$ vi foo.h +$ git commit -a -m "edited foo.h" +------------ + +* Update the Git repository with recent changes from p4, rebasing your + work on top: ++ +------------ +$ git p4 rebase +------------ + +* Submit your commits back to p4: ++ +------------ +$ git p4 submit +------------ + + +COMMANDS +-------- + +Clone +~~~~~ +Generally, 'git p4 clone' is used to create a new Git directory +from an existing p4 repository: +------------ +$ git p4 clone //depot/path/project +------------ +This: + +1. Creates an empty Git repository in a subdirectory called 'project'. ++ +2. Imports the full contents of the head revision from the given p4 +depot path into a single commit in the Git branch 'refs/remotes/p4/master'. ++ +3. Creates a local branch, 'master' from this remote and checks it out. + +To reproduce the entire p4 history in Git, use the '@all' modifier on +the depot path: +------------ +$ git p4 clone //depot/path/project@all +------------ + + +Sync +~~~~ +As development continues in the p4 repository, those changes can +be included in the Git repository using: +------------ +$ git p4 sync +------------ +This command finds new changes in p4 and imports them as Git commits. + +P4 repositories can be added to an existing Git repository using +'git p4 sync' too: +------------ +$ mkdir repo-git +$ cd repo-git +$ git init +$ git p4 sync //path/in/your/perforce/depot +------------ +This imports the specified depot into +'refs/remotes/p4/master' in an existing Git repository. The +'--branch' option can be used to specify a different branch to +be used for the p4 content. + +If a Git repository includes branches 'refs/remotes/origin/p4', these +will be fetched and consulted first during a 'git p4 sync'. Since +importing directly from p4 is considerably slower than pulling changes +from a Git remote, this can be useful in a multi-developer environment. + +If there are multiple branches, doing 'git p4 sync' will automatically +use the "BRANCH DETECTION" algorithm to try to partition new changes +into the right branch. This can be overridden with the '--branch' +option to specify just a single branch to update. + + +Rebase +~~~~~~ +A common working pattern is to fetch the latest changes from the p4 depot +and merge them with local uncommitted changes. Often, the p4 repository +is the ultimate location for all code, thus a rebase workflow makes +sense. This command does 'git p4 sync' followed by 'git rebase' to move +local commits on top of updated p4 changes. +------------ +$ git p4 rebase +------------ + + +Submit +~~~~~~ +Submitting changes from a Git repository back to the p4 repository +requires a separate p4 client workspace. This should be specified +using the 'P4CLIENT' environment variable or the Git configuration +variable 'git-p4.client'. The p4 client must exist, but the client root +will be created and populated if it does not already exist. + +To submit all changes that are in the current Git branch but not in +the 'p4/master' branch, use: +------------ +$ git p4 submit +------------ + +To specify a branch other than the current one, use: +------------ +$ git p4 submit topicbranch +------------ + +The upstream reference is generally 'refs/remotes/p4/master', but can +be overridden using the '--origin=' command-line option. + +The p4 changes will be created as the user invoking 'git p4 submit'. The +'--preserve-user' option will cause ownership to be modified +according to the author of the Git commit. This option requires admin +privileges in p4, which can be granted using 'p4 protect'. + + +OPTIONS +------- + +General options +~~~~~~~~~~~~~~~ +All commands except clone accept these options. + +--git-dir <dir>:: + Set the 'GIT_DIR' environment variable. See linkgit:git[1]. + +-v:: +--verbose:: + Provide more progress information. + +Sync options +~~~~~~~~~~~~ +These options can be used in the initial 'clone' as well as in +subsequent 'sync' operations. + +--branch <ref>:: + Import changes into <ref> instead of refs/remotes/p4/master. + If <ref> starts with refs/, it is used as is. Otherwise, if + it does not start with p4/, that prefix is added. ++ +By default a <ref> not starting with refs/ is treated as the +name of a remote-tracking branch (under refs/remotes/). This +behavior can be modified using the --import-local option. ++ +The default <ref> is "master". ++ +This example imports a new remote "p4/proj2" into an existing +Git repository: ++ +---- + $ git init + $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2 +---- + +--detect-branches:: + Use the branch detection algorithm to find new paths in p4. It is + documented below in "BRANCH DETECTION". + +--changesfile <file>:: + Import exactly the p4 change numbers listed in 'file', one per + line. Normally, 'git p4' inspects the current p4 repository + state and detects the changes it should import. + +--silent:: + Do not print any progress information. + +--detect-labels:: + Query p4 for labels associated with the depot paths, and add + them as tags in Git. Limited usefulness as only imports labels + associated with new changelists. Deprecated. + +--import-labels:: + Import labels from p4 into Git. + +--import-local:: + By default, p4 branches are stored in 'refs/remotes/p4/', + where they will be treated as remote-tracking branches by + linkgit:git-branch[1] and other commands. This option instead + puts p4 branches in 'refs/heads/p4/'. Note that future + sync operations must specify '--import-local' as well so that + they can find the p4 branches in refs/heads. + +--max-changes <n>:: + Limit the number of imported changes to 'n'. Useful to + limit the amount of history when using the '@all' p4 revision + specifier. + +--keep-path:: + The mapping of file names from the p4 depot path to Git, by + default, involves removing the entire depot path. With this + option, the full p4 depot path is retained in Git. For example, + path '//depot/main/foo/bar.c', when imported from + '//depot/main/', becomes 'foo/bar.c'. With '--keep-path', the + Git path is instead 'depot/main/foo/bar.c'. + +--use-client-spec:: + Use a client spec to find the list of interesting files in p4. + See the "CLIENT SPEC" section below. + +Clone options +~~~~~~~~~~~~~ +These options can be used in an initial 'clone', along with the 'sync' +options described above. + +--destination <directory>:: + Where to create the Git repository. If not provided, the last + component in the p4 depot path is used to create a new + directory. + +--bare:: + Perform a bare clone. See linkgit:git-clone[1]. + +-/ <path>:: + Exclude selected depot paths when cloning. + +Submit options +~~~~~~~~~~~~~~ +These options can be used to modify 'git p4 submit' behavior. + +--origin <commit>:: + Upstream location from which commits are identified to submit to + p4. By default, this is the most recent p4 commit reachable + from 'HEAD'. + +-M:: + Detect renames. See linkgit:git-diff[1]. Renames will be + represented in p4 using explicit 'move' operations. There + is no corresponding option to detect copies, but there are + variables for both moves and copies. + +--preserve-user:: + Re-author p4 changes before submitting to p4. This option + requires p4 admin privileges. + +--export-labels:: + Export tags from Git as p4 labels. Tags found in Git are applied + to the perforce working directory. + +-n:: +--dry-run:: + Show just what commits would be submitted to p4; do not change + state in Git or p4. + +--prepare-p4-only:: + Apply a commit to the p4 workspace, opening, adding and deleting + files in p4 as for a normal submit operation. Do not issue the + final "p4 submit", but instead print a message about how to + submit manually or revert. This option always stops after the + first (oldest) commit. Git tags are not exported to p4. + +--conflict=(ask|skip|quit):: + Conflicts can occur when applying a commit to p4. When this + happens, the default behavior ("ask") is to prompt whether to + skip this commit and continue, or quit. This option can be used + to bypass the prompt, causing conflicting commits to be automatically + skipped, or to quit trying to apply commits, without prompting. + +--branch <branch>:: + After submitting, sync this named branch instead of the default + p4/master. See the "Sync options" section above for more + information. + +Rebase options +~~~~~~~~~~~~~~ +These options can be used to modify 'git p4 rebase' behavior. + +--import-labels:: + Import p4 labels. + +DEPOT PATH SYNTAX +----------------- +The p4 depot path argument to 'git p4 sync' and 'git p4 clone' can +be one or more space-separated p4 depot paths, with an optional +p4 revision specifier on the end: + +"//depot/my/project":: + Import one commit with all files in the '#head' change under that tree. + +"//depot/my/project@all":: + Import one commit for each change in the history of that depot path. + +"//depot/my/project@1,6":: + Import only changes 1 through 6. + +"//depot/proj1@all //depot/proj2@all":: + Import all changes from both named depot paths into a single + repository. Only files below these directories are included. + There is not a subdirectory in Git for each "proj1" and "proj2". + You must use the '--destination' option when specifying more + than one depot path. The revision specifier must be specified + identically on each depot path. If there are files in the + depot paths with the same name, the path with the most recently + updated version of the file is the one that appears in Git. + +See 'p4 help revisions' for the full syntax of p4 revision specifiers. + + +CLIENT SPEC +----------- +The p4 client specification is maintained with the 'p4 client' command +and contains among other fields, a View that specifies how the depot +is mapped into the client repository. The 'clone' and 'sync' commands +can consult the client spec when given the '--use-client-spec' option or +when the useClientSpec variable is true. After 'git p4 clone', the +useClientSpec variable is automatically set in the repository +configuration file. This allows future 'git p4 submit' commands to +work properly; the submit command looks only at the variable and does +not have a command-line option. + +The full syntax for a p4 view is documented in 'p4 help views'. 'git p4' +knows only a subset of the view syntax. It understands multi-line +mappings, overlays with '+', exclusions with '-' and double-quotes +around whitespace. Of the possible wildcards, 'git p4' only handles +'...', and only when it is at the end of the path. 'git p4' will complain +if it encounters an unhandled wildcard. + +Bugs in the implementation of overlap mappings exist. If multiple depot +paths map through overlays to the same location in the repository, +'git p4' can choose the wrong one. This is hard to solve without +dedicating a client spec just for 'git p4'. + +The name of the client can be given to 'git p4' in multiple ways. The +variable 'git-p4.client' takes precedence if it exists. Otherwise, +normal p4 mechanisms of determining the client are used: environment +variable P4CLIENT, a file referenced by P4CONFIG, or the local host name. + + +BRANCH DETECTION +---------------- +P4 does not have the same concept of a branch as Git. Instead, +p4 organizes its content as a directory tree, where by convention +different logical branches are in different locations in the tree. +The 'p4 branch' command is used to maintain mappings between +different areas in the tree, and indicate related content. 'git p4' +can use these mappings to determine branch relationships. + +If you have a repository where all the branches of interest exist as +subdirectories of a single depot path, you can use '--detect-branches' +when cloning or syncing to have 'git p4' automatically find +subdirectories in p4, and to generate these as branches in Git. + +For example, if the P4 repository structure is: +---- +//depot/main/... +//depot/branch1/... +---- + +And "p4 branch -o branch1" shows a View line that looks like: +---- +//depot/main/... //depot/branch1/... +---- + +Then this 'git p4 clone' command: +---- +git p4 clone --detect-branches //depot@all +---- +produces a separate branch in 'refs/remotes/p4/' for //depot/main, +called 'master', and one for //depot/branch1 called 'depot/branch1'. + +However, it is not necessary to create branches in p4 to be able to use +them like branches. Because it is difficult to infer branch +relationships automatically, a Git configuration setting +'git-p4.branchList' can be used to explicitly identify branch +relationships. It is a list of "source:destination" pairs, like a +simple p4 branch specification, where the "source" and "destination" are +the path elements in the p4 repository. The example above relied on the +presence of the p4 branch. Without p4 branches, the same result will +occur with: +---- +git init depot +cd depot +git config git-p4.branchList main:branch1 +git p4 clone --detect-branches //depot@all . +---- + + +PERFORMANCE +----------- +The fast-import mechanism used by 'git p4' creates one pack file for +each invocation of 'git p4 sync'. Normally, Git garbage compression +(linkgit:git-gc[1]) automatically compresses these to fewer pack files, +but explicit invocation of 'git repack -adf' may improve performance. + + +CONFIGURATION VARIABLES +----------------------- +The following config settings can be used to modify 'git p4' behavior. +They all are in the 'git-p4' section. + +General variables +~~~~~~~~~~~~~~~~~ +git-p4.user:: + User specified as an option to all p4 commands, with '-u <user>'. + The environment variable 'P4USER' can be used instead. + +git-p4.password:: + Password specified as an option to all p4 commands, with + '-P <password>'. + The environment variable 'P4PASS' can be used instead. + +git-p4.port:: + Port specified as an option to all p4 commands, with + '-p <port>'. + The environment variable 'P4PORT' can be used instead. + +git-p4.host:: + Host specified as an option to all p4 commands, with + '-h <host>'. + The environment variable 'P4HOST' can be used instead. + +git-p4.client:: + Client specified as an option to all p4 commands, with + '-c <client>', including the client spec. + +Clone and sync variables +~~~~~~~~~~~~~~~~~~~~~~~~ +git-p4.syncFromOrigin:: + Because importing commits from other Git repositories is much faster + than importing them from p4, a mechanism exists to find p4 changes + first in Git remotes. If branches exist under 'refs/remote/origin/p4', + those will be fetched and used when syncing from p4. This + variable can be set to 'false' to disable this behavior. + +git-p4.branchUser:: + One phase in branch detection involves looking at p4 branches + to find new ones to import. By default, all branches are + inspected. This option limits the search to just those owned + by the single user named in the variable. + +git-p4.branchList:: + List of branches to be imported when branch detection is + enabled. Each entry should be a pair of branch names separated + by a colon (:). This example declares that both branchA and + branchB were created from main: ++ +------------- +git config git-p4.branchList main:branchA +git config --add git-p4.branchList main:branchB +------------- + +git-p4.ignoredP4Labels:: + List of p4 labels to ignore. This is built automatically as + unimportable labels are discovered. + +git-p4.importLabels:: + Import p4 labels into git, as per --import-labels. + +git-p4.labelImportRegexp:: + Only p4 labels matching this regular expression will be imported. The + default value is '[a-zA-Z0-9_\-.]+$'. + +git-p4.useClientSpec:: + Specify that the p4 client spec should be used to identify p4 + depot paths of interest. This is equivalent to specifying the + option '--use-client-spec'. See the "CLIENT SPEC" section above. + This variable is a boolean, not the name of a p4 client. + +Submit variables +~~~~~~~~~~~~~~~~ +git-p4.detectRenames:: + Detect renames. See linkgit:git-diff[1]. This can be true, + false, or a score as expected by 'git diff -M'. + +git-p4.detectCopies:: + Detect copies. See linkgit:git-diff[1]. This can be true, + false, or a score as expected by 'git diff -C'. + +git-p4.detectCopiesHarder:: + Detect copies harder. See linkgit:git-diff[1]. A boolean. + +git-p4.preserveUser:: + On submit, re-author changes to reflect the Git author, + regardless of who invokes 'git p4 submit'. + +git-p4.allowMissingP4Users:: + When 'preserveUser' is true, 'git p4' normally dies if it + cannot find an author in the p4 user map. This setting + submits the change regardless. + +git-p4.skipSubmitEdit:: + The submit process invokes the editor before each p4 change + is submitted. If this setting is true, though, the editing + step is skipped. + +git-p4.skipSubmitEditCheck:: + After editing the p4 change message, 'git p4' makes sure that + the description really was changed by looking at the file + modification time. This option disables that test. + +git-p4.allowSubmit:: + By default, any branch can be used as the source for a 'git p4 + submit' operation. This configuration variable, if set, permits only + the named branches to be used as submit sources. Branch names + must be the short names (no "refs/heads/"), and should be + separated by commas (","), with no spaces. + +git-p4.skipUserNameCheck:: + If the user running 'git p4 submit' does not exist in the p4 + user map, 'git p4' exits. This option can be used to force + submission regardless. + +git-p4.attemptRCSCleanup:: + If enabled, 'git p4 submit' will attempt to cleanup RCS keywords + ($Header$, etc). These would otherwise cause merge conflicts and prevent + the submit going ahead. This option should be considered experimental at + present. + +git-p4.exportLabels:: + Export Git tags to p4 labels, as per --export-labels. + +git-p4.labelExportRegexp:: + Only p4 labels matching this regular expression will be exported. The + default value is '[a-zA-Z0-9_\-.]+$'. + +git-p4.conflict:: + Specify submit behavior when a conflict with p4 is found, as per + --conflict. The default behavior is 'ask'. + +IMPLEMENTATION DETAILS +---------------------- +* Changesets from p4 are imported using Git fast-import. +* Cloning or syncing does not require a p4 client; file contents are + collected using 'p4 print'. +* Submitting requires a p4 client, which is not in the same location + as the Git repository. Patches are applied, one at a time, to + this p4 client and submitted from there. +* Each commit imported by 'git p4' has a line at the end of the log + message indicating the p4 depot location and change number. This + line is used by later 'git p4 sync' operations to know which p4 + changes are new. diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt index 20c8551d6..cdab9ed50 100644 --- a/Documentation/git-pack-objects.txt +++ b/Documentation/git-pack-objects.txt @@ -35,7 +35,7 @@ A pack index file (.idx) is generated for fast, random access to the objects in the pack. Placing both the index file (.idx) and the packed archive (.pack) in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES) -enables git to read from the pack archive. +enables Git to read from the pack archive. The 'git unpack-objects' command can read the packed archive and expand the objects contained in the pack into "one-file @@ -50,9 +50,8 @@ base-name:: Write into a pair of files (.pack and .idx), using <base-name> to determine the name of the created file. When this option is used, the two files are written in - <base-name>-<SHA1>.{pack,idx} files. <SHA1> is a hash - of the sorted object names to make the resulting filename - based on the pack content, and written to the standard + <base-name>-<SHA-1>.{pack,idx} files. <SHA-1> is a hash + based on the pack content and is written to the standard output of the command. --stdout:: @@ -80,7 +79,7 @@ base-name:: --include-tag:: Include unasked-for annotated tags if the object they reference was included in the resulting packfile. This - can be useful to send new tags to native git clients. + can be useful to send new tags to native Git clients. --window=<n>:: --depth=<n>:: @@ -185,14 +184,14 @@ base-name:: option only makes sense in conjunction with --stdout. + Note: A thin pack violates the packed archive format by omitting -required objects and is thus unusable by git without making it +required objects and is thus unusable by Git without making it self-contained. Use `git index-pack --fix-thin` (see linkgit:git-index-pack[1]) to restore the self-contained property. --delta-base-offset:: A packed archive can express the base object of a delta as either a 20-byte object name or as an offset in the - stream, but ancient versions of git don't understand the + stream, but ancient versions of Git don't understand the latter. By default, 'git pack-objects' only uses the former format for better compatibility. This option allows the command to use the latter format for @@ -202,7 +201,7 @@ self-contained. Use `git index-pack --fix-thin` + Note: Porcelain commands such as `git gc` (see linkgit:git-gc[1]), `git repack` (see linkgit:git-repack[1]) pass this option by default -in modern git when they put objects in your repository into pack files. +in modern Git when they put objects in your repository into pack files. So does `git bundle` (see linkgit:git-bundle[1]) when it creates a bundle. --threads=<n>:: @@ -212,7 +211,7 @@ So does `git bundle` (see linkgit:git-bundle[1]) when it creates a bundle. This is meant to reduce packing time on multiprocessor machines. The required amount of memory for the delta search window is however multiplied by the number of threads. - Specifying 0 will cause git to auto-detect the number of CPU's + Specifying 0 will cause Git to auto-detect the number of CPU's and set the number of threads accordingly. --index-version=<version>[,<offset>]:: diff --git a/Documentation/git-pack-refs.txt b/Documentation/git-pack-refs.txt index a3c6677bf..154081f2d 100644 --- a/Documentation/git-pack-refs.txt +++ b/Documentation/git-pack-refs.txt @@ -14,7 +14,8 @@ DESCRIPTION ----------- Traditionally, tips of branches and tags (collectively known as -'refs') were stored one file per ref under `$GIT_DIR/refs` +'refs') were stored one file per ref in a (sub)directory +under `$GIT_DIR/refs` directory. While many branch tips tend to be updated often, most tags and some branch tips are never updated. When a repository has hundreds or thousands of tags, this @@ -22,17 +23,18 @@ one-file-per-ref format both wastes storage and hurts performance. This command is used to solve the storage and performance -problem by stashing the refs in a single file, +problem by storing the refs in a single file, `$GIT_DIR/packed-refs`. When a ref is missing from the -traditional `$GIT_DIR/refs` hierarchy, it is looked up in this +traditional `$GIT_DIR/refs` directory hierarchy, it is looked +up in this file and used if found. Subsequent updates to branches always create new files under -`$GIT_DIR/refs` hierarchy. +`$GIT_DIR/refs` directory hierarchy. A recommended practice to deal with a repository with too many -refs is to pack its refs with `--all --prune` once, and -occasionally run `git pack-refs \--prune`. Tags are by +refs is to pack its refs with `--all` once, and +occasionally run `git pack-refs`. Tags are by definition stationary and are not expected to change. Branch heads will be packed with the initial `pack-refs --all`, but only the currently active branch heads will become unpacked, @@ -57,6 +59,15 @@ a repository with many branches of historical interests. The command usually removes loose refs under `$GIT_DIR/refs` hierarchy after packing them. This option tells it not to. + +BUGS +---- + +Older documentation written before the packed-refs mechanism was +introduced may still say things like ".git/refs/heads/<branch> file +exists" when it means "branch <branch> exists". + + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt index 90268f02e..312c3b1fe 100644 --- a/Documentation/git-patch-id.txt +++ b/Documentation/git-patch-id.txt @@ -12,7 +12,7 @@ SYNOPSIS DESCRIPTION ----------- -A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with +A "patch ID" is nothing but a SHA-1 of the diff associated with a patch, with whitespace and line numbers ignored. As such, it's "reasonably stable", but at the same time also reasonably unique, i.e., two patches that have the same "patch ID" are almost guaranteed to be the same thing. diff --git a/Documentation/git-peek-remote.txt b/Documentation/git-peek-remote.txt deleted file mode 100644 index 87ea3fb05..000000000 --- a/Documentation/git-peek-remote.txt +++ /dev/null @@ -1,43 +0,0 @@ -git-peek-remote(1) -================== - -NAME ----- -git-peek-remote - List the references in a remote repository - - -SYNOPSIS --------- -[verse] -'git peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory> - -DESCRIPTION ------------ -This command is deprecated; use 'git ls-remote' instead. - -OPTIONS -------- ---upload-pack=<git-upload-pack>:: - Use this to specify the path to 'git-upload-pack' on the - remote side, if it is not found on your $PATH. Some - installations of sshd ignores the user's environment - setup scripts for login shells (e.g. .bash_profile) and - your privately installed git may not be found on the system - default $PATH. Another workaround suggested is to set - up your $PATH in ".bashrc", but this flag is for people - who do not want to pay the overhead for non-interactive - shells, but prefer having a lean .bashrc file (they set most of - the things up in .bash_profile). - -<host>:: - A remote host that houses the repository. When this - part is specified, 'git-upload-pack' is invoked via - ssh. - -<directory>:: - The repository to sync from. - - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-prune-packed.txt b/Documentation/git-prune-packed.txt index 80dc022ed..6738055bd 100644 --- a/Documentation/git-prune-packed.txt +++ b/Documentation/git-prune-packed.txt @@ -14,7 +14,7 @@ SYNOPSIS DESCRIPTION ----------- -This program searches the `$GIT_OBJECT_DIR` for all objects that currently +This program searches the `$GIT_OBJECT_DIRECTORY` for all objects that currently exist in a pack file as well as the independent object directories. All such extra objects are removed. diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt index 80d01b057..058ac0dc8 100644 --- a/Documentation/git-prune.txt +++ b/Documentation/git-prune.txt @@ -24,6 +24,8 @@ objects unreachable from any of these head objects from the object database. In addition, it prunes the unpacked objects that are also found in packs by running 'git prune-packed'. +It also removes entries from .git/shallow that are not reachable by +any ref. Note that unreachable, packed objects will remain. If this is not desired, see linkgit:git-repack[1]. @@ -59,7 +61,7 @@ borrows from your repository via its `.git/objects/info/alternates`: ------------ -$ git prune $(cd ../another && $(git rev-parse --all)) +$ git prune $(cd ../another && git rev-parse --all) ------------ Notes diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index e1da46876..200eb2226 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -3,7 +3,7 @@ git-pull(1) NAME ---- -git-pull - Fetch from and merge with another repository or a local branch +git-pull - Fetch from and integrate with another repository or a local branch SYNOPSIS @@ -42,6 +42,8 @@ Assume the following history exists and the current branch is A---B---C master on origin / D---E---F---G master + ^ + origin/master in your repository ------------ Then "`git pull`" will fetch and replay the changes from the remote @@ -51,7 +53,7 @@ result in a new commit along with the names of the two parent commits and a log message from the user describing the changes. ------------ - A---B---C remotes/origin/master + A---B---C origin/master / \ D---E---F---G---H master ------------ @@ -59,8 +61,8 @@ and a log message from the user describing the changes. See linkgit:git-merge[1] for details, including how conflicts are presented and handled. -In git 1.7.0 or later, to cancel a conflicting merge, use -`git reset --merge`. *Warning*: In older versions of git, running 'git pull' +In Git 1.7.0 or later, to cancel a conflicting merge, use +`git reset --merge`. *Warning*: In older versions of Git, running 'git pull' with uncommitted changes is discouraged: while possible, it leaves you in a state that may be hard to back out of in the case of a conflict. @@ -89,7 +91,7 @@ must be given before the options meant for 'git fetch'. This option controls if new commits of all populated submodules should be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]). That might be necessary to get the data needed for merging submodule - commits, a feature git learned in 1.7.3. Notice that the result of a + commits, a feature Git learned in 1.7.3. Notice that the result of a merge will not be checked out in the submodule, "git submodule update" has to be called afterwards to bring the work tree up to date with the merge result. @@ -97,20 +99,27 @@ must be given before the options meant for 'git fetch'. Options related to merging ~~~~~~~~~~~~~~~~~~~~~~~~~~ -include::merge-options.txt[] - :git-pull: 1 ---rebase:: - Rebase the current branch on top of the upstream branch after - fetching. If there is a remote-tracking branch corresponding to - the upstream branch and the upstream branch was rebased since last - fetched, the rebase uses that information to avoid rebasing - non-local changes. +include::merge-options.txt[] + +-r:: +--rebase[=false|true|preserve]:: + When true, rebase the current branch on top of the upstream + branch after fetching. If there is a remote-tracking branch + corresponding to the upstream branch and the upstream branch + was rebased since last fetched, the rebase uses that information + to avoid rebasing non-local changes. ++ +When preserve, also rebase the current branch on top of the upstream +branch, but pass `--preserve-merges` along to `git rebase` so that +locally created merge commits will not be flattened. ++ +When false, merge the current branch into the upstream branch. + -See `branch.<name>.rebase` and `branch.autosetuprebase` in +See `pull.rebase`, `branch.<name>.rebase` and `branch.autosetuprebase` in linkgit:git-config[1] if you want to make `git pull` always use -`{litdd}rebase` instead of merging. +`--rebase` instead of merging. + [NOTE] This is a potentially _dangerous_ mode of operation. @@ -217,7 +226,7 @@ $ git merge origin/next ------------------------------------------------ -If you tried a pull which resulted in a complex conflicts and +If you tried a pull which resulted in complex conflicts and would want to start over, you can recover with 'git reset'. @@ -227,7 +236,7 @@ Using --recurse-submodules can only fetch new commits in already checked out submodules right now. When e.g. upstream added a new submodule in the just fetched commits of the superproject the submodule itself can not be fetched, making it impossible to check out that submodule later without -having to do a fetch again. This is expected to be fixed in a future git +having to do a fetch again. This is expected to be fixed in a future Git version. SEE ALSO diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 88acfcd4c..2b7f4f939 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -9,9 +9,10 @@ git-push - Update remote refs along with associated objects SYNOPSIS -------- [verse] -'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>] - [--repo=<repository>] [-f | --force] [-v | --verbose] [-u | --set-upstream] - [<repository> [<refspec>...]] +'git push' [--all | --mirror | --tags] [--follow-tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>] + [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream] + [--force-with-lease[=<refname>[:<expect>]]] + [--no-verify] [<repository> [<refspec>...]] DESCRIPTION ----------- @@ -23,6 +24,17 @@ You can make interesting things happen to a repository every time you push into it, by setting up 'hooks' there. See documentation for linkgit:git-receive-pack[1]. +When the command line does not specify where to push with the +`<repository>` argument, `branch.*.remote` configuration for the +current branch is consulted to determine where to push. If the +configuration is missing, it defaults to 'origin'. + +When the command line does not specify what to push with `<refspec>...` +arguments or `--all`, `--mirror`, `--tags` options, the command finds +the default `<refspec>` by consulting `remote.*.push` configuration, +and if it is not found, honors `push.default` configuration to decide +what to push (See gitlink:git-config[1] for the meaning of `push.default`). + OPTIONS[[OPTIONS]] ------------------ @@ -33,11 +45,10 @@ OPTIONS[[OPTIONS]] of a remote (see the section <<REMOTES,REMOTES>> below). <refspec>...:: + Specify what destination ref to update with what source object. The format of a <refspec> parameter is an optional plus - `{plus}`, followed by the source ref <src>, followed + `+`, followed by the source object <src>, followed by a colon `:`, followed by the destination ref <dst>. - It is used to specify with what <src> object the <dst> ref - in the remote repository is to be updated. + The <src> is often the name of the branch you would want to push, but it can be any arbitrary "SHA-1 expression", such as `master~4` or @@ -45,14 +56,20 @@ it can be any arbitrary "SHA-1 expression", such as `master~4` or + The <dst> tells which ref on the remote side is updated with this push. Arbitrary expressions cannot be used here, an actual ref must -be named. If `:`<dst> is omitted, the same ref as <src> will be -updated. +be named. +If `git push [<repository>]` without any `<refspec>` argument is set to +update some ref at the destination with `<src>` with +`remote.<repository>.push` configuration variable, `:<dst>` part can +be omitted---such a push will update a ref that `<src>` normally updates +without any `<refspec>` on the command line. Otherwise, missing +`:<dst>` means to update the same ref as the `<src>`. + The object referenced by <src> is used to update the <dst> reference -on the remote side, but by default this is only allowed if the -update can fast-forward <dst>. By having the optional leading `{plus}`, -you can tell git to update the <dst> ref even when the update is not a -fast-forward. This does *not* attempt to merge <src> into <dst>. See +on the remote side. By default this is only allowed if <dst> is not +a tag (annotated or lightweight), and then only if it can fast-forward +<dst>. By having the optional leading `+`, you can tell Git to update +the <dst> ref even if it is not allowed by default (e.g., it is not a +fast-forward.) This does *not* attempt to merge <src> into <dst>. See EXAMPLES below for details. + `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`. @@ -60,17 +77,23 @@ EXAMPLES below for details. Pushing an empty <src> allows you to delete the <dst> ref from the remote repository. + -The special refspec `:` (or `{plus}:` to allow non-fast-forward updates) -directs git to push "matching" branches: for every branch that exists on +The special refspec `:` (or `+:` to allow non-fast-forward updates) +directs Git to push "matching" branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name -already exists on the remote side. This is the default operation mode -if no explicit refspec is found (that is neither on the command line -nor in any Push line of the corresponding remotes file---see below). +already exists on the remote side. --all:: Instead of naming each ref to push, specifies that all refs under `refs/heads/` be pushed. +--prune:: + Remove remote branches that don't have a local counterpart. For example + a remote branch `tmp` will be removed if a local branch with the same + name doesn't exist any more. This also respects refspecs, e.g. + `git push --prune remote refs/heads/*:refs/tmp/*` would + make sure that remote `refs/tmp/foo` will be removed if `refs/heads/foo` + doesn't exist. + --mirror:: Instead of naming each ref to push, specifies that all refs under `refs/` (which includes but is not @@ -100,6 +123,12 @@ nor in any Push line of the corresponding remotes file---see below). addition to refspecs explicitly listed on the command line. +--follow-tags:: + Push all the refs that would be pushed without this option, + and also push annotated tags in `refs/tags` that are missing + from the remote but are pointing at commit-ish that are + reachable from the refs being pushed. + --receive-pack=<git-receive-pack>:: --exec=<git-receive-pack>:: Path to the 'git-receive-pack' program on the remote @@ -107,12 +136,75 @@ nor in any Push line of the corresponding remotes file---see below). repository over ssh, and you do not have the program in a directory on the default $PATH. +--[no-]force-with-lease:: +--force-with-lease=<refname>:: +--force-with-lease=<refname>:<expect>:: + Usually, "git push" refuses to update a remote ref that is + not an ancestor of the local ref used to overwrite it. ++ +This option bypasses the check, but instead requires that the +current value of the ref to be the expected value. "git push" +fails otherwise. ++ +Imagine that you have to rebase what you have already published. +You will have to bypass the "must fast-forward" rule in order to +replace the history you originally published with the rebased history. +If somebody else built on top of your original history while you are +rebasing, the tip of the branch at the remote may advance with her +commit, and blindly pushing with `--force` will lose her work. ++ +This option allows you to say that you expect the history you are +updating is what you rebased and want to replace. If the remote ref +still points at the commit you specified, you can be sure that no +other people did anything to the ref (it is like taking a "lease" on +the ref without explicitly locking it, and you update the ref while +making sure that your earlier "lease" is still valid). ++ +`--force-with-lease` alone, without specifying the details, will protect +all remote refs that are going to be updated by requiring their +current value to be the same as the remote-tracking branch we have +for them, unless specified with a `--force-with-lease=<refname>:<expect>` +option that explicitly states what the expected value is. ++ +`--force-with-lease=<refname>`, without specifying the expected value, will +protect the named ref (alone), if it is going to be updated, by +requiring its current value to be the same as the remote-tracking +branch we have for it. ++ +`--force-with-lease=<refname>:<expect>` will protect the named ref (alone), +if it is going to be updated, by requiring its current value to be +the same as the specified value <expect> (which is allowed to be +different from the remote-tracking branch we have for the refname, +or we do not even have to have such a remote-tracking branch when +this form is used). ++ +Note that all forms other than `--force-with-lease=<refname>:<expect>` +that specifies the expected current value of the ref explicitly are +still experimental and their semantics may change as we gain experience +with this feature. ++ +"--no-force-with-lease" will cancel all the previous --force-with-lease on the +command line. + -f:: --force:: Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. - This flag disables the check. This can cause the - remote repository to lose commits; use it with care. + Also, when `--force-with-lease` option is used, the command refuses + to update a remote ref whose current value does not match + what is expected. ++ +This flag disables these checks, and can cause the remote repository +to lose commits; use it with care. ++ +Note that `--force` applies to all the refs that are pushed, hence +using it with `push.default` set to `matching` or with multiple push +destinations configured with `remote.*.push` may overwrite refs +other than the current branch (including local refs that are +strictly behind their remote counterpart). To force a push to only +one branch, use a `+` in front of the refspec to push (e.g `git push +origin +master` to force a push to the `master` branch). See the +`<refspec>...` section above for details. --repo=<repository>:: This option is only relevant if no <repository> argument is @@ -139,8 +231,7 @@ useful if you write an alias or script around 'git push'. linkgit:git-pull[1] and other commands. For more information, see 'branch.<name>.merge' in linkgit:git-config[1]. ---thin:: ---no-thin:: +--[no-]thin:: These options are passed to linkgit:git-send-pack[1]. A thin transfer significantly reduces the amount of sent data when the sender and receiver share many of the same objects in common. The default is @@ -162,13 +253,30 @@ useful if you write an alias or script around 'git push'. is specified. This flag forces progress status even if the standard error stream is not directed to a terminal. +--recurse-submodules=check|on-demand:: + Make sure all submodule commits used by the revisions to be + pushed are available on a remote-tracking branch. If 'check' is + used Git will verify that all submodule commits that changed in + the revisions to be pushed are available on at least one remote + of the submodule. If any commits are missing the push will be + aborted and exit with non-zero status. If 'on-demand' is used + all submodules that changed in the revisions to be pushed will + be pushed. If on-demand was not able to push all necessary + revisions it will also be aborted and exit with non-zero status. + +--[no-]verify:: + Toggle the pre-push hook (see linkgit:githooks[5]). The + default is \--verify, giving the hook a chance to prevent the + push. With \--no-verify, the hook is bypassed completely. + + include::urls-remotes.txt[] OUTPUT ------ The output of "git push" depends on the transport method used; this -section describes the output when pushing over the git protocol (either +section describes the output when pushing over the Git protocol (either locally or via ssh). The status of the push is output in tabular form, with each line @@ -190,7 +298,7 @@ option is used. flag:: A single character indicating the status of the ref: (space);; for a successfully pushed fast-forward; -`{plus}`;; for a successful forced update; +`+`;; for a successful forced update; `-`;; for a successfully deleted ref; `*`;; for a successfully pushed new ref; `!`;; for a ref that was rejected or failed to push; and @@ -200,7 +308,7 @@ summary:: For a successfully pushed ref, the summary shows the old and new values of the ref in a form suitable for using as an argument to `git log` (this is `<old>..<new>` in most cases, and - `<old>\...<new>` for forced non-fast-forward updates). + `<old>...<new>` for forced non-fast-forward updates). + For a failed update, more details are given: + @@ -263,7 +371,8 @@ leading to commit A. The history looks like this: ---------------- Further suppose that the other person already pushed changes leading to A -back to the original repository you two obtained the original commit X. +back to the original repository from which you two obtained the original +commit X. The push done by the other person updated the branch that used to point at commit X to point at commit A. It is a fast-forward. @@ -327,62 +436,75 @@ a case where you do mean to lose history. Examples -------- -git push:: +`git push`:: Works like `git push <remote>`, where <remote> is the current branch's remote (or `origin`, if no remote is configured for the current branch). -git push origin:: +`git push origin`:: Without additional configuration, works like `git push origin :`. + The default behavior of this command when no <refspec> is given can be -configured by setting the `push` option of the remote. +configured by setting the `push` option of the remote, or the `push.default` +configuration variable. + For example, to default to pushing only the current branch to `origin` use `git config remote.origin.push HEAD`. Any valid <refspec> (like the ones in the examples below) can be configured as the default for `git push origin`. -git push origin ::: +`git push origin :`:: Push "matching" branches to `origin`. See <refspec> in the <<OPTIONS,OPTIONS>> section above for a description of "matching" branches. -git push origin master:: +`git push origin master`:: Find a ref that matches `master` in the source repository (most likely, it would find `refs/heads/master`), and update the same ref (e.g. `refs/heads/master`) in `origin` repository with it. If `master` did not exist remotely, it would be created. -git push origin HEAD:: +`git push origin HEAD`:: A handy way to push the current branch to the same name on the remote. -git push origin master:satellite/master dev:satellite/dev:: +`git push mothership master:satellite/master dev:satellite/dev`:: Use the source ref that matches `master` (e.g. `refs/heads/master`) to update the ref that matches `satellite/master` (most probably - `refs/remotes/satellite/master`) in the `origin` repository, then + `refs/remotes/satellite/master`) in the `mothership` repository; do the same for `dev` and `satellite/dev`. ++ +This is to emulate `git fetch` run on the `mothership` using `git +push` that is run in the opposite direction in order to integrate +the work done on `satellite`, and is often necessary when you can +only make connection in one way (i.e. satellite can ssh into +mothership but mothership cannot initiate connection to satellite +because the latter is behind a firewall or does not run sshd). ++ +After running this `git push` on the `satellite` machine, you would +ssh into the `mothership` and run `git merge` there to complete the +emulation of `git pull` that were run on `mothership` to pull changes +made on `satellite`. -git push origin HEAD:master:: +`git push origin HEAD:master`:: Push the current branch to the remote ref matching `master` in the `origin` repository. This form is convenient to push the current branch without thinking about its local name. -git push origin master:refs/heads/experimental:: +`git push origin master:refs/heads/experimental`:: Create the branch `experimental` in the `origin` repository by copying the current `master` branch. This form is only needed to create a new branch or tag in the remote repository when the local name and the remote name are different; otherwise, the ref name on its own will work. -git push origin :experimental:: +`git push origin :experimental`:: Find a ref that matches `experimental` in the `origin` repository (e.g. `refs/heads/experimental`), and delete it. -git push origin {plus}dev:master:: +`git push origin +dev:master`:: Update the origin repository's master branch with the dev branch, allowing non-fast-forward updates. *This can leave unreferenced commits dangling in the origin repository.* Consider the diff --git a/Documentation/git-quiltimport.txt b/Documentation/git-quiltimport.txt index 7f112f3dc..a35619658 100644 --- a/Documentation/git-quiltimport.txt +++ b/Documentation/git-quiltimport.txt @@ -14,7 +14,7 @@ SYNOPSIS DESCRIPTION ----------- -Applies a quilt patchset onto the current git branch, preserving +Applies a quilt patchset onto the current Git branch, preserving the patch boundaries, patch order, and patch descriptions present in the quilt patchset. @@ -25,7 +25,7 @@ the patch description is displayed and the user is asked to interactively enter the author of the patch. If a subject is not found in the patch description the patch name is -preserved as the 1 line subject in the git description. +preserved as the 1 line subject in the Git description. OPTIONS ------- diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt index a43e87448..c4bde6509 100644 --- a/Documentation/git-read-tree.txt +++ b/Documentation/git-read-tree.txt @@ -341,7 +341,7 @@ since you pulled from him: ---------------- $ git fetch git://.... linus -$ LT=`cat .git/FETCH_HEAD` +$ LT=`git rev-parse FETCH_HEAD` ---------------- Your work tree is still based on your HEAD ($JC), but you have diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 504945c69..2889be6bd 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -8,11 +8,11 @@ git-rebase - Forward-port local commits to the updated upstream head SYNOPSIS -------- [verse] -'git rebase' [-i | --interactive] [options] [--onto <newbase>] +'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] [<upstream>] [<branch>] -'git rebase' [-i | --interactive] [options] --onto <newbase> +'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] --root [<branch>] -'git rebase' --continue | --skip | --abort +'git rebase' --continue | --skip | --abort | --edit-todo DESCRIPTION ----------- @@ -179,7 +179,7 @@ parameter can be any valid commit-ish. In case of conflict, 'git rebase' will stop at the first problematic commit and leave conflict markers in the tree. You can use 'git diff' to locate the markers (<<<<<<) and make edits to resolve the conflict. For each -file you edit, you need to tell git that the conflict has been resolved, +file you edit, you need to tell Git that the conflict has been resolved, typically this would be done with @@ -208,9 +208,12 @@ rebase.stat:: rebase.autosquash:: If set to true enable '--autosquash' option by default. +rebase.autostash:: + If set to true enable '--autostash' option by default. + OPTIONS ------- -<newbase>:: +--onto <newbase>:: Starting point at which to create the new commits. If the --onto option is not specified, the starting point is <upstream>. May be any valid commit, and not just an @@ -238,9 +241,16 @@ leave out at most one of A and B, in which case it defaults to HEAD. will be reset to where it was when the rebase operation was started. +--keep-empty:: + Keep the commits that do not change anything from its + parents in the result. + --skip:: Restart the rebasing process by skipping the current patch. +--edit-todo:: + Edit the todo list during an interactive rebase. + -m:: --merge:: Use merging strategies to rebase. When the recursive (default) merge @@ -267,9 +277,9 @@ which makes little sense. -X <strategy-option>:: --strategy-option=<strategy-option>:: Pass the <strategy-option> through to the merge strategy. - This implies `\--merge` and, if no strategy has been + This implies `--merge` and, if no strategy has been specified, `-s recursive`. Note the reversal of 'ours' and - 'theirs' as noted in above for the `-m` option. + 'theirs' as noted above for the `-m` option. -q:: --quiet:: @@ -312,7 +322,17 @@ You may find this (or --no-ff with an interactive rebase) helpful after reverting a topic branch merge, as this option recreates the topic branch with fresh commits so it can be remerged successfully without needing to "revert the reversion" (see the -link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details). +link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details). + +--fork-point:: +--no-fork-point:: + Use 'git merge-base --fork-point' to find a better common ancestor + between `upstream` and `branch` when calculating which commits have + have been introduced by `branch` (see linkgit:git-merge-base[1]). ++ +If no non-option arguments are given on the command line, then the default is +`--fork-point @{u}` otherwise the `upstream` argument is interpreted literally +unless the `--fork-point` option is specified. --ignore-whitespace:: --whitespace=<option>:: @@ -340,14 +360,36 @@ This uses the `--interactive` machinery internally, but combining it with the `--interactive` option explicitly is generally not a good idea unless you know what you are doing (see BUGS below). +-x <cmd>:: +--exec <cmd>:: + Append "exec <cmd>" after each line creating a commit in the + final history. <cmd> will be interpreted as one or more shell + commands. ++ +This option can only be used with the `--interactive` option +(see INTERACTIVE MODE below). ++ +You may execute several commands by either using one instance of `--exec` +with several commands: ++ + git rebase -i --exec "cmd1 && cmd2 && ..." ++ +or by giving more than one `--exec`: ++ + git rebase -i --exec "cmd1" --exec "cmd2" --exec ... ++ +If `--autosquash` is used, "exec" lines will not be appended for +the intermediate commits, and will only appear at the end of each +squash/fixup series. --root:: Rebase all commits reachable from <branch>, instead of limiting them with an <upstream>. This allows you to rebase - the root commit(s) on a branch. Must be used with --onto, and + the root commit(s) on a branch. When used with --onto, it will skip changes already contained in <newbase> (instead of - <upstream>). When used together with --preserve-merges, 'all' - root commits will be rewritten to have <newbase> as parent + <upstream>) whereas without --onto it will operate on every change. + When used together with both --onto and --preserve-merges, + 'all' root commits will be rewritten to have <newbase> as parent instead. --autosquash:: @@ -357,7 +399,9 @@ idea unless you know what you are doing (see BUGS below). the same ..., automatically modify the todo list of rebase -i so that the commit marked for squashing comes right after the commit to be modified, and change the action of the moved - commit from `pick` to `squash` (or `fixup`). + commit from `pick` to `squash` (or `fixup`). Ignores subsequent + "fixup! " or "squash! " after the first, in case you referred to an + earlier fixup/squash with `git commit --fixup/--squash`. + This option is only valid when the '--interactive' option is used. + @@ -365,6 +409,13 @@ If the '--autosquash' option is enabled by default using the configuration variable `rebase.autosquash`, this option can be used to override and disable this setting. +--[no-]autostash:: + Automatically create a temporary stash before the operation + begins, and apply it after the operation ends. This means + that you can run rebase on a dirty worktree. However, use + with care: the final stash application after a successful + rebase might result in non-trivial conflicts. + --no-ff:: With --interactive, cherry-pick all rebased commits instead of fast-forwarding over the unchanged ones. This ensures that the @@ -375,7 +426,7 @@ Without --interactive, this is a synonym for --force-rebase. You may find this helpful after reverting a topic branch merge, as this option recreates the topic branch with fresh commits so it can be remerged successfully without needing to "revert the reversion" (see the -link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details). +link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details). include::merge-strategies.txt[] @@ -409,10 +460,13 @@ The interactive mode is meant for this type of workflow: where point 2. consists of several instances of -a. regular use +a) regular use + 1. finish something worthy of a commit 2. commit -b. independent fixup + +b) independent fixup + 1. realize that something does not work 2. fix that 3. commit it @@ -514,6 +568,24 @@ in `$SHELL`, or the default shell if `$SHELL` is not set), so you can use shell features (like "cd", ">", ";" ...). The command is run from the root of the working tree. +---------------------------------- +$ git rebase -i --exec "make test" +---------------------------------- + +This command lets you check that intermediate commits are compilable. +The todo list becomes like that: + +-------------------- +pick 5928aea one +exec make test +pick 04d0fda two +exec make test +pick ba46169 three +exec make test +pick f4593f9 four +exec make test +-------------------- + SPLITTING COMMITS ----------------- @@ -608,8 +680,8 @@ Easy case: The changes are literally the same.:: Hard case: The changes are not the same.:: This happens if the 'subsystem' rebase had conflicts, or used - `\--interactive` to omit, edit, squash, or fixup commits; or - if the upstream used one of `commit \--amend`, `reset`, or + `--interactive` to omit, edit, squash, or fixup commits; or + if the upstream used one of `commit --amend`, `reset`, or `filter-branch`. @@ -645,7 +717,7 @@ correspond to the ones before the rebase. NOTE: While an "easy case recovery" sometimes appears to be successful even in the hard case, it may have unintended consequences. For example, a commit that was removed via `git rebase - \--interactive` will be **resurrected**! + --interactive` will be **resurrected**! The idea is to manually tell 'git rebase' "where the old 'subsystem' ended and your 'topic' began", that is, what the old merge-base @@ -653,7 +725,7 @@ between them was. You will have to find a way to name the last commit of the old 'subsystem', for example: * With the 'subsystem' reflog: after 'git fetch', the old tip of - 'subsystem' is at `subsystem@\{1}`. Subsequent fetches will + 'subsystem' is at `subsystem@{1}`. Subsequent fetches will increase the number. (See linkgit:git-reflog[1].) * Relative to the tip of 'topic': knowing that your 'topic' has three diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt index 459c08598..b1f7dc643 100644 --- a/Documentation/git-receive-pack.txt +++ b/Documentation/git-receive-pack.txt @@ -150,7 +150,7 @@ if the repository is packed and is served via a dumb transport. SEE ALSO -------- -linkgit:git-send-pack[1] +linkgit:git-send-pack[1], linkgit:gitnamespaces[7] GIT --- diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt index 976dc1493..70791b9fd 100644 --- a/Documentation/git-reflog.txt +++ b/Documentation/git-reflog.txt @@ -38,14 +38,14 @@ The reflog will cover all recent actions (HEAD reflog records branch switching as well). It is an alias for `git log -g --abbrev-commit --pretty=oneline`; see linkgit:git-log[1]. -The reflog is useful in various git commands, to specify the old value -of a reference. For example, `HEAD@\{2\}` means "where HEAD used to be -two moves ago", `master@\{one.week.ago\}` means "where master used to +The reflog is useful in various Git commands, to specify the old value +of a reference. For example, `HEAD@{2}` means "where HEAD used to be +two moves ago", `master@{one.week.ago}` means "where master used to point to one week ago", and so on. See linkgit:gitrevisions[7] for more details. To delete single entries from the reflog, use the subcommand "delete" -and specify the _exact_ entry (e.g. "`git reflog delete master@\{2\}`"). +and specify the _exact_ entry (e.g. "`git reflog delete master@{2}`"). OPTIONS @@ -67,14 +67,19 @@ them. --expire=<time>:: Entries older than this time are pruned. Without the option it is taken from configuration `gc.reflogExpire`, - which in turn defaults to 90 days. + which in turn defaults to 90 days. --expire=all prunes + entries regardless of their age; --expire=never turns off + pruning of reachable entries (but see --expire-unreachable). --expire-unreachable=<time>:: Entries older than this time and not reachable from the current tip of the branch are pruned. Without the option it is taken from configuration `gc.reflogExpireUnreachable`, which in turn defaults to - 30 days. + 30 days. --expire-unreachable=all prunes unreachable + entries regardless of their age; --expire-unreachable=never + turns off early pruning of unreachable entries (but see + --expire). --all:: Instead of listing <refs> explicitly, prune all refs. diff --git a/Documentation/git-remote-ext.txt b/Documentation/git-remote-ext.txt index 8a8e1d775..cd0bb77e4 100644 --- a/Documentation/git-remote-ext.txt +++ b/Documentation/git-remote-ext.txt @@ -13,7 +13,7 @@ git remote add <nick> "ext::<command>[ <arguments>...]" DESCRIPTION ----------- This remote helper uses the specified '<command>' to connect -to a remote git server. +to a remote Git server. Data written to stdin of the specified '<command>' is assumed to be sent to a git:// server, git-upload-pack, git-receive-pack @@ -33,12 +33,12 @@ The following sequences have a special meaning: '%s':: Replaced with name (receive-pack, upload-pack, or - upload-archive) of the service git wants to invoke. + upload-archive) of the service Git wants to invoke. '%S':: Replaced with long name (git-receive-pack, git-upload-pack, or git-upload-archive) of the service - git wants to invoke. + Git wants to invoke. '%G' (must be the first characters in an argument):: This argument will not be passed to '<command>'. Instead, it @@ -75,7 +75,7 @@ GIT_EXT_SERVICE_NOPREFIX:: EXAMPLES: --------- -This remote helper is transparently used by git when +This remote helper is transparently used by Git when you use commands such as "git fetch <URL>", "git clone <URL>", , "git push <URL>" or "git remote add <nick> <URL>", where <URL> begins with `ext::`. Examples: @@ -86,7 +86,7 @@ begins with `ext::`. Examples: edit .ssh/config. "ext::socat -t3600 - ABSTRACT-CONNECT:/git-server %G/somerepo":: - Represents repository with path /somerepo accessable over + Represents repository with path /somerepo accessible over git protocol at abstract namespace address /git-server. "ext::git-server-alias foo %G/repo":: @@ -100,14 +100,14 @@ begins with `ext::`. Examples: Represents a repository with path /repo accessed using the helper program "git-server-alias foo". The hostname for the remote server passed in the protocol stream will be "foo" - (this allows multiple virtual git servers to share a + (this allows multiple virtual Git servers to share a link-level address). "ext::git-server-alias foo %G/repo% with% spaces %Vfoo":: Represents a repository with path '/repo with spaces' accessed using the helper program "git-server-alias foo". The hostname for the remote server passed in the protocol stream will be "foo" - (this allows multiple virtual git servers to share a + (this allows multiple virtual Git servers to share a link-level address). "ext::git-ssl foo.example /bar":: @@ -116,11 +116,6 @@ begins with `ext::`. Examples: determined by the helper using environment variables (see above). -Documentation --------------- -Documentation by Ilari Liusvaara, Jonathan Nieder and the git list -<git@vger.kernel.org> - GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt index 4aecd4d18..bcd37668e 100644 --- a/Documentation/git-remote-fd.txt +++ b/Documentation/git-remote-fd.txt @@ -11,14 +11,14 @@ SYNOPSIS DESCRIPTION ----------- -This helper uses specified file descriptors to connect to a remote git server. +This helper uses specified file descriptors to connect to a remote Git server. This is not meant for end users but for programs and scripts calling git fetch, push or archive. If only <infd> is given, it is assumed to be a bidirectional socket connected -to remote git server (git-upload-pack, git-receive-pack or +to remote Git server (git-upload-pack, git-receive-pack or git-upload-achive). If both <infd> and <outfd> are given, they are assumed -to be pipes connected to a remote git server (<infd> being the inbound pipe +to be pipes connected to a remote Git server (<infd> being the inbound pipe and <outfd> being the outbound pipe. It is assumed that any handshaking procedures have already been completed @@ -35,25 +35,21 @@ GIT_TRANSLOOP_DEBUG:: EXAMPLES -------- -git fetch fd::17 master:: +`git fetch fd::17 master`:: Fetch master, using file descriptor #17 to communicate with git-upload-pack. -git fetch fd::17/foo master:: +`git fetch fd::17/foo master`:: Same as above. -git push fd::7,8 master (as URL):: +`git push fd::7,8 master (as URL)`:: Push master, using file descriptor #7 to read data from git-receive-pack and file descriptor #8 to write data to same service. -git push fd::7,8/bar master:: +`git push fd::7,8/bar master`:: Same as above. -Documentation --------------- -Documentation by Ilari Liusvaara and the git list <git@vger.kernel.org> - GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt deleted file mode 100644 index 930b4034a..000000000 --- a/Documentation/git-remote-helpers.txt +++ /dev/null @@ -1,245 +0,0 @@ -git-remote-helpers(1) -===================== - -NAME ----- -git-remote-helpers - Helper programs to interact with remote repositories - -SYNOPSIS --------- -[verse] -'git remote-<transport>' <repository> [<URL>] - -DESCRIPTION ------------ - -Remote helper programs are normally not used directly by end users, -but they are invoked by git when it needs to interact with remote -repositories git does not support natively. A given helper will -implement a subset of the capabilities documented here. When git -needs to interact with a repository using a remote helper, it spawns -the helper as an independent process, sends commands to the helper's -standard input, and expects results from the helper's standard -output. Because a remote helper runs as an independent process from -git, there is no need to re-link git to add a new helper, nor any -need to link the helper with the implementation of git. - -Every helper must support the "capabilities" command, which git will -use to determine what other commands the helper will accept. Other -commands generally concern facilities like discovering and updating -remote refs, transporting objects between the object database and -the remote repository, and updating the local object store. - -Helpers supporting the 'fetch' capability can discover refs from the -remote repository and transfer objects reachable from those refs to -the local object store. Helpers supporting the 'push' capability can -transfer local objects to the remote repository and update remote refs. - -Git comes with a "curl" family of remote helpers, that handle various -transport protocols, such as 'git-remote-http', 'git-remote-https', -'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities -'fetch', 'option', and 'push'. - -INVOCATION ----------- - -Remote helper programs are invoked with one or (optionally) two -arguments. The first argument specifies a remote repository as in git; -it is either the name of a configured remote or a URL. The second -argument specifies a URL; it is usually of the form -'<transport>://<address>', but any arbitrary string is possible. - -When git encounters a URL of the form '<transport>://<address>', where -'<transport>' is a protocol that it cannot handle natively, it -automatically invokes 'git remote-<transport>' with the full URL as -the second argument. If such a URL is encountered directly on the -command line, the first argument is the same as the second, and if it -is encountered in a configured remote, the first argument is the name -of that remote. - -A URL of the form '<transport>::<address>' explicitly instructs git to -invoke 'git remote-<transport>' with '<address>' as the second -argument. If such a URL is encountered directly on the command line, -the first argument is '<address>', and if it is encountered in a -configured remote, the first argument is the name of that remote. - -Additionally, when a configured remote has 'remote.<name>.vcs' set to -'<transport>', git explicitly invokes 'git remote-<transport>' with -'<name>' as the first argument. If set, the second argument is -'remote.<name>.url'; otherwise, the second argument is omitted. - -COMMANDS --------- - -Commands are given by the caller on the helper's standard input, one per line. - -'capabilities':: - Lists the capabilities of the helper, one per line, ending - with a blank line. Each capability may be preceded with '*', - which marks them mandatory for git version using the remote - helper to understand (unknown mandatory capability is fatal - error). - -'list':: - Lists the refs, one per line, in the format "<value> <name> - [<attr> ...]". The value may be a hex sha1 hash, "@<dest>" for - a symref, or "?" to indicate that the helper could not get the - value of the ref. A space-separated list of attributes follows - the name; unrecognized attributes are ignored. The list ends - with a blank line. -+ -If 'push' is supported this may be called as 'list for-push' -to obtain the current refs prior to sending one or more 'push' -commands to the helper. - -'option' <name> <value>:: - Sets the transport helper option <name> to <value>. Outputs a - single line containing one of 'ok' (option successfully set), - 'unsupported' (option not recognized) or 'error <msg>' - (option <name> is supported but <value> is not valid - for it). Options should be set before other commands, - and may influence the behavior of those commands. -+ -Supported if the helper has the "option" capability. - -'fetch' <sha1> <name>:: - Fetches the given object, writing the necessary objects - to the database. Fetch commands are sent in a batch, one - per line, terminated with a blank line. - Outputs a single blank line when all fetch commands in the - same batch are complete. Only objects which were reported - in the ref list with a sha1 may be fetched this way. -+ -Optionally may output a 'lock <file>' line indicating a file under -GIT_DIR/objects/pack which is keeping a pack until refs can be -suitably updated. -+ -Supported if the helper has the "fetch" capability. - -'push' +<src>:<dst>:: - Pushes the given local <src> commit or branch to the - remote branch described by <dst>. A batch sequence of - one or more push commands is terminated with a blank line. -+ -Zero or more protocol options may be entered after the last 'push' -command, before the batch's terminating blank line. -+ -When the push is complete, outputs one or more 'ok <dst>' or -'error <dst> <why>?' lines to indicate success or failure of -each pushed ref. The status report output is terminated by -a blank line. The option field <why> may be quoted in a C -style string if it contains an LF. -+ -Supported if the helper has the "push" capability. - -'import' <name>:: - Produces a fast-import stream which imports the current value - of the named ref. It may additionally import other refs as - needed to construct the history efficiently. The script writes - to a helper-specific private namespace. The value of the named - ref should be written to a location in this namespace derived - by applying the refspecs from the "refspec" capability to the - name of the ref. -+ -Especially useful for interoperability with a foreign versioning -system. -+ -Supported if the helper has the "import" capability. - -'connect' <service>:: - Connects to given service. Standard input and standard output - of helper are connected to specified service (git prefix is - included in service name so e.g. fetching uses 'git-upload-pack' - as service) on remote side. Valid replies to this command are - empty line (connection established), 'fallback' (no smart - transport support, fall back to dumb transports) and just - exiting with error message printed (can't connect, don't - bother trying to fall back). After line feed terminating the - positive (empty) response, the output of service starts. After - the connection ends, the remote helper exits. -+ -Supported if the helper has the "connect" capability. - -If a fatal error occurs, the program writes the error message to -stderr and exits. The caller should expect that a suitable error -message has been printed if the child closes the connection without -completing a valid response for the current command. - -Additional commands may be supported, as may be determined from -capabilities reported by the helper. - -CAPABILITIES ------------- - -'fetch':: -'option':: -'push':: -'import':: -'connect':: - This helper supports the corresponding command with the same name. - -'refspec' 'spec':: - When using the import command, expect the source ref to have - been written to the destination ref. The earliest applicable - refspec takes precedence. For example - "refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}" means - that, after an "import refs/heads/name", the script has written to - refs/svn/origin/branches/name. If this capability is used at - all, it must cover all refs reported by the list command; if - it is not used, it is effectively "{asterisk}:{asterisk}" - -REF LIST ATTRIBUTES -------------------- - -'for-push':: - The caller wants to use the ref list to prepare push - commands. A helper might chose to acquire the ref list by - opening a different type of connection to the destination. - -'unchanged':: - This ref is unchanged since the last import or fetch, although - the helper cannot necessarily determine what value that produced. - -OPTIONS -------- -'option verbosity' <n>:: - Changes the verbosity of messages displayed by the helper. - A value of 0 for <n> means that processes operate - quietly, and the helper produces only error output. - 1 is the default level of verbosity, and higher values - of <n> correspond to the number of -v flags passed on the - command line. - -'option progress' \{'true'|'false'\}:: - Enables (or disables) progress messages displayed by the - transport helper during a command. - -'option depth' <depth>:: - Deepens the history of a shallow repository. - -'option followtags' \{'true'|'false'\}:: - If enabled the helper should automatically fetch annotated - tag objects if the object the tag points at was transferred - during the fetch command. If the tag is not fetched by - the helper a second fetch command will usually be sent to - ask for the tag specifically. Some helpers may be able to - use this option to avoid a second network connection. - -'option dry-run' \{'true'|'false'\}: - If true, pretend the operation completed successfully, - but don't actually change any repository data. For most - helpers this only applies to the 'push', if supported. - -'option servpath <c-style-quoted-path>':: - Sets service path (--upload-pack, --receive-pack etc.) for - next connect. Remote helper may support this option, but - must not rely on this option being set before - connect request occurs. - -SEE ALSO --------- -linkgit:git-remote[1] - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote-helpers.txto b/Documentation/git-remote-helpers.txto new file mode 100644 index 000000000..49233f5d2 --- /dev/null +++ b/Documentation/git-remote-helpers.txto @@ -0,0 +1,9 @@ +git-remote-helpers +================== + +This document has been moved to linkgit:gitremote-helpers[1]. + +Please let the owners of the referring site know so that they can update the +link you clicked to get here. + +Thanks. diff --git a/Documentation/git-remote-testgit.txt b/Documentation/git-remote-testgit.txt new file mode 100644 index 000000000..f791d73c0 --- /dev/null +++ b/Documentation/git-remote-testgit.txt @@ -0,0 +1,30 @@ +git-remote-testgit(1) +===================== + +NAME +---- +git-remote-testgit - Example remote-helper + + +SYNOPSIS +-------- +[verse] +git clone testgit::<source-repo> [<destination>] + +DESCRIPTION +----------- + +This command is a simple remote-helper, that is used both as a +testcase for the remote-helper functionality, and as an example to +show remote-helper authors one possible implementation. + +The best way to learn more is to read the comments and source code in +'git-remote-testgit'. + +SEE ALSO +-------- +linkgit:gitremote-helpers[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 5a8c5061f..2507c8bd9 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -10,16 +10,16 @@ SYNOPSIS -------- [verse] 'git remote' [-v | --verbose] -'git remote add' [-t <branch>] [-m <master>] [-f] [--tags|--no-tags] [--mirror=<fetch|push>] <name> <url> +'git remote add' [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=<fetch|push>] <name> <url> 'git remote rename' <old> <new> -'git remote rm' <name> -'git remote set-head' <name> (-a | -d | <branch>) -'git remote set-branches' <name> [--add] <branch>... +'git remote remove' <name> +'git remote set-head' <name> (-a | --auto | -d | --delete | <branch>) +'git remote set-branches' [--add] <name> <branch>... 'git remote set-url' [--push] <name> <newurl> [<oldurl>] 'git remote set-url --add' [--push] <name> <newurl> 'git remote set-url --delete' [--push] <name> <url> -'git remote' [-v | --verbose] 'show' [-n] <name> -'git remote prune' [-n | --dry-run] <name> +'git remote' [-v | --verbose] 'show' [-n] <name>... +'git remote prune' [-n | --dry-run] <name>... 'git remote' [-v | --verbose] 'update' [-p | --prune] [(<group> | <remote>)...] DESCRIPTION @@ -67,14 +67,14 @@ multiple branches without grabbing all branches. With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` is set up to point at remote's `<master>` branch. See also the set-head command. + -When a fetch mirror is created with `\--mirror=fetch`, the refs will not +When a fetch mirror is created with `--mirror=fetch`, the refs will not be stored in the 'refs/remotes/' namespace, but rather everything in 'refs/' on the remote will be directly mirrored into 'refs/' in the local repository. This option only makes sense in bare repositories, because a fetch would overwrite any local commits. + -When a push mirror is created with `\--mirror=push`, then `git push` -will always behave as if `\--mirror` was passed. +When a push mirror is created with `--mirror=push`, then `git push` +will always behave as if `--mirror` was passed. 'rename':: @@ -85,6 +85,7 @@ In case <old> and <new> are the same, and <old> is a file under `$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to the configuration file format. +'remove':: 'rm':: Remove the remote named <name>. All remote-tracking branches and @@ -100,9 +101,9 @@ branch. For example, if the default branch for `origin` is set to `master`, then `origin` may be specified wherever you would normally specify `origin/master`. + -With `-d`, the symbolic ref `refs/remotes/<name>/HEAD` is deleted. +With `-d` or `--delete`, the symbolic ref `refs/remotes/<name>/HEAD` is deleted. + -With `-a`, the remote is queried to determine its `HEAD`, then the +With `-a` or `--auto`, the remote is queried to determine its `HEAD`, then the symbolic-ref `refs/remotes/<name>/HEAD` is set to the same branch. e.g., if the remote `HEAD` is pointed at `next`, "`git remote set-head origin -a`" will set the symbolic-ref `refs/remotes/origin/HEAD` to `refs/remotes/origin/next`. This will @@ -186,18 +187,25 @@ Examples $ git remote origin $ git branch -r -origin/master -$ git remote add linux-nfs git://linux-nfs.org/pub/linux/nfs-2.6.git + origin/HEAD -> origin/master + origin/master +$ git remote add staging git://git.kernel.org/.../gregkh/staging.git $ git remote -linux-nfs origin -$ git fetch -* refs/remotes/linux-nfs/master: storing branch 'master' ... - commit: bf81b46 +staging +$ git fetch staging +... +From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging + * [new branch] master -> staging/master + * [new branch] staging-linus -> staging/staging-linus + * [new branch] staging-next -> staging/staging-next $ git branch -r -origin/master -linux-nfs/master -$ git checkout -b nfs linux-nfs/master + origin/HEAD -> origin/master + origin/master + staging/master + staging/staging-linus + staging/staging-next +$ git checkout -b staging staging/master ... ------------ diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt index 40af32115..509cf73e5 100644 --- a/Documentation/git-repack.txt +++ b/Documentation/git-repack.txt @@ -14,7 +14,7 @@ SYNOPSIS DESCRIPTION ----------- -This script is used to combine all objects that do not currently +This command is used to combine all objects that do not currently reside in a "pack", into a pack. It can also be used to re-organize existing packs into a single, more efficient pack. @@ -34,7 +34,7 @@ OPTIONS Especially useful when packing a repository that is used for private development. Use with '-d'. This will clean up the objects that `git prune` - leaves behind, but `git fsck --full` shows as + leaves behind, but `git fsck --full --dangling` shows as dangling. + Note that users fetching over dumb protocols will have to fetch the diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index 17df52527..0a02f7065 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -10,20 +10,25 @@ SYNOPSIS [verse] 'git replace' [-f] <object> <replacement> 'git replace' -d <object>... -'git replace' -l [<pattern>] +'git replace' [--format=<format>] [-l [<pattern>]] DESCRIPTION ----------- -Adds a 'replace' reference in `.git/refs/replace/` +Adds a 'replace' reference in `refs/replace/` namespace. -The name of the 'replace' reference is the SHA1 of the object that is -replaced. The content of the 'replace' reference is the SHA1 of the +The name of the 'replace' reference is the SHA-1 of the object that is +replaced. The content of the 'replace' reference is the SHA-1 of the replacement object. -Unless `-f` is given, the 'replace' reference must not yet exist in -`.git/refs/replace/` directory. +The replaced object and the replacement object must be of the same type. +This restriction can be bypassed using `-f`. -Replacement references will be used by default by all git commands +Unless `-f` is given, the 'replace' reference must not yet exist. + +There is no other restriction on the replaced and replacement objects. +Merge commits can be replaced by non-merge commits and vice versa. + +Replacement references will be used by default by all Git commands except those doing reachability traversal (prune, pack transfer and fsck). @@ -50,18 +55,51 @@ achieve the same effect as the `--no-replace-objects` option. OPTIONS ------- -f:: +--force:: If an existing replace ref for the same object exists, it will be overwritten (instead of failing). -d:: +--delete:: Delete existing replace refs for the given objects. -l <pattern>:: +--list <pattern>:: List replace refs for objects that match the given pattern (or all if no pattern is given). Typing "git replace" without arguments, also lists all replace refs. +--format=<format>:: + When listing, use the specified <format>, which can be one of + 'short', 'medium' and 'long'. When omitted, the format + defaults to 'short'. + +FORMATS +------- + +The following format are available: + +* 'short': + <replaced sha1> +* 'medium': + <replaced sha1> -> <replacement sha1> +* 'long': + <replaced sha1> (<replaced type>) -> <replacement sha1> (<replacement type>) + +CREATING REPLACEMENT OBJECTS +---------------------------- + +linkgit:git-filter-branch[1], linkgit:git-hash-object[1] and +linkgit:git-rebase[1], among other git commands, can be used to create +replacement objects from existing objects. + +If you want to replace many blobs, trees or commits that are part of a +string of commits, you may just want to create a replacement string of +commits and then only replace the commit at the tip of the target +string of commits with the commit at the tip of the replacement string +of commits. + BUGS ---- Comparing blobs or trees that have been replaced with those that @@ -70,12 +108,13 @@ go back to a replaced commit will move the branch to the replacement commit instead of the replaced commit. There may be other problems when using 'git rev-list' related to -pending objects. And of course things may break if an object of one -type is replaced by an object of another type (for example a blob -replaced by a commit). +pending objects. SEE ALSO -------- +linkgit:git-hash-object[1] +linkgit:git-filter-branch[1] +linkgit:git-rebase[1] linkgit:git-tag[1] linkgit:git-branch[1] linkgit:git[1] diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt deleted file mode 100644 index 9ec115b9e..000000000 --- a/Documentation/git-repo-config.txt +++ /dev/null @@ -1,23 +0,0 @@ -git-repo-config(1) -================== - -NAME ----- -git-repo-config - Get and set repository or global options - - -SYNOPSIS --------- -[verse] -'git repo-config' ... - - -DESCRIPTION ------------ - -This is a synonym for linkgit:git-config[1]. Please refer to the -documentation of that command. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt index a6253ba61..a62227f84 100644 --- a/Documentation/git-rerere.txt +++ b/Documentation/git-rerere.txt @@ -8,7 +8,7 @@ git-rerere - Reuse recorded resolution of conflicted merges SYNOPSIS -------- [verse] -'git rerere' ['clear'|'forget' <pathspec>|'diff'|'status'|'gc'] +'git rerere' ['clear'|'forget' <pathspec>|'diff'|'remaining'|'status'|'gc'] DESCRIPTION ----------- @@ -37,30 +37,35 @@ its working state. 'clear':: -This resets the metadata used by rerere if a merge resolution is to be +Reset the metadata used by rerere if a merge resolution is to be aborted. Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]' will automatically invoke this command. 'forget' <pathspec>:: -This resets the conflict resolutions which rerere has recorded for the current +Reset the conflict resolutions which rerere has recorded for the current conflict in <pathspec>. 'diff':: -This displays diffs for the current state of the resolution. It is +Display diffs for the current state of the resolution. It is useful for tracking what has changed while the user is resolving conflicts. Additional arguments are passed directly to the system 'diff' command installed in PATH. 'status':: -Like 'diff', but this only prints the filenames that will be tracked -for resolutions. +Print paths with conflicts whose merge resolution rerere will record. + +'remaining':: + +Print paths with conflicts that have not been autoresolved by rerere. +This includes paths whose resolutions cannot be tracked by rerere, +such as conflicting submodules. 'gc':: -This prunes records of conflicted merges that +Prune records of conflicted merges that occurred a long time ago. By default, unresolved conflicts older than 15 days and resolved conflicts older than 60 days are pruned. These defaults are controlled via the @@ -96,15 +101,15 @@ One way to do it is to pull master into the topic branch: The commits marked with `*` touch the same area in the same file; you need to resolve the conflicts when creating the commit -marked with `{plus}`. Then you can test the result to make sure your +marked with `+`. Then you can test the result to make sure your work-in-progress still works with what is in the latest master. After this test merge, there are two ways to continue your work on the topic. The easiest is to build on top of the test merge -commit `{plus}`, and when your work in the topic branch is finally +commit `+`, and when your work in the topic branch is finally ready, pull the topic branch into master, and/or ask the upstream to pull from you. By that time, however, the master or -the upstream might have been advanced since the test merge `{plus}`, +the upstream might have been advanced since the test merge `+`, in which case the final commit graph would look like this: ------------ diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index b2832fc7e..f445cb38f 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt @@ -8,20 +8,20 @@ git-reset - Reset current HEAD to the specified state SYNOPSIS -------- [verse] -'git reset' [-q] [<commit>] [--] <paths>... -'git reset' [--patch|-p] [<commit>] [--] [<paths>...] +'git reset' [-q] [<tree-ish>] [--] <paths>... +'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...] 'git reset' [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>] DESCRIPTION ----------- -In the first and second form, copy entries from <commit> to the index. +In the first and second form, copy entries from <tree-ish> to the index. In the third form, set the current branch head (HEAD) to <commit>, optionally -modifying index and working tree to match. The <commit> defaults to HEAD -in all forms. +modifying index and working tree to match. The <tree-ish>/<commit> defaults +to HEAD in all forms. -'git reset' [-q] [<commit>] [--] <paths>...:: +'git reset' [-q] [<tree-ish>] [--] <paths>...:: This form resets the index entries for all <paths> to their - state at <commit>. (It does not affect the working tree, nor + state at <tree-ish>. (It does not affect the working tree, nor the current branch.) + This means that `git reset <paths>` is the opposite of `git add @@ -34,20 +34,20 @@ Alternatively, using linkgit:git-checkout[1] and specifying a commit, you can copy the contents of a path out of a commit to the index and to the working tree in one go. -'git reset' --patch|-p [<commit>] [--] [<paths>...]:: +'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...]:: Interactively select hunks in the difference between the index - and <commit> (defaults to HEAD). The chosen hunks are applied + and <tree-ish> (defaults to HEAD). The chosen hunks are applied in reverse to the index. + This means that `git reset -p` is the opposite of `git add -p`, i.e. you can use it to selectively reset hunks. See the ``Interactive Mode'' -section of linkgit:git-add[1] to learn how to operate the `\--patch` mode. +section of linkgit:git-add[1] to learn how to operate the `--patch` mode. -'git reset' [--<mode>] [<commit>]:: +'git reset' [<mode>] [<commit>]:: This form resets the current branch head to <commit> and possibly updates the index (resetting it to the tree of <commit>) and - the working tree depending on <mode>, which - must be one of the following: + the working tree depending on <mode>. If <mode> is omitted, + defaults to "--mixed". The <mode> must be one of the following: + -- --soft:: diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt index 38fafcaa6..045b37b82 100644 --- a/Documentation/git-rev-list.txt +++ b/Documentation/git-rev-list.txt @@ -40,7 +40,7 @@ SYNOPSIS [ \--right-only ] [ \--cherry-mark ] [ \--cherry-pick ] - [ \--encoding[=<encoding>] ] + [ \--encoding=<encoding> ] [ \--(author|committer|grep)=<pattern> ] [ \--regexp-ignore-case | -i ] [ \--extended-regexp | -E ] @@ -99,7 +99,7 @@ between the two operands. The following two commands are equivalent: $ git rev-list A...B ----------------------------------------------------------------------- -'rev-list' is a very essential git command, since it +'rev-list' is a very essential Git command, since it provides the ability to build and traverse commit ancestry graphs. For this reason, it has a lot of different options that enables it to be used by commands as different as 'git bisect' and diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index 42c9676ea..0d2cdcde5 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -14,7 +14,7 @@ SYNOPSIS DESCRIPTION ----------- -Many git porcelainish commands take mixture of flags +Many Git porcelainish commands take mixture of flags (i.e. parameters that begin with a dash '-') and parameters meant for the underlying 'git rev-list' command they use internally and flags and parameters for the other commands they use @@ -24,9 +24,23 @@ distinguish between them. OPTIONS ------- + +Operation Modes +~~~~~~~~~~~~~~~ + +Each of these options must appear first on the command line. + --parseopt:: Use 'git rev-parse' in option parsing mode (see PARSEOPT section below). +--sq-quote:: + Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE + section below). In contrast to the `--sq` option below, this + mode does only quoting. Nothing else is done to command input. + +Options for --parseopt +~~~~~~~~~~~~~~~~~~~~~~ + --keep-dashdash:: Only meaningful in `--parseopt` mode. Tells the option parser to echo out the first `--` met instead of skipping it. @@ -36,10 +50,12 @@ OPTIONS the first non-option argument. This can be used to parse sub-commands that take options themselves. ---sq-quote:: - Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE - section below). In contrast to the `--sq` option below, this - mode does only quoting. Nothing else is done to command input. +--stuck-long:: + Only meaningful in `--parseopt` mode. Output the options in their + long form if available, and with their arguments stuck. + +Options for Filtering +~~~~~~~~~~~~~~~~~~~~~ --revs-only:: Do not output flags and parameters not meant for @@ -55,13 +71,43 @@ OPTIONS --no-flags:: Do not output flag parameters. +Options for Output +~~~~~~~~~~~~~~~~~~ + --default <arg>:: If there is no parameter given by the user, use `<arg>` instead. +--prefix <arg>:: + Behave as if 'git rev-parse' was invoked from the `<arg>` + subdirectory of the working tree. Any relative filenames are + resolved as if they are prefixed by `<arg>` and will be printed + in that form. ++ +This can be used to convert arguments to a command run in a subdirectory +so that they can still be used after moving to the top-level of the +repository. For example: ++ +---- +prefix=$(git rev-parse --show-prefix) +cd "$(git rev-parse --show-toplevel)" +eval "set -- $(git rev-parse --sq --prefix "$prefix" "$@")" +---- + --verify:: - The parameter given must be usable as a single, valid - object name. Otherwise barf and abort. + Verify that exactly one parameter is provided, and that it + can be turned into a raw 20-byte SHA-1 that can be used to + access the object database. If so, emit it to the standard + output; otherwise, error out. ++ +If you want to make sure that the output actually names an object in +your object database and/or can be used as a specific type of object +you require, you can add "^{type}" peeling operator to the parameter. +For example, `git rev-parse "$VAR^{commit}"` will make sure `$VAR` +names an existing object that is a commit-ish (i.e. a commit, or an +annotated tag that points at a commit). To make sure that `$VAR` +names an existing object of any type, `git rev-parse "$VAR^{object}"` +can be used. -q:: --quiet:: @@ -83,8 +129,19 @@ OPTIONS strip '{caret}' prefix from the object names that already have one. +--abbrev-ref[=(strict|loose)]:: + A non-ambiguous short name of the objects name. + The option core.warnAmbiguousRefs is used to select the strict + abbreviation mode. + +--short:: +--short=number:: + Instead of outputting the full SHA-1 values of object names try to + abbreviate them to a shorter unique name. When no length is specified + 7 is used. The minimum length is 4. + --symbolic:: - Usually the object names are output in SHA1 form (with + Usually the object names are output in SHA-1 form (with possible '{caret}' prefix); this option makes them output in a form as close to the original input as possible. @@ -96,10 +153,8 @@ OPTIONS unfortunately named tag "master"), and show them as full refnames (e.g. "refs/heads/master"). ---abbrev-ref[=(strict|loose)]:: - A non-ambiguous short name of the objects name. - The option core.warnAmbiguousRefs is used to select the strict - abbreviation mode. +Options for Objects +~~~~~~~~~~~~~~~~~~~ --all:: Show all refs found in `refs/`. @@ -113,35 +168,51 @@ OPTIONS + If a `pattern` is given, only refs matching the given shell glob are shown. If the pattern does not contain a globbing character (`?`, -`{asterisk}`, or `[`), it is turned into a prefix match by -appending `/{asterisk}`. +`*`, or `[`), it is turned into a prefix match by appending `/*`. --glob=pattern:: Show all refs matching the shell glob pattern `pattern`. If the pattern does not start with `refs/`, this is automatically prepended. If the pattern does not contain a globbing - character (`?`, `{asterisk}`, or `[`), it is turned into a prefix - match by appending `/{asterisk}`. + character (`?`, `*`, or `[`), it is turned into a prefix + match by appending `/*`. + +--exclude=<glob-pattern>:: + Do not include refs matching '<glob-pattern>' that the next `--all`, + `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise + consider. Repetitions of this option accumulate exclusion patterns + up to the next `--all`, `--branches`, `--tags`, `--remotes`, or + `--glob` option (other options or arguments do not clear + accumlated patterns). ++ +The patterns given should not begin with `refs/heads`, `refs/tags`, or +`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`, +respectively, and they must begin with `refs/` when applied to `--glob` +or `--all`. If a trailing '/{asterisk}' is intended, it must be given +explicitly. ---show-toplevel:: - Show the absolute path of the top-level directory. +--disambiguate=<prefix>:: + Show every object whose name begins with the given prefix. + The <prefix> must be at least 4 hexadecimal digits long to + avoid listing each and every object in the repository by + mistake. ---show-prefix:: - When the command is invoked from a subdirectory, show the - path of the current directory relative to the top-level - directory. +Options for Files +~~~~~~~~~~~~~~~~~ ---show-cdup:: - When the command is invoked from a subdirectory, show the - path of the top-level directory relative to the current - directory (typically a sequence of "../", or an empty string). +--local-env-vars:: + List the GIT_* environment variables that are local to the + repository (e.g. GIT_DIR or GIT_WORK_TREE, but not GIT_EDITOR). + Only the names of the variables are listed, not their value, + even if they are set. --git-dir:: Show `$GIT_DIR` if defined. Otherwise show the path to - the .git directory, relative to the current directory. + the .git directory. The path shown, when relative, is + relative to the current working directory. + If `$GIT_DIR` is not defined and the current directory -is not detected to lie in a git repository or work tree +is not detected to lie in a Git repository or work tree print a message to stderr and exit with nonzero status. --is-inside-git-dir:: @@ -155,17 +226,27 @@ print a message to stderr and exit with nonzero status. --is-bare-repository:: When the repository is bare print "true", otherwise "false". ---local-env-vars:: - List the GIT_* environment variables that are local to the - repository (e.g. GIT_DIR or GIT_WORK_TREE, but not GIT_EDITOR). - Only the names of the variables are listed, not their value, - even if they are set. +--resolve-git-dir <path>:: + Check if <path> is a valid repository or a gitfile that + points at a valid repository, and print the location of the + repository. If <path> is a gitfile then the resolved path + to the real repository is printed. ---short:: ---short=number:: - Instead of outputting the full SHA1 values of object names try to - abbreviate them to a shorter unique name. When no length is specified - 7 is used. The minimum length is 4. +--show-cdup:: + When the command is invoked from a subdirectory, show the + path of the top-level directory relative to the current + directory (typically a sequence of "../", or an empty string). + +--show-prefix:: + When the command is invoked from a subdirectory, show the + path of the current directory relative to the top-level + directory. + +--show-toplevel:: + Show the absolute path of the top-level directory. + +Other Options +~~~~~~~~~~~~~ --since=datestring:: --after=datestring:: @@ -222,7 +303,9 @@ Each line of options has this format: `<flags>` are of `*`, `=`, `?` or `!`. * Use `=` if the option takes an argument. - * Use `?` to mean that the option is optional (though its use is discouraged). + * Use `?` to mean that the option takes an optional argument. You + probably want to use the `--stuck-long` mode to be able to + unambiguously parse the optional argument. * Use `*` to mean that this option should not be listed in the usage generated for the `-h` argument. It's shown for `--help-all` as @@ -296,12 +379,12 @@ $ git rev-parse --verify HEAD * Print the commit object name from the revision in the $REV shell variable: + ------------ -$ git rev-parse --verify $REV +$ git rev-parse --verify $REV^{commit} ------------ + This will error out if $REV is empty or not a valid revision. -* Same as above: +* Similar to above: + ------------ $ git rev-parse --default master --verify $REV diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt index 3d0a7d1da..2de67a549 100644 --- a/Documentation/git-revert.txt +++ b/Documentation/git-revert.txt @@ -8,7 +8,10 @@ git-revert - Revert some existing commits SYNOPSIS -------- [verse] -'git revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>... +'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] <commit>... +'git revert' --continue +'git revert' --quit +'git revert' --abort DESCRIPTION ----------- @@ -24,7 +27,7 @@ throw away all uncommitted changes in your working directory, you should see linkgit:git-reset[1], particularly the '--hard' option. If you want to extract specific files as they were in another commit, you should see linkgit:git-checkout[1], specifically the `git checkout -<commit> \-- <filename>` syntax. Take care with these alternatives as +<commit> -- <filename>` syntax. Take care with these alternatives as both will discard uncommitted changes in your working directory. OPTIONS @@ -56,7 +59,7 @@ brought in by the merge. As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge. This may or may not be what you want. + -See the link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for +See the link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for more details. --no-edit:: @@ -91,14 +94,18 @@ effect to your index in a row. Pass the merge strategy-specific option through to the merge strategy. See linkgit:git-merge[1] for details. +SEQUENCER SUBCOMMANDS +--------------------- +include::sequencer.txt[] + EXAMPLES -------- -git revert HEAD~3:: +`git revert HEAD~3`:: Revert the changes specified by the fourth last commit in HEAD and create a new commit with the reverted changes. -git revert -n master{tilde}5..master{tilde}2:: +`git revert -n master~5..master~2`:: Revert the changes done by commits from the fifth last commit in master (included) to the third last commit in master diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt index da0215d20..f1efc116e 100644 --- a/Documentation/git-rm.txt +++ b/Documentation/git-rm.txt @@ -28,7 +28,7 @@ OPTIONS ------- <file>...:: Files to remove. Fileglobs (e.g. `*.c`) can be given to - remove all matching files. If you want git to expand + remove all matching files. If you want Git to expand file glob characters, you may need to shell-escape them. A leading directory name (e.g. `dir` to remove `dir/file1` and `dir/file2`) can be @@ -74,13 +74,12 @@ DISCUSSION The <file> list given to the command can be exact pathnames, file glob patterns, or leading directory names. The command -removes only the paths that are known to git. Giving the name of -a file that you have not told git about does not remove that file. +removes only the paths that are known to Git. Giving the name of +a file that you have not told Git about does not remove that file. File globbing matches across directory boundaries. Thus, given two directories `d` and `d2`, there is a difference between -using `git rm {apostrophe}d{asterisk}{apostrophe}` and -`git rm {apostrophe}d/{asterisk}{apostrophe}`, as the former will +using `git rm 'd*'` and `git rm 'd/*'`, as the former will also remove all of directory `d2`. REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM @@ -135,21 +134,51 @@ use the following command: git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached ---------------- +SUBMODULES +---------- +Only submodules using a gitfile (which means they were cloned +with a Git version 1.7.8 or newer) will be removed from the work +tree, as their repository lives inside the .git directory of the +superproject. If a submodule (or one of those nested inside it) +still uses a .git directory, `git rm` will fail - no matter if forced +or not - to protect the submodule's history. If it exists the +submodule.<name> section in the linkgit:gitmodules[5] file will also +be removed and that file will be staged (unless --cached or -n are used). + +A submodule is considered up-to-date when the HEAD is the same as +recorded in the index, no tracked files are modified and no untracked +files that aren't ignored are present in the submodules work tree. +Ignored files are deemed expendable and won't stop a submodule's work +tree from being removed. + +If you only want to remove the local checkout of a submodule from your +work tree without committing the removal, +use linkgit:git-submodule[1] `deinit` instead. + EXAMPLES -------- -git rm Documentation/\*.txt:: +`git rm Documentation/\*.txt`:: Removes all `*.txt` files from the index that are under the `Documentation` directory and any of its subdirectories. + Note that the asterisk `*` is quoted from the shell in this -example; this lets git, and not the shell, expand the pathnames +example; this lets Git, and not the shell, expand the pathnames of files and subdirectories under the `Documentation/` directory. -git rm -f git-*.sh:: +`git rm -f git-*.sh`:: Because this example lets the shell expand the asterisk (i.e. you are listing the files explicitly), it does not remove `subdir/git-foo.sh`. +BUGS +---- +Each time a superproject update removes a populated submodule +(e.g. when switching between commits before and after the removal) a +stale submodule checkout will remain in the old location. Removing the +old directory is only safe when it uses a gitfile, as otherwise the +history of the submodule will be deleted too. This step will be +obsolete when recursive submodule update has been implemented. + SEE ALSO -------- linkgit:git-add[1] diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 327233c85..f0e57a597 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -45,8 +45,9 @@ Composing ~~~~~~~~~ --annotate:: - Review and edit each patch you're about to send. See the - CONFIGURATION section for 'sendemail.multiedit'. + Review and edit each patch you're about to send. Default is the value + of 'sendemail.annotate'. See the CONFIGURATION section for + 'sendemail.multiedit'. --bcc=<address>:: Specify a "Bcc:" value for each email. Default is the value of @@ -67,7 +68,7 @@ The --cc option must be repeated for each user you want on the cc list. When '--compose' is used, git send-email will use the From, Subject, and In-Reply-To headers specified in the message. If the body of the message (what you type after the headers and a blank line) only contains blank -(or GIT: prefixed) lines the summary won't be sent, but From, Subject, +(or Git: prefixed) lines the summary won't be sent, but From, Subject, and In-Reply-To headers will be used unless they are removed. + Missing From or In-Reply-To headers will be prompted for. @@ -126,6 +127,10 @@ The --to option must be repeated for each user you want on the to list. + Note that no attempts whatsoever are made to validate the encoding. +--compose-encoding=<encoding>:: + Specify encoding of compose message. Default is the value of the + 'sendemail.composeencoding'; if that is unspecified, UTF-8 is assumed. + Sending ~~~~~~~ @@ -160,8 +165,8 @@ Sending Furthermore, passwords need not be specified in configuration files or on the command line. If a username has been specified (with '--smtp-user' or a 'sendemail.smtpuser'), but no password has been -specified (with '--smtp-pass' or 'sendemail.smtppass'), then the -user is prompted for a password while the input is masked for privacy. +specified (with '--smtp-pass' or 'sendemail.smtppass'), then +a password is obtained using 'git-credential'. --smtp-server=<host>:: If set, specifies the outgoing SMTP server to use (e.g. @@ -193,11 +198,21 @@ must be used for each option. --smtp-ssl:: Legacy alias for '--smtp-encryption ssl'. +--smtp-ssl-cert-path:: + Path to ca-certificates (either a directory or a single file). + Set it to an empty string to disable certificate verification. + Defaults to the value set to the 'sendemail.smtpsslcertpath' + configuration variable, if set, or `/etc/ssl/certs` otherwise. + --smtp-user=<user>:: Username for SMTP-AUTH. Default is the value of 'sendemail.smtpuser'; if a username is not specified (with '--smtp-user' or 'sendemail.smtpuser'), then authentication is not attempted. +--smtp-debug=0|1:: + Enable (1) or disable (0) debug output. If enabled, SMTP + commands and replies will be printed. Useful to debug TLS + connection and authentication problems. Automating ~~~~~~~~~~ diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt index bd3eaa69b..dc3a568ba 100644 --- a/Documentation/git-send-pack.txt +++ b/Documentation/git-send-pack.txt @@ -3,7 +3,7 @@ git-send-pack(1) NAME ---- -git-send-pack - Push objects over git protocol to another repository +git-send-pack - Push objects over Git protocol to another repository SYNOPSIS diff --git a/Documentation/git-sh-i18n--envsubst.txt b/Documentation/git-sh-i18n--envsubst.txt index 5c3ec327b..2ffaf9392 100644 --- a/Documentation/git-sh-i18n--envsubst.txt +++ b/Documentation/git-sh-i18n--envsubst.txt @@ -25,7 +25,7 @@ plumbing scripts and/or are writing new ones. 'git sh-i18n{litdd}envsubst' is Git's stripped-down copy of the GNU `envsubst(1)` program that comes with the GNU gettext package. It's used internally by linkgit:git-sh-i18n[1] to interpolate the variables -passed to the the `eval_gettext` function. +passed to the `eval_gettext` function. No promises are made about the interface, or that this program won't disappear without warning in the next version diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt index a2f346ca7..4f67c4cde 100644 --- a/Documentation/git-sh-setup.txt +++ b/Documentation/git-sh-setup.txt @@ -3,7 +3,7 @@ git-sh-setup(1) NAME ---- -git-sh-setup - Common git shell script setup code +git-sh-setup - Common Git shell script setup code SYNOPSIS -------- @@ -19,7 +19,7 @@ Porcelain-ish scripts and/or are writing new ones. The 'git sh-setup' scriptlet is designed to be sourced (using `.`) by other shell scripts to set up some variables pointing at -the normal git directories and a few helper shell functions. +the normal Git directories and a few helper shell functions. Before sourcing it, your script should set up a few variables; `USAGE` (and `LONG_USAGE`, if any) is used to define message @@ -41,9 +41,11 @@ usage:: die with the usage message. set_reflog_action:: - set the message that will be recorded to describe the - end-user action in the reflog, when the script updates a - ref. + Set GIT_REFLOG_ACTION environment to a given string (typically + the name of the program) unless it is already set. Whenever + the script runs a `git` command that updates refs, a reflog + entry is created using the value of this string to leave the + record of what command updated the ref. git_editor:: runs an editor of user's choice (GIT_EDITOR, core.editor, VISUAL or @@ -68,10 +70,26 @@ require_work_tree_exists:: cd_to_toplevel, which is impossible to do if there is no working tree. +require_clean_work_tree <action> [<hint>]:: + checks that the working tree and index associated with the + repository have no uncommitted changes to tracked files. + Otherwise it emits an error message of the form `Cannot + <action>: <reason>. <hint>`, and dies. Example: ++ +---------------- +require_clean_work_tree rebase "Please commit or stash them." +---------------- + get_author_ident_from_commit:: outputs code for use with eval to set the GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit. +create_virtual_base:: + modifies the first file so only lines in common with the + second file remain. If there is insufficient common material, + then the first file is left empty. The result is suitable + as a virtual base input for a 3-way merge. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt index 9b9250600..c35051ba5 100644 --- a/Documentation/git-shell.txt +++ b/Documentation/git-shell.txt @@ -9,25 +9,81 @@ git-shell - Restricted login shell for Git-only SSH access SYNOPSIS -------- [verse] -'git shell' [-c <command> <argument>] +'chsh' -s $(command -v git-shell) <user> +'git clone' <user>`@localhost:/path/to/repo.git` +'ssh' <user>`@localhost` DESCRIPTION ----------- -A login shell for SSH accounts to provide restricted Git access. When -'-c' is given, the program executes <command> non-interactively; -<command> can be one of 'git receive-pack', 'git upload-pack', 'git -upload-archive', 'cvs server', or a command in COMMAND_DIR. The shell -is started in interactive mode when no arguments are given; in this -case, COMMAND_DIR must exist, and any of the executables in it can be -invoked. +This is a login shell for SSH accounts to provide restricted Git access. +It permits execution only of server-side Git commands implementing the +pull/push functionality, plus custom commands present in a subdirectory +named `git-shell-commands` in the user's home directory. -'cvs server' is a special command which executes git-cvsserver. +COMMANDS +-------- + +'git shell' accepts the following commands after the '-c' option: + +'git receive-pack <argument>':: +'git upload-pack <argument>':: +'git upload-archive <argument>':: + Call the corresponding server-side command to support + the client's 'git push', 'git fetch', or 'git archive --remote' + request. +'cvs server':: + Imitate a CVS server. See linkgit:git-cvsserver[1]. + +If a `~/git-shell-commands` directory is present, 'git shell' will +also handle other, custom commands by running +"`git-shell-commands/<command> <arguments>`" from the user's home +directory. + +INTERACTIVE USE +--------------- + +By default, the commands above can be executed only with the '-c' +option; the shell is not interactive. -COMMAND_DIR is the path "$HOME/git-shell-commands". The user must have -read and execute permissions to the directory in order to execute the -programs in it. The programs are executed with a cwd of $HOME, and -<argument> is parsed as a command-line string. +If a `~/git-shell-commands` directory is present, 'git shell' +can also be run interactively (with no arguments). If a `help` +command is present in the `git-shell-commands` directory, it is +run to provide the user with an overview of allowed actions. Then a +"git> " prompt is presented at which one can enter any of the +commands from the `git-shell-commands` directory, or `exit` to close +the connection. + +Generally this mode is used as an administrative interface to allow +users to list repositories they have access to, create, delete, or +rename repositories, or change repository descriptions and +permissions. + +If a `no-interactive-login` command exists, then it is run and the +interactive shell is aborted. + +EXAMPLE +------- + +To disable interactive logins, displaying a greeting instead: ++ +---------------- +$ chsh -s /usr/bin/git-shell +$ mkdir $HOME/git-shell-commands +$ cat >$HOME/git-shell-commands/no-interactive-login <<\EOF +#!/bin/sh +printf '%s\n' "Hi $USER! You've successfully authenticated, but I do not" +printf '%s\n' "provide interactive shell access." +exit 128 +EOF +$ chmod +x $HOME/git-shell-commands/no-interactive-login +---------------- + +SEE ALSO +-------- +ssh(1), +linkgit:git-daemon[1], +contrib/git-shell-commands/README GIT --- diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index ff3755b4c..31af7f273 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -8,14 +8,13 @@ git-shortlog - Summarize 'git log' output SYNOPSIS -------- [verse] -git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w] -'git shortlog' [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] <commit>... +git log --pretty=short | 'git shortlog' [<options>] +'git shortlog' [<options>] [<revision range>] [[\--] <path>...] DESCRIPTION ----------- Summarizes 'git log' output in a format suitable for inclusion -in release announcements. Each commit will be grouped by author and -the first line of the commit message will be shown. +in release announcements. Each commit will be grouped by author and title. Additionally, "[PATCH]" will be stripped from the commit description. @@ -27,10 +26,6 @@ reference to the current repository. OPTIONS ------- --h:: ---help:: - Print a short usage message and exit. - -n:: --numbered:: Sort output according to the number of commits per author instead @@ -47,7 +42,7 @@ OPTIONS --format[=<format>]:: Instead of the commit subject, use some other information to describe each commit. '<format>' can be any string accepted - by the `--format` option of 'git log', such as '{asterisk} [%h] %s'. + by the `--format` option of 'git log', such as '* [%h] %s'. (See the "PRETTY FORMATS" section of linkgit:git-log[1].) Each pretty-printed commit will be rewrapped before it is shown. @@ -57,7 +52,25 @@ OPTIONS line of each entry is indented by `indent1` spaces, and the second and subsequent lines are indented by `indent2` spaces. `width`, `indent1`, and `indent2` default to 76, 6 and 9 respectively. - ++ +If width is `0` (zero) then indent the lines of the output without wrapping +them. + +<revision range>:: + Show only commits in the specified revision range. When no + <revision range> is specified, it defaults to `HEAD` (i.e. the + whole history leading to the current commit). `origin..HEAD` + specifies all the commits reachable from the current commit + (i.e. `HEAD`), but not from `origin`. For a complete list of + ways to spell <revision range>, see the "Specifying Ranges" + section of linkgit:gitrevisions[7]. + +[\--] <path>...:: + Consider only commits that are enough to explain how the files + that match the specified paths came to be. ++ +Paths may need to be prefixed with "\-- " to separate them from +options or the revision range, when confusion arises. MAPPING AUTHORS --------------- diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt index a8e77b535..a515648ab 100644 --- a/Documentation/git-show-branch.txt +++ b/Documentation/git-show-branch.txt @@ -31,7 +31,7 @@ no <rev> nor <glob> is given on the command line. OPTIONS ------- <rev>:: - Arbitrary extended SHA1 expression (see linkgit:gitrevisions[7]) + Arbitrary extended SHA-1 expression (see linkgit:gitrevisions[7]) that typically names a branch head or a tag. <glob>:: @@ -142,7 +142,7 @@ displayed, indented N places. If a commit is on the I-th branch, the I-th indentation character shows a `+` sign; otherwise it shows a space. Merge commits are denoted by a `-` sign. Each commit shows a short name that -can be used as an extended SHA1 to name that commit. +can be used as an extended SHA-1 to name that commit. The following example shows three branches, "master", "fixes" and "mhf": diff --git a/Documentation/git-show-index.txt b/Documentation/git-show-index.txt index 2dcbbb245..fbdc8adae 100644 --- a/Documentation/git-show-index.txt +++ b/Documentation/git-show-index.txt @@ -14,12 +14,12 @@ SYNOPSIS DESCRIPTION ----------- -Reads given idx file for packed git archive created with +Reads given idx file for packed Git archive created with 'git pack-objects' command, and dumps its contents. The information it outputs is subset of what you can get from 'git verify-pack -v'; this command only shows the packfile -offset and SHA1 of each object. +offset and SHA-1 of each object. GIT --- diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt index 3c4589529..ffd1b03a9 100644 --- a/Documentation/git-show-ref.txt +++ b/Documentation/git-show-ref.txt @@ -21,6 +21,8 @@ commit IDs. Results can be filtered using a pattern and tags can be dereferenced into object IDs. Additionally, it can be used to test whether a particular ref exists. +By default, shows the tags, heads, and remote refs. + The --exclude-existing form is a filter that does the inverse, it shows the refs from stdin that don't exist in the local repository. @@ -32,26 +34,26 @@ OPTIONS --head:: - Show the HEAD reference. + Show the HEAD reference, even if it would normally be filtered out. --tags:: --heads:: - Limit to only "refs/heads" and "refs/tags", respectively. These - options are not mutually exclusive; when given both, references stored - in "refs/heads" and "refs/tags" are displayed. + Limit to "refs/heads" and "refs/tags", respectively. These options + are not mutually exclusive; when given both, references stored in + "refs/heads" and "refs/tags" are displayed. -d:: --dereference:: - Dereference tags into object IDs as well. They will be shown with "^{}" + Dereference tags into object IDs as well. They will be shown with "{caret}{}" appended. -s:: --hash[=<n>]:: - Only show the SHA1 hash, not the reference name. When combined with - --dereference the dereferenced tag will still be shown after the SHA1. + Only show the SHA-1 hash, not the reference name. When combined with + --dereference the dereferenced tag will still be shown after the SHA-1. --verify:: @@ -73,9 +75,9 @@ OPTIONS --exclude-existing[=<pattern>]:: Make 'git show-ref' act as a filter that reads refs from stdin of the - form "^(?:<anything>\s)?<refname>(?:{backslash}{caret}\{\})?$" + form "`^(?:<anything>\s)?<refname>(?:\^{})?$`" and performs the following actions on each: - (1) strip "^{}" at the end of line if any; + (1) strip "{caret}{}" at the end of line if any; (2) ignore if pattern is provided and does not head-match refname; (3) warn if refname is not a well-formed refname and skip; (4) ignore if refname is a ref that exists in the local repository; @@ -173,6 +175,7 @@ FILES SEE ALSO -------- +linkgit:git-for-each-ref[1], linkgit:git-ls-remote[1], linkgit:git-update-ref[1], linkgit:gitrepository-layout[5] diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt index 1f0e30b91..4e617e697 100644 --- a/Documentation/git-show.txt +++ b/Documentation/git-show.txt @@ -45,26 +45,35 @@ include::pretty-options.txt[] include::pretty-formats.txt[] +COMMON DIFF OPTIONS +------------------- + +:git-log: 1 +include::diff-options.txt[] + +include::diff-generate-patch.txt[] + + EXAMPLES -------- -git show v1.0.0:: +`git show v1.0.0`:: Shows the tag `v1.0.0`, along with the object the tags points at. -git show v1.0.0^\{tree\}:: +`git show v1.0.0^{tree}`:: Shows the tree pointed to by the tag `v1.0.0`. -git show -s --format=%s v1.0.0^\{commit\}:: +`git show -s --format=%s v1.0.0^{commit}`:: Shows the subject of the commit pointed to by the tag `v1.0.0`. -git show next~10:Documentation/README:: +`git show next~10:Documentation/README`:: Shows the contents of the file `Documentation/README` as they were current in the 10th last commit of the branch `next`. -git show master:Makefile master:t/Makefile:: +`git show master:Makefile master:t/Makefile`:: Concatenates the contents of said Makefiles in the head of the branch `master`. diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index 15f051fa4..db7e80303 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -13,9 +13,11 @@ SYNOPSIS 'git stash' drop [-q|--quiet] [<stash>] 'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>] 'git stash' branch <branchname> [<stash>] -'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] [<message>]] +'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] + [-u|--include-untracked] [-a|--all] [<message>]] 'git stash' clear -'git stash' create +'git stash' create [<message>] +'git stash' store [-m|--message <message>] [-q|--quiet] <commit> DESCRIPTION ----------- @@ -35,14 +37,14 @@ you create one. The latest stash you created is stored in `refs/stash`; older stashes are found in the reflog of this reference and can be named using -the usual reflog syntax (e.g. `stash@\{0}` is the most recently -created stash, `stash@\{1}` is the one before it, `stash@\{2.hours.ago}` +the usual reflog syntax (e.g. `stash@{0}` is the most recently +created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}` is also possible). OPTIONS ------- -save [-p|--patch] [--[no-]keep-index] [-q|--quiet] [<message>]:: +save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]:: Save your local modifications to a new 'stash', and run `git reset --hard` to revert them. The <message> part is optional and gives @@ -54,13 +56,18 @@ save [-p|--patch] [--[no-]keep-index] [-q|--quiet] [<message>]:: If the `--keep-index` option is used, all changes already added to the index are left intact. + +If the `--include-untracked` option is used, all untracked files are also +stashed and then cleaned up with `git clean`, leaving the working directory +in a very clean state. If the `--all` option is used instead then the +ignored files are stashed and cleaned in addition to the untracked files. ++ With `--patch`, you can interactively select hunks from the diff between HEAD and the working tree to be stashed. The stash entry is constructed such that its index state is the same as the index state of your repository, and its worktree contains only the changes you selected interactively. The selected changes are then rolled back from your worktree. See the ``Interactive Mode'' section of -linkgit:git-add[1] to learn how to operate the `\--patch` mode. +linkgit:git-add[1] to learn how to operate the `--patch` mode. + The `--patch` option implies `--keep-index`. You can use `--no-keep-index` to override this. @@ -68,7 +75,7 @@ The `--patch` option implies `--keep-index`. You can use list [<options>]:: List the stashes that you currently have. Each 'stash' is listed - with its name (e.g. `stash@\{0}` is the latest stash, `stash@\{1}` is + with its name (e.g. `stash@{0}` is the latest stash, `stash@{1}` is the one before, etc.), the name of the branch that was current when the stash was made, and a short description of the commit the stash was based on. @@ -87,7 +94,7 @@ show [<stash>]:: stashed state and its original parent. When no `<stash>` is given, shows the latest one. By default, the command shows the diffstat, but it will accept any format known to 'git diff' (e.g., `git stash show - -p stash@\{1}` to view the second most recent stash in patch form). + -p stash@{1}` to view the second most recent stash in patch form). pop [--index] [-q|--quiet] [<stash>]:: @@ -105,8 +112,8 @@ tree's changes, but also the index's ones. However, this can fail, when you have conflicts (which are stored in the index, where you therefore can no longer apply the changes as they were originally). + -When no `<stash>` is given, `stash@\{0}` is assumed, otherwise `<stash>` must -be a reference of the form `stash@\{<revision>}`. +When no `<stash>` is given, `stash@{0}` is assumed, otherwise `<stash>` must +be a reference of the form `stash@{<revision>}`. apply [--index] [-q|--quiet] [<stash>]:: @@ -137,15 +144,23 @@ clear:: drop [-q|--quiet] [<stash>]:: Remove a single stashed state from the stash list. When no `<stash>` - is given, it removes the latest one. i.e. `stash@\{0}`, otherwise - `<stash>` must a valid stash log reference of the form - `stash@\{<revision>}`. + is given, it removes the latest one. i.e. `stash@{0}`, otherwise + `<stash>` must be a valid stash log reference of the form + `stash@{<revision>}`. create:: Create a stash (which is a regular commit object) and return its object name, without storing it anywhere in the ref namespace. + This is intended to be useful for scripts. It is probably not + the command you want to use; see "save" above. + +store:: + Store a given stash created via 'git stash create' (which is a + dangling merge commit) in the stash ref, updating the stash + reflog. This is intended to be useful for scripts. It is + probably not the command you want to use; see "save" above. DISCUSSION ---------- diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index 3d51717bb..a4acaa038 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -16,7 +16,7 @@ DESCRIPTION Displays paths that have differences between the index file and the current HEAD commit, paths that have differences between the working tree and the index file, and paths in the working tree that are not -tracked by git (and are not ignored by linkgit:gitignore[5]). The first +tracked by Git (and are not ignored by linkgit:gitignore[5]). The first are what you _would_ commit by running `git commit`; the second and third are what you _could_ commit by running 'git add' before running `git commit`. @@ -35,23 +35,32 @@ OPTIONS --porcelain:: Give the output in an easy-to-parse format for scripts. This is similar to the short output, but will remain stable - across git versions and regardless of user configuration. See + across Git versions and regardless of user configuration. See below for details. +--long:: + Give the output in the long-format. This is the default. + -u[<mode>]:: --untracked-files[=<mode>]:: Show untracked files. + The mode parameter is optional (defaults to 'all'), and is used to -specify the handling of untracked files; when -u is not used, the -default is 'normal', i.e. show untracked files and directories. +specify the handling of untracked files. + The possible options are: + - - 'no' - Show no untracked files - - 'normal' - Shows untracked files and directories + - 'no' - Show no untracked files. + - 'normal' - Shows untracked files and directories. - 'all' - Also shows individual files in untracked directories. + +When `-u` option is not used, untracked files and directories are +shown (i.e. the same as specifying `normal`), to help you avoid +forgetting to add newly created files. Because it takes extra work +to find untracked files in the filesystem, this mode may take some +time in a large working tree. You can use `no` to have `git status` +return more quickly without showing untracked files. ++ The default can be changed using the status.showUntrackedFiles configuration variable documented in linkgit:git-config[1]. @@ -77,6 +86,13 @@ configuration variable documented in linkgit:git-config[1]. Terminate entries with NUL, instead of LF. This implies the `--porcelain` output format if no other format is given. +--column[=<options>]:: +--no-column:: + Display untracked files in columns. See configuration variable + column.status for option syntax.`--column` and `--no-column` + without options are equivalent to 'always' and 'never' + respectively. + OUTPUT ------ @@ -86,7 +102,7 @@ The default, long format, is designed to be human readable, verbose and descriptive. Its contents and format are subject to change at any time. -The paths mentioned in the output, unlike many other git commands, are +The paths mentioned in the output, unlike many other Git commands, are made relative to the current directory if you are working in a subdirectory (this is on purpose, to help cutting and pasting). See the status.relativePaths config option below. @@ -98,12 +114,12 @@ In the short-format, the status of each path is shown as XY PATH1 -> PATH2 -where `PATH1` is the path in the `HEAD`, and the ` \-> PATH2` part is +where `PATH1` is the path in the `HEAD`, and the " `-> PATH2`" part is shown only when `PATH1` corresponds to a different path in the index/worktree (i.e. the file is renamed). The 'XY' is a two-letter status code. -The fields (including the `\->`) are separated from each other by a +The fields (including the `->`) are separated from each other by a single space. If a filename contains whitespace or other nonprintable characters, that field will be quoted in the manner of a C string literal: surrounded by ASCII double quote (34) characters, and with @@ -158,7 +174,7 @@ Porcelain Format ~~~~~~~~~~~~~~~~ The porcelain format is similar to the short format, but is guaranteed -not to change in a backwards-incompatible way between git versions or +not to change in a backwards-incompatible way between Git versions or based on user configuration. This makes it ideal for parsing by scripts. The description of the short format above also describes the porcelain format, with a few exceptions: @@ -177,7 +193,7 @@ order is reversed (e.g 'from \-> to' becomes 'to from'). Second, a NUL and the terminating newline (but a space still separates the status field from the first filename). Third, filenames containing special characters are not specially formatted; no quoting or -backslash-escaping is performed. Fourth, there is no branch line. +backslash-escaping is performed. CONFIGURATION ------------- @@ -194,7 +210,13 @@ directory. If `status.submodulesummary` is set to a non zero number or true (identical to -1 or an unlimited number), the submodule summary will be enabled for the long format and a summary of commits for modified submodules will be -shown (see --summary-limit option of linkgit:git-submodule[1]). +shown (see --summary-limit option of linkgit:git-submodule[1]). Please note +that the summary output from the status command will be suppressed for all +submodules when `diff.ignoreSubmodules` is set to 'all' or only for those +submodules where `submodule.<name>.ignore=all`. To also view the summary for +ignored submodules you can either use the --ignore-submodules=dirty command +line option or the 'git submodule summary' command, which shows a similar +output but does not honor these settings. SEE ALSO -------- diff --git a/Documentation/git-stripspace.txt b/Documentation/git-stripspace.txt index b78f031cd..c87bfcb67 100644 --- a/Documentation/git-stripspace.txt +++ b/Documentation/git-stripspace.txt @@ -3,26 +3,89 @@ git-stripspace(1) NAME ---- -git-stripspace - Filter out empty lines +git-stripspace - Remove unnecessary whitespace SYNOPSIS -------- [verse] -'git stripspace' [-s | --strip-comments] < <stream> +'git stripspace' [-s | --strip-comments] < input DESCRIPTION ----------- -Remove multiple empty lines, and empty lines at beginning and end. + +Clean the input in the manner used by Git for text such as commit +messages, notes, tags and branch descriptions. + +With no arguments, this will: + +- remove trailing whitespace from all lines +- collapse multiple consecutive empty lines into one empty line +- remove empty lines from the beginning and end of the input +- add a missing '\n' to the last line if necessary. + +In the case where the input consists entirely of whitespace characters, no +output will be produced. + +*NOTE*: This is intended for cleaning metadata, prefer the `--whitespace=fix` +mode of linkgit:git-apply[1] for correcting whitespace of patches or files in +the repository. OPTIONS ------- -s:: --strip-comments:: - In addition to empty lines, also strip lines starting with '#'. + Skip and remove all lines starting with comment character (default '#'). + +-c:: +--comment-lines:: + Prepend comment character and blank to each line. Lines will automatically + be terminated with a newline. On empty lines, only the comment character + will be prepended. + +EXAMPLES +-------- -<stream>:: - Byte stream to act on. +Given the following noisy input with '$' indicating the end of a line: + +-------- +|A brief introduction $ +| $ +|$ +|A new paragraph$ +|# with a commented-out line $ +|explaining lots of stuff.$ +|$ +|# An old paragraph, also commented-out. $ +| $ +|The end.$ +| $ +--------- + +Use 'git stripspace' with no arguments to obtain: + +-------- +|A brief introduction$ +|$ +|A new paragraph$ +|# with a commented-out line$ +|explaining lots of stuff.$ +|$ +|# An old paragraph, also commented-out.$ +|$ +|The end.$ +--------- + +Use 'git stripspace --strip-comments' to obtain: + +-------- +|A brief introduction$ +|$ +|A new paragraph$ +|explaining lots of stuff.$ +|$ +|The end.$ +--------- GIT --- diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 0ec85742d..bfef8a0c6 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -9,13 +9,16 @@ git-submodule - Initialize, update or inspect submodules SYNOPSIS -------- [verse] -'git submodule' [--quiet] add [-b branch] [-f|--force] - [--reference <repository>] [--] <repository> [<path>] +'git submodule' [--quiet] add [-b <branch>] [-f|--force] [--name <name>] + [--reference <repository>] [--depth <depth>] [--] <repository> [<path>] 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...] 'git submodule' [--quiet] init [--] [<path>...] -'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase] - [--reference <repository>] [--merge] [--recursive] [--] [<path>...] -'git submodule' [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...] +'git submodule' [--quiet] deinit [-f|--force] [--] <path>... +'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] + [-f|--force] [--rebase] [--reference <repository>] [--depth <depth>] + [--merge] [--recursive] [--] [<path>...] +'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>] + [commit] [--] [<path>...] 'git submodule' [--quiet] foreach [--recursive] <command> 'git submodule' [--quiet] sync [--] [<path>...] @@ -42,9 +45,9 @@ if you choose to go that route. Submodules are composed from a so-called `gitlink` tree entry in the main repository that refers to a particular commit object within the inner repository that is completely separate. -A record in the `.gitmodules` file at the root of the source -tree assigns a logical name to the submodule and describes -the default URL the submodule shall be cloned from. +A record in the `.gitmodules` (see linkgit:gitmodules[5]) file at the +root of the source tree assigns a logical name to the submodule and +describes the default URL the submodule shall be cloned from. The logical name can be used for overriding this URL within your local repository configuration (see 'submodule init'). @@ -74,18 +77,25 @@ argument <path> is the relative location for the cloned submodule to exist in the superproject. If <path> is not given, the "humanish" part of the source repository is used ("repo" for "/path/to/repo.git" and "foo" for "host.xz:foo/.git"). +The <path> is also used as the submodule's logical name in its +configuration entries unless `--name` is used to specify a logical name. + <repository> is the URL of the new submodule's origin repository. This may be either an absolute URL, or (if it begins with ./ or ../), the location relative to the superproject's origin -repository. If the superproject doesn't have an origin configured +repository (Please note that to specify a repository 'foo.git' +which is located right next to a superproject 'bar.git', you'll +have to use '../foo.git' instead of './foo.git' - as one might expect +when following the rules for relative URLs - because the evaluation +of relative URLs in Git is identical to that of relative directories). +If the superproject doesn't have an origin configured the superproject is its own authoritative upstream and the current working directory is used instead. + <path> is the relative location for the cloned submodule to exist in the superproject. If <path> does not exist, then the submodule is created by cloning from the named URL. If <path> does -exist and is already a valid git repository, then this is added +exist and is already a valid Git repository, then this is added to the changeset without cloning. This second form is provided to ease creating a new submodule from scratch, and presumes the user will later push the submodule to the given URL. @@ -106,14 +116,22 @@ status:: initialized, `+` if the currently checked out submodule commit does not match the SHA-1 found in the index of the containing repository and `U` if the submodule has merge conflicts. - This command is the default command for 'git submodule'. + -If '--recursive' is specified, this command will recurse into nested +If `--recursive` is specified, this command will recurse into nested submodules, and show their status as well. ++ +If you are only interested in changes of the currently initialized +submodules with respect to the commit recorded in the index or the HEAD, +linkgit:git-status[1] and linkgit:git-diff[1] will provide that information +too (and can also report changes to a submodule's work tree). init:: - Initialize the submodules, i.e. register each submodule name - and url found in .gitmodules into .git/config. + Initialize the submodules recorded in the index (which were + added and committed elsewhere) by copying submodule + names and urls from .gitmodules to .git/config. + Optional <path> arguments limit which submodules will be initialized. + It will also copy the value of `submodule.$name.update` into + .git/config. The key used in .git/config is `submodule.$name.url`. This command does not alter existing information in .git/config. You can then customize the submodule clone URLs in .git/config @@ -122,29 +140,53 @@ init:: the explicit 'init' step if you do not intend to customize any submodule locations. +deinit:: + Unregister the given submodules, i.e. remove the whole + `submodule.$name` section from .git/config together with their work + tree. Further calls to `git submodule update`, `git submodule foreach` + and `git submodule sync` will skip any unregistered submodules until + they are initialized again, so use this command if you don't want to + have a local checkout of the submodule in your work tree anymore. If + you really want to remove a submodule from the repository and commit + that use linkgit:git-rm[1] instead. ++ +If `--force` is specified, the submodule's work tree will be removed even if +it contains local modifications. + update:: Update the registered submodules, i.e. clone missing submodules and checkout the commit specified in the index of the containing repository. - This will make the submodules HEAD be detached unless '--rebase' or - '--merge' is specified or the key `submodule.$name.update` is set to - `rebase` or `merge`. + This will make the submodules HEAD be detached unless `--rebase` or + `--merge` is specified or the key `submodule.$name.update` is set to + `rebase`, `merge` or `none`. `none` can be overridden by specifying + `--checkout`. Setting the key `submodule.$name.update` to `!command` + will cause `command` to be run. `command` can be any arbitrary shell + command that takes a single argument, namely the sha1 to update to. + If the submodule is not yet initialized, and you just want to use the setting as stored in .gitmodules, you can automatically initialize the -submodule with the --init option. +submodule with the `--init` option. + -If '--recursive' is specified, this command will recurse into the +If `--recursive` is specified, this command will recurse into the registered submodules, and update any nested submodules within. ++ +If `--force` is specified, the submodule will be checked out (using +`git checkout --force` if appropriate), even if the commit specified in the +index of the containing repository already matches the commit checked out in +the submodule. summary:: Show commit summary between the given commit (defaults to HEAD) and working tree/index. For a submodule in question, a series of commits in the submodule between the given super project commit and the - index or working tree (switched by --cached) are shown. If the option - --files is given, show the series of commits in the submodule between + index or working tree (switched by `--cached`) are shown. If the option + `--files` is given, show the series of commits in the submodule between the index of the super project and the working tree of the submodule - (this option doesn't allow to use the --cached option or to provide an + (this option doesn't allow to use the `--cached` option or to provide an explicit commit). ++ +Using the `--submodule=log` option with linkgit:git-diff[1] will provide that +information too. foreach:: Evaluates an arbitrary shell command in each checked out submodule. @@ -155,9 +197,9 @@ foreach:: superproject, $sha1 is the commit as recorded in the superproject, and $toplevel is the absolute path to the top-level of the superproject. Any submodules defined in the superproject but not checked out are - ignored by this command. Unless given --quiet, foreach prints the name + ignored by this command. Unless given `--quiet`, foreach prints the name of each submodule before evaluating the command. - If --recursive is given, submodules are traversed recursively (i.e. + If `--recursive` is given, submodules are traversed recursively (i.e. the given shell command is evaluated in nested submodules as well). A non-zero return from the command in any submodule causes the processing to terminate. This can be overridden by adding '|| :' @@ -170,7 +212,7 @@ commit for each submodule. sync:: Synchronizes submodules' remote URL configuration setting to the value specified in .gitmodules. It will only affect those - submodules which already have an url entry in .git/config (that is the + submodules which already have a URL entry in .git/config (that is the case when they are initialized or freshly added). This is useful when submodule URLs change upstream and you need to update your local repositories accordingly. @@ -187,13 +229,19 @@ OPTIONS -b:: --branch:: Branch of repository to add as submodule. + The name of the branch is recorded as `submodule.<path>.branch` in + `.gitmodules` for `update --remote`. -f:: --force:: - This option is only valid for add and update commands. + This option is only valid for add, deinit and update commands. When running add, allow adding an otherwise ignored submodule path. + When running deinit the submodule work trees will be removed even if + they contain local changes. When running update, throw away local changes in submodules when - switching to a different commit. + switching to a different commit; and always run a checkout operation + in the submodule, even if the commit listed in the index of the + containing repository matches the commit checked out in the submodule. --cached:: This option is only valid for status and summary commands. These @@ -213,6 +261,27 @@ OPTIONS (the default). This limit only applies to modified submodules. The size is always limited to 1 for added/deleted/typechanged submodules. +--remote:: + This option is only valid for the update command. Instead of using + the superproject's recorded SHA-1 to update the submodule, use the + status of the submodule's remote-tracking branch. The remote used + is branch's remote (`branch.<name>.remote`), defaulting to `origin`. + The remote branch used defaults to `master`, but the branch name may + be overridden by setting the `submodule.<name>.branch` option in + either `.gitmodules` or `.git/config` (with `.git/config` taking + precedence). ++ +This works for any of the supported update procedures (`--checkout`, +`--rebase`, etc.). The only change is the source of the target SHA-1. +For example, `submodule update --remote --merge` will merge upstream +submodule changes into the submodules, while `submodule update +--merge` will merge superproject gitlink changes into the submodules. ++ +In order to ensure a current tracking branch state, `update --remote` +fetches the submodule's remote repository before calculating the +SHA-1. If you don't want to fetch, you should use `submodule update +--remote --no-fetch`. + -N:: --no-fetch:: This option is only valid for the update command. @@ -237,13 +306,23 @@ OPTIONS If the key `submodule.$name.update` is set to `rebase`, this option is implicit. +--init:: + This option is only valid for the update command. + Initialize all submodules for which "git submodule init" has not been + called so far before updating. + +--name:: + This option is only valid for the add command. It sets the submodule's + name to the given string instead of defaulting to its path. The name + must be valid as a directory name and may not end with a '/'. + --reference <repository>:: This option is only valid for add and update commands. These commands sometimes need to clone a remote repository. In this case, this option will be passed to the linkgit:git-clone[1] command. + *NOTE*: Do *not* use this option unless you have read the note -for linkgit:git-clone[1]'s --reference and --shared options carefully. +for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully. --recursive:: This option is only valid for foreach, update and status commands. @@ -251,6 +330,12 @@ for linkgit:git-clone[1]'s --reference and --shared options carefully. only in the submodules of the current repo, but also in any nested submodules inside those submodules (and so on). +--depth:: + This option is valid for add and update commands. Create a 'shallow' + clone with a history truncated to the specified number of revisions. + See linkgit:git-clone[1] + + <path>...:: Paths to submodule(s). When specified this will restrict the command to only operate on the submodules found at the specified paths. diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index ed5eca1fc..30c5ee256 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -3,7 +3,7 @@ git-svn(1) NAME ---- -git-svn - Bidirectional operation between a Subversion repository and git +git-svn - Bidirectional operation between a Subversion repository and Git SYNOPSIS -------- @@ -12,8 +12,8 @@ SYNOPSIS DESCRIPTION ----------- -'git svn' is a simple conduit for changesets between Subversion and git. -It provides a bidirectional flow of changes between a Subversion and a git +'git svn' is a simple conduit for changesets between Subversion and Git. +It provides a bidirectional flow of changes between a Subversion and a Git repository. 'git svn' can track a standard Subversion repository, @@ -21,15 +21,15 @@ following the common "trunk/branches/tags" layout, with the --stdlayout option. It can also follow branches and tags in any layout with the -T/-t/-b options (see options to 'init' below, and also the 'clone' command). -Once tracking a Subversion repository (with any of the above methods), the git +Once tracking a Subversion repository (with any of the above methods), the Git repository can be updated from Subversion by the 'fetch' command and -Subversion updated from git by the 'dcommit' command. +Subversion updated from Git by the 'dcommit' command. COMMANDS -------- 'init':: - Initializes an empty git repository with additional + Initializes an empty Git repository with additional metadata directories for 'git svn'. The Subversion URL may be specified as a command-line argument, or as full URL arguments to -T/-t/-b. Optionally, the target @@ -79,12 +79,29 @@ COMMANDS trailing slash, so be sure you include one in the argument if that is what you want. If --branches/-b is specified, the prefix must include a trailing slash. - Setting a prefix is useful if you wish to track multiple - projects that share a common repository. + Setting a prefix (with a trailing slash) is strongly + encouraged in any case, as your SVN-tracking refs will + then be located at "refs/remotes/$prefix/*", which is + compatible with Git's own remote-tracking ref layout + (refs/remotes/$remote/*). Setting a prefix is also useful + if you wish to track multiple projects that share a common + repository. ++ +NOTE: In Git v2.0, the default prefix will CHANGE from "" (no prefix) +to "origin/". This is done to put SVN-tracking refs at +"refs/remotes/origin/*" instead of "refs/remotes/*", and make them +more compatible with how Git's own remote-tracking refs are organized +(i.e. refs/remotes/$remote/*). You can enjoy the same benefits today, +by using the --prefix option. + --ignore-paths=<regex>;; When passed to 'init' or 'clone' this regular expression will be preserved as a config key. See 'fetch' for a description of '--ignore-paths'. +--include-paths=<regex>;; + When passed to 'init' or 'clone' this regular expression will + be preserved as a config key. See 'fetch' for a description + of '--include-paths'. --no-minimize-url;; When tracking multiple directories (using --stdlayout, --branches, or --tags options), git svn will attempt to connect @@ -100,19 +117,22 @@ COMMANDS 'fetch':: Fetch unfetched revisions from the Subversion remote we are tracking. The name of the [svn-remote "..."] section in the - .git/config file may be specified as an optional command-line - argument. + $GIT_DIR/config file may be specified as an optional + command-line argument. ++ +This automatically updates the rev_map if needed (see +'$GIT_DIR/svn/\*\*/.rev_map.*' in the FILES section below for details). --localtime;; - Store Git commit times in the local timezone instead of UTC. This + Store Git commit times in the local time zone instead of UTC. This makes 'git log' (even without --date=local) show the same times - that `svn log` would in the local timezone. + that `svn log` would in the local time zone. + This doesn't interfere with interoperating with the Subversion repository you cloned from, but if you wish for your local Git repository to be able to interoperate with someone else's local Git repository, either don't use this option or you should both use it in -the same local timezone. +the same local time zone. --parent;; Fetch only from the SVN parent of the current HEAD. @@ -146,6 +166,21 @@ Skip "branches" and "tags" of first level directories;; ------------------------------------------------------------------------ -- +--include-paths=<regex>;; + This allows one to specify a Perl regular expression that will + cause the inclusion of only matching paths from checkout from SVN. + The '--include-paths' option should match for every 'fetch' + (including automatic fetches due to 'clone', 'dcommit', + 'rebase', etc) on a given repository. '--ignore-paths' takes + precedence over '--include-paths'. + +--log-window-size=<n>;; + Fetch <n> log entries per request when scanning Subversion history. + The default is 100. For very large Subversion repositories, larger + values may be needed for 'clone'/'fetch' to complete in reasonable + time. But overly large values may lead to higher memory usage and + request timeouts. + 'clone':: Runs 'init' and 'fetch'. It will automatically create a directory based on the basename of the URL passed to it; @@ -157,6 +192,17 @@ Skip "branches" and "tags" of first level directories;; affecting the working tree; and the 'rebase' command will be able to update the working tree with the latest changes. +--preserve-empty-dirs;; + Create a placeholder file in the local Git repository for each + empty directory fetched from Subversion. This includes directories + that become empty by removing all entries in the Subversion + repository (but not the directory itself). The placeholder files + are also tracked and removed when no longer necessary. + +--placeholder-filename=<filename>;; + Set the name of placeholder files created by --preserve-empty-dirs. + Default: ".gitignore" + 'rebase':: This fetches revisions from the SVN parent of the current HEAD and rebases the current (uncommitted to SVN) work against it. @@ -171,6 +217,9 @@ accept. However, '--fetch-all' only fetches from the current + Like 'git rebase'; this requires that the working tree be clean and have no uncommitted changes. ++ +This automatically updates the rev_map if needed (see +'$GIT_DIR/svn/\*\*/.rev_map.*' in the FILES section below for details). -l;; --local;; @@ -178,18 +227,16 @@ and have no uncommitted changes. last fetched commit from the upstream SVN. 'dcommit':: - Commit each diff from a specified head directly to the SVN + Commit each diff from the current branch directly to the SVN repository, and then rebase or reset (depending on whether or not there is a diff between SVN and head). This will create - a revision in SVN for each commit in git. - It is recommended that you run 'git svn' fetch and rebase (not - pull or merge) your commits against the latest changes in the - SVN repository. - An optional revision or branch argument may be specified, and - causes 'git svn' to do all work on that revision/branch - instead of HEAD. - This is advantageous over 'set-tree' (below) because it produces - cleaner, more linear history. + a revision in SVN for each commit in Git. ++ +When an optional Git branch name (or a Git commit object name) +is specified as an argument, the subcommand works on the specified +branch, not on the current branch. ++ +Use of 'dcommit' is preferred to 'set-tree' (below). + --no-rebase;; After committing, do not rebase or reset. @@ -211,8 +258,25 @@ discouraged. Add the given merge information during the dcommit (e.g. `--mergeinfo="/branches/foo:1-10"`). All svn server versions can store this information (as a property), and svn clients starting from - version 1.5 can make use of it. 'git svn' currently does not use it - and does not set it automatically. + version 1.5 can make use of it. To specify merge information from multiple + branches, use a single space character between the branches + (`--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"`) ++ +[verse] +config key: svn.pushmergeinfo ++ +This option will cause git-svn to attempt to automatically populate the +svn:mergeinfo property in the SVN repository when possible. Currently, this can +only be done when dcommitting non-fast-forward merges where all parents but the +first have already been pushed into SVN. + +--interactive;; + Ask the user to confirm that a patch set should actually be sent to SVN. + For each patch, one may answer "yes" (accept this patch), "no" (discard this + patch), "all" (accept all patches), or "quit". + + + 'git svn dcommit' returns immediately if answer is "no" or "quit", without + committing anything to SVN. 'branch':: Create a branch in the SVN repository. @@ -226,13 +290,15 @@ discouraged. Create a tag by using the tags_subdir instead of the branches_subdir specified during git svn init. --d;; ---destination;; +-d<path>;; +--destination=<path>;; + If more than one --branches (or --tags) option was given to the 'init' or 'clone' command, you must provide the location of the branch (or - tag) you wish to create in the SVN repository. The value of this - option must match one of the paths specified by a --branches (or - --tags) option. You can see these paths with the commands + tag) you wish to create in the SVN repository. <path> specifies which + path to use to create the branch or tag and should match the pattern + on the left-hand side of one of the configured branches or tags + refspecs. You can see these refspecs with the commands + git config --get-all svn-remote.<name>.branches git config --get-all svn-remote.<name>.tags @@ -253,6 +319,11 @@ where <name> is the name of the SVN repository as specified by the -R option to git config --get-all svn-remote.<name>.commiturl + +--parents;; + Create parent folders. This parameter is equivalent to the parameter + --parents on svn cp commands and is useful for non-standard repository + layouts. + 'tag':: Create a tag in the SVN repository. This is a shorthand for 'branch -t'. @@ -283,7 +354,7 @@ New features: + -- --show-commit;; - shows the git commit sha1, as well + shows the Git commit sha1, as well --oneline;; our version of --pretty=oneline -- @@ -295,24 +366,34 @@ environment). This command has the same behaviour. Any other arguments are passed directly to 'git log' 'blame':: - Show what revision and author last modified each line of a file. The - output of this mode is format-compatible with the output of - `svn blame' by default. Like the SVN blame command, - local uncommitted changes in the working copy are ignored; - the version of the file in the HEAD revision is annotated. Unknown - arguments are passed directly to 'git blame'. + Show what revision and author last modified each line of a file. The + output of this mode is format-compatible with the output of + `svn blame' by default. Like the SVN blame command, + local uncommitted changes in the working tree are ignored; + the version of the file in the HEAD revision is annotated. Unknown + arguments are passed directly to 'git blame'. + --git-format;; Produce output in the same format as 'git blame', but with - SVN revision numbers instead of git commit hashes. In this mode, + SVN revision numbers instead of Git commit hashes. In this mode, changes that haven't been committed to SVN (including local working-copy edits) are shown as revision 0. 'find-rev':: When given an SVN revision number of the form 'rN', returns the - corresponding git commit hash (this can optionally be followed by a + corresponding Git commit hash (this can optionally be followed by a tree-ish to specify which branch should be searched). When given a tree-ish, returns the corresponding SVN revision number. ++ +--before;; + Don't require an exact match if given an SVN revision, instead find + the commit corresponding to the state of the SVN repository (on the + current branch) at the specified revision. ++ +--after;; + Don't require an exact match if given an SVN revision; if there is + not an exact match return the closest match searching forward in the + history. 'set-tree':: You should consider using 'dcommit' instead of this command. @@ -335,7 +416,7 @@ Any other arguments are passed directly to 'git log' the $GIT_DIR/info/exclude file. 'mkdirs':: - Attempts to recreate empty directories that core git cannot track + Attempts to recreate empty directories that core Git cannot track based on information in $GIT_DIR/svn/<refname>/unhandled.log files. Empty directories are automatically recreated when using "git svn clone" and "git svn rebase", so "mkdirs" is intended @@ -373,8 +454,8 @@ Any other arguments are passed directly to 'git log' specific revision. 'gc':: - Compress $GIT_DIR/svn/<refname>/unhandled.log files in .git/svn - and remove $GIT_DIR/svn/<refname>index files in .git/svn. + Compress $GIT_DIR/svn/<refname>/unhandled.log files and remove + $GIT_DIR/svn/<refname>/index files. 'reset':: Undoes the effects of 'fetch' back to the specified revision. @@ -387,9 +468,10 @@ Any other arguments are passed directly to 'git log' file cannot be ignored forever (with --ignore-paths) the only way to repair the repo is to use 'reset'. + -Only the rev_map and refs/remotes/git-svn are changed. Follow 'reset' -with a 'fetch' and then 'git reset' or 'git rebase' to move local -branches onto the new tree. +Only the rev_map and refs/remotes/git-svn are changed (see +'$GIT_DIR/svn/\*\*/.rev_map.*' in the FILES section below for details). +Follow 'reset' with a 'fetch' and then 'git reset' or 'git rebase' to +move local branches onto the new tree. -r <n>;; --revision=<n>;; @@ -467,9 +549,9 @@ order. Only the leading sha1 is read from each line, so + Remove directories from the SVN tree if there are no files left behind. SVN can version empty directories, and they are not -removed by default if there are no files left in them. git +removed by default if there are no files left in them. Git cannot version empty directories. Enabling this flag will make -the commit to SVN act like git. +the commit to SVN act like Git. + [verse] config key: svn.rmdir @@ -544,6 +626,8 @@ config key: svn.repackflags --merge:: -s<strategy>:: --strategy=<strategy>:: +-p:: +--preserve-merges:: These are only used with the 'dcommit' and 'rebase' commands. + Passed directly to 'git rebase' when using 'dcommit' if a @@ -554,7 +638,7 @@ Passed directly to 'git rebase' when using 'dcommit' if a This can be used with the 'dcommit', 'rebase', 'branch' and 'tag' commands. + -For 'dcommit', print out the series of git arguments that would show +For 'dcommit', print out the series of Git arguments that would show which diffs would be committed to SVN. + For 'rebase', display the local branch associated with the upstream svn @@ -565,14 +649,14 @@ For 'branch' and 'tag', display the urls that will be used for copying when creating the branch or tag. --use-log-author:: - When retrieving svn commits into git (as part of 'fetch', 'rebase', or + When retrieving svn commits into Git (as part of 'fetch', 'rebase', or 'dcommit' operations), look for the first `From:` or `Signed-off-by:` line in the log message and use that as the author string. --add-author-from:: - When committing to svn from git (as part of 'commit-diff', 'set-tree' or 'dcommit' + When committing to svn from Git (as part of 'commit-diff', 'set-tree' or 'dcommit' operations), if the existing log message doesn't already have a `From:` or `Signed-off-by:` line, append a `From:` line based on the - git commit's author string. If you use this, then `--use-log-author` + Git commit's author string. If you use this, then `--use-log-author` will retrieve a valid author string for all commits. @@ -593,10 +677,19 @@ ADVANCED OPTIONS Default: "svn" --follow-parent:: + This option is only relevant if we are tracking branches (using + one of the repository layout options --trunk, --tags, + --branches, --stdlayout). For each tracked branch, try to find + out where its revision was copied from, and set + a suitable parent in the first Git commit for the branch. This is especially helpful when we're tracking a directory - that has been moved around within the repository, or if we - started tracking a branch and never tracked the trunk it was - descended from. This feature is enabled by default, use + that has been moved around within the repository. If this + feature is disabled, the branches created by 'git svn' will all + be linear and not share any history, meaning that there will be + no information on where branches were branched off or merged. + However, following long/convoluted histories can take a long + time, so disabling this feature may speed up the cloning + process. This feature is enabled by default, use --no-follow-parent to disable it. + [verse] @@ -611,7 +704,7 @@ svn-remote.<name>.noMetadata:: + This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, -if you lose your .git/svn/**/.rev_map.* files, 'git svn' will not +if you lose your '$GIT_DIR/svn/\*\*/.rev_map.*' files, 'git svn' will not be able to rebuild them. + The 'git svn log' command will not work on repositories using @@ -620,7 +713,7 @@ option for (hopefully) obvious reasons. + This option is NOT recommended as it makes it difficult to track down old references to SVN revision numbers in existing documentation, bug -reports and archives. If you plan to eventually migrate from SVN to git +reports and archives. If you plan to eventually migrate from SVN to Git and are certain about dropping SVN history, consider linkgit:git-filter-branch[1] instead. filter-branch also allows reformatting of metadata for ease-of-reading and rewriting authorship @@ -660,7 +753,7 @@ svn-remote.<name>.rewriteUUID:: svn-remote.<name>.pushurl:: - Similar to git's 'remote.<name>.pushurl', this key is designed + Similar to Git's 'remote.<name>.pushurl', this key is designed to be used in cases where 'url' points to an SVN repository via a read-only transport, to provide an alternate read/write transport. It is assumed that both keys point to the same @@ -704,7 +797,8 @@ for rewriteRoot and rewriteUUID which can be used together. BASIC EXAMPLES -------------- -Tracking and contributing to the trunk of a Subversion-managed project: +Tracking and contributing to the trunk of a Subversion-managed project +(ignoring tags and branches): ------------------------------------------------------------------------ # Clone a repo (like git clone): @@ -713,15 +807,15 @@ Tracking and contributing to the trunk of a Subversion-managed project: cd trunk # You should be on master branch, double-check with 'git branch' git branch -# Do some work and commit locally to git: +# Do some work and commit locally to Git: git commit ... # Something is committed to SVN, rebase your local changes against the # latest changes in SVN: git svn rebase -# Now commit your changes (that were committed previously using git) to SVN, +# Now commit your changes (that were committed previously using Git) to SVN, # as well as automatically updating your working HEAD: git svn dcommit -# Append svn:ignore settings to the default git exclude file: +# Append svn:ignore settings to the default Git exclude file: git svn show-ignore >> .git/info/exclude ------------------------------------------------------------------------ @@ -729,15 +823,17 @@ Tracking and contributing to an entire Subversion-managed project (complete with a trunk, tags and branches): ------------------------------------------------------------------------ -# Clone a repo (like git clone): - git svn clone http://svn.example.com/project -T trunk -b branches -t tags +# Clone a repo with standard SVN directory layout (like git clone): + git svn clone http://svn.example.com/project --stdlayout --prefix svn/ +# Or, if the repo uses a non-standard directory layout: + git svn clone http://svn.example.com/project -T tr -b branch -t tag --prefix svn/ # View all branches and tags you have cloned: git branch -r # Create a new branch in SVN - git svn branch waldo + git svn branch waldo # Reset your master to trunk (or any other branch, replacing 'trunk' # with the appropriate name): - git reset --hard remotes/trunk + git reset --hard svn/trunk # You may only dcommit to one branch/tag/trunk at a time. The usage # of dcommit/rebase/show-ignore should be the same as above. ------------------------------------------------------------------------ @@ -751,7 +847,7 @@ have each person clone that repository with 'git clone': ------------------------------------------------------------------------ # Do the initial import on a server - ssh server "cd /pub && git svn clone http://svn.example.com/project + ssh server "cd /pub && git svn clone http://svn.example.com/project [options...]" # Clone locally - make sure the refs/remotes/ space matches the server mkdir project cd project @@ -759,31 +855,33 @@ have each person clone that repository with 'git clone': git remote add origin server:/pub/project git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*' git fetch -# Prevent fetch/pull from remote git server in the future, +# Prevent fetch/pull from remote Git server in the future, # we only want to use git svn for future updates git config --remove-section remote.origin # Create a local branch from one of the branches just fetched git checkout -b master FETCH_HEAD -# Initialize 'git svn' locally (be sure to use the same URL and -T/-b/-t options as were used on server) - git svn init http://svn.example.com/project +# Initialize 'git svn' locally (be sure to use the same URL and +# --stdlayout/-T/-b/-t/--prefix options as were used on server) + git svn init http://svn.example.com/project [options...] # Pull the latest changes from Subversion git svn rebase ------------------------------------------------------------------------ REBASE VS. PULL/MERGE --------------------- - -Originally, 'git svn' recommended that the 'remotes/git-svn' branch be -pulled or merged from. This is because the author favored +Prefer to use 'git svn rebase' or 'git rebase', rather than +'git pull' or 'git merge' to synchronize unintegrated commits with a 'git svn' +branch. Doing so will keep the history of unintegrated commits linear with +respect to the upstream SVN repository and allow the use of the preferred +'git svn dcommit' subcommand to push unintegrated commits back into SVN. + +Originally, 'git svn' recommended that developers pulled or merged from +the 'git svn' branch. This was because the author favored `git svn set-tree B` to commit a single head rather than the -`git svn set-tree A..B` notation to commit multiple commits. - -If you use `git svn set-tree A..B` to commit several diffs and you do -not have the latest remotes/git-svn merged into my-branch, you should -use `git svn rebase` to update your work branch instead of `git pull` or -`git merge`. `pull`/`merge` can cause non-linear history to be flattened -when committing into SVN, which can lead to merge commits reversing -previous commits in SVN. +`git svn set-tree A..B` notation to commit multiple commits. Use of +'git pull' or 'git merge' with `git svn set-tree A..B` will cause non-linear +history to be flattened when committing into SVN and this can lead to merge +commits unexpectedly reversing previous commits in SVN. MERGE TRACKING -------------- @@ -791,22 +889,68 @@ While 'git svn' can track copy history (including branches and tags) for repositories adopting a standard layout, it cannot yet represent merge history that happened inside git back upstream to SVN users. Therefore it is advised that -users keep history as linear as possible inside git to ease +users keep history as linear as possible inside Git to ease compatibility with SVN (see the CAVEATS section below). +HANDLING OF SVN BRANCHES +------------------------ +If 'git svn' is configured to fetch branches (and --follow-branches +is in effect), it sometimes creates multiple Git branches for one +SVN branch, where the additional branches have names of the form +'branchname@nnn' (with nnn an SVN revision number). These additional +branches are created if 'git svn' cannot find a parent commit for the +first commit in an SVN branch, to connect the branch to the history of +the other branches. + +Normally, the first commit in an SVN branch consists +of a copy operation. 'git svn' will read this commit to get the SVN +revision the branch was created from. It will then try to find the +Git commit that corresponds to this SVN revision, and use that as the +parent of the branch. However, it is possible that there is no suitable +Git commit to serve as parent. This will happen, among other reasons, +if the SVN branch is a copy of a revision that was not fetched by 'git +svn' (e.g. because it is an old revision that was skipped with +'--revision'), or if in SVN a directory was copied that is not tracked +by 'git svn' (such as a branch that is not tracked at all, or a +subdirectory of a tracked branch). In these cases, 'git svn' will still +create a Git branch, but instead of using an existing Git commit as the +parent of the branch, it will read the SVN history of the directory the +branch was copied from and create appropriate Git commits. This is +indicated by the message "Initializing parent: <branchname>". + +Additionally, it will create a special branch named +'<branchname>@<SVN-Revision>', where <SVN-Revision> is the SVN revision +number the branch was copied from. This branch will point to the newly +created parent commit of the branch. If in SVN the branch was deleted +and later recreated from a different version, there will be multiple +such branches with an '@'. + +Note that this may mean that multiple Git commits are created for a +single SVN revision. + +An example: in an SVN repository with a standard +trunk/tags/branches layout, a directory trunk/sub is created in r.100. +In r.200, trunk/sub is branched by copying it to branches/. 'git svn +clone -s' will then create a branch 'sub'. It will also create new Git +commits for r.100 through r.199 and use these as the history of branch +'sub'. Thus there will be two Git commits for each revision from r.100 +to r.199 (one containing trunk/, one containing trunk/sub/). Finally, +it will create a branch 'sub@200' pointing to the new parent commit of +branch 'sub' (i.e. the commit for r.200 and trunk/sub/). + CAVEATS ------- For the sake of simplicity and interoperating with Subversion, it is recommended that all 'git svn' users clone, fetch and dcommit directly from the SVN server, and avoid all 'git clone'/'pull'/'merge'/'push' -operations between git repositories and branches. The recommended -method of exchanging code between git branches and users is +operations between Git repositories and branches. The recommended +method of exchanging code between Git branches and users is 'git format-patch' and 'git am', or just 'dcommit'ing to the SVN repository. Running 'git merge' or 'git pull' is NOT recommended on a branch you plan to 'dcommit' from because Subversion users cannot see any -merges you've made. Furthermore, if you merge or pull from a git branch +merges you've made. Furthermore, if you merge or pull from a Git branch that is a mirror of an SVN branch, 'dcommit' may commit to the wrong branch. @@ -825,7 +969,7 @@ any 'git svn' metadata, or config. So repositories created and managed with using 'git svn' should use 'rsync' for cloning, if cloning is to be done at all. -Since 'dcommit' uses rebase internally, any git branches you 'git push' to +Since 'dcommit' uses rebase internally, any Git branches you 'git push' to before 'dcommit' on will require forcing an overwrite of the existing ref on the remote repository. This is generally considered bad practice, see the linkgit:git-push[1] documentation for details. @@ -835,12 +979,37 @@ already dcommitted. It is considered bad practice to --amend commits you've already pushed to a remote repository for other users, and dcommit with SVN is analogous to that. +When cloning an SVN repository, if none of the options for describing +the repository layout is used (--trunk, --tags, --branches, +--stdlayout), 'git svn clone' will create a Git repository with +completely linear history, where branches and tags appear as separate +directories in the working copy. While this is the easiest way to get a +copy of a complete repository, for projects with many branches it will +lead to a working copy many times larger than just the trunk. Thus for +projects using the standard directory structure (trunk/branches/tags), +it is recommended to clone with option '--stdlayout'. If the project +uses a non-standard structure, and/or if branches and tags are not +required, it is easiest to only clone one directory (typically trunk), +without giving any repository layout options. If the full history with +branches and tags is required, the options '--trunk' / '--branches' / +'--tags' must be used. + +When using the options for describing the repository layout (--trunk, +--tags, --branches, --stdlayout), please also specify the --prefix +option (e.g. '--prefix=origin/') to cause your SVN-tracking refs to be +placed at refs/remotes/origin/* rather than the default refs/remotes/*. +The former is more compatible with the layout of Git's "regular" +remote-tracking refs (refs/remotes/$remote/*), and may potentially +prevent similarly named SVN branches and Git remotes from clobbering +each other. In Git v2.0 the default prefix used (i.e. when no --prefix +is given) will change from "" (no prefix) to "origin/". + When using multiple --branches or --tags, 'git svn' does not automatically handle name collisions (for example, if two branches from different paths have the same name, or if a branch and a tag have the same name). In these cases, -use 'init' to set up your git repository then, before your first 'fetch', edit -the .git/config file so that the branches and tags are associated with -different name spaces. For example: +use 'init' to set up your Git repository then, before your first 'fetch', edit +the $GIT_DIR/config file so that the branches and tags are associated +with different name spaces. For example: branches = stable/*:refs/remotes/svn/stable/* branches = debug/*:refs/remotes/svn/debug/* @@ -851,18 +1020,24 @@ BUGS We ignore all SVN properties except svn:executable. Any unhandled properties are logged to $GIT_DIR/svn/<refname>/unhandled.log -Renamed and copied directories are not detected by git and hence not +Renamed and copied directories are not detected by Git and hence not tracked when committing to SVN. I do not plan on adding support for this as it's quite difficult and time-consuming to get working for all -the possible corner cases (git doesn't do it, either). Committing +the possible corner cases (Git doesn't do it, either). Committing renamed and copied files is fully supported if they're similar enough -for git to detect them. +for Git to detect them. + +In SVN, it is possible (though discouraged) to commit changes to a tag +(because a tag is just a directory copy, thus technically the same as a +branch). When cloning an SVN repository, 'git svn' cannot know if such a +commit to a tag will happen in the future. Thus it acts conservatively +and imports all SVN tags as branches, prefixing the tag name with 'tags/'. CONFIGURATION ------------- 'git svn' stores [svn-remote] configuration information in the -repository .git/config file. It is similar the core git +repository $GIT_DIR/config file. It is similar the core Git [remote] sections except 'fetch' keys do not accept glob arguments; but they are instead handled by the 'branches' and 'tags' keys. Since some SVN repositories are oddly @@ -891,14 +1066,46 @@ comma-separated list of names within braces. For example: [svn-remote "huge-project"] url = http://server.org/svn fetch = trunk/src:refs/remotes/trunk - branches = branches/{red,green}/src:refs/remotes/branches/* - tags = tags/{1.0,2.0}/src:refs/remotes/tags/* + branches = branches/{red,green}/src:refs/remotes/project-a/branches/* + tags = tags/{1.0,2.0}/src:refs/remotes/project-a/tags/* +------------------------------------------------------------------------ + +Multiple fetch, branches, and tags keys are supported: + +------------------------------------------------------------------------ +[svn-remote "messy-repo"] + url = http://server.org/svn + fetch = trunk/project-a:refs/remotes/project-a/trunk + fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo + branches = branches/server/*:refs/remotes/project-a/branches/* + branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/* + tags = tags/server/*:refs/remotes/project-a/tags/* +------------------------------------------------------------------------ + +Creating a branch in such a configuration requires disambiguating which +location to use using the -d or --destination flag: + +------------------------------------------------------------------------ +$ git svn branch -d branches/server release-2-3-0 ------------------------------------------------------------------------ Note that git-svn keeps track of the highest revision in which a branch or tag has appeared. If the subset of branches or tags is changed after -fetching, then .git/svn/.metadata must be manually edited to remove (or -reset) branches-maxRev and/or tags-maxRev as appropriate. +fetching, then $GIT_DIR/svn/.metadata must be manually edited to remove +(or reset) branches-maxRev and/or tags-maxRev as appropriate. + +FILES +----- +$GIT_DIR/svn/\*\*/.rev_map.*:: + Mapping between Subversion revision numbers and Git commit + names. In a repository where the noMetadata option is not set, + this can be rebuilt from the git-svn-id: lines that are at the + end of every commit (see the 'svn.noMetadata' section above for + details). ++ +'git svn fetch' and 'git svn rebase' automatically update the rev_map +if it is missing or not up to date. 'git svn reset' automatically +rewinds it. SEE ALSO -------- diff --git a/Documentation/git-symbolic-ref.txt b/Documentation/git-symbolic-ref.txt index 75b1ae506..ef68ad2b7 100644 --- a/Documentation/git-symbolic-ref.txt +++ b/Documentation/git-symbolic-ref.txt @@ -3,12 +3,14 @@ git-symbolic-ref(1) NAME ---- -git-symbolic-ref - Read and modify symbolic refs +git-symbolic-ref - Read, modify and delete symbolic refs SYNOPSIS -------- [verse] -'git symbolic-ref' [-q] [-m <reason>] <name> [<ref>] +'git symbolic-ref' [-m <reason>] <name> <ref> +'git symbolic-ref' [-q] [--short] <name> +'git symbolic-ref' --delete [-q] <name> DESCRIPTION ----------- @@ -20,6 +22,9 @@ argument to see which branch your working tree is on. Given two arguments, creates or updates a symbolic ref <name> to point at the given branch <ref>. +Given `--delete` and an additional argument, deletes the given +symbolic ref. + A symbolic ref is a regular file that stores a string that begins with `ref: refs/`. For example, your `.git/HEAD` is a regular file whose contents is `ref: refs/heads/master`. @@ -27,12 +32,20 @@ a regular file whose contents is `ref: refs/heads/master`. OPTIONS ------- +-d:: +--delete:: + Delete the symbolic ref <name>. + -q:: --quiet:: Do not issue an error message if the <name> is not a symbolic ref but a detached HEAD; instead exit with non-zero status silently. +--short:: + When showing the value of <name> as a symbolic ref, try to shorten the + value, e.g. from `refs/heads/master` to `master`. + -m:: Update the reflog for <name> with <reason>. This is valid only when creating or updating a symbolic ref. @@ -43,12 +56,9 @@ In the past, `.git/HEAD` was a symbolic link pointing at `refs/heads/master`. When we wanted to switch to another branch, we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we wanted to find out which branch we are on, we did `readlink .git/HEAD`. -This was fine, and internally that is what still happens by -default, but on platforms that do not have working symlinks, -or that do not have the `readlink(1)` command, this was a bit -cumbersome. On some platforms, `ln -sf` does not even work as -advertised (horrors). Therefore symbolic links are now deprecated -and symbolic refs are used by default. +But symbolic links are not entirely portable, so they are now +deprecated and symbolic refs (as described above) are used by +default. 'git symbolic-ref' will exit with status 0 if the contents of the symbolic ref were printed correctly, with status 1 if the requested diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index fb1c0ac69..404257df9 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -12,17 +12,18 @@ SYNOPSIS 'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <tagname> [<commit> | <object>] 'git tag' -d <tagname>... -'git tag' [-n[<num>]] -l [--contains <commit>] [<pattern>...] +'git tag' [-n[<num>]] -l [--contains <commit>] [--points-at <object>] + [--column[=<options>] | --no-column] [<pattern>...] + [<pattern>...] 'git tag' -v <tagname>... DESCRIPTION ----------- -Add a tag reference in `.git/refs/tags/`, unless `-d/-l/-v` is given +Add a tag reference in `refs/tags/`, unless `-d/-l/-v` is given to delete, list or verify tags. -Unless `-f` is given, the tag to be created must not yet exist in the -`.git/refs/tags/` directory. +Unless `-f` is given, the named tag must not yet exist. If one of `-a`, `-s`, or `-u <key-id>` is passed, the command creates a 'tag' object, and requires a tag message. Unless @@ -32,33 +33,51 @@ in the tag message. If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>` are absent, `-a` is implied. -Otherwise just a tag reference for the SHA1 object name of the commit object is +Otherwise just a tag reference for the SHA-1 object name of the commit object is created (i.e. a lightweight tag). A GnuPG signed tag object will be created when `-s` or `-u <key-id>` is used. When `-u <key-id>` is not used, the committer identity for the current user is used to find the -GnuPG key for signing. +GnuPG key for signing. The configuration variable `gpg.program` +is used to specify custom GnuPG binary. + +Tag objects (created with `-a`, `s`, or `-u`) are called "annotated" +tags; they contain a creation date, the tagger name and e-mail, a +tagging message, and an optional GnuPG signature. Whereas a +"lightweight" tag is simply a name for an object (usually a commit +object). + +Annotated tags are meant for release while lightweight tags are meant +for private or temporary object labels. For this reason, some git +commands for naming objects (like `git describe`) will ignore +lightweight tags by default. + OPTIONS ------- -a:: +--annotate:: Make an unsigned, annotated tag object -s:: - Make a GPG-signed tag, using the default e-mail address's key +--sign:: + Make a GPG-signed tag, using the default e-mail address's key. -u <key-id>:: - Make a GPG-signed tag, using the given key +--local-user=<key-id>:: + Make a GPG-signed tag, using the given key. -f:: --force:: Replace an existing tag with the given name (instead of failing) -d:: +--delete:: Delete existing tags with the given names. -v:: +--verify:: Verify the gpg signature of the given tag names. -n<num>:: @@ -69,16 +88,30 @@ OPTIONS If the tag is not annotated, the commit message is displayed instead. -l <pattern>:: +--list <pattern>:: List tags with names that match the given pattern (or all if no pattern is given). Running "git tag" without arguments also lists all tags. The pattern is a shell wildcard (i.e., matched using fnmatch(3)). Multiple patterns may be given; if any of them matches, the tag is shown. ---contains <commit>:: - Only list tags which contain the specified commit. +--column[=<options>]:: +--no-column:: + Display tag listing in columns. See configuration variable + column.tag for option syntax.`--column` and `--no-column` + without options are equivalent to 'always' and 'never' respectively. ++ +This option is only applicable when listing tags without annotation lines. + +--contains [<commit>]:: + Only list tags which contain the specified commit (HEAD if not + specified). + +--points-at <object>:: + Only list tags of the given object. -m <msg>:: +--message=<msg>:: Use the given tag message (instead of prompting). If multiple `-m` options are given, their values are concatenated as separate paragraphs. @@ -86,21 +119,35 @@ OPTIONS is given. -F <file>:: +--file=<file>:: Take the tag message from the given file. Use '-' to read the message from the standard input. Implies `-a` if none of `-a`, `-s`, or `-u <key-id>` is given. +--cleanup=<mode>:: + This option sets how the tag message is cleaned up. + The '<mode>' can be one of 'verbatim', 'whitespace' and 'strip'. The + 'strip' mode is default. The 'verbatim' mode does not change message at + all, 'whitespace' removes just leading/trailing whitespace lines and + 'strip' removes both whitespace and commentary. + <tagname>:: The name of the tag to create, delete, or describe. The new tag name must pass all checks defined by linkgit:git-check-ref-format[1]. Some of these checks may restrict the characters allowed in a tag name. +<commit>:: +<object>:: + The object that the new tag will refer to, usually a commit. + Defaults to HEAD. + + CONFIGURATION ------------- By default, 'git tag' in sign-with-default mode (-s) will use your -committer identity (of the form "Your Name <your@email.address>") to +committer identity (of the form "Your Name <\your@email.address>") to find a key. If you want to use a different default key, you can specify it in the repository configuration as follows: @@ -213,7 +260,7 @@ $ git pull git://git..../proj.git master In such a case, you do not want to automatically follow the other person's tags. -One important aspect of git is its distributed nature, which +One important aspect of Git is its distributed nature, which largely means there is no inherent "upstream" or "downstream" in the system. On the face of it, the above example might seem to indicate that the tag namespace is owned diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt deleted file mode 100644 index 95b135d8a..000000000 --- a/Documentation/git-tar-tree.txt +++ /dev/null @@ -1,82 +0,0 @@ -git-tar-tree(1) -=============== - -NAME ----- -git-tar-tree - Create a tar archive of the files in the named tree object - - -SYNOPSIS --------- -[verse] -'git tar-tree' [--remote=<repo>] <tree-ish> [ <base> ] - -DESCRIPTION ------------ -THIS COMMAND IS DEPRECATED. Use 'git archive' with `--format=tar` -option instead (and move the <base> argument to `--prefix=base/`). - -Creates a tar archive containing the tree structure for the named tree. -When <base> is specified it is added as a leading path to the files in the -generated tar archive. - -'git tar-tree' 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 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. -It can be extracted using 'git get-tar-commit-id'. - -OPTIONS -------- - -<tree-ish>:: - The tree or commit to produce tar archive for. If it is - the object name of a commit object. - -<base>:: - Leading path to the files in the resulting tar archive. - ---remote=<repo>:: - Instead of making a tar archive from local repository, - retrieve a tar archive from a remote repository. - -CONFIGURATION -------------- - -tar.umask:: - This variable can be used to restrict the permission bits of - tar archive entries. The default is 0002, which turns off the - world write bit. The special value "user" indicates that the - archiving user's umask will be used instead. See umask(2) for - details. - -EXAMPLES --------- -git tar-tree HEAD junk | (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 - `/var/tmp/junk` directory. - -git tar-tree v1.4.0 git-1.4.0 | gzip >git-1.4.0.tar.gz:: - - Create a tarball for v1.4.0 release. - -git tar-tree v1.4.0{caret}\{tree\} git-1.4.0 | gzip >git-1.4.0.tar.gz:: - - Create a tarball for v1.4.0 release, but without a - global extended pax header. - -git tar-tree --remote=example.com:git.git v1.4.0 >git-1.4.0.tar:: - - Get a tarball v1.4.0 from example.com. - -git tar-tree HEAD:Documentation/ git-docs > git-1.4.0-docs.tar:: - - Put everything in the current head's Documentation/ directory - into 'git-1.4.0-docs.tar', with the prefix 'git-docs/'. - -GIT ---- -Part of the linkgit:git[1] suite diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt index a96403cb8..78a0d955e 100644 --- a/Documentation/git-tools.txt +++ b/Documentation/git-tools.txt @@ -1,11 +1,11 @@ -A short git tools survey +A short Git tools survey ======================== Introduction ------------ -Apart from git contrib/ area there are some others third-party tools +Apart from Git contrib/ area there are some others third-party tools you may want to look. This document presents a brief summary of each tool and the corresponding @@ -17,26 +17,26 @@ Alternative/Augmentative Porcelains - *Cogito* (http://www.kernel.org/pub/software/scm/cogito/) - Cogito is a version control system layered on top of the git tree history + Cogito is a version control system layered on top of the Git tree history storage system. It aims at seamless user interface and ease of use, - providing generally smoother user experience than the "raw" Core GIT + providing generally smoother user experience than the "raw" Core Git itself and indeed many other version control systems. Cogito is no longer maintained as most of its functionality - is now in core GIT. + is now in core Git. - *pg* (http://www.spearce.org/category/projects/scm/pg/) - pg is a shell script wrapper around GIT to help the user manage a set of - patches to files. pg is somewhat like quilt or StGIT, but it does have a + pg is a shell script wrapper around Git to help the user manage a set of + patches to files. pg is somewhat like quilt or StGit, but it does have a slightly different feature set. - *StGit* (http://www.procode.org/stgit/) - Stacked GIT provides a quilt-like patch management functionality in the - GIT environment. You can easily manage your patches in the scope of GIT + Stacked Git provides a quilt-like patch management functionality in the + Git environment. You can easily manage your patches in the scope of Git until they get merged upstream. @@ -45,33 +45,33 @@ History Viewers - *gitk* (shipped with git-core) - gitk is a simple Tk GUI for browsing history of GIT repositories easily. + gitk is a simple Tk GUI for browsing history of Git repositories easily. - *gitview* (contrib/) - gitview is a GTK based repository browser for git + gitview is a GTK based repository browser for Git - *gitweb* (shipped with git-core) - GITweb provides full-fledged web interface for GIT repositories. + Gitweb provides full-fledged web interface for Git repositories. - *qgit* (http://digilander.libero.it/mcostalba/) - QGit is a git/StGIT GUI viewer built on Qt/C++. QGit could be used + QGit is a git/StGit GUI viewer built on Qt/C++. QGit could be used to browse history and directory tree, view annotated files, commit changes cherry picking single files or applying patches. - Currently it is the fastest and most feature rich among the git + Currently it is the fastest and most feature rich among the Git viewers and commit tools. - *tig* (http://jonas.nitro.dk/tig/) - tig by Jonas Fonseca is a simple git repository browser + tig by Jonas Fonseca is a simple Git repository browser written using ncurses. Basically, it just acts as a front-end for git-log and git-show/git-diff. Additionally, you can also - use it as a pager for git commands. + use it as a pager for Git commands. Foreign SCM interface @@ -80,20 +80,20 @@ Foreign SCM interface - *git-svn* (shipped with git-core) git-svn is a simple conduit for changesets between a single Subversion - branch and git. + branch and Git. - *quilt2git / git2quilt* (http://home-tj.org/wiki/index.php/Misc) These utilities convert patch series in a quilt repository and commit - series in git back and forth. + series in Git back and forth. - *hg-to-git* (contrib/) - hg-to-git converts a Mercurial repository into a git one, and + hg-to-git converts a Mercurial repository into a Git one, and preserves the full branch history in the process. hg-to-git can - also be used in an incremental way to keep the git repository + also be used in an incremental way to keep the Git repository in sync with the master Mercurial repository. @@ -102,14 +102,14 @@ Others - *(h)gct* (http://www.cyd.liu.se/users/~freku045/gct/) - Commit Tool or (h)gct is a GUI enabled commit tool for git and + Commit Tool or (h)gct is a GUI enabled commit tool for Git and Mercurial (hg). It allows the user to view diffs, select which files to committed (or ignored / reverted) write commit messages and perform the commit itself. - *git.el* (contrib/) - This is an Emacs interface for git. The user interface is modeled on + This is an Emacs interface for Git. The user interface is modelled on pcl-cvs. It has been developed on Emacs 21 and will probably need some tweaking to work on XEmacs. diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt index ff23494e7..12cb108b8 100644 --- a/Documentation/git-unpack-objects.txt +++ b/Documentation/git-unpack-objects.txt @@ -9,7 +9,7 @@ git-unpack-objects - Unpack objects from a packed archive SYNOPSIS -------- [verse] -'git unpack-objects' [-n] [-q] [-r] [--strict] <pack-file +'git unpack-objects' [-n] [-q] [-r] [--strict] < <pack-file> DESCRIPTION diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index a3081f4e2..e0a87029c 100644 --- a/Documentation/git-update-index.txt +++ b/Documentation/git-update-index.txt @@ -14,12 +14,12 @@ SYNOPSIS [--refresh] [-q] [--unmerged] [--ignore-missing] [(--cacheinfo <mode> <object> <file>)...] [--chmod=(+|-)x] - [--assume-unchanged | --no-assume-unchanged] - [--skip-worktree | --no-skip-worktree] + [--[no-]assume-unchanged] + [--[no-]skip-worktree] [--ignore-submodules] [--really-refresh] [--unresolve] [--again | -g] [--info-only] [--index-info] - [-z] [--stdin] + [-z] [--stdin] [--index-version <n>] [--verbose] [--] [<file>...] @@ -77,15 +77,14 @@ OPTIONS --chmod=(+|-)x:: Set the execute permissions on the updated files. ---assume-unchanged:: ---no-assume-unchanged:: +--[no-]assume-unchanged:: When these flags are specified, the object names recorded for the paths are not updated. Instead, these options set and unset the "assume unchanged" bit for the - paths. When the "assume unchanged" bit is on, git stops + paths. When the "assume unchanged" bit is on, Git stops checking the working tree files for possible modifications, so you need to manually unset the bit to - tell git when you change the working tree file. This is + tell Git when you change the working tree file. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs). @@ -102,8 +101,7 @@ you will need to handle the situation manually. Like '--refresh', but checks stat information unconditionally, without regard to the "assume unchanged" setting. ---skip-worktree:: ---no-skip-worktree:: +--[no-]skip-worktree:: When one of these flags is specified, the object name recorded for the paths are not updated. Instead, these options set and unset the "skip-worktree" bit for the paths. See @@ -143,6 +141,18 @@ you will need to handle the situation manually. --verbose:: Report what is being added and removed from index. +--index-version <n>:: + Write the resulting index out in the named on-disk format version. + Supported versions are 2, 3 and 4. The current default version is 2 + or 3, depending on whether extra features are used, such as + `git add -N`. ++ +Version 4 performs a simple pathname compression that reduces index +size by 30%-50% on large repositories, which results in faster load +time. Version 4 is relatively young (first released in in 1.8.0 in +October 2012). Other Git implementations such as JGit and libgit2 +may not support it yet. + -z:: Only meaningful with `--stdin` or `--index-info`; paths are separated with NUL character instead of LF. @@ -235,7 +245,7 @@ $ git update-index --index-info ------------ The first line of the input feeds 0 as the mode to remove the -path; the SHA1 does not matter as long as it is well formatted. +path; the SHA-1 does not matter as long as it is well formatted. Then the second and third line feeds stage 1 and stage 2 entries for that path. After the above, we would end up with this: @@ -249,18 +259,18 @@ $ git ls-files -s Using ``assume unchanged'' bit ------------------------------ -Many operations in git depend on your filesystem to have an +Many operations in Git depend on your filesystem to have an efficient `lstat(2)` implementation, so that `st_mtime` information for working tree files can be cheaply checked to see if the file contents have changed from the version recorded in the index file. Unfortunately, some filesystems have inefficient `lstat(2)`. If your filesystem is one of them, you can set "assume unchanged" bit to paths you have not changed to -cause git not to do this check. Note that setting this bit on a -path does not mean git will check the contents of the file to -see if it has changed -- it makes git to omit any checking and +cause Git not to do this check. Note that setting this bit on a +path does not mean Git will check the contents of the file to +see if it has changed -- it makes Git to omit any checking and assume it has *not* changed. When you make changes to working -tree files, you have to explicitly tell git about it by dropping +tree files, you have to explicitly tell Git about it by dropping "assume unchanged" bit, either before or after you modify them. In order to set "assume unchanged" bit, use `--assume-unchanged` @@ -270,7 +280,7 @@ have the "assume unchanged" bit set, use `git ls-files -v` The command looks at `core.ignorestat` configuration variable. When this is true, paths updated with `git update-index paths...` and -paths updated with other git commands that update both index and +paths updated with other Git commands that update both index and working tree (e.g. 'git apply --index', 'git checkout-index -u', and 'git read-tree -u') are automatically marked as "assume unchanged". Note that "assume unchanged" bit is *not* set if diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt index d377a3524..0a0a5512b 100644 --- a/Documentation/git-update-ref.txt +++ b/Documentation/git-update-ref.txt @@ -8,7 +8,7 @@ git-update-ref - Update the object name stored in a ref safely SYNOPSIS -------- [verse] -'git update-ref' [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>]) +'git update-ref' [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>] | --stdin [-z]) DESCRIPTION ----------- @@ -58,6 +58,58 @@ archive by creating a symlink tree). With `-d` flag, it deletes the named <ref> after verifying it still contains <oldvalue>. +With `--stdin`, update-ref reads instructions from standard input and +performs all modifications together. Specify commands of the form: + + update SP <ref> SP <newvalue> [SP <oldvalue>] LF + create SP <ref> SP <newvalue> LF + delete SP <ref> [SP <oldvalue>] LF + verify SP <ref> [SP <oldvalue>] LF + option SP <opt> LF + +Quote fields containing whitespace as if they were strings in C source +code. Alternatively, use `-z` to specify commands without quoting: + + update SP <ref> NUL <newvalue> NUL [<oldvalue>] NUL + create SP <ref> NUL <newvalue> NUL + delete SP <ref> NUL [<oldvalue>] NUL + verify SP <ref> NUL [<oldvalue>] NUL + option SP <opt> NUL + +Lines of any other format or a repeated <ref> produce an error. +Command meanings are: + +update:: + Set <ref> to <newvalue> after verifying <oldvalue>, if given. + Specify a zero <newvalue> to ensure the ref does not exist + after the update and/or a zero <oldvalue> to make sure the + ref does not exist before the update. + +create:: + Create <ref> with <newvalue> after verifying it does not + exist. The given <newvalue> may not be zero. + +delete:: + Delete <ref> after verifying it exists with <oldvalue>, if + given. If given, <oldvalue> may not be zero. + +verify:: + Verify <ref> against <oldvalue> but do not change it. If + <oldvalue> zero or missing, the ref must not exist. + +option:: + Modify behavior of the next command naming a <ref>. + The only valid option is `no-deref` to avoid dereferencing + a symbolic ref. + +Use 40 "0" or the empty string to specify a zero value, except that +with `-z` an empty <oldvalue> is considered missing. + +If all <ref>s can be locked with matching <oldvalue>s +simultaneously, all modifications are performed. Otherwise, no +modifications are performed. Note that while each individual +<ref> is updated or deleted atomically, a concurrent reader may +still see a subset of the modifications. Logging Updates --------------- @@ -73,7 +125,7 @@ in ref value. Log lines are formatted as: Where "oldsha1" is the 40 character hexadecimal value previously stored in <ref>, "newsha1" is the 40 character hexadecimal value of <newvalue> and "committer" is the committer's name, email address -and date in the standard GIT committer ident format. +and date in the standard Git committer ident format. Optionally with -m: diff --git a/Documentation/git-upload-archive.txt b/Documentation/git-upload-archive.txt index 4d52d3833..d09bbb52b 100644 --- a/Documentation/git-upload-archive.txt +++ b/Documentation/git-upload-archive.txt @@ -14,7 +14,7 @@ SYNOPSIS DESCRIPTION ----------- Invoked by 'git archive --remote' and sends a generated archive to the -other end over the git protocol. +other end over the Git protocol. This command is usually not invoked directly by the end user. The UI for the protocol is on the 'git archive' side, and the program pair diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt index a58e90ca8..0abc806ea 100644 --- a/Documentation/git-upload-pack.txt +++ b/Documentation/git-upload-pack.txt @@ -26,7 +26,7 @@ OPTIONS ------- --strict:: - Do not try <directory>/.git/ if <directory> is no git directory. + Do not try <directory>/.git/ if <directory> is no Git directory. --timeout=<n>:: Interrupt transfer after <n> seconds of inactivity. @@ -34,6 +34,10 @@ OPTIONS <directory>:: The repository to sync from. +SEE ALSO +-------- +linkgit:gitnamespaces[7] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt index 5317cc247..44ff9541d 100644 --- a/Documentation/git-var.txt +++ b/Documentation/git-var.txt @@ -3,7 +3,7 @@ git-var(1) NAME ---- -git-var - Show a git logical variable +git-var - Show a Git logical variable SYNOPSIS @@ -13,13 +13,13 @@ SYNOPSIS DESCRIPTION ----------- -Prints a git logical variable. +Prints a Git logical variable. OPTIONS ------- -l:: Cause the logical variables to be listed. In addition, all the - variables of the git configuration file .git/config are listed + variables of the Git configuration file .git/config are listed as well. (However, the configuration variables listing functionality is deprecated in favor of `git config -l`.) @@ -35,30 +35,29 @@ GIT_AUTHOR_IDENT:: The author of a piece of code. GIT_COMMITTER_IDENT:: - The person who put a piece of code into git. + The person who put a piece of code into Git. GIT_EDITOR:: - Text editor for use by git commands. The value is meant to be + Text editor for use by Git commands. The value is meant to be interpreted by the shell when it is used. Examples: `~/bin/vi`, `$SOME_ENVIRONMENT_VARIABLE`, `"C:\Program Files\Vim\gvim.exe" --nofork`. The order of preference is the `$GIT_EDITOR` environment variable, then `core.editor` configuration, then - `$VISUAL`, then `$EDITOR`, and then finally 'vi'. + `$VISUAL`, then `$EDITOR`, and then the default chosen at compile + time, which is usually 'vi'. +ifdef::git-default-editor[] + The build you are using chose '{git-default-editor}' as the default. +endif::git-default-editor[] GIT_PAGER:: - Text viewer for use by git commands (e.g., 'less'). The value + Text viewer for use by Git commands (e.g., 'less'). The value is meant to be interpreted by the shell. The order of preference is the `$GIT_PAGER` environment variable, then `core.pager` - configuration, then `$PAGER`, and then finally 'less'. - -Diagnostics ------------ -You don't exist. Go away!:: - The passwd(5) gecos field couldn't be read -Your parents must have hated you!:: - The passwd(5) gecos field is longer than a giant static buffer. -Your sysadmin must hate you!:: - The passwd(5) name field is longer than a giant static buffer. + configuration, then `$PAGER`, and then the default chosen at + compile time (usually 'less'). +ifdef::git-default-pager[] + The build you are using chose '{git-default-pager}' as the default. +endif::git-default-pager[] SEE ALSO -------- diff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt index cd230769f..526ba7be9 100644 --- a/Documentation/git-verify-pack.txt +++ b/Documentation/git-verify-pack.txt @@ -3,7 +3,7 @@ git-verify-pack(1) NAME ---- -git-verify-pack - Validate packed git archive files +git-verify-pack - Validate packed Git archive files SYNOPSIS @@ -14,7 +14,7 @@ SYNOPSIS DESCRIPTION ----------- -Reads given idx file for packed git archive created with the +Reads given idx file for packed Git archive created with the 'git pack-objects' command and verifies idx file and the corresponding pack file. @@ -40,11 +40,11 @@ OUTPUT FORMAT ------------- When specifying the -v option the format used is: - SHA1 type size size-in-pack-file offset-in-packfile + SHA-1 type size size-in-pack-file offset-in-packfile for objects that are not deltified in the pack, and - SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1 + SHA-1 type size size-in-packfile offset-in-packfile depth base-SHA-1 for objects that are deltified. diff --git a/Documentation/git-verify-tag.txt b/Documentation/git-verify-tag.txt index 5ff76e892..f88ba96f0 100644 --- a/Documentation/git-verify-tag.txt +++ b/Documentation/git-verify-tag.txt @@ -21,7 +21,7 @@ OPTIONS Print the contents of the tag object before validating it. <tag>...:: - SHA1 identifiers of git tag objects. + SHA-1 identifiers of Git tag objects. GIT --- diff --git a/Documentation/git-web--browse.txt b/Documentation/git-web--browse.txt index c2bc87bc6..2de575f5b 100644 --- a/Documentation/git-web--browse.txt +++ b/Documentation/git-web--browse.txt @@ -3,7 +3,7 @@ git-web{litdd}browse(1) NAME ---- -git-web--browse - git helper script to launch a web browser +git-web--browse - Git helper script to launch a web browser SYNOPSIS -------- @@ -34,6 +34,8 @@ The following browsers (or commands) are currently supported: * dillo * open (this is the default under Mac OS X GUI) * start (this is the default under MinGW) +* cygstart (this is the default under Cygwin) +* xdg-open Custom commands may also be specified. @@ -50,7 +52,7 @@ OPTIONS -c <conf.var>:: --config=<conf.var>:: - CONF.VAR is looked up in the git config files. If it's set, + CONF.VAR is looked up in the Git config files. If it's set, then its value specifies the browser that should be used. CONFIGURATION VARIABLES diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt index 99388bd37..8b63ceb00 100644 --- a/Documentation/git-whatchanged.txt +++ b/Documentation/git-whatchanged.txt @@ -13,52 +13,26 @@ SYNOPSIS DESCRIPTION ----------- -Shows commit logs and diff output each commit introduces. The -command internally invokes 'git rev-list' piped to -'git diff-tree', and takes command line options for both of -these commands. -This manual page describes only the most frequently used options. +Shows commit logs and diff output each commit introduces. +New users are encouraged to use linkgit:git-log[1] instead. The +`whatchanged` command is essentially the same as linkgit:git-log[1] +but defaults to show the raw format diff output and to skip merges. -OPTIONS -------- --p:: - Show textual diffs, instead of the git internal diff - output format that is useful only to tell the changed - paths and their nature of changes. +The command is kept primarily for historical reasons; fingers of +many people who learned Git long before `git log` was invented by +reading Linux kernel mailing list are trained to type it. --<n>:: - Limit output to <n> commits. - -<since>..<until>:: - Limit output to between the two named commits (bottom - exclusive, top inclusive). - --r:: - Show git internal diff output, but for the whole tree, - not just the top level. - --m:: - By default, differences for merge commits are not shown. - With this flag, show differences to that commit from all - of its parents. -+ -However, it is not very useful in general, although it -*is* useful on a file-by-file basis. - -include::pretty-options.txt[] - -include::pretty-formats.txt[] Examples -------- -git whatchanged -p v2.6.12.. include/scsi drivers/scsi:: +`git whatchanged -p v2.6.12.. include/scsi drivers/scsi`:: Show as patches the commits since version 'v2.6.12' that changed any file in the include/scsi or drivers/scsi subdirectories -git whatchanged --since="2 weeks ago" \-- gitk:: +`git whatchanged --since="2 weeks ago" -- gitk`:: Show the changes during the last two weeks to the file 'gitk'. The "--" is necessary to avoid confusion with the *branch* named diff --git a/Documentation/git.txt b/Documentation/git.txt index e6b64dbde..02bbc084b 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -9,11 +9,11 @@ git - the stupid content tracker SYNOPSIS -------- [verse] -'git' [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] - [-p|--paginate|--no-pager] [--no-replace-objects] - [--bare] [--git-dir=<path>] [--work-tree=<path>] - [-c <name>=<value>] - [--help] <command> [<args>] +'git' [--version] [--help] [-C <path>] [-c <name>=<value>] + [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] + [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] + [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] + <command> [<args>] DESCRIPTION ----------- @@ -22,28 +22,154 @@ unusually rich command set that provides both high-level operations and full access to internals. See linkgit:gittutorial[7] to get started, then see -link:everyday.html[Everyday Git] for a useful minimum set of commands, and -"man git-commandname" for documentation of each command. CVS users may -also want to read linkgit:gitcvs-migration[7]. See -the link:user-manual.html[Git User's Manual] for a more in-depth -introduction. +link:everyday.html[Everyday Git] for a useful minimum set of +commands. The link:user-manual.html[Git User's Manual] has a more +in-depth introduction. -The '<command>' is either a name of a Git command (see below) or an alias -as defined in the configuration file (see linkgit:git-config[1]). +After you mastered the basic concepts, you can come back to this +page to learn what commands Git offers. You can learn more about +individual Git commands with "git help command". linkgit:gitcli[7] +manual page gives you an overview of the command line command syntax. -Formatted and hyperlinked version of the latest git -documentation can be viewed at -`http://www.kernel.org/pub/software/scm/git/docs/`. +Formatted and hyperlinked version of the latest Git documentation +can be viewed at `http://git-htmldocs.googlecode.com/git/git.html`. ifdef::stalenotes[] [NOTE] ============ You are reading the documentation for the latest (possibly -unreleased) version of git, that is available from 'master' +unreleased) version of Git, that is available from 'master' branch of the `git.git` repository. Documentation for older releases are available here: +* link:v1.9.0/git.html[documentation for release 1.9.0] + +* release notes for + link:RelNotes/1.9.0.txt[1.9.0]. + +* link:v1.8.5.5/git.html[documentation for release 1.8.5.5] + +* release notes for + link:RelNotes/1.8.5.5.txt[1.8.5.5], + link:RelNotes/1.8.5.4.txt[1.8.5.4], + link:RelNotes/1.8.5.3.txt[1.8.5.3], + link:RelNotes/1.8.5.2.txt[1.8.5.2], + link:RelNotes/1.8.5.1.txt[1.8.5.1], + link:RelNotes/1.8.5.txt[1.8.5]. + +* link:v1.8.4.5/git.html[documentation for release 1.8.4.5] + +* release notes for + link:RelNotes/1.8.4.5.txt[1.8.4.5], + link:RelNotes/1.8.4.4.txt[1.8.4.4], + link:RelNotes/1.8.4.3.txt[1.8.4.3], + link:RelNotes/1.8.4.2.txt[1.8.4.2], + link:RelNotes/1.8.4.1.txt[1.8.4.1], + link:RelNotes/1.8.4.txt[1.8.4]. + +* link:v1.8.3.4/git.html[documentation for release 1.8.3.4] + +* release notes for + link:RelNotes/1.8.3.4.txt[1.8.3.4], + link:RelNotes/1.8.3.3.txt[1.8.3.3], + link:RelNotes/1.8.3.2.txt[1.8.3.2], + link:RelNotes/1.8.3.1.txt[1.8.3.1], + link:RelNotes/1.8.3.txt[1.8.3]. + +* link:v1.8.2.3/git.html[documentation for release 1.8.2.3] + +* release notes for + link:RelNotes/1.8.2.3.txt[1.8.2.3], + link:RelNotes/1.8.2.2.txt[1.8.2.2], + link:RelNotes/1.8.2.1.txt[1.8.2.1], + link:RelNotes/1.8.2.txt[1.8.2]. + +* link:v1.8.1.6/git.html[documentation for release 1.8.1.6] + +* release notes for + link:RelNotes/1.8.1.6.txt[1.8.1.6], + link:RelNotes/1.8.1.5.txt[1.8.1.5], + link:RelNotes/1.8.1.4.txt[1.8.1.4], + link:RelNotes/1.8.1.3.txt[1.8.1.3], + link:RelNotes/1.8.1.2.txt[1.8.1.2], + link:RelNotes/1.8.1.1.txt[1.8.1.1], + link:RelNotes/1.8.1.txt[1.8.1]. + +* link:v1.8.0.3/git.html[documentation for release 1.8.0.3] + +* release notes for + link:RelNotes/1.8.0.3.txt[1.8.0.3], + link:RelNotes/1.8.0.2.txt[1.8.0.2], + link:RelNotes/1.8.0.1.txt[1.8.0.1], + link:RelNotes/1.8.0.txt[1.8.0]. + +* link:v1.7.12.4/git.html[documentation for release 1.7.12.4] + +* release notes for + link:RelNotes/1.7.12.4.txt[1.7.12.4], + link:RelNotes/1.7.12.3.txt[1.7.12.3], + link:RelNotes/1.7.12.2.txt[1.7.12.2], + link:RelNotes/1.7.12.1.txt[1.7.12.1], + link:RelNotes/1.7.12.txt[1.7.12]. + +* link:v1.7.11.7/git.html[documentation for release 1.7.11.7] + +* release notes for + link:RelNotes/1.7.11.7.txt[1.7.11.7], + link:RelNotes/1.7.11.6.txt[1.7.11.6], + link:RelNotes/1.7.11.5.txt[1.7.11.5], + link:RelNotes/1.7.11.4.txt[1.7.11.4], + link:RelNotes/1.7.11.3.txt[1.7.11.3], + link:RelNotes/1.7.11.2.txt[1.7.11.2], + link:RelNotes/1.7.11.1.txt[1.7.11.1], + link:RelNotes/1.7.11.txt[1.7.11]. + +* link:v1.7.10.5/git.html[documentation for release 1.7.10.5] + +* release notes for + link:RelNotes/1.7.10.5.txt[1.7.10.5], + link:RelNotes/1.7.10.4.txt[1.7.10.4], + link:RelNotes/1.7.10.3.txt[1.7.10.3], + link:RelNotes/1.7.10.2.txt[1.7.10.2], + link:RelNotes/1.7.10.1.txt[1.7.10.1], + link:RelNotes/1.7.10.txt[1.7.10]. + +* link:v1.7.9.7/git.html[documentation for release 1.7.9.7] + +* release notes for + link:RelNotes/1.7.9.7.txt[1.7.9.7], + link:RelNotes/1.7.9.6.txt[1.7.9.6], + link:RelNotes/1.7.9.5.txt[1.7.9.5], + link:RelNotes/1.7.9.4.txt[1.7.9.4], + link:RelNotes/1.7.9.3.txt[1.7.9.3], + link:RelNotes/1.7.9.2.txt[1.7.9.2], + link:RelNotes/1.7.9.1.txt[1.7.9.1], + link:RelNotes/1.7.9.txt[1.7.9]. + +* link:v1.7.8.6/git.html[documentation for release 1.7.8.6] + +* release notes for + link:RelNotes/1.7.8.6.txt[1.7.8.6], + link:RelNotes/1.7.8.5.txt[1.7.8.5], + link:RelNotes/1.7.8.4.txt[1.7.8.4], + link:RelNotes/1.7.8.3.txt[1.7.8.3], + link:RelNotes/1.7.8.2.txt[1.7.8.2], + link:RelNotes/1.7.8.1.txt[1.7.8.1], + link:RelNotes/1.7.8.txt[1.7.8]. + +* link:v1.7.7.7/git.html[documentation for release 1.7.7.7] + +* release notes for + link:RelNotes/1.7.7.7.txt[1.7.7.7], + link:RelNotes/1.7.7.6.txt[1.7.7.6], + link:RelNotes/1.7.7.5.txt[1.7.7.5], + link:RelNotes/1.7.7.4.txt[1.7.7.4], + link:RelNotes/1.7.7.3.txt[1.7.7.3], + link:RelNotes/1.7.7.2.txt[1.7.7.2], + link:RelNotes/1.7.7.1.txt[1.7.7.1], + link:RelNotes/1.7.7.txt[1.7.7]. + * link:v1.7.6.6/git.html[documentation for release 1.7.6.6] * release notes for @@ -276,12 +402,12 @@ endif::stalenotes[] OPTIONS ------- --version:: - Prints the git suite version that the 'git' program came from. + Prints the Git suite version that the 'git' program came from. --help:: Prints the synopsis and a list of the most commonly used commands. If the option '--all' or '-a' is given then all - available commands are printed. If a git command is named this + available commands are printed. If a Git command is named this option will bring up the manual page for that command. + Other options are available to control how the manual page is @@ -289,6 +415,20 @@ displayed. See linkgit:git-help[1] for more information, because `git --help ...` is converted internally into `git help ...`. +-C <path>:: + Run as if git was started in '<path>' instead of the current working + directory. When multiple `-C` options are given, each subsequent + non-absolute `-C <path>` is interpreted relative to the preceding `-C + <path>`. ++ +This option affects options that expect path name like `--git-dir` and +`--work-tree` in that their interpretations of the path names would be +made relative to the working directory caused by the `-C` option. For +example the following invocations are equivalent: + + git --git-dir=a.git --work-tree=b -C c status + git --git-dir=c/a.git --work-tree=c/b status + -c <name>=<value>:: Pass a configuration parameter to the command. The value given will override values from configuration files. @@ -296,22 +436,22 @@ help ...`. 'git config' (subkeys separated by dots). --exec-path[=<path>]:: - Path to wherever your core git programs are installed. + Path to wherever your core Git programs are installed. This can also be controlled by setting the GIT_EXEC_PATH environment variable. If no path is given, 'git' will print the current setting and then exit. --html-path:: - Print the path, without trailing slash, where git's HTML + Print the path, without trailing slash, where Git's HTML documentation is installed and exit. --man-path:: Print the manpath (see `man(1)`) for the man pages for - this version of git and exit. + this version of Git and exit. --info-path:: Print the path where the Info files documenting this - version of git are installed and exit. + version of Git are installed and exit. -p:: --paginate:: @@ -321,7 +461,7 @@ help ...`. below). --no-pager:: - Do not pipe git output into a pager. + Do not pipe Git output into a pager. --git-dir=<path>:: Set the path to the repository. This can also be controlled by @@ -336,38 +476,45 @@ help ...`. variable (see core.worktree in linkgit:git-config[1] for a more detailed discussion). +--namespace=<path>:: + Set the Git namespace. See linkgit:gitnamespaces[7] for more + details. Equivalent to setting the `GIT_NAMESPACE` environment + variable. + --bare:: Treat the repository as a bare repository. If GIT_DIR environment is not set, it is set to the current working directory. --no-replace-objects:: - Do not use replacement refs to replace git objects. See + Do not use replacement refs to replace Git objects. See linkgit:git-replace[1] for more information. +--literal-pathspecs:: + Treat pathspecs literally (i.e. no globbing, no pathspec magic). + This is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment + variable to `1`. -FURTHER DOCUMENTATION ---------------------- - -See the references above to get started using git. The following is -probably more detail than necessary for a first-time user. +--glob-pathspecs:: + Add "glob" magic to all pathspec. This is equivalent to setting + the `GIT_GLOB_PATHSPECS` environment variable to `1`. Disabling + globbing on individual pathspecs can be done using pathspec + magic ":(literal)" -The link:user-manual.html#git-concepts[git concepts chapter of the -user-manual] and linkgit:gitcore-tutorial[7] both provide -introductions to the underlying git architecture. +--noglob-pathspecs:: + Add "literal" magic to all pathspec. This is equivalent to setting + the `GIT_NOGLOB_PATHSPECS` environment variable to `1`. Enabling + globbing on individual pathspecs can be done using pathspec + magic ":(glob)" -See linkgit:gitworkflows[7] for an overview of recommended workflows. - -See also the link:howto-index.html[howto] documents for some useful -examples. - -The internals are documented in the -link:technical/api-index.html[GIT API documentation]. +--icase-pathspecs:: + Add "icase" magic to all pathspec. This is equivalent to setting + the `GIT_ICASE_PATHSPECS` environment variable to `1`. GIT COMMANDS ------------ -We divide git into high level ("porcelain") commands and low level +We divide Git into high level ("porcelain") commands and low level ("plumbing") commands. High-level commands (porcelain) @@ -404,7 +551,7 @@ include::cmds-foreignscminterface.txt[] Low-level commands (plumbing) ----------------------------- -Although git includes its +Although Git includes its own porcelain layer, its low-level commands are sufficient to support development of alternative porcelains. Developers of such porcelains might start by reading about linkgit:git-update-index[1] and @@ -462,10 +609,9 @@ include::cmds-purehelpers.txt[] Configuration Mechanism ----------------------- -Starting from 0.99.9 (actually mid 0.99.8.GIT), `.git/config` file -is used to hold per-repository configuration options. It is a -simple text file modeled after `.ini` format familiar to some -people. Here is an example: +Git uses a simple text format to store customizations that are per +repository and are per user. Such a configuration file may look +like this: ------------ # @@ -480,13 +626,13 @@ people. Here is an example: ; user identity [user] name = "Junio C Hamano" - email = "junkio@twinsun.com" + email = "gitster@pobox.com" ------------ Various commands read from the configuration file and adjust their operation accordingly. See linkgit:git-config[1] for a -list. +list and more details about the configuration mechanism. Identifier Terminology @@ -525,7 +671,7 @@ Identifier Terminology Symbolic Identifiers -------------------- -Any git command accepting any <object> can also use the following +Any Git command accepting any <object> can also use the following symbolic notation: HEAD:: @@ -561,13 +707,13 @@ Please see linkgit:gitglossary[7]. Environment Variables --------------------- -Various git commands use the following environment variables: +Various Git commands use the following environment variables: -The git Repository +The Git Repository ~~~~~~~~~~~~~~~~~~ -These environment variables apply to 'all' core git commands. Nb: it +These environment variables apply to 'all' core Git commands. Nb: it is worth noting that they may be used/overridden by SCMS sitting above -git so take care if using Cogito etc. +Git so take care if using Cogito etc. 'GIT_INDEX_FILE':: This environment allows the specification of an alternate @@ -581,43 +727,53 @@ git so take care if using Cogito etc. directory is used. 'GIT_ALTERNATE_OBJECT_DIRECTORIES':: - Due to the immutable nature of git objects, old objects can be + Due to the immutable nature of Git objects, old objects can be archived into shared, read-only directories. This variable specifies a ":" separated (on Windows ";" separated) list - of git object directories which can be used to search for git + of Git object directories which can be used to search for Git objects. New objects will not be written to these directories. 'GIT_DIR':: If the 'GIT_DIR' environment variable is set then it specifies a path to use instead of the default `.git` for the base of the repository. + The '--git-dir' command-line option also sets this value. 'GIT_WORK_TREE':: - Set the path to the working tree. The value will not be - used in combination with repositories found automatically in - a .git directory (i.e. $GIT_DIR is not set). + Set the path to the root of the working tree. This can also be controlled by the '--work-tree' command line option and the core.worktree configuration variable. +'GIT_NAMESPACE':: + Set the Git namespace; see linkgit:gitnamespaces[7] for details. + The '--namespace' command-line option also sets this value. + 'GIT_CEILING_DIRECTORIES':: - This should be a colon-separated list of absolute paths. - If set, it is a list of directories that git should not chdir - up into while looking for a repository directory. - It will not exclude the current working directory or - a GIT_DIR set on the command line or in the environment. - (Useful for excluding slow-loading network directories.) + This should be a colon-separated list of absolute paths. If + set, it is a list of directories that Git should not chdir up + into while looking for a repository directory (useful for + excluding slow-loading network directories). It will not + exclude the current working directory or a GIT_DIR set on the + command line or in the environment. Normally, Git has to read + the entries in this list and resolve any symlink that + might be present in order to compare them with the current + directory. However, if even this access is slow, you + can add an empty entry to the list to tell Git that the + subsequent entries are not symlinks and needn't be resolved; + e.g., + 'GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink'. 'GIT_DISCOVERY_ACROSS_FILESYSTEM':: When run in a directory that does not have ".git" repository - directory, git tries to find such a directory in the parent + directory, Git tries to find such a directory in the parent directories to find the top of the working tree, but by default it does not cross filesystem boundaries. This environment variable - can be set to true to tell git not to stop at filesystem + can be set to true to tell Git not to stop at filesystem boundaries. Like 'GIT_CEILING_DIRECTORIES', this will not affect an explicit repository directory set via 'GIT_DIR' or on the command line. -git Commits +Git Commits ~~~~~~~~~~~ 'GIT_AUTHOR_NAME':: 'GIT_AUTHOR_EMAIL':: @@ -628,13 +784,13 @@ git Commits 'EMAIL':: see linkgit:git-commit-tree[1] -git Diffs +Git Diffs ~~~~~~~~~ 'GIT_DIFF_OPTS':: Only valid setting is "--unified=??" or "-u??" to set the number of context lines shown when a unified diff is created. This takes precedence over any "-U" or "--unified" option - value passed on the git diff command line. + value passed on the Git diff command line. 'GIT_EXTERNAL_DIFF':: When the environment variable 'GIT_EXTERNAL_DIFF' is set, the @@ -648,7 +804,7 @@ where: <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the contents of <old|new>, - <old|new>-hex:: are the 40-hexdigit SHA1 hashes, + <old|new>-hex:: are the 40-hexdigit SHA-1 hashes, <old|new>-mode:: are the octal representation of the file modes. + The file parameters can point at the user's working file @@ -659,6 +815,15 @@ temporary file --- it is removed when 'GIT_EXTERNAL_DIFF' exits. + For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1 parameter, <path>. ++ +For each path 'GIT_EXTERNAL_DIFF' is called, two environment variables, +'GIT_DIFF_PATH_COUNTER' and 'GIT_DIFF_PATH_TOTAL' are set. + +'GIT_DIFF_PATH_COUNTER':: + A 1-based counter incremented by one for every path. + +'GIT_DIFF_PATH_TOTAL':: + The total number of paths. other ~~~~~ @@ -669,17 +834,26 @@ other 'GIT_PAGER':: This environment variable overrides `$PAGER`. If it is set - to an empty string or to the value "cat", git will not launch + to an empty string or to the value "cat", Git will not launch a pager. See also the `core.pager` option in linkgit:git-config[1]. +'GIT_EDITOR':: + This environment variable overrides `$EDITOR` and `$VISUAL`. + It is used by several Git commands when, on interactive mode, + an editor is to be launched. See also linkgit:git-var[1] + and the `core.editor` option in linkgit:git-config[1]. + 'GIT_SSH':: If this environment variable is set then 'git fetch' and 'git push' will use this command instead of 'ssh' when they need to connect to a remote system. - The '$GIT_SSH' command will be given exactly two arguments: - the 'username@host' (or just 'host') from the URL and the - shell command to execute on that remote system. + The '$GIT_SSH' command will be given exactly two or + four arguments: the 'username@host' (or just 'host') + from the URL and the shell command to execute on that + remote system, optionally preceded by '-p' (literally) and + the 'port' from the URL when it specifies something other + than the default SSH port. + To pass options to the program that you want to list in GIT_SSH you will need to wrap the program and options into a shell script, @@ -690,44 +864,98 @@ personal `.ssh/config` file. Please consult your ssh documentation for further details. 'GIT_ASKPASS':: - If this environment variable is set, then git commands which need to + If this environment variable is set, then Git commands which need to acquire passwords or passphrases (e.g. for HTTP or IMAP authentication) will call this program with a suitable prompt as command line argument and read the password from its STDOUT. See also the 'core.askpass' option in linkgit:git-config[1]. +'GIT_CONFIG_NOSYSTEM':: + Whether to skip reading settings from the system-wide + `$(prefix)/etc/gitconfig` file. This environment variable can + be used along with `$HOME` and `$XDG_CONFIG_HOME` to create a + predictable environment for a picky script, or you can set it + temporarily to avoid using a buggy `/etc/gitconfig` file while + waiting for someone with sufficient permissions to fix it. + 'GIT_FLUSH':: If this environment variable is set to "1", then commands such as 'git blame' (in incremental mode), 'git rev-list', 'git log', - and 'git whatchanged' will force a flush of the output stream - after each commit-oriented record have been flushed. If this + 'git check-attr' and 'git check-ignore' will + force a flush of the output stream after each record have been + flushed. If this variable is set to "0", the output of these commands will be done using completely buffered I/O. If this environment variable is - not set, git will choose buffered or record-oriented flushing + not set, Git will choose buffered or record-oriented flushing based on whether stdout appears to be redirected to a file or not. 'GIT_TRACE':: If this variable is set to "1", "2" or "true" (comparison - is case insensitive), git will print `trace:` messages on + is case insensitive), Git will print `trace:` messages on stderr telling about alias expansion, built-in command execution and external command execution. If this variable is set to an integer value greater than 1 - and lower than 10 (strictly) then git will interpret this + and lower than 10 (strictly) then Git will interpret this value as an open file descriptor and will try to write the trace messages into this file descriptor. Alternatively, if this variable is set to an absolute path - (starting with a '/' character), git will interpret this + (starting with a '/' character), Git will interpret this as a file path and will try to write the trace messages into it. +'GIT_TRACE_PACK_ACCESS':: + If this variable is set to a path, a file will be created at + the given path logging all accesses to any packs. For each + access, the pack file name and an offset in the pack is + recorded. This may be helpful for troubleshooting some + pack-related performance problems. + +'GIT_TRACE_PACKET':: + If this variable is set, it shows a trace of all packets + coming in or out of a given program. This can help with + debugging object negotiation or other protocol issues. Tracing + is turned off at a packet starting with "PACK". + +GIT_LITERAL_PATHSPECS:: + Setting this variable to `1` will cause Git to treat all + pathspecs literally, rather than as glob patterns. For example, + running `GIT_LITERAL_PATHSPECS=1 git log -- '*.c'` will search + for commits that touch the path `*.c`, not any paths that the + glob `*.c` matches. You might want this if you are feeding + literal paths to Git (e.g., paths previously given to you by + `git ls-tree`, `--raw` diff output, etc). + +GIT_GLOB_PATHSPECS:: + Setting this variable to `1` will cause Git to treat all + pathspecs as glob patterns (aka "glob" magic). + +GIT_NOGLOB_PATHSPECS:: + Setting this variable to `1` will cause Git to treat all + pathspecs as literal (aka "literal" magic). + +GIT_ICASE_PATHSPECS:: + Setting this variable to `1` will cause Git to treat all + pathspecs as case-insensitive. + +'GIT_REFLOG_ACTION':: + When a ref is updated, reflog entries are created to keep + track of the reason why the ref was updated (which is + typically the name of the high-level command that updated + the ref), in addition to the old and new values of the ref. + A scripted Porcelain command can use set_reflog_action + helper function in `git-sh-setup` to set its name to this + variable when it is invoked as the top level command by the + end user, to be recorded in the body of the reflog. + + Discussion[[Discussion]] ------------------------ More detail on the following is available from the -link:user-manual.html#git-concepts[git concepts chapter of the +link:user-manual.html#git-concepts[Git concepts chapter of the user-manual] and linkgit:gitcore-tutorial[7]. -A git project normally consists of a working directory with a ".git" +A Git project normally consists of a working directory with a ".git" subdirectory at the top level. The .git directory contains, among other things, a compressed object database representing the complete history of the project, an "index" file which links that history to the current @@ -744,7 +972,7 @@ The commit, equivalent to what other systems call a "changeset" or represents an immediately preceding step. Commits with more than one parent represent merges of independent lines of development. -All objects are named by the SHA1 hash of their contents, normally +All objects are named by the SHA-1 hash of their contents, normally written as a string of 40 hex digits. Such names are globally unique. The entire history leading up to a commit can be vouched for by signing just that commit. A fourth object type, the tag, is provided for this @@ -754,9 +982,9 @@ When first created, objects are stored in individual files, but for efficiency may later be compressed together into "pack files". Named pointers called refs mark interesting points in history. A ref -may contain the SHA1 name of an object or the name of another ref. Refs -with names beginning `ref/head/` contain the SHA1 name of the most -recent commit (or "head") of a branch under development. SHA1 names of +may contain the SHA-1 name of an object or the name of another ref. Refs +with names beginning `ref/head/` contain the SHA-1 name of the most +recent commit (or "head") of a branch under development. SHA-1 names of tags of interest are stored under `ref/tags/`. A special ref named `HEAD` contains the name of the currently checked-out branch. @@ -773,12 +1001,37 @@ The index is also capable of storing multiple entries (called "stages") for a given pathname. These stages are used to hold the various unmerged version of a file when a merge is in progress. +FURTHER DOCUMENTATION +--------------------- + +See the references in the "description" section to get started +using Git. The following is probably more detail than necessary +for a first-time user. + +The link:user-manual.html#git-concepts[Git concepts chapter of the +user-manual] and linkgit:gitcore-tutorial[7] both provide +introductions to the underlying Git architecture. + +See linkgit:gitworkflows[7] for an overview of recommended workflows. + +See also the link:howto-index.html[howto] documents for some useful +examples. + +The internals are documented in the +link:technical/api-index.html[Git API documentation]. + +Users migrating from CVS may also want to +read linkgit:gitcvs-migration[7]. + + Authors ------- Git was started by Linus Torvalds, and is currently maintained by Junio -C Hamano. Numerous contributions have come from the git mailing list -<git@vger.kernel.org>. For a more complete list of contributors, see -http://git-scm.com/about. If you have a clone of git.git itself, the +C Hamano. Numerous contributions have come from the Git mailing list +<git@vger.kernel.org>. http://www.ohloh.net/p/git/contributors/summary +gives you a more complete list of contributors. + +If you have a clone of git.git itself, the output of linkgit:git-shortlog[1] and linkgit:git-blame[1] can show you the authors for specific parts of the project. diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 2bbe76b5d..643c1ba92 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -56,8 +56,9 @@ When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per attribute. The rules how the pattern matches paths are the same as in `.gitignore` files; see linkgit:gitignore[5]. +Unlike `.gitignore`, negative patterns are forbidden. -When deciding what attributes are assigned to a path, git +When deciding what attributes are assigned to a path, Git consults `$GIT_DIR/info/attributes` file (which has the highest precedence), `.gitattributes` file in the same directory as the path in question, and its parent directories up to the toplevel of the @@ -66,6 +67,11 @@ is from the path in question, the lower its precedence). Finally global and system-wide files are considered (they have the lowest precedence). +When the `.gitattributes` file is missing from the work tree, the +path in the index is used as a fall-back. During checkout process, +`.gitattributes` in the index is used and then the file in the +working tree is used as a fall-back. + If you wish to affect only a single repository (i.e., to assign attributes to files that are particular to one user's workflow for that repository), then @@ -75,6 +81,8 @@ repositories (i.e., attributes of interest to all users) should go into `.gitattributes` files. Attributes that should affect all repositories for a single user should be placed in a file specified by the `core.attributesfile` configuration option (see linkgit:git-config[1]). +Its default value is $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME +is either not set or empty, $HOME/.config/git/attributes is used instead. Attributes for all users on a system should be placed in the `$(prefix)/etc/gitattributes` file. @@ -86,7 +94,7 @@ the name of the attribute prefixed with an exclamation point `!`. EFFECTS ------- -Certain operations by git can be influenced by assigning +Certain operations by Git can be influenced by assigning particular attributes to a path. Currently, the following operations are attributes-aware. @@ -96,7 +104,7 @@ Checking-out and checking-in These attributes affect how the contents stored in the repository are copied to the working tree files when commands such as 'git checkout' and 'git merge' run. They also affect how -git stores the contents you prepare in the working tree in the +Git stores the contents you prepare in the working tree in the repository upon 'git add' and 'git commit'. `text` @@ -116,22 +124,22 @@ Set:: Unset:: - Unsetting the `text` attribute on a path tells git not to + Unsetting the `text` attribute on a path tells Git not to attempt any end-of-line conversion upon checkin or checkout. Set to string value "auto":: When `text` is set to "auto", the path is marked for automatic - end-of-line normalization. If git decides that the content is + end-of-line normalization. If Git decides that the content is text, its line endings are normalized to LF on checkin. Unspecified:: - If the `text` attribute is unspecified, git uses the + If the `text` attribute is unspecified, Git uses the `core.autocrlf` configuration variable to determine if the file should be converted. -Any other value causes git to act as if `text` has been left +Any other value causes Git to act as if `text` has been left unspecified. `eol` @@ -143,13 +151,13 @@ content checks, effectively setting the `text` attribute. Set to string value "crlf":: - This setting forces git to normalize line endings for this + This setting forces Git to normalize line endings for this file on checkin and convert them to CRLF when the file is checked out. Set to string value "lf":: - This setting forces git to normalize line endings to LF on + This setting forces Git to normalize line endings to LF on checkin and prevents conversion to CRLF when the file is checked out. @@ -168,11 +176,11 @@ crlf=input eol=lf End-of-line conversion ^^^^^^^^^^^^^^^^^^^^^^ -While git normally leaves file contents alone, it can be configured to +While Git normally leaves file contents alone, it can be configured to normalize line endings to LF in the repository and, optionally, to convert them to CRLF when files are checked out. -Here is an example that will make git normalize .txt, .vcproj and .sh +Here is an example that will make Git normalize .txt, .vcproj and .sh files, ensure that .vcproj files have CRLF and .sh files have LF in the working directory, and prevent .jpg files from being normalized regardless of their content. @@ -186,7 +194,7 @@ regardless of their content. Other source code management systems normalize all text files in their repositories, and there are two ways to enable similar automatic -normalization in git. +normalization in Git. If you simply want to have CRLF line endings in your working directory regardless of the repository you are working with, you can set the @@ -211,9 +219,9 @@ attribute to "auto" for _all_ files. * text=auto ------------------------ -This ensures that all files that git considers to be text will have +This ensures that all files that Git considers to be text will have normalized (LF) line endings in the repository. The `core.eol` -configuration variable controls which line endings git will use for +configuration variable controls which line endings Git will use for normalized files in your working directory; the default is to use the native line ending for your platform, or CRLF if `core.autocrlf` is set. @@ -226,7 +234,7 @@ directory: ------------------------------------------------- $ echo "* text=auto" >>.gitattributes -$ rm .git/index # Remove the index to force git to +$ rm .git/index # Remove the index to force Git to $ git reset # re-scan the working directory $ git status # Show files that will be normalized $ git add -u @@ -241,17 +249,17 @@ unset their `text` attribute before running 'git add -u'. manual.pdf -text ------------------------ -Conversely, text files that git does not detect can have normalization +Conversely, text files that Git does not detect can have normalization enabled manually. ------------------------ weirdchars.txt text ------------------------ -If `core.safecrlf` is set to "true" or "warn", git verifies if +If `core.safecrlf` is set to "true" or "warn", Git verifies if the conversion is reversible for the current setting of -`core.autocrlf`. For "true", git rejects irreversible -conversions; for "warn", git only prints a warning but accepts +`core.autocrlf`. For "true", Git rejects irreversible +conversions; for "warn", Git only prints a warning but accepts an irreversible conversion. The safety triggers to prevent such a conversion done to the files in the work tree, but there are a few exceptions. Even though... @@ -272,7 +280,7 @@ few exceptions. Even though... `ident` ^^^^^^^ -When the attribute `ident` is set for a path, git replaces +When the attribute `ident` is set for a path, Git replaces `$Id$` in the blob object with `$Id:`, followed by the 40-character hexadecimal blob object name, followed by a dollar sign `$` upon checkout. Any byte sequence that begins with @@ -294,16 +302,27 @@ output is used to update the worktree file. Similarly, the `clean` command is used to convert the contents of worktree file upon checkin. -A missing filter driver definition in the config is not an error -but makes the filter a no-op passthru. +One use of the content filtering is to massage the content into a shape +that is more convenient for the platform, filesystem, and the user to use. +For this mode of operation, the key phrase here is "more convenient" and +not "turning something unusable into usable". In other words, the intent +is that if someone unsets the filter driver definition, or does not have +the appropriate filter program, the project should still be usable. + +Another use of the content filtering is to store the content that cannot +be directly used in the repository (e.g. a UUID that refers to the true +content stored outside Git, or an encrypted content) and turn it into a +usable form upon checkout (e.g. download the external content, or decrypt +the encrypted content). + +These two filters behave differently, and by default, a filter is taken as +the former, massaging the contents into more convenient shape. A missing +filter driver definition in the config, or a filter driver that exits with +a non-zero status, is not an error but makes the filter a no-op passthru. -The content filtering is done to massage the content into a -shape that is more convenient for the platform, filesystem, and -the user to use. The key phrase here is "more convenient" and not -"turning something unusable into usable". In other words, the -intent is that if someone unsets the filter driver definition, -or does not have the appropriate filter program, the project -should still be usable. +You can declare that a filter turns a content that by itself is unusable +into a usable content by setting the filter.<driver>.required configuration +variable to `true`. For example, in .gitattributes, you would assign the `filter` attribute for paths. @@ -335,6 +354,16 @@ input that is already correctly indented. In this case, the lack of a smudge filter means that the clean filter _must_ accept its own output without modifying it. +If a filter _must_ succeed in order to make the stored contents usable, +you can declare that the filter is `required`, in the configuration: + +------------------------ +[filter "crypt"] + clean = openssl enc ... + smudge = openssl enc -d ... + required +------------------------ + Sequence "%f" on the filter command line is replaced with the name of the file the filter is working on. A filter might use this in keyword substitution. For example: @@ -368,7 +397,7 @@ clean/smudge filter or text/eol/ident attributes, merging anything where the attribute is not in place would normally cause merge conflicts. -To prevent these unnecessary merge conflicts, git can be told to run a +To prevent these unnecessary merge conflicts, Git can be told to run a virtual check-out and check-in of all three stages of a file when resolving a three-way merge by setting the `merge.renormalize` configuration variable. This prevents changes caused by check-in @@ -388,11 +417,11 @@ Generating diff text `diff` ^^^^^^ -The attribute `diff` affects how 'git' generates diffs for particular -files. It can tell git whether to generate a textual patch for the path +The attribute `diff` affects how Git generates diffs for particular +files. It can tell Git whether to generate a textual patch for the path or to treat the path as a binary file. It can also affect what line is -shown on the hunk header `@@ -k,l +n,m @@` line, tell git to use an -external command to generate the diff, or ask git to convert binary +shown on the hunk header `@@ -k,l +n,m @@` line, tell Git to use an +external command to generate the diff, or ask Git to convert binary files to a text format before generating the diff. Set:: @@ -420,7 +449,7 @@ String:: specify one or more options, as described in the following section. The options for the diff driver "foo" are defined by the configuration variables in the "diff.foo" section of the - git config file. + Git config file. Defining an external diff driver @@ -438,7 +467,7 @@ To define an external diff driver `jcdiff`, add a section to your command = j-c-diff ---------------------------------------------------------------- -When git needs to show you a diff for the path with `diff` +When Git needs to show you a diff for the path with `diff` attribute set to `jcdiff`, it calls the command you specified with the above configuration, i.e. `j-c-diff`, with 7 parameters, just like `GIT_EXTERNAL_DIFF` program is called. @@ -488,6 +517,8 @@ configuration file (you still need to enable this with the attribute mechanism, via `.gitattributes`). The following built in patterns are available: +- `ada` suitable for source code in the Ada language. + - `bibtex` suitable for files with BibTeX coded references. - `cpp` suitable for source code in the C and C++ languages. @@ -500,6 +531,8 @@ patterns are available: - `java` suitable for source code in the Java language. +- `matlab` suitable for source code in the MATLAB language. + - `objc` suitable for source code in the Objective-C language. - `pascal` suitable for source code in the Pascal/Delphi language. @@ -573,7 +606,7 @@ should generate it separately and send it as a comment _in addition to_ the usual binary diff that you might send. Because text conversion can be slow, especially when doing a -large number of them with `git log -p`, git provides a mechanism +large number of them with `git log -p`, Git provides a mechanism to cache the output and use it in future diffs. To enable caching, set the "cachetextconv" variable in your diff driver's config. For example: @@ -586,7 +619,7 @@ config. For example: This will cache the result of running "exif" on each blob indefinitely. If you change the textconv config variable for a -diff driver, git will automatically invalidate the cache entries +diff driver, Git will automatically invalidate the cache entries and re-run the textconv filter. If you want to invalidate the cache manually (e.g., because your version of "exif" was updated and now produces better output), you can remove the cache @@ -607,7 +640,7 @@ output to resemble unified diff. You are free to locate and report changes in the most appropriate way for your data format. A textconv, by comparison, is much more limiting. You provide a -transformation of the data into a line-oriented text format, and git +transformation of the data into a line-oriented text format, and Git uses its regular diff tools to generate the output. There are several advantages to choosing this method: @@ -617,7 +650,7 @@ advantages to choosing this method: odt2txt). 2. Git diff features. By performing only the transformation step - yourself, you can still utilize many of git's diff features, + yourself, you can still utilize many of Git's diff features, including colorization, word-diff, and combined diffs for merges. 3. Caching. Textconv caching can speed up repeated diffs, such as those @@ -642,7 +675,7 @@ attribute in the `.gitattributes` file: *.ps -diff ------------------------ -This will cause git to generate `Binary files differ` (or a binary +This will cause Git to generate `Binary files differ` (or a binary patch, if binary patches are enabled) instead of a regular diff. However, one may also want to specify other diff driver attributes. For @@ -798,7 +831,7 @@ control per path. Set:: - Notice all types of potential whitespace errors known to git. + Notice all types of potential whitespace errors known to Git. The tab width is taken from the value of the `core.whitespace` configuration variable. @@ -830,7 +863,7 @@ archive files. `export-subst` ^^^^^^^^^^^^^^ -If the attribute `export-subst` is set for a file then git will expand +If the attribute `export-subst` is set for a file then Git will expand several placeholders when adding this file to an archive. The expansion depends on the availability of a commit ID, i.e., if linkgit:git-archive[1] has been given a tree instead of a commit or a @@ -897,12 +930,15 @@ state. DEFINING MACRO ATTRIBUTES ------------------------- -Custom macro attributes can be defined only in the `.gitattributes` -file at the toplevel (i.e. not in any subdirectory). The built-in -macro attribute "binary" is equivalent to: +Custom macro attributes can be defined only in top-level gitattributes +files (`$GIT_DIR/info/attributes`, the `.gitattributes` file at the +top level of the working tree, or the global or system-wide +gitattributes files), not in `.gitattributes` files in working tree +subdirectories. The built-in macro attribute "binary" is equivalent +to: ------------ -[attr]binary -diff -text +[attr]binary -diff -merge -text ------------ @@ -928,7 +964,7 @@ abc -foo -bar the attributes given to path `t/abc` are computed as follows: 1. By examining `t/.gitattributes` (which is in the same - directory as the path in question), git finds that the first + directory as the path in question), Git finds that the first line matches. `merge` attribute is set. It also finds that the second line matches, and attributes `foo` and `bar` are unset. @@ -955,6 +991,9 @@ frotz unspecified ---------------------------------------------------------------- +SEE ALSO +-------- +linkgit:git-check-attr[1]. GIT --- diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index f734f97b8..1c3e109cb 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -3,7 +3,7 @@ gitcli(7) NAME ---- -gitcli - git command line interface and conventions +gitcli - Git command line interface and conventions SYNOPSIS -------- @@ -13,7 +13,7 @@ gitcli DESCRIPTION ----------- -This manual describes the convention used throughout git CLI. +This manual describes the convention used throughout Git CLI. Many commands take revisions (most often "commits", but sometimes "tree-ish", depending on the context and command) and paths as their @@ -25,50 +25,79 @@ arguments. Here are the rules: are paths. * When an argument can be misunderstood as either a revision or a path, - they can be disambiguated by placing `\--` between them. - E.g. `git diff \-- HEAD` is, "I have a file called HEAD in my work + they can be disambiguated by placing `--` between them. + E.g. `git diff -- HEAD` is, "I have a file called HEAD in my work tree. Please show changes between the version I staged in the index - and what I have in the work tree for that file". not "show difference + and what I have in the work tree for that file", not "show difference between the HEAD commit and the work tree as a whole". You can say - `git diff HEAD \--` to ask for the latter. + `git diff HEAD --` to ask for the latter. - * Without disambiguating `\--`, git makes a reasonable guess, but errors + * Without disambiguating `--`, Git makes a reasonable guess, but errors out and asking you to disambiguate when ambiguous. E.g. if you have a file called HEAD in your work tree, `git diff HEAD` is ambiguous, and - you have to say either `git diff HEAD \--` or `git diff \-- HEAD` to + you have to say either `git diff HEAD --` or `git diff -- HEAD` to disambiguate. - ++ When writing a script that is expected to handle random user-input, it is a good practice to make it explicit which arguments are which by placing -disambiguating `\--` at appropriate places. +disambiguating `--` at appropriate places. + + * Many commands allow wildcards in paths, but you need to protect + them from getting globbed by the shell. These two mean different + things: ++ +-------------------------------- +$ git checkout -- *.c +$ git checkout -- \*.c +-------------------------------- ++ +The former lets your shell expand the fileglob, and you are asking +the dot-C files in your working tree to be overwritten with the version +in the index. The latter passes the `*.c` to Git, and you are asking +the paths in the index that match the pattern to be checked out to your +working tree. After running `git add hello.c; rm hello.c`, you will _not_ +see `hello.c` in your working tree with the former, but with the latter +you will. + + * Just as the filesystem '.' (period) refers to the current directory, + using a '.' as a repository name in Git (a dot-repository) is a relative + path and means your current repository. Here are the rules regarding the "flags" that you should follow when you are -scripting git: +scripting Git: - * it's preferred to use the non dashed form of git commands, which means that + * it's preferred to use the non dashed form of Git commands, which means that you should prefer `git foo` to `git-foo`. * splitting short options to separate words (prefer `git foo -a -b` to `git foo -ab`, the latter may not even work). - * when a command line option takes an argument, use the 'sticked' form. In + * when a command line option takes an argument, use the 'stuck' form. In other words, write `git foo -oArg` instead of `git foo -o Arg` for short options, and `git foo --long-opt=Arg` instead of `git foo --long-opt Arg` for long options. An option that takes optional option-argument must be - written in the 'sticked' form. + written in the 'stuck' form. * when you give a revision parameter to a command, make sure the parameter is not ambiguous with a name of a file in the work tree. E.g. do not write `git log -1 HEAD` but write `git log -1 HEAD --`; the former will not work if you happen to have a file called `HEAD` in the work tree. + * many commands allow a long option `--option` to be abbreviated + only to their unique prefix (e.g. if there is no other option + whose name begins with `opt`, you may be able to spell `--opt` to + invoke the `--option` flag), but you should fully spell them out + when writing your scripts; later versions of Git may introduce a + new option whose name shares the same prefix, e.g. `--optimize`, + to make a short prefix that used to be unique no longer unique. + ENHANCED OPTION PARSER ---------------------- -From the git 1.5.4 series and further, many git commands (not all of them at the +From the Git 1.5.4 series and further, many Git commands (not all of them at the time of the writing though) come with an enhanced option parser. -Here is an exhaustive list of the facilities provided by this option parser. +Here is a list of the facilities provided by this option parser. Magic Options @@ -81,18 +110,19 @@ couple of magic command line options: + --------------------------------------------- $ git describe -h -usage: git describe [options] <committish>* +usage: git describe [options] <commit-ish>* + or: git describe [options] --dirty --contains find the tag that comes after the commit --debug debug search strategy on stderr - --all use any ref in .git/refs - --tags use any tag in .git/refs/tags - --abbrev [<n>] use <n> digits to display SHA-1s - --candidates <n> consider <n> most recent tags (default: 10) + --all use any ref + --tags use any tag, even unannotated + --long always use long format + --abbrev[=<n>] use <n> digits to display SHA-1s --------------------------------------------- --help-all:: - Some git commands take options that are only used for plumbing or that + Some Git commands take options that are only used for plumbing or that are deprecated, and such options are hidden from the default usage. This option gives the full list of options. @@ -112,6 +142,16 @@ options. This means that you can for example use `git rm -rf` or `git clean -fdx`. +Abbreviating long options +~~~~~~~~~~~~~~~~~~~~~~~~~ +Commands that support the enhanced option parser accepts unique +prefix of a long option as if it is fully spelled out, but use this +with a caution. For example, `git commit --amen` behaves as if you +typed `git commit --amend`, but that is true only until a later version +of Git introduces another option that shares the same prefix, +e.g. `git commit --amenity` option. + + Separating argument from the option ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You can write the mandatory option parameter to an option as a separate @@ -125,7 +165,7 @@ $ git foo -o Arg ---------------------------- However, this is *NOT* allowed for switches with an optional value, where the -'sticked' form must be used: +'stuck' form must be used: ---------------------------- $ git describe --abbrev HEAD # correct $ git describe --abbrev=10 HEAD # correct diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index c27d086f6..058a35298 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -3,7 +3,7 @@ gitcore-tutorial(7) NAME ---- -gitcore-tutorial - A git core tutorial for developers +gitcore-tutorial - A Git core tutorial for developers SYNOPSIS -------- @@ -12,17 +12,17 @@ git * DESCRIPTION ----------- -This tutorial explains how to use the "core" git commands to set up and -work with a git repository. +This tutorial explains how to use the "core" Git commands to set up and +work with a Git repository. -If you just need to use git as a revision control system you may prefer -to start with "A Tutorial Introduction to GIT" (linkgit:gittutorial[7]) or -link:user-manual.html[the GIT User Manual]. +If you just need to use Git as a revision control system you may prefer +to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or +link:user-manual.html[the Git User Manual]. However, an understanding of these low-level tools can be helpful if -you want to understand git's internals. +you want to understand Git's internals. -The core git is often called "plumbing", with the prettier user +The core Git is often called "plumbing", with the prettier user interfaces on top of it called "porcelain". You may not want to use the plumbing directly very often, but it can be good to know what the plumbing does for when the porcelain isn't flushing. @@ -40,19 +40,19 @@ Deeper technical details are often marked as Notes, which you can skip on your first reading. -Creating a git repository +Creating a Git repository ------------------------- -Creating a new git repository couldn't be easier: all git repositories start +Creating a new Git repository couldn't be easier: all Git repositories start out empty, and the only thing you need to do is find yourself a subdirectory that you want to use as a working tree - either an empty one for a totally new project, or an existing working tree that you want -to import into git. +to import into Git. For our first example, we're going to start a totally new repository from scratch, with no pre-existing files, and we'll call it 'git-tutorial'. To start up, create a subdirectory for it, change into that -subdirectory, and initialize the git infrastructure with 'git init': +subdirectory, and initialize the Git infrastructure with 'git init': ------------------------------------------------ $ mkdir git-tutorial @@ -60,13 +60,13 @@ $ cd git-tutorial $ git init ------------------------------------------------ -to which git will reply +to which Git will reply ---------------- Initialized empty Git repository in .git/ ---------------- -which is just git's way of saying that you haven't been doing anything +which is just Git's way of saying that you haven't been doing anything strange, and that it will have created a local `.git` directory setup for your new project. You will now have a `.git` directory, and you can inspect that with 'ls'. For your new empty project, it should show you @@ -102,13 +102,13 @@ start out expecting to work on the `master` branch. However, this is only a convention, and you can name your branches anything you want, and don't have to ever even 'have' a `master` -branch. A number of the git tools will assume that `.git/HEAD` is +branch. A number of the Git tools will assume that `.git/HEAD` is valid, though. [NOTE] -An 'object' is identified by its 160-bit SHA1 hash, aka 'object name', +An 'object' is identified by its 160-bit SHA-1 hash, aka 'object name', and a reference to an object is always the 40-byte hex -representation of that SHA1 name. The files in the `refs` +representation of that SHA-1 name. The files in the `refs` subdirectory are expected to contain these hex references (usually with a final `\n` at the end), and you should thus expect to see a number of 41-byte files containing these @@ -119,18 +119,18 @@ populating your tree. An advanced user may want to take a look at linkgit:gitrepository-layout[5] after finishing this tutorial. -You have now created your first git repository. Of course, since it's +You have now created your first Git repository. Of course, since it's empty, that's not very useful, so let's start populating it with data. -Populating a git repository +Populating a Git repository --------------------------- We'll keep this simple and stupid, so we'll start off with populating a few trivial files just to get a feel for it. Start off with just creating any random files that you want to maintain -in your git repository. We'll start off with a few bad examples, just to +in your Git repository. We'll start off with a few bad examples, just to get a feel for how this works: ------------------------------------------------ @@ -146,13 +146,13 @@ but to actually check in your hard work, you will have to go through two steps: - commit that index file as an object. -The first step is trivial: when you want to tell git about any changes +The first step is trivial: when you want to tell Git about any changes to your working tree, you use the 'git update-index' program. That program normally just takes a list of filenames you want to update, but to avoid trivial mistakes, it refuses to add new entries to the index (or remove existing ones) unless you explicitly tell it that you're -adding a new entry with the `\--add` flag (or removing an entry with the -`\--remove`) flag. +adding a new entry with the `--add` flag (or removing an entry with the +`--remove`) flag. So to populate the index with the two files you just created, you can do @@ -160,10 +160,10 @@ So to populate the index with the two files you just created, you can do $ git update-index --add hello example ------------------------------------------------ -and you have now told git to track those two files. +and you have now told Git to track those two files. In fact, as you did that, if you now look into your object directory, -you'll notice that git will have added two new objects to the object +you'll notice that Git will have added two new objects to the object database. If you did exactly the steps above, you should now be able to do @@ -189,7 +189,7 @@ $ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238 ---------------- where the `-t` tells 'git cat-file' to tell you what the "type" of the -object is. git will tell you that you have a "blob" object (i.e., just a +object is. Git will tell you that you have a "blob" object (i.e., just a regular file), and you can see the contents with ---------------- @@ -214,28 +214,28 @@ Anyway, as we mentioned previously, you normally never actually take a look at the objects themselves, and typing long 40-character hex names is not something you'd normally want to do. The above digression was just to show that 'git update-index' did something magical, and -actually saved away the contents of your files into the git object +actually saved away the contents of your files into the Git object database. Updating the index did something else too: it created a `.git/index` file. This is the index that describes your current working tree, and something you should be very aware of. Again, you normally never worry about the index file itself, but you should be aware of the fact that -you have not actually really "checked in" your files into git so far, -you've only *told* git about them. +you have not actually really "checked in" your files into Git so far, +you've only *told* Git about them. -However, since git knows about them, you can now start using some of the -most basic git commands to manipulate the files or look at their status. +However, since Git knows about them, you can now start using some of the +most basic Git commands to manipulate the files or look at their status. -In particular, let's not even check in the two files into git yet, we'll +In particular, let's not even check in the two files into Git yet, we'll start off by adding another line to `hello` first: ------------------------------------------------ $ echo "It's a new day for git" >>hello ------------------------------------------------ -and you can now, since you told git about the previous state of `hello`, ask -git what has changed in the tree compared to your old index, using the +and you can now, since you told Git about the previous state of `hello`, ask +Git what has changed in the tree compared to your old index, using the 'git diff-files' command: ------------ @@ -282,11 +282,11 @@ index 557db03..263414f 100644 ------------ -Committing git state +Committing Git state -------------------- -Now, we want to go to the next stage in git, which is to take the files -that git knows about in the index, and commit them as a real tree. We do +Now, we want to go to the next stage in Git, which is to take the files +that Git knows about in the index, and commit them as a real tree. We do that in two phases: creating a 'tree' object, and committing that 'tree' object as a 'commit' object together with an explanation of what the tree was all about, along with information of how we came to that state. @@ -296,7 +296,7 @@ There are no options or other input: `git write-tree` will take the current index state, and write an object that describes that whole index. In other words, we're now tying together all the different filenames with their contents (and their permissions), and we're -creating the equivalent of a git "directory" object: +creating the equivalent of a Git "directory" object: ------------------------------------------------ $ git write-tree @@ -399,10 +399,10 @@ $ git diff HEAD which ends up doing the above for you. In other words, 'git diff-index' normally compares a tree against the -working tree, but when given the `\--cached` flag, it is told to +working tree, but when given the `--cached` flag, it is told to instead compare against just the index cache contents, and ignore the current working tree state entirely. Since we just wrote the index -file to HEAD, doing `git diff-index \--cached -p HEAD` should thus return +file to HEAD, doing `git diff-index --cached -p HEAD` should thus return an empty set of differences, and that's exactly what it does. [NOTE] @@ -411,13 +411,13 @@ an empty set of differences, and that's exactly what it does. comparisons, and saying that it compares a tree against the working tree is thus not strictly accurate. In particular, the list of files to compare (the "meta-data") *always* comes from the index file, -regardless of whether the `\--cached` flag is used or not. The `\--cached` +regardless of whether the `--cached` flag is used or not. The `--cached` flag really only determines whether the file *contents* to be compared come from the working tree or not. -This is not hard to understand, as soon as you realize that git simply +This is not hard to understand, as soon as you realize that Git simply never knows (or cares) about files that it is not told about -explicitly. git will never go *looking* for files to compare, it +explicitly. Git will never go *looking* for files to compare, it expects you to tell it what the files are, and that's what the index is there for. ================ @@ -433,7 +433,7 @@ update the index cache: $ git update-index hello ------------------------------------------------ -(note how we didn't need the `\--add` flag this time, since git knew +(note how we didn't need the `--add` flag this time, since Git knew about the file already). Note what happens to the different 'git diff-{asterisk}' versions here. @@ -464,7 +464,7 @@ this point (you can continue to edit things and update the index), you can just leave an empty message. Otherwise `git commit` will commit the change for you. -You've now made your first real git commit. And if you're interested in +You've now made your first real Git commit. And if you're interested in looking at what `git commit` really does, feel free to investigate: it's a few very simple shell scripts to generate the helpful (?) commit message headers, and a few one-liners that actually do the @@ -534,48 +534,15 @@ all, but just show the actual commit message. In fact, together with the 'git rev-list' program (which generates a list of revisions), 'git diff-tree' ends up being a veritable fount of -changes. A trivial (but very useful) script called 'git whatchanged' is -included with git which does exactly this, and shows a log of recent -activities. - -To see the whole history of our pitiful little git-tutorial project, you -can do - ----------------- -$ git log ----------------- - -which shows just the log messages, or if we want to see the log together -with the associated patches use the more complex (and much more -powerful) - ----------------- -$ git whatchanged -p ----------------- - -and you will see exactly what has changed in the repository over its -short history. - -[NOTE] -When using the above two commands, the initial commit will be shown. -If this is a problem because it is huge, you can hide it by setting -the log.showroot configuration variable to false. Having this, you -can still show it for each command just adding the `\--root` option, -which is a flag for 'git diff-tree' accepted by both commands. - -With that, you should now be having some inkling of what git does, and -can explore on your own. - -[NOTE] -Most likely, you are not directly using the core -git Plumbing commands, but using Porcelain such as 'git add', `git-rm' -and `git-commit'. +changes. You can emulate `git log`, `git log -p`, etc. with a trivial +script that pipes the output of `git rev-list` to `git diff-tree --stdin`, +which was exactly how early versions of `git log` were implemented. Tagging a version ----------------- -In git, there are two kinds of tags, a "light" one, and an "annotated tag". +In Git, there are two kinds of tags, a "light" one, and an "annotated tag". A "light" tag is technically nothing more than a branch, except we put it in the `.git/refs/tags/` subdirectory instead of calling it a `head`. @@ -598,7 +565,7 @@ obviously be an empty diff, but if you continue to develop and commit stuff, you can use your tag as an "anchor-point" to see what has changed since you tagged it. -An "annotated tag" is actually a real git object, and contains not only a +An "annotated tag" is actually a real Git object, and contains not only a pointer to the state you want to tag, but also a small tag name and message, along with optionally a PGP signature that says that yes, you really did @@ -623,17 +590,17 @@ name for the state at that point. Copying repositories -------------------- -git repositories are normally totally self-sufficient and relocatable. +Git repositories are normally totally self-sufficient and relocatable. Unlike CVS, for example, there is no separate notion of -"repository" and "working tree". A git repository normally *is* the -working tree, with the local git information hidden in the `.git` +"repository" and "working tree". A Git repository normally *is* the +working tree, with the local Git information hidden in the `.git` subdirectory. There is nothing else. What you see is what you got. [NOTE] -You can tell git to split the git internal information from +You can tell Git to split the Git internal information from the directory that it tracks, but we'll ignore that for now: it's not how normal projects work, and it's really only meant for special uses. -So the mental model of "the git information is always tied directly to +So the mental model of "the Git information is always tied directly to the working tree that it describes" may not be technically 100% accurate, but it's a good model for all normal use. @@ -649,13 +616,13 @@ $ rm -rf git-tutorial and it will be gone. There's no external repository, and there's no history outside the project you created. - - if you want to move or duplicate a git repository, you can do so. There + - if you want to move or duplicate a Git repository, you can do so. There is 'git clone' command, but if all you want to do is just to create a copy of your repository (with all the full history that went along with it), you can do so with a regular `cp -a git-tutorial new-git-tutorial`. + -Note that when you've moved or copied a git repository, your git index +Note that when you've moved or copied a Git repository, your Git index file (which caches various information, notably some of the "stat" information for the files involved) will likely need to be refreshed. So after you do a `cp -a` to create a new copy, you'll want to do @@ -667,7 +634,7 @@ $ git update-index --refresh in the new repository to make sure that the index file is up-to-date. Note that the second point is true even across machines. You can -duplicate a remote git repository with *any* regular copy mechanism, be it +duplicate a remote Git repository with *any* regular copy mechanism, be it 'scp', 'rsync' or 'wget'. When copying a remote repository, you'll want to at a minimum update the @@ -694,23 +661,23 @@ The above can also be written as simply $ git reset ---------------- -and in fact a lot of the common git command combinations can be scripted +and in fact a lot of the common Git command combinations can be scripted with the `git xyz` interfaces. You can learn things by just looking at what the various git scripts do. For example, `git reset` used to be the above two lines implemented in 'git reset', but some things like 'git status' and 'git commit' are slightly more complex scripts around -the basic git commands. +the basic Git commands. Many (most?) public remote repositories will not contain any of the checked out files or even an index file, and will *only* contain the -actual core git files. Such a repository usually doesn't even have the -`.git` subdirectory, but has all the git files directly in the +actual core Git files. Such a repository usually doesn't even have the +`.git` subdirectory, but has all the Git files directly in the repository. -To create your own local live copy of such a "raw" git repository, you'd +To create your own local live copy of such a "raw" Git repository, you'd first create your own subdirectory for the project, and then copy the raw repository contents into the `.git` directory. For example, to -create your own copy of the git repository, you'd do the following +create your own copy of the Git repository, you'd do the following ---------------- $ mkdir my-git @@ -725,7 +692,7 @@ $ git read-tree HEAD ---------------- to populate the index. However, now you have populated the index, and -you have all the git internal files, but you will notice that you don't +you have all the Git internal files, but you will notice that you don't actually have any of the working tree files to work on. To get those, you'd check them out with @@ -757,13 +724,13 @@ repository, and checked it out. Creating a new branch --------------------- -Branches in git are really nothing more than pointers into the git +Branches in Git are really nothing more than pointers into the Git object database from within the `.git/refs/` subdirectory, and as we already discussed, the `HEAD` branch is nothing but a symlink to one of these object pointers. You can at any time create a new branch by just picking an arbitrary -point in the project history, and just writing the SHA1 name of that +point in the project history, and just writing the SHA-1 name of that object into a file under `.git/refs/heads/`. You can use any filename you want (and indeed, subdirectories), but the convention is that the "normal" branch is called `master`. That's just a convention, though, @@ -849,7 +816,7 @@ $ git commit -m "Some work." -i hello Here, we just added another line to `hello`, and we used a shorthand for doing both `git update-index hello` and `git commit` by just giving the filename directly to `git commit`, with an `-i` flag (it tells -git to 'include' that file in addition to what you have done to +Git to 'include' that file in addition to what you have done to the index file so far when making the commit). The `-m` flag is to give the commit log message from the command line. @@ -881,7 +848,7 @@ helps you view what's going on: $ gitk --all ---------------- -will show you graphically both of your branches (that's what the `\--all` +will show you graphically both of your branches (that's what the `--all` means: normally it will just show you your current `HEAD`) and their histories. You can also see exactly how they came to be from a common source. @@ -900,7 +867,7 @@ where the first argument is going to be used as the commit message if the merge can be resolved automatically. Now, in this case we've intentionally created a situation where the -merge will need to be fixed up by hand, though, so git will do as much +merge will need to be fixed up by hand, though, so Git will do as much of it as it can automatically (which in this case is just merge the `example` file, which had no differences in the `mybranch` branch), and say: @@ -935,11 +902,11 @@ which will very loudly warn you that you're now committing a merge (which is correct, so never mind), and you can write a small merge message about your adventures in 'git merge'-land. -After you're done, start up `gitk \--all` to see graphically what the +After you're done, start up `gitk --all` to see graphically what the history looks like. Notice that `mybranch` still exists, and you can switch to it, and continue to work with it if you want to. The `mybranch` branch will not contain the merge, but next time you merge it -from the `master` branch, git will know how you merged it, so you'll not +from the `master` branch, Git will know how you merged it, so you'll not have to do _that_ merge again. Another useful tool, especially if you do not always work in X-Window @@ -956,13 +923,12 @@ $ git show-branch --topo-order --more=1 master mybranch ------------------------------------------------ The first two lines indicate that it is showing the two branches -and the first line of the commit log message from their -top-of-the-tree commits, you are currently on `master` branch -(notice the asterisk `{asterisk}` character), and the first column for -the later output lines is used to show commits contained in the +with the titles of their top-of-the-tree commits, you are currently on +`master` branch (notice the asterisk `*` character), and the first +column for the later output lines is used to show commits contained in the `master` branch, and the second column for the `mybranch` -branch. Three commits are shown along with their log messages. -All of them have non blank characters in the first column (`{asterisk}` +branch. Three commits are shown along with their titles. +All of them have non blank characters in the first column (`*` shows an ordinary commit on the current branch, `-` is a merge commit), which means they are now part of the `master` branch. Only the "Some work" commit has the plus `+` character in the second column, @@ -1002,9 +968,9 @@ would be different) ---------------- Updating from ae3a2da... to a80b4aa.... Fast-forward (no commit created; -m option ignored) - example | 1 + - hello | 1 + - 2 files changed, 2 insertions(+), 0 deletions(-) + example | 1 + + hello | 1 + + 2 files changed, 2 insertions(+) ---------------- Because your branch did not contain anything more than what had @@ -1013,7 +979,7 @@ not actually do a merge. Instead, it just updated the top of the tree of your branch to that of the `master` branch. This is often called 'fast-forward' merge. -You can run `gitk \--all` again to see how the commit ancestry +You can run `gitk --all` again to see how the commit ancestry looks like, or run 'show-branch', which tells you this. ------------------------------------------------ @@ -1029,7 +995,7 @@ Merging external work --------------------- It's usually much more common that you merge with somebody else than -merging with your own branches, so it's worth pointing out that git +merging with your own branches, so it's worth pointing out that Git makes that very easy too, and in fact, it's not that different from doing a 'git merge'. In fact, a remote merge ends up being nothing more than "fetch the work from a remote repository into a temporary tag" @@ -1069,7 +1035,7 @@ and requires you to have a log-in privilege over `ssh` to the remote machine. It finds out the set of objects the other side lacks by exchanging the head commits both ends have and transfers (close to) minimum set of objects. It is by far the -most efficient way to exchange git objects between repositories. +most efficient way to exchange Git objects between repositories. Local directory:: `/path/to/repo.git/` @@ -1078,7 +1044,7 @@ This transport is the same as SSH transport but uses 'sh' to run both ends on the local machine instead of running other end on the remote machine via 'ssh'. -git Native:: +Git Native:: `git://remote.machine/path/to/repo.git/` + This transport was designed for anonymous downloading. Like SSH @@ -1100,8 +1066,8 @@ necessary objects. Because of this behavior, they are sometimes also called 'commit walkers'. + The 'commit walkers' are sometimes also called 'dumb -transports', because they do not require any git aware smart -server like git Native transport does. Any stock HTTP server +transports', because they do not require any Git aware smart +server like Git Native transport does. Any stock HTTP server that does not even support directory index would suffice. But you must prepare your repository with 'git update-server-info' to help dumb transport downloaders. @@ -1234,7 +1200,7 @@ file (the first tree goes to stage 1, the second to stage 2, etc.). After reading three trees into three stages, the paths that are the same in all three stages are 'collapsed' into stage 0. Also paths that are the same in two of three stages are -collapsed into stage 0, taking the SHA1 from either stage 2 or +collapsed into stage 0, taking the SHA-1 from either stage 2 or stage 3, whichever is different from stage 1 (i.e. only one side changed from the common ancestor). @@ -1257,7 +1223,7 @@ this 'collapsing' tends to trivially merge most of the paths fairly quickly, leaving only a handful of real changes in non-zero stages. -To look at only non-zero stages, use `\--unmerged` flag: +To look at only non-zero stages, use `--unmerged` flag: ------------ $ git ls-files --unmerged @@ -1322,7 +1288,7 @@ update the public repository from it. This is often called [NOTE] This public repository could further be mirrored, and that is -how git repositories at `kernel.org` are managed. +how Git repositories at `kernel.org` are managed. Publishing the changes from your local (private) repository to your remote (public) repository requires a write privilege on @@ -1341,7 +1307,7 @@ done only once. on the remote machine. The communication between the two over the network internally uses an SSH connection. -Your private repository's git directory is usually `.git`, but +Your private repository's Git directory is usually `.git`, but your public repository is often named after the project name, i.e. `<project>.git`. Let's create such a public repository for project `my-git`. After logging into the remote machine, create @@ -1351,7 +1317,7 @@ an empty directory: $ mkdir my-git.git ------------ -Then, make that directory into a git repository by running +Then, make that directory into a Git repository by running 'git init', but this time, since its name is not the usual `.git`, we do things slightly differently: @@ -1390,7 +1356,7 @@ This synchronizes your public repository to match the named branch head (i.e. `master` in this case) and objects reachable from them in your current repository. -As a real example, this is how I update my public git +As a real example, this is how I update my public Git repository. Kernel.org mirror network takes care of the propagation to other publicly visible machines: @@ -1403,9 +1369,9 @@ Packing your repository ----------------------- Earlier, we saw that one file under `.git/objects/??/` directory -is stored for each git object you create. This representation +is stored for each Git object you create. This representation is efficient to create atomically and safely, but -not so convenient to transport over the network. Since git objects are +not so convenient to transport over the network. Since Git objects are immutable once they are created, there is a way to optimize the storage by "packing them together". The command @@ -1420,7 +1386,7 @@ packed, and stores the packed file in `.git/objects/pack` directory. [NOTE] -You will see two files, `pack-{asterisk}.pack` and `pack-{asterisk}.idx`, +You will see two files, `pack-*.pack` and `pack-*.idx`, in `.git/objects/pack` directory. They are closely related to each other, and if you ever copy them by hand to a different repository for whatever reason, you should make sure you copy @@ -1473,14 +1439,14 @@ repositories every once in a while. Working with Others ------------------- -Although git is a truly distributed system, it is often +Although Git is a truly distributed system, it is often convenient to organize your project with an informal hierarchy of developers. Linux kernel development is run this way. There is a nice illustration (page 17, "Merges to Mainline") in link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation]. It should be stressed that this hierarchy is purely *informal*. -There is nothing fundamental in git that enforces the "chain of +There is nothing fundamental in Git that enforces the "chain of patch flow" this hierarchy implies. You do not have to pull from only one remote repository. @@ -1593,7 +1559,7 @@ Working with Others, Shared Repository Style If you are coming from CVS background, the style of cooperation suggested in the previous section may be new to you. You do not -have to worry. git supports "shared public repository" style of +have to worry. Git supports "shared public repository" style of cooperation you are probably more familiar with as well. See linkgit:gitcvs-migration[7] for the details. @@ -1603,7 +1569,7 @@ Bundling your work together It is likely that you will be working on more than one thing at a time. It is easy to manage those more-or-less independent tasks -using branches with git. +using branches with Git. We have already seen how branches work previously, with "fun and work" example using two branches. The idea is the diff --git a/Documentation/gitcredentials.txt b/Documentation/gitcredentials.txt new file mode 100644 index 000000000..47576be5d --- /dev/null +++ b/Documentation/gitcredentials.txt @@ -0,0 +1,183 @@ +gitcredentials(7) +================= + +NAME +---- +gitcredentials - providing usernames and passwords to Git + +SYNOPSIS +-------- +------------------ +git config credential.https://example.com.username myusername +git config credential.helper "$helper $options" +------------------ + +DESCRIPTION +----------- + +Git will sometimes need credentials from the user in order to perform +operations; for example, it may need to ask for a username and password +in order to access a remote repository over HTTP. This manual describes +the mechanisms Git uses to request these credentials, as well as some +features to avoid inputting these credentials repeatedly. + +REQUESTING CREDENTIALS +---------------------- + +Without any credential helpers defined, Git will try the following +strategies to ask the user for usernames and passwords: + +1. If the `GIT_ASKPASS` environment variable is set, the program + specified by the variable is invoked. A suitable prompt is provided + to the program on the command line, and the user's input is read + from its standard output. + +2. Otherwise, if the `core.askpass` configuration variable is set, its + value is used as above. + +3. Otherwise, if the `SSH_ASKPASS` environment variable is set, its + value is used as above. + +4. Otherwise, the user is prompted on the terminal. + +AVOIDING REPETITION +------------------- + +It can be cumbersome to input the same credentials over and over. Git +provides two methods to reduce this annoyance: + +1. Static configuration of usernames for a given authentication context. + +2. Credential helpers to cache or store passwords, or to interact with + a system password wallet or keychain. + +The first is simple and appropriate if you do not have secure storage available +for a password. It is generally configured by adding this to your config: + +--------------------------------------- +[credential "https://example.com"] + username = me +--------------------------------------- + +Credential helpers, on the other hand, are external programs from which Git can +request both usernames and passwords; they typically interface with secure +storage provided by the OS or other programs. + +To use a helper, you must first select one to use. Git currently +includes the following helpers: + +cache:: + + Cache credentials in memory for a short period of time. See + linkgit:git-credential-cache[1] for details. + +store:: + + Store credentials indefinitely on disk. See + linkgit:git-credential-store[1] for details. + +You may also have third-party helpers installed; search for +`credential-*` in the output of `git help -a`, and consult the +documentation of individual helpers. Once you have selected a helper, +you can tell Git to use it by putting its name into the +credential.helper variable. + +1. Find a helper. ++ +------------------------------------------- +$ git help -a | grep credential- +credential-foo +------------------------------------------- + +2. Read its description. ++ +------------------------------------------- +$ git help credential-foo +------------------------------------------- + +3. Tell Git to use it. ++ +------------------------------------------- +$ git config --global credential.helper foo +------------------------------------------- + +If there are multiple instances of the `credential.helper` configuration +variable, each helper will be tried in turn, and may provide a username, +password, or nothing. Once Git has acquired both a username and a +password, no more helpers will be tried. + + +CREDENTIAL CONTEXTS +------------------- + +Git considers each credential to have a context defined by a URL. This context +is used to look up context-specific configuration, and is passed to any +helpers, which may use it as an index into secure storage. + +For instance, imagine we are accessing `https://example.com/foo.git`. When Git +looks into a config file to see if a section matches this context, it will +consider the two a match if the context is a more-specific subset of the +pattern in the config file. For example, if you have this in your config file: + +-------------------------------------- +[credential "https://example.com"] + username = foo +-------------------------------------- + +then we will match: both protocols are the same, both hosts are the same, and +the "pattern" URL does not care about the path component at all. However, this +context would not match: + +-------------------------------------- +[credential "https://kernel.org"] + username = foo +-------------------------------------- + +because the hostnames differ. Nor would it match `foo.example.com`; Git +compares hostnames exactly, without considering whether two hosts are part of +the same domain. Likewise, a config entry for `http://example.com` would not +match: Git compares the protocols exactly. + + +CONFIGURATION OPTIONS +--------------------- + +Options for a credential context can be configured either in +`credential.*` (which applies to all credentials), or +`credential.<url>.*`, where <url> matches the context as described +above. + +The following options are available in either location: + +helper:: + + The name of an external credential helper, and any associated options. + If the helper name is not an absolute path, then the string `git + credential-` is prepended. The resulting string is executed by the + shell (so, for example, setting this to `foo --option=bar` will execute + `git credential-foo --option=bar` via the shell. See the manual of + specific helpers for examples of their use. + +username:: + + A default username, if one is not provided in the URL. + +useHttpPath:: + + By default, Git does not consider the "path" component of an http URL + to be worth matching via external helpers. This means that a credential + stored for `https://example.com/foo.git` will also be used for + `https://example.com/bar.git`. If you do want to distinguish these + cases, set this option to `true`. + + +CUSTOM HELPERS +-------------- + +You can write your own custom helpers to interface with any system in +which you keep credentials. See the documentation for Git's +link:technical/api-credentials.html[credentials API] for details. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt index aeb0cdc97..5ea94cbce 100644 --- a/Documentation/gitcvs-migration.txt +++ b/Documentation/gitcvs-migration.txt @@ -3,7 +3,7 @@ gitcvs-migration(7) NAME ---- -gitcvs-migration - git for CVS users +gitcvs-migration - Git for CVS users SYNOPSIS -------- @@ -19,7 +19,7 @@ important than any other. However, you can emulate the CVS model by designating a single shared repository which people can synchronize with; this document explains how to do that. -Some basic familiarity with git is required. Having gone through +Some basic familiarity with Git is required. Having gone through linkgit:gittutorial[7] and linkgit:gitglossary[7] should be sufficient. @@ -81,7 +81,7 @@ other than `master`. Setting Up a Shared Repository ------------------------------ -We assume you have already created a git repository for your project, +We assume you have already created a Git repository for your project, possibly created from scratch or from a tarball (see linkgit:gittutorial[7]), or imported from an already existing CVS repository (see the next section). @@ -101,7 +101,7 @@ Next, give every team member read/write access to this repository. One easy way to do this is to give all the team members ssh access to the machine where the repository is hosted. If you don't want to give them a full shell on the machine, there is a restricted shell which only allows -users to do git pushes and pulls; see linkgit:git-shell[1]. +users to do Git pushes and pulls; see linkgit:git-shell[1]. Put all the committers in the same group, and make the repository writable by that group: @@ -125,7 +125,7 @@ of the project you are interested in and run linkgit:git-cvsimport[1]: $ git cvsimport -C <destination> <module> ------------------------------------------- -This puts a git archive of the named CVS module in the directory +This puts a Git archive of the named CVS module in the directory <destination>, which will be created if necessary. The import checks out from CVS every revision of every file. Reportedly @@ -133,8 +133,8 @@ cvsimport can average some twenty revisions per second, so for a medium-sized project this should not take more than a couple of minutes. Larger projects or remote repositories may take longer. -The main trunk is stored in the git branch named `origin`, and additional -CVS branches are stored in git branches with the same names. The most +The main trunk is stored in the Git branch named `origin`, and additional +CVS branches are stored in Git branches with the same names. The most recent version of the main trunk is also left checked out on the `master` branch, so you can start adding your own changes right away. @@ -157,13 +157,13 @@ points. You can use these, for example, to send all commits to the shared repository to a mailing list. See linkgit:githooks[5]. You can enforce finer grained permissions using update hooks. See -link:howto/update-hook-example.txt[Controlling access to branches using +link:howto/update-hook-example.html[Controlling access to branches using update hooks]. -Providing CVS Access to a git Repository +Providing CVS Access to a Git Repository ---------------------------------------- -It is also possible to provide true CVS access to a git repository, so +It is also possible to provide true CVS access to a Git repository, so that developers can still use CVS; see linkgit:git-cvsserver[1] for details. @@ -171,8 +171,8 @@ Alternative Development Models ------------------------------ CVS users are accustomed to giving a group of developers commit access to -a common repository. As we've seen, this is also possible with git. -However, the distributed nature of git allows other development models, +a common repository. As we've seen, this is also possible with Git. +However, the distributed nature of Git allows other development models, and you may want to first consider whether one of them might be a better fit for your project. diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt index 370624c17..c8b3e51c8 100644 --- a/Documentation/gitdiffcore.txt +++ b/Documentation/gitdiffcore.txt @@ -108,7 +108,7 @@ it changes it to: For the purpose of breaking a filepair, diffcore-break examines the extent of changes between the contents of the files before and after modification (i.e. the contents that have "bcd1234..." -and "0123456..." as their SHA1 content ID, in the above +and "0123456..." as their SHA-1 content ID, in the above example). The amount of deletion of original contents and insertion of new material are added together, and if it exceeds the "break score", the filepair is broken into two. The break @@ -168,11 +168,11 @@ a similarity score different from the default of 50% by giving a number after the "-M" or "-C" option (e.g. "-M8" to tell it to use 8/10 = 80%). -Note. When the "-C" option is used with `\--find-copies-harder` +Note. When the "-C" option is used with `--find-copies-harder` option, 'git diff-{asterisk}' commands feed unmodified filepairs to diffcore mechanism as well as modified ones. This lets the copy detector consider unmodified files as copy source candidates at -the expense of making it slower. Without `\--find-copies-harder`, +the expense of making it slower. Without `--find-copies-harder`, 'git diff-{asterisk}' commands can detect copies only if the file that was copied happened to have been modified in the same changeset. @@ -222,26 +222,35 @@ version prefixed with '+'. diffcore-pickaxe: For Detecting Addition/Deletion of Specified String --------------------------------------------------------------------- -This transformation is used to find filepairs that represent -changes that touch a specified string, and is controlled by the --S option and the `\--pickaxe-all` option to the 'git diff-{asterisk}' -commands. - -When diffcore-pickaxe is in use, it checks if there are -filepairs whose "result" side and whose "origin" side have -different number of specified string. Such a filepair represents -"the string appeared in this changeset". It also checks for the -opposite case that loses the specified string. - -When `\--pickaxe-all` is not in effect, diffcore-pickaxe leaves -only such filepairs that touch the specified string in its -output. When `\--pickaxe-all` is used, diffcore-pickaxe leaves all -filepairs intact if there is such a filepair, or makes the -output empty otherwise. The latter behaviour is designed to -make reviewing of the changes in the context of the whole +This transformation limits the set of filepairs to those that change +specified strings between the preimage and the postimage in a certain +way. -S<block of text> and -G<regular expression> options are used to +specify different ways these strings are sought. + +"-S<block of text>" detects filepairs whose preimage and postimage +have different number of occurrences of the specified block of text. +By definition, it will not detect in-file moves. Also, when a +changeset moves a file wholesale without affecting the interesting +string, diffcore-rename kicks in as usual, and `-S` omits the filepair +(since the number of occurrences of that string didn't change in that +rename-detected filepair). When used with `--pickaxe-regex`, treat +the <block of text> as an extended POSIX regular expression to match, +instead of a literal string. + +"-G<regular expression>" (mnemonic: grep) detects filepairs whose +textual diff has an added or a deleted line that matches the given +regular expression. This means that it will detect in-file (or what +rename-detection considers the same file) moves, which is noise. The +implementation runs diff twice and greps, and this can be quite +expensive. + +When `-S` or `-G` are used without `--pickaxe-all`, only filepairs +that match their respective criterion are kept in the output. When +`--pickaxe-all` is used, if even one filepair matches their respective +criterion in a changeset, the entire changeset is kept. This behavior +is designed to make reviewing changes in the context of the whole changeset easier. - diffcore-order: For Sorting the Output Based on Filenames --------------------------------------------------------- @@ -254,7 +263,7 @@ pattern. Filepairs that match a glob pattern on an earlier line in the file are output before ones that match a later line, and filepairs that do not match any glob pattern are output last. -As an example, a typical orderfile for the core git probably +As an example, a typical orderfile for the core Git probably would look like this: ------------------------------------------------ diff --git a/Documentation/gitglossary.txt b/Documentation/gitglossary.txt index d77a45aed..e52de7dbb 100644 --- a/Documentation/gitglossary.txt +++ b/Documentation/gitglossary.txt @@ -3,7 +3,7 @@ gitglossary(7) NAME ---- -gitglossary - A GIT Glossary +gitglossary - A Git Glossary SYNOPSIS -------- @@ -19,7 +19,7 @@ SEE ALSO linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:gitcvs-migration[7], -link:everyday.html[Everyday git], +link:everyday.html[Everyday Git], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index 28edefa20..d954bf6ba 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -3,7 +3,7 @@ githooks(5) NAME ---- -githooks - Hooks used by git +githooks - Hooks used by Git SYNOPSIS -------- @@ -73,7 +73,7 @@ pre-commit ~~~~~~~~~~ This hook is invoked by 'git commit', and can be bypassed -with `\--no-verify` option. It takes no parameter, and is +with `--no-verify` option. It takes no parameter, and is invoked before obtaining the proposed commit log message and making a commit. Exiting with non-zero status from this script causes the 'git commit' to abort. @@ -99,23 +99,23 @@ given); `template` (if a `-t` option was given or the configuration option `commit.template` is set); `merge` (if the commit is a merge or a `.git/MERGE_MSG` file exists); `squash` (if a `.git/SQUASH_MSG` file exists); or `commit`, followed by -a commit SHA1 (if a `-c`, `-C` or `\--amend` option was given). +a commit SHA-1 (if a `-c`, `-C` or `--amend` option was given). If the exit status is non-zero, 'git commit' will abort. The purpose of the hook is to edit the message file in place, and -it is not suppressed by the `\--no-verify` option. A non-zero exit +it is not suppressed by the `--no-verify` option. A non-zero exit means a failure of the hook and aborts the commit. It should not be used as replacement for pre-commit hook. -The sample `prepare-commit-msg` hook that comes with git comments +The sample `prepare-commit-msg` hook that comes with Git comments out the `Conflicts:` part of a merge's commit message. commit-msg ~~~~~~~~~~ This hook is invoked by 'git commit', and can be bypassed -with `\--no-verify` option. It takes a single parameter, the +with `--no-verify` option. It takes a single parameter, the name of the file that holds the proposed commit log message. Exiting with non-zero status causes the 'git commit' to abort. @@ -140,9 +140,11 @@ the outcome of 'git commit'. pre-rebase ~~~~~~~~~~ -This hook is called by 'git rebase' and can be used to prevent a branch -from getting rebased. - +This hook is called by 'git rebase' and can be used to prevent a +branch from getting rebased. The hook may be called with one or +two parameters. The first parameter is the upstream from which +the series was forked. The second parameter is the branch being +rebased, and is not set when rebasing the current branch. post-checkout ~~~~~~~~~~~~~ @@ -176,6 +178,35 @@ save and restore any form of metadata associated with the working tree (eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl for an example of how to do this. +pre-push +~~~~~~~~ + +This hook is called by 'git push' and can be used to prevent a push from taking +place. The hook is called with two parameters which provide the name and +location of the destination remote, if a named remote is not being used both +values will be the same. + +Information about what is to be pushed is provided on the hook's standard +input with lines of the form: + + <local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF + +For instance, if the command +git push origin master:foreign+ were run the +hook would receive a line like the following: + + refs/heads/master 67890 refs/heads/foreign 12345 + +although the full, 40-character SHA-1s would be supplied. If the foreign ref +does not yet exist the `<remote SHA-1>` will be 40 `0`. If a ref is to be +deleted, the `<local ref>` will be supplied as `(delete)` and the `<local +SHA-1>` will be 40 `0`. If the local commit was specified by something other +than a name which could be expanded (such as `HEAD~`, or a SHA-1) it will be +supplied as it was originally given. + +If this hook exits with a non-zero status, 'git push' will abort without +pushing anything. Information about why the push is rejected may be sent +to the user by writing to standard error. + [[pre-receive]] pre-receive ~~~~~~~~~~~ @@ -220,7 +251,7 @@ three parameters: - the name of the ref being updated, - the old object name stored in the ref, - - and the new objectname to be stored in the ref. + - and the new object name to be stored in the ref. A zero exit from the update hook allows the ref to be updated. Exiting with a non-zero status prevents 'git-receive-pack' @@ -275,7 +306,7 @@ for the user. The default 'post-receive' hook is empty, but there is a sample script `post-receive-email` provided in the `contrib/hooks` -directory in git distribution, which implements sending commit +directory in Git distribution, which implements sending commit emails. [[post-update]] @@ -303,7 +334,7 @@ them. When enabled, the default 'post-update' hook runs 'git update-server-info' to keep the information used by dumb transports (e.g., HTTP) up-to-date. If you are publishing -a git repository that is accessible via HTTP, you should +a Git repository that is accessible via HTTP, you should probably enable this hook. Both standard output and standard error output are forwarded to @@ -336,7 +367,7 @@ preceding SP is also omitted. Currently, no commands pass any 'extra-info'. The hook always runs after the automatic note copying (see -"notes.rewrite.<command>" in linkgit:git-config.txt) has happened, and +"notes.rewrite.<command>" in linkgit:git-config.txt[1]) has happened, and thus has access to these notes. The following command-specific comments apply: diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 2e7328b83..b08d34d84 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -7,18 +7,18 @@ gitignore - Specifies intentionally untracked files to ignore SYNOPSIS -------- -$GIT_DIR/info/exclude, .gitignore +$HOME/.config/git/ignore, $GIT_DIR/info/exclude, .gitignore DESCRIPTION ----------- A `gitignore` file specifies intentionally untracked files that -git should ignore. -Files already tracked by git are not affected; see the NOTES +Git should ignore. +Files already tracked by Git are not affected; see the NOTES below for details. Each line in a `gitignore` file specifies a pattern. -When deciding whether to ignore a path, git normally checks +When deciding whether to ignore a path, Git normally checks `gitignore` patterns from multiple sources, with the following order of precedence, from highest to lowest (within one level of precedence, the last matching pattern decides the outcome): @@ -41,21 +41,29 @@ precedence, the last matching pattern decides the outcome): variable 'core.excludesfile'. Which file to place a pattern in depends on how the pattern is meant to -be used. Patterns which should be version-controlled and distributed to -other repositories via clone (i.e., files that all developers will want -to ignore) should go into a `.gitignore` file. Patterns which are -specific to a particular repository but which do not need to be shared -with other related repositories (e.g., auxiliary files that live inside -the repository but are specific to one user's workflow) should go into -the `$GIT_DIR/info/exclude` file. Patterns which a user wants git to -ignore in all situations (e.g., backup or temporary files generated by -the user's editor of choice) generally go into a file specified by -`core.excludesfile` in the user's `~/.gitconfig`. - -The underlying git plumbing tools, such as +be used. + + * Patterns which should be version-controlled and distributed to + other repositories via clone (i.e., files that all developers will want + to ignore) should go into a `.gitignore` file. + + * Patterns which are + specific to a particular repository but which do not need to be shared + with other related repositories (e.g., auxiliary files that live inside + the repository but are specific to one user's workflow) should go into + the `$GIT_DIR/info/exclude` file. + + * Patterns which a user wants Git to + ignore in all situations (e.g., backup or temporary files generated by + the user's editor of choice) generally go into a file specified by + `core.excludesfile` in the user's `~/.gitconfig`. Its default value is + $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or + empty, $HOME/.config/git/ignore is used instead. + +The underlying Git plumbing tools, such as 'git ls-files' and 'git read-tree', read `gitignore` patterns specified by command-line options, or from -files specified by command-line options. Higher-level git +files specified by command-line options. Higher-level Git tools, such as 'git status' and 'git add', use patterns from the sources specified above. @@ -66,26 +74,32 @@ PATTERN FORMAT for readability. - A line starting with # serves as a comment. + Put a backslash ("`\`") in front of the first hash for patterns + that begin with a hash. - - An optional prefix '!' which negates the pattern; any + - An optional prefix "`!`" which negates the pattern; any matching file excluded by a previous pattern will become - included again. If a negated pattern matches, this will - override lower precedence patterns sources. + included again. It is not possible to re-include a file if a parent + directory of that file is excluded. Git doesn't list excluded + directories for performance reasons, so any patterns on contained + files have no effect, no matter where they are defined. + Put a backslash ("`\`") in front of the first "`!`" for patterns + that begin with a literal "`!`", for example, "`\!important!.txt`". - If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find a match with a directory. In other words, `foo/` will match a directory `foo` and paths underneath it, but will not match a regular file or a symbolic link `foo` (this is consistent - with the way how pathspec works in general in git). + with the way how pathspec works in general in Git). - - If the pattern does not contain a slash '/', git treats it as + - If the pattern does not contain a slash '/', Git treats it as a shell glob pattern and checks for a match against the pathname relative to the location of the `.gitignore` file (relative to the toplevel of the work tree if not from a `.gitignore` file). - - Otherwise, git treats the pattern as a shell glob suitable + - Otherwise, Git treats the pattern as a shell glob suitable for consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will not match a / in the pathname. For example, "Documentation/{asterisk}.html" matches @@ -96,11 +110,30 @@ PATTERN FORMAT For example, "/{asterisk}.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c". +Two consecutive asterisks ("`**`") in patterns matched against +full pathname may have special meaning: + + - A leading "`**`" followed by a slash means match in all + directories. For example, "`**/foo`" matches file or directory + "`foo`" anywhere, the same as pattern "`foo`". "`**/foo/bar`" + matches file or directory "`bar`" anywhere that is directly + under directory "`foo`". + + - A trailing "`/**`" matches everything inside. For example, + "`abc/**`" matches all files inside directory "`abc`", relative + to the location of the `.gitignore` file, with infinite depth. + + - A slash followed by two consecutive asterisks then a slash + matches zero or more directories. For example, "`a/**/b`" + matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on. + + - Other consecutive asterisks are considered invalid. + NOTES ----- The purpose of gitignore files is to ensure that certain files -not tracked by git remain untracked. +not tracked by Git remain untracked. To ignore uncommitted changes in a file that is already tracked, use 'git update-index {litdd}assume-unchanged'. @@ -148,13 +181,28 @@ Another example: $ echo '!/vmlinux*' >arch/foo/kernel/.gitignore -------------------------------------------------------------- -The second .gitignore prevents git from ignoring +The second .gitignore prevents Git from ignoring `arch/foo/kernel/vmlinux.lds.S`. +Example to exclude everything except a specific directory `foo/bar` +(note the `/*` - without the slash, the wildcard would also exclude +everything within `foo/bar`): + +-------------------------------------------------------------- + $ cat .gitignore + # exclude everything except directory foo/bar + /* + !/foo + /foo/* + !/foo/bar +-------------------------------------------------------------- + SEE ALSO -------- -linkgit:git-rm[1], linkgit:git-update-index[1], -linkgit:gitrepository-layout[5] +linkgit:git-rm[1], +linkgit:git-update-index[1], +linkgit:gitrepository-layout[5], +linkgit:git-check-ignore[1] GIT --- diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index a17a35493..1e9e38ae4 100644 --- a/Documentation/gitk.txt +++ b/Documentation/gitk.txt @@ -3,12 +3,12 @@ gitk(1) NAME ---- -gitk - The git repository browser +gitk - The Git repository browser SYNOPSIS -------- [verse] -'gitk' [<option>...] [<revs>] [--] [<path>...] +'gitk' [<options>] [<revision range>] [\--] [<path>...] DESCRIPTION ----------- @@ -16,21 +16,38 @@ Displays changes in a repository or a selected set of commits. This includes visualizing the commit graph, showing information related to each commit, and the files in the trees of each revision. -Historically, gitk was the first repository browser. It's written in tcl/tk -and started off in a separate repository but was later merged into the main -git repository. - OPTIONS ------- -To control which revisions to show, the command takes options applicable to -the 'git rev-list' command (see linkgit:git-rev-list[1]). -This manual page describes only the most -frequently used options. --n <number>:: ---max-count=<number>:: +To control which revisions to show, gitk supports most options +applicable to the 'git rev-list' command. It also supports a few +options applicable to the 'git diff-*' commands to control how the +changes each commit introduces are shown. Finally, it supports some +gitk-specific options. + +gitk generally only understands options with arguments in the +'sticked' form (see linkgit:gitcli[7]) due to limitations in the +command line parser. + +rev-list options and arguments +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This manual page describes only the most frequently used options. See +linkgit:git-rev-list[1] for a complete list. + +--all:: + + Show all refs (branches, tags, etc.). + +--branches[=<pattern>]:: +--tags[=<pattern>]:: +--remotes[=<pattern>]:: - Limits the number of commits to show. + Pretend as if all the branches (tags, remote branches, resp.) + are listed on the command line as '<commit>'. If '<pattern>' + is given, limit refs to ones matching given shell glob. If + pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the + end is implied. --since=<date>:: @@ -40,9 +57,9 @@ frequently used options. Show commits older than a specific date. ---all:: +--date-order:: - Show all branches. + Sort commits by date when possible. --merge:: @@ -51,19 +68,53 @@ frequently used options. that modify the conflicted files and do not exist on all the heads being merged. ---argscmd=<command>:: - Command to be run each time gitk has to determine the list of - <revs> to show. The command is expected to print on its standard - output a list of additional revs to be shown, one per line. - Use this instead of explicitly specifying <revs> if the set of - commits to show may vary between refreshes. +--left-right:: ---select-commit=<ref>:: + Mark which side of a symmetric diff a commit is reachable + from. Commits from the left side are prefixed with a `<` + symbol and those from the right with a `>` symbol. - Automatically select the specified commit after loading the graph. - Default behavior is equivalent to specifying '--select-commit=HEAD'. +--full-history:: + + When filtering history with '<path>...', does not prune some + history. (See "History simplification" in linkgit:git-log[1] + for a more detailed explanation.) + +--simplify-merges:: + + Additional option to '--full-history' to remove some needless + merges from the resulting history, as there are no selected + commits contributing to this merge. (See "History + simplification" in linkgit:git-log[1] for a more detailed + explanation.) -<revs>:: +--ancestry-path:: + + When given a range of commits to display + (e.g. 'commit1..commit2' or 'commit2 {caret}commit1'), only + display commits that exist directly on the ancestry chain + between the 'commit1' and 'commit2', i.e. commits that are + both descendants of 'commit1', and ancestors of 'commit2'. + (See "History simplification" in linkgit:git-log[1] for a more + detailed explanation.) + +-L<start>,<end>:<file>:: +-L:<regex>:<file>:: + + Trace the evolution of the line range given by "<start>,<end>" + (or the funcname regex <regex>) within the <file>. You may + not give any pathspec limiters. This is currently limited to + a walk starting from a single revision, i.e., you may only + give zero or one positive revision arguments. + You can specify this option more than once. ++ +*Note:* gitk (unlike linkgit:git-log[1]) currently only understands +this option if you specify it "glued together" with its argument. Do +*not* put a space after `-L`. ++ +include::line-range-format.txt[] + +<revision range>:: Limit the revisions to show. This can be either a single revision meaning show from the given revision and back, or it can be a range in @@ -78,6 +129,23 @@ frequently used options. avoid ambiguity with respect to revision names use "--" to separate the paths from any preceding options. +gitk-specific options +~~~~~~~~~~~~~~~~~~~~~ + +--argscmd=<command>:: + + Command to be run each time gitk has to determine the revision + range to show. The command is expected to print on its + standard output a list of additional revisions to be shown, + one per line. Use this instead of explicitly specifying a + '<revision range>' if the set of commits to show may vary + between refreshes. + +--select-commit=<ref>:: + + Select the specified commit after loading the graph. + Default behavior is equivalent to specifying '--select-commit=HEAD'. + Examples -------- gitk v2.6.12.. include/scsi drivers/scsi:: @@ -101,6 +169,13 @@ Files Gitk creates the .gitk file in your $HOME directory to store preferences such as display options, font, and colors. +History +------- +Gitk was the first graphical repository browser. It's written in +tcl/tk and started off in a separate repository but was later merged +into the main Git repository. + + SEE ALSO -------- 'qgit(1)':: @@ -108,10 +183,10 @@ SEE ALSO 'gitview(1)':: A repository browser written in Python using Gtk. It's based on - 'bzrk(1)' and distributed in the contrib area of the git repository. + 'bzrk(1)' and distributed in the contrib area of the Git repository. 'tig(1)':: - A minimal repository browser and git tool output highlighter written + A minimal repository browser and Git tool output highlighter written in C using Ncurses. GIT diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt index 4040941e5..347a9f76e 100644 --- a/Documentation/gitmodules.txt +++ b/Documentation/gitmodules.txt @@ -13,26 +13,30 @@ $GIT_WORK_DIR/.gitmodules DESCRIPTION ----------- -The `.gitmodules` file, located in the top-level directory of a git +The `.gitmodules` file, located in the top-level directory of a Git working tree, is a text file with a syntax matching the requirements of linkgit:git-config[1]. The file contains one subsection per submodule, and the subsection value -is the name of the submodule. Each submodule section also contains the +is the name of the submodule. The name is set to the path where the +submodule has been added unless it was customized with the '--name' +option of 'git submodule add'. Each submodule section also contains the following required keys: submodule.<name>.path:: - Defines the path, relative to the top-level directory of the git + Defines the path, relative to the top-level directory of the Git working tree, where the submodule is expected to be checked out. The path name must not end with a `/`. All submodule paths must be unique within the .gitmodules file. submodule.<name>.url:: - Defines an url from where the submodule repository can be cloned. + Defines a URL from which the submodule repository can be cloned. This may be either an absolute URL ready to be passed to linkgit:git-clone[1] or (if it begins with ./ or ../) a location relative to the superproject's origin repository. +In addition, there are a number of optional keys: + submodule.<name>.update:: Defines what to do when the submodule is updated by the superproject. If 'checkout' (the default), the new commit specified in the @@ -41,8 +45,16 @@ submodule.<name>.update:: the commit specified in the superproject. If 'merge', the commit specified in the superproject will be merged into the current branch in the submodule. + If 'none', the submodule with name `$name` will not be updated + by default. + This config option is overridden if 'git submodule update' is given - the '--merge' or '--rebase' options. + the '--merge', '--rebase' or '--checkout' options. + +submodule.<name>.branch:: + A remote branch name for tracking updates in the upstream submodule. + If the option is not specified, it defaults to 'master'. See the + `--remote` documentation in linkgit:git-submodule[1] for details. submodule.<name>.fetchRecurseSubmodules:: This option can be used to control recursive fetching of this @@ -65,7 +77,8 @@ submodule.<name>.ignore:: the superproject, the setting there will override the one found in .gitmodules. Both settings can be overridden on the command line by using the - "--ignore-submodule" option. + "--ignore-submodule" option. The 'git submodule' commands are not + affected by this setting. EXAMPLES @@ -84,7 +97,7 @@ Consider the following .gitmodules file: This defines two submodules, `libfoo` and `libbar`. These are expected to be checked out in the paths 'include/foo' and 'include/bar', and for both -submodules an url is specified which can be used for cloning the submodules. +submodules a URL is specified which can be used for cloning the submodules. SEE ALSO -------- diff --git a/Documentation/gitnamespaces.txt b/Documentation/gitnamespaces.txt new file mode 100644 index 000000000..7685e3651 --- /dev/null +++ b/Documentation/gitnamespaces.txt @@ -0,0 +1,82 @@ +gitnamespaces(7) +================ + +NAME +---- +gitnamespaces - Git namespaces + +SYNOPSIS +-------- +[verse] +GIT_NAMESPACE=<namespace> 'git upload-pack' +GIT_NAMESPACE=<namespace> 'git receive-pack' + + +DESCRIPTION +----------- + +Git supports dividing the refs of a single repository into multiple +namespaces, each of which has its own branches, tags, and HEAD. Git can +expose each namespace as an independent repository to pull from and push +to, while sharing the object store, and exposing all the refs to +operations such as linkgit:git-gc[1]. + +Storing multiple repositories as namespaces of a single repository +avoids storing duplicate copies of the same objects, such as when +storing multiple branches of the same source. The alternates mechanism +provides similar support for avoiding duplicates, but alternates do not +prevent duplication between new objects added to the repositories +without ongoing maintenance, while namespaces do. + +To specify a namespace, set the `GIT_NAMESPACE` environment variable to +the namespace. For each ref namespace, Git stores the corresponding +refs in a directory under `refs/namespaces/`. For example, +`GIT_NAMESPACE=foo` will store refs under `refs/namespaces/foo/`. You +can also specify namespaces via the `--namespace` option to +linkgit:git[1]. + +Note that namespaces which include a `/` will expand to a hierarchy of +namespaces; for example, `GIT_NAMESPACE=foo/bar` will store refs under +`refs/namespaces/foo/refs/namespaces/bar/`. This makes paths in +`GIT_NAMESPACE` behave hierarchically, so that cloning with +`GIT_NAMESPACE=foo/bar` produces the same result as cloning with +`GIT_NAMESPACE=foo` and cloning from that repo with `GIT_NAMESPACE=bar`. It +also avoids ambiguity with strange namespace paths such as `foo/refs/heads/`, +which could otherwise generate directory/file conflicts within the `refs` +directory. + +linkgit:git-upload-pack[1] and linkgit:git-receive-pack[1] rewrite the +names of refs as specified by `GIT_NAMESPACE`. git-upload-pack and +git-receive-pack will ignore all references outside the specified +namespace. + +The smart HTTP server, linkgit:git-http-backend[1], will pass +GIT_NAMESPACE through to the backend programs; see +linkgit:git-http-backend[1] for sample configuration to expose +repository namespaces as repositories. + +For a simple local test, you can use linkgit:git-remote-ext[1]: + +---------- +git clone ext::'git --namespace=foo %s /tmp/prefixed.git' +---------- + +SECURITY +-------- + +Anyone with access to any namespace within a repository can potentially +access objects from any other namespace stored in the same repository. +You can't directly say "give me object ABCD" if you don't have a ref to +it, but you can do some other sneaky things like: + +. Claiming to push ABCD, at which point the server will optimize out the + need for you to actually send it. Now you have a ref to ABCD and can + fetch it (claiming not to have it, of course). + +. Requesting other refs, claiming that you have ABCD, at which point the + server may generate deltas against ABCD. + +None of this causes a problem if you only host public repositories, or +if everyone who may read one namespace may also read everything in every +other namespace (for instance, if everyone in an organization has read +permission to every repository). diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt new file mode 100644 index 000000000..c2908db76 --- /dev/null +++ b/Documentation/gitremote-helpers.txt @@ -0,0 +1,455 @@ +gitremote-helpers(1) +==================== + +NAME +---- +gitremote-helpers - Helper programs to interact with remote repositories + +SYNOPSIS +-------- +[verse] +'git remote-<transport>' <repository> [<URL>] + +DESCRIPTION +----------- + +Remote helper programs are normally not used directly by end users, +but they are invoked by Git when it needs to interact with remote +repositories Git does not support natively. A given helper will +implement a subset of the capabilities documented here. When Git +needs to interact with a repository using a remote helper, it spawns +the helper as an independent process, sends commands to the helper's +standard input, and expects results from the helper's standard +output. Because a remote helper runs as an independent process from +Git, there is no need to re-link Git to add a new helper, nor any +need to link the helper with the implementation of Git. + +Every helper must support the "capabilities" command, which Git +uses to determine what other commands the helper will accept. Those +other commands can be used to discover and update remote refs, +transport objects between the object database and the remote repository, +and update the local object store. + +Git comes with a "curl" family of remote helpers, that handle various +transport protocols, such as 'git-remote-http', 'git-remote-https', +'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities +'fetch', 'option', and 'push'. + +INVOCATION +---------- + +Remote helper programs are invoked with one or (optionally) two +arguments. The first argument specifies a remote repository as in Git; +it is either the name of a configured remote or a URL. The second +argument specifies a URL; it is usually of the form +'<transport>://<address>', but any arbitrary string is possible. +The 'GIT_DIR' environment variable is set up for the remote helper +and can be used to determine where to store additional data or from +which directory to invoke auxiliary Git commands. + +When Git encounters a URL of the form '<transport>://<address>', where +'<transport>' is a protocol that it cannot handle natively, it +automatically invokes 'git remote-<transport>' with the full URL as +the second argument. If such a URL is encountered directly on the +command line, the first argument is the same as the second, and if it +is encountered in a configured remote, the first argument is the name +of that remote. + +A URL of the form '<transport>::<address>' explicitly instructs Git to +invoke 'git remote-<transport>' with '<address>' as the second +argument. If such a URL is encountered directly on the command line, +the first argument is '<address>', and if it is encountered in a +configured remote, the first argument is the name of that remote. + +Additionally, when a configured remote has 'remote.<name>.vcs' set to +'<transport>', Git explicitly invokes 'git remote-<transport>' with +'<name>' as the first argument. If set, the second argument is +'remote.<name>.url'; otherwise, the second argument is omitted. + +INPUT FORMAT +------------ + +Git sends the remote helper a list of commands on standard input, one +per line. The first command is always the 'capabilities' command, in +response to which the remote helper must print a list of the +capabilities it supports (see below) followed by a blank line. The +response to the capabilities command determines what commands Git uses +in the remainder of the command stream. + +The command stream is terminated by a blank line. In some cases +(indicated in the documentation of the relevant commands), this blank +line is followed by a payload in some other protocol (e.g., the pack +protocol), while in others it indicates the end of input. + +Capabilities +~~~~~~~~~~~~ + +Each remote helper is expected to support only a subset of commands. +The operations a helper supports are declared to Git in the response +to the `capabilities` command (see COMMANDS, below). + +In the following, we list all defined capabilities and for +each we list which commands a helper with that capability +must provide. + +Capabilities for Pushing +^^^^^^^^^^^^^^^^^^^^^^^^ +'connect':: + Can attempt to connect to 'git receive-pack' (for pushing), + 'git upload-pack', etc for communication using + git's native packfile protocol. This + requires a bidirectional, full-duplex connection. ++ +Supported commands: 'connect'. + +'push':: + Can discover remote refs and push local commits and the + history leading up to them to new or existing remote refs. ++ +Supported commands: 'list for-push', 'push'. + +'export':: + Can discover remote refs and push specified objects from a + fast-import stream to remote refs. ++ +Supported commands: 'list for-push', 'export'. + +If a helper advertises 'connect', Git will use it if possible and +fall back to another capability if the helper requests so when +connecting (see the 'connect' command under COMMANDS). +When choosing between 'push' and 'export', Git prefers 'push'. +Other frontends may have some other order of preference. + +'no-private-update':: + When using the 'refspec' capability, git normally updates the + private ref on successful push. This update is disabled when + the remote-helper declares the capability 'no-private-update'. + + +Capabilities for Fetching +^^^^^^^^^^^^^^^^^^^^^^^^^ +'connect':: + Can try to connect to 'git upload-pack' (for fetching), + 'git receive-pack', etc for communication using the + Git's native packfile protocol. This + requires a bidirectional, full-duplex connection. ++ +Supported commands: 'connect'. + +'fetch':: + Can discover remote refs and transfer objects reachable from + them to the local object store. ++ +Supported commands: 'list', 'fetch'. + +'import':: + Can discover remote refs and output objects reachable from + them as a stream in fast-import format. ++ +Supported commands: 'list', 'import'. + +'check-connectivity':: + Can guarantee that when a clone is requested, the received + pack is self contained and is connected. + +If a helper advertises 'connect', Git will use it if possible and +fall back to another capability if the helper requests so when +connecting (see the 'connect' command under COMMANDS). +When choosing between 'fetch' and 'import', Git prefers 'fetch'. +Other frontends may have some other order of preference. + +Miscellaneous capabilities +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +'option':: + For specifying settings like `verbosity` (how much output to + write to stderr) and `depth` (how much history is wanted in the + case of a shallow clone) that affect how other commands are + carried out. + +'refspec' <refspec>:: + For remote helpers that implement 'import' or 'export', this capability + allows the refs to be constrained to a private namespace, instead of + writing to refs/heads or refs/remotes directly. + It is recommended that all importers providing the 'import' + capability use this. It's mandatory for 'export'. ++ +A helper advertising the capability +`refspec refs/heads/*:refs/svn/origin/branches/*` +is saying that, when it is asked to `import refs/heads/topic`, the +stream it outputs will update the `refs/svn/origin/branches/topic` +ref. ++ +This capability can be advertised multiple times. The first +applicable refspec takes precedence. The left-hand of refspecs +advertised with this capability must cover all refs reported by +the list command. If no 'refspec' capability is advertised, +there is an implied `refspec *:*`. ++ +When writing remote-helpers for decentralized version control +systems, it is advised to keep a local copy of the repository to +interact with, and to let the private namespace refs point to this +local repository, while the refs/remotes namespace is used to track +the remote repository. + +'bidi-import':: + This modifies the 'import' capability. + The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers + to retrieve information about blobs and trees that already exist in + fast-import's memory. This requires a channel from fast-import to the + remote-helper. + If it is advertised in addition to "import", Git establishes a pipe from + fast-import to the remote-helper's stdin. + It follows that Git and fast-import are both connected to the + remote-helper's stdin. Because Git can send multiple commands to + the remote-helper it is required that helpers that use 'bidi-import' + buffer all 'import' commands of a batch before sending data to fast-import. + This is to prevent mixing commands and fast-import responses on the + helper's stdin. + +'export-marks' <file>:: + This modifies the 'export' capability, instructing Git to dump the + internal marks table to <file> when complete. For details, + read up on '--export-marks=<file>' in linkgit:git-fast-export[1]. + +'import-marks' <file>:: + This modifies the 'export' capability, instructing Git to load the + marks specified in <file> before processing any input. For details, + read up on '--import-marks=<file>' in linkgit:git-fast-export[1]. + +'signed-tags':: + This modifies the 'export' capability, instructing Git to pass + '--signed-tags=verbatim' to linkgit:git-fast-export[1]. In the + absence of this capability, Git will use '--signed-tags=warn-strip'. + + + +COMMANDS +-------- + +Commands are given by the caller on the helper's standard input, one per line. + +'capabilities':: + Lists the capabilities of the helper, one per line, ending + with a blank line. Each capability may be preceded with '*', + which marks them mandatory for Git versions using the remote + helper to understand. Any unknown mandatory capability is a + fatal error. ++ +Support for this command is mandatory. + +'list':: + Lists the refs, one per line, in the format "<value> <name> + [<attr> ...]". The value may be a hex sha1 hash, "@<dest>" for + a symref, or "?" to indicate that the helper could not get the + value of the ref. A space-separated list of attributes follows + the name; unrecognized attributes are ignored. The list ends + with a blank line. ++ +See REF LIST ATTRIBUTES for a list of currently defined attributes. ++ +Supported if the helper has the "fetch" or "import" capability. + +'list for-push':: + Similar to 'list', except that it is used if and only if + the caller wants to the resulting ref list to prepare + push commands. + A helper supporting both push and fetch can use this + to distinguish for which operation the output of 'list' + is going to be used, possibly reducing the amount + of work that needs to be performed. ++ +Supported if the helper has the "push" or "export" capability. + +'option' <name> <value>:: + Sets the transport helper option <name> to <value>. Outputs a + single line containing one of 'ok' (option successfully set), + 'unsupported' (option not recognized) or 'error <msg>' + (option <name> is supported but <value> is not valid + for it). Options should be set before other commands, + and may influence the behavior of those commands. ++ +See OPTIONS for a list of currently defined options. ++ +Supported if the helper has the "option" capability. + +'fetch' <sha1> <name>:: + Fetches the given object, writing the necessary objects + to the database. Fetch commands are sent in a batch, one + per line, terminated with a blank line. + Outputs a single blank line when all fetch commands in the + same batch are complete. Only objects which were reported + in the output of 'list' with a sha1 may be fetched this way. ++ +Optionally may output a 'lock <file>' line indicating a file under +GIT_DIR/objects/pack which is keeping a pack until refs can be +suitably updated. ++ +If option 'check-connectivity' is requested, the helper must output +'connectivity-ok' if the clone is self-contained and connected. ++ +Supported if the helper has the "fetch" capability. + +'push' +<src>:<dst>:: + Pushes the given local <src> commit or branch to the + remote branch described by <dst>. A batch sequence of + one or more 'push' commands is terminated with a blank line + (if there is only one reference to push, a single 'push' command + is followed by a blank line). For example, the following would + be two batches of 'push', the first asking the remote-helper + to push the local ref 'master' to the remote ref 'master' and + the local 'HEAD' to the remote 'branch', and the second + asking to push ref 'foo' to ref 'bar' (forced update requested + by the '+'). ++ +------------ +push refs/heads/master:refs/heads/master +push HEAD:refs/heads/branch +\n +push +refs/heads/foo:refs/heads/bar +\n +------------ ++ +Zero or more protocol options may be entered after the last 'push' +command, before the batch's terminating blank line. ++ +When the push is complete, outputs one or more 'ok <dst>' or +'error <dst> <why>?' lines to indicate success or failure of +each pushed ref. The status report output is terminated by +a blank line. The option field <why> may be quoted in a C +style string if it contains an LF. ++ +Supported if the helper has the "push" capability. + +'import' <name>:: + Produces a fast-import stream which imports the current value + of the named ref. It may additionally import other refs as + needed to construct the history efficiently. The script writes + to a helper-specific private namespace. The value of the named + ref should be written to a location in this namespace derived + by applying the refspecs from the "refspec" capability to the + name of the ref. ++ +Especially useful for interoperability with a foreign versioning +system. ++ +Just like 'push', a batch sequence of one or more 'import' is +terminated with a blank line. For each batch of 'import', the remote +helper should produce a fast-import stream terminated by a 'done' +command. ++ +Note that if the 'bidi-import' capability is used the complete batch +sequence has to be buffered before starting to send data to fast-import +to prevent mixing of commands and fast-import responses on the helper's +stdin. ++ +Supported if the helper has the "import" capability. + +'export':: + Instructs the remote helper that any subsequent input is + part of a fast-import stream (generated by 'git fast-export') + containing objects which should be pushed to the remote. ++ +Especially useful for interoperability with a foreign versioning +system. ++ +The 'export-marks' and 'import-marks' capabilities, if specified, +affect this command in so far as they are passed on to 'git +fast-export', which then will load/store a table of marks for +local objects. This can be used to implement for incremental +operations. ++ +Supported if the helper has the "export" capability. + +'connect' <service>:: + Connects to given service. Standard input and standard output + of helper are connected to specified service (git prefix is + included in service name so e.g. fetching uses 'git-upload-pack' + as service) on remote side. Valid replies to this command are + empty line (connection established), 'fallback' (no smart + transport support, fall back to dumb transports) and just + exiting with error message printed (can't connect, don't + bother trying to fall back). After line feed terminating the + positive (empty) response, the output of service starts. After + the connection ends, the remote helper exits. ++ +Supported if the helper has the "connect" capability. + +If a fatal error occurs, the program writes the error message to +stderr and exits. The caller should expect that a suitable error +message has been printed if the child closes the connection without +completing a valid response for the current command. + +Additional commands may be supported, as may be determined from +capabilities reported by the helper. + +REF LIST ATTRIBUTES +------------------- + +The 'list' command produces a list of refs in which each ref +may be followed by a list of attributes. The following ref list +attributes are defined. + +'unchanged':: + This ref is unchanged since the last import or fetch, although + the helper cannot necessarily determine what value that produced. + +OPTIONS +------- + +The following options are defined and (under suitable circumstances) +set by Git if the remote helper has the 'option' capability. + +'option verbosity' <n>:: + Changes the verbosity of messages displayed by the helper. + A value of 0 for <n> means that processes operate + quietly, and the helper produces only error output. + 1 is the default level of verbosity, and higher values + of <n> correspond to the number of -v flags passed on the + command line. + +'option progress' \{'true'|'false'\}:: + Enables (or disables) progress messages displayed by the + transport helper during a command. + +'option depth' <depth>:: + Deepens the history of a shallow repository. + +'option followtags' \{'true'|'false'\}:: + If enabled the helper should automatically fetch annotated + tag objects if the object the tag points at was transferred + during the fetch command. If the tag is not fetched by + the helper a second fetch command will usually be sent to + ask for the tag specifically. Some helpers may be able to + use this option to avoid a second network connection. + +'option dry-run' \{'true'|'false'\}: + If true, pretend the operation completed successfully, + but don't actually change any repository data. For most + helpers this only applies to the 'push', if supported. + +'option servpath <c-style-quoted-path>':: + Sets service path (--upload-pack, --receive-pack etc.) for + next connect. Remote helper may support this option, but + must not rely on this option being set before + connect request occurs. + +'option check-connectivity' \{'true'|'false'\}:: + Request the helper to check connectivity of a clone. + +'option cloning \{'true'|'false'\}:: + Notify the helper this is a clone request (i.e. the current + repository is guaranteed empty). + +'option update-shallow \{'true'|'false'\}:: + Allow to extend .git/shallow if the new refs require it. + +SEE ALSO +-------- +linkgit:git-remote[1] + +linkgit:git-remote-testgit[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt index eb3d04078..aa03882dd 100644 --- a/Documentation/gitrepository-layout.txt +++ b/Documentation/gitrepository-layout.txt @@ -12,43 +12,48 @@ $GIT_DIR/* DESCRIPTION ----------- -You may find these things in your git repository (`.git` -directory for a repository associated with your working tree, or -`<project>.git` directory for a public 'bare' repository. It is -also possible to have a working tree where `.git` is a plain -ASCII file containing `gitdir: <path>`, i.e. the path to the -real git repository). +A Git repository comes in two different flavours: + + * a `.git` directory at the root of the working tree; + + * a `<project>.git` directory that is a 'bare' repository + (i.e. without its own working tree), that is typically used for + exchanging histories with others by pushing into it and fetching + from it. + +*Note*: Also you can have a plain text file `.git` at the root of +your working tree, containing `gitdir: <path>` to point at the real +directory that has the repository. This mechanism is often used for +a working tree of a submodule checkout, to allow you in the +containing superproject to `git checkout` a branch that does not +have the submodule. The `checkout` has to remove the entire +submodule working tree, without losing the submodule repository. + +These things may exist in a Git repository. objects:: Object store associated with this repository. Usually an object store is self sufficient (i.e. all the objects that are referred to by an object found in it are also - found in it), but there are couple of ways to violate - it. + found in it), but there are a few ways to violate it. + -. You could populate the repository by running a commit walker -without `-a` option. Depending on which options are given, you -could have only commit objects without associated blobs and -trees this way, for example. A repository with this kind of -incomplete object store is not suitable to be published to the -outside world but sometimes useful for private repository. -. You also could have an incomplete but locally usable repository -by cloning shallowly. See linkgit:git-clone[1]. -. You can be using `objects/info/alternates` mechanism, or -`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanism to 'borrow' +. You could have an incomplete but locally usable repository +by creating a shallow clone. See linkgit:git-clone[1]. +. You could be using the `objects/info/alternates` or +`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanisms to 'borrow' objects from other object stores. A repository with this kind of incomplete object store is not suitable to be published for use with dumb transports but otherwise is OK as long as -`objects/info/alternates` points at the right object stores -it borrows from. +`objects/info/alternates` points at the object stores it +borrows from. objects/[0-9a-f][0-9a-f]:: - Traditionally, each object is stored in its own file. - They are split into 256 subdirectories using the first - two letters from its object name to keep the number of - directory entries `objects` directory itself needs to - hold. Objects found here are often called 'unpacked' - (or 'loose') objects. + A newly created object is stored in its own file. + The objects are splayed over 256 subdirectories using + the first two characters of the sha1 object name to + keep the number of directory entries in `objects` + itself to a manageable number. Objects found + here are often called 'unpacked' (or 'loose') objects. objects/pack:: Packs (files that store many object in compressed form, @@ -85,7 +90,7 @@ objects/info/http-alternates:: refs:: References are stored in subdirectories of this - directory. The 'git prune' command knows to keep + directory. The 'git prune' command knows to preserve objects reachable from refs found in this directory and its subdirectories. @@ -100,6 +105,12 @@ refs/remotes/`name`:: records tip-of-the-tree commit objects of branches copied from a remote repository. +refs/replace/`<obj-sha1>`:: + records the SHA-1 of the object that replaces `<obj-sha1>`. + This is similar to info/grafts and is internally used and + maintained by linkgit:git-replace[1]. Such refs can be exchanged + between repositories while grafts are not. + packed-refs:: records the same information as refs/heads/, refs/tags/, and friends record in a more efficient way. See @@ -109,7 +120,7 @@ HEAD:: A symref (see glossary) to the `refs/heads/` namespace describing the currently active branch. It does not mean much if the repository is not associated with any working tree - (i.e. a 'bare' repository), but a valid git repository + (i.e. a 'bare' repository), but a valid Git repository *must* have the HEAD file; some porcelains may use it to guess the designated "default" branch of the repository (usually 'master'). It is legal if the named branch @@ -119,19 +130,20 @@ HEAD:: + HEAD can also record a specific commit directly, instead of being a symref to point at the current branch. Such a state -is often called 'detached HEAD', and almost all commands work -identically as normal. See linkgit:git-checkout[1] for -details. +is often called 'detached HEAD.' See linkgit:git-checkout[1] +for details. branches:: A slightly deprecated way to store shorthands to be used - to specify URL to 'git fetch', 'git pull' and 'git push' - commands is to store a file in `branches/<name>` and - give 'name' to these commands in place of 'repository' - argument. + to specify a URL to 'git fetch', 'git pull' and 'git push'. + A file can be stored as `branches/<name>` and then + 'name' can be given to these commands in place of + 'repository' argument. See the REMOTES section in + linkgit:git-fetch[1] for details. This mechanism is legacy + and not likely to be found in modern repositories. hooks:: - Hooks are customization scripts used by various git + Hooks are customization scripts used by various Git commands. A handful of sample hooks are installed when 'git init' is run, but all of them are disabled by default. To enable, the `.sample` suffix has to be @@ -169,13 +181,19 @@ info/exclude:: This file, by convention among Porcelains, stores the exclude pattern list. `.gitignore` is the per-directory ignore file. 'git status', 'git add', 'git rm' and - 'git clean' look at it but the core git commands do not look + 'git clean' look at it but the core Git commands do not look at it. See also: linkgit:gitignore[5]. +info/sparse-checkout:: + This file stores sparse checkout patterns. + See also: linkgit:git-read-tree[1]. + remotes:: - Stores shorthands to be used to give URL and default - refnames to interact with remote repository to - 'git fetch', 'git pull' and 'git push' commands. + Stores shorthands for URL and default refnames for use + when interacting with remote repositories via 'git fetch', + 'git pull' and 'git push' commands. See the REMOTES section + in linkgit:git-fetch[1] for details. This mechanism is legacy + and not likely to be found in modern repositories. logs:: Records of changes made to refs are stored in this @@ -193,6 +211,9 @@ shallow:: and maintained by shallow clone mechanism. See `--depth` option to linkgit:git-clone[1] and linkgit:git-fetch[1]. +modules:: + Contains the git-repositories of the submodules. + SEE ALSO -------- linkgit:git-init[1], diff --git a/Documentation/gitrevisions.txt b/Documentation/gitrevisions.txt index fc4789f98..c0ed6d192 100644 --- a/Documentation/gitrevisions.txt +++ b/Documentation/gitrevisions.txt @@ -3,7 +3,7 @@ gitrevisions(7) NAME ---- -gitrevisions - specifying revisions and ranges for git +gitrevisions - specifying revisions and ranges for Git SYNOPSIS -------- diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt index f1e4422ac..3109ea8aa 100644 --- a/Documentation/gittutorial-2.txt +++ b/Documentation/gittutorial-2.txt @@ -3,7 +3,7 @@ gittutorial-2(7) NAME ---- -gittutorial-2 - A tutorial introduction to git: part two +gittutorial-2 - A tutorial introduction to Git: part two SYNOPSIS -------- @@ -16,11 +16,11 @@ DESCRIPTION You should work through linkgit:gittutorial[7] before reading this tutorial. The goal of this tutorial is to introduce two fundamental pieces of -git's architecture--the object database and the index file--and to +Git's architecture--the object database and the index file--and to provide the reader with everything necessary to understand the rest -of the git documentation. +of the Git documentation. -The git object database +The Git object database ----------------------- Let's start a new project and create a small amount of history: @@ -34,33 +34,33 @@ $ echo 'hello world' > file.txt $ git add . $ git commit -a -m "initial commit" [master (root-commit) 54196cc] initial commit - 1 files changed, 1 insertions(+), 0 deletions(-) + 1 file changed, 1 insertion(+) create mode 100644 file.txt $ echo 'hello world!' >file.txt $ git commit -a -m "add emphasis" [master c4d59f3] add emphasis - 1 files changed, 1 insertions(+), 1 deletions(-) + 1 file changed, 1 insertion(+), 1 deletion(-) ------------------------------------------------ -What are the 7 digits of hex that git responded to the commit with? +What are the 7 digits of hex that Git responded to the commit with? We saw in part one of the tutorial that commits have names like this. -It turns out that every object in the git history is stored under -a 40-digit hex name. That name is the SHA1 hash of the object's -contents; among other things, this ensures that git will never store -the same data twice (since identical data is given an identical SHA1 -name), and that the contents of a git object will never change (since +It turns out that every object in the Git history is stored under +a 40-digit hex name. That name is the SHA-1 hash of the object's +contents; among other things, this ensures that Git will never store +the same data twice (since identical data is given an identical SHA-1 +name), and that the contents of a Git object will never change (since that would change the object's name as well). The 7 char hex strings here are simply the abbreviation of such 40 character long strings. Abbreviations can be used everywhere where the 40 character strings can be used, so long as they are unambiguous. It is expected that the content of the commit object you created while -following the example above generates a different SHA1 hash than +following the example above generates a different SHA-1 hash than the one shown above because the commit object records the time when it was created and the name of the person performing the commit. -We can ask git about this particular object with the `cat-file` +We can ask Git about this particular object with the `cat-file` command. Don't copy the 40 hex digits from this example but use those from your own version. Note that you can shorten it to only a few characters to save yourself typing all 40 hex digits: @@ -80,14 +80,14 @@ A tree can refer to one or more "blob" objects, each corresponding to a file. In addition, a tree can also refer to other tree objects, thus creating a directory hierarchy. You can examine the contents of any tree using ls-tree (remember that a long enough initial portion -of the SHA1 will also work): +of the SHA-1 will also work): ------------------------------------------------ $ git ls-tree 92b8b694 100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad file.txt ------------------------------------------------ -Thus we see that this tree has one file in it. The SHA1 hash is a +Thus we see that this tree has one file in it. The SHA-1 hash is a reference to that file's data: ------------------------------------------------ @@ -102,11 +102,11 @@ $ git cat-file blob 3b18e512 hello world ------------------------------------------------ -Note that this is the old file data; so the object that git named in +Note that this is the old file data; so the object that Git named in its response to the initial tree was a tree with a snapshot of the directory state that was recorded by the first commit. -All of these objects are stored under their SHA1 names inside the git +All of these objects are stored under their SHA-1 names inside the Git directory: ------------------------------------------------ @@ -142,7 +142,7 @@ ref: refs/heads/master As you can see, this tells us which branch we're currently on, and it tells us this by naming a file under the .git directory, which itself -contains a SHA1 name referring to a commit object, which we can +contains a SHA-1 name referring to a commit object, which we can examine with cat-file: ------------------------------------------------ @@ -191,7 +191,7 @@ Besides blobs, trees, and commits, the only remaining type of object is a "tag", which we won't discuss here; refer to linkgit:git-tag[1] for details. -So now we know how git uses the object database to represent a +So now we know how Git uses the object database to represent a project's history: * "commit" objects refer to "tree" objects representing the @@ -208,7 +208,7 @@ project's history: Note, by the way, that lots of commands take a tree as an argument. But as we can see above, a tree can be referred to in many different -ways--by the SHA1 name for that tree, by the name of a commit that +ways--by the SHA-1 name for that tree, by the name of a commit that refers to the tree, by the name of a branch whose head refers to that tree, etc.--and most such commands can accept any of these names. @@ -403,21 +403,21 @@ What next? At this point you should know everything necessary to read the man pages for any of the git commands; one good place to start would be -with the commands mentioned in link:everyday.html[Everyday git]. You +with the commands mentioned in link:everyday.html[Everyday Git]. You should be able to find any unknown jargon in linkgit:gitglossary[7]. The link:user-manual.html[Git User's Manual] provides a more -comprehensive introduction to git. +comprehensive introduction to Git. linkgit:gitcvs-migration[7] explains how to -import a CVS repository into git, and shows how to use git in a +import a CVS repository into Git, and shows how to use Git in a CVS-like way. -For some interesting examples of git use, see the +For some interesting examples of Git use, see the link:howto-index.html[howtos]. -For git developers, linkgit:gitcore-tutorial[7] goes -into detail on the lower-level git mechanisms involved in, for +For Git developers, linkgit:gitcore-tutorial[7] goes +into detail on the lower-level Git mechanisms involved in, for example, creating a new commit. SEE ALSO @@ -427,7 +427,7 @@ linkgit:gitcvs-migration[7], linkgit:gitcore-tutorial[7], linkgit:gitglossary[7], linkgit:git-help[1], -link:everyday.html[Everyday git], +link:everyday.html[Everyday Git], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index dee050567..826219631 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -3,7 +3,7 @@ gittutorial(7) NAME ---- -gittutorial - A tutorial introduction to git (for version 1.5.1 or newer) +gittutorial - A tutorial introduction to Git (for version 1.5.1 or newer) SYNOPSIS -------- @@ -13,10 +13,10 @@ git * DESCRIPTION ----------- -This tutorial explains how to import a new project into git, make +This tutorial explains how to import a new project into Git, make changes to it, and share changes with other developers. -If you are instead primarily interested in using git to fetch a project, +If you are instead primarily interested in using Git to fetch a project, for example, to test the latest version, you may prefer to start with the first two chapters of link:user-manual.html[The Git User's Manual]. @@ -36,7 +36,7 @@ $ git help log With the latter, you can use the manual viewer of your choice; see linkgit:git-help[1] for more information. -It is a good idea to introduce yourself to git with your name and +It is a good idea to introduce yourself to Git with your name and public email address before doing any operation. The easiest way to do so is: @@ -50,7 +50,7 @@ Importing a new project ----------------------- Assume you have a tarball project.tar.gz with your initial work. You -can place it under git revision control as follows. +can place it under Git revision control as follows. ------------------------------------------------ $ tar xzf project.tar.gz @@ -67,14 +67,14 @@ Initialized empty Git repository in .git/ You've now initialized the working directory--you may notice a new directory created, named ".git". -Next, tell git to take a snapshot of the contents of all files under the +Next, tell Git to take a snapshot of the contents of all files under the current directory (note the '.'), with 'git add': ------------------------------------------------ $ git add . ------------------------------------------------ -This snapshot is now stored in a temporary staging area which git calls +This snapshot is now stored in a temporary staging area which Git calls the "index". You can permanently store the contents of the index in the repository with 'git commit': @@ -83,7 +83,7 @@ $ git commit ------------------------------------------------ This will prompt you for a commit message. You've now stored the first -version of your project in git. +version of your project in Git. Making changes -------------- @@ -139,9 +139,11 @@ them to the index, and commit, all in one step. A note on commit messages: Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more -thorough description. Tools that turn commits into email, for -example, use the first line on the Subject: line and the rest of the -commit in the body. +thorough description. The text up to the first blank line in a commit +message is treated as the commit title, and that title is used +throughout Git. For example, linkgit:git-format-patch[1] turns a +commit into email, and it uses the title on the Subject line and the +rest of the commit in the body. Git tracks content not files ---------------------------- @@ -178,7 +180,7 @@ $ git log --stat --summary Managing branches ----------------- -A single git repository can maintain multiple branches of +A single Git repository can maintain multiple branches of development. To create a new branch named "experimental", use ------------------------------------------------ @@ -274,10 +276,10 @@ $ git branch -D crazy-idea Branches are cheap and easy, so this is a good way to try something out. -Using git for collaboration +Using Git for collaboration --------------------------- -Suppose that Alice has started a new project with a git repository in +Suppose that Alice has started a new project with a Git repository in /home/alice/project, and that Bob, who has a home directory on the same machine, wants to contribute. @@ -318,7 +320,7 @@ Note that in general, Alice would want her local changes committed before initiating this "pull". If Bob's work conflicts with what Alice did since their histories forked, Alice will use her working tree and the index to resolve conflicts, and existing local changes will interfere with the -conflict resolution process (git will still perform the fetch but will +conflict resolution process (Git will still perform the fetch but will refuse to merge --- Alice will have to get rid of her local changes in some way and pull again when this happens). @@ -420,7 +422,7 @@ bob$ git pull ------------------------------------- Note that he doesn't need to give the path to Alice's repository; -when Bob cloned Alice's repository, git stored the location of her +when Bob cloned Alice's repository, Git stored the location of her repository in the repository configuration, and that location is used for pulls: @@ -448,7 +450,7 @@ perform clones and pulls using the ssh protocol: bob$ git clone alice.org:/home/alice/project myrepo ------------------------------------- -Alternatively, git has a native protocol, or can use rsync or http; +Alternatively, Git has a native protocol, or can use rsync or http; see linkgit:git-pull[1] for details. Git can also be used in a CVS-like mode, with a central repository @@ -516,7 +518,7 @@ share this name with other people (for example, to identify a release version), you should create a "tag" object, and perhaps sign it; see linkgit:git-tag[1] for details. -Any git command that needs to know a commit can take any of these +Any Git command that needs to know a commit can take any of these names. For example: ------------------------------------- @@ -552,9 +554,9 @@ files it manages in your current directory. So $ git grep "hello" ------------------------------------- -is a quick way to search just the files that are tracked by git. +is a quick way to search just the files that are tracked by Git. -Many git commands also take sets of commits, which can be specified +Many Git commands also take sets of commits, which can be specified in a number of ways. Here are some examples with 'git log': ------------------------------------- @@ -590,7 +592,7 @@ then merged back together, the order in which 'git log' presents those commits is meaningless. Most projects with multiple contributors (such as the Linux kernel, -or git itself) have frequent merges, and 'gitk' does a better job of +or Git itself) have frequent merges, and 'gitk' does a better job of visualizing their history. For example, ------------------------------------- @@ -621,7 +623,7 @@ Next Steps This tutorial should be enough to perform basic distributed revision control for your projects. However, to fully understand the depth -and power of git you need to understand two simple ideas on which it +and power of Git you need to understand two simple ideas on which it is based: * The object database is the rather elegant system used to @@ -634,7 +636,7 @@ is based: Part two of this tutorial explains the object database, the index file, and a few other odds and ends that you'll -need to make the most of git. You can find it at linkgit:gittutorial-2[7]. +need to make the most of Git. You can find it at linkgit:gittutorial-2[7]. If you don't want to continue with that right away, a few other digressions that may be interesting at this point are: @@ -654,7 +656,7 @@ digressions that may be interesting at this point are: * linkgit:gitworkflows[7]: Gives an overview of recommended workflows. - * link:everyday.html[Everyday GIT with 20 Commands Or So] + * link:everyday.html[Everyday Git with 20 Commands Or So] * linkgit:gitcvs-migration[7]: Git for CVS users. @@ -666,7 +668,7 @@ linkgit:gitcore-tutorial[7], linkgit:gitglossary[7], linkgit:git-help[1], linkgit:gitworkflows[7], -link:everyday.html[Everyday git], +link:everyday.html[Everyday Git], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt new file mode 100644 index 000000000..952f503af --- /dev/null +++ b/Documentation/gitweb.conf.txt @@ -0,0 +1,958 @@ +gitweb.conf(5) +============== + +NAME +---- +gitweb.conf - Gitweb (Git web interface) configuration file + +SYNOPSIS +-------- +/etc/gitweb.conf, /etc/gitweb-common.conf, $GITWEBDIR/gitweb_config.perl + +DESCRIPTION +----------- + +The gitweb CGI script for viewing Git repositories over the web uses a +perl script fragment as its configuration file. You can set variables +using "`our $variable = value`"; text from a "#" character until the +end of a line is ignored. See *perlsyn*(1) for details. + +An example: + + # gitweb configuration file for http://git.example.org + # + our $projectroot = "/srv/git"; # FHS recommendation + our $site_name = 'Example.org >> Repos'; + + +The configuration file is used to override the default settings that +were built into gitweb at the time the 'gitweb.cgi' script was generated. + +While one could just alter the configuration settings in the gitweb +CGI itself, those changes would be lost upon upgrade. Configuration +settings might also be placed into a file in the same directory as the +CGI script with the default name 'gitweb_config.perl' -- allowing +one to have multiple gitweb instances with different configurations by +the use of symlinks. + +Note that some configuration can be controlled on per-repository rather than +gitweb-wide basis: see "Per-repository gitweb configuration" subsection on +linkgit:gitweb[1] manpage. + + +DISCUSSION +---------- +Gitweb reads configuration data from the following sources in the +following order: + + * built-in values (some set during build stage), + + * common system-wide configuration file (defaults to + '/etc/gitweb-common.conf'), + + * either per-instance configuration file (defaults to 'gitweb_config.perl' + in the same directory as the installed gitweb), or if it does not exists + then fallback system-wide configuration file (defaults to '/etc/gitweb.conf'). + +Values obtained in later configuration files override values obtained earlier +in the above sequence. + +Locations of the common system-wide configuration file, the fallback +system-wide configuration file and the per-instance configuration file +are defined at compile time using build-time Makefile configuration +variables, respectively `GITWEB_CONFIG_COMMON`, `GITWEB_CONFIG_SYSTEM` +and `GITWEB_CONFIG`. + +You can also override locations of gitweb configuration files during +runtime by setting the following environment variables: +`GITWEB_CONFIG_COMMON`, `GITWEB_CONFIG_SYSTEM` and `GITWEB_CONFIG` +to a non-empty value. + + +The syntax of the configuration files is that of Perl, since these files are +handled by sourcing them as fragments of Perl code (the language that +gitweb itself is written in). Variables are typically set using the +`our` qualifier (as in "`our $variable = <value>;`") to avoid syntax +errors if a new version of gitweb no longer uses a variable and therefore +stops declaring it. + +You can include other configuration file using read_config_file() +subroutine. For example, one might want to put gitweb configuration +related to access control for viewing repositories via Gitolite (one +of Git repository management tools) in a separate file, e.g. in +'/etc/gitweb-gitolite.conf'. To include it, put + +-------------------------------------------------- +read_config_file("/etc/gitweb-gitolite.conf"); +-------------------------------------------------- + +somewhere in gitweb configuration file used, e.g. in per-installation +gitweb configuration file. Note that read_config_file() checks itself +that the file it reads exists, and does nothing if it is not found. +It also handles errors in included file. + + +The default configuration with no configuration file at all may work +perfectly well for some installations. Still, a configuration file is +useful for customizing or tweaking the behavior of gitweb in many ways, and +some optional features will not be present unless explicitly enabled using +the configurable `%features` variable (see also "Configuring gitweb +features" section below). + + +CONFIGURATION VARIABLES +----------------------- +Some configuration variables have their default values (embedded in the CGI +script) set during building gitweb -- if that is the case, this fact is put +in their description. See gitweb's 'INSTALL' file for instructions on building +and installing gitweb. + + +Location of repositories +~~~~~~~~~~~~~~~~~~~~~~~~ +The configuration variables described below control how gitweb finds +Git repositories, and how repositories are displayed and accessed. + +See also "Repositories" and later subsections in linkgit:gitweb[1] manpage. + +$projectroot:: + Absolute filesystem path which will be prepended to project path; + the path to repository is `$projectroot/$project`. Set to + `$GITWEB_PROJECTROOT` during installation. This variable has to be + set correctly for gitweb to find repositories. ++ +For example, if `$projectroot` is set to "/srv/git" by putting the following +in gitweb config file: ++ +---------------------------------------------------------------------------- +our $projectroot = "/srv/git"; +---------------------------------------------------------------------------- ++ +then ++ +------------------------------------------------ +http://git.example.com/gitweb.cgi?p=foo/bar.git +------------------------------------------------ ++ +and its path_info based equivalent ++ +------------------------------------------------ +http://git.example.com/gitweb.cgi/foo/bar.git +------------------------------------------------ ++ +will map to the path '/srv/git/foo/bar.git' on the filesystem. + +$projects_list:: + Name of a plain text file listing projects, or a name of directory + to be scanned for projects. ++ +Project list files should list one project per line, with each line +having the following format ++ +----------------------------------------------------------------------------- +<URI-encoded filesystem path to repository> SP <URI-encoded repository owner> +----------------------------------------------------------------------------- ++ +The default value of this variable is determined by the `GITWEB_LIST` +makefile variable at installation time. If this variable is empty, gitweb +will fall back to scanning the `$projectroot` directory for repositories. + +$project_maxdepth:: + If `$projects_list` variable is unset, gitweb will recursively + scan filesystem for Git repositories. The `$project_maxdepth` + is used to limit traversing depth, relative to `$projectroot` + (starting point); it means that directories which are further + from `$projectroot` than `$project_maxdepth` will be skipped. ++ +It is purely performance optimization, originally intended for MacOS X, +where recursive directory traversal is slow. Gitweb follows symbolic +links, but it detects cycles, ignoring any duplicate files and directories. ++ +The default value of this variable is determined by the build-time +configuration variable `GITWEB_PROJECT_MAXDEPTH`, which defaults to +2007. + +$export_ok:: + Show repository only if this file exists (in repository). Only + effective if this variable evaluates to true. Can be set when + building gitweb by setting `GITWEB_EXPORT_OK`. This path is + relative to `GIT_DIR`. git-daemon[1] uses 'git-daemon-export-ok', + unless started with `--export-all`. By default this variable is + not set, which means that this feature is turned off. + +$export_auth_hook:: + Function used to determine which repositories should be shown. + This subroutine should take one parameter, the full path to + a project, and if it returns true, that project will be included + in the projects list and can be accessed through gitweb as long + as it fulfills the other requirements described by $export_ok, + $projects_list, and $projects_maxdepth. Example: ++ +---------------------------------------------------------------------------- +our $export_auth_hook = sub { return -e "$_[0]/git-daemon-export-ok"; }; +---------------------------------------------------------------------------- ++ +though the above might be done by using `$export_ok` instead ++ +---------------------------------------------------------------------------- +our $export_ok = "git-daemon-export-ok"; +---------------------------------------------------------------------------- ++ +If not set (default), it means that this feature is disabled. ++ +See also more involved example in "Controlling access to Git repositories" +subsection on linkgit:gitweb[1] manpage. + +$strict_export:: + Only allow viewing of repositories also shown on the overview page. + This for example makes `$gitweb_export_ok` file decide if repository is + available and not only if it is shown. If `$gitweb_list` points to + file with list of project, only those repositories listed would be + available for gitweb. Can be set during building gitweb via + `GITWEB_STRICT_EXPORT`. By default this variable is not set, which + means that you can directly access those repositories that are hidden + from projects list page (e.g. the are not listed in the $projects_list + file). + + +Finding files +~~~~~~~~~~~~~ +The following configuration variables tell gitweb where to find files. +The values of these variables are paths on the filesystem. + +$GIT:: + Core git executable to use. By default set to `$GIT_BINDIR/git`, which + in turn is by default set to `$(bindir)/git`. If you use Git installed + from a binary package, you should usually set this to "/usr/bin/git". + This can just be "git" if your web server has a sensible PATH; from + security point of view it is better to use absolute path to git binary. + If you have multiple Git versions installed it can be used to choose + which one to use. Must be (correctly) set for gitweb to be able to + work. + +$mimetypes_file:: + File to use for (filename extension based) guessing of MIME types before + trying '/etc/mime.types'. *NOTE* that this path, if relative, is taken + as relative to the current Git repository, not to CGI script. If unset, + only '/etc/mime.types' is used (if present on filesystem). If no mimetypes + file is found, mimetype guessing based on extension of file is disabled. + Unset by default. + +$highlight_bin:: + Path to the highlight executable to use (it must be the one from + http://www.andre-simon.de[] due to assumptions about parameters and output). + By default set to 'highlight'; set it to full path to highlight + executable if it is not installed on your web server's PATH. + Note that 'highlight' feature must be set for gitweb to actually + use syntax highlighting. ++ +*NOTE*: if you want to add support for new file type (supported by +"highlight" but not used by gitweb), you need to modify `%highlight_ext` +or `%highlight_basename`, depending on whether you detect type of file +based on extension (for example "sh") or on its basename (for example +"Makefile"). The keys of these hashes are extension and basename, +respectively, and value for given key is name of syntax to be passed via +`--syntax <syntax>` to highlighter. ++ +For example if repositories you are hosting use "phtml" extension for +PHP files, and you want to have correct syntax-highlighting for those +files, you can add the following to gitweb configuration: ++ +--------------------------------------------------------- +our %highlight_ext; +$highlight_ext{'phtml'} = 'php'; +--------------------------------------------------------- + + +Links and their targets +~~~~~~~~~~~~~~~~~~~~~~~ +The configuration variables described below configure some of gitweb links: +their target and their look (text or image), and where to find page +prerequisites (stylesheet, favicon, images, scripts). Usually they are left +at their default values, with the possible exception of `@stylesheets` +variable. + +@stylesheets:: + List of URIs of stylesheets (relative to the base URI of a page). You + might specify more than one stylesheet, for example to use "gitweb.css" + as base with site specific modifications in a separate stylesheet + to make it easier to upgrade gitweb. For example, you can add + a `site` stylesheet by putting ++ +---------------------------------------------------------------------------- +push @stylesheets, "gitweb-site.css"; +---------------------------------------------------------------------------- ++ +in the gitweb config file. Those values that are relative paths are +relative to base URI of gitweb. ++ +This list should contain the URI of gitweb's standard stylesheet. The default +URI of gitweb stylesheet can be set at build time using the `GITWEB_CSS` +makefile variable. Its default value is 'static/gitweb.css' +(or 'static/gitweb.min.css' if the `CSSMIN` variable is defined, +i.e. if CSS minifier is used during build). ++ +*Note*: there is also a legacy `$stylesheet` configuration variable, which was +used by older gitweb. If `$stylesheet` variable is defined, only CSS stylesheet +given by this variable is used by gitweb. + +$logo:: + Points to the location where you put 'git-logo.png' on your web + server, or to be more the generic URI of logo, 72x27 size). This image + is displayed in the top right corner of each gitweb page and used as + a logo for the Atom feed. Relative to the base URI of gitweb (as a path). + Can be adjusted when building gitweb using `GITWEB_LOGO` variable + By default set to 'static/git-logo.png'. + +$favicon:: + Points to the location where you put 'git-favicon.png' on your web + server, or to be more the generic URI of favicon, which will be served + as "image/png" type. Web browsers that support favicons (website icons) + may display them in the browser's URL bar and next to the site name in + bookmarks. Relative to the base URI of gitweb. Can be adjusted at + build time using `GITWEB_FAVICON` variable. + By default set to 'static/git-favicon.png'. + +$javascript:: + Points to the location where you put 'gitweb.js' on your web server, + or to be more generic the URI of JavaScript code used by gitweb. + Relative to the base URI of gitweb. Can be set at build time using + the `GITWEB_JS` build-time configuration variable. ++ +The default value is either 'static/gitweb.js', or 'static/gitweb.min.js' if +the `JSMIN` build variable was defined, i.e. if JavaScript minifier was used +at build time. *Note* that this single file is generated from multiple +individual JavaScript "modules". + +$home_link:: + Target of the home link on the top of all pages (the first part of view + "breadcrumbs"). By default it is set to the absolute URI of a current page + (to the value of `$my_uri` variable, or to "/" if `$my_uri` is undefined + or is an empty string). + +$home_link_str:: + Label for the "home link" at the top of all pages, leading to `$home_link` + (usually the main gitweb page, which contains the projects list). It is + used as the first component of gitweb's "breadcrumb trail": + `<home link> / <project> / <action>`. Can be set at build time using + the `GITWEB_HOME_LINK_STR` variable. By default it is set to "projects", + as this link leads to the list of projects. Another popular choice is to + set it to the name of site. Note that it is treated as raw HTML so it + should not be set from untrusted sources. + +@extra_breadcrumbs:: + Additional links to be added to the start of the breadcrumb trail before + the home link, to pages that are logically "above" the gitweb projects + list, such as the organization and department which host the gitweb + server. Each element of the list is a reference to an array, in which + element 0 is the link text (equivalent to `$home_link_str`) and element + 1 is the target URL (equivalent to `$home_link`). ++ +For example, the following setting produces a breadcrumb trail like +"home / dev / projects / ..." where "projects" is the home link. +---------------------------------------------------------------------------- + our @extra_breadcrumbs = ( + [ 'home' => 'https://www.example.org/' ], + [ 'dev' => 'https://dev.example.org/' ], + ); +---------------------------------------------------------------------------- + +$logo_url:: +$logo_label:: + URI and label (title) for the Git logo link (or your site logo, + if you chose to use different logo image). By default, these both + refer to Git homepage, http://git-scm.com[]; in the past, they pointed + to Git documentation at http://www.kernel.org[]. + + +Changing gitweb's look +~~~~~~~~~~~~~~~~~~~~~~ +You can adjust how pages generated by gitweb look using the variables described +below. You can change the site name, add common headers and footers for all +pages, and add a description of this gitweb installation on its main page +(which is the projects list page), etc. + +$site_name:: + Name of your site or organization, to appear in page titles. Set it + to something descriptive for clearer bookmarks etc. If this variable + is not set or is, then gitweb uses the value of the `SERVER_NAME` + CGI environment variable, setting site name to "$SERVER_NAME Git", + or "Untitled Git" if this variable is not set (e.g. if running gitweb + as standalone script). ++ +Can be set using the `GITWEB_SITENAME` at build time. Unset by default. + +$site_html_head_string:: + HTML snippet to be included in the <head> section of each page. + Can be set using `GITWEB_SITE_HTML_HEAD_STRING` at build time. + No default value. + +$site_header:: + Name of a file with HTML to be included at the top of each page. + Relative to the directory containing the 'gitweb.cgi' script. + Can be set using `GITWEB_SITE_HEADER` at build time. No default + value. + +$site_footer:: + Name of a file with HTML to be included at the bottom of each page. + Relative to the directory containing the 'gitweb.cgi' script. + Can be set using `GITWEB_SITE_FOOTER` at build time. No default + value. + +$home_text:: + Name of a HTML file which, if it exists, is included on the + gitweb projects overview page ("projects_list" view). Relative to + the directory containing the gitweb.cgi script. Default value + can be adjusted during build time using `GITWEB_HOMETEXT` variable. + By default set to 'indextext.html'. + +$projects_list_description_width:: + The width (in characters) of the "Description" column of the projects list. + Longer descriptions will be truncated (trying to cut at word boundary); + the full description is available in the 'title' attribute (usually shown on + mouseover). The default is 25, which might be too small if you + use long project descriptions. + +$default_projects_order:: + Default value of ordering of projects on projects list page, which + means the ordering used if you don't explicitly sort projects list + (if there is no "o" CGI query parameter in the URL). Valid values + are "none" (unsorted), "project" (projects are by project name, + i.e. path to repository relative to `$projectroot`), "descr" + (project description), "owner", and "age" (by date of most current + commit). ++ +Default value is "project". Unknown value means unsorted. + + +Changing gitweb's behavior +~~~~~~~~~~~~~~~~~~~~~~~~~~ +These configuration variables control _internal_ gitweb behavior. + +$default_blob_plain_mimetype:: + Default mimetype for the blob_plain (raw) view, if mimetype checking + doesn't result in some other type; by default "text/plain". + Gitweb guesses mimetype of a file to display based on extension + of its filename, using `$mimetypes_file` (if set and file exists) + and '/etc/mime.types' files (see *mime.types*(5) manpage; only + filename extension rules are supported by gitweb). + +$default_text_plain_charset:: + Default charset for text files. If this is not set, the web server + configuration will be used. Unset by default. + +$fallback_encoding:: + Gitweb assumes this charset when a line contains non-UTF-8 characters. + The fallback decoding is used without error checking, so it can be even + "utf-8". The value must be a valid encoding; see the *Encoding::Supported*(3pm) + man page for a list. The default is "latin1", aka. "iso-8859-1". + +@diff_opts:: + Rename detection options for git-diff and git-diff-tree. The default is + (\'-M'); set it to (\'-C') or (\'-C', \'-C') to also detect copies, + or set it to () i.e. empty list if you don't want to have renames + detection. ++ +*Note* that rename and especially copy detection can be quite +CPU-intensive. Note also that non Git tools can have problems with +patches generated with options mentioned above, especially when they +involve file copies (\'-C') or criss-cross renames (\'-B'). + + +Some optional features and policies +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Most of features are configured via `%feature` hash; however some of extra +gitweb features can be turned on and configured using variables described +below. This list beside configuration variables that control how gitweb +looks does contain variables configuring administrative side of gitweb +(e.g. cross-site scripting prevention; admittedly this as side effect +affects how "summary" pages look like, or load limiting). + +@git_base_url_list:: + List of Git base URLs. These URLs are used to generate URLs + describing from where to fetch a project, which are shown on + project summary page. The full fetch URL is "`$git_base_url/$project`", + for each element of this list. You can set up multiple base URLs + (for example one for `git://` protocol, and one for `http://` + protocol). ++ +Note that per repository configuration can be set in '$GIT_DIR/cloneurl' +file, or as values of multi-value `gitweb.url` configuration variable in +project config. Per-repository configuration takes precedence over value +composed from `@git_base_url_list` elements and project name. ++ +You can setup one single value (single entry/item in this list) at build +time by setting the `GITWEB_BASE_URL` built-time configuration variable. +By default it is set to (), i.e. an empty list. This means that gitweb +would not try to create project URL (to fetch) from project name. + +$projects_list_group_categories:: + Whether to enables the grouping of projects by category on the project + list page. The category of a project is determined by the + `$GIT_DIR/category` file or the `gitweb.category` variable in each + repository's configuration. Disabled by default (set to 0). + +$project_list_default_category:: + Default category for projects for which none is specified. If this is + set to the empty string, such projects will remain uncategorized and + listed at the top, above categorized projects. Used only if project + categories are enabled, which means if `$projects_list_group_categories` + is true. By default set to "" (empty string). + +$prevent_xss:: + If true, some gitweb features are disabled to prevent content in + repositories from launching cross-site scripting (XSS) attacks. Set this + to true if you don't trust the content of your repositories. + False by default (set to 0). + +$maxload:: + Used to set the maximum load that we will still respond to gitweb queries. + If the server load exceeds this value then gitweb will return + "503 Service Unavailable" error. The server load is taken to be 0 + if gitweb cannot determine its value. Currently it works only on Linux, + where it uses '/proc/loadavg'; the load there is the number of active + tasks on the system -- processes that are actually running -- averaged + over the last minute. ++ +Set `$maxload` to undefined value (`undef`) to turn this feature off. +The default value is 300. + +$omit_age_column:: + If true, omit the column with date of the most current commit on the + projects list page. It can save a bit of I/O and a fork per repository. + +$omit_owner:: + If true prevents displaying information about repository owner. + +$per_request_config:: + If this is set to code reference, it will be run once for each request. + You can set parts of configuration that change per session this way. + For example, one might use the following code in a gitweb configuration + file ++ +-------------------------------------------------------------------------------- +our $per_request_config = sub { + $ENV{GL_USER} = $cgi->remote_user || "gitweb"; +}; +-------------------------------------------------------------------------------- ++ +If `$per_request_config` is not a code reference, it is interpreted as boolean +value. If it is true gitweb will process config files once per request, +and if it is false gitweb will process config files only once, each time it +is executed. True by default (set to 1). ++ +*NOTE*: `$my_url`, `$my_uri`, and `$base_url` are overwritten with their default +values before every request, so if you want to change them, be sure to set +this variable to true or a code reference effecting the desired changes. ++ +This variable matters only when using persistent web environments that +serve multiple requests using single gitweb instance, like mod_perl, +FastCGI or Plackup. + + +Other variables +~~~~~~~~~~~~~~~ +Usually you should not need to change (adjust) any of configuration +variables described below; they should be automatically set by gitweb to +correct value. + + +$version:: + Gitweb version, set automatically when creating gitweb.cgi from + gitweb.perl. You might want to modify it if you are running modified + gitweb, for example ++ +--------------------------------------------------- +our $version .= " with caching"; +--------------------------------------------------- ++ +if you run modified version of gitweb with caching support. This variable +is purely informational, used e.g. in the "generator" meta header in HTML +header. + +$my_url:: +$my_uri:: + Full URL and absolute URL of the gitweb script; + in earlier versions of gitweb you might have need to set those + variables, but now there should be no need to do it. See + `$per_request_config` if you need to set them still. + +$base_url:: + Base URL for relative URLs in pages generated by gitweb, + (e.g. `$logo`, `$favicon`, `@stylesheets` if they are relative URLs), + needed and used '<base href="$base_url">' only for URLs with nonempty + PATH_INFO. Usually gitweb sets its value correctly, + and there is no need to set this variable, e.g. to $my_uri or "/". + See `$per_request_config` if you need to override it anyway. + + +CONFIGURING GITWEB FEATURES +--------------------------- +Many gitweb features can be enabled (or disabled) and configured using the +`%feature` hash. Names of gitweb features are keys of this hash. + +Each `%feature` hash element is a hash reference and has the following +structure: +---------------------------------------------------------------------- +"<feature_name>" => { + "sub" => <feature-sub (subroutine)>, + "override" => <allow-override (boolean)>, + "default" => [ <options>... ] +}, +---------------------------------------------------------------------- +Some features cannot be overridden per project. For those +features the structure of appropriate `%feature` hash element has a simpler +form: +---------------------------------------------------------------------- +"<feature_name>" => { + "override" => 0, + "default" => [ <options>... ] +}, +---------------------------------------------------------------------- +As one can see it lacks the \'sub' element. + +The meaning of each part of feature configuration is described +below: + +default:: + List (array reference) of feature parameters (if there are any), + used also to toggle (enable or disable) given feature. ++ +Note that it is currently *always* an array reference, even if +feature doesn't accept any configuration parameters, and \'default' +is used only to turn it on or off. In such case you turn feature on +by setting this element to `[1]`, and torn it off by setting it to +`[0]`. See also the passage about the "blame" feature in the "Examples" +section. ++ +To disable features that accept parameters (are configurable), you +need to set this element to empty list i.e. `[]`. + +override:: + If this field has a true value then the given feature is + overridable, which means that it can be configured + (or enabled/disabled) on a per-repository basis. ++ +Usually given "<feature>" is configurable via the `gitweb.<feature>` +config variable in the per-repository Git configuration file. ++ +*Note* that no feature is overridable by default. + +sub:: + Internal detail of implementation. What is important is that + if this field is not present then per-repository override for + given feature is not supported. ++ +You wouldn't need to ever change it in gitweb config file. + + +Features in `%feature` +~~~~~~~~~~~~~~~~~~~~~~ +The gitweb features that are configurable via `%feature` hash are listed +below. This should be a complete list, but ultimately the authoritative +and complete list is in gitweb.cgi source code, with features described +in the comments. + +blame:: + Enable the "blame" and "blame_incremental" blob views, showing for + each line the last commit that modified it; see linkgit:git-blame[1]. + This can be very CPU-intensive and is therefore disabled by default. ++ +This feature can be configured on a per-repository basis via +repository's `gitweb.blame` configuration variable (boolean). + +snapshot:: + Enable and configure the "snapshot" action, which allows user to + download a compressed archive of any tree or commit, as produced + by linkgit:git-archive[1] and possibly additionally compressed. + This can potentially generate high traffic if you have large project. ++ +The value of \'default' is a list of names of snapshot formats, +defined in `%known_snapshot_formats` hash, that you wish to offer. +Supported formats include "tgz", "tbz2", "txz" (gzip/bzip2/xz +compressed tar archive) and "zip"; please consult gitweb sources for +a definitive list. By default only "tgz" is offered. ++ +This feature can be configured on a per-repository basis via +repository's `gitweb.blame` configuration variable, which contains +a comma separated list of formats or "none" to disable snapshots. +Unknown values are ignored. + +grep:: + Enable grep search, which lists the files in currently selected + tree (directory) containing the given string; see linkgit:git-grep[1]. + This can be potentially CPU-intensive, of course. Enabled by default. ++ +This feature can be configured on a per-repository basis via +repository's `gitweb.grep` configuration variable (boolean). + +pickaxe:: + Enable the so called pickaxe search, which will list the commits + that introduced or removed a given string in a file. This can be + practical and quite faster alternative to "blame" action, but it is + still potentially CPU-intensive. Enabled by default. ++ +The pickaxe search is described in linkgit:git-log[1] (the +description of `-S<string>` option, which refers to pickaxe entry in +linkgit:gitdiffcore[7] for more details). ++ +This feature can be configured on a per-repository basis by setting +repository's `gitweb.pickaxe` configuration variable (boolean). + +show-sizes:: + Enable showing size of blobs (ordinary files) in a "tree" view, in a + separate column, similar to what `ls -l` does; see description of + `-l` option in linkgit:git-ls-tree[1] manpage. This costs a bit of + I/O. Enabled by default. ++ +This feature can be configured on a per-repository basis via +repository's `gitweb.showsizes` configuration variable (boolean). + +patches:: + Enable and configure "patches" view, which displays list of commits in email + (plain text) output format; see also linkgit:git-format-patch[1]. + The value is the maximum number of patches in a patchset generated + in "patches" view. Set the 'default' field to a list containing single + item of or to an empty list to disable patch view, or to a list + containing a single negative number to remove any limit. + Default value is 16. ++ +This feature can be configured on a per-repository basis via +repository's `gitweb.patches` configuration variable (integer). + +avatar:: + Avatar support. When this feature is enabled, views such as + "shortlog" or "commit" will display an avatar associated with + the email of each committer and author. ++ +Currently available providers are *"gravatar"* and *"picon"*. +Only one provider at a time can be selected ('default' is one element list). +If an unknown provider is specified, the feature is disabled. +*Note* that some providers might require extra Perl packages to be +installed; see 'gitweb/INSTALL' for more details. ++ +This feature can be configured on a per-repository basis via +repository's `gitweb.avatar` configuration variable. ++ +See also `%avatar_size` with pixel sizes for icons and avatars +("default" is used for one-line like "log" and "shortlog", "double" +is used for two-line like "commit", "commitdiff" or "tag"). If the +default font sizes or lineheights are changed (e.g. via adding extra +CSS stylesheet in `@stylesheets`), it may be appropriate to change +these values. + +highlight:: + Server-side syntax highlight support in "blob" view. It requires + `$highlight_bin` program to be available (see the description of + this variable in the "Configuration variables" section above), + and therefore is disabled by default. ++ +This feature can be configured on a per-repository basis via +repository's `gitweb.highlight` configuration variable (boolean). + +remote_heads:: + Enable displaying remote heads (remote-tracking branches) in the "heads" + list. In most cases the list of remote-tracking branches is an + unnecessary internal private detail, and this feature is therefore + disabled by default. linkgit:git-instaweb[1], which is usually used + to browse local repositories, enables and uses this feature. ++ +This feature can be configured on a per-repository basis via +repository's `gitweb.remote_heads` configuration variable (boolean). + + +The remaining features cannot be overridden on a per project basis. + +search:: + Enable text search, which will list the commits which match author, + committer or commit text to a given string; see the description of + `--author`, `--committer` and `--grep` options in linkgit:git-log[1] + manpage. Enabled by default. ++ +Project specific override is not supported. + +forks:: + If this feature is enabled, gitweb considers projects in + subdirectories of project root (basename) to be forks of existing + projects. For each project +$projname.git+, projects in the + +$projname/+ directory and its subdirectories will not be + shown in the main projects list. Instead, a \'\+' mark is shown + next to +$projname+, which links to a "forks" view that lists all + the forks (all projects in +$projname/+ subdirectory). Additionally + a "forks" view for a project is linked from project summary page. ++ +If the project list is taken from a file (+$projects_list+ points to a +file), forks are only recognized if they are listed after the main project +in that file. ++ +Project specific override is not supported. + +actions:: + Insert custom links to the action bar of all project pages. This + allows you to link to third-party scripts integrating into gitweb. ++ +The "default" value consists of a list of triplets in the form +`("<label>", "<link>", "<position>")` where "position" is the label +after which to insert the link, "link" is a format string where `%n` +expands to the project name, `%f` to the project path within the +filesystem (i.e. "$projectroot/$project"), `%h` to the current hash +(\'h' gitweb parameter) and `%b` to the current hash base +(\'hb' gitweb parameter); `%%` expands to \'%'. ++ +For example, at the time this page was written, the http://repo.or.cz[] +Git hosting site set it to the following to enable graphical log +(using the third party tool *git-browser*): ++ +---------------------------------------------------------------------- +$feature{'actions'}{'default'} = + [ ('graphiclog', '/git-browser/by-commit.html?r=%n', 'summary')]; +---------------------------------------------------------------------- ++ +This adds a link titled "graphiclog" after the "summary" link, leading to +`git-browser` script, passing `r=<project>` as a query parameter. ++ +Project specific override is not supported. + +timed:: + Enable displaying how much time and how many Git commands it took to + generate and display each page in the page footer (at the bottom of + page). For example the footer might contain: "This page took 6.53325 + seconds and 13 Git commands to generate." Disabled by default. ++ +Project specific override is not supported. + +javascript-timezone:: + Enable and configure the ability to change a common time zone for dates + in gitweb output via JavaScript. Dates in gitweb output include + authordate and committerdate in "commit", "commitdiff" and "log" + views, and taggerdate in "tag" view. Enabled by default. ++ +The value is a list of three values: a default time zone (for if the client +hasn't selected some other time zone and saved it in a cookie), a name of cookie +where to store selected time zone, and a CSS class used to mark up +dates for manipulation. If you want to turn this feature off, set "default" +to empty list: `[]`. ++ +Typical gitweb config files will only change starting (default) time zone, +and leave other elements at their default values: ++ +--------------------------------------------------------------------------- +$feature{'javascript-timezone'}{'default'}[0] = "utc"; +--------------------------------------------------------------------------- ++ +The example configuration presented here is guaranteed to be backwards +and forward compatible. ++ +Time zone values can be "local" (for local time zone that browser uses), "utc" +(what gitweb uses when JavaScript or this feature is disabled), or numerical +time zones in the form of "+/-HHMM", such as "+0200". ++ +Project specific override is not supported. + +extra-branch-refs:: + List of additional directories under "refs" which are going to + be used as branch refs. For example if you have a gerrit setup + where all branches under refs/heads/ are official, + push-after-review ones and branches under refs/sandbox/, + refs/wip and refs/other are user ones where permissions are + much wider, then you might want to set this variable as + follows: ++ +-------------------------------------------------------------------------------- +$feature{'extra-branch-refs'}{'default'} = + ['sandbox', 'wip', 'other']; +-------------------------------------------------------------------------------- ++ +This feature can be configured on per-repository basis after setting +$feature{'extra-branch-refs'}{'override'} to true, via repository's +`gitweb.extraBranchRefs` configuration variable, which contains a +space separated list of refs. An example: ++ +-------------------------------------------------------------------------------- +[gitweb] + extraBranchRefs = sandbox wip other +-------------------------------------------------------------------------------- ++ +The gitweb.extraBranchRefs is actually a multi-valued configuration +variable, so following example is also correct and the result is the +same as of the snippet above: ++ +-------------------------------------------------------------------------------- +[gitweb] + extraBranchRefs = sandbox + extraBranchRefs = wip other +-------------------------------------------------------------------------------- ++ +It is an error to specify a ref that does not pass "git check-ref-format" +scrutiny. Duplicated values are filtered. + + +EXAMPLES +-------- + +To enable blame, pickaxe search, and snapshot support (allowing "tar.gz" and +"zip" snapshots), while allowing individual projects to turn them off, put +the following in your GITWEB_CONFIG file: + + $feature{'blame'}{'default'} = [1]; + $feature{'blame'}{'override'} = 1; + + $feature{'pickaxe'}{'default'} = [1]; + $feature{'pickaxe'}{'override'} = 1; + + $feature{'snapshot'}{'default'} = ['zip', 'tgz']; + $feature{'snapshot'}{'override'} = 1; + +If you allow overriding for the snapshot feature, you can specify which +snapshot formats are globally disabled. You can also add any command line +options you want (such as setting the compression level). For instance, you +can disable Zip compressed snapshots and set *gzip*(1) to run at level 6 by +adding the following lines to your gitweb configuration file: + + $known_snapshot_formats{'zip'}{'disabled'} = 1; + $known_snapshot_formats{'tgz'}{'compressor'} = ['gzip','-6']; + +BUGS +---- +Debugging would be easier if the fallback configuration file +(`/etc/gitweb.conf`) and environment variable to override its location +('GITWEB_CONFIG_SYSTEM') had names reflecting their "fallback" role. +The current names are kept to avoid breaking working setups. + +ENVIRONMENT +----------- +The location of per-instance and system-wide configuration files can be +overridden using the following environment variables: + +GITWEB_CONFIG:: + Sets location of per-instance configuration file. +GITWEB_CONFIG_SYSTEM:: + Sets location of fallback system-wide configuration file. + This file is read only if per-instance one does not exist. +GITWEB_CONFIG_COMMON:: + Sets location of common system-wide configuration file. + + +FILES +----- +gitweb_config.perl:: + This is default name of per-instance configuration file. The + format of this file is described above. +/etc/gitweb.conf:: + This is default name of fallback system-wide configuration + file. This file is used only if per-instance configuration + variable is not found. +/etc/gitweb-common.conf:: + This is default name of common system-wide configuration + file. + + +SEE ALSO +-------- +linkgit:gitweb[1], linkgit:git-instaweb[1] + +'gitweb/README', 'gitweb/INSTALL' + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt new file mode 100644 index 000000000..cca14b8cc --- /dev/null +++ b/Documentation/gitweb.txt @@ -0,0 +1,704 @@ +gitweb(1) +========= + +NAME +---- +gitweb - Git web interface (web frontend to Git repositories) + +SYNOPSIS +-------- +To get started with gitweb, run linkgit:git-instaweb[1] from a Git repository. +This would configure and start your web server, and run web browser pointing to +gitweb. + + +DESCRIPTION +----------- +Gitweb provides a web interface to Git repositories. Its features include: + +* Viewing multiple Git repositories with common root. +* Browsing every revision of the repository. +* Viewing the contents of files in the repository at any revision. +* Viewing the revision log of branches, history of files and directories, + see what was changed when, by who. +* Viewing the blame/annotation details of any file (if enabled). +* Generating RSS and Atom feeds of commits, for any branch. + The feeds are auto-discoverable in modern web browsers. +* Viewing everything that was changed in a revision, and step through + revisions one at a time, viewing the history of the repository. +* Finding commits which commit messages matches given search term. + +See http://git.kernel.org/?p=git/git.git;a=tree;f=gitweb[] or +http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/[] for gitweb source code, +browsed using gitweb itself. + + +CONFIGURATION +------------- +Various aspects of gitweb's behavior can be controlled through the configuration +file 'gitweb_config.perl' or '/etc/gitweb.conf'. See the linkgit:gitweb.conf[5] +for details. + +Repositories +~~~~~~~~~~~~ +Gitweb can show information from one or more Git repositories. These +repositories have to be all on local filesystem, and have to share common +repository root, i.e. be all under a single parent repository (but see also +"Advanced web server setup" section, "Webserver configuration with multiple +projects' root" subsection). + +----------------------------------------------------------------------- +our $projectroot = '/path/to/parent/directory'; +----------------------------------------------------------------------- + +The default value for `$projectroot` is '/pub/git'. You can change it during +building gitweb via `GITWEB_PROJECTROOT` build configuration variable. + +By default all Git repositories under `$projectroot` are visible and available +to gitweb. The list of projects is generated by default by scanning the +`$projectroot` directory for Git repositories (for object databases to be +more exact; gitweb is not interested in a working area, and is best suited +to showing "bare" repositories). + +The name of the repository in gitweb is the path to its `$GIT_DIR` (its object +database) relative to `$projectroot`. Therefore the repository $repo can be +found at "$projectroot/$repo". + + +Projects list file format +~~~~~~~~~~~~~~~~~~~~~~~~~ +Instead of having gitweb find repositories by scanning filesystem +starting from $projectroot, you can provide a pre-generated list of +visible projects by setting `$projects_list` to point to a plain text +file with a list of projects (with some additional info). + +This file uses the following format: + +* One record (for project / repository) per line; does not support line +continuation (newline escaping). + +* Leading and trailing whitespace are ignored. + +* Whitespace separated fields; any run of whitespace can be used as field +separator (rules for Perl's "`split(" ", $line)`"). + +* Fields use modified URI encoding, defined in RFC 3986, section 2.1 +(Percent-Encoding), or rather "Query string encoding" (see +link:http://en.wikipedia.org/wiki/Query_string#URL_encoding[]), the difference +being that SP (" ") can be encoded as "{plus}" (and therefore "{plus}" has to be +also percent-encoded). ++ +Reserved characters are: "%" (used for encoding), "{plus}" (can be used to +encode SPACE), all whitespace characters as defined in Perl, including SP, +TAB and LF, (used to separate fields in a record). + +* Currently recognized fields are: +<repository path>:: + path to repository GIT_DIR, relative to `$projectroot` +<repository owner>:: + displayed as repository owner, preferably full name, or email, + or both + +You can generate the projects list index file using the project_index action +(the 'TXT' link on projects list page) directly from gitweb; see also +"Generating projects list using gitweb" section below. + +Example contents: +----------------------------------------------------------------------- +foo.git Joe+R+Hacker+<joe@example.com> +foo/bar.git O+W+Ner+<owner@example.org> +----------------------------------------------------------------------- + + +By default this file controls only which projects are *visible* on projects +list page (note that entries that do not point to correctly recognized Git +repositories won't be displayed by gitweb). Even if a project is not +visible on projects list page, you can view it nevertheless by hand-crafting +a gitweb URL. By setting `$strict_export` configuration variable (see +linkgit:gitweb.conf[5]) to true value you can allow viewing only of +repositories also shown on the overview page (i.e. only projects explicitly +listed in projects list file will be accessible). + + +Generating projects list using gitweb +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +We assume that GITWEB_CONFIG has its default Makefile value, namely +'gitweb_config.perl'. Put the following in 'gitweb_make_index.perl' file: +---------------------------------------------------------------------------- +read_config_file("gitweb_config.perl"); +$projects_list = $projectroot; +---------------------------------------------------------------------------- + +Then create the following script to get list of project in the format +suitable for GITWEB_LIST build configuration variable (or +`$projects_list` variable in gitweb config): + +---------------------------------------------------------------------------- +#!/bin/sh + +export GITWEB_CONFIG="gitweb_make_index.perl" +export GATEWAY_INTERFACE="CGI/1.1" +export HTTP_ACCEPT="*/*" +export REQUEST_METHOD="GET" +export QUERY_STRING="a=project_index" + +perl -- /var/www/cgi-bin/gitweb.cgi +---------------------------------------------------------------------------- + +Run this script and save its output to a file. This file could then be used +as projects list file, which means that you can set `$projects_list` to its +filename. + + +Controlling access to Git repositories +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +By default all Git repositories under `$projectroot` are visible and +available to gitweb. You can however configure how gitweb controls access +to repositories. + +* As described in "Projects list file format" section, you can control which +projects are *visible* by selectively including repositories in projects +list file, and setting `$projects_list` gitweb configuration variable to +point to it. With `$strict_export` set, projects list file can be used to +control which repositories are *available* as well. + +* You can configure gitweb to only list and allow viewing of the explicitly +exported repositories, via `$export_ok` variable in gitweb config file; see +linkgit:gitweb.conf[5] manpage. If it evaluates to true, gitweb shows +repositories only if this file named by `$export_ok` exists in its object +database (if directory has the magic file named `$export_ok`). ++ +For example linkgit:git-daemon[1] by default (unless `--export-all` option +is used) allows pulling only for those repositories that have +'git-daemon-export-ok' file. Adding ++ +-------------------------------------------------------------------------- +our $export_ok = "git-daemon-export-ok"; +-------------------------------------------------------------------------- ++ +makes gitweb show and allow access only to those repositories that can be +fetched from via `git://` protocol. + +* Finally, it is possible to specify an arbitrary perl subroutine that will +be called for each repository to determine if it can be exported. The +subroutine receives an absolute path to the project (repository) as its only +parameter (i.e. "$projectroot/$project"). ++ +For example, if you use mod_perl to run the script, and have dumb +HTTP protocol authentication configured for your repositories, you +can use the following hook to allow access only if the user is +authorized to read the files: ++ +-------------------------------------------------------------------------- +$export_auth_hook = sub { + use Apache2::SubRequest (); + use Apache2::Const -compile => qw(HTTP_OK); + my $path = "$_[0]/HEAD"; + my $r = Apache2::RequestUtil->request; + my $sub = $r->lookup_file($path); + return $sub->filename eq $path + && $sub->status == Apache2::Const::HTTP_OK; +}; +-------------------------------------------------------------------------- + + +Per-repository gitweb configuration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +You can configure individual repositories shown in gitweb by creating file +in the 'GIT_DIR' of Git repository, or by setting some repo configuration +variable (in 'GIT_DIR/config', see linkgit:git-config[1]). + +You can use the following files in repository: + +README.html:: + A html file (HTML fragment) which is included on the gitweb project + "summary" page inside `<div>` block element. You can use it for longer + description of a project, to provide links (for example to project's + homepage), etc. This is recognized only if XSS prevention is off + (`$prevent_xss` is false, see linkgit:gitweb.conf[5]); a way to include + a README safely when XSS prevention is on may be worked out in the + future. + +description (or `gitweb.description`):: + Short (shortened to `$projects_list_description_width` in the projects + list page, which is 25 characters by default; see + linkgit:gitweb.conf[5]) single line description of a project (of a + repository). Plain text file; HTML will be escaped. By default set to ++ +------------------------------------------------------------------------------- +Unnamed repository; edit this file to name it for gitweb. +------------------------------------------------------------------------------- ++ +from the template during repository creation, usually installed in +'/usr/share/git-core/templates/'. You can use the `gitweb.description` repo +configuration variable, but the file takes precedence. + +category (or `gitweb.category`):: + Singe line category of a project, used to group projects if + `$projects_list_group_categories` is enabled. By default (file and + configuration variable absent), uncategorized projects are put in the + `$project_list_default_category` category. You can use the + `gitweb.category` repo configuration variable, but the file takes + precedence. ++ +The configuration variables `$projects_list_group_categories` and +`$project_list_default_category` are described in linkgit:gitweb.conf[5] + +cloneurl (or multiple-valued `gitweb.url`):: + File with repository URL (used for clone and fetch), one per line. + Displayed in the project summary page. You can use multiple-valued + `gitweb.url` repository configuration variable for that, but the file + takes precedence. ++ +This is per-repository enhancement / version of global prefix-based +`@git_base_url_list` gitweb configuration variable (see +linkgit:gitweb.conf[5]). + +gitweb.owner:: + You can use the `gitweb.owner` repository configuration variable to set + repository's owner. It is displayed in the project list and summary + page. ++ +If it's not set, filesystem directory's owner is used (via GECOS field, +i.e. real name field from *getpwuid*(3)) if `$projects_list` is unset +(gitweb scans `$projectroot` for repositories); if `$projects_list` +points to file with list of repositories, then project owner defaults to +value from this file for given repository. + +various `gitweb.*` config variables (in config):: + Read description of `%feature` hash for detailed list, and descriptions. + See also "Configuring gitweb features" section in linkgit:gitweb.conf[5] + + +ACTIONS, AND URLS +----------------- +Gitweb can use path_info (component) based URLs, or it can pass all necessary +information via query parameters. The typical gitweb URLs are broken down in to +five components: + +----------------------------------------------------------------------- +.../gitweb.cgi/<repo>/<action>/<revision>:/<path>?<arguments> +----------------------------------------------------------------------- + +repo:: + The repository the action will be performed on. ++ +All actions except for those that list all available projects, +in whatever form, require this parameter. + +action:: + The action that will be run. Defaults to 'projects_list' if repo + is not set, and to 'summary' otherwise. + +revision:: + Revision shown. Defaults to HEAD. + +path:: + The path within the <repository> that the action is performed on, + for those actions that require it. + +arguments:: + Any arguments that control the behaviour of the action. + +Some actions require or allow to specify two revisions, and sometimes even two +pathnames. In most general form such path_info (component) based gitweb URL +looks like this: + +----------------------------------------------------------------------- +.../gitweb.cgi/<repo>/<action>/<revision_from>:/<path_from>..<revision_to>:/<path_to>?<arguments> +----------------------------------------------------------------------- + + +Each action is implemented as a subroutine, and must be present in %actions +hash. Some actions are disabled by default, and must be turned on via feature +mechanism. For example to enable 'blame' view add the following to gitweb +configuration file: + +----------------------------------------------------------------------- +$feature{'blame'}{'default'} = [1]; +----------------------------------------------------------------------- + + +Actions: +~~~~~~~~ +The standard actions are: + +project_list:: + Lists the available Git repositories. This is the default command if no + repository is specified in the URL. + +summary:: + Displays summary about given repository. This is the default command if + no action is specified in URL, and only repository is specified. + +heads:: +remotes:: + Lists all local or all remote-tracking branches in given repository. ++ +The latter is not available by default, unless configured. + +tags:: + List all tags (lightweight and annotated) in given repository. + +blob:: +tree:: + Shows the files and directories in a given repository path, at given + revision. This is default command if no action is specified in the URL, + and path is given. + +blob_plain:: + Returns the raw data for the file in given repository, at given path and + revision. Links to this action are marked 'raw'. + +blobdiff:: + Shows the difference between two revisions of the same file. + +blame:: +blame_incremental:: + Shows the blame (also called annotation) information for a file. On a + per line basis it shows the revision in which that line was last changed + and the user that committed the change. The incremental version (which + if configured is used automatically when JavaScript is enabled) uses + Ajax to incrementally add blame info to the contents of given file. ++ +This action is disabled by default for performance reasons. + +commit:: +commitdiff:: + Shows information about a specific commit in a repository. The 'commit' + view shows information about commit in more detail, the 'commitdiff' + action shows changeset for given commit. + +patch:: + Returns the commit in plain text mail format, suitable for applying with + linkgit:git-am[1]. + +tag:: + Display specific annotated tag (tag object). + +log:: +shortlog:: + Shows log information (commit message or just commit subject) for a + given branch (starting from given revision). ++ +The 'shortlog' view is more compact; it shows one commit per line. + +history:: + Shows history of the file or directory in a given repository path, + starting from given revision (defaults to HEAD, i.e. default branch). ++ +This view is similar to 'shortlog' view. + +rss:: +atom:: + Generates an RSS (or Atom) feed of changes to repository. + + +WEBSERVER CONFIGURATION +----------------------- +This section explains how to configure some common webservers to run gitweb. In +all cases, `/path/to/gitweb` in the examples is the directory you ran installed +gitweb in, and contains `gitweb_config.perl`. + +If you've configured a web server that isn't listed here for gitweb, please send +in the instructions so they can be included in a future release. + +Apache as CGI +~~~~~~~~~~~~~ +Apache must be configured to support CGI scripts in the directory in +which gitweb is installed. Let's assume that it is '/var/www/cgi-bin' +directory. + +----------------------------------------------------------------------- +ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" + +<Directory "/var/www/cgi-bin"> + Options Indexes FollowSymlinks ExecCGI + AllowOverride None + Order allow,deny + Allow from all +</Directory> +----------------------------------------------------------------------- + +With that configuration the full path to browse repositories would be: + + http://server/cgi-bin/gitweb.cgi + +Apache with mod_perl, via ModPerl::Registry +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +You can use mod_perl with gitweb. You must install Apache::Registry +(for mod_perl 1.x) or ModPerl::Registry (for mod_perl 2.x) to enable +this support. + +Assuming that gitweb is installed to '/var/www/perl', the following +Apache configuration (for mod_perl 2.x) is suitable. + +----------------------------------------------------------------------- +Alias /perl "/var/www/perl" + +<Directory "/var/www/perl"> + SetHandler perl-script + PerlResponseHandler ModPerl::Registry + PerlOptions +ParseHeaders + Options Indexes FollowSymlinks +ExecCGI + AllowOverride None + Order allow,deny + Allow from all +</Directory> +----------------------------------------------------------------------- + +With that configuration the full path to browse repositories would be: + + http://server/perl/gitweb.cgi + +Apache with FastCGI +~~~~~~~~~~~~~~~~~~~ +Gitweb works with Apache and FastCGI. First you need to rename, copy +or symlink gitweb.cgi to gitweb.fcgi. Let's assume that gitweb is +installed in '/usr/share/gitweb' directory. The following Apache +configuration is suitable (UNTESTED!) + +----------------------------------------------------------------------- +FastCgiServer /usr/share/gitweb/gitweb.cgi +ScriptAlias /gitweb /usr/share/gitweb/gitweb.cgi + +Alias /gitweb/static /usr/share/gitweb/static +<Directory /usr/share/gitweb/static> + SetHandler default-handler +</Directory> +----------------------------------------------------------------------- + +With that configuration the full path to browse repositories would be: + + http://server/gitweb + + +ADVANCED WEB SERVER SETUP +------------------------- +All of those examples use request rewriting, and need `mod_rewrite` +(or equivalent; examples below are written for Apache). + +Single URL for gitweb and for fetching +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +If you want to have one URL for both gitweb and your `http://` +repositories, you can configure Apache like this: + +----------------------------------------------------------------------- +<VirtualHost *:80> + ServerName git.example.org + DocumentRoot /pub/git + SetEnv GITWEB_CONFIG /etc/gitweb.conf + + # turning on mod rewrite + RewriteEngine on + + # make the front page an internal rewrite to the gitweb script + RewriteRule ^/$ /cgi-bin/gitweb.cgi + + # make access for "dumb clients" work + RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \ + /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT] +</VirtualHost> +----------------------------------------------------------------------- + +The above configuration expects your public repositories to live under +'/pub/git' and will serve them as `http://git.domain.org/dir-under-pub-git`, +both as clonable Git URL and as browseable gitweb interface. If you then +start your linkgit:git-daemon[1] with `--base-path=/pub/git --export-all` +then you can even use the `git://` URL with exactly the same path. + +Setting the environment variable `GITWEB_CONFIG` will tell gitweb to use the +named file (i.e. in this example '/etc/gitweb.conf') as a configuration for +gitweb. You don't really need it in above example; it is required only if +your configuration file is in different place than built-in (during +compiling gitweb) 'gitweb_config.perl' or '/etc/gitweb.conf'. See +linkgit:gitweb.conf[5] for details, especially information about precedence +rules. + +If you use the rewrite rules from the example you *might* also need +something like the following in your gitweb configuration file +('/etc/gitweb.conf' following example): +---------------------------------------------------------------------------- +@stylesheets = ("/some/absolute/path/gitweb.css"); +$my_uri = "/"; +$home_link = "/"; +$per_request_config = 1; +---------------------------------------------------------------------------- +Nowadays though gitweb should create HTML base tag when needed (to set base +URI for relative links), so it should work automatically. + + +Webserver configuration with multiple projects' root +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +If you want to use gitweb with several project roots you can edit your +Apache virtual host and gitweb configuration files in the following way. + +The virtual host configuration (in Apache configuration file) should look +like this: +-------------------------------------------------------------------------- +<VirtualHost *:80> + ServerName git.example.org + DocumentRoot /pub/git + SetEnv GITWEB_CONFIG /etc/gitweb.conf + + # turning on mod rewrite + RewriteEngine on + + # make the front page an internal rewrite to the gitweb script + RewriteRule ^/$ /cgi-bin/gitweb.cgi [QSA,L,PT] + + # look for a public_git folder in unix users' home + # http://git.example.org/~<user>/ + RewriteRule ^/\~([^\/]+)(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \ + [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT] + + # http://git.example.org/+<user>/ + #RewriteRule ^/\+([^\/]+)(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \ + [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT] + + # http://git.example.org/user/<user>/ + #RewriteRule ^/user/([^\/]+)/(gitweb.cgi)?$ /cgi-bin/gitweb.cgi \ + [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT] + + # defined list of project roots + RewriteRule ^/scm(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \ + [QSA,E=GITWEB_PROJECTROOT:/pub/scm/,L,PT] + RewriteRule ^/var(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \ + [QSA,E=GITWEB_PROJECTROOT:/var/git/,L,PT] + + # make access for "dumb clients" work + RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \ + /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT] +</VirtualHost> +-------------------------------------------------------------------------- + +Here actual project root is passed to gitweb via `GITWEB_PROJECT_ROOT` +environment variable from a web server, so you need to put the following +line in gitweb configuration file ('/etc/gitweb.conf' in above example): +-------------------------------------------------------------------------- +$projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/pub/git"; +-------------------------------------------------------------------------- +*Note* that this requires to be set for each request, so either +`$per_request_config` must be false, or the above must be put in code +referenced by `$per_request_config`; + +These configurations enable two things. First, each unix user (`<user>`) of +the server will be able to browse through gitweb Git repositories found in +'~/public_git/' with the following url: + + http://git.example.org/~<user>/ + +If you do not want this feature on your server just remove the second +rewrite rule. + +If you already use `mod_userdir` in your virtual host or you don't want to +use the \'~' as first character, just comment or remove the second rewrite +rule, and uncomment one of the following according to what you want. + +Second, repositories found in '/pub/scm/' and '/var/git/' will be accessible +through `http://git.example.org/scm/` and `http://git.example.org/var/`. +You can add as many project roots as you want by adding rewrite rules like +the third and the fourth. + + +PATH_INFO usage +~~~~~~~~~~~~~~~ +If you enable PATH_INFO usage in gitweb by putting +---------------------------------------------------------------------------- +$feature{'pathinfo'}{'default'} = [1]; +---------------------------------------------------------------------------- +in your gitweb configuration file, it is possible to set up your server so +that it consumes and produces URLs in the form + + http://git.example.com/project.git/shortlog/sometag + +i.e. without 'gitweb.cgi' part, by using a configuration such as the +following. This configuration assumes that '/var/www/gitweb' is the +DocumentRoot of your webserver, contains the gitweb.cgi script and +complementary static files (stylesheet, favicon, JavaScript): + +---------------------------------------------------------------------------- +<VirtualHost *:80> + ServerAlias git.example.com + + DocumentRoot /var/www/gitweb + + <Directory /var/www/gitweb> + Options ExecCGI + AddHandler cgi-script cgi + + DirectoryIndex gitweb.cgi + + RewriteEngine On + RewriteCond %{REQUEST_FILENAME} !-f + RewriteCond %{REQUEST_FILENAME} !-d + RewriteRule ^.* /gitweb.cgi/$0 [L,PT] + </Directory> +</VirtualHost> +---------------------------------------------------------------------------- +The rewrite rule guarantees that existing static files will be properly +served, whereas any other URL will be passed to gitweb as PATH_INFO +parameter. + +*Notice* that in this case you don't need special settings for +`@stylesheets`, `$my_uri` and `$home_link`, but you lose "dumb client" +access to your project .git dirs (described in "Single URL for gitweb and +for fetching" section). A possible workaround for the latter is the +following: in your project root dir (e.g. '/pub/git') have the projects +named *without* a .git extension (e.g. '/pub/git/project' instead of +'/pub/git/project.git') and configure Apache as follows: +---------------------------------------------------------------------------- +<VirtualHost *:80> + ServerAlias git.example.com + + DocumentRoot /var/www/gitweb + + AliasMatch ^(/.*?)(\.git)(/.*)?$ /pub/git$1$3 + <Directory /var/www/gitweb> + Options ExecCGI + AddHandler cgi-script cgi + + DirectoryIndex gitweb.cgi + + RewriteEngine On + RewriteCond %{REQUEST_FILENAME} !-f + RewriteCond %{REQUEST_FILENAME} !-d + RewriteRule ^.* /gitweb.cgi/$0 [L,PT] + </Directory> +</VirtualHost> +---------------------------------------------------------------------------- + +The additional AliasMatch makes it so that + + http://git.example.com/project.git + +will give raw access to the project's Git dir (so that the project can be +cloned), while + + http://git.example.com/project + +will provide human-friendly gitweb access. + +This solution is not 100% bulletproof, in the sense that if some project has +a named ref (branch, tag) starting with 'git/', then paths such as + + http://git.example.com/project/command/abranch..git/abranch + +will fail with a 404 error. + + +BUGS +---- +Please report any bugs or feature requests to git@vger.kernel.org, +putting "gitweb" in the subject of email. + +SEE ALSO +-------- +linkgit:gitweb.conf[5], linkgit:git-instaweb[1] + +'gitweb/README', 'gitweb/INSTALL' + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt index 5e4f362ff..f16c414ea 100644 --- a/Documentation/gitworkflows.txt +++ b/Documentation/gitworkflows.txt @@ -3,7 +3,7 @@ gitworkflows(7) NAME ---- -gitworkflows - An overview of recommended workflows with git +gitworkflows - An overview of recommended workflows with Git SYNOPSIS -------- @@ -39,8 +39,8 @@ To achieve this, try to split your work into small steps from the very beginning. It is always easier to squash a few commits together than to split one big commit into several. Don't be afraid of making too small or imperfect steps along the way. You can always go back later -and edit the commits with `git rebase \--interactive` before you -publish them. You can use `git stash save \--keep-index` to run the +and edit the commits with `git rebase --interactive` before you +publish them. You can use `git stash save --keep-index` to run the test suite independent of other uncommitted changes; see the EXAMPLES section of linkgit:git-stash[1]. @@ -242,10 +242,10 @@ tag to the tip of 'master' indicating the release version: .Release tagging [caption="Recipe: "] ===================================== -`git tag -s -m "GIT X.Y.Z" vX.Y.Z master` +`git tag -s -m "Git X.Y.Z" vX.Y.Z master` ===================================== -You need to push the new tag to a public git server (see +You need to push the new tag to a public Git server (see "DISTRIBUTED WORKFLOWS" below). This makes the tag available to others tracking your project. The push could also trigger a post-update hook to perform release-related items such as building diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index 3595b586b..378306f58 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -7,7 +7,7 @@ A bare repository is normally an appropriately named <<def_directory,directory>> with a `.git` suffix that does not have a locally checked-out copy of any of the files under - revision control. That is, all of the `git` + revision control. That is, all of the Git administrative and control files that would normally be present in the hidden `.git` sub-directory are directly present in the `repository.git` directory instead, @@ -22,7 +22,7 @@ <<def_commit,commit>> on a branch is referred to as the tip of that branch. The tip of the branch is referenced by a branch <<def_head,head>>, which moves forward as additional development - is done on the branch. A single git + is done on the branch. A single Git <<def_repository,repository>> can track an arbitrary number of branches, but your <<def_working_tree,working tree>> is associated with just one of them (the "current" or "checked out" @@ -37,9 +37,9 @@ <<def_commit,commit>> could be one of its <<def_parent,parents>>). [[def_changeset]]changeset:: - BitKeeper/cvsps speak for "<<def_commit,commit>>". Since git does not + BitKeeper/cvsps speak for "<<def_commit,commit>>". Since Git does not store changes, but states, it really does not make sense to use the term - "changesets" with git. + "changesets" with Git. [[def_checkout]]checkout:: The action of updating all or part of the @@ -52,7 +52,7 @@ [[def_cherry-picking]]cherry-picking:: In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of changes out of a series of changes (typically commits) and record them - as a new series of changes on top of a different codebase. In GIT, this is + as a new series of changes on top of a different codebase. In Git, this is performed by the "git cherry-pick" command to extract the change introduced by an existing <<def_commit,commit>> and to record it based on the tip of the current <<def_branch,branch>> as a new commit. @@ -64,14 +64,14 @@ [[def_commit]]commit:: As a noun: A single point in the - git history; the entire history of a project is represented as a + Git history; the entire history of a project is represented as a set of interrelated commits. The word "commit" is often - used by git in the same places other revision control systems + used by Git in the same places other revision control systems use the words "revision" or "version". Also used as a short hand for <<def_commit_object,commit object>>. + As a verb: The action of storing a new snapshot of the project's -state in the git history, by creating a new commit representing the current +state in the Git history, by creating a new commit representing the current state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>> to point at the new commit. @@ -82,8 +82,20 @@ to point at the new commit. to the top <<def_directory,directory>> of the stored revision. -[[def_core_git]]core git:: - Fundamental data structures and utilities of git. Exposes only limited +[[def_commit-ish]]commit-ish (also committish):: + A <<def_commit_object,commit object>> or an + <<def_object,object>> that can be recursively dereferenced to + a commit object. + The following are all commit-ishes: + a commit object, + a <<def_tag_object,tag object>> that points to a commit + object, + a tag object that points to a tag object that points to a + commit object, + etc. + +[[def_core_git]]core Git:: + Fundamental data structures and utilities of Git. Exposes only limited source code management tools. [[def_DAG]]DAG:: @@ -100,12 +112,22 @@ to point at the new commit. [[def_detached_HEAD]]detached HEAD:: Normally the <<def_HEAD,HEAD>> stores the name of a - <<def_branch,branch>>. However, git also allows you to <<def_checkout,check out>> - an arbitrary <<def_commit,commit>> that isn't necessarily the tip of any - particular branch. In this case HEAD is said to be "detached". - -[[def_dircache]]dircache:: - You are *waaaaay* behind. See <<def_index,index>>. + <<def_branch,branch>>, and commands that operate on the + history HEAD represents operate on the history leading to the + tip of the branch the HEAD points at. However, Git also + allows you to <<def_checkout,check out>> an arbitrary + <<def_commit,commit>> that isn't necessarily the tip of any + particular branch. The HEAD in such a state is called + "detached". ++ +Note that commands that operate on the history of the current branch +(e.g. `git commit` to build a new history on top of it) still work +while the HEAD is detached. They update the HEAD to point at the tip +of the updated history without affecting any branch. Commands that +update or inquire information _about_ the current branch (e.g. `git +branch --set-upstream-to` that sets what remote-tracking branch the +current branch integrates with) obviously do not work, as there is no +(real) current branch to ask about in this state. [[def_directory]]directory:: The list you get with "ls" :-) @@ -115,11 +137,6 @@ to point at the new commit. it contains modifications which have not been <<def_commit,committed>> to the current <<def_branch,branch>>. -[[def_ent]]ent:: - Favorite synonym to "<<def_tree-ish,tree-ish>>" by some total geeks. See - `http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth - explanation. Avoid this term, not to confuse people. - [[def_evil_merge]]evil merge:: An evil merge is a <<def_merge,merge>> that introduces changes that do not appear in any <<def_parent,parent>>. @@ -142,22 +159,26 @@ to point at the new commit. and to get them, too. See also linkgit:git-fetch[1]. [[def_file_system]]file system:: - Linus Torvalds originally designed git to be a user space file system, + Linus Torvalds originally designed Git to be a user space file system, i.e. the infrastructure to hold files and directories. That ensured the - efficiency and speed of git. + efficiency and speed of Git. -[[def_git_archive]]git archive:: +[[def_git_archive]]Git archive:: Synonym for <<def_repository,repository>> (for arch people). +[[def_gitfile]]gitfile:: + A plain file `.git` at the root of a working tree that + points at the directory that is the real repository. + [[def_grafts]]grafts:: Grafts enables two otherwise different lines of development to be joined together by recording fake ancestry information for commits. This way - you can make git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has + you can make Git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has is different from what was recorded when the commit was created. Configured via the `.git/info/grafts` file. [[def_hash]]hash:: - In git's context, synonym to <<def_object_name,object name>>. + In Git's context, synonym for <<def_object_name,object name>>. [[def_head]]head:: A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a @@ -177,14 +198,14 @@ to point at the new commit. A synonym for <<def_head,head>>. [[def_hook]]hook:: - During the normal execution of several git commands, call-outs are made + During the normal execution of several Git commands, call-outs are made to optional scripts that allow a developer to add functionality or checking. Typically, the hooks allow for a command to be pre-verified and potentially aborted, and allow for a post-notification after the operation is done. The hook scripts are found in the `$GIT_DIR/hooks/` directory, and are enabled by simply removing the `.sample` suffix from the filename. In earlier versions - of git you had to make them executable. + of Git you had to make them executable. [[def_index]]index:: A collection of files with stat information, whose contents are stored @@ -201,7 +222,7 @@ to point at the new commit. [[def_master]]master:: The default development <<def_branch,branch>>. Whenever you - create a git <<def_repository,repository>>, a branch named + create a Git <<def_repository,repository>>, a branch named "master" is created, and becomes the active branch. In most cases, this contains the local development, though that is purely by convention and is not required. @@ -228,8 +249,8 @@ This commit is referred to as a "merge commit", or sometimes just a "merge". [[def_object]]object:: - The unit of storage in git. It is uniquely identified by the - <<def_SHA1,SHA1>> of its contents. Consequently, an + The unit of storage in Git. It is uniquely identified by the + <<def_SHA1,SHA-1>> of its contents. Consequently, an object can not be changed. [[def_object_database]]object database:: @@ -241,10 +262,9 @@ This commit is referred to as a "merge commit", or sometimes just a Synonym for <<def_object_name,object name>>. [[def_object_name]]object name:: - The unique identifier of an <<def_object,object>>. The <<def_hash,hash>> - of the object's contents using the Secure Hash Algorithm - 1 and usually represented by the 40 character hexadecimal encoding of - the <<def_hash,hash>> of the object. + The unique identifier of an <<def_object,object>>. The + object name is usually represented by a 40 character + hexadecimal string. Also colloquially called <<def_SHA1,SHA-1>>. [[def_object_type]]object type:: One of the identifiers "<<def_commit_object,commit>>", @@ -253,14 +273,13 @@ This commit is referred to as a "merge commit", or sometimes just a <<def_object,object>>. [[def_octopus]]octopus:: - To <<def_merge,merge>> more than two <<def_branch,branches>>. Also denotes an - intelligent predator. + To <<def_merge,merge>> more than two <<def_branch,branches>>. [[def_origin]]origin:: The default upstream <<def_repository,repository>>. Most projects have at least one upstream project which they track. By default 'origin' is used for that purpose. New upstream updates - will be fetched into remote <<def_remote_tracking_branch,remote-tracking branches>> named + will be fetched into <<def_remote_tracking_branch,remote-tracking branches>> named origin/name-of-upstream-branch, which you can see using `git branch -r`. @@ -274,7 +293,7 @@ This commit is referred to as a "merge commit", or sometimes just a pack. [[def_pathspec]]pathspec:: - Pattern used to specify paths. + Pattern used to limit paths in Git commands. + Pathspecs are used on the command line of "git ls-files", "git ls-tree", "git add", "git grep", "git diff", "git checkout", @@ -283,6 +302,8 @@ limit the scope of operations to some subset of the tree or worktree. See the documentation of each command for whether paths are relative to the current directory or toplevel. The pathspec syntax is as follows: ++ +-- * any path matches itself * the pathspec up to the last slash represents a @@ -292,41 +313,78 @@ pathspec syntax is as follows: of the pathname. Paths relative to the directory prefix will be matched against that pattern using fnmatch(3); in particular, '*' and '?' _can_ match directory separators. + +-- + For example, Documentation/*.jpg will match all .jpg files in the Documentation subtree, including Documentation/chapter_1/figure_1.jpg. - + A pathspec that begins with a colon `:` has special meaning. In the short form, the leading colon `:` is followed by zero or more "magic signature" letters (which optionally is terminated by another colon `:`), -and the remainder is the pattern to match against the path. The optional -colon that terminates the "magic signature" can be omitted if the pattern -begins with a character that cannot be a "magic signature" and is not a -colon. +and the remainder is the pattern to match against the path. +The "magic signature" consists of ASCII symbols that are neither +alphanumeric, glob, regex special charaters nor colon. +The optional colon that terminates the "magic signature" can be +omitted if the pattern begins with a character that does not belong to +"magic signature" symbol set and is not a colon. + In the long form, the leading colon `:` is followed by a open parenthesis `(`, a comma-separated list of zero or more "magic words", and a close parentheses `)`, and the remainder is the pattern to match against the path. + -The "magic signature" consists of an ASCII symbol that is not -alphanumeric. +A pathspec with only a colon means "there is no pathspec". This form +should not be combined with other pathspec. + -- -top `/`;; - The magic word `top` (mnemonic: `/`) makes the pattern match - from the root of the working tree, even when you are running - the command from inside a subdirectory. --- +top;; + The magic word `top` (magic signature: `/`) makes the pattern + match from the root of the working tree, even when you are + running the command from inside a subdirectory. + +literal;; + Wildcards in the pattern such as `*` or `?` are treated + as literal characters. + +icase;; + Case insensitive match. + +glob;; + Git treats the pattern as a shell glob suitable for + consumption by fnmatch(3) with the FNM_PATHNAME flag: + wildcards in the pattern will not match a / in the pathname. + For example, "Documentation/{asterisk}.html" matches + "Documentation/git.html" but not "Documentation/ppc/ppc.html" + or "tools/perf/Documentation/perf.html". + -Currently only the slash `/` is recognized as the "magic signature", -but it is envisioned that we will support more types of magic in later -versions of git. +Two consecutive asterisks ("`**`") in patterns matched against +full pathname may have special meaning: + + - A leading "`**`" followed by a slash means match in all + directories. For example, "`**/foo`" matches file or directory + "`foo`" anywhere, the same as pattern "`foo`". "`**/foo/bar`" + matches file or directory "`bar`" anywhere that is directly + under directory "`foo`". + + - A trailing "`/**`" matches everything inside. For example, + "`abc/**`" matches all files inside directory "abc", relative + to the location of the `.gitignore` file, with infinite depth. + + - A slash followed by two consecutive asterisks then a slash + matches zero or more directories. For example, "`a/**/b`" + matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on. + + - Other consecutive asterisks are considered invalid. + -A pathspec with only a colon means "there is no pathspec". This form -should not be combined with other pathspec. +Glob magic is incompatible with literal magic. + +exclude;; + After a path matches any non-exclude pathspec, it will be run + through all exclude pathspec (magic signature: `!`). If it + matches, the path is ignored. +-- [[def_parent]]parent:: A <<def_commit_object,commit object>> contains a (possibly empty) list @@ -341,12 +399,12 @@ should not be combined with other pathspec. particular line of text. See linkgit:git-diff[1]. [[def_plumbing]]plumbing:: - Cute name for <<def_core_git,core git>>. + Cute name for <<def_core_git,core Git>>. [[def_porcelain]]porcelain:: Cute name for programs and program suites depending on - <<def_core_git,core git>>, presenting a high level access to - core git. Porcelains expose more of a <<def_SCM,SCM>> + <<def_core_git,core Git>>, presenting a high level access to + core Git. Porcelains expose more of a <<def_SCM,SCM>> interface than the <<def_plumbing,plumbing>>. [[def_pull]]pull:: @@ -381,10 +439,20 @@ should not be combined with other pathspec. to the result. [[def_ref]]ref:: - A 40-byte hex representation of a <<def_SHA1,SHA1>> or a name that - denotes a particular <<def_object,object>>. They may be stored in - a file under `$GIT_DIR/refs/` directory, or - in the `$GIT_DIR/packed-refs` file. + A name that begins with `refs/` (e.g. `refs/heads/master`) + that points to an <<def_object_name,object name>> or another + ref (the latter is called a <<def_symref,symbolic ref>>). + For convenience, a ref can sometimes be abbreviated when used + as an argument to a Git command; see linkgit:gitrevisions[7] + for details. + Refs are stored in the <<def_repository,repository>>. ++ +The ref namespace is hierarchical. +Different subhierarchies are used for different purposes (e.g. the +`refs/heads/` hierarchy is used to represent local branches). ++ +There are a few special-purpose refs that do not begin with `refs/`. +The most notable example is `HEAD`. [[def_reflog]]reflog:: A reflog shows the local "history" of a ref. In other words, @@ -395,23 +463,16 @@ should not be combined with other pathspec. [[def_refspec]]refspec:: A "refspec" is used by <<def_fetch,fetch>> and <<def_push,push>> to describe the mapping between remote - <<def_ref,ref>> and local ref. They are combined with a colon in - the format <src>:<dst>, preceded by an optional plus sign, +. - For example: `git fetch $URL - refs/heads/master:refs/heads/origin` means "grab the master - <<def_branch,branch>> <<def_head,head>> from the $URL and store - it as my origin branch head". And `git push - $URL refs/heads/master:refs/heads/to-upstream` means "publish my - master branch head as to-upstream branch at $URL". See also - linkgit:git-push[1]. + <<def_ref,ref>> and local ref. [[def_remote_tracking_branch]]remote-tracking branch:: - A regular git <<def_branch,branch>> that is used to follow changes from - another <<def_repository,repository>>. A remote-tracking - branch should not contain direct modifications or have local commits - made to it. A remote-tracking branch can usually be - identified as the right-hand-side <<def_ref,ref>> in a Pull: - <<def_refspec,refspec>>. + A <<def_ref,ref>> that is used to follow changes from another + <<def_repository,repository>>. It typically looks like + 'refs/remotes/foo/bar' (indicating that it tracks a branch named + 'bar' in a remote named 'foo'), and matches the right-hand-side of + a configured fetch <<def_refspec,refspec>>. A remote-tracking + branch should not contain direct modifications or have local + commits made to it. [[def_repository]]repository:: A collection of <<def_ref,refs>> together with an @@ -426,9 +487,7 @@ should not be combined with other pathspec. <<def_merge,merge>> left behind. [[def_revision]]revision:: - A particular state of files and directories which was stored in the - <<def_object_database,object database>>. It is referenced by a - <<def_commit_object,commit object>>. + Synonym for <<def_commit,commit>> (the noun). [[def_rewind]]rewind:: To throw away part of the development, i.e. to assign the @@ -437,13 +496,14 @@ should not be combined with other pathspec. [[def_SCM]]SCM:: Source code management (tool). -[[def_SHA1]]SHA1:: - Synonym for <<def_object_name,object name>>. +[[def_SHA1]]SHA-1:: + "Secure Hash Algorithm 1"; a cryptographic hash function. + In the context of Git used as a synonym for <<def_object_name,object name>>. [[def_shallow_repository]]shallow repository:: A shallow <<def_repository,repository>> has an incomplete history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other - words, git is told to pretend that these commits do not have the + words, Git is told to pretend that these commits do not have the parents, even though they are recorded in the <<def_commit_object,commit object>>). This is sometimes useful when you are interested only in the recent history of a project even though the real history recorded in the @@ -452,7 +512,7 @@ should not be combined with other pathspec. its history can be later deepened with linkgit:git-fetch[1]. [[def_symref]]symref:: - Symbolic reference: instead of containing the <<def_SHA1,SHA1>> + Symbolic reference: instead of containing the <<def_SHA1,SHA-1>> id itself, it is of the format 'ref: refs/some/thing' and when referenced, it recursively dereferences to this reference. '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic @@ -464,9 +524,9 @@ should not be combined with other pathspec. object of an arbitrary type (typically a tag points to either a <<def_tag_object,tag>> or a <<def_commit_object,commit object>>). In contrast to a <<def_head,head>>, a tag is not updated by - the `commit` command. A git tag has nothing to do with a Lisp + the `commit` command. A Git tag has nothing to do with a Lisp tag (which would be called an <<def_object_type,object type>> - in git's context). A tag is most typically used to mark a particular + in Git's context). A tag is most typically used to mark a particular point in the commit ancestry <<def_chain,chain>>. [[def_tag_object]]tag object:: @@ -476,7 +536,7 @@ should not be combined with other pathspec. signature, in which case it is called a "signed tag object". [[def_topic_branch]]topic branch:: - A regular git <<def_branch,branch>> that is used by a developer to + A regular Git <<def_branch,branch>> that is used by a developer to identify a conceptual line of development. Since branches are very easy and inexpensive, it is often desirable to have several small branches that each contain very well defined concepts or small incremental yet @@ -492,10 +552,19 @@ should not be combined with other pathspec. with refs to the associated blob and/or tree objects. A <<def_tree,tree>> is equivalent to a <<def_directory,directory>>. -[[def_tree-ish]]tree-ish:: - A <<def_ref,ref>> pointing to either a <<def_commit_object,commit - object>>, a <<def_tree_object,tree object>>, or a <<def_tag_object,tag - object>> pointing to a tag or commit or tree object. +[[def_tree-ish]]tree-ish (also treeish):: + A <<def_tree_object,tree object>> or an <<def_object,object>> + that can be recursively dereferenced to a tree object. + Dereferencing a <<def_commit_object,commit object>> yields the + tree object corresponding to the <<def_revision,revision>>'s + top <<def_directory,directory>>. + The following are all tree-ishes: + a <<def_commit-ish,commit-ish>>, + a tree object, + a <<def_tag_object,tag object>> that points to a tree object, + a tag object that points to a tag object that points to a tree + object, + etc. [[def_unmerged_index]]unmerged index:: An <<def_index,index>> which contains unmerged diff --git a/Documentation/howto-index.sh b/Documentation/howto-index.sh index 34aa30c5b..a2340864b 100755 --- a/Documentation/howto-index.sh +++ b/Documentation/howto-index.sh @@ -1,11 +1,11 @@ #!/bin/sh cat <<\EOF -GIT Howto Index +Git Howto Index =============== Here is a collection of mailing list postings made by various -people describing how they use git in their workflow. +people describing how they use Git in their workflow. EOF diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index d527b3077..ca4378740 100644 --- a/Documentation/howto/maintain-git.txt +++ b/Documentation/howto/maintain-git.txt @@ -1,53 +1,64 @@ From: Junio C Hamano <gitster@pobox.com> Date: Wed, 21 Nov 2007 16:32:55 -0800 Subject: Addendum to "MaintNotes" -Abstract: Imagine that git development is racing along as usual, when our friendly +Abstract: Imagine that Git development is racing along as usual, when our friendly neighborhood maintainer is struck down by a wayward bus. Out of the hordes of suckers (loyal developers), you have been tricked (chosen) to step up as the new maintainer. This howto will show you "how to" do it. +Content-type: text/asciidoc -The maintainer's git time is spent on three activities. +How to maintain Git +=================== - - Communication (60%) +Activities +---------- + +The maintainer's Git time is spent on three activities. + + - Communication (45%) Mailing list discussions on general design, fielding user questions, diagnosing bug reports; reviewing, commenting on, suggesting alternatives to, and rejecting patches. - - Integration (30%) + - Integration (50%) Applying new patches from the contributors while spotting and correcting minor mistakes, shuffling the integration and testing branches, pushing the results out, cutting the releases, and making announcements. - - Own development (10%) + - Own development (5%) Scratching my own itch and sending proposed patch series out. +The Policy +---------- + The policy on Integration is informally mentioned in "A Note from the maintainer" message, which is periodically posted to this mailing list after each feature release is made. -The policy. - - - Feature releases are numbered as vX.Y.Z and are meant to + - Feature releases are numbered as vX.Y.0 and are meant to contain bugfixes and enhancements in any area, including functionality, performance and usability, without regression. - - Maintenance releases are numbered as vX.Y.Z.W and are meant - to contain only bugfixes for the corresponding vX.Y.Z feature - release and earlier maintenance releases vX.Y.Z.V (V < W). + - One release cycle for a feature release is expected to last for + eight to ten weeks. + + - Maintenance releases are numbered as vX.Y.Z and are meant + to contain only bugfixes for the corresponding vX.Y.0 feature + release and earlier maintenance releases vX.Y.W (W < Z). - 'master' branch is used to prepare for the next feature release. In other words, at some point, the tip of 'master' - branch is tagged with vX.Y.Z. + branch is tagged with vX.Y.0. - 'maint' branch is used to prepare for the next maintenance - release. After the feature release vX.Y.Z is made, the tip + release. After the feature release vX.Y.0 is made, the tip of 'maint' branch is set to that release, and bugfixes will accumulate on the branch, and at some point, the tip of the - branch is tagged with vX.Y.Z.1, vX.Y.Z.2, and so on. + branch is tagged with vX.Y.1, vX.Y.2, and so on. - 'next' branch is used to publish changes (both enhancements and fixes) that (1) have worthwhile goal, (2) are in a fairly @@ -58,12 +69,15 @@ The policy. - 'pu' branch is used to publish other proposed changes that do not yet pass the criteria set for 'next'. - - The tips of 'master', 'maint' and 'next' branches will always - fast-forward, to allow people to build their own - customization on top of them. + - The tips of 'master' and 'maint' branches will not be rewound to + allow people to build their own customization on top of them. + Early in a new development cycle, 'next' is rewound to the tip of + 'master' once, but otherwise it will not be rewound until the end + of the cycle. - - Usually 'master' contains all of 'maint', 'next' contains all - of 'master' and 'pu' contains all of 'next'. + - Usually 'master' contains all of 'maint' and 'next' contains all + of 'master'. 'pu' contains all the topics merged to 'next', but + is rebuilt directly on 'master'. - The tip of 'master' is meant to be more stable than any tagged releases, and the users are encouraged to follow it. @@ -72,15 +86,27 @@ The policy. users are encouraged to test it so that regressions and bugs are found before new topics are merged to 'master'. +Note that before v1.9.0 release, the version numbers used to be +structured slightly differently. vX.Y.Z were feature releases while +vX.Y.Z.W were maintenance releases for vX.Y.Z. + -A typical git day for the maintainer implements the above policy +A Typical Git Day +----------------- + +A typical Git day for the maintainer implements the above policy by doing the following: - - Scan mailing list and #git channel log. Respond with review - comments, suggestions etc. Kibitz. Collect potentially - usable patches from the mailing list. Patches about a single - topic go to one mailbox (I read my mail in Gnus, and type - \C-o to save/append messages in files in mbox format). + - Scan mailing list. Respond with review comments, suggestions + etc. Kibitz. Collect potentially usable patches from the + mailing list. Patches about a single topic go to one mailbox (I + read my mail in Gnus, and type \C-o to save/append messages in + files in mbox format). + + - Write his own patches to address issues raised on the list but + nobody has stepped up solving. Send it out just like other + contributors do, and pick them up just like patches from other + contributors (see above). - Review the patches in the saved mailboxes. Edit proposed log message for typofixes and clarifications, and add Acks @@ -96,40 +122,32 @@ by doing the following: - Obviously correct fixes that pertain to the tip of 'master' are directly applied to 'master'. + - Other topics are not handled in this step. + This step is done with "git am". $ git checkout master ;# or "git checkout maint" - $ git am -3 -s mailbox + $ git am -sc3 mailbox $ make test - - Merge downwards (maint->master): - - $ git checkout master - $ git merge maint - $ make test + In practice, almost no patch directly goes to 'master' or + 'maint'. - Review the last issue of "What's cooking" message, review the - topics scheduled for merging upwards (topic->master and - topic->maint), and merge. + topics ready for merging (topic->master and topic->maint). Use + "Meta/cook -w" script (where Meta/ contains a checkout of the + 'todo' branch) to aid this step. + + And perform the merge. Use "Meta/Reintegrate -e" script (see + later) to aid this step. + + $ Meta/cook -w last-issue-of-whats-cooking.mbox $ git checkout master ;# or "git checkout maint" - $ git merge ai/topic ;# or "git merge ai/maint-topic" + $ echo ai/topic | Meta/Reintegrate -e ;# "git merge ai/topic" $ git log -p ORIG_HEAD.. ;# final review $ git diff ORIG_HEAD.. ;# final review $ make test ;# final review - $ git branch -d ai/topic ;# or "git branch -d ai/maint-topic" - - - Merge downwards (maint->master) if needed: - - $ git checkout master - $ git merge maint - $ make test - - - Merge downwards (master->next) if needed: - - $ git checkout next - $ git merge master - $ make test - Handle the remaining patches: @@ -138,9 +156,9 @@ by doing the following: and not in 'master') is applied to a new topic branch that is forked from the tip of 'master'. This includes both enhancements and unobvious fixes to 'master'. A topic - branch is named as ai/topic where "ai" is typically - author's initial and "topic" is a descriptive name of the - topic (in other words, "what's the series is about"). + branch is named as ai/topic where "ai" is two-letter string + named after author's initial and "topic" is a descriptive name + of the topic (in other words, "what's the series is about"). - An unobvious fix meant for 'maint' is applied to a new topic branch that is forked from the tip of 'maint'. The @@ -158,7 +176,8 @@ by doing the following: The above except the "replacement" are all done with: - $ git am -3 -s mailbox + $ git checkout ai/topic ;# or "git checkout -b ai/topic master" + $ git am -sc3 mailbox while patch replacement is often done by: @@ -166,94 +185,170 @@ by doing the following: then replace some parts with the new patch, and reapplying: + $ git checkout ai/topic $ git reset --hard ai/topic~$n - $ git am -3 -s 000*.txt + $ git am -sc3 -s 000*.txt The full test suite is always run for 'maint' and 'master' after patch application; for topic branches the tests are run as time permits. - - Update "What's cooking" message to review the updates to - existing topics, newly added topics and graduated topics. - - This step is helped with Meta/UWC script (where Meta/ contains - a checkout of the 'todo' branch). + - Merge maint to master as needed: - - Merge topics to 'next'. For each branch whose tip is not - merged to 'next', one of three things can happen: + $ git checkout master + $ git merge maint + $ make test - - The commits are all next-worthy; merge the topic to next: + - Merge master to next as needed: $ git checkout next - $ git merge ai/topic ;# or "git merge ai/maint-topic" + $ git merge master $ make test + - Review the last issue of "What's cooking" again and see if topics + that are ready to be merged to 'next' are still in good shape + (e.g. has there any new issue identified on the list with the + series?) + + - Prepare 'jch' branch, which is used to represent somewhere + between 'master' and 'pu' and often is slightly ahead of 'next'. + + $ Meta/Reintegrate master..pu >Meta/redo-jch.sh + + The result is a script that lists topics to be merged in order to + rebuild 'pu' as the input to Meta/Reintegrate script. Remove + later topics that should not be in 'jch' yet. Add a line that + consists of '### match next' before the name of the first topic + in the output that should be in 'jch' but not in 'next' yet. + + - Now we are ready to start merging topics to 'next'. For each + branch whose tip is not merged to 'next', one of three things can + happen: + + - The commits are all next-worthy; merge the topic to next; - The new parts are of mixed quality, but earlier ones are - next-worthy; merge the early parts to next: + next-worthy; merge the early parts to next; + - Nothing is next-worthy; do not do anything. + + This step is aided with Meta/redo-jch.sh script created earlier. + If a topic that was already in 'next' gained a patch, the script + would list it as "ai/topic~1". To include the new patch to the + updated 'next', drop the "~1" part; to keep it excluded, do not + touch the line. If a topic that was not in 'next' should be + merged to 'next', add it at the end of the list. Then: + + $ git checkout -B jch master + $ Meta/redo-jch.sh -c1 + + to rebuild the 'jch' branch from scratch. "-c1" tells the script + to stop merging at the first line that begins with '###' + (i.e. the "### match next" line you added earlier). + + At this point, build-test the result. It may reveal semantic + conflicts (e.g. a topic renamed a variable, another added a new + reference to the variable under its old name), in which case + prepare an appropriate merge-fix first (see appendix), and + rebuild the 'jch' branch from scratch, starting at the tip of + 'master'. + + Then do the same to 'next' $ git checkout next - $ git merge ai/topic~2 ;# the tip two are dubious - $ make test + $ sh Meta/redo-jch.sh -c1 -e - - Nothing is next-worthy; do not do anything. + The "-e" option allows the merge message that comes from the + history of the topic and the comments in the "What's cooking" to + be edited. The resulting tree should match 'jch' as the same set + of topics are merged on 'master'; otherwise there is a mismerge. + Investigate why and do not proceed until the mismerge is found + and rectified. - - Rebase topics that do not have any commit in next yet. This - step is optional but sometimes is worth doing when an old - series that is not in next can take advantage of low-level - framework change that is merged to 'master' already. + $ git diff jch next - $ git rebase master ai/topic + When all is well, clean up the redo-jch.sh script with - This step is helped with Meta/git-topic.perl script to - identify which topic is rebaseable. There also is a - pre-rebase hook to make sure that topics that are already in - 'next' are not rebased beyond the merged commit. + $ sh Meta/redo-jch.sh -u - - Rebuild "pu" to merge the tips of topics not in 'next'. + This removes topics listed in the script that have already been + merged to 'master'. This may lose '### match next' marker; + add it again to the appropriate place when it happens. - $ git checkout pu - $ git reset --hard next - $ git merge ai/topic ;# repeat for all remaining topics - $ make test + - Rebuild 'pu'. - This step is helped with Meta/PU script + $ Meta/Reintegrate master..pu >Meta/redo-pu.sh - - Push four integration branches to a private repository at - k.org and run "make test" on all of them. + Edit the result by adding new topics that are not still in 'pu' + in the script. Then - - Push four integration branches to /pub/scm/git/git.git at - k.org. This triggers its post-update hook which: + $ git checkout -B pu jch + $ sh Meta/redo-pu.sh - (1) runs "git pull" in $HOME/git-doc/ repository to pull - 'master' just pushed out; + When all is well, clean up the redo-pu.sh script with - (2) runs "make doc" in $HOME/git-doc/, install the generated - documentation in staging areas, which are separate - repositories that have html and man branches checked - out. + $ sh Meta/redo-pu.sh -u - (3) runs "git commit" in the staging areas, and run "git - push" back to /pub/scm/git/git.git/ to update the html - and man branches. + Double check by running - (4) installs generated documentation to /pub/software/scm/git/docs/ - to be viewed from http://www.kernel.org/ + $ git branch --no-merged pu - - Fetch html and man branches back from k.org, and push four - integration branches and the two documentation branches to - repo.or.cz + to see there is no unexpected leftover topics. + At this point, build-test the result for semantic conflicts, and + if there are, prepare an appropriate merge-fix first (see + appendix), and rebuild the 'pu' branch from scratch, starting at + the tip of 'jch'. + + - Update "What's cooking" message to review the updates to + existing topics, newly added topics and graduated topics. + + This step is helped with Meta/cook script. + + $ Meta/cook + + This script inspects the history between master..pu, finds tips + of topic branches, compares what it found with the current + contents in Meta/whats-cooking.txt, and updates that file. + Topics not listed in the file but are found in master..pu are + added to the "New topics" section, topics listed in the file that + are no longer found in master..pu are moved to the "Graduated to + master" section, and topics whose commits changed their states + (e.g. used to be only in 'pu', now merged to 'next') are updated + with change markers "<<" and ">>". + + Look for lines enclosed in "<<" and ">>"; they hold contents from + old file that are replaced by this integration round. After + verifying them, remove the old part. Review the description for + each topic and update its doneness and plan as needed. To review + the updated plan, run + + $ Meta/cook -w + + which will pick up comments given to the topics, such as "Will + merge to 'next'", etc. (see Meta/cook script to learn what kind + of phrases are supported). + + - Compile, test and install all four (five) integration branches; + Meta/Dothem script may aid this step. + + - Format documentation if the 'master' branch was updated; + Meta/dodoc.sh script may aid this step. + + - Push the integration branches out to public places; Meta/pushall + script may aid this step. + +Observations +------------ Some observations to be made. - * Each topic is tested individually, and also together with - other topics cooking in 'next'. Until it matures, none part - of it is merged to 'master'. + * Each topic is tested individually, and also together with other + topics cooking first in 'pu', then in 'jch' and then in 'next'. + Until it matures, no part of it is merged to 'master'. * A topic already in 'next' can get fixes while still in 'next'. Such a topic will have many merges to 'next' (in other words, "git log --first-parent next" will show many - "Merge ai/topic to next" for the same topic. + "Merge branch 'ai/topic' to next" for the same topic. * An unobvious fix for 'maint' is cooked in 'next' and then merged to 'master' to make extra sure it is Ok and then @@ -275,3 +370,80 @@ Some observations to be made. * Being in the 'next' branch is not a guarantee for a topic to be included in the next feature release. Being in the 'master' branch typically is. + + +Appendix +-------- + +Preparing a "merge-fix" +~~~~~~~~~~~~~~~~~~~~~~~ + +A merge of two topics may not textually conflict but still have +conflict at the semantic level. A classic example is for one topic +to rename an variable and all its uses, while another topic adds a +new use of the variable under its old name. When these two topics +are merged together, the reference to the variable newly added by +the latter topic will still use the old name in the result. + +The Meta/Reintegrate script that is used by redo-jch and redo-pu +scripts implements a crude but usable way to work this issue around. +When the script merges branch $X, it checks if "refs/merge-fix/$X" +exists, and if so, the effect of it is squashed into the result of +the mechanical merge. In other words, + + $ echo $X | Meta/Reintegrate + +is roughly equivalent to this sequence: + + $ git merge --rerere-autoupdate $X + $ git commit + $ git cherry-pick -n refs/merge-fix/$X + $ git commit --amend + +The goal of this "prepare a merge-fix" step is to come up with a +commit that can be squashed into a result of mechanical merge to +correct semantic conflicts. + +After finding that the result of merging branch "ai/topic" to an +integration branch had such a semantic conflict, say pu~4, check the +problematic merge out on a detached HEAD, edit the working tree to +fix the semantic conflict, and make a separate commit to record the +fix-up: + + $ git checkout pu~4 + $ git show -s --pretty=%s ;# double check + Merge branch 'ai/topic' to pu + $ edit + $ git commit -m 'merge-fix/ai/topic' -a + +Then make a reference "refs/merge-fix/ai/topic" to point at this +result: + + $ git update-ref refs/merge-fix/ai/topic HEAD + +Then double check the result by asking Meta/Reintegrate to redo the +merge: + + $ git checkout pu~5 ;# the parent of the problem merge + $ echo ai/topic | Meta/Reintegrate + $ git diff pu~4 + +This time, because you prepared refs/merge-fix/ai/topic, the +resulting merge should have been tweaked to include the fix for the +semantic conflict. + +Note that this assumes that the order in which conflicting branches +are merged does not change. If the reason why merging ai/topic +branch needs this merge-fix is because another branch merged earlier +to the integration branch changed the underlying assumption ai/topic +branch made (e.g. ai/topic branch added a site to refer to a +variable, while the other branch renamed that variable and adjusted +existing use sites), and if you changed redo-jch (or redo-pu) script +to merge ai/topic branch before the other branch, then the above +merge-fix should not be applied while merging ai/topic, but should +instead be applied while merging the other branch. You would need +to move the fix to apply to the other branch, perhaps like this: + + $ mf=refs/merge-fix + $ git update-ref $mf/$the_other_branch $mf/ai/topic + $ git update-ref -d $mf/ai/topic diff --git a/Documentation/howto/new-command.txt b/Documentation/howto/new-command.txt new file mode 100644 index 000000000..d7de5a3e9 --- /dev/null +++ b/Documentation/howto/new-command.txt @@ -0,0 +1,104 @@ +From: Eric S. Raymond <esr@thyrsus.com> +Abstract: This is how-to documentation for people who want to add extension + commands to Git. It should be read alongside api-builtin.txt. +Content-type: text/asciidoc + +How to integrate new subcommands +================================ + +This is how-to documentation for people who want to add extension +commands to Git. It should be read alongside api-builtin.txt. + +Runtime environment +------------------- + +Git subcommands are standalone executables that live in the Git exec +path, normally /usr/lib/git-core. The git executable itself is a +thin wrapper that knows where the subcommands live, and runs them by +passing command-line arguments to them. + +(If "git foo" is not found in the Git exec path, the wrapper +will look in the rest of your $PATH for it. Thus, it's possible +to write local Git extensions that don't live in system space.) + +Implementation languages +------------------------ + +Most subcommands are written in C or shell. A few are written in +Perl. + +While we strongly encourage coding in portable C for portability, +these specific scripting languages are also acceptable. We won't +accept more without a very strong technical case, as we don't want +to broaden the Git suite's required dependencies. Import utilities, +surgical tools, remote helpers and other code at the edges of the +Git suite are more lenient and we allow Python (and even Tcl/tk), +but they should not be used for core functions. + +This may change in the future. Especially Python is not allowed in +core because we need better Python integration in the Git Windows +installer before we can be confident people in that environment +won't experience an unacceptably large loss of capability. + +C commands are normally written as single modules, named after the +command, that link a collection of functions called libgit. Thus, +your command 'git-foo' would normally be implemented as a single +"git-foo.c" (or "builtin/foo.c" if it is to be linked to the main +binary); this organization makes it easy for people reading the code +to find things. + +See the CodingGuidelines document for other guidance on what we consider +good practice in C and shell, and api-builtin.txt for the support +functions available to built-in commands written in C. + +What every extension command needs +---------------------------------- + +You must have a man page, written in asciidoc (this is what Git help +followed by your subcommand name will display). Be aware that there is +a local asciidoc configuration and macros which you should use. It's +often helpful to start by cloning an existing page and replacing the +text content. + +You must have a test, written to report in TAP (Test Anything Protocol). +Tests are executables (usually shell scripts) that live in the 't' +subdirectory of the tree. Each test name begins with 't' and a sequence +number that controls where in the test sequence it will be executed; +conventionally the rest of the name stem is that of the command +being tested. + +Read the file t/README to learn more about the conventions to be used +in writing tests, and the test support library. + +Integrating a command +--------------------- + +Here are the things you need to do when you want to merge a new +subcommand into the Git tree. + +1. Don't forget to sign off your patch! + +2. Append your command name to one of the variables BUILTIN_OBJS, +EXTRA_PROGRAMS, SCRIPT_SH, SCRIPT_PERL or SCRIPT_PYTHON. + +3. Drop its test in the t directory. + +4. If your command is implemented in an interpreted language with a +p-code intermediate form, make sure .gitignore in the main directory +includes a pattern entry that ignores such files. Python .pyc and +.pyo files will already be covered. + +5. If your command has any dependency on a particular version of +your language, document it in the INSTALL file. + +6. There is a file command-list.txt in the distribution main directory +that categorizes commands by type, so they can be listed in appropriate +subsections in the documentation's summary command list. Add an entry +for yours. To understand the categories, look at git-commands.txt +in the main directory. + +7. Give the maintainer one paragraph to include in the RelNotes file +to describe the new feature; a good place to do so is in the cover +letter [PATCH 0/n]. + +That's all there is to it. diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt index 74a1c0c4b..19ab604f1 100644 --- a/Documentation/howto/rebase-from-internal-branch.txt +++ b/Documentation/howto/rebase-from-internal-branch.txt @@ -4,11 +4,16 @@ Cc: Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org> Subject: Re: sending changesets from the middle of a git tree Date: Sun, 14 Aug 2005 18:37:39 -0700 Abstract: In this article, JC talks about how he rebases the - public "pu" branch using the core GIT tools when he updates + public "pu" branch using the core Git tools when he updates the "master" branch, and how "rebase" works. Also discussed is how this applies to individual developers who sends patches upstream. +Content-type: text/asciidoc +How to rebase from an internal branch +===================================== + +-------------------------------------- Petr Baudis <pasky@suse.cz> writes: > Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter @@ -19,13 +24,14 @@ Petr Baudis <pasky@suse.cz> writes: >> > branch to the real branches. >> > Actually, wouldn't this be also precisely for what StGIT is intended to? +-------------------------------------- Exactly my feeling. I was sort of waiting for Catalin to speak up. With its basing philosophical ancestry on quilt, this is the kind of task StGIT is designed to do. I just have done a simpler one, this time using only the core -GIT tools. +Git tools. I had a handful of commits that were ahead of master in pu, and I wanted to add some documentation bypassing my usual habit of @@ -90,7 +96,7 @@ you ran fsck-cache, which is normal. After testing "pu", you can run "git prune" to get rid of those original three commits. While I am talking about "git rebase", I should talk about how -to do cherrypicking using only the core GIT tools. +to do cherrypicking using only the core Git tools. Let's go back to the earlier picture, with different labels. @@ -156,8 +162,3 @@ you continue on starting from the new "master" head, which is the #1' commit. -jc - -- -To unsubscribe from this list: send the line "unsubscribe git" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/Documentation/howto/rebuild-from-update-hook.txt b/Documentation/howto/rebuild-from-update-hook.txt index 48c67568d..25378f68d 100644 --- a/Documentation/howto/rebuild-from-update-hook.txt +++ b/Documentation/howto/rebuild-from-update-hook.txt @@ -3,19 +3,23 @@ Message-ID: <7vy86o6usx.fsf@assigned-by-dhcp.cox.net> From: Junio C Hamano <gitster@pobox.com> Date: Fri, 26 Aug 2005 18:19:10 -0700 Abstract: In this how-to article, JC talks about how he - uses the post-update hook to automate git documentation page + uses the post-update hook to automate Git documentation page shown at http://www.kernel.org/pub/software/scm/git/docs/. +Content-type: text/asciidoc + +How to rebuild from update hook +=============================== The pages under http://www.kernel.org/pub/software/scm/git/docs/ are built from Documentation/ directory of the git.git project and needed to be kept up-to-date. The www.kernel.org/ servers are mirrored and I was told that the origin of the mirror is on the machine $some.kernel.org, on which I was given an account -when I took over git maintainership from Linus. +when I took over Git maintainership from Linus. The directories relevant to this how-to are these two: - /pub/scm/git/git.git/ The public git repository. + /pub/scm/git/git.git/ The public Git repository. /pub/software/scm/git/docs/ The HTML documentation page. So I made a repository to generate the documentation under my @@ -42,7 +46,7 @@ script: EOF Initially I used to run this by hand whenever I push into the -public git repository. Then I did a cron job that ran twice a +public Git repository. Then I did a cron job that ran twice a day. The current round uses the post-update hook mechanism, like this: diff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt index 323b513ed..1b3b188d3 100644 --- a/Documentation/howto/recover-corrupted-blob-object.txt +++ b/Documentation/howto/recover-corrupted-blob-object.txt @@ -3,18 +3,24 @@ From: Linus Torvalds <torvalds@linux-foundation.org> Subject: corrupt object on git-gc Abstract: Some tricks to reconstruct blob objects in order to fix a corrupted repository. +Content-type: text/asciidoc +How to recover a corrupted blob object +====================================== + +----------------------------------------------------------- On Fri, 9 Nov 2007, Yossi Leybovich wrote: > > Did not help still the repository look for this object? > Any one know how can I track this object and understand which file is it +----------------------------------------------------------- -So exactly *because* the SHA1 hash is cryptographically secure, the hash +So exactly *because* the SHA-1 hash is cryptographically secure, the hash itself doesn't actually tell you anything, in order to fix a corrupt object you basically have to find the "original source" for it. The easiest way to do that is almost always to have backups, and find the -same object somewhere else. Backups really are a good idea, and git makes +same object somewhere else. Backups really are a good idea, and Git makes it pretty easy (if nothing else, just clone the repository somewhere else, and make sure that you do *not* use a hard-linked clone, and preferably not the same disk/machine). @@ -31,19 +37,23 @@ original object, so right now the corrupt object is useless, but it's very interesting for the future, in the hope that you can re-create a non-corrupt version. +----------------------------------------------------------- So: > ib]$ mv .git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../ +----------------------------------------------------------- This is the right thing to do, although it's usually best to save it under -it's full SHA1 name (you just dropped the "4b" from the result ;). +it's full SHA-1 name (you just dropped the "4b" from the result ;). Let's see what that tells us: +----------------------------------------------------------- > ib]$ git-fsck --full > broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 > to blob 4b9458b3786228369c63936db65827de3cc06200 > missing blob 4b9458b3786228369c63936db65827de3cc06200 +----------------------------------------------------------- Ok, I removed the "dangling commit" messages, because they are just messages about the fact that you probably have rebased etc, so they're not @@ -79,7 +89,7 @@ working tree, in which case fixing this problem is really simple, just do git hash-object -w my-magic-file -again, and if it outputs the missing SHA1 (4b945..) you're now all done! +again, and if it outputs the missing SHA-1 (4b945..) you're now all done! But that's the really lucky case, so let's assume that it was some older version that was broken. How do you tell which version it was? @@ -124,7 +134,7 @@ and your repository is good again! git log --raw --all and just looked for the sha of the missing object (4b9458b..) in that -whole thing. It's up to you - git does *have* a lot of information, it is +whole thing. It's up to you - Git does *have* a lot of information, it is just missing one particular blob version. Trying to recreate trees and especially commits is *much* harder. So you diff --git a/Documentation/howto/recover-corrupted-object-harder.txt b/Documentation/howto/recover-corrupted-object-harder.txt new file mode 100644 index 000000000..6f33dac0e --- /dev/null +++ b/Documentation/howto/recover-corrupted-object-harder.txt @@ -0,0 +1,242 @@ +Date: Wed, 16 Oct 2013 04:34:01 -0400 +From: Jeff King <peff@peff.net> +Subject: pack corruption post-mortem +Abstract: Recovering a corrupted object when no good copy is available. +Content-type: text/asciidoc + +How to recover an object from scratch +===================================== + +I was recently presented with a repository with a corrupted packfile, +and was asked if the data was recoverable. This post-mortem describes +the steps I took to investigate and fix the problem. I thought others +might find the process interesting, and it might help somebody in the +same situation. + +******************************** +Note: In this case, no good copy of the repository was available. For +the much easier case where you can get the corrupted object from +elsewhere, see link:recover-corrupted-blob-object.html[this howto]. +******************************** + +I started with an fsck, which found a problem with exactly one object +(I've used $pack and $obj below to keep the output readable, and also +because I'll refer to them later): + +----------- + $ git fsck + error: $pack SHA1 checksum mismatch + error: index CRC mismatch for object $obj from $pack at offset 51653873 + error: inflate: data stream error (incorrect data check) + error: cannot unpack $obj from $pack at offset 51653873 +----------- + +The pack checksum failing means a byte is munged somewhere, and it is +presumably in the object mentioned (since both the index checksum and +zlib were failing). + +Reading the zlib source code, I found that "incorrect data check" means +that the adler-32 checksum at the end of the zlib data did not match the +inflated data. So stepping the data through zlib would not help, as it +did not fail until the very end, when we realize the crc does not match. +The problematic bytes could be anywhere in the object data. + +The first thing I did was pull the broken data out of the packfile. I +needed to know how big the object was, which I found out with: + +------------ + $ git show-index <$idx | cut -d' ' -f1 | sort -n | grep -A1 51653873 + 51653873 + 51664736 +------------ + +Show-index gives us the list of objects and their offsets. We throw away +everything but the offsets, and then sort them so that our interesting +offset (which we got from the fsck output above) is followed immediately +by the offset of the next object. Now we know that the object data is +10863 bytes long, and we can grab it with: + +------------ + dd if=$pack of=object bs=1 skip=51653873 count=10863 +------------ + +I inspected a hexdump of the data, looking for any obvious bogosity +(e.g., a 4K run of zeroes would be a good sign of filesystem +corruption). But everything looked pretty reasonable. + +Note that the "object" file isn't fit for feeding straight to zlib; it +has the git packed object header, which is variable-length. We want to +strip that off so we can start playing with the zlib data directly. You +can either work your way through it manually (the format is described in +link:../technical/pack-format.html[Documentation/technical/pack-format.txt]), +or you can walk through it in a debugger. I did the latter, creating a +valid pack like: + +------------ + # pack magic and version + printf 'PACK\0\0\0\2' >tmp.pack + # pack has one object + printf '\0\0\0\1' >>tmp.pack + # now add our object data + cat object >>tmp.pack + # and then append the pack trailer + /path/to/git.git/test-sha1 -b <tmp.pack >trailer + cat trailer >>tmp.pack +------------ + +and then running "git index-pack tmp.pack" in the debugger (stop at +unpack_raw_entry). Doing this, I found that there were 3 bytes of header +(and the header itself had a sane type and size). So I stripped those +off with: + +------------ + dd if=object of=zlib bs=1 skip=3 +------------ + +I ran the result through zlib's inflate using a custom C program. And +while it did report the error, I did get the right number of output +bytes (i.e., it matched git's size header that we decoded above). But +feeding the result back to "git hash-object" didn't produce the same +sha1. So there were some wrong bytes, but I didn't know which. The file +happened to be C source code, so I hoped I could notice something +obviously wrong with it, but I didn't. I even got it to compile! + +I also tried comparing it to other versions of the same path in the +repository, hoping that there would be some part of the diff that didn't +make sense. Unfortunately, this happened to be the only revision of this +particular file in the repository, so I had nothing to compare against. + +So I took a different approach. Working under the guess that the +corruption was limited to a single byte, I wrote a program to munge each +byte individually, and try inflating the result. Since the object was +only 10K compressed, that worked out to about 2.5M attempts, which took +a few minutes. + +The program I used is here: + +---------------------------------------------- +#include <stdio.h> +#include <unistd.h> +#include <string.h> +#include <signal.h> +#include <zlib.h> + +static int try_zlib(unsigned char *buf, int len) +{ + /* make this absurdly large so we don't have to loop */ + static unsigned char out[1024*1024]; + z_stream z; + int ret; + + memset(&z, 0, sizeof(z)); + inflateInit(&z); + + z.next_in = buf; + z.avail_in = len; + z.next_out = out; + z.avail_out = sizeof(out); + + ret = inflate(&z, 0); + inflateEnd(&z); + return ret >= 0; +} + +/* eye candy */ +static int counter = 0; +static void progress(int sig) +{ + fprintf(stderr, "\r%d", counter); + alarm(1); +} + +int main(void) +{ + /* oversized so we can read the whole buffer in */ + unsigned char buf[1024*1024]; + int len; + unsigned i, j; + + signal(SIGALRM, progress); + alarm(1); + + len = read(0, buf, sizeof(buf)); + for (i = 0; i < len; i++) { + unsigned char c = buf[i]; + for (j = 0; j <= 0xff; j++) { + buf[i] = j; + + counter++; + if (try_zlib(buf, len)) + printf("i=%d, j=%x\n", i, j); + } + buf[i] = c; + } + + alarm(0); + fprintf(stderr, "\n"); + return 0; +} +---------------------------------------------- + +I compiled and ran with: + +------- + gcc -Wall -Werror -O3 munge.c -o munge -lz + ./munge <zlib +------- + + +There were a few false positives early on (if you write "no data" in the +zlib header, zlib thinks it's just fine :) ). But I got a hit about +halfway through: + +------- + i=5642, j=c7 +------- + +I let it run to completion, and got a few more hits at the end (where it +was munging the crc to match our broken data). So there was a good +chance this middle hit was the source of the problem. + +I confirmed by tweaking the byte in a hex editor, zlib inflating the +result (no errors!), and then piping the output into "git hash-object", +which reported the sha1 of the broken object. Success! + +I fixed the packfile itself with: + +------- + chmod +w $pack + printf '\xc7' | dd of=$pack bs=1 seek=51659518 conv=notrunc + chmod -w $pack +------- + +The `\xc7` comes from the replacement byte our "munge" program found. +The offset 51659518 is derived by taking the original object offset +(51653873), adding the replacement offset found by "munge" (5642), and +then adding back in the 3 bytes of git header we stripped. + +After that, "git fsck" ran clean. + +As for the corruption itself, I was lucky that it was indeed a single +byte. In fact, it turned out to be a single bit. The byte 0xc7 was +corrupted to 0xc5. So presumably it was caused by faulty hardware, or a +cosmic ray. + +And the aborted attempt to look at the inflated output to see what was +wrong? I could have looked forever and never found it. Here's the diff +between what the corrupted data inflates to, versus the real data: + +-------------- + - cp = strtok (arg, "+"); + + cp = strtok (arg, "."); +-------------- + +It tweaked one byte and still ended up as valid, readable C that just +happened to do something totally different! One takeaway is that on a +less unlucky day, looking at the zlib output might have actually been +helpful, as most random changes would actually break the C code. + +But more importantly, git's hashing and checksumming noticed a problem +that easily could have gone undetected in another system. The result +still compiled, but would have caused an interesting bug (that would +have been blamed on some random commit). diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt index 6fd711996..acf3e477e 100644 --- a/Documentation/howto/revert-a-faulty-merge.txt +++ b/Documentation/howto/revert-a-faulty-merge.txt @@ -7,6 +7,10 @@ Abstract: Sometimes a branch that was already merged to the mainline after the offending branch is fixed. Message-ID: <7vocz8a6zk.fsf@gitster.siamese.dyndns.org> References: <alpine.LFD.2.00.0812181949450.14014@localhost.localdomain> +Content-type: text/asciidoc + +How to revert a faulty merge +============================ Alan <alan@clueserver.org> said: @@ -33,7 +37,7 @@ where A and B are on the side development that was not so good, M is the merge that brings these premature changes into the mainline, x are changes unrelated to what the side branch did and already made on the mainline, and W is the "revert of the merge M" (doesn't W look M upside down?). -IOW, "diff W^..W" is similar to "diff -R M^..M". +IOW, `"diff W^..W"` is similar to `"diff -R M^..M"`. Such a "revert" of a merge can be made with: @@ -117,9 +121,9 @@ If you reverted the revert in such a case as in the previous example: ---A---B A'--B'--C' where Y is the revert of W, A' and B' are rerolled A and B, and there may -also be a further fix-up C' on the side branch. "diff Y^..Y" is similar -to "diff -R W^..W" (which in turn means it is similar to "diff M^..M"), -and "diff A'^..C'" by definition would be similar but different from that, +also be a further fix-up C' on the side branch. `"diff Y^..Y"` is similar +to `"diff -R W^..W"` (which in turn means it is similar to `"diff M^..M"`), +and `"diff A'^..C'"` by definition would be similar but different from that, because it is a rerolled series of the earlier change. There will be a lot of overlapping changes that result in conflicts. So do not do "revert of revert" blindly without thinking.. @@ -160,7 +164,7 @@ merged. So it's debugging hell, because now you don't have lots of small changes that you can try to pinpoint which _part_ of it changes. But does it all work? Sure it does. You can revert a merge, and from a -purely technical angle, git did it very naturally and had no real +purely technical angle, Git did it very naturally and had no real troubles. It just considered it a change from "state before merge" to "state after merge", and that was it. Nothing complicated, nothing odd, nothing really dangerous. Git will do it without even thinking about it. diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt index 093c65604..85f69dbac 100644 --- a/Documentation/howto/revert-branch-rebase.txt +++ b/Documentation/howto/revert-branch-rebase.txt @@ -8,14 +8,14 @@ Date: Mon, 29 Aug 2005 21:39:02 -0700 Content-type: text/asciidoc Message-ID: <7voe7g3uop.fsf@assigned-by-dhcp.cox.net> -Reverting an existing commit -============================ +How to revert an existing commit +================================ One of the changes I pulled into the 'master' branch turns out to -break building GIT with GCC 2.95. While they were well intentioned +break building Git with GCC 2.95. While they were well-intentioned portability fixes, keeping things working with gcc-2.95 was also important. Here is what I did to revert the change in the 'master' -branch and to adjust the 'pu' branch, using core GIT tools and +branch and to adjust the 'pu' branch, using core Git tools and barebone Porcelain. First, prepare a throw-away branch in case I screw things up. @@ -154,7 +154,7 @@ $ git pull . master Packing 0 objects Unpacking 0 objects -* committish: e3a693c... refs/heads/master from . +* commit-ish: e3a693c... refs/heads/master from . Trying to merge e3a693c... into 8c1f5f0... using 10d781b... Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f cache.h | 8 ++++---- diff --git a/Documentation/howto/separating-topic-branches.txt b/Documentation/howto/separating-topic-branches.txt index 6d3eb8ed0..bd1027433 100644 --- a/Documentation/howto/separating-topic-branches.txt +++ b/Documentation/howto/separating-topic-branches.txt @@ -1,6 +1,10 @@ From: Junio C Hamano <gitster@pobox.com> Subject: Separating topic branches Abstract: In this article, JC describes how to separate topic branches. +Content-type: text/asciidoc + +How to separate topic branches +============================== This text was originally a footnote to a discussion about the behaviour of the git diff commands. diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt index 622ee5c8d..6de4f3c48 100644 --- a/Documentation/howto/setup-git-server-over-http.txt +++ b/Documentation/howto/setup-git-server-over-http.txt @@ -1,6 +1,14 @@ From: Rutger Nijlunsing <rutger@nospam.com> -Subject: Setting up a git repository which can be pushed into and pulled from over HTTP(S). +Subject: Setting up a Git repository which can be pushed into and pulled from over HTTP(S). Date: Thu, 10 Aug 2006 22:00:26 +0200 +Content-type: text/asciidoc + +How to setup Git server over http +================================= + +NOTE: This document is from 2006. A lot has happened since then, and this +document is now relevant mainly if your web host is not CGI capable. +Almost everyone else should instead look at linkgit:git-http-backend[1]. Since Apache is one of those packages people like to compile themselves while others prefer the bureaucrat's dream Debian, it is @@ -40,20 +48,20 @@ What's needed: - have permissions to chown a directory -- have git installed on the client, and +- have Git installed on the client, and -- either have git installed on the server or have a webdav client on +- either have Git installed on the server or have a webdav client on the client. In effect, this means you're going to be root, or that you're using a preconfigured WebDAV server. -Step 1: setup a bare GIT repository +Step 1: setup a bare Git repository ----------------------------------- -At the time of writing, git-http-push cannot remotely create a GIT -repository. So we have to do that at the server side with git. Another +At the time of writing, git-http-push cannot remotely create a Git +repository. So we have to do that at the server side with Git. Another option is to generate an empty bare repository at the client and copy it to the server with a WebDAV client (which is the only option if Git is not installed on the server). @@ -77,8 +85,8 @@ Initialize a bare repository $ git --bare init -Change the ownership to your web-server's credentials. Use "grep ^User -httpd.conf" and "grep ^Group httpd.conf" to find out: +Change the ownership to your web-server's credentials. Use `"grep ^User +httpd.conf"` and `"grep ^Group httpd.conf"` to find out: $ chown -R www.www . @@ -185,7 +193,7 @@ http://<servername>/my-new-repo.git [x] Open as webfolder -> login . Step 3: setup the client ------------------------ -Make sure that you have HTTP support, i.e. your git was built with +Make sure that you have HTTP support, i.e. your Git was built with libcurl (version more recent than 7.10). The command 'git http-push' with no argument should display a usage message. @@ -264,7 +272,7 @@ Reading /usr/local/apache2/logs/error_log is often helpful. On Debian: Read /var/log/apache2/error.log instead. -If you access HTTPS locations, git may fail verifying the SSL +If you access HTTPS locations, Git may fail verifying the SSL certificate (this is return code 60). Setting http.sslVerify=false can help diagnosing the problem, but removes security checks. diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt index b7f8d416d..a5193b1e5 100644 --- a/Documentation/howto/update-hook-example.txt +++ b/Documentation/howto/update-hook-example.txt @@ -5,6 +5,10 @@ Message-ID: <7vfypumlu3.fsf@assigned-by-dhcp.cox.net> Abstract: An example hooks/update script is presented to implement repository maintenance policies, such as who can push into which branch and who can make a tag. +Content-type: text/asciidoc + +How to use the update hook +========================== When your developer runs git-push into the repository, git-receive-pack is run (either locally or over ssh) as that @@ -32,8 +36,7 @@ like this as your hooks/update script. [jc: editorial note. This is a much improved version by Carl since I posted the original outline] --- >8 -- beginning of script -- >8 -- - +---------------------------------------------------- #!/bin/bash umask 002 @@ -111,12 +114,12 @@ then info "Found matching head pattern: '$head_pattern'" for user_pattern in $user_patterns; do - info "Checking user: '$username' against pattern: '$user_pattern'" - matchlen=$(expr "$username" : "$user_pattern") - if test "$matchlen" = "${#username}" - then - grant "Allowing user: '$username' with pattern: '$user_pattern'" - fi + info "Checking user: '$username' against pattern: '$user_pattern'" + matchlen=$(expr "$username" : "$user_pattern") + if test "$matchlen" = "${#username}" + then + grant "Allowing user: '$username' with pattern: '$user_pattern'" + fi done deny "The user is not in the access list for this branch" done @@ -149,13 +152,13 @@ then info "Found matching head pattern: '$head_pattern'" for group_pattern in $group_patterns; do - for groupname in $groups; do - info "Checking group: '$groupname' against pattern: '$group_pattern'" - matchlen=$(expr "$groupname" : "$group_pattern") - if test "$matchlen" = "${#groupname}" - then - grant "Allowing group: '$groupname' with pattern: '$group_pattern'" - fi + for groupname in $groups; do + info "Checking group: '$groupname' against pattern: '$group_pattern'" + matchlen=$(expr "$groupname" : "$group_pattern") + if test "$matchlen" = "${#groupname}" + then + grant "Allowing group: '$groupname' with pattern: '$group_pattern'" + fi done done deny "None of the user's groups are in the access list for this branch" @@ -169,24 +172,21 @@ then fi deny >/dev/null "There are no more rules to check. Denying access" - --- >8 -- end of script -- >8 -- +---------------------------------------------------- This uses two files, $GIT_DIR/info/allowed-users and allowed-groups, to describe which heads can be pushed into by whom. The format of each file would look like this: - refs/heads/master junio - +refs/heads/pu junio - refs/heads/cogito$ pasky - refs/heads/bw/.* linus - refs/heads/tmp/.* .* - refs/tags/v[0-9].* junio + refs/heads/master junio + +refs/heads/pu junio + refs/heads/cogito$ pasky + refs/heads/bw/.* linus + refs/heads/tmp/.* .* + refs/tags/v[0-9].* junio With this, Linus can push or create "bw/penguin" or "bw/zebra" or "bw/panda" branches, Pasky can do only "cogito", and JC can do master and pu branches and make versioned tags. And anybody can do tmp/blah branches. The '+' sign at the pu record means that JC can make non-fast-forward pushes on it. - ------------- diff --git a/Documentation/howto/use-git-daemon.txt b/Documentation/howto/use-git-daemon.txt index 4e2f75cb6..7af2e52cf 100644 --- a/Documentation/howto/use-git-daemon.txt +++ b/Documentation/howto/use-git-daemon.txt @@ -1,7 +1,10 @@ +Content-type: text/asciidoc + How to use git-daemon +===================== Git can be run in inetd mode and in stand alone mode. But all you want is -let a coworker pull from you, and therefore need to set up a git server +let a coworker pull from you, and therefore need to set up a Git server real quick, right? Note that git-daemon is not really chatty at the moment, especially when diff --git a/Documentation/howto/using-merge-subtree.txt b/Documentation/howto/using-merge-subtree.txt index 293305612..1ae8d1214 100644 --- a/Documentation/howto/using-merge-subtree.txt +++ b/Documentation/howto/using-merge-subtree.txt @@ -25,7 +25,7 @@ What you want is the 'subtree' merge strategy, which helps you in such a situation. In this example, let's say you have the repository at `/path/to/B` (but -it can be an URL as well, if you want). You want to merge the 'master' +it can be a URL as well, if you want). You want to merge the 'master' branch of that repository to the `dir-B` subdirectory in your current branch. diff --git a/Documentation/howto/using-signed-tag-in-pull-request.txt b/Documentation/howto/using-signed-tag-in-pull-request.txt new file mode 100644 index 000000000..bbf040eda --- /dev/null +++ b/Documentation/howto/using-signed-tag-in-pull-request.txt @@ -0,0 +1,217 @@ +From: Junio C Hamano <gitster@pobox.com> +Date: Tue, 17 Jan 2011 13:00:00 -0800 +Subject: Using signed tag in pull requests +Abstract: Beginning v1.7.9, a contributor can push a signed tag to her + publishing repository and ask her integrator to pull it. This assures the + integrator that the pulled history is authentic and allows others to + later validate it. +Content-type: text/asciidoc + +How to use a signed tag in pull requests +======================================== + +A typical distributed workflow using Git is for a contributor to fork a +project, build on it, publish the result to her public repository, and ask +the "upstream" person (often the owner of the project where she forked +from) to pull from her public repository. Requesting such a "pull" is made +easy by the `git request-pull` command. + +Earlier, a typical pull request may have started like this: + +------------ + The following changes since commit 406da78032179...: + + Froboz 3.2 (2011-09-30 14:20:57 -0700) + + are available in the Git repository at: + + example.com:/git/froboz.git for-xyzzy +------------ + +followed by a shortlog of the changes and a diffstat. + +The request was for a branch name (e.g. `for-xyzzy`) in the public +repository of the contributor, and even though it stated where the +contributor forked her work from, the message did not say anything about +the commit to expect at the tip of the for-xyzzy branch. If the site that +hosts the public repository of the contributor cannot be fully trusted, it +was unnecessarily hard to make sure what was pulled by the integrator was +genuinely what the contributor had produced for the project. Also there +was no easy way for third-party auditors to later verify the resulting +history. + +Starting from Git release v1.7.9, a contributor can add a signed tag to +the commit at the tip of the history and ask the integrator to pull that +signed tag. When the integrator runs `git pull`, the signed tag is +automatically verified to assure that the history is not tampered with. +In addition, the resulting merge commit records the content of the signed +tag, so that other people can verify that the branch merged by the +integrator was signed by the contributor, without fetching the signed tag +used to validate the pull request separately and keeping it in the refs +namespace. + +This document describes the workflow between the contributor and the +integrator, using Git v1.7.9 or later. + + +A contributor or a lieutenant +----------------------------- + +After preparing her work to be pulled, the contributor uses `git tag -s` +to create a signed tag: + +------------ + $ git checkout work + $ ... "git pull" from sublieutenants, "git commit" your own work ... + $ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work +------------ + +Note that this example uses the `-m` option to create a signed tag with +just a one-liner message, but this is for illustration purposes only. It +is advisable to compose a well-written explanation of what the topic does +to justify why it is worthwhile for the integrator to pull it, as this +message will eventually become part of the final history after the +integrator responds to the pull request (as we will see later). + +Then she pushes the tag out to her public repository: + +------------ + $ git push example.com:/git/froboz.git/ +frotz-for-xyzzy +------------ + +There is no need to push the `work` branch or anything else. + +Note that the above command line used a plus sign at the beginning of +`+frotz-for-xyzzy` to allow forcing the update of a tag, as the same +contributor may want to reuse a signed tag with the same name after the +previous pull request has already been responded to. + +The contributor then prepares a message to request a "pull": + +------------ + $ git request-pull v3.2 example.com:/git/froboz.git/ frotz-for-xyzzy >msg.txt +------------ + +The arguments are: + +. the version of the integrator's commit the contributor based her work on; +. the URL of the repository, to which the contributor has pushed what she + wants to get pulled; and +. the name of the tag the contributor wants to get pulled (earlier, she could + write only a branch name here). + +The resulting msg.txt file begins like so: + +------------ + The following changes since commit 406da78032179...: + + Froboz 3.2 (2011-09-30 14:20:57 -0700) + + are available in the Git repository at: + + example.com:/git/froboz.git tags/frotz-for-xyzzy + + for you to fetch changes up to 703f05ad5835c...: + + Add tests and documentation for frotz (2011-12-02 10:02:52 -0800) + + ----------------------------------------------- + Completed frotz feature + ----------------------------------------------- +------------ + +followed by a shortlog of the changes and a diffstat. Comparing this with +the earlier illustration of the output from the traditional `git request-pull` +command, the reader should notice that: + +. The tip commit to expect is shown to the integrator; and +. The signed tag message is shown prominently between the dashed lines + before the shortlog. + +The latter is why the contributor would want to justify why pulling her +work is worthwhile when creating the signed tag. The contributor then +opens her favorite MUA, reads msg.txt, edits and sends it to her upstream +integrator. + + +Integrator +---------- + +After receiving such a pull request message, the integrator fetches and +integrates the tag named in the request, with: + +------------ + $ git pull example.com:/git/froboz.git/ tags/frotz-for-xyzzy +------------ + +This operation will always open an editor to allow the integrator to fine +tune the commit log message when merging a signed tag. Also, pulling a +signed tag will always create a merge commit even when the integrator does +not have any new commit since the contributor's work forked (i.e. 'fast +forward'), so that the integrator can properly explain what the merge is +about and why it was made. + +In the editor, the integrator will see something like this: + +------------ + Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/ + + Completed frotz feature + # gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB + # gpg: Good signature from "Con Tributor <nitfol@example.com>" +------------ + +Notice that the message recorded in the signed tag "Completed frotz +feature" appears here, and again that is why it is important for the +contributor to explain her work well when creating the signed tag. + +As usual, the lines commented with `#` are stripped out. The resulting +commit records the signed tag used for this validation in a hidden field +so that it can later be used by others to audit the history. There is no +need for the integrator to keep a separate copy of the tag in his +repository (i.e. `git tag -l` won't list the `frotz-for-xyzzy` tag in the +above example), and there is no need to publish the tag to his public +repository, either. + +After the integrator responds to the pull request and her work becomes +part of the permanent history, the contributor can remove the tag from +her public repository, if she chooses, in order to keep the tag namespace +of her public repository clean, with: + +------------ + $ git push example.com:/git/froboz.git :frotz-for-xyzzy +------------ + + +Auditors +-------- + +The `--show-signature` option can be given to `git log` or `git show` and +shows the verification status of the embedded signed tag in merge commits +created when the integrator responded to a pull request of a signed tag. + +A typical output from `git show --show-signature` may look like this: + +------------ + $ git show --show-signature + commit 02306ef6a3498a39118aef9df7975bdb50091585 + merged tag 'frotz-for-xyzzy' + gpg: Signature made Fri 06 Jan 2012 12:41:49 PM PST using RSA key ID 96AFE6CB + gpg: Good signature from "Con Tributor <nitfol@example.com>" + Merge: 406da78 703f05a + Author: Inte Grator <xyzzy@example.com> + Date: Tue Jan 17 13:49:41 2012 -0800 + + Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/ + + Completed frotz feature + + * tag 'frotz-for-xyzzy' (100 commits) + Add tests and documentation for frotz + ... +------------ + +There is no need for the auditor to explicitly fetch the contributor's +signature, or to even be aware of what tag(s) the contributor and integrator +used to communicate the signature. All the required information is recorded +as part of the merge commit. diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt index 625d3154e..e9a1d5d25 100644 --- a/Documentation/i18n.txt +++ b/Documentation/i18n.txt @@ -1,9 +1,9 @@ -At the core level, git is character encoding agnostic. +At the core level, Git is character encoding agnostic. - The pathnames recorded in the index and in the tree objects are treated as uninterpreted sequences of non-NUL bytes. What readdir(2) returns are what are recorded and compared - with the data git keeps track of, which in turn are expected + with the data Git keeps track of, which in turn are expected to be what lstat(2) and creat(2) accepts. There is no such thing as pathname encoding translation. @@ -15,9 +15,9 @@ At the core level, git is character encoding agnostic. bytes. Although we encourage that the commit log messages are encoded -in UTF-8, both the core and git Porcelain are designed not to +in UTF-8, both the core and Git Porcelain are designed not to force UTF-8 on projects. If all participants of a particular -project find it more convenient to use legacy encodings, git +project find it more convenient to use legacy encodings, Git does not forbid it. However, there are a few things to keep in mind. diff --git a/Documentation/install-doc-quick.sh b/Documentation/install-doc-quick.sh index 35f440876..327f69bcf 100755 --- a/Documentation/install-doc-quick.sh +++ b/Documentation/install-doc-quick.sh @@ -1,31 +1,39 @@ #!/bin/sh -# This requires a branch named in $head -# (usually 'man' or 'html', provided by the git.git repository) -set -e -head="$1" -mandir="$2" -SUBDIRECTORY_OK=t -USAGE='<refname> <target directory>' -. "$(git --exec-path)"/git-sh-setup -cd_to_toplevel +# This requires git-manpages and/or git-htmldocs repositories -test -z "$mandir" && usage -if ! git rev-parse --verify "$head^0" >/dev/null; then - echo >&2 "head: $head does not exist in the current repository" - usage +repository=${1?repository} +destdir=${2?destination} + +head=master GIT_DIR= +for d in "$repository/.git" "$repository" +do + if GIT_DIR="$d" git rev-parse refs/heads/master >/dev/null 2>&1 + then + GIT_DIR="$d" + export GIT_DIR + break + fi +done + +if test -z "$GIT_DIR" +then + echo >&2 "Neither $repository nor $repository/.git is a repository" + exit 1 fi -GIT_INDEX_FILE=`pwd`/.quick-doc.index -export GIT_INDEX_FILE +GIT_WORK_TREE=$(pwd) +GIT_INDEX_FILE=$(pwd)/.quick-doc.$$ +export GIT_INDEX_FILE GIT_WORK_TREE rm -f "$GIT_INDEX_FILE" trap 'rm -f "$GIT_INDEX_FILE"' 0 git read-tree $head -git checkout-index -a -f --prefix="$mandir"/ +git checkout-index -a -f --prefix="$destdir"/ -if test -n "$GZ"; then +if test -n "$GZ" +then git ls-tree -r --name-only $head | - xargs printf "$mandir/%s\n" | + xargs printf "$destdir/%s\n" | xargs gzip -f fi rm -f "$GIT_INDEX_FILE" diff --git a/Documentation/line-range-format.txt b/Documentation/line-range-format.txt new file mode 100644 index 000000000..d7f26039c --- /dev/null +++ b/Documentation/line-range-format.txt @@ -0,0 +1,29 @@ +<start> and <end> can take one of these forms: + +- number ++ +If <start> or <end> is a number, it specifies an +absolute line number (lines count from 1). ++ + +- /regex/ ++ +This form will use the first line matching the given +POSIX regex. If <start> is a regex, it will search from the end of +the previous `-L` range, if any, otherwise from the start of file. +If <start> is ``^/regex/'', it will search from the start of file. +If <end> is a regex, it will search +starting at the line given by <start>. ++ + +- +offset or -offset ++ +This is only valid for <end> and will specify a number +of lines before or after the line given by <start>. + ++ +If ``:<regex>'' is given in place of <start> and <end>, it denotes the range +from the first funcname line that matches <regex>, up to the next +funcname line. ``:<regex>'' searches from the end of the previous `-L` range, +if any, otherwise from the start of file. +``^:<regex>'' searches from the start of file. diff --git a/Documentation/mailmap.txt b/Documentation/mailmap.txt index 288f04e70..4a8c27652 100644 --- a/Documentation/mailmap.txt +++ b/Documentation/mailmap.txt @@ -1,5 +1,6 @@ If the file `.mailmap` exists at the toplevel of the repository, or at -the location pointed to by the mailmap.file configuration option, it +the location pointed to by the mailmap.file or mailmap.blob +configuration options, it is used to map author and committer names and email addresses to canonical real names and email addresses. @@ -46,7 +47,7 @@ Jane Doe <jane@desktop.(none)> Joe R. Developer <joe@example.com> ------------ -Note how there is no need for an entry for <jane@laptop.(none)>, because the +Note how there is no need for an entry for `<jane@laptop.(none)>`, because the real name of that author is already correct. Example 2: Your repository contains commits from the following diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt index 861bd6f55..d78d6d854 100644 --- a/Documentation/merge-config.txt +++ b/Documentation/merge-config.txt @@ -9,18 +9,18 @@ merge.conflictstyle:: merge.defaultToUpstream:: If merge is called without any commit argument, merge the upstream branches configured for the current branch by using their last - observed values stored in their remote tracking branches. + observed values stored in their remote-tracking branches. The values of the `branch.<current branch>.merge` that name the branches at the remote named by `branch.<current branch>.remote` are consulted, and then they are mapped via `remote.<remote>.fetch` - to their corresponding remote tracking branches, and the tips of + to their corresponding remote-tracking branches, and the tips of these tracking branches are merged. merge.ff:: - By default, git does not create an extra merge commit when merging + By default, Git does not create an extra merge commit when merging a commit that is a descendant of the current commit. Instead, the tip of the current branch is fast-forwarded. When set to `false`, - this variable tells git to create an extra merge commit in such + this variable tells Git to create an extra merge commit in such a case (equivalent to giving the `--no-ff` option from the command line). When set to `only`, only such fast-forward merges are allowed (equivalent to giving the `--ff-only` option from the @@ -38,10 +38,10 @@ merge.renameLimit:: diff.renameLimit. merge.renormalize:: - Tell git that canonical representation of files in the + Tell Git that canonical representation of files in the repository has changed over time (e.g. earlier commits record text files with CRLF line endings, but recent ones use LF line - endings). In such a repository, git can convert the data + endings). In such a repository, Git can convert the data recorded in commits to a canonical form before performing a merge to reduce unnecessary conflicts. For more information, see section "Merging branches with differing checkin/checkout @@ -52,12 +52,12 @@ merge.stat:: at the end of the merge. True by default. merge.tool:: - Controls which merge resolution program is used by - linkgit:git-mergetool[1]. Valid built-in values are: "araxis", - "bc3", "diffuse", "ecmerge", "emerge", "gvimdiff", "kdiff3", "meld", - "opendiff", "p4merge", "tkdiff", "tortoisemerge", "vimdiff" - and "xxdiff". Any other value is treated is custom merge tool - and there must be a corresponding mergetool.<tool>.cmd option. + Controls which merge tool is used by linkgit:git-mergetool[1]. + The list below shows the valid built-in values. + Any other value is treated as a custom merge tool and requires + that a corresponding mergetool.<tool>.cmd variable is defined. + +include::mergetools-merge.txt[] merge.verbosity:: Controls the amount of output shown by the recursive merge diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index b613d4ed0..e1343155f 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -7,14 +7,40 @@ With --no-commit perform the merge but pretend the merge failed and do not autocommit, to give the user a chance to inspect and further tweak the merge result before committing. +--edit:: +-e:: +--no-edit:: + Invoke an editor before committing successful mechanical merge to + further edit the auto-generated merge message, so that the user + can explain and justify the merge. The `--no-edit` option can be + used to accept the auto-generated message (this is generally + discouraged). +ifndef::git-pull[] +The `--edit` (or `-e`) option is still useful if you are +giving a draft message with the `-m` option from the command line +and want to edit it in the editor. +endif::git-pull[] ++ +Older scripts may depend on the historical behaviour of not allowing the +user to edit the merge log message. They will see an editor opened when +they run `git merge`. To make it easier to adjust such scripts to the +updated behaviour, the environment variable `GIT_MERGE_AUTOEDIT` can be +set to `no` at the beginning of them. + --ff:: + When the merge resolves as a fast-forward, only update the branch + pointer, without creating a merge commit. This is the default + behavior. + --no-ff:: - Do not generate a merge commit if the merge resolved as - a fast-forward, only update the branch pointer. This is - the default behavior of git-merge. -+ -With --no-ff Generate a merge commit even if the merge -resolved as a fast-forward. + Create a merge commit even when the merge resolves as a + fast-forward. This is the default behaviour when merging an + annotated (and possibly signed) tag. + +--ff-only:: + Refuse to merge and exit with a non-zero status unless the + current `HEAD` is already up-to-date or the merge can be + resolved as a fast-forward. --log[=<n>]:: --no-log:: @@ -49,11 +75,6 @@ merge. With --no-squash perform the merge and commit the result. This option can be used to override --squash. ---ff-only:: - Refuse to merge and exit with a non-zero status unless the - current `HEAD` is already up-to-date or the merge can be - resolved as a fast-forward. - -s <strategy>:: --strategy=<strategy>:: Use the given merge strategy; can be supplied more than @@ -67,6 +88,11 @@ option can be used to override --squash. Pass merge strategy specific option through to the merge strategy. +--verify-signatures:: +--no-verify-signatures:: + Verify that the commits being merged have good and trusted GPG signatures + and abort the merge in case they do not. + --summary:: --no-summary:: Synonyms to --stat and --no-stat; these are deprecated and will be diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index 595a3cf1a..fb6e593e7 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -32,13 +32,14 @@ ours;; This option forces conflicting hunks to be auto-resolved cleanly by favoring 'our' version. Changes from the other tree that do not conflict with our side are reflected to the merge result. + For a binary file, the entire contents are taken from our side. + This should not be confused with the 'ours' merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring 'our' history contains all that happened in it. theirs;; - This is opposite of 'ours'. + This is the opposite of 'ours'. patience;; With this option, 'merge-recursive' spends a little extra time @@ -47,6 +48,12 @@ patience;; this when the branches to be merged have diverged wildly. See also linkgit:git-diff[1] `--patience`. +diff-algorithm=[patience|minimal|histogram|myers];; + Tells 'merge-recursive' to use a different diff algorithm, which + can help avoid mismerges that occur due to unimportant matching + lines (such as braces from distinct functions). See also + linkgit:git-diff[1] `--diff-algorithm`. + ignore-space-change;; ignore-all-space;; ignore-space-at-eol;; @@ -106,3 +113,11 @@ subtree:: match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree. + +With the strategies that use 3-way merge (including the default, 'recursive'), +if a change is made on both branches, but later reverted on one of the +branches, that change will be present in the merged result; some people find +this behavior confusing. It occurs because only the heads and the merge base +are considered when performing a merge, not the individual commits. The merge +algorithm therefore considers the reverted change as no change at all, and +substitutes the changed version instead. diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index 561cc9f7d..1d174fd0b 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -75,7 +75,7 @@ This is designed to be as compact as possible. * 'raw' + The 'raw' format shows the entire commit exactly as -stored in the commit object. Notably, the SHA1s are +stored in the commit object. Notably, the SHA-1s are displayed in full, regardless of whether --abbrev or --no-abbrev are used, and 'parents' information show the true parent commits, without taking grafts nor history @@ -106,18 +106,22 @@ The placeholders are: - '%P': parent hashes - '%p': abbreviated parent hashes - '%an': author name -- '%aN': author name (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1]) +- '%aN': author name (respecting .mailmap, see linkgit:git-shortlog[1] + or linkgit:git-blame[1]) - '%ae': author email -- '%aE': author email (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1]) +- '%aE': author email (respecting .mailmap, see + linkgit:git-shortlog[1] or linkgit:git-blame[1]) - '%ad': author date (format respects --date= option) - '%aD': author date, RFC2822 style - '%ar': author date, relative - '%at': author date, UNIX timestamp - '%ai': author date, ISO 8601 format - '%cn': committer name -- '%cN': committer name (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1]) +- '%cN': committer name (respecting .mailmap, see + linkgit:git-shortlog[1] or linkgit:git-blame[1]) - '%ce': committer email -- '%cE': committer email (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1]) +- '%cE': committer email (respecting .mailmap, see + linkgit:git-shortlog[1] or linkgit:git-blame[1]) - '%cd': committer date - '%cD': committer date, RFC2822 style - '%cr': committer date, relative @@ -130,20 +134,50 @@ The placeholders are: - '%b': body - '%B': raw body (unwrapped subject and body) - '%N': commit notes -- '%gD': reflog selector, e.g., `refs/stash@\{1\}` -- '%gd': shortened reflog selector, e.g., `stash@\{1\}` +- '%GG': raw verification message from GPG for a signed commit +- '%G?': show "G" for a Good signature, "B" for a Bad signature, "U" for a good, + untrusted signature and "N" for no signature +- '%GS': show the name of the signer for a signed commit +- '%GK': show the key used to sign a signed commit +- '%gD': reflog selector, e.g., `refs/stash@{1}` +- '%gd': shortened reflog selector, e.g., `stash@{1}` +- '%gn': reflog identity name +- '%gN': reflog identity name (respecting .mailmap, see + linkgit:git-shortlog[1] or linkgit:git-blame[1]) +- '%ge': reflog identity email +- '%gE': reflog identity email (respecting .mailmap, see + linkgit:git-shortlog[1] or linkgit:git-blame[1]) - '%gs': reflog subject - '%Cred': switch color to red - '%Cgreen': switch color to green - '%Cblue': switch color to blue - '%Creset': reset color -- '%C(...)': color specification, as described in color.branch.* config option +- '%C(...)': color specification, as described in color.branch.* config option; + adding `auto,` at the beginning will emit color only when colors are + enabled for log output (by `color.diff`, `color.ui`, or `--color`, and + respecting the `auto` settings of the former if we are going to a + terminal). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring + on the next placeholders until the color is switched again. - '%m': left, right or boundary mark - '%n': newline - '%%': a raw '%' - '%x00': print a byte from a hex code - '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of linkgit:git-shortlog[1]. +- '%<(<N>[,trunc|ltrunc|mtrunc])': make the next placeholder take at + least N columns, padding spaces on the right if necessary. + Optionally truncate at the beginning (ltrunc), the middle (mtrunc) + or the end (trunc) if the output is longer than N columns. + Note that truncating only works correctly with N >= 2. +- '%<|(<N>)': make the next placeholder take at least until Nth + columns, padding spaces on the right if necessary +- '%>(<N>)', '%>|(<N>)': similar to '%<(<N>)', '%<|(<N>)' + respectively, but padding spaces on the left +- '%>>(<N>)', '%>>|(<N>)': similar to '%>(<N>)', '%>|(<N>)' + respectively, except that if the next placeholder takes more spaces + than given and there are spaces on its left, use those spaces +- '%><(<N>)', '%><|(<N>)': similar to '% <(<N>)', '%<|(<N>)' + respectively, but padding both sides (i.e. the text is centered) NOTE: Some placeholders may depend on other options given to the revision traversal engine. For example, the `%g*` reflog options will @@ -151,7 +185,7 @@ insert an empty string unless we are traversing reflog entries (e.g., by `git log -g`). The `%d` placeholder will use the "short" decoration format if `--decorate` was not already provided on the command line. -If you add a `{plus}` (plus sign) after '%' of a placeholder, a line-feed +If you add a `+` (plus sign) after '%' of a placeholder, a line-feed is inserted immediately before the expansion if and only if the placeholder expands to a non-empty string. diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt index 2a3dc8664..eea0e306a 100644 --- a/Documentation/pretty-options.txt +++ b/Documentation/pretty-options.txt @@ -28,7 +28,7 @@ people using 80-column terminals. This is a shorthand for "--pretty=oneline --abbrev-commit" used together. ---encoding[=<encoding>]:: +--encoding=<encoding>:: The commit objects record the encoding used for the log message in their encoding header; this option can be used to tell the command to re-code the commit log message in the encoding @@ -66,3 +66,7 @@ being displayed. Examples: "--notes=foo" will show only notes from --[no-]standard-notes:: These options are deprecated. Use the above --notes/--no-notes options instead. + +--show-signature:: + Check the validity of a signed commit object by passing the signature + to `gpg --verify` and show the output. diff --git a/Documentation/pt_BR/gittutorial.txt b/Documentation/pt_BR/gittutorial.txt deleted file mode 100644 index beba06525..000000000 --- a/Documentation/pt_BR/gittutorial.txt +++ /dev/null @@ -1,675 +0,0 @@ -gittutorial(7) -============== - -NOME ----- -gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova) - -SINOPSE --------- -git * - -DESCRIÇÃO ------------ - -Este tutorial explica como importar um novo projeto para o git, -adicionar mudanças a ele, e compartilhar mudanças com outros -desenvolvedores. - -Se, ao invés disso, você está interessado primariamente em usar git para -obter um projeto, por exemplo, para testar a última versão, você pode -preferir começar com os primeiros dois capÃtulos de -link:user-manual.html[O Manual do Usuário Git]. - -Primeiro, note que você pode obter documentação para um comando como -`git log --graph` com: - ------------------------------------------------- -$ man git-log ------------------------------------------------- - -ou: - ------------------------------------------------- -$ git help log ------------------------------------------------- - -Com a última forma, você pode usar o visualizador de manual de sua -escolha; veja linkgit:git-help[1] para maior informação. - -É uma boa idéia informar ao git seu nome e endereço público de email -antes de fazer qualquer operação. A maneira mais fácil de fazê-lo é: - ------------------------------------------------- -$ git config --global user.name "Seu Nome Vem Aqui" -$ git config --global user.email voce@seudominio.exemplo.com ------------------------------------------------- - - -Importando um novo projeto ------------------------ - -Assuma que você tem um tarball project.tar.gz com seu trabalho inicial. -Você pode colocá-lo sob controle de revisão git da seguinte forma: - ------------------------------------------------- -$ tar xzf project.tar.gz -$ cd project -$ git init ------------------------------------------------- - -Git irá responder - ------------------------------------------------- -Initialized empty Git repository in .git/ ------------------------------------------------- - -Agora que você iniciou seu diretório de trabalho, você deve ter notado que um -novo diretório foi criado com o nome de ".git". - -A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os -arquivos sob o diretório atual (note o '.'), com 'git-add': - ------------------------------------------------- -$ git add . ------------------------------------------------- - -Este instantâneo está agora armazenado em uma área temporária que o git -chama de "index" ou Ãndice. Você pode armazenar permanentemente o -conteúdo do Ãndice no repositório com 'git-commit': - ------------------------------------------------- -$ git commit ------------------------------------------------- - -Isto vai te pedir por uma mensagem de commit. Você agora gravou sua -primeira versão de seu projeto no git. - -Fazendo mudanças --------------- - -Modifique alguns arquivos, e, então, adicione seu conteúdo atualizado ao -Ãndice: - ------------------------------------------------- -$ git add file1 file2 file3 ------------------------------------------------- - -Você está agora pronto para fazer o commit. Você pode ver o que está -para ser gravado usando 'git-diff' com a opção --cached: - ------------------------------------------------- -$ git diff --cached ------------------------------------------------- - -(Sem --cached, o comando 'git-diff' irá te mostrar quaisquer mudanças -que você tenha feito mas ainda não adicionou ao Ãndice.) Você também -pode obter um breve sumário da situação com 'git-status': - ------------------------------------------------- -$ git status -# On branch master -# Changes to be committed: -# (use "git reset HEAD <file>..." to unstage) -# -# modified: file1 -# modified: file2 -# modified: file3 -# ------------------------------------------------- - -Se você precisar fazer qualquer outro ajuste, faça-o agora, e, então, -adicione qualquer conteúdo modificado ao Ãndice. Finalmente, grave suas -mudanças com: - ------------------------------------------------- -$ git commit ------------------------------------------------- - -Ao executar esse comando, ele irá te pedir uma mensagem descrevendo a mudança, -e, então, irá gravar a nova versão do projeto. - -Alternativamente, ao invés de executar 'git-add' antes, você pode usar - ------------------------------------------------- -$ git commit -a ------------------------------------------------- - -o que irá automaticamente notar quaisquer arquivos modificados (mas não -novos), adicioná-los ao Ãndices, e gravar, tudo em um único passo. - -Uma nota em mensagens de commit: Apesar de não ser exigido, é uma boa -idéia começar a mensagem com uma simples e curta (menos de 50 -caracteres) linha sumarizando a mudança, seguida de uma linha em branco -e, então, uma descrição mais detalhada. Ferramentas que transformam -commits em email, por exemplo, usam a primeira linha no campo de -cabeçalho "Subject:" e o resto no corpo. - -Git rastreia conteúdo, não arquivos ----------------------------- - -Muitos sistemas de controle de revisão provêem um comando `add` que diz -ao sistema para começar a rastrear mudanças em um novo arquivo. O -comando `add` do git faz algo mais simples e mais poderoso: 'git-add' é -usado tanto para arquivos novos e arquivos recentemente modificados, e -em ambos os casos, ele tira o instantâneo dos arquivos dados e armazena -o conteúdo no Ãndice, pronto para inclusão do próximo commit. - -Visualizando a história do projeto ------------------------ - -Em qualquer ponto você pode visualizar a história das suas mudanças -usando - ------------------------------------------------- -$ git log ------------------------------------------------- - -Se você também quiser ver a diferença completa a cada passo, use - ------------------------------------------------- -$ git log -p ------------------------------------------------- - -Geralmente, uma visão geral da mudança é útil para ter a sensação de -cada passo - ------------------------------------------------- -$ git log --stat --summary ------------------------------------------------- - -Gerenciando "branches"/ramos ------------------ - -Um simples repositório git pode manter múltiplos ramos de -desenvolvimento. Para criar um novo ramo chamado "experimental", use - ------------------------------------------------- -$ git branch experimental ------------------------------------------------- - -Se você executar agora - ------------------------------------------------- -$ git branch ------------------------------------------------- - -você vai obter uma lista de todos os ramos existentes: - ------------------------------------------------- - experimental -* master ------------------------------------------------- - -O ramo "experimental" é o que você acaba de criar, e o ramo "master" é o -ramo padrão que foi criado pra você automaticamente. O asterisco marca -o ramo em que você está atualmente; digite - ------------------------------------------------- -$ git checkout experimental ------------------------------------------------- - -para mudar para o ramo experimental. Agora edite um arquivo, grave a -mudança, e mude de volta para o ramo master: - ------------------------------------------------- -(edita arquivo) -$ git commit -a -$ git checkout master ------------------------------------------------- - -Verifique que a mudança que você fez não está mais visÃvel, já que ela -foi feita no ramo experimental e você está de volta ao ramo master. - -Você pode fazer uma mudança diferente no ramo master: - ------------------------------------------------- -(edit file) -$ git commit -a ------------------------------------------------- - -neste ponto, os dois ramos divergiram, com diferentes mudanças feitas em -cada um. Para unificar as mudanças feitas no experimental para o -master, execute - ------------------------------------------------- -$ git merge experimental ------------------------------------------------- - -Se as mudanças não conflitarem, estará pronto. Se existirem conflitos, -marcadores serão deixados nos arquivos problemáticos exibindo o -conflito; - ------------------------------------------------- -$ git diff ------------------------------------------------- - -vai exibir isto. Após você editar os arquivos para resolver os -conflitos, - ------------------------------------------------- -$ git commit -a ------------------------------------------------- - -irá gravar o resultado da unificação. Finalmente, - ------------------------------------------------- -$ gitk ------------------------------------------------- - -vai mostrar uma bela representação gráfica da história resultante. - -Neste ponto você pode remover seu ramo experimental com - ------------------------------------------------- -$ git branch -d experimental ------------------------------------------------- - -Este comando garante que as mudanças no ramo experimental já estão no -ramo atual. - -Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode -sempre remover o ramo com - -------------------------------------- -$ git branch -D ideia-louca -------------------------------------- - -Ramos são baratos e fáceis, então isto é uma boa maneira de experimentar -alguma coisa. - -Usando git para colaboração ---------------------------- - -Suponha que Alice começou um novo projeto com um repositório git em -/home/alice/project, e que Bob, que tem um diretório home na mesma -máquina, quer contribuir. - -Bob começa com: - ------------------------------------------------- -bob$ git clone /home/alice/project myrepo ------------------------------------------------- - -Isso cria um novo diretório "myrepo" contendo um clone do repositório de -Alice. O clone está no mesmo pé que o projeto original, possuindo sua -própria cópia da história do projeto original. - -Bob então faz algumas mudanças e as grava: - ------------------------------------------------- -(editar arquivos) -bob$ git commit -a -(repetir conforme necessário) ------------------------------------------------- - -Quanto está pronto, ele diz a Alice para puxar as mudanças do -repositório em /home/bob/myrepo. Ela o faz com: - ------------------------------------------------- -alice$ cd /home/alice/project -alice$ git pull /home/bob/myrepo master ------------------------------------------------- - -Isto unifica as mudanças do ramo "master" do Bob ao ramo atual de Alice. -Se Alice fez suas próprias mudanças no intervalo, ela, então, pode -precisar corrigir manualmente quaisquer conflitos. (Note que o argumento -"master" no comando acima é, de fato, desnecessário, já que é o padrão.) - -O comando "pull" executa, então, duas operações: ele obtém mudanças de -um ramo remoto, e, então, as unifica no ramo atual. - -Note que, em geral, Alice gostaria que suas mudanças locais fossem -gravadas antes de iniciar este "pull". Se o trabalho de Bob conflita -com o que Alice fez desde que suas histórias se ramificaram, Alice irá -usar seu diretório de trabalho e o Ãndice para resolver conflitos, e -mudanças locais existentes irão interferir com o processo de resolução -de conflitos (git ainda irá realizar a obtenção mas irá se recusar a -unificar --- Alice terá que se livrar de suas mudanças locais de alguma -forma e puxar de novo quando isso acontecer). - -Alice pode espiar o que Bob fez sem unificar primeiro, usando o comando -"fetch"; isto permite Alice inspecionar o que Bob fez, usando um sÃmbolo -especial "FETCH_HEAD", com o fim de determinar se ele tem alguma coisa -que vale puxar, assim: - ------------------------------------------------- -alice$ git fetch /home/bob/myrepo master -alice$ git log -p HEAD..FETCH_HEAD ------------------------------------------------- - -Esta operação é segura mesmo se Alice tem mudanças locais não gravadas. -A notação de intervalo "HEAD..FETCH_HEAD" significa mostrar tudo que é -alcançável de FETCH_HEAD mas exclua tudo o que é alcançável de HEAD. -Alice já sabe tudo que leva a seu estado atual (HEAD), e revisa o que Bob -tem em seu estado (FETCH_HEAD) que ela ainda não viu com esse comando. - -Se Alice quer visualizar o que Bob fez desde que suas histórias se -ramificaram, ela pode disparar o seguinte comando: - ------------------------------------------------- -$ gitk HEAD..FETCH_HEAD ------------------------------------------------- - -Isto usa a mesma notação de intervalo que vimos antes com 'git log'. - -Alice pode querer ver o que ambos fizeram desde que ramificaram. Ela -pode usar a forma com três pontos ao invés da forma com dois pontos: - ------------------------------------------------- -$ gitk HEAD...FETCH_HEAD ------------------------------------------------- - -Isto significa "mostre tudo que é alcançável de qualquer um deles, mas -exclua tudo que é alcançável a partir de ambos". - -Por favor, note que essas notações de intervalo podem ser usadas tanto -com gitk quanto com "git log". - -Após inspecionar o que Bob fez, se não há nada urgente, Alice pode -decidir continuar trabalhando sem puxar de Bob. Se a história de Bob -tem alguma coisa que Alice precisa imediatamente, Alice pode optar por -separar seu trabalho em progresso primeiro, fazer um "pull", e, então, -finalmente, retomar seu trabalho em progresso em cima da história -resultante. - -Quando você está trabalhando em um pequeno grupo unido, não é incomum -interagir com o mesmo repositório várias e várias vezes. Definindo um -repositório remoto antes de tudo, você pode fazê-lo mais facilmente: - ------------------------------------------------- -alice$ git remote add bob /home/bob/myrepo ------------------------------------------------- - -Com isso, Alice pode executar a primeira parte da operação "pull" usando -o comando 'git-fetch' sem unificar suas mudanças com seu próprio ramo, -usando: - -------------------------------------- -alice$ git fetch bob -------------------------------------- - -Diferente da forma longa, quando Alice obteve de Bob usando um -repositório remoto antes definido com 'git-remote', o que foi obtido é -armazenado em um ramo remoto, neste caso `bob/master`. Então, após isso: - -------------------------------------- -alice$ git log -p master..bob/master -------------------------------------- - -mostra uma lista de todas as mudanças que Bob fez desde que ramificou do -ramo master de Alice. - -Após examinar essas mudanças, Alice pode unificá-las em seu ramo master: - -------------------------------------- -alice$ git merge bob/master -------------------------------------- - -Esse `merge` pode também ser feito puxando de seu próprio ramo remoto, -assim: - -------------------------------------- -alice$ git pull . remotes/bob/master -------------------------------------- - -Note que 'git pull' sempre unifica ao ramo atual, independente do que -mais foi passado na linha de comando. - -Depois, Bob pode atualizar seu repositório com as últimas mudanças de -Alice, usando - -------------------------------------- -bob$ git pull -------------------------------------- - -Note que ele não precisa dar o caminho do repositório de Alice; quando -Bob clonou seu repositório, o git armazenou a localização de seu -repositório na configuração do mesmo, e essa localização é usada -para puxar: - -------------------------------------- -bob$ git config --get remote.origin.url -/home/alice/project -------------------------------------- - -(A configuração completa criada por 'git-clone' é visÃvel usando `git -config -l`, e a página de manual linkgit:git-config[1] explica o -significado de cada opção.) - -Git também mantém uma cópia limpa do ramo master de Alice sob o nome -"origin/master": - -------------------------------------- -bob$ git branch -r - origin/master -------------------------------------- - -Se Bob decidir depois em trabalhar em um host diferente, ele ainda pode -executar clones e puxar usando o protocolo ssh: - -------------------------------------- -bob$ git clone alice.org:/home/alice/project myrepo -------------------------------------- - -Alternativamente, o git tem um protocolo nativo, ou pode usar rsync ou -http; veja linkgit:git-pull[1] para detalhes. - -Git pode também ser usado em um modo parecido com CVS, com um -repositório central para o qual vários usuários empurram modificações; -veja linkgit:git-push[1] e linkgit:gitcvs-migration[7]. - -Explorando história ------------------ - -A história no git é representada como uma série de commits -interrelacionados. Nós já vimos que o comando 'git-log' pode listar -esses commits. Note que a primeira linha de cada entrada no log também -dá o nome para o commit: - -------------------------------------- -$ git log -commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 -Author: Junio C Hamano <junkio@cox.net> -Date: Tue May 16 17:18:22 2006 -0700 - - merge-base: Clarify the comments on post processing. -------------------------------------- - -Nós podemos dar este nome ao 'git-show' para ver os detalhes sobre este -commit. - -------------------------------------- -$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 -------------------------------------- - -Mas há outras formas de se referir aos commits. Você pode usar qualquer -parte inicial do nome que seja longo o bastante para identificar -unicamente o commit: - -------------------------------------- -$ git show c82a22c39c # os primeiros caracteres do nome são o bastante - # usualmente -$ git show HEAD # a ponta do ramo atual -$ git show experimental # a ponta do ramo "experimental" -------------------------------------- - -Todo commit normalmente tem um commit "pai" que aponta para o estado -anterior do projeto: - -------------------------------------- -$ git show HEAD^ # para ver o pai de HEAD -$ git show HEAD^^ # para ver o avô de HEAD -$ git show HEAD~4 # para ver o trisavô de HEAD -------------------------------------- - -Note que commits de unificação podem ter mais de um pai: - -------------------------------------- -$ git show HEAD^1 # mostra o primeiro pai de HEAD (o mesmo que HEAD^) -$ git show HEAD^2 # mostra o segundo pai de HEAD -------------------------------------- - -Você também pode dar aos commits nomes à sua escolha; após executar - -------------------------------------- -$ git tag v2.5 1b2e1d63ff -------------------------------------- - -você pode se referir a 1b2e1d63ff pelo nome "v2.5". Se você pretende -compartilhar esse nome com outras pessoas (por exemplo, para identificar -uma versão de lançamento), você deveria criar um objeto "tag", e talvez -assiná-lo; veja linkgit:git-tag[1] para detalhes. - -Qualquer comando git que precise conhecer um commit pode receber -quaisquer desses nomes. Por exemplo: - -------------------------------------- -$ git diff v2.5 HEAD # compara o HEAD atual com v2.5 -$ git branch stable v2.5 # inicia um novo ramo chamado "stable" baseado - # em v2.5 -$ git reset --hard HEAD^ # reseta seu ramo atual e seu diretório de - # trabalho a seu estado em HEAD^ -------------------------------------- - -Seja cuidadoso com o último comando: além de perder quaisquer mudanças -em seu diretório de trabalho, ele também remove todos os commits -posteriores desse ramo. Se esse ramo é o único ramo contendo esses -commits, eles serão perdidos. Também, não use 'git-reset' num ramo -publicamente visÃvel de onde outros desenvolvedores puxam, já que vai -forçar unificações desnecessárias para que outros desenvolvedores limpem -a história. Se você precisa desfazer mudanças que você empurrou, use -'git-revert' no lugar. - -O comando 'git-grep' pode buscar strings em qualquer versão de seu -projeto, então - -------------------------------------- -$ git grep "hello" v2.5 -------------------------------------- - -procura por todas as ocorrências de "hello" em v2.5. - -Se você deixar de fora o nome do commit, 'git-grep' irá procurar -quaisquer dos arquivos que ele gerencia no diretório corrente. Então - -------------------------------------- -$ git grep "hello" -------------------------------------- - -é uma forma rápida de buscar somente os arquivos que são rastreados pelo -git. - -Muitos comandos git também recebem um conjunto de commits, o que pode -ser especificado de várias formas. Aqui estão alguns exemplos com 'git-log': - -------------------------------------- -$ git log v2.5..v2.6 # commits entre v2.5 e v2.6 -$ git log v2.5.. # commits desde v2.5 -$ git log --since="2 weeks ago" # commits das últimas 2 semanas -$ git log v2.5.. Makefile # commits desde v2.5 que modificam - # Makefile -------------------------------------- - -Você também pode dar ao 'git-log' um "intervalo" de commits onde o -primeiro não é necessariamente um ancestral do segundo; por exemplo, se -as pontas dos ramos "stable" e "master" divergiram de um commit -comum algum tempo atrás, então - -------------------------------------- -$ git log stable..master -------------------------------------- - -irá listar os commits feitos no ramo "master" mas não no ramo -"stable", enquanto - -------------------------------------- -$ git log master..stable -------------------------------------- - -irá listar a lista de commits feitos no ramo "stable" mas não no ramo -"master". - -O comando 'git-log' tem uma fraqueza: ele precisa mostrar os commits em -uma lista. Quando a história tem linhas de desenvolvimento que -divergiram e então foram unificadas novamente, a ordem em que 'git-log' -apresenta essas mudanças é irrelevante. - -A maioria dos projetos com múltiplos contribuidores (como o kernel -Linux, ou o próprio git) tem unificações frequentes, e 'gitk' faz um -trabalho melhor de visualizar sua história. Por exemplo, - -------------------------------------- -$ gitk --since="2 weeks ago" drivers/ -------------------------------------- - -permite a você navegar em quaisquer commits desde as últimas duas semanas -de commits que modificaram arquivos sob o diretório "drivers". (Nota: -você pode ajustar as fontes do gitk segurando a tecla control enquanto -pressiona "-" ou "+".) - -Finalmente, a maioria dos comandos que recebem nomes de arquivo permitirão -também, opcionalmente, preceder qualquer nome de arquivo por um -commit, para especificar uma versão particular do arquivo: - -------------------------------------- -$ git diff v2.5:Makefile HEAD:Makefile.in -------------------------------------- - -Você pode usar 'git-show' para ver tal arquivo: - -------------------------------------- -$ git show v2.5:Makefile -------------------------------------- - -Próximos passos ----------- - -Este tutorial deve ser o bastante para operar controle de revisão -distribuÃdo básico para seus projetos. No entanto, para entender -plenamente a profundidade e o poder do git você precisa entender duas -idéias simples nas quais ele se baseia: - - * A base de objetos é um sistema bem elegante usado para armazenar a - história de seu projeto--arquivos, diretórios, e commits. - - * O arquivo de Ãndice é um cache do estado de uma árvore de diretório, - usado para criar commits, restaurar diretórios de trabalho, e - armazenar as várias árvores envolvidas em uma unificação. - -A parte dois deste tutorial explica a base de objetos, o arquivo de -Ãndice, e algumas outras coisinhas que você vai precisar pra usar o -máximo do git. Você pode encontrá-la em linkgit:gittutorial-2[7]. - -Se você não quiser continuar com o tutorial agora nesse momento, algumas -outras digressões que podem ser interessantes neste ponto são: - - * linkgit:git-format-patch[1], linkgit:git-am[1]: Estes convertem - séries de commits em patches para email, e vice-versa, úteis para - projetos como o kernel Linux que dependem fortemente de patches - enviados por email. - - * linkgit:git-bisect[1]: Quando há uma regressão em seu projeto, uma - forma de rastrear um bug é procurando pela história para encontrar o - commit culpado. Git bisect pode ajudar a executar uma busca binária - por esse commit. Ele é inteligente o bastante para executar uma - busca próxima da ótima mesmo no caso de uma história complexa - não-linear com muitos ramos unificados. - - * link:everyday.html[GIT diariamente com 20 e tantos comandos] - - * linkgit:gitcvs-migration[7]: Git para usuários de CVS. - -VEJA TAMBÉM --------- -linkgit:gittutorial-2[7], -linkgit:gitcvs-migration[7], -linkgit:gitcore-tutorial[7], -linkgit:gitglossary[7], -linkgit:git-help[1], -link:everyday.html[git diariamente], -link:user-manual.html[O Manual do Usuário git] - -GIT ---- -Parte da suite linkgit:git[1]. diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt index 5dd6e5a0c..18cffc25b 100644 --- a/Documentation/pull-fetch-param.txt +++ b/Documentation/pull-fetch-param.txt @@ -13,7 +13,7 @@ endif::git-pull[] <refspec>:: The format of a <refspec> parameter is an optional plus - `{plus}`, followed by the source ref <src>, followed + `+`, followed by the source ref <src>, followed by a colon `:`, followed by the destination ref <dst>. + The remote ref that matches <src> @@ -68,6 +68,11 @@ Some short-cut notations are also supported. + * `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`; it requests fetching everything up to the given tag. -* A parameter <ref> without a colon is equivalent to - <ref>: when pulling/fetching, so it merges <ref> into the current - branch without storing the remote branch anywhere locally +ifndef::git-pull[] +* A parameter <ref> without a colon fetches that ref into FETCH_HEAD, +endif::git-pull[] +ifdef::git-pull[] +* A parameter <ref> without a colon merges <ref> into the current + branch, +endif::git-pull[] + and updates the remote-tracking branches (if any). diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 39e620726..03533af71 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -3,79 +3,99 @@ Commit Limiting Besides specifying a range of commits that should be listed using the special notations explained in the description, additional commit -limiting may be applied. Note that they are applied before commit -ordering and formatting options, such as '--reverse'. +limiting may be applied. + +Using more options generally further limits the output (e.g. +`--since=<date1>` limits to commits newer than `<date1>`, and using it +with `--grep=<pattern>` further limits to commits whose log message +has a line that matches `<pattern>`), unless otherwise noted. + +Note that these are applied before commit +ordering and formatting options, such as `--reverse`. -- --n 'number':: +-<number>:: +-n <number>:: --max-count=<number>:: - Limit the number of commits to output. --skip=<number>:: - Skip 'number' commits before starting to show the commit output. --since=<date>:: --after=<date>:: - Show commits more recent than a specific date. --until=<date>:: --before=<date>:: - Show commits older than a specific date. ifdef::git-rev-list[] --max-age=<timestamp>:: --min-age=<timestamp>:: - Limit the commits output to specified time range. endif::git-rev-list[] --author=<pattern>:: --committer=<pattern>:: - Limit the commits output to ones with author/committer - header lines that match the specified pattern (regular expression). + header lines that match the specified pattern (regular + expression). With more than one `--author=<pattern>`, + commits whose author matches any of the given patterns are + chosen (similarly for multiple `--committer=<pattern>`). + +--grep-reflog=<pattern>:: + Limit the commits output to ones with reflog entries that + match the specified pattern (regular expression). With + more than one `--grep-reflog`, commits whose reflog message + matches any of the given patterns are chosen. It is an + error to use this option unless `--walk-reflogs` is in use. --grep=<pattern>:: - Limit the commits output to ones with log message that - matches the specified pattern (regular expression). + matches the specified pattern (regular expression). With + more than one `--grep=<pattern>`, commits whose message + matches any of the given patterns are chosen (but see + `--all-match`). ++ +When `--show-notes` is in effect, the message from the notes as +if it is part of the log message. --all-match:: - Limit the commits output to ones that match all given --grep, - --author and --committer instead of ones that match at least one. + Limit the commits output to ones that match all given `--grep`, + instead of ones that match at least one. -i:: --regexp-ignore-case:: + Match the regular expression limiting patterns without regard to letter + case. - Match the regexp limiting patterns without regard to letters case. +--basic-regexp:: + Consider the limiting patterns to be basic regular expressions; + this is the default. -E:: --extended-regexp:: - Consider the limiting patterns to be extended regular expressions instead of the default basic regular expressions. -F:: --fixed-strings:: - Consider the limiting patterns to be fixed strings (don't interpret pattern as a regular expression). ---remove-empty:: +--perl-regexp:: + Consider the limiting patterns to be Perl-compatible regular expressions. + Requires libpcre to be compiled in. +--remove-empty:: Stop when a given path disappears from the tree. --merges:: - Print only merge commits. This is exactly the same as `--min-parents=2`. --no-merges:: - Do not print commits with more than one parent. This is exactly the same as `--max-parents=1`. @@ -83,8 +103,7 @@ endif::git-rev-list[] --max-parents=<number>:: --no-min-parents:: --no-max-parents:: - - Show only commits which have at least (or at most) that many + Show only commits which have at least (or at most) that many parent commits. In particular, `--max-parents=1` is the same as `--no-merges`, `--min-parents=2` is the same as `--merges`. `--max-parents=0` gives all root commits and `--min-parents=3` all octopus merges. @@ -103,50 +122,58 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit). brought in to your history by such a merge. --not:: - Reverses the meaning of the '{caret}' prefix (or lack thereof) - for all following revision specifiers, up to the next '--not'. + for all following revision specifiers, up to the next `--not`. --all:: - Pretend as if all the refs in `refs/` are listed on the command line as '<commit>'. --branches[=<pattern>]:: - Pretend as if all the refs in `refs/heads` are listed on the command line as '<commit>'. If '<pattern>' is given, limit branches to ones matching given shell glob. If pattern lacks '?', - '*', or '[', '/*' at the end is implied. + '{asterisk}', or '[', '/{asterisk}' at the end is implied. --tags[=<pattern>]:: - Pretend as if all the refs in `refs/tags` are listed on the command line as '<commit>'. If '<pattern>' is given, limit - tags to ones matching given shell glob. If pattern lacks '?', '*', - or '[', '/*' at the end is implied. + tags to ones matching given shell glob. If pattern lacks '?', '{asterisk}', + or '[', '/{asterisk}' at the end is implied. --remotes[=<pattern>]:: - Pretend as if all the refs in `refs/remotes` are listed on the command line as '<commit>'. If '<pattern>' is given, limit remote-tracking branches to ones matching given shell glob. - If pattern lacks '?', '*', or '[', '/*' at the end is implied. + If pattern lacks '?', '{asterisk}', or '[', '/{asterisk}' at the end is implied. --glob=<glob-pattern>:: Pretend as if all the refs matching shell glob '<glob-pattern>' are listed on the command line as '<commit>'. Leading 'refs/', - is automatically prepended if missing. If pattern lacks '?', '*', - or '[', '/*' at the end is implied. + is automatically prepended if missing. If pattern lacks '?', '{asterisk}', + or '[', '/{asterisk}' at the end is implied. ---ignore-missing:: +--exclude=<glob-pattern>:: + + Do not include refs matching '<glob-pattern>' that the next `--all`, + `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise + consider. Repetitions of this option accumulate exclusion patterns + up to the next `--all`, `--branches`, `--tags`, `--remotes`, or + `--glob` option (other options or arguments do not clear + accumlated patterns). ++ +The patterns given should not begin with `refs/heads`, `refs/tags`, or +`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`, +respectively, and they must begin with `refs/` when applied to `--glob` +or `--all`. If a trailing '/{asterisk}' is intended, it must be given +explicitly. +--ignore-missing:: Upon seeing an invalid object name in the input, pretend as if the bad input was not given. ifndef::git-rev-list[] --bisect:: - Pretend as if the bad bisection ref `refs/bisect/bad` was listed and as if it was followed by `--not` and the good bisection refs `refs/bisect/good-*` on the command @@ -154,7 +181,6 @@ ifndef::git-rev-list[] endif::git-rev-list[] --stdin:: - In addition to the '<commit>' listed on the command line, read them from the standard input. If a '--' separator is seen, stop reading commits and start reading paths to limit the @@ -162,48 +188,43 @@ endif::git-rev-list[] ifdef::git-rev-list[] --quiet:: - Don't print anything to standard output. This form is primarily meant to allow the caller to test the exit status to see if a range of objects is fully connected (or not). It is faster than redirecting stdout - to /dev/null as the output does not have to be formatted. + to `/dev/null` as the output does not have to be formatted. endif::git-rev-list[] --cherry-mark:: - Like `--cherry-pick` (see below) but mark equivalent commits with `=` rather than omitting them, and inequivalent ones with `+`. --cherry-pick:: - Omit any commit that introduces the same change as - another commit on the "other side" when the set of + another commit on the ``other side'' when the set of commits are limited with symmetric difference. + For example, if you have two branches, `A` and `B`, a usual way to list all commits on only one side of them is with `--left-right` (see the example below in the description of -the `--left-right` option). It however shows the commits that were cherry-picked -from the other branch (for example, "3rd on b" may be cherry-picked -from branch A). With this option, such pairs of commits are +the `--left-right` option). However, it shows the commits that were +cherry-picked from the other branch (for example, ``3rd on b'' may be +cherry-picked from branch A). With this option, such pairs of commits are excluded from the output. --left-only:: --right-only:: - List only commits on the respective side of a symmetric range, i.e. only those which would be marked `<` resp. `>` by `--left-right`. + For example, `--cherry-pick --right-only A...B` omits those commits from `B` which are in `A` or are patch-equivalent to a commit in -`A`. In other words, this lists the `{plus}` commits from `git cherry A B`. +`A`. In other words, this lists the `+` commits from `git cherry A B`. More precisely, `--cherry-pick --right-only --no-merges` gives the exact list. --cherry:: - A synonym for `--right-only --cherry-mark --no-merges`; useful to limit the output to the commits on our side and mark those that have been applied to the other side of a forked history with @@ -212,32 +233,29 @@ list. -g:: --walk-reflogs:: - Instead of walking the commit ancestry chain, walk reflog entries from the most recent one to older ones. When this option is used you cannot specify commits to exclude (that is, '{caret}commit', 'commit1..commit2', nor 'commit1\...commit2' notations cannot be used). + -With '\--pretty' format other than oneline (for obvious reasons), +With `--pretty` format other than `oneline` (for obvious reasons), this causes the output to have two extra lines of information taken from the reflog. By default, 'commit@\{Nth}' notation is used in the output. When the starting commit is specified as 'commit@\{now}', output also uses 'commit@\{timestamp}' notation -instead. Under '\--pretty=oneline', the commit message is +instead. Under `--pretty=oneline`, the commit message is prefixed with this information on the same line. -This option cannot be combined with '\--reverse'. +This option cannot be combined with `--reverse`. See also linkgit:git-reflog[1]. --merge:: - After a failed merge, show refs that touch files having a conflict and don't exist on all heads to merge. --boundary:: - - Output uninteresting commits at the boundary, which are usually - not shown. + Output excluded boundary commits. Boundary commits are + prefixed with `-`. -- @@ -252,11 +270,9 @@ is how to do it, as there are various strategies to simplify the history. The following options select the commits to be shown: <paths>:: - Commits modifying the given <paths> are selected. --simplify-by-decoration:: - Commits that are referred by some branch or tag are selected. Note that extra commits can be shown to give a meaningful history. @@ -264,33 +280,27 @@ Note that extra commits can be shown to give a meaningful history. The following options affect the way the simplification is performed: Default mode:: - Simplifies the history to the simplest history explaining the final state of the tree. Simplest because it prunes some side branches if the end result is the same (i.e. merging branches with the same content) --full-history:: - Same as the default mode, but does not prune some history. --dense:: - Only the selected commits are shown, plus some to have a meaningful history. --sparse:: - All commits in the simplified history are shown. --simplify-merges:: - - Additional option to '--full-history' to remove some needless + Additional option to `--full-history` to remove some needless merges from the resulting history, as there are no selected commits contributing to this merge. --ancestry-path:: - When given a range of commits to display (e.g. 'commit1..commit2' or 'commit2 {caret}commit1'), only display commits that exist directly on the ancestry chain between the 'commit1' and @@ -307,43 +317,45 @@ In the following, we will always refer to the same example history to illustrate the differences between simplification settings. We assume that you are filtering for a file `foo` in this commit graph: ----------------------------------------------------------------------- - .-A---M---N---O---P - / / / / / - I B C D E - \ / / / / - `-------------' + .-A---M---N---O---P---Q + / / / / / / + I B C D E Y + \ / / / / / + `-------------' X ----------------------------------------------------------------------- -The horizontal line of history A---P is taken to be the first parent of +The horizontal line of history A---Q is taken to be the first parent of each merge. The commits are: * `I` is the initial commit, in which `foo` exists with contents - "asdf", and a file `quux` exists with contents "quux". Initial + ``asdf'', and a file `quux` exists with contents ``quux''. Initial commits are compared to an empty tree, so `I` is !TREESAME. -* In `A`, `foo` contains just "foo". +* In `A`, `foo` contains just ``foo''. * `B` contains the same change as `A`. Its merge `M` is trivial and hence TREESAME to all parents. -* `C` does not change `foo`, but its merge `N` changes it to "foobar", +* `C` does not change `foo`, but its merge `N` changes it to ``foobar'', so it is not TREESAME to any parent. -* `D` sets `foo` to "baz". Its merge `O` combines the strings from - `N` and `D` to "foobarbaz"; i.e., it is not TREESAME to any parent. +* `D` sets `foo` to ``baz''. Its merge `O` combines the strings from + `N` and `D` to ``foobarbaz''; i.e., it is not TREESAME to any parent. + +* `E` changes `quux` to ``xyzzy'', and its merge `P` combines the + strings to ``quux xyzzy''. `P` is TREESAME to `O`, but not to `E`. -* `E` changes `quux` to "xyzzy", and its merge `P` combines the - strings to "quux xyzzy". Despite appearing interesting, `P` is - TREESAME to all parents. +* `X` is an independent root commit that added a new file `side`, and `Y` + modified it. `Y` is TREESAME to `X`. Its merge `Q` added `side` to `P`, and + `Q` is TREESAME to `P`, but not to `Y`. -'rev-list' walks backwards through history, including or excluding -commits based on whether '\--full-history' and/or parent rewriting -(via '\--parents' or '\--children') are used. The following settings +`rev-list` walks backwards through history, including or excluding +commits based on whether `--full-history` and/or parent rewriting +(via `--parents` or `--children`) are used. The following settings are available. Default mode:: - Commits are included if they are not TREESAME to any parent - (though this can be changed, see '\--sparse' below). If the + (though this can be changed, see `--sparse` below). If the commit was a merge, and it was TREESAME to one parent, follow only that parent. (Even if there are several TREESAME parents, follow only one of them.) Otherwise, follow all @@ -362,12 +374,11 @@ available, removed `B` from consideration entirely. `C` was considered via `N`, but is TREESAME. Root commits are compared to an empty tree, so `I` is !TREESAME. + -Parent/child relations are only visible with --parents, but that does +Parent/child relations are only visible with `--parents`, but that does not affect the commits selected in default mode, so we have shown the parent lines. --full-history without parent rewriting:: - This mode differs from the default in one point: always follow all parents of a merge, even if it is TREESAME to one of them. Even if more than one side of the merge has commits that are @@ -375,10 +386,10 @@ parent lines. the example, we get + ----------------------------------------------------------------------- - I A B N D O + I A B N D O P Q ----------------------------------------------------------------------- + -`P` and `M` were excluded because they are TREESAME to a parent. `E`, +`M` was excluded because it is TREESAME to both parents. `E`, `C` and `B` were all walked, but only `B` was !TREESAME, so the others do not appear. + @@ -387,47 +398,43 @@ about the parent/child relationships between the commits, so we show them disconnected. --full-history with parent rewriting:: - Ordinary commits are only included if they are !TREESAME - (though this can be changed, see '\--sparse' below). + (though this can be changed, see `--sparse` below). + Merges are always included. However, their parent list is rewritten: Along each parent, prune away commits that are not included themselves. This results in + ----------------------------------------------------------------------- - .-A---M---N---O---P + .-A---M---N---O---P---Q / / / / / I B / D / \ / / / / `-------------' ----------------------------------------------------------------------- + -Compare to '\--full-history' without rewriting above. Note that `E` +Compare to `--full-history` without rewriting above. Note that `E` was pruned away because it is TREESAME, but the parent list of P was rewritten to contain `E`'s parent `I`. The same happened for `C` and -`N`. Note also that `P` was included despite being TREESAME. +`N`, and `X`, `Y` and `Q`. In addition to the above settings, you can change whether TREESAME affects inclusion: --dense:: - Commits that are walked are included if they are not TREESAME to any parent. --sparse:: - All commits that are walked are included. + -Note that without '\--full-history', this still simplifies merges: if +Note that without `--full-history`, this still simplifies merges: if one of the parents is TREESAME, we follow only that one, so the other sides of the merge are never walked. --simplify-merges:: - First, build a history graph in the same way that - '\--full-history' with parent rewriting does (see above). + `--full-history` with parent rewriting does (see above). + Then simplify each commit `C` to its replacement `C'` in the final history according to the following rules: @@ -436,8 +443,9 @@ history according to the following rules: * Set `C'` to `C`. + * Replace each parent `P` of `C'` with its simplification `P'`. In - the process, drop parents that are ancestors of other parents, and - remove duplicates. + the process, drop parents that are ancestors of other parents or that are + root commits TREESAME to an empty tree, and remove duplicates, but take care + to never drop all parents that we are TREESAME to. + * If after this parent rewriting, `C'` is a root or merge commit (has zero or >1 parents), a boundary commit, or !TREESAME, it remains. @@ -445,7 +453,7 @@ history according to the following rules: -- + The effect of this is best shown by way of comparing to -'\--full-history' with parent rewriting. The example turns into: +`--full-history` with parent rewriting. The example turns into: + ----------------------------------------------------------------------- .-A---M---N---O @@ -455,7 +463,7 @@ The effect of this is best shown by way of comparing to `---------' ----------------------------------------------------------------------- + -Note the major differences in `N` and `P` over '\--full-history': +Note the major differences in `N`, `P`, and `Q` over `--full-history`: + -- * `N`'s parent list had `I` removed, because it is an ancestor of the @@ -463,16 +471,19 @@ Note the major differences in `N` and `P` over '\--full-history': + * `P`'s parent list similarly had `I` removed. `P` was then removed completely, because it had one parent and is TREESAME. ++ +* `Q`'s parent list had `Y` simplified to `X`. `X` was then removed, because it + was a TREESAME root. `Q` was then removed completely, because it had one + parent and is TREESAME. -- Finally, there is a fifth simplification mode available: --ancestry-path:: - Limit the displayed commits to those directly on the ancestry - chain between the "from" and "to" commits in the given commit - range. I.e. only display commits that are ancestor of the "to" - commit, and descendants of the "from" commit. + chain between the ``from'' and ``to'' commits in the given commit + range. I.e. only display commits that are ancestor of the ``to'' + commit and descendants of the ``from'' commit. + As an example use case, consider the following commit history: + @@ -487,14 +498,14 @@ As an example use case, consider the following commit history: A regular 'D..M' computes the set of commits that are ancestors of `M`, but excludes the ones that are ancestors of `D`. This is useful to see what happened to the history leading to `M` since `D`, in the sense -that "what does `M` have that did not exist in `D`". The result in this +that ``what does `M` have that did not exist in `D`''. The result in this example would be all the commits, except `A` and `B` (and `D` itself, of course). + When we want to find out what commits in `M` are contaminated with the bug introduced by `D` and need fixing, however, we might want to view only the subset of 'D..M' that are actually descendants of `D`, i.e. -excluding `C` and `K`. This is exactly what the '\--ancestry-path' +excluding `C` and `K`. This is exactly what the `--ancestry-path` option does. Applied to the 'D..M' range, it results in: + ----------------------------------------------------------------------- @@ -505,7 +516,7 @@ option does. Applied to the 'D..M' range, it results in: L--M ----------------------------------------------------------------------- -The '\--simplify-by-decoration' option allows you to view only the +The `--simplify-by-decoration` option allows you to view only the big picture of the topology of the history, by omitting commits that are not referenced by tags. Commits are marked as !TREESAME (in other words, kept after history simplification rules described @@ -518,50 +529,47 @@ Bisection Helpers ~~~~~~~~~~~~~~~~~ --bisect:: - -Limit output to the one commit object which is roughly halfway between -included and excluded commits. Note that the bad bisection ref -`refs/bisect/bad` is added to the included commits (if it -exists) and the good bisection refs `refs/bisect/good-*` are -added to the excluded commits (if they exist). Thus, supposing there -are no refs in `refs/bisect/`, if - + Limit output to the one commit object which is roughly halfway between + included and excluded commits. Note that the bad bisection ref + `refs/bisect/bad` is added to the included commits (if it + exists) and the good bisection refs `refs/bisect/good-*` are + added to the excluded commits (if they exist). Thus, supposing there + are no refs in `refs/bisect/`, if ++ ----------------------------------------------------------------------- $ git rev-list --bisect foo ^bar ^baz ----------------------------------------------------------------------- - ++ outputs 'midpoint', the output of the two commands - ++ ----------------------------------------------------------------------- $ git rev-list foo ^midpoint $ git rev-list midpoint ^bar ^baz ----------------------------------------------------------------------- - ++ would be of roughly the same length. Finding the change which introduces a regression is thus reduced to a binary search: repeatedly generate and test new 'midpoint's until the commit chain is of length one. --bisect-vars:: - -This calculates the same as `--bisect`, except that refs in -`refs/bisect/` are not used, and except that this outputs -text ready to be eval'ed by the shell. These lines will assign the -name of the midpoint revision to the variable `bisect_rev`, and the -expected number of commits to be tested after `bisect_rev` is tested -to `bisect_nr`, the expected number of commits to be tested if -`bisect_rev` turns out to be good to `bisect_good`, the expected -number of commits to be tested if `bisect_rev` turns out to be bad to -`bisect_bad`, and the number of commits we are bisecting right now to -`bisect_all`. + This calculates the same as `--bisect`, except that refs in + `refs/bisect/` are not used, and except that this outputs + text ready to be eval'ed by the shell. These lines will assign the + name of the midpoint revision to the variable `bisect_rev`, and the + expected number of commits to be tested after `bisect_rev` is tested + to `bisect_nr`, the expected number of commits to be tested if + `bisect_rev` turns out to be good to `bisect_good`, the expected + number of commits to be tested if `bisect_rev` turns out to be bad to + `bisect_bad`, and the number of commits we are bisecting right now to + `bisect_all`. --bisect-all:: - -This outputs all the commit objects between the included and excluded -commits, ordered by their distance to the included and excluded -commits. Refs in `refs/bisect/` are not used. The farthest -from them is displayed first. (This is the only one displayed by -`--bisect`.) + This outputs all the commit objects between the included and excluded + commits, ordered by their distance to the included and excluded + commits. Refs in `refs/bisect/` are not used. The farthest + from them is displayed first. (This is the only one displayed by + `--bisect`.) + This is useful because it makes it easy to choose a good commit to test when you want to avoid to test some of them for some reason (they @@ -578,54 +586,74 @@ Commit Ordering By default, the commits are shown in reverse chronological order. ---topo-order:: +--date-order:: + Show no parents before all of its children are shown, but + otherwise show commits in the commit timestamp order. - This option makes them appear in topological order (i.e. - descendant commits are shown before their parents). +--author-date-order:: + Show no parents before all of its children are shown, but + otherwise show commits in the author timestamp order. ---date-order:: +--topo-order:: + Show no parents before all of its children are shown, and + avoid showing commits on multiple lines of history + intermixed. ++ +For example, in a commit history like this: ++ +---------------------------------------------------------------- - This option is similar to '--topo-order' in the sense that no - parent comes before all of its children, but otherwise things - are still ordered in the commit timestamp order. + ---1----2----4----7 + \ \ + 3----5----6----8--- ---reverse:: +---------------------------------------------------------------- ++ +where the numbers denote the order of commit timestamps, `git +rev-list` and friends with `--date-order` show the commits in the +timestamp order: 8 7 6 5 4 3 2 1. ++ +With `--topo-order`, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5 +3 1); some older commits are shown before newer ones in order to +avoid showing the commits from two parallel development track mixed +together. +--reverse:: Output the commits in reverse order. - Cannot be combined with '\--walk-reflogs'. + Cannot be combined with `--walk-reflogs`. Object Traversal ~~~~~~~~~~~~~~~~ -These options are mostly targeted for packing of git repositories. +These options are mostly targeted for packing of Git repositories. --objects:: - Print the object IDs of any object referenced by the listed - commits. '--objects foo ^bar' thus means "send me + commits. `--objects foo ^bar` thus means ``send me all object IDs which I need to download if I have the commit - object 'bar', but not 'foo'". + object _bar_ but not _foo_''. --objects-edge:: - - Similar to '--objects', but also print the IDs of excluded - commits prefixed with a "-" character. This is used by - linkgit:git-pack-objects[1] to build "thin" pack, which records + Similar to `--objects`, but also print the IDs of excluded + commits prefixed with a ``-'' character. This is used by + linkgit:git-pack-objects[1] to build ``thin'' pack, which records objects in deltified form based on objects contained in these excluded commits to reduce network traffic. --unpacked:: - - Only useful with '--objects'; print the object IDs that are not + Only useful with `--objects`; print the object IDs that are not in packs. ---no-walk:: - - Only show the given revs, but do not traverse their ancestors. +--no-walk[=(sorted|unsorted)]:: + Only show the given commits, but do not traverse their ancestors. + This has no effect if a range is specified. If the argument + `unsorted` is given, the commits are shown in the order they were + given on the command line. Otherwise (if `sorted` or no argument + was given), the commits are shown in reverse chronological order + by commit time. --do-walk:: - - Overrides a previous --no-walk. + Overrides a previous `--no-walk`. Commit Formatting ~~~~~~~~~~~~~~~~~ @@ -639,46 +667,41 @@ endif::git-rev-list[] include::pretty-options.txt[] --relative-date:: - Synonym for `--date=relative`. --date=(relative|local|default|iso|rfc|short|raw):: - Only takes effect for dates shown in human-readable format, such - as when using "--pretty". `log.date` config variable sets a default - value for log command's --date option. + as when using `--pretty`. `log.date` config variable sets a default + value for the log command's `--date` option. + `--date=relative` shows dates relative to the current time, -e.g. "2 hours ago". +e.g. ``2 hours ago''. + -`--date=local` shows timestamps in user's local timezone. +`--date=local` shows timestamps in user's local time zone. + `--date=iso` (or `--date=iso8601`) shows timestamps in ISO 8601 format. + `--date=rfc` (or `--date=rfc2822`) shows timestamps in RFC 2822 -format, often found in E-mail messages. +format, often found in email messages. + -`--date=short` shows only date but not time, in `YYYY-MM-DD` format. +`--date=short` shows only the date, but not the time, in `YYYY-MM-DD` format. + -`--date=raw` shows the date in the internal raw git format `%s %z` format. +`--date=raw` shows the date in the internal raw Git format `%s %z` format. + -`--date=default` shows timestamps in the original timezone +`--date=default` shows timestamps in the original time zone (either committer's or author's). ifdef::git-rev-list[] --header:: - Print the contents of the commit in raw-format; each record is separated with a NUL character. endif::git-rev-list[] --parents:: - Print also the parents of the commit (in the form "commit parent..."). Also enables parent rewriting, see 'History Simplification' below. --children:: - Print also the children of the commit (in the form "commit child..."). Also enables parent rewriting, see 'History Simplification' below. @@ -688,7 +711,6 @@ ifdef::git-rev-list[] endif::git-rev-list[] --left-right:: - Mark which side of a symmetric diff a commit is reachable from. Commits from the left side are prefixed with `<` and those from the right with `>`. If combined with `--boundary`, those @@ -718,7 +740,6 @@ you would get an output like this: ----------------------------------------------------------------------- --graph:: - Draw a text-based graphical representation of the commit history on the left hand side of the output. This may cause extra lines to be printed in between commits, in order for the graph history @@ -726,31 +747,29 @@ you would get an output like this: + This enables parent rewriting, see 'History Simplification' below. + -This implies the '--topo-order' option by default, but the -'--date-order' option may also be specified. +This implies the `--topo-order` option by default, but the +`--date-order` option may also be specified. ifdef::git-rev-list[] --count:: Print a number stating how many commits would have been listed, and suppress all other output. When used together - with '--left-right', instead print the counts for left and + with `--left-right`, instead print the counts for left and right commits, separated by a tab. When used together with - '--cherry-mark', omit patch equivalent commits from these + `--cherry-mark`, omit patch equivalent commits from these counts and print the count for equivalent commits separated by a tab. endif::git-rev-list[] - ifndef::git-rev-list[] Diff Formatting ~~~~~~~~~~~~~~~ -Below are listed options that control the formatting of diff output. +Listed below are options that control the formatting of diff output. Some of them are specific to linkgit:git-rev-list[1], however other diff options may be given. See linkgit:git-diff-files[1] for more options. -c:: - With this option, diff output for a merge commit shows the differences from each of the parents to the merge result simultaneously instead of showing pairwise diff between a parent @@ -758,29 +777,22 @@ options may be given. See linkgit:git-diff-files[1] for more options. which were modified from all parents. --cc:: - - This flag implies the '-c' options and further compresses the + This flag implies the `-c` option and further compresses the patch output by omitting uninteresting hunks whose contents in the parents have only two variants and the merge result picks one of them without modification. -m:: - This flag makes the merge commits show the full diff like regular commits; for each merge parent, a separate log entry and diff is generated. An exception is that only diff against - the first parent is shown when '--first-parent' option is given; + the first parent is shown when `--first-parent` option is given; in that case, the output represents the changes the merge brought _into_ the then-current branch. -r:: - Show recursive diffs. -t:: - - Show the tree objects in the diff output. This implies '-r'. - --s:: - Suppress diff output. + Show the tree objects in the diff output. This implies `-r`. endif::git-rev-list[] diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt index b290b617d..5a286d0d6 100644 --- a/Documentation/revisions.txt +++ b/Documentation/revisions.txt @@ -2,13 +2,13 @@ SPECIFYING REVISIONS -------------------- A revision parameter '<rev>' typically, but not necessarily, names a -commit object. It uses what is called an 'extended SHA1' +commit object. It uses what is called an 'extended SHA-1' syntax. Here are various ways to spell object names. The ones listed near the end of this list name trees and blobs contained in a commit. '<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e':: - The full SHA1 object name (40-byte hexadecimal string), or + The full SHA-1 object name (40-byte hexadecimal string), or a leading substring that is unique within the repository. E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both name the same commit object if there is no other object in @@ -23,23 +23,23 @@ blobs contained in a commit. A symbolic ref name. E.g. 'master' typically means the commit object referenced by 'refs/heads/master'. If you happen to have both 'heads/master' and 'tags/master', you can - explicitly say 'heads/master' to tell git which one you mean. - When ambiguous, a '<name>' is disambiguated by taking the + explicitly say 'heads/master' to tell Git which one you mean. + When ambiguous, a '<refname>' is disambiguated by taking the first match in the following rules: - . If '$GIT_DIR/<name>' exists, that is what you mean (this is usually + . If '$GIT_DIR/<refname>' exists, that is what you mean (this is usually useful only for 'HEAD', 'FETCH_HEAD', 'ORIG_HEAD', 'MERGE_HEAD' and 'CHERRY_PICK_HEAD'); - . otherwise, 'refs/<name>' if it exists; + . otherwise, 'refs/<refname>' if it exists; . otherwise, 'refs/tags/<refname>' if it exists; - . otherwise, 'refs/heads/<name>' if it exists; + . otherwise, 'refs/heads/<refname>' if it exists; - . otherwise, 'refs/remotes/<name>' if it exists; + . otherwise, 'refs/remotes/<refname>' if it exists; - . otherwise, 'refs/remotes/<name>/HEAD' if it exists. + . otherwise, 'refs/remotes/<refname>/HEAD' if it exists. + 'HEAD' names the commit on which you based the changes in the working tree. 'FETCH_HEAD' records the branch which you fetched from a remote repository @@ -55,6 +55,11 @@ when you run `git cherry-pick`. + Note that any of the 'refs/*' cases above may come either from the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file. +While the ref name encoding is unspecified, UTF-8 is preferred as +some output processing may assume ref names in UTF-8. + +'@':: + '@' alone is a shortcut for 'HEAD'. '<refname>@\{<date>\}', e.g. 'master@\{yesterday\}', 'HEAD@\{5 minutes ago\}':: A ref followed by the suffix '@' with a date specification @@ -83,13 +88,13 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file. branch 'blabla' then '@\{1\}' means the same as 'blabla@\{1\}'. '@\{-<n>\}', e.g. '@\{-1\}':: - The construct '@\{-<n>\}' means the <n>th branch checked out + The construct '@\{-<n>\}' means the <n>th branch/commit checked out before the current one. -'<refname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}':: - The suffix '@\{upstream\}' to a ref (short form '<refname>@\{u\}') refers to - the branch the ref is set to build on top of. A missing ref defaults - to the current branch. +'<branchname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}':: + The suffix '@\{upstream\}' to a branchname (short form '<branchname>@\{u\}') + refers to the branch that the branch specified by branchname is set to build on + top of. A missing branchname defaults to the current one. '<rev>{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0':: A suffix '{caret}' to a revision parameter means the first parent of @@ -101,7 +106,7 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file. '<rev>{tilde}<n>', e.g. 'master{tilde}3':: A suffix '{tilde}<n>' to a revision parameter means the commit - object that is the <n>th generation grand-parent of the named + object that is the <n>th generation ancestor of the named commit object, following only the first parents. I.e. '<rev>{tilde}3' is equivalent to '<rev>{caret}{caret}{caret}' which is equivalent to '<rev>{caret}1{caret}1{caret}1'. See below for an illustration of @@ -109,11 +114,23 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file. '<rev>{caret}\{<type>\}', e.g. 'v0.99.8{caret}\{commit\}':: A suffix '{caret}' followed by an object type name enclosed in - brace pair means the object - could be a tag, and dereference the tag recursively until an - object of that type is found or the object cannot be - dereferenced anymore (in which case, barf). '<rev>{caret}0' + brace pair means dereference the object at '<rev>' recursively until + an object of type '<type>' is found or the object cannot be + dereferenced anymore (in which case, barf). + For example, if '<rev>' is a commit-ish, '<rev>{caret}\{commit\}' + describes the corresponding commit object. + Similarly, if '<rev>' is a tree-ish, '<rev>{caret}\{tree\}' + describes the corresponding tree object. + '<rev>{caret}0' is a short-hand for '<rev>{caret}\{commit\}'. ++ +'rev{caret}\{object\}' can be used to make sure 'rev' names an +object that exists, without requiring 'rev' to be a tag, and +without dereferencing 'rev'; because a tag is already an object, +it does not have to be dereferenced even once to get to an object. ++ +'rev{caret}\{tag\}' can be used to ensure that 'rev' identifies an +existing tag object. '<rev>{caret}\{\}', e.g. 'v0.99.8{caret}\{\}':: A suffix '{caret}' followed by an empty brace pair @@ -213,18 +230,58 @@ of 'r1' and 'r2' and is defined as It is the set of commits that are reachable from either one of 'r1' or 'r2' but not from both. +In these two shorthands, you can omit one end and let it default to HEAD. +For example, 'origin..' is a shorthand for 'origin..HEAD' and asks "What +did I do since I forked from the origin branch?" Similarly, '..origin' +is a shorthand for 'HEAD..origin' and asks "What did the origin do since +I forked from them?" Note that '..' would mean 'HEAD..HEAD' which is an +empty range that is both reachable and unreachable from HEAD. + Two other shorthands for naming a set that is formed by a commit and its parent commits exist. The 'r1{caret}@' notation means all parents of 'r1'. 'r1{caret}!' includes commit 'r1' but excludes all of its parents. +To summarize: + +'<rev>':: + Include commits that are reachable from (i.e. ancestors of) + <rev>. + +'{caret}<rev>':: + Exclude commits that are reachable from (i.e. ancestors of) + <rev>. + +'<rev1>..<rev2>':: + Include commits that are reachable from <rev2> but exclude + those that are reachable from <rev1>. When either <rev1> or + <rev2> is omitted, it defaults to 'HEAD'. + +'<rev1>\...<rev2>':: + Include commits that are reachable from either <rev1> or + <rev2> but exclude those that are reachable from both. When + either <rev1> or <rev2> is omitted, it defaults to 'HEAD'. + +'<rev>{caret}@', e.g. 'HEAD{caret}@':: + A suffix '{caret}' followed by an at sign is the same as listing + all parents of '<rev>' (meaning, include anything reachable from + its parents, but not the commit itself). + +'<rev>{caret}!', e.g. 'HEAD{caret}!':: + A suffix '{caret}' followed by an exclamation mark is the same + as giving commit '<rev>' and then all its parents prefixed with + '{caret}' to exclude them (and their ancestors). + Here are a handful of examples: D G H D D F G H I J D F ^G D H D ^D B E I J F B + B..C C B...C G H D E B C ^D B C E I J F B C + C I J F C C^@ I J F + C^! C F^! D G H D F diff --git a/Documentation/sequencer.txt b/Documentation/sequencer.txt new file mode 100644 index 000000000..5747f442f --- /dev/null +++ b/Documentation/sequencer.txt @@ -0,0 +1,12 @@ +--continue:: + Continue the operation in progress using the information in + '.git/sequencer'. Can be used to continue after resolving + conflicts in a failed cherry-pick or revert. + +--quit:: + Forget about the current operation in progress. Can be used + to clear the sequencer state after a failed cherry-pick or + revert. + +--abort:: + Cancel the operation and return to the pre-sequence state. diff --git a/Documentation/technical/api-allocation-growing.txt b/Documentation/technical/api-allocation-growing.txt index 43dbe09f7..542946b1b 100644 --- a/Documentation/technical/api-allocation-growing.txt +++ b/Documentation/technical/api-allocation-growing.txt @@ -5,7 +5,9 @@ Dynamically growing an array using realloc() is error prone and boring. Define your array with: -* a pointer (`ary`) that points at the array, initialized to `NULL`; +* a pointer (`item`) that points at the array, initialized to `NULL` + (although please name the variable based on its contents, not on its + type); * an integer variable (`alloc`) that keeps track of how big the current allocation is, initialized to `0`; @@ -13,22 +15,22 @@ Define your array with: * another integer variable (`nr`) to keep track of how many elements the array currently has, initialized to `0`. -Then before adding `n`th element to the array, call `ALLOC_GROW(ary, n, +Then before adding `n`th element to the item, call `ALLOC_GROW(item, n, alloc)`. This ensures that the array can hold at least `n` elements by calling `realloc(3)` and adjusting `alloc` variable. ------------ -sometype *ary; +sometype *item; size_t nr; size_t alloc for (i = 0; i < nr; i++) - if (we like ary[i] already) + if (we like item[i] already) return; /* we did not like any existing one, so add one */ -ALLOC_GROW(ary, nr + 1, alloc); -ary[nr++] = value you like; +ALLOC_GROW(item, nr + 1, alloc); +item[nr++] = value you like; ------------ You are responsible for updating the `nr` variable. diff --git a/Documentation/technical/api-argv-array.txt b/Documentation/technical/api-argv-array.txt new file mode 100644 index 000000000..a6b7d83a8 --- /dev/null +++ b/Documentation/technical/api-argv-array.txt @@ -0,0 +1,63 @@ +argv-array API +============== + +The argv-array API allows one to dynamically build and store +NULL-terminated lists. An argv-array maintains the invariant that the +`argv` member always points to a non-NULL array, and that the array is +always NULL-terminated at the element pointed to by `argv[argc]`. This +makes the result suitable for passing to functions expecting to receive +argv from main(), or the link:api-run-command.html[run-command API]. + +The link:api-string-list.html[string-list API] is similar, but cannot be +used for these purposes; instead of storing a straight string pointer, +it contains an item structure with a `util` field that is not compatible +with the traditional argv interface. + +Each `argv_array` manages its own memory. Any strings pushed into the +array are duplicated, and all memory is freed by argv_array_clear(). + +Data Structures +--------------- + +`struct argv_array`:: + + A single array. This should be initialized by assignment from + `ARGV_ARRAY_INIT`, or by calling `argv_array_init`. The `argv` + member contains the actual array; the `argc` member contains the + number of elements in the array, not including the terminating + NULL. + +Functions +--------- + +`argv_array_init`:: + Initialize an array. This is no different than assigning from + `ARGV_ARRAY_INIT`. + +`argv_array_push`:: + Push a copy of a string onto the end of the array. + +`argv_array_pushl`:: + Push a list of strings onto the end of the array. The arguments + should be a list of `const char *` strings, terminated by a NULL + argument. + +`argv_array_pushf`:: + Format a string and push it onto the end of the array. This is a + convenience wrapper combining `strbuf_addf` and `argv_array_push`. + +`argv_array_pop`:: + Remove the final element from the array. If there are no + elements in the array, do nothing. + +`argv_array_clear`:: + Free all memory associated with the array and return it to the + initial, empty state. + +`argv_array_detach`:: + Detach the argv array from the `struct argv_array`, transferring + ownership of the allocated array and strings. + +`argv_array_free_detached`:: + Free the memory allocated by a `struct argv_array` that was later + detached and is now no longer needed. diff --git a/Documentation/technical/api-builtin.txt b/Documentation/technical/api-builtin.txt index b0cafe87b..e3d6e7a79 100644 --- a/Documentation/technical/api-builtin.txt +++ b/Documentation/technical/api-builtin.txt @@ -5,7 +5,7 @@ Adding a new built-in --------------------- There are 4 things to do to add a built-in command implementation to -git: +Git: . Define the implementation of the built-in command `foo` with signature: @@ -14,8 +14,8 @@ git: . Add the external declaration for the function to `builtin.h`. -. Add the command to `commands[]` table in `handle_internal_command()`, - defined in `git.c`. The entry should look like: +. Add the command to the `commands[]` table defined in `git.c`. + The entry should look like: { "foo", cmd_foo, <options> }, + @@ -23,7 +23,7 @@ where options is the bitwise-or of: `RUN_SETUP`:: - Make sure there is a git directory to work on, and if there is a + Make sure there is a Git directory to work on, and if there is a work tree, chdir to the top of it if the command was invoked in a subdirectory. If there is no work tree, no chdir() is done. @@ -39,7 +39,7 @@ where options is the bitwise-or of: on bare repositories. This only makes sense when `RUN_SETUP` is also set. -. Add `builtin-foo.o` to `BUILTIN_OBJS` in `Makefile`. +. Add `builtin/foo.o` to `BUILTIN_OBJS` in `Makefile`. Additionally, if `foo` is a new command, there are 3 more things to do: diff --git a/Documentation/technical/api-config.txt b/Documentation/technical/api-config.txt new file mode 100644 index 000000000..230b3a0f6 --- /dev/null +++ b/Documentation/technical/api-config.txt @@ -0,0 +1,140 @@ +config API +========== + +The config API gives callers a way to access Git configuration files +(and files which have the same syntax). See linkgit:git-config[1] for a +discussion of the config file syntax. + +General Usage +------------- + +Config files are parsed linearly, and each variable found is passed to a +caller-provided callback function. The callback function is responsible +for any actions to be taken on the config option, and is free to ignore +some options. It is not uncommon for the configuration to be parsed +several times during the run of a Git program, with different callbacks +picking out different variables useful to themselves. + +A config callback function takes three parameters: + +- the name of the parsed variable. This is in canonical "flat" form: the + section, subsection, and variable segments will be separated by dots, + and the section and variable segments will be all lowercase. E.g., + `core.ignorecase`, `diff.SomeType.textconv`. + +- the value of the found variable, as a string. If the variable had no + value specified, the value will be NULL (typically this means it + should be interpreted as boolean true). + +- a void pointer passed in by the caller of the config API; this can + contain callback-specific data + +A config callback should return 0 for success, or -1 if the variable +could not be parsed properly. + +Basic Config Querying +--------------------- + +Most programs will simply want to look up variables in all config files +that Git knows about, using the normal precedence rules. To do this, +call `git_config` with a callback function and void data pointer. + +`git_config` will read all config sources in order of increasing +priority. Thus a callback should typically overwrite previously-seen +entries with new ones (e.g., if both the user-wide `~/.gitconfig` and +repo-specific `.git/config` contain `color.ui`, the config machinery +will first feed the user-wide one to the callback, and then the +repo-specific one; by overwriting, the higher-priority repo-specific +value is left at the end). + +The `git_config_with_options` function lets the caller examine config +while adjusting some of the default behavior of `git_config`. It should +almost never be used by "regular" Git code that is looking up +configuration variables. It is intended for advanced callers like +`git-config`, which are intentionally tweaking the normal config-lookup +process. It takes two extra parameters: + +`filename`:: +If this parameter is non-NULL, it specifies the name of a file to +parse for configuration, rather than looking in the usual files. Regular +`git_config` defaults to `NULL`. + +`respect_includes`:: +Specify whether include directives should be followed in parsed files. +Regular `git_config` defaults to `1`. + +There is a special version of `git_config` called `git_config_early`. +This version takes an additional parameter to specify the repository +config, instead of having it looked up via `git_path`. This is useful +early in a Git program before the repository has been found. Unless +you're working with early setup code, you probably don't want to use +this. + +Reading Specific Files +---------------------- + +To read a specific file in git-config format, use +`git_config_from_file`. This takes the same callback and data parameters +as `git_config`. + +Value Parsing Helpers +--------------------- + +To aid in parsing string values, the config API provides callbacks with +a number of helper functions, including: + +`git_config_int`:: +Parse the string to an integer, including unit factors. Dies on error; +otherwise, returns the parsed result. + +`git_config_ulong`:: +Identical to `git_config_int`, but for unsigned longs. + +`git_config_bool`:: +Parse a string into a boolean value, respecting keywords like "true" and +"false". Integer values are converted into true/false values (when they +are non-zero or zero, respectively). Other values cause a die(). If +parsing is successful, the return value is the result. + +`git_config_bool_or_int`:: +Same as `git_config_bool`, except that integers are returned as-is, and +an `is_bool` flag is unset. + +`git_config_maybe_bool`:: +Same as `git_config_bool`, except that it returns -1 on error rather +than dying. + +`git_config_string`:: +Allocates and copies the value string into the `dest` parameter; if no +string is given, prints an error message and returns -1. + +`git_config_pathname`:: +Similar to `git_config_string`, but expands `~` or `~user` into the +user's home directory when found at the beginning of the path. + +Include Directives +------------------ + +By default, the config parser does not respect include directives. +However, a caller can use the special `git_config_include` wrapper +callback to support them. To do so, you simply wrap your "real" callback +function and data pointer in a `struct config_include_data`, and pass +the wrapper to the regular config-reading functions. For example: + +------------------------------------------- +int read_file_with_include(const char *file, config_fn_t fn, void *data) +{ + struct config_include_data inc = CONFIG_INCLUDE_INIT; + inc.fn = fn; + inc.data = data; + return git_config_from_file(git_config_include, file, &inc); +} +------------------------------------------- + +`git_config` respects includes automatically. The lower-level +`git_config_from_file` does not. + +Writing Config Files +-------------------- + +TODO diff --git a/Documentation/technical/api-credentials.txt b/Documentation/technical/api-credentials.txt new file mode 100644 index 000000000..c1b42a40d --- /dev/null +++ b/Documentation/technical/api-credentials.txt @@ -0,0 +1,268 @@ +credentials API +=============== + +The credentials API provides an abstracted way of gathering username and +password credentials from the user (even though credentials in the wider +world can take many forms, in this document the word "credential" always +refers to a username and password pair). + +This document describes two interfaces: the C API that the credential +subsystem provides to the rest of Git, and the protocol that Git uses to +communicate with system-specific "credential helpers". If you are +writing Git code that wants to look up or prompt for credentials, see +the section "C API" below. If you want to write your own helper, see +the section on "Credential Helpers" below. + +Typical setup +------------- + +------------ ++-----------------------+ +| Git code (C) |--- to server requiring ---> +| | authentication +|.......................| +| C credential API |--- prompt ---> User ++-----------------------+ + ^ | + | pipe | + | v ++-----------------------+ +| Git credential helper | ++-----------------------+ +------------ + +The Git code (typically a remote-helper) will call the C API to obtain +credential data like a login/password pair (credential_fill). The +API will itself call a remote helper (e.g. "git credential-cache" or +"git credential-store") that may retrieve credential data from a +store. If the credential helper cannot find the information, the C API +will prompt the user. Then, the caller of the API takes care of +contacting the server, and does the actual authentication. + +C API +----- + +The credential C API is meant to be called by Git code which needs to +acquire or store a credential. It is centered around an object +representing a single credential and provides three basic operations: +fill (acquire credentials by calling helpers and/or prompting the user), +approve (mark a credential as successfully used so that it can be stored +for later use), and reject (mark a credential as unsuccessful so that it +can be erased from any persistent storage). + +Data Structures +~~~~~~~~~~~~~~~ + +`struct credential`:: + + This struct represents a single username/password combination + along with any associated context. All string fields should be + heap-allocated (or NULL if they are not known or not applicable). + The meaning of the individual context fields is the same as + their counterparts in the helper protocol; see the section below + for a description of each field. ++ +The `helpers` member of the struct is a `string_list` of helpers. Each +string specifies an external helper which will be run, in order, to +either acquire or store credentials. See the section on credential +helpers below. This list is filled-in by the API functions +according to the corresponding configuration variables before +consulting helpers, so there usually is no need for a caller to +modify the helpers field at all. ++ +This struct should always be initialized with `CREDENTIAL_INIT` or +`credential_init`. + + +Functions +~~~~~~~~~ + +`credential_init`:: + + Initialize a credential structure, setting all fields to empty. + +`credential_clear`:: + + Free any resources associated with the credential structure, + returning it to a pristine initialized state. + +`credential_fill`:: + + Instruct the credential subsystem to fill the username and + password fields of the passed credential struct by first + consulting helpers, then asking the user. After this function + returns, the username and password fields of the credential are + guaranteed to be non-NULL. If an error occurs, the function will + die(). + +`credential_reject`:: + + Inform the credential subsystem that the provided credentials + have been rejected. This will cause the credential subsystem to + notify any helpers of the rejection (which allows them, for + example, to purge the invalid credentials from storage). It + will also free() the username and password fields of the + credential and set them to NULL (readying the credential for + another call to `credential_fill`). Any errors from helpers are + ignored. + +`credential_approve`:: + + Inform the credential subsystem that the provided credentials + were successfully used for authentication. This will cause the + credential subsystem to notify any helpers of the approval, so + that they may store the result to be used again. Any errors + from helpers are ignored. + +`credential_from_url`:: + + Parse a URL into broken-down credential fields. + +Example +~~~~~~~ + +The example below shows how the functions of the credential API could be +used to login to a fictitious "foo" service on a remote host: + +----------------------------------------------------------------------- +int foo_login(struct foo_connection *f) +{ + int status; + /* + * Create a credential with some context; we don't yet know the + * username or password. + */ + + struct credential c = CREDENTIAL_INIT; + c.protocol = xstrdup("foo"); + c.host = xstrdup(f->hostname); + + /* + * Fill in the username and password fields by contacting + * helpers and/or asking the user. The function will die if it + * fails. + */ + credential_fill(&c); + + /* + * Otherwise, we have a username and password. Try to use it. + */ + status = send_foo_login(f, c.username, c.password); + switch (status) { + case FOO_OK: + /* It worked. Store the credential for later use. */ + credential_accept(&c); + break; + case FOO_BAD_LOGIN: + /* Erase the credential from storage so we don't try it + * again. */ + credential_reject(&c); + break; + default: + /* + * Some other error occurred. We don't know if the + * credential is good or bad, so report nothing to the + * credential subsystem. + */ + } + + /* Free any associated resources. */ + credential_clear(&c); + + return status; +} +----------------------------------------------------------------------- + + +Credential Helpers +------------------ + +Credential helpers are programs executed by Git to fetch or save +credentials from and to long-term storage (where "long-term" is simply +longer than a single Git process; e.g., credentials may be stored +in-memory for a few minutes, or indefinitely on disk). + +Each helper is specified by a single string in the configuration +variable `credential.helper` (and others, see linkgit:git-config[1]). +The string is transformed by Git into a command to be executed using +these rules: + + 1. If the helper string begins with "!", it is considered a shell + snippet, and everything after the "!" becomes the command. + + 2. Otherwise, if the helper string begins with an absolute path, the + verbatim helper string becomes the command. + + 3. Otherwise, the string "git credential-" is prepended to the helper + string, and the result becomes the command. + +The resulting command then has an "operation" argument appended to it +(see below for details), and the result is executed by the shell. + +Here are some example specifications: + +---------------------------------------------------- +# run "git credential-foo" +foo + +# same as above, but pass an argument to the helper +foo --bar=baz + +# the arguments are parsed by the shell, so use shell +# quoting if necessary +foo --bar="whitespace arg" + +# you can also use an absolute path, which will not use the git wrapper +/path/to/my/helper --with-arguments + +# or you can specify your own shell snippet +!f() { echo "password=`cat $HOME/.secret`"; }; f +---------------------------------------------------- + +Generally speaking, rule (3) above is the simplest for users to specify. +Authors of credential helpers should make an effort to assist their +users by naming their program "git-credential-$NAME", and putting it in +the $PATH or $GIT_EXEC_PATH during installation, which will allow a user +to enable it with `git config credential.helper $NAME`. + +When a helper is executed, it will have one "operation" argument +appended to its command line, which is one of: + +`get`:: + + Return a matching credential, if any exists. + +`store`:: + + Store the credential, if applicable to the helper. + +`erase`:: + + Remove a matching credential, if any, from the helper's storage. + +The details of the credential will be provided on the helper's stdin +stream. The exact format is the same as the input/output format of the +`git credential` plumbing command (see the section `INPUT/OUTPUT +FORMAT` in linkgit:git-credential[7] for a detailed specification). + +For a `get` operation, the helper should produce a list of attributes +on stdout in the same format. A helper is free to produce a subset, or +even no values at all if it has nothing useful to provide. Any provided +attributes will overwrite those already known about by Git. + +For a `store` or `erase` operation, the helper's output is ignored. +If it fails to perform the requested operation, it may complain to +stderr to inform the user. If it does not support the requested +operation (e.g., a read-only store), it should silently ignore the +request. + +If a helper receives any other operation, it should silently ignore the +request. This leaves room for future operations to be added (older +helpers will just ignore the new requests). + +See also +-------- + +linkgit:gitcredentials[7] + +linkgit:git-config[5] (See configuration variables `credential.*`) diff --git a/Documentation/technical/api-diff.txt b/Documentation/technical/api-diff.txt index 2d2ebc04b..8b001de0d 100644 --- a/Documentation/technical/api-diff.txt +++ b/Documentation/technical/api-diff.txt @@ -28,7 +28,8 @@ Calling sequence * Call `diff_setup_done()`; this inspects the options set up so far for internal consistency and make necessary tweaking to it (e.g. if - textual patch output was asked, recursive behaviour is turned on). + textual patch output was asked, recursive behaviour is turned on); + the callback set_default in diff_options can be used to tweak this more. * As you find different pairs of files, call `diff_change()` to feed modified files, `diff_addremove()` to feed created or deleted files, @@ -115,6 +116,13 @@ Notable members are: operation, but some do not have anything to do with the diffcore library. +`touched_flags`:: + Records whether a flag has been changed due to user request + (rather than just set/unset by default). + +`set_default`:: + Callback which allows tweaking the options in diff_setup_done(). + BINARY, TEXT;; Affects the way how a file that is seemingly binary is treated. diff --git a/Documentation/technical/api-directory-listing.txt b/Documentation/technical/api-directory-listing.txt index add6f435b..7f8e78d91 100644 --- a/Documentation/technical/api-directory-listing.txt +++ b/Documentation/technical/api-directory-listing.txt @@ -9,37 +9,51 @@ Data structure -------------- `struct dir_struct` structure is used to pass directory traversal -options to the library and to record the paths discovered. The notable -options are: +options to the library and to record the paths discovered. A single +`struct dir_struct` is used regardless of whether or not the traversal +recursively descends into subdirectories. + +The notable options are: `exclude_per_dir`:: The name of the file to be read in each directory for excluded files (typically `.gitignore`). -`collect_ignored`:: +`flags`:: + + A bit-field of options (the `*IGNORED*` flags are mutually exclusive): + +`DIR_SHOW_IGNORED`::: + + Return just ignored files in `entries[]`, not untracked files. + +`DIR_SHOW_IGNORED_TOO`::: - Include paths that are to be excluded in the result. + Similar to `DIR_SHOW_IGNORED`, but return ignored files in `ignored[]` + in addition to untracked files in `entries[]`. -`show_ignored`:: +`DIR_COLLECT_IGNORED`::: - The traversal is for finding just ignored files, not unignored - files. + Special mode for git-add. Return ignored files in `ignored[]` and + untracked files in `entries[]`. Only returns ignored files that match + pathspec exactly (no wildcards). Does not recurse into ignored + directories. -`show_other_directories`:: +`DIR_SHOW_OTHER_DIRECTORIES`::: Include a directory that is not tracked. -`hide_empty_directories`:: +`DIR_HIDE_EMPTY_DIRECTORIES`::: Do not include a directory that is not tracked and is empty. -`no_gitlinks`:: +`DIR_NO_GITLINKS`::: - If set, recurse into a directory that looks like a git + If set, recurse into a directory that looks like a Git directory. Otherwise it is shown as a directory. -The result of the enumeration is left in these fields:: +The result of the enumeration is left in these fields: `entries[]`:: @@ -54,6 +68,14 @@ The result of the enumeration is left in these fields:: Internal use; keeps track of allocation of `entries[]` array. +`ignored[]`:: + + An array of `struct dir_entry`, used for ignored paths with the + `DIR_SHOW_IGNORED_TOO` and `DIR_COLLECT_IGNORED` flags. + +`ignored_nr`:: + + The number of members in `ignored[]` array. Calling sequence ---------------- @@ -64,11 +86,13 @@ marked. If you to exclude files, make sure you have loaded index first. * Prepare `struct dir_struct dir` and clear it with `memset(&dir, 0, sizeof(dir))`. -* Call `add_exclude()` to add single exclude pattern, - `add_excludes_from_file()` to add patterns from a file - (e.g. `.git/info/exclude`), and/or set `dir.exclude_per_dir`. A - short-hand function `setup_standard_excludes()` can be used to set up - the standard set of exclude settings. +* To add single exclude pattern, call `add_exclude_list()` and then + `add_exclude()`. + +* To add patterns from a file (e.g. `.git/info/exclude`), call + `add_excludes_from_file()` , and/or set `dir.exclude_per_dir`. A + short-hand function `setup_standard_excludes()` can be used to set + up the standard set of exclude settings. * Set options described in the Data Structure section above. @@ -76,4 +100,6 @@ marked. If you to exclude files, make sure you have loaded index first. * Use `dir.entries[]`. +* Call `clear_directory()` when none of the contained elements are no longer in use. + (JC) diff --git a/Documentation/technical/api-gitattributes.txt b/Documentation/technical/api-gitattributes.txt index 9d97eaa9d..ce363b630 100644 --- a/Documentation/technical/api-gitattributes.txt +++ b/Documentation/technical/api-gitattributes.txt @@ -11,27 +11,15 @@ Data Structure `struct git_attr`:: An attribute is an opaque object that is identified by its name. - Pass the name and its length to `git_attr()` function to obtain - the object of this type. The internal representation of this - structure is of no interest to the calling programs. + Pass the name to `git_attr()` function to obtain the object of + this type. The internal representation of this structure is + of no interest to the calling programs. The name of the + attribute can be retrieved by calling `git_attr_name()`. `struct git_attr_check`:: This structure represents a set of attributes to check in a call - to `git_checkattr()` function, and receives the results. - - -Calling Sequence ----------------- - -* Prepare an array of `struct git_attr_check` to define the list of - attributes you would want to check. To populate this array, you would - need to define necessary attributes by calling `git_attr()` function. - -* Call git_checkattr() to check the attributes for the path. - -* Inspect `git_attr_check` structure to see how each of the attribute in - the array is defined for the path. + to `git_check_attr()` function, and receives the results. Attribute Values @@ -57,6 +45,19 @@ If none of the above returns true, `.value` member points at a string value of the attribute for the path. +Querying Specific Attributes +---------------------------- + +* Prepare an array of `struct git_attr_check` to define the list of + attributes you would want to check. To populate this array, you would + need to define necessary attributes by calling `git_attr()` function. + +* Call `git_check_attr()` to check the attributes for the path. + +* Inspect `git_attr_check` structure to see how each of the attribute in + the array is defined for the path. + + Example ------- @@ -72,18 +73,18 @@ static void setup_check(void) { if (check[0].attr) return; /* already done */ - check[0].attr = git_attr("crlf", 4); - check[1].attr = git_attr("ident", 5); + check[0].attr = git_attr("crlf"); + check[1].attr = git_attr("ident"); } ------------ -. Call `git_checkattr()` with the prepared array of `struct git_attr_check`: +. Call `git_check_attr()` with the prepared array of `struct git_attr_check`: ------------ const char *path; setup_check(); - git_checkattr(path, ARRAY_SIZE(check), check); + git_check_attr(path, ARRAY_SIZE(check), check); ------------ . Act on `.value` member of the result, left in `check[]`: @@ -108,4 +109,20 @@ static void setup_check(void) } ------------ -(JC) + +Querying All Attributes +----------------------- + +To get the values of all attributes associated with a file: + +* Call `git_all_attrs()`, which returns an array of `git_attr_check` + structures. + +* Iterate over the `git_attr_check` array to examine the attribute + names and values. The name of the attribute described by a + `git_attr_check` object can be retrieved via + `git_attr_name(check[i].attr)`. (Please note that no items will be + returned for unset attributes, so `ATTR_UNSET()` will return false + for all returned `git_array_check` objects.) + +* Free the `git_array_check` array. diff --git a/Documentation/technical/api-hash.txt b/Documentation/technical/api-hash.txt deleted file mode 100644 index e5061e067..000000000 --- a/Documentation/technical/api-hash.txt +++ /dev/null @@ -1,52 +0,0 @@ -hash API -======== - -The hash API is a collection of simple hash table functions. Users are expected -to implement their own hashing. - -Data Structures ---------------- - -`struct hash_table`:: - - The hash table structure. The `array` member points to the hash table - entries. The `size` member counts the total number of valid and invalid - entries in the table. The `nr` member keeps track of the number of - valid entries. - -`struct hash_table_entry`:: - - An opaque structure representing an entry in the hash table. The `hash` - member is the entry's hash key and the `ptr` member is the entry's - value. - -Functions ---------- - -`init_hash`:: - - Initialize the hash table. - -`free_hash`:: - - Release memory associated with the hash table. - -`insert_hash`:: - - Insert a pointer into the hash table. If an entry with that hash - already exists, a pointer to the existing entry's value is returned. - Otherwise NULL is returned. This allows callers to implement - chaining, etc. - -`lookup_hash`:: - - Lookup an entry in the hash table. If an entry with that hash exists - the entry's value is returned. Otherwise NULL is returned. - -`for_each_hash`:: - - Call a function for each entry in the hash table. The function is - expected to take the entry's value as its only argument and return an - int. If the function returns a negative int the loop is aborted - immediately. Otherwise, the return value is accumulated and the sum - returned upon completion of the loop. diff --git a/Documentation/technical/api-hashmap.txt b/Documentation/technical/api-hashmap.txt new file mode 100644 index 000000000..42ca2347e --- /dev/null +++ b/Documentation/technical/api-hashmap.txt @@ -0,0 +1,235 @@ +hashmap API +=========== + +The hashmap API is a generic implementation of hash-based key-value mappings. + +Data Structures +--------------- + +`struct hashmap`:: + + The hash table structure. ++ +The `size` member keeps track of the total number of entries. The `cmpfn` +member is a function used to compare two entries for equality. The `table` and +`tablesize` members store the hash table and its size, respectively. + +`struct hashmap_entry`:: + + An opaque structure representing an entry in the hash table, which must + be used as first member of user data structures. Ideally it should be + followed by an int-sized member to prevent unused memory on 64-bit + systems due to alignment. ++ +The `hash` member is the entry's hash code and the `next` member points to the +next entry in case of collisions (i.e. if multiple entries map to the same +bucket). + +`struct hashmap_iter`:: + + An iterator structure, to be used with hashmap_iter_* functions. + +Types +----- + +`int (*hashmap_cmp_fn)(const void *entry, const void *entry_or_key, const void *keydata)`:: + + User-supplied function to test two hashmap entries for equality. Shall + return 0 if the entries are equal. ++ +This function is always called with non-NULL `entry` / `entry_or_key` +parameters that have the same hash code. When looking up an entry, the `key` +and `keydata` parameters to hashmap_get and hashmap_remove are always passed +as second and third argument, respectively. Otherwise, `keydata` is NULL. + +Functions +--------- + +`unsigned int strhash(const char *buf)`:: +`unsigned int strihash(const char *buf)`:: +`unsigned int memhash(const void *buf, size_t len)`:: +`unsigned int memihash(const void *buf, size_t len)`:: + + Ready-to-use hash functions for strings, using the FNV-1 algorithm (see + http://www.isthe.com/chongo/tech/comp/fnv). ++ +`strhash` and `strihash` take 0-terminated strings, while `memhash` and +`memihash` operate on arbitrary-length memory. ++ +`strihash` and `memihash` are case insensitive versions. + +`void hashmap_init(struct hashmap *map, hashmap_cmp_fn equals_function, size_t initial_size)`:: + + Initializes a hashmap structure. ++ +`map` is the hashmap to initialize. ++ +The `equals_function` can be specified to compare two entries for equality. +If NULL, entries are considered equal if their hash codes are equal. ++ +If the total number of entries is known in advance, the `initial_size` +parameter may be used to preallocate a sufficiently large table and thus +prevent expensive resizing. If 0, the table is dynamically resized. + +`void hashmap_free(struct hashmap *map, int free_entries)`:: + + Frees a hashmap structure and allocated memory. ++ +`map` is the hashmap to free. ++ +If `free_entries` is true, each hashmap_entry in the map is freed as well +(using stdlib's free()). + +`void hashmap_entry_init(void *entry, unsigned int hash)`:: + + Initializes a hashmap_entry structure. ++ +`entry` points to the entry to initialize. ++ +`hash` is the hash code of the entry. + +`void *hashmap_get(const struct hashmap *map, const void *key, const void *keydata)`:: + + Returns the hashmap entry for the specified key, or NULL if not found. ++ +`map` is the hashmap structure. ++ +`key` is a hashmap_entry structure (or user data structure that starts with +hashmap_entry) that has at least been initialized with the proper hash code +(via `hashmap_entry_init`). ++ +If an entry with matching hash code is found, `key` and `keydata` are passed +to `hashmap_cmp_fn` to decide whether the entry matches the key. + +`void *hashmap_get_next(const struct hashmap *map, const void *entry)`:: + + Returns the next equal hashmap entry, or NULL if not found. This can be + used to iterate over duplicate entries (see `hashmap_add`). ++ +`map` is the hashmap structure. ++ +`entry` is the hashmap_entry to start the search from, obtained via a previous +call to `hashmap_get` or `hashmap_get_next`. + +`void hashmap_add(struct hashmap *map, void *entry)`:: + + Adds a hashmap entry. This allows to add duplicate entries (i.e. + separate values with the same key according to hashmap_cmp_fn). ++ +`map` is the hashmap structure. ++ +`entry` is the entry to add. + +`void *hashmap_put(struct hashmap *map, void *entry)`:: + + Adds or replaces a hashmap entry. If the hashmap contains duplicate + entries equal to the specified entry, only one of them will be replaced. ++ +`map` is the hashmap structure. ++ +`entry` is the entry to add or replace. ++ +Returns the replaced entry, or NULL if not found (i.e. the entry was added). + +`void *hashmap_remove(struct hashmap *map, const void *key, const void *keydata)`:: + + Removes a hashmap entry matching the specified key. If the hashmap + contains duplicate entries equal to the specified key, only one of + them will be removed. ++ +`map` is the hashmap structure. ++ +`key` is a hashmap_entry structure (or user data structure that starts with +hashmap_entry) that has at least been initialized with the proper hash code +(via `hashmap_entry_init`). ++ +If an entry with matching hash code is found, `key` and `keydata` are +passed to `hashmap_cmp_fn` to decide whether the entry matches the key. ++ +Returns the removed entry, or NULL if not found. + +`void hashmap_iter_init(struct hashmap *map, struct hashmap_iter *iter)`:: +`void *hashmap_iter_next(struct hashmap_iter *iter)`:: +`void *hashmap_iter_first(struct hashmap *map, struct hashmap_iter *iter)`:: + + Used to iterate over all entries of a hashmap. ++ +`hashmap_iter_init` initializes a `hashmap_iter` structure. ++ +`hashmap_iter_next` returns the next hashmap_entry, or NULL if there are no +more entries. ++ +`hashmap_iter_first` is a combination of both (i.e. initializes the iterator +and returns the first entry, if any). + +Usage example +------------- + +Here's a simple usage example that maps long keys to double values. +[source,c] +------------ +struct hashmap map; + +struct long2double { + struct hashmap_entry ent; /* must be the first member! */ + long key; + double value; +}; + +static int long2double_cmp(const struct long2double *e1, const struct long2double *e2, const void *unused) +{ + return !(e1->key == e2->key); +} + +void long2double_init(void) +{ + hashmap_init(&map, (hashmap_cmp_fn) long2double_cmp, 0); +} + +void long2double_free(void) +{ + hashmap_free(&map, 1); +} + +static struct long2double *find_entry(long key) +{ + struct long2double k; + hashmap_entry_init(&k, memhash(&key, sizeof(long))); + k.key = key; + return hashmap_get(&map, &k, NULL); +} + +double get_value(long key) +{ + struct long2double *e = find_entry(key); + return e ? e->value : 0; +} + +void set_value(long key, double value) +{ + struct long2double *e = find_entry(key); + if (!e) { + e = malloc(sizeof(struct long2double)); + hashmap_entry_init(e, memhash(&key, sizeof(long))); + e->key = key; + hashmap_add(&map, e); + } + e->value = value; +} +------------ + +Using variable-sized keys +------------------------- + +The `hashmap_entry_get` and `hashmap_entry_remove` functions expect an ordinary +`hashmap_entry` structure as key to find the correct entry. If the key data is +variable-sized (e.g. a FLEX_ARRAY string) or quite large, it is undesirable +to create a full-fledged entry structure on the heap and copy all the key data +into the structure. + +In this case, the `keydata` parameter can be used to pass +variable-sized key data directly to the comparison function, and the `key` +parameter can be a stripped-down, fixed size entry structure allocated on the +stack. + +See test-hashmap.c for an example using arbitrary-length strings as keys. diff --git a/Documentation/technical/api-history-graph.txt b/Documentation/technical/api-history-graph.txt index d6fc90ac7..18142b6d2 100644 --- a/Documentation/technical/api-history-graph.txt +++ b/Documentation/technical/api-history-graph.txt @@ -33,11 +33,11 @@ The following utility functions are wrappers around `graph_next_line()` and They can all be called with a NULL graph argument, in which case no graph output will be printed. -* `graph_show_commit()` calls `graph_next_line()` until it returns non-zero. - This prints all graph lines up to, and including, the line containing this - commit. Output is printed to stdout. The last line printed does not contain - a terminating newline. This should not be called if the commit line has - already been printed, or it will loop forever. +* `graph_show_commit()` calls `graph_next_line()` and + `graph_is_commit_finished()` until one of them return non-zero. This prints + all graph lines up to, and including, the line containing this commit. + Output is printed to stdout. The last line printed does not contain a + terminating newline. * `graph_show_oneline()` calls `graph_next_line()` and prints the result to stdout. The line printed does not contain a terminating newline. diff --git a/Documentation/technical/api-index-skel.txt b/Documentation/technical/api-index-skel.txt index af7cc2e39..eda8c195c 100644 --- a/Documentation/technical/api-index-skel.txt +++ b/Documentation/technical/api-index-skel.txt @@ -1,7 +1,7 @@ -GIT API Documents +Git API Documents ================= -GIT has grown a set of internal API over time. This collection +Git has grown a set of internal API over time. This collection documents them. //////////////////////////////////////////////////////////////// @@ -11,5 +11,3 @@ documents them. //////////////////////////////////////////////////////////////// // table of contents end //////////////////////////////////////////////////////////////// - -2007-11-24 diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt index f6a4a361b..be50cf4de 100644 --- a/Documentation/technical/api-parse-options.txt +++ b/Documentation/technical/api-parse-options.txt @@ -1,7 +1,7 @@ parse-options API ================= -The parse-options API is used to parse and massage options in git +The parse-options API is used to parse and massage options in Git and to provide a usage help with consistent look. Basics @@ -21,7 +21,7 @@ that allow to change the behavior of a command. * There are basically two forms of options: 'Short options' consist of one dash (`-`) and one alphanumeric character. - 'Long options' begin with two dashes (`\--`) and some + 'Long options' begin with two dashes (`--`) and some alphanumeric characters. * Options are case-sensitive. @@ -29,9 +29,9 @@ that allow to change the behavior of a command. The parse-options API allows: -* 'sticked' and 'separate form' of options with arguments. - `-oArg` is sticked, `-o Arg` is separate form. - `\--option=Arg` is sticked, `\--option Arg` is separate form. +* 'stuck' and 'separate form' of options with arguments. + `-oArg` is stuck, `-o Arg` is separate form. + `--option=Arg` is stuck, `--option Arg` is separate form. * Long options may be 'abbreviated', as long as the abbreviation is unambiguous. @@ -39,11 +39,14 @@ The parse-options API allows: * Short options may be bundled, e.g. `-a -b` can be specified as `-ab`. * Boolean long options can be 'negated' (or 'unset') by prepending - `no-`, e.g. `\--no-abbrev` instead of `\--abbrev`. + `no-`, e.g. `--no-abbrev` instead of `--abbrev`. Conversely, + options that begin with `no-` can be 'negated' by removing it. + Other long options can be unset (e.g., set string to NULL, set + integer to 0) by prepending `no-`. -* Options and non-option arguments can clearly be separated using the `\--` - option, e.g. `-a -b \--option \-- \--this-is-a-file` indicates that - `\--this-is-a-file` must not be processed as an option. +* Options and non-option arguments can clearly be separated using the `--` + option, e.g. `-a -b --option -- --this-is-a-file` indicates that + `--this-is-a-file` must not be processed as an option. Steps to parse options ---------------------- @@ -75,7 +78,7 @@ before the full parser, which in turn shows the full help message. Flags are the bitwise-or of: `PARSE_OPT_KEEP_DASHDASH`:: - Keep the `\--` that usually separates options from + Keep the `--` that usually separates options from non-option arguments. `PARSE_OPT_STOP_AT_NON_OPTION`:: @@ -113,31 +116,36 @@ say `static struct option builtin_add_options[]`. There are some macros to easily define options: `OPT__ABBREV(&int_var)`:: - Add `\--abbrev[=<n>]`. + Add `--abbrev[=<n>]`. `OPT__COLOR(&int_var, description)`:: - Add `\--color[=<when>]` and `--no-color`. + Add `--color[=<when>]` and `--no-color`. `OPT__DRY_RUN(&int_var, description)`:: - Add `-n, \--dry-run`. + Add `-n, --dry-run`. `OPT__FORCE(&int_var, description)`:: - Add `-f, \--force`. + Add `-f, --force`. `OPT__QUIET(&int_var, description)`:: - Add `-q, \--quiet`. + Add `-q, --quiet`. `OPT__VERBOSE(&int_var, description)`:: - Add `-v, \--verbose`. + Add `-v, --verbose`. `OPT_GROUP(description)`:: Start an option group. `description` is a short string that describes the group or an empty string. Start the description with an upper-case letter. -`OPT_BOOLEAN(short, long, &int_var, description)`:: - Introduce a boolean option. - `int_var` is incremented on each use. +`OPT_BOOL(short, long, &int_var, description)`:: + Introduce a boolean option. `int_var` is set to one with + `--option` and set to zero with `--no-option`. + +`OPT_COUNTUP(short, long, &int_var, description)`:: + Introduce a count-up option. + `int_var` is incremented on each use of `--option`, and + reset to zero with `--no-option`. `OPT_BIT(short, long, &int_var, description, mask)`:: Introduce a boolean option. @@ -148,8 +156,9 @@ There are some macros to easily define options: If used, `int_var` is bitwise-anded with the inverted `mask`. `OPT_SET_INT(short, long, &int_var, description, integer)`:: - Introduce a boolean option. - If used, set `int_var` to `integer`. + Introduce an integer option. + `int_var` is set to `integer` with `--option`, and + reset to zero with `--no-option`. `OPT_SET_PTR(short, long, &ptr_var, description, ptr)`:: Introduce a boolean option. @@ -167,6 +176,10 @@ There are some macros to easily define options: Introduce an option with date argument, see `approxidate()`. The timestamp is put into `int_var`. +`OPT_EXPIRY_DATE(short, long, &int_var, description)`:: + Introduce an option with expiry date argument, see `parse_expiry_date()`. + The timestamp is put into `int_var`. + `OPT_CALLBACK(short, long, &var, arg_str, description, func_ptr)`:: Introduce an option with argument. The argument will be fed into the function given by `func_ptr` @@ -198,16 +211,21 @@ There are some macros to easily define options: "auto", set `int_var` to 1 if stdout is a tty or a pager, 0 otherwise. +`OPT_NOOP_NOARG(short, long)`:: + Introduce an option that has no effect and takes no arguments. + Use it to hide deprecated options that are still to be recognized + and ignored silently. + The last element of the array must be `OPT_END()`. If not stated otherwise, interpret the arguments as follows: * `short` is a character for the short option - (e.g. `{apostrophe}e{apostrophe}` for `-e`, use `0` to omit), + (e.g. `'e'` for `-e`, use `0` to omit), * `long` is a string for the long option - (e.g. `"example"` for `\--example`, use `NULL` to omit), + (e.g. `"example"` for `--example`, use `NULL` to omit), * `int_var` is an integer variable, @@ -231,10 +249,10 @@ The function must be defined in this form: The callback mechanism is as follows: * Inside `func`, the only interesting member of the structure - given by `opt` is the void pointer `opt\->value`. - `\*opt\->value` will be the value that is saved into `var`, if you + given by `opt` is the void pointer `opt->value`. + `*opt->value` will be the value that is saved into `var`, if you use `OPT_CALLBACK()`. - For example, do `*(unsigned long *)opt\->value = 42;` to get 42 + For example, do `*(unsigned long *)opt->value = 42;` to get 42 into an `unsigned long` variable. * Return value `0` indicates success and non-zero return @@ -257,10 +275,10 @@ Examples -------- See `test-parse-options.c` and -`builtin-add.c`, -`builtin-clone.c`, -`builtin-commit.c`, -`builtin-fetch.c`, -`builtin-fsck.c`, -`builtin-rm.c` +`builtin/add.c`, +`builtin/clone.c`, +`builtin/commit.c`, +`builtin/fetch.c`, +`builtin/fsck.c`, +`builtin/rm.c` for real-world examples. diff --git a/Documentation/technical/api-ref-iteration.txt b/Documentation/technical/api-ref-iteration.txt index dbbea95db..02adfd45d 100644 --- a/Documentation/technical/api-ref-iteration.txt +++ b/Documentation/technical/api-ref-iteration.txt @@ -35,7 +35,7 @@ Iteration functions * `head_ref_submodule()`, `for_each_ref_submodule()`, `for_each_ref_in_submodule()`, `for_each_tag_ref_submodule()`, `for_each_branch_ref_submodule()`, `for_each_remote_ref_submodule()` - do the same as the functions descibed above but for a specified + do the same as the functions described above but for a specified submodule. * `for_each_rawref()` can be used to learn about broken ref and symref. @@ -50,10 +50,10 @@ submodules object database. You can do this by a code-snippet like this: const char *path = "path/to/submodule" - if (!add_submodule_odb(path)) + if (add_submodule_odb(path)) die("Error submodule '%s' not populated.", path); -`add_submodule_odb()` will return an non-zero value on success. If you +`add_submodule_odb()` will return zero on success. If you do not do this you will get an error for each ref that it does not point to a valid object. diff --git a/Documentation/technical/api-remote.txt b/Documentation/technical/api-remote.txt index c54b17db6..5d245aa9d 100644 --- a/Documentation/technical/api-remote.txt +++ b/Documentation/technical/api-remote.txt @@ -3,7 +3,7 @@ Remotes configuration API The API in remote.h gives access to the configuration related to remotes. It handles all three configuration mechanisms historically -and currently used by git, and presents the information in a uniform +and currently used by Git, and presents the information in a uniform fashion. Note that the code also handles plain URLs without any configuration, giving them just the default information. @@ -45,7 +45,7 @@ struct remote `receivepack`, `uploadpack`:: The configured helper programs to run on the remote side, for - git-native protocols. + Git-native protocols. `http_proxy`:: @@ -58,16 +58,16 @@ default remote, given the current branch and configuration. struct refspec -------------- -A struct refspec holds the parsed interpretation of a refspec. If it -will force updates (starts with a '+'), force is true. If it is a -pattern (sides end with '*') pattern is true. src and dest are the two -sides (if a pattern, only the part outside of the wildcards); if there -is only one side, it is src, and dst is NULL; if sides exist but are -empty (i.e., the refspec either starts or ends with ':'), the -corresponding side is "". +A struct refspec holds the parsed interpretation of a refspec. If it +will force updates (starts with a '+'), force is true. If it is a +pattern (sides end with '*') pattern is true. src and dest are the +two sides (including '*' characters if present); if there is only one +side, it is src, and dst is NULL; if sides exist but are empty (i.e., +the refspec either starts or ends with ':'), the corresponding side is +"". -This parsing can be done to an array of strings to give an array of -struct refpsecs with parse_ref_spec(). +An array of strings can be parsed into an array of struct refspecs +using parse_fetch_refspec() or parse_push_refspec(). remote_find_tracking(), given a remote and a struct refspec with either src or dst filled out, will fill out the other such that the diff --git a/Documentation/technical/api-revision-walking.txt b/Documentation/technical/api-revision-walking.txt index 996da0503..55b878ade 100644 --- a/Documentation/technical/api-revision-walking.txt +++ b/Documentation/technical/api-revision-walking.txt @@ -56,6 +56,11 @@ function. returning a `struct commit *` each time you call it. The end of the revision list is indicated by returning a NULL pointer. +`reset_revision_walk`:: + + Reset the flags used by the revision walking api. You can use + this to do multiple sequential revision walks. + Data structures --------------- diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt index f18b4f481..5d7d7f2d3 100644 --- a/Documentation/technical/api-run-command.txt +++ b/Documentation/technical/api-run-command.txt @@ -55,10 +55,8 @@ The functions above do the following: non-zero. . If the program terminated due to a signal, then the return value is the - signal number - 128, ie. it is negative and so indicates an unusual - condition; a diagnostic is printed. This return value can be passed to - exit(2), which will report the same code to the parent process that a - POSIX shell's $? would report for a program that died from the signal. + signal number + 128, ie. the same value that a POSIX shell's $? would + report. A diagnostic is printed. `start_async`:: diff --git a/Documentation/technical/api-setup.txt b/Documentation/technical/api-setup.txt index 4f63a04d7..540e45568 100644 --- a/Documentation/technical/api-setup.txt +++ b/Documentation/technical/api-setup.txt @@ -8,6 +8,42 @@ Talk about * is_inside_git_dir() * is_inside_work_tree() * setup_work_tree() -* get_pathspec() (Dscho) + +Pathspec +-------- + +See glossary-context.txt for the syntax of pathspec. In memory, a +pathspec set is represented by "struct pathspec" and is prepared by +parse_pathspec(). This function takes several arguments: + +- magic_mask specifies what features that are NOT supported by the + following code. If a user attempts to use such a feature, + parse_pathspec() can reject it early. + +- flags specifies other things that the caller wants parse_pathspec to + perform. + +- prefix and args come from cmd_* functions + +get_pathspec() is obsolete and should never be used in new code. + +parse_pathspec() helps catch unsupported features and reject them +politely. At a lower level, different pathspec-related functions may +not support the same set of features. Such pathspec-sensitive +functions are guarded with GUARD_PATHSPEC(), which will die in an +unfriendly way when an unsupported feature is requested. + +The command designers are supposed to make sure that GUARD_PATHSPEC() +never dies. They have to make sure all unsupported features are caught +by parse_pathspec(), not by GUARD_PATHSPEC. grepping GUARD_PATHSPEC() +should give the designers all pathspec-sensitive codepaths and what +features they support. + +A similar process is applied when a new pathspec magic is added. The +designer lifts the GUARD_PATHSPEC restriction in the functions that +support the new magic. At the same time (s)he has to make sure this +new feature will be caught at parse_pathspec() in commands that cannot +handle the new magic in some cases. grepping parse_pathspec() should +help. diff --git a/Documentation/technical/api-sha1-array.txt b/Documentation/technical/api-sha1-array.txt new file mode 100644 index 000000000..3e75497a3 --- /dev/null +++ b/Documentation/technical/api-sha1-array.txt @@ -0,0 +1,76 @@ +sha1-array API +============== + +The sha1-array API provides storage and manipulation of sets of SHA-1 +identifiers. The emphasis is on storage and processing efficiency, +making them suitable for large lists. Note that the ordering of items is +not preserved over some operations. + +Data Structures +--------------- + +`struct sha1_array`:: + + A single array of SHA-1 hashes. This should be initialized by + assignment from `SHA1_ARRAY_INIT`. The `sha1` member contains + the actual data. The `nr` member contains the number of items in + the set. The `alloc` and `sorted` members are used internally, + and should not be needed by API callers. + +Functions +--------- + +`sha1_array_append`:: + Add an item to the set. The sha1 will be placed at the end of + the array (but note that some operations below may lose this + ordering). + +`sha1_array_lookup`:: + Perform a binary search of the array for a specific sha1. + If found, returns the offset (in number of elements) of the + sha1. If not found, returns a negative integer. If the array is + not sorted, this function has the side effect of sorting it. + +`sha1_array_clear`:: + Free all memory associated with the array and return it to the + initial, empty state. + +`sha1_array_for_each_unique`:: + Efficiently iterate over each unique element of the list, + executing the callback function for each one. If the array is + not sorted, this function has the side effect of sorting it. + +Examples +-------- + +----------------------------------------- +void print_callback(const unsigned char sha1[20], + void *data) +{ + printf("%s\n", sha1_to_hex(sha1)); +} + +void some_func(void) +{ + struct sha1_array hashes = SHA1_ARRAY_INIT; + unsigned char sha1[20]; + + /* Read objects into our set */ + while (read_object_from_stdin(sha1)) + sha1_array_append(&hashes, sha1); + + /* Check if some objects are in our set */ + while (read_object_from_stdin(sha1)) { + if (sha1_array_lookup(&hashes, sha1) >= 0) + printf("it's in there!\n"); + + /* + * Print the unique set of objects. We could also have + * avoided adding duplicate objects in the first place, + * but we would end up re-sorting the array repeatedly. + * Instead, this will sort once and then skip duplicates + * in linear time. + */ + sha1_array_for_each_unique(&hashes, print_callback, NULL); +} +----------------------------------------- diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt index afe275995..3350d97dd 100644 --- a/Documentation/technical/api-strbuf.txt +++ b/Documentation/technical/api-strbuf.txt @@ -156,6 +156,11 @@ then they will free() it. Remove the bytes between `pos..pos+len` and replace it with the given data. +`strbuf_add_commented_lines`:: + + Add a NUL-terminated string to the buffer. Each line will be prepended + by a comment character and a blank. + `strbuf_add`:: Add data of given length to the buffer. @@ -225,10 +230,20 @@ which can be used by the programmer of the callback as she sees fit. destination. This is useful for literal data to be fed to either strbuf_expand or to the *printf family of functions. +`strbuf_humanise_bytes`:: + + Append the given byte size as a human-readable string (i.e. 12.23 KiB, + 3.50 MiB). + `strbuf_addf`:: Add a formatted string to the buffer. +`strbuf_commented_addf`:: + + Add a formatted string prepended by a comment character and a + blank to the buffer. + `strbuf_fread`:: Read a given size of data from a FILE* pointer to the buffer. @@ -255,14 +270,46 @@ same behaviour as well. `strbuf_getline`:: - Read a line from a FILE* pointer. The second argument specifies the line + Read a line from a FILE *, overwriting the existing contents + of the strbuf. The second argument specifies the line terminator character, typically `'\n'`. + Reading stops after the terminator or at EOF. The terminator + is removed from the buffer before returning. Returns 0 unless + there was nothing left before EOF, in which case it returns `EOF`. + +`strbuf_getwholeline`:: + + Like `strbuf_getline`, but keeps the trailing terminator (if + any) in the buffer. + +`strbuf_getwholeline_fd`:: + + Like `strbuf_getwholeline`, but operates on a file descriptor. + It reads one character at a time, so it is very slow. Do not + use it unless you need the correct position in the file + descriptor. `stripspace`:: Strip whitespace from a buffer. The second parameter controls if comments are considered contents to be removed or not. +`strbuf_split_buf`:: +`strbuf_split_str`:: +`strbuf_split_max`:: +`strbuf_split`:: + + Split a string or strbuf into a list of strbufs at a specified + terminator character. The returned substrings include the + terminator characters. Some of these functions take a `max` + parameter, which, if positive, limits the output to that + number of substrings. + +`strbuf_list_free`:: + + Free a list of strbufs (for example, the return values of the + `strbuf_split()` functions). + `launch_editor`:: Launch the user preferred editor to edit a file and fill the buffer diff --git a/Documentation/technical/api-string-list.txt b/Documentation/technical/api-string-list.txt index 3f575bdcf..20be34883 100644 --- a/Documentation/technical/api-string-list.txt +++ b/Documentation/technical/api-string-list.txt @@ -1,8 +1,9 @@ string-list API =============== -The string_list API offers a data structure and functions to handle sorted -and unsorted string lists. +The string_list API offers a data structure and functions to handle +sorted and unsorted string lists. A "sorted" list is one whose +entries are sorted by string value in `strcmp()` order. The 'string_list' struct used to be called 'path_list', but was renamed because it is not specific to paths. @@ -20,8 +21,9 @@ If you need something advanced, you can manually malloc() the `items` member (you need this if you add things later) and you should set the `nr` and `alloc` members in that case, too. -. Adds new items to the list, using `string_list_append` or - `string_list_insert`. +. Adds new items to the list, using `string_list_append`, + `string_list_append_nodup`, `string_list_insert`, + `string_list_split`, and/or `string_list_split_in_place`. . Can check if a string is in the list using `string_list_has_string` or `unsorted_string_list_has_string` and get it from the list using @@ -29,15 +31,24 @@ member (you need this if you add things later) and you should set the . Can sort an unsorted list using `sort_string_list`. +. Can remove duplicate items from a sorted list using + `string_list_remove_duplicates`. + +. Can remove individual items of an unsorted list using + `unsorted_string_list_delete_item`. + +. Can remove items not matching a criterion from a sorted or unsorted + list using `filter_string_list`, or remove empty strings using + `string_list_remove_empty_items`. + . Finally it should free the list using `string_list_clear`. Example: ---- -struct string_list list; +struct string_list list = STRING_LIST_INIT_NODUP; int i; -memset(&list, 0, sizeof(struct string_list)); string_list_append(&list, "foo"); string_list_append(&list, "bar"); for (i = 0; i < list.nr; i++) @@ -57,6 +68,20 @@ Functions * General ones (works with sorted and unsorted lists as well) +`filter_string_list`:: + + Apply a function to each item in a list, retaining only the + items for which the function returns true. If free_util is + true, call free() on the util members of any items that have + to be deleted. Preserve the order of the items that are + retained. + +`string_list_remove_empty_items`:: + + Remove any empty strings from the list. If free_util is true, + call free() on the util members of any items that have to be + deleted. Preserve the order of the items that are retained. + `print_string_list`:: Dump a string_list to stdout, useful mainly for debugging purposes. It @@ -80,7 +105,9 @@ Functions Insert a new element to the string_list. The returned pointer can be handy if you want to write something to the `util` pointer of the - string_list_item containing the just added string. + string_list_item containing the just added string. If the given + string already exists the insertion will be skipped and the + pointer to the existing item returned. + Since this function uses xrealloc() (which die()s if it fails) if the list needs to grow, it is safe not to check the pointer. I.e. you may @@ -91,15 +118,32 @@ write `string_list_insert(...)->util = ...;`. Look up a given string in the string_list, returning the containing string_list_item. If the string is not found, NULL is returned. +`string_list_remove_duplicates`:: + + Remove all but the first of consecutive entries that have the + same string value. If free_util is true, call free() on the + util members of any items that have to be deleted. + * Functions for unsorted lists only `string_list_append`:: - Append a new string to the end of the string_list. + Append a new string to the end of the string_list. If + `strdup_string` is set, then the string argument is copied; + otherwise the new `string_list_entry` refers to the input + string. + +`string_list_append_nodup`:: + + Append a new string to the end of the string_list. The new + `string_list_entry` always refers to the input string, even if + `strdup_string` is set. This function can be used to hand + ownership of a malloc()ed string to a `string_list` that has + `strdup_string` set. `sort_string_list`:: - Make an unsorted list sorted. + Sort the list's entries by string value in `strcmp()` order. `unsorted_string_list_has_string`:: @@ -112,6 +156,32 @@ write `string_list_insert(...)->util = ...;`. The above two functions need to look through all items, as opposed to their counterpart for sorted lists, which performs a binary search. +`unsorted_string_list_delete_item`:: + + Remove an item from a string_list. The `string` pointer of the items + will be freed in case the `strdup_strings` member of the string_list + is set. The third parameter controls if the `util` pointer of the + items should be freed or not. + +`string_list_split`:: +`string_list_split_in_place`:: + + Split a string into substrings on a delimiter character and + append the substrings to a `string_list`. If `maxsplit` is + non-negative, then split at most `maxsplit` times. Return the + number of substrings appended to the list. ++ +`string_list_split` requires a `string_list` that has `strdup_strings` +set to true; it leaves the input string untouched and makes copies of +the substrings in newly-allocated memory. +`string_list_split_in_place` requires a `string_list` that has +`strdup_strings` set to false; it splits the input string in place, +overwriting the delimiter characters with NULs and creating new +string_list_items that point into the original string (the original +string must therefore not be modified or freed while the `string_list` +is in use). + + Data structures --------------- diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt new file mode 100644 index 000000000..544373b16 --- /dev/null +++ b/Documentation/technical/http-protocol.txt @@ -0,0 +1,506 @@ +HTTP transfer protocols +======================= + +Git supports two HTTP based transfer protocols. A "dumb" protocol +which requires only a standard HTTP server on the server end of the +connection, and a "smart" protocol which requires a Git aware CGI +(or server module). This document describes both protocols. + +As a design feature smart clients can automatically upgrade "dumb" +protocol URLs to smart URLs. This permits all users to have the +same published URL, and the peers automatically select the most +efficient transport available to them. + + +URL Format +---------- + +URLs for Git repositories accessed by HTTP use the standard HTTP +URL syntax documented by RFC 1738, so they are of the form: + + http://<host>:<port>/<path>?<searchpart> + +Within this documentation the placeholder `$GIT_URL` will stand for +the http:// repository URL entered by the end-user. + +Servers SHOULD handle all requests to locations matching `$GIT_URL`, as +both the "smart" and "dumb" HTTP protocols used by Git operate +by appending additional path components onto the end of the user +supplied `$GIT_URL` string. + +An example of a dumb client requesting for a loose object: + + $GIT_URL: http://example.com:8080/git/repo.git + URL request: http://example.com:8080/git/repo.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355 + +An example of a smart request to a catch-all gateway: + + $GIT_URL: http://example.com/daemon.cgi?svc=git&q= + URL request: http://example.com/daemon.cgi?svc=git&q=/info/refs&service=git-receive-pack + +An example of a request to a submodule: + + $GIT_URL: http://example.com/git/repo.git/path/submodule.git + URL request: http://example.com/git/repo.git/path/submodule.git/info/refs + +Clients MUST strip a trailing `/`, if present, from the user supplied +`$GIT_URL` string to prevent empty path tokens (`//`) from appearing +in any URL sent to a server. Compatible clients MUST expand +`$GIT_URL/info/refs` as `foo/info/refs` and not `foo//info/refs`. + + +Authentication +-------------- + +Standard HTTP authentication is used if authentication is required +to access a repository, and MAY be configured and enforced by the +HTTP server software. + +Because Git repositories are accessed by standard path components +server administrators MAY use directory based permissions within +their HTTP server to control repository access. + +Clients SHOULD support Basic authentication as described by RFC 2616. +Servers SHOULD support Basic authentication by relying upon the +HTTP server placed in front of the Git server software. + +Servers SHOULD NOT require HTTP cookies for the purposes of +authentication or access control. + +Clients and servers MAY support other common forms of HTTP based +authentication, such as Digest authentication. + + +SSL +--- + +Clients and servers SHOULD support SSL, particularly to protect +passwords when relying on Basic HTTP authentication. + + +Session State +------------- + +The Git over HTTP protocol (much like HTTP itself) is stateless +from the perspective of the HTTP server side. All state MUST be +retained and managed by the client process. This permits simple +round-robin load-balancing on the server side, without needing to +worry about state management. + +Clients MUST NOT require state management on the server side in +order to function correctly. + +Servers MUST NOT require HTTP cookies in order to function correctly. +Clients MAY store and forward HTTP cookies during request processing +as described by RFC 2616 (HTTP/1.1). Servers SHOULD ignore any +cookies sent by a client. + + +General Request Processing +-------------------------- + +Except where noted, all standard HTTP behavior SHOULD be assumed +by both client and server. This includes (but is not necessarily +limited to): + +If there is no repository at `$GIT_URL`, or the resource pointed to by a +location matching `$GIT_URL` does not exist, the server MUST NOT respond +with `200 OK` response. A server SHOULD respond with +`404 Not Found`, `410 Gone`, or any other suitable HTTP status code +which does not imply the resource exists as requested. + +If there is a repository at `$GIT_URL`, but access is not currently +permitted, the server MUST respond with the `403 Forbidden` HTTP +status code. + +Servers SHOULD support both HTTP 1.0 and HTTP 1.1. +Servers SHOULD support chunked encoding for both request and response +bodies. + +Clients SHOULD support both HTTP 1.0 and HTTP 1.1. +Clients SHOULD support chunked encoding for both request and response +bodies. + +Servers MAY return ETag and/or Last-Modified headers. + +Clients MAY revalidate cached entities by including If-Modified-Since +and/or If-None-Match request headers. + +Servers MAY return `304 Not Modified` if the relevant headers appear +in the request and the entity has not changed. Clients MUST treat +`304 Not Modified` identical to `200 OK` by reusing the cached entity. + +Clients MAY reuse a cached entity without revalidation if the +Cache-Control and/or Expires header permits caching. Clients and +servers MUST follow RFC 2616 for cache controls. + + +Discovering References +---------------------- + +All HTTP clients MUST begin either a fetch or a push exchange by +discovering the references available on the remote repository. + +Dumb Clients +~~~~~~~~~~~~ + +HTTP clients that only support the "dumb" protocol MUST discover +references by making a request for the special info/refs file of +the repository. + +Dumb HTTP clients MUST make a `GET` request to `$GIT_URL/info/refs`, +without any search/query parameters. + + C: GET $GIT_URL/info/refs HTTP/1.0 + + S: 200 OK + S: + S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint + S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master + S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0 + S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{} + +The Content-Type of the returned info/refs entity SHOULD be +`text/plain; charset=utf-8`, but MAY be any content type. +Clients MUST NOT attempt to validate the returned Content-Type. +Dumb servers MUST NOT return a return type starting with +`application/x-git-`. + +Cache-Control headers MAY be returned to disable caching of the +returned entity. + +When examining the response clients SHOULD only examine the HTTP +status code. Valid responses are `200 OK`, or `304 Not Modified`. + +The returned content is a UNIX formatted text file describing +each ref and its known value. The file SHOULD be sorted by name +according to the C locale ordering. The file SHOULD NOT include +the default ref named `HEAD`. + + info_refs = *( ref_record ) + ref_record = any_ref / peeled_ref + + any_ref = obj-id HTAB refname LF + peeled_ref = obj-id HTAB refname LF + obj-id HTAB refname "^{}" LF + +Smart Clients +~~~~~~~~~~~~~ + +HTTP clients that support the "smart" protocol (or both the +"smart" and "dumb" protocols) MUST discover references by making +a parameterized request for the info/refs file of the repository. + +The request MUST contain exactly one query parameter, +`service=$servicename`, where `$servicename` MUST be the service +name the client wishes to contact to complete the operation. +The request MUST NOT contain additional query parameters. + + C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0 + +dumb server reply: + + S: 200 OK + S: + S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint + S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master + S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0 + S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{} + +smart server reply: + + S: 200 OK + S: Content-Type: application/x-git-upload-pack-advertisement + S: Cache-Control: no-cache + S: + S: 001e# service=git-upload-pack\n + S: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0multi_ack\n + S: 0042d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n + S: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n + S: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n + +Dumb Server Response +^^^^^^^^^^^^^^^^^^^^ +Dumb servers MUST respond with the dumb server reply format. + +See the prior section under dumb clients for a more detailed +description of the dumb server response. + +Smart Server Response +^^^^^^^^^^^^^^^^^^^^^ +If the server does not recognize the requested service name, or the +requested service name has been disabled by the server administrator, +the server MUST respond with the `403 Forbidden` HTTP status code. + +Otherwise, smart servers MUST respond with the smart server reply +format for the requested service name. + +Cache-Control headers SHOULD be used to disable caching of the +returned entity. + +The Content-Type MUST be `application/x-$servicename-advertisement`. +Clients SHOULD fall back to the dumb protocol if another content +type is returned. When falling back to the dumb protocol clients +SHOULD NOT make an additional request to `$GIT_URL/info/refs`, but +instead SHOULD use the response already in hand. Clients MUST NOT +continue if they do not support the dumb protocol. + +Clients MUST validate the status code is either `200 OK` or +`304 Not Modified`. + +Clients MUST validate the first five bytes of the response entity +matches the regex `^[0-9a-f]{4}#`. If this test fails, clients +MUST NOT continue. + +Clients MUST parse the entire response as a sequence of pkt-line +records. + +Clients MUST verify the first pkt-line is `# service=$servicename`. +Servers MUST set $servicename to be the request parameter value. +Servers SHOULD include an LF at the end of this line. +Clients MUST ignore an LF at the end of the line. + +Servers MUST terminate the response with the magic `0000` end +pkt-line marker. + +The returned response is a pkt-line stream describing each ref and +its known value. The stream SHOULD be sorted by name according to +the C locale ordering. The stream SHOULD include the default ref +named `HEAD` as the first ref. The stream MUST include capability +declarations behind a NUL on the first ref. + + smart_reply = PKT-LINE("# service=$servicename" LF) + ref_list + "0000" + ref_list = empty_list / non_empty_list + + empty_list = PKT-LINE(zero-id SP "capabilities^{}" NUL cap-list LF) + + non_empty_list = PKT-LINE(obj-id SP name NUL cap_list LF) + *ref_record + + cap-list = capability *(SP capability) + capability = 1*(LC_ALPHA / DIGIT / "-" / "_") + LC_ALPHA = %x61-7A + + ref_record = any_ref / peeled_ref + any_ref = PKT-LINE(obj-id SP name LF) + peeled_ref = PKT-LINE(obj-id SP name LF) + PKT-LINE(obj-id SP name "^{}" LF + + +Smart Service git-upload-pack +------------------------------ +This service reads from the repository pointed to by `$GIT_URL`. + +Clients MUST first perform ref discovery with +`$GIT_URL/info/refs?service=git-upload-pack`. + + C: POST $GIT_URL/git-upload-pack HTTP/1.0 + C: Content-Type: application/x-git-upload-pack-request + C: + C: 0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7\n + C: 0032have 441b40d833fdfa93eb2908e52742248faf0ee993\n + C: 0000 + + S: 200 OK + S: Content-Type: application/x-git-upload-pack-result + S: Cache-Control: no-cache + S: + S: ....ACK %s, continue + S: ....NAK + +Clients MUST NOT reuse or revalidate a cached response. +Servers MUST include sufficient Cache-Control headers +to prevent caching of the response. + +Servers SHOULD support all capabilities defined here. + +Clients MUST send at least one "want" command in the request body. +Clients MUST NOT reference an id in a "want" command which did not +appear in the response obtained through ref discovery unless the +server advertises capability `allow-tip-sha1-in-want`. + + compute_request = want_list + have_list + request_end + request_end = "0000" / "done" + + want_list = PKT-LINE(want NUL cap_list LF) + *(want_pkt) + want_pkt = PKT-LINE(want LF) + want = "want" SP id + cap_list = *(SP capability) SP + + have_list = *PKT-LINE("have" SP id LF) + +TODO: Document this further. + +The Negotiation Algorithm +~~~~~~~~~~~~~~~~~~~~~~~~~ +The computation to select the minimal pack proceeds as follows +(C = client, S = server): + +'init step:' + +C: Use ref discovery to obtain the advertised refs. + +C: Place any object seen into set `advertised`. + +C: Build an empty set, `common`, to hold the objects that are later + determined to be on both ends. + +C: Build a set, `want`, of the objects from `advertised` the client + wants to fetch, based on what it saw during ref discovery. + +C: Start a queue, `c_pending`, ordered by commit time (popping newest + first). Add all client refs. When a commit is popped from + the queue its parents SHOULD be automatically inserted back. + Commits MUST only enter the queue once. + +'one compute step:' + +C: Send one `$GIT_URL/git-upload-pack` request: + + C: 0032want <want #1>............................... + C: 0032want <want #2>............................... + .... + C: 0032have <common #1>............................. + C: 0032have <common #2>............................. + .... + C: 0032have <have #1>............................... + C: 0032have <have #2>............................... + .... + C: 0000 + +The stream is organized into "commands", with each command +appearing by itself in a pkt-line. Within a command line +the text leading up to the first space is the command name, +and the remainder of the line to the first LF is the value. +Command lines are terminated with an LF as the last byte of +the pkt-line value. + +Commands MUST appear in the following order, if they appear +at all in the request stream: + +* "want" +* "have" + +The stream is terminated by a pkt-line flush (`0000`). + +A single "want" or "have" command MUST have one hex formatted +SHA-1 as its value. Multiple SHA-1s MUST be sent by sending +multiple commands. + +The `have` list is created by popping the first 32 commits +from `c_pending`. Less can be supplied if `c_pending` empties. + +If the client has sent 256 "have" commits and has not yet +received one of those back from `s_common`, or the client has +emptied `c_pending` it SHOULD include a "done" command to let +the server know it won't proceed: + + C: 0009done + +S: Parse the git-upload-pack request: + +Verify all objects in `want` are directly reachable from refs. + +The server MAY walk backwards through history or through +the reflog to permit slightly stale requests. + +If no "want" objects are received, send an error: +TODO: Define error if no "want" lines are requested. + +If any "want" object is not reachable, send an error: +TODO: Define error if an invalid "want" is requested. + +Create an empty list, `s_common`. + +If "have" was sent: + +Loop through the objects in the order supplied by the client. + +For each object, if the server has the object reachable from +a ref, add it to `s_common`. If a commit is added to `s_common`, +do not add any ancestors, even if they also appear in `have`. + +S: Send the git-upload-pack response: + +If the server has found a closed set of objects to pack or the +request ends with "done", it replies with the pack. +TODO: Document the pack based response + + S: PACK... + +The returned stream is the side-band-64k protocol supported +by the git-upload-pack service, and the pack is embedded into +stream 1. Progress messages from the server side MAY appear +in stream 2. + +Here a "closed set of objects" is defined to have at least +one path from every "want" to at least one "common" object. + +If the server needs more information, it replies with a +status continue response: +TODO: Document the non-pack response + +C: Parse the upload-pack response: + TODO: Document parsing response + +'Do another compute step.' + + +Smart Service git-receive-pack +------------------------------ +This service reads from the repository pointed to by `$GIT_URL`. + +Clients MUST first perform ref discovery with +`$GIT_URL/info/refs?service=git-receive-pack`. + + C: POST $GIT_URL/git-receive-pack HTTP/1.0 + C: Content-Type: application/x-git-receive-pack-request + C: + C: ....0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\0 report-status + C: 0000 + C: PACK.... + + S: 200 OK + S: Content-Type: application/x-git-receive-pack-result + S: Cache-Control: no-cache + S: + S: .... + +Clients MUST NOT reuse or revalidate a cached response. +Servers MUST include sufficient Cache-Control headers +to prevent caching of the response. + +Servers SHOULD support all capabilities defined here. + +Clients MUST send at least one command in the request body. +Within the command portion of the request body clients SHOULD send +the id obtained through ref discovery as old_id. + + update_request = command_list + "PACK" <binary data> + + command_list = PKT-LINE(command NUL cap_list LF) + *(command_pkt) + command_pkt = PKT-LINE(command LF) + cap_list = *(SP capability) SP + + command = create / delete / update + create = zero-id SP new_id SP name + delete = old_id SP zero-id SP name + update = old_id SP new_id SP name + +TODO: Document this further. + + +References +---------- + +link:http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)] +link:http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1] +link:technical/pack-protocol.html +link:technical/protocol-capabilities.html diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index 8930b3fab..f352a9b22 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -1,7 +1,7 @@ -GIT index format +Git index format ================ -= The git index file has the following format +== The Git index file has the following format All binary numbers are in network byte order. Version 2 is described here unless stated otherwise. @@ -12,7 +12,7 @@ GIT index format The signature is { 'D', 'I', 'R', 'C' } (stands for "dircache") 4-byte version number: - The current supported versions are 2 and 3. + The current supported versions are 2, 3 and 4. 32-bit number of index entries. @@ -21,9 +21,9 @@ GIT index format - Extensions Extensions are identified by signature. Optional extensions can - be ignored if GIT does not understand them. + be ignored if Git does not understand them. - GIT currently supports cached tree and resolve undo extensions. + Git currently supports cached tree and resolve undo extensions. 4-byte extension signature. If the first byte is 'A'..'Z' the extension is optional and can be ignored. @@ -93,8 +93,8 @@ GIT index format 12-bit name length if the length is less than 0xFFF; otherwise 0xFFF is stored in this field. - (Version 3) A 16-bit field, only applicable if the "extended flag" - above is 1, split into (high to low bits). + (Version 3 or later) A 16-bit field, only applicable if the + "extended flag" above is 1, split into (high to low bits). 1-bit reserved for future @@ -113,9 +113,22 @@ GIT index format are encoded in 7-bit ASCII and the encoding cannot contain a NUL byte (iow, this is a UNIX pathname). + (Version 4) In version 4, the entry path name is prefix-compressed + relative to the path name for the previous entry (the very first + entry is encoded as if the path name for the previous entry is an + empty string). At the beginning of an entry, an integer N in the + variable width encoding (the same encoding as the offset is encoded + for OFS_DELTA pack entries; see pack-format.txt) is stored, followed + by a NUL-terminated string S. Removing N bytes from the end of the + path name for the previous entry, and replacing it with the string S + yields the path name for this entry. + 1-8 nul bytes as necessary to pad the entry to a multiple of eight bytes while keeping the name NUL-terminated. + (Version 4) In version 4, the padding after the pathname does not + exist. + == Extensions === Cached tree @@ -148,8 +161,9 @@ GIT index format this span of index as a tree. An entry can be in an invalidated state and is represented by having - -1 in the entry_count field. In this case, there is no object name - and the next entry starts immediately after the newline. + a negative number in the entry_count field. In this case, there is no + object name and the next entry starts immediately after the newline. + When writing an invalid entry, -1 should always be used as entry_count. The entries are written out in the top-down, depth-first order. The first entry represents the root level of the repository, followed by the @@ -161,7 +175,7 @@ GIT index format A conflict is represented in the index as a set of higher stage entries. When a conflict is resolved (e.g. with "git add path"), these higher - stage entries will be removed and a stage-0 entry with proper resoluton + stage entries will be removed and a stage-0 entry with proper resolution is added. When these higher stage entries are removed, they are saved in the diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt index 1803e64e4..8e5bf60be 100644 --- a/Documentation/technical/pack-format.txt +++ b/Documentation/technical/pack-format.txt @@ -1,7 +1,7 @@ -GIT pack format +Git pack format =============== -= pack-*.pack files have the following format: +== pack-*.pack files have the following format: - A header appears at the beginning and consists of the following: @@ -9,7 +9,7 @@ GIT pack format The signature is: {'P', 'A', 'C', 'K'} 4-byte version number (network byte order): - GIT currently accepts version number 2 or 3 but + Git currently accepts version number 2 or 3 but generates version 2 only. 4-byte number of objects contained in the pack (network byte order) @@ -26,15 +26,17 @@ GIT pack format (deltified representation) n-byte type and length (3-bit type, (n-1)*7+4-bit length) - 20-byte base object name + 20-byte base object name if OBJ_REF_DELTA or a negative relative + offset from the delta object's position in the pack if this + is an OBJ_OFS_DELTA object compressed delta data Observation: length of each object is encoded in a variable length format and is not constrained to 32-bit or anything. - - The trailer records 20-byte SHA1 checksum of all of the above. + - The trailer records 20-byte SHA-1 checksum of all of the above. -= Original (version 1) pack-*.idx files have the following format: +== Original (version 1) pack-*.idx files have the following format: - The header consists of 256 4-byte network byte order integers. N-th entry of this table records the number of @@ -53,10 +55,10 @@ GIT pack format - The file is concluded with a trailer: - A copy of the 20-byte SHA1 checksum at the end of + A copy of the 20-byte SHA-1 checksum at the end of corresponding packfile. - 20-byte SHA1-checksum of all of the above. + 20-byte SHA-1-checksum of all of the above. Pack Idx file: @@ -104,7 +106,7 @@ Pack file entry: <+ If it is not DELTA, then deflated bytes (the size above is the size before compression). If it is REF_DELTA, then - 20-byte base object name SHA1 (the size above is the + 20-byte base object name SHA-1 (the size above is the size of the delta data that follows). delta data, deflated. If it is OFS_DELTA, then @@ -123,8 +125,8 @@ Pack file entry: <+ -= Version 2 pack-*.idx files support packs larger than 4 GiB, and - have some other reorganizations. They have the format: +== Version 2 pack-*.idx files support packs larger than 4 GiB, and + have some other reorganizations. They have the format: - A 4-byte magic number '\377tOc' which is an unreasonable fanout[0] value. @@ -133,7 +135,7 @@ Pack file entry: <+ - A 256-entry fan-out table just like v1. - - A table of sorted 20-byte SHA1 object names. These are + - A table of sorted 20-byte SHA-1 object names. These are packed together without offset values to reduce the cache footprint of the binary search for a specific object name. @@ -154,7 +156,7 @@ Pack file entry: <+ - The same trailer as a v1 pack file: - A copy of the 20-byte SHA1 checksum at the end of + A copy of the 20-byte SHA-1 checksum at the end of corresponding packfile. - 20-byte SHA1-checksum of all of the above. + 20-byte SHA-1-checksum of all of the above. diff --git a/Documentation/technical/pack-heuristics.txt b/Documentation/technical/pack-heuristics.txt index 103eb5d98..95a07db6e 100644 --- a/Documentation/technical/pack-heuristics.txt +++ b/Documentation/technical/pack-heuristics.txt @@ -1,15 +1,15 @@ - Concerning Git's Packing Heuristics - =================================== +Concerning Git's Packing Heuristics +=================================== Oh, here's a really stupid question: Where do I go to learn the details - of git's packing heuristics? + of Git's packing heuristics? Be careful what you ask! -Followers of the git, please open the git IRC Log and turn to +Followers of the Git, please open the Git IRC Log and turn to February 10, 2006. It's a rare occasion, and we are joined by the King Git Himself, @@ -19,7 +19,7 @@ and seeks enlightenment. Others are present, but silent. Let's listen in! <njs`> Oh, here's a really stupid question -- where do I go to - learn the details of git's packing heuristics? google avails + learn the details of Git's packing heuristics? google avails me not, reading the source didn't help a lot, and wading through the whole mailing list seems less efficient than any of that. @@ -37,7 +37,7 @@ Ah! Modesty after all. <linus> njs, I don't think the docs exist. That's something where I don't think anybody else than me even really got involved. - Most of the rest of git others have been busy with (especially + Most of the rest of Git others have been busy with (especially Junio), but packing nobody touched after I did it. It's cryptic, yet vague. Linus in style for sure. Wise men @@ -57,7 +57,7 @@ Bait... And switch. That ought to do it! - <linus> Remember: git really doesn't follow files. So what it does is + <linus> Remember: Git really doesn't follow files. So what it does is - generate a list of all objects - sort the list according to magic heuristics - walk the list, using a sliding window, seeing if an object @@ -89,7 +89,7 @@ Ah, grasshopper! And thus the enlightenment begins anew. <linus> The "magic" is actually in theory totally arbitrary. ANY order will give you a working pack, but no, it's not - ordered by SHA1. + ordered by SHA-1. Before talking about the ordering for the sliding delta window, let's talk about the recency order. That's more @@ -366,12 +366,6 @@ been detailed! <linus> Yes, we always write out most recent first -For the other record: - - <pasky> njs`: http://pastebin.com/547965 - -The 'net never forgets, so that should be good until the end of time. - <njs`> And, yeah, I got the part about deeper-in-history stuff having worse IO characteristics, one sort of doesn't care. @@ -382,7 +376,7 @@ The 'net never forgets, so that should be good until the end of time. <njs`> (if only it happened more...) <linus> Anyway, the pack-file could easily be denser still, but - because it's used both for streaming (the git protocol) and + because it's used both for streaming (the Git protocol) and for on-disk, it has a few pessimizations. Actually, it is a made-up word. But it is a made-up word being @@ -432,12 +426,12 @@ Gasp! OK, saved. That's a fair Engineering trade off. Close call! In fact, Linus reflects on some Basic Engineering Fundamentals, design options, etc. - <linus> More importantly, they allow git to still _conceptually_ + <linus> More importantly, they allow Git to still _conceptually_ never deal with deltas at all, and be a "whole object" store. Which has some problems (we discussed bad huge-file - behaviour on the git lists the other day), but it does mean - that the basic git concepts are really really simple and + behaviour on the Git lists the other day), but it does mean + that the basic Git concepts are really really simple and straightforward. It's all been quite stable. @@ -461,6 +455,6 @@ Nuff said. <njs`> :-) <njs`> appreciate the infodump, I really was failing to find the - details on git packs :-) + details on Git packs :-) And now you know the rest of the story. diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index a7004c63e..c73b62f5e 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -60,6 +60,13 @@ process on the server side over the Git protocol is this: "0039git-upload-pack /schacon/gitbook.git\0host=example.com\0" | nc -v example.com 9418 +If the server refuses the request for some reasons, it could abort +gracefully with an error message. + +---- + error-line = PKT-LINE("ERR" SP explanation-text) +---- + SSH Transport ------------- @@ -110,7 +117,7 @@ A few things to remember here: - The repository path is always quoted with single quotes. Fetching Data From a Server -=========================== +--------------------------- When one Git repository wants to get data that a second repository has, the first can 'fetch' from the second. This operation determines @@ -127,7 +134,8 @@ with the object name that each reference currently points to. $ echo -e -n "0039git-upload-pack /schacon/gitbook.git\0host=example.com\0" | nc -v example.com 9418 - 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag + 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack + side-band side-band-64k ofs-delta shallow no-progress include-tag 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration 003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master 003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9 @@ -153,6 +161,7 @@ MUST peel the ref if it's an annotated tag. ---- advertised-refs = (no-refs / list-of-refs) + *shallow flush-pkt no-refs = PKT-LINE(zero-id SP "capabilities^{}" @@ -166,6 +175,8 @@ MUST peel the ref if it's an annotated tag. other-tip = obj-id SP refname LF other-peeled = obj-id SP refname "^{}" LF + shallow = PKT-LINE("shallow" SP obj-id) + capability-list = capability *(SP capability) capability = 1*(LC_ALPHA / DIGIT / "-" / "_") LC_ALPHA = %x61-7A @@ -220,8 +231,7 @@ obtained through ref discovery. The client MUST write all obj-ids which it only has shallow copies of (meaning that it does not have the parents of a commit) as 'shallow' lines so that the server is aware of the limitations of -the client's history. Clients MUST NOT mention an obj-id which -it does not know exists on the server. +the client's history. The client now sends the maximum commit history depth it wants for this transaction, which is the number of commits it wants from the @@ -252,8 +262,10 @@ a positive depth, this step is skipped. ---- If the client has requested a positive depth, the server will compute -the set of commits which are no deeper than the desired depth, starting -at the client's wants. The server writes 'shallow' lines for each +the set of commits which are no deeper than the desired depth. The set +of commits start at the client's wants. + +The server writes 'shallow' lines for each commit whose parents will not be sent as a result. The server writes an 'unshallow' line for each commit which the client has indicated is shallow, but is no longer shallow at the currently requested depth @@ -344,7 +356,7 @@ Then the server will start sending its packfile data. A simple clone may look like this (with no 'have' lines): ---- - C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\0multi_ack \ + C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \ side-band-64k ofs-delta\n C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n @@ -360,7 +372,7 @@ A simple clone may look like this (with no 'have' lines): An incremental update (fetch) response might look like this: ---- - C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\0multi_ack \ + C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \ side-band-64k ofs-delta\n C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n @@ -412,7 +424,7 @@ entire packfile without multiplexing. Pushing Data To a Server -======================== +------------------------ Pushing data to a server will invoke the 'receive-pack' process on the server, which will allow the client to tell it which references it should @@ -452,7 +464,9 @@ contain all the objects that the server will need to complete the new references. ---- - update-request = command-list [pack-file] + update-request = *shallow command-list [pack-file] + + shallow = PKT-LINE("shallow" SP obj-id) command-list = PKT-LINE(command NUL capability-list LF) *PKT-LINE(command LF) diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index b15517fa0..e3e792476 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -18,11 +18,12 @@ was sent. Server MUST NOT ignore capabilities that client requested and server advertised. As a consequence of these rules, server MUST NOT advertise capabilities it does not understand. -The 'report-status' and 'delete-refs' capabilities are sent and +The 'report-status', 'delete-refs', and 'quiet' capabilities are sent and recognized by the receive-pack (push to server) process. -The 'ofs-delta' capability is sent and recognized by both upload-pack -and receive-pack protocols. +The 'ofs-delta' and 'side-band-64k' capabilities are sent and recognized +by both upload-pack and receive-pack protocols. The 'agent' capability +may optionally be sent in both protocols. All other capabilities are only recognized by the upload-pack (fetch from server) process. @@ -71,14 +72,29 @@ interleaved with S-R-Q. thin-pack --------- -This capability means that the server can send a 'thin' pack, a pack -which does not contain base objects; if those base objects are available -on client side. Client requests 'thin-pack' capability when it -understands how to "thicken" it by adding required delta bases making -it self-contained. +A thin pack is one with deltas which reference base objects not +contained within the pack (but are known to exist at the receiving +end). This can reduce the network traffic significantly, but it +requires the receiving end to know how to "thicken" these packs by +adding the missing bases to the pack. -Client MUST NOT request 'thin-pack' capability if it cannot turn a thin -pack into a self-contained pack. +The upload-pack server advertises 'thin-pack' when it can generate +and send a thin pack. A client requests the 'thin-pack' capability +when it understands how to "thicken" it, notifying the server that +it can receive such a pack. A client MUST NOT request the +'thin-pack' capability if it cannot turn a thin pack into a +self-contained pack. + +Receive-pack, on the other hand, is assumed by default to be able to +handle thin packs, but can ask the client not to use the feature by +advertising the 'no-thin' capability. A client MUST NOT send a thin +pack if the server advertises the 'no-thin' capability. + +The reasons for this asymmetry are historical. The receive-pack +program did not exist until after the invention of thin packs, so +historically the reference implementation of receive-pack always +understood thin packs. Adding 'no-thin' later allowed receive-pack +to disable the feature in a backwards-compatible manner. side-band, side-band-64k @@ -123,6 +139,20 @@ Server can send, and client understand PACKv2 with delta referring to its base by position in pack rather than by an obj-id. That is, they can send/read OBJ_OFS_DELTA (aka type 6) in a packfile. +agent +----- + +The server may optionally send a capability of the form `agent=X` to +notify the client that the server is running version `X`. The client may +optionally return its own agent string by responding with an `agent=Y` +capability (but it MUST NOT do so if the server did not mention the +agent capability). The `X` and `Y` strings may contain any printable +ASCII characters except space (i.e., the byte range 32 < x < 127), and +are typically of the form "package/version" (e.g., "git/1.8.3.1"). The +agent strings are purely informative for statistics and debugging +purposes, and MUST NOT be used to programatically assume the presence +or absence of particular features. + shallow ------- @@ -168,7 +198,7 @@ of whether or not there are tags available. report-status ------------- -The upload-pack process can receive a 'report-status' capability, +The receive-pack process can receive a 'report-status' capability, which tells it that the client wants a report of what happened after a packfile upload and reference update. If the pushing client requests this capability, after unpacking and updating references the server @@ -185,3 +215,20 @@ it is capable of accepting a zero-id value as the target value of a reference update. It is not sent back by the client, it simply informs the client that it can be sent zero-id values to delete references. + +quiet +----- + +If the receive-pack server advertises the 'quiet' capability, it is +capable of silencing human-readable progress output which otherwise may +be shown when processing the received pack. A send-pack client should +respond with the 'quiet' capability to suppress server-side progress +reporting if the local progress reporting is also being suppressed +(e.g., via `push -q`, or if stderr does not go to a tty). + +allow-tip-sha1-in-want +---------------------- + +If the upload-pack server advertises this capability, fetch-pack may +send "want" lines with SHA-1s that exist at the server but are not +advertised by upload-pack. diff --git a/Documentation/technical/protocol-common.txt b/Documentation/technical/protocol-common.txt index d30a1b951..fb7ff084f 100644 --- a/Documentation/technical/protocol-common.txt +++ b/Documentation/technical/protocol-common.txt @@ -36,7 +36,7 @@ More specifically, they: . 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 `*`, + caret `^`, colon `:`, question-mark `?`, asterisk `*`, or open bracket `[` anywhere. . They cannot end with a slash `/` nor a dot `.`. diff --git a/Documentation/technical/racy-git.txt b/Documentation/technical/racy-git.txt index 53aa0c82c..242a044db 100644 --- a/Documentation/technical/racy-git.txt +++ b/Documentation/technical/racy-git.txt @@ -1,21 +1,21 @@ -Use of index and Racy git problem +Use of index and Racy Git problem ================================= Background ---------- -The index is one of the most important data structures in git. +The index is one of the most important data structures in Git. It represents a virtual working tree state by recording list of paths and their object names and serves as a staging area to write out the next tree object to be committed. The state is "virtual" in the sense that it does not necessarily have to, and often does not, match the files in the working tree. -There are cases git needs to examine the differences between the +There are cases Git needs to examine the differences between the virtual working tree state in the index and the files in the working tree. The most obvious case is when the user asks `git diff` (or its low level implementation, `git diff-files`) or -`git-ls-files --modified`. In addition, git internally checks +`git-ls-files --modified`. In addition, Git internally checks if the files in the working tree are different from what are recorded in the index to avoid stomping on local changes in them during patch application, switching branches, and merging. @@ -24,16 +24,16 @@ In order to speed up this comparison between the files in the working tree and the index entries, the index entries record the information obtained from the filesystem via `lstat(2)` system call when they were last updated. When checking if they differ, -git first runs `lstat(2)` on the files and compares the result +Git first runs `lstat(2)` on the files and compares the result with this information (this is what was originally done by the `ce_match_stat()` function, but the current code does it in `ce_match_stat_basic()` function). If some of these "cached -stat information" fields do not match, git can tell that the +stat information" fields do not match, Git can tell that the files are modified without even looking at their contents. Note: not all members in `struct stat` obtained via `lstat(2)` are used for this comparison. For example, `st_atime` obviously -is not useful. Currently, git compares the file type (regular +is not useful. Currently, Git compares the file type (regular files vs symbolic links) and executable bits (only for regular files) from `st_mode` member, `st_mtime` and `st_ctime` timestamps, `st_uid`, `st_gid`, `st_ino`, and `st_size` members. @@ -46,10 +46,10 @@ because in-core timestamps can have finer granularity than on-disk timestamps, resulting in meaningless changes when an inode is evicted from the inode cache. See commit 8ce13b0 of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git -([PATCH] Sync in core time granuality with filesystems, +([PATCH] Sync in core time granularity with filesystems, 2005-01-04). -Racy git +Racy Git -------- There is one slight problem with the optimization based on the @@ -67,13 +67,13 @@ timestamp does not change, after this sequence, the cached stat information the index entry records still exactly match what you would see in the filesystem, even though the file `foo` is now different. -This way, git can incorrectly think files in the working tree +This way, Git can incorrectly think files in the working tree are unmodified even though they actually are. This is called -the "racy git" problem (discovered by Pasky), and the entries +the "racy Git" problem (discovered by Pasky), and the entries that appear clean when they may not be because of this problem are called "racily clean". -To avoid this problem, git does two things: +To avoid this problem, Git does two things: . When the cached stat information says the file has not been modified, and the `st_mtime` is the same as (or newer than) @@ -116,7 +116,7 @@ timestamp comparison check done with the former logic anymore. The latter makes sure that the cached stat information for `foo` would never match with the file in the working tree, so later checks by `ce_match_stat_basic()` would report that the index entry -does not match the file and git does not have to fall back on more +does not match the file and Git does not have to fall back on more expensive `ce_modified_check_fs()`. @@ -135,9 +135,9 @@ them, and give the same timestamp to the index file: $ git ls-files | git update-index --stdin $ touch -r .datestamp .git/index -This will make all index entries racily clean. The linux-2.6 -project, for example, there are over 20,000 files in the working -tree. On my Athlon 64 X2 3800+, after the above: +This will make all index entries racily clean. The linux project, for +example, there are over 20,000 files in the working tree. On my +Athlon 64 X2 3800+, after the above: $ /usr/bin/time git diff-files 1.68user 0.54system 0:02.22elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k @@ -159,7 +159,7 @@ of the cached stat information. Avoiding runtime penalty ------------------------ -In order to avoid the above runtime penalty, post 1.4.2 git used +In order to avoid the above runtime penalty, post 1.4.2 Git used to have a code that made sure the index file got timestamp newer than the youngest files in the index when there are many young files with the same timestamp as the diff --git a/Documentation/technical/send-pack-pipeline.txt b/Documentation/technical/send-pack-pipeline.txt index 681efe421..9b5a0bc18 100644 --- a/Documentation/technical/send-pack-pipeline.txt +++ b/Documentation/technical/send-pack-pipeline.txt @@ -1,5 +1,5 @@ -git-send-pack -============= +Git-send-pack internals +======================= Overall operation ----------------- diff --git a/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt index 559263af4..5183b1542 100644 --- a/Documentation/technical/shallow.txt +++ b/Documentation/technical/shallow.txt @@ -1,8 +1,14 @@ -Def.: Shallow commits do have parents, but not in the shallow +Shallow commits +=============== + +.Definition +********************************************************* +Shallow commits do have parents, but not in the shallow repo, and therefore grafts are introduced pretending that these commits have no parents. +********************************************************* -The basic idea is to write the SHA1s of shallow commits into +The basic idea is to write the SHA-1s of shallow commits into $GIT_DIR/shallow, and handle its contents like the contents of $GIT_DIR/info/grafts (with the difference that shallow cannot contain parent information). @@ -12,7 +18,7 @@ even the config, since the user should not touch that file at all (even throughout development of the shallow clone, it was never manually edited!). -Each line contains exactly one SHA1. When read, a commit_graft +Each line contains exactly one SHA-1. When read, a commit_graft will be constructed, which has nr_parent < 0 to make it easier to discern from user provided grafts. @@ -47,3 +53,6 @@ It also writes an appropriate $GIT_DIR/shallow. You can deepen a shallow repository with "git-fetch --depth 20 repo branch", which will fetch branch from repo, but stop at depth 20, updating $GIT_DIR/shallow. + +The special depth 2147483647 (or 0x7fffffff, the largest positive +number a signed 32-bit integer can contain) means infinite depth. diff --git a/Documentation/technical/trivial-merge.txt b/Documentation/technical/trivial-merge.txt index 24c84100b..c79d4a7c4 100644 --- a/Documentation/technical/trivial-merge.txt +++ b/Documentation/technical/trivial-merge.txt @@ -74,24 +74,24 @@ For multiple ancestors, a '+' means that this case applies even if only one ancestor or remote fits; a '^' means all of the ancestors must be the same. -case ancest head remote result ----------------------------------------- -1 (empty)+ (empty) (empty) (empty) -2ALT (empty)+ *empty* remote remote -2 (empty)^ (empty) remote no merge -3ALT (empty)+ head *empty* head -3 (empty)^ head (empty) no merge -4 (empty)^ head remote no merge -5ALT * head head head -6 ancest+ (empty) (empty) no merge -8 ancest^ (empty) ancest no merge -7 ancest+ (empty) remote no merge -10 ancest^ ancest (empty) no merge -9 ancest+ head (empty) no merge -16 anc1/anc2 anc1 anc2 no merge -13 ancest+ head ancest head -14 ancest+ ancest remote remote -11 ancest+ head remote no merge + case ancest head remote result + ---------------------------------------- + 1 (empty)+ (empty) (empty) (empty) + 2ALT (empty)+ *empty* remote remote + 2 (empty)^ (empty) remote no merge + 3ALT (empty)+ head *empty* head + 3 (empty)^ head (empty) no merge + 4 (empty)^ head remote no merge + 5ALT * head head head + 6 ancest+ (empty) (empty) no merge + 8 ancest^ (empty) ancest no merge + 7 ancest+ (empty) remote no merge + 10 ancest^ ancest (empty) no merge + 9 ancest+ head (empty) no merge + 16 anc1/anc2 anc1 anc2 no merge + 13 ancest+ head ancest head + 14 ancest+ ancest remote remote + 11 ancest+ head remote no merge Only #2ALT and #3ALT use *empty*, because these are the only cases where there can be conflicts that didn't exist before. Note that we diff --git a/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt index 00f7e79c4..282758e76 100644 --- a/Documentation/urls-remotes.txt +++ b/Documentation/urls-remotes.txt @@ -6,7 +6,7 @@ REMOTES[[REMOTES]] The name of one of the following can be used instead of a URL as `<repository>` argument: -* a remote in the git configuration file: `$GIT_DIR/config`, +* a remote in the Git configuration file: `$GIT_DIR/config`, * a file in the `$GIT_DIR/remotes` directory, or * a file in the `$GIT_DIR/branches` directory. diff --git a/Documentation/urls.txt b/Documentation/urls.txt index 289019478..9ccb24677 100644 --- a/Documentation/urls.txt +++ b/Documentation/urls.txt @@ -6,8 +6,15 @@ address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent. -Git natively supports ssh, git, http, https, ftp, ftps, and rsync -protocols. The following syntaxes may be used with them: +Git supports ssh, git, http, and https protocols (in addition, ftp, +and ftps can be used for fetching and rsync can be used for fetching +and pushing, but these are inefficient and deprecated; do not use +them). + +The native transport (i.e. git:// URL) does no authentication and +should be used with caution on unsecured networks. + +The following syntaxes may be used with them: - ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/ - git://host.xz{startsb}:port{endsb}/path/to/repo.git/ @@ -19,17 +26,23 @@ An alternative scp-like syntax may also be used with the ssh protocol: - {startsb}user@{endsb}host.xz:path/to/repo.git/ +This syntax is only recognized if there are no slashes before the +first colon. This helps differentiate a local path that contains a +colon. For example the local path `foo:bar` could be specified as an +absolute path or `./foo:bar` to avoid being misinterpreted as an ssh +url. + The ssh and git protocols additionally support ~username expansion: - ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/~{startsb}user{endsb}/path/to/repo.git/ - git://host.xz{startsb}:port{endsb}/~{startsb}user{endsb}/path/to/repo.git/ - {startsb}user@{endsb}host.xz:/~{startsb}user{endsb}/path/to/repo.git/ -For local repositories, also supported by git natively, the following +For local repositories, also supported by Git natively, the following syntaxes may be used: - /path/to/repo.git/ -- file:///path/to/repo.git/ +- \file:///path/to/repo.git/ ifndef::git-clone[] These two syntaxes are mostly equivalent, except when cloning, when @@ -42,7 +55,7 @@ These two syntaxes are mostly equivalent, except the former implies --local option. endif::git-clone[] -When git doesn't know how to handle a certain transport protocol, it +When Git doesn't know how to handle a certain transport protocol, it attempts to use the 'remote-<transport>' remote helper, if one exists. To explicitly request a remote helper, the following syntax may be used: @@ -51,7 +64,7 @@ may be used: where <address> may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being -invoked. See linkgit:git-remote-helpers[1] for details. +invoked. See linkgit:gitremote-helpers[1] for details. If there are a large number of similarly-named remote repositories and you want to use a different format for them (such that the URLs you diff --git a/Documentation/user-manual.conf b/Documentation/user-manual.conf index 339b30919..d87294de2 100644 --- a/Documentation/user-manual.conf +++ b/Documentation/user-manual.conf @@ -14,7 +14,7 @@ ifdef::backend-docbook[] # "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this. [listingblock] <example><title>{title}</title> -<literallayout> +<literallayout class="monospaced"> | </literallayout> {title#}</example> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index f13a84613..d4f980446 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1,11 +1,10 @@ -Git User's Manual (for version 1.5.3 or newer) -______________________________________________ - +Git User Manual +=============== Git is a fast distributed revision control system. This manual is designed to be readable by someone with basic UNIX -command-line skills, but no previous knowledge of git. +command-line skills, but no previous knowledge of Git. <<repositories-and-branches>> and <<exploring-git-history>> explain how to fetch and study a project using git--read these chapters to learn how @@ -19,7 +18,7 @@ Further chapters cover more specialized topics. Comprehensive reference documentation is available through the man pages, or linkgit:git-help[1] command. For example, for the command -"git clone <repo>", you can either use: +`git clone <repo>`, you can either use: ------------------------------------------------ $ man git-clone @@ -34,7 +33,7 @@ $ git help clone With the latter, you can use the manual viewer of your choice; see linkgit:git-help[1] for more information. -See also <<git-quick-start>> for a brief overview of git commands, +See also <<git-quick-start>> for a brief overview of Git commands, without any explanation. Finally, see <<todo>> for ways that you can help make this manual more @@ -46,10 +45,10 @@ Repositories and Branches ========================= [[how-to-get-a-git-repository]] -How to get a git repository +How to get a Git repository --------------------------- -It will be useful to have a git repository to experiment with as you +It will be useful to have a Git repository to experiment with as you read this manual. The best way to get one is by using the linkgit:git-clone[1] command to @@ -57,20 +56,20 @@ download a copy of an existing repository. If you don't already have a project in mind, here are some interesting examples: ------------------------------------------------ - # git itself (approx. 10MB download): + # Git itself (approx. 40MB download): $ git clone git://git.kernel.org/pub/scm/git/git.git - # the Linux kernel (approx. 150MB download): -$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + # the Linux kernel (approx. 640MB download): +$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ------------------------------------------------ The initial clone may be time-consuming for a large project, but you will only need to clone once. -The clone command creates a new directory named after the project ("git" -or "linux-2.6" in the examples above). After you cd into this +The clone command creates a new directory named after the project +(`git` or `linux` in the examples above). After you cd into this directory, you will see that it contains a copy of the project files, called the <<def_working_tree,working tree>>, together with a special -top-level directory named ".git", which contains all the information +top-level directory named `.git`, which contains all the information about the history of the project. [[how-to-check-out]] @@ -79,7 +78,7 @@ How to check out a different version of a project Git is best thought of as a tool for storing the history of a collection of files. It stores the history as a compressed collection of -interrelated snapshots of the project's contents. In git each such +interrelated snapshots of the project's contents. In Git each such version is called a <<def_commit,commit>>. Those snapshots aren't necessarily all arranged in a single line from @@ -87,7 +86,7 @@ oldest to newest; instead, work may simultaneously proceed along parallel lines of development, called <<def_branch,branches>>, which may merge and diverge. -A single git repository can track development on multiple branches. It +A single Git repository can track development on multiple branches. It does this by keeping a list of <<def_head,heads>> which reference the latest commit on each branch; the linkgit:git-branch[1] command shows you the list of branch heads: @@ -188,7 +187,7 @@ As you can see, a commit shows who made the latest change, what they did, and why. Every commit has a 40-hexdigit id, sometimes called the "object name" or the -"SHA-1 id", shown on the first line of the "git show" output. You can usually +"SHA-1 id", shown on the first line of the `git show` output. You can usually refer to a commit by a shorter name, such as a tag or a branch name, but this longer name can also be useful. Most importantly, it is a globally unique name for this commit: so if you tell somebody else the object name (for @@ -198,7 +197,7 @@ has that commit at all). Since the object name is computed as a hash over the contents of the commit, you are guaranteed that the commit can never change without its name also changing. -In fact, in <<git-concepts>> we shall see that everything stored in git +In fact, in <<git-concepts>> we shall see that everything stored in Git history, including file data and directory contents, is stored in an object with a name that is a hash of its contents. @@ -211,7 +210,7 @@ parent commit which shows what happened before this commit. Following the chain of parents will eventually take you back to the beginning of the project. -However, the commits do not form a simple list; git allows lines of +However, the commits do not form a simple list; Git allows lines of development to diverge and then reconverge, and the point where two lines of development reconverge is called a "merge". The commit representing a merge can therefore have more than one parent, with @@ -219,8 +218,8 @@ each parent representing the most recent commit on one of the lines of development leading to that point. The best way to see how this works is using the linkgit:gitk[1] -command; running gitk now on a git repository and looking for merge -commits will help understand how the git organizes history. +command; running gitk now on a Git repository and looking for merge +commits will help understand how Git organizes history. In the following, we say that commit X is "reachable" from commit Y if commit X is an ancestor of commit Y. Equivalently, you could say @@ -231,7 +230,7 @@ leading from commit Y to commit X. Understanding history: History diagrams ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -We will sometimes represent git history using diagrams like the one +We will sometimes represent Git history using diagrams like the one below. Commits are shown as "o", and the links between them with lines drawn with - / and \. Time goes left to right: @@ -268,35 +267,31 @@ Manipulating branches Creating, deleting, and modifying branches is quick and easy; here's a summary of the commands: -git branch:: - list all branches -git branch <branch>:: - create a new branch named <branch>, referencing the same - point in history as the current branch -git branch <branch> <start-point>:: - create a new branch named <branch>, referencing - <start-point>, which may be specified any way you like, - including using a branch name or a tag name -git branch -d <branch>:: - delete the branch <branch>; if the branch you are deleting - points to a commit which is not reachable from the current - branch, this command will fail with a warning. -git branch -D <branch>:: - even if the branch points to a commit not reachable - from the current branch, you may know that that commit - is still reachable from some other branch or tag. In that - case it is safe to use this command to force git to delete - the branch. -git checkout <branch>:: - make the current branch <branch>, updating the working - directory to reflect the version referenced by <branch> -git checkout -b <new> <start-point>:: - create a new branch <new> referencing <start-point>, and +`git branch`:: + list all branches. +`git branch <branch>`:: + create a new branch named `<branch>`, referencing the same + point in history as the current branch. +`git branch <branch> <start-point>`:: + create a new branch named `<branch>`, referencing + `<start-point>`, which may be specified any way you like, + including using a branch name or a tag name. +`git branch -d <branch>`:: + delete the branch `<branch>`; if the branch is not fully + merged in its upstream branch or contained in the current branch, + this command will fail with a warning. +`git branch -D <branch>`:: + delete the branch `<branch>` irrespective of its merged status. +`git checkout <branch>`:: + make the current branch `<branch>`, updating the working + directory to reflect the version referenced by `<branch>`. +`git checkout -b <new> <start-point>`:: + create a new branch `<new>` referencing `<start-point>`, and check it out. The special symbol "HEAD" can always be used to refer to the current -branch. In fact, git uses a file named "HEAD" in the .git directory to -remember which branch is current: +branch. In fact, Git uses a file named `HEAD` in the `.git` directory +to remember which branch is current: ------------------------------------------------ $ cat .git/HEAD @@ -313,10 +308,17 @@ referenced by a tag: ------------------------------------------------ $ git checkout v2.6.17 -Note: moving to "v2.6.17" which isn't a local branch -If you want to create a new branch from this checkout, you may do so -(now or later) by using -b with the checkout command again. Example: - git checkout -b <new_branch_name> +Note: checking out 'v2.6.17'. + +You are in 'detached HEAD' state. You can look around, make experimental +changes and commit them, and you can discard any commits you make in this +state without impacting any branches by performing another checkout. + +If you want to create a new branch to retain commits you create, you may +do so (now or later) by using -b with the checkout command again. Example: + + git checkout -b new_branch_name + HEAD is now at 427abfa... Linux v2.6.17 ------------------------------------------------ @@ -327,7 +329,7 @@ and git branch shows that you are no longer on a branch: $ cat .git/HEAD 427abfa28afedffadfca9dd8b067eb6d36bac53f $ git branch -* (no branch) +* (detached from v2.6.17) master ------------------------------------------------ @@ -346,7 +348,7 @@ of the HEAD in the repository that you cloned from. That repository may also have had other branches, though, and your local repository keeps branches which track each of those remote branches, called remote-tracking branches, which you -can view using the "-r" option to linkgit:git-branch[1]: +can view using the `-r` option to linkgit:git-branch[1]: ------------------------------------------------ $ git branch -r @@ -364,7 +366,7 @@ In this example, "origin" is called a remote repository, or "remote" for short. The branches of this repository are called "remote branches" from our point of view. The remote-tracking branches listed above were created based on the remote branches at clone time and will -be updated by "git fetch" (hence "git pull") and "git push". See +be updated by `git fetch` (hence `git pull`) and `git push`. See <<Updating-a-repository-With-git-fetch>> for details. You might want to build on one of these remote-tracking branches @@ -374,10 +376,10 @@ on a branch of your own, just as you would for a tag: $ git checkout -b my-todo-copy origin/todo ------------------------------------------------ -You can also check out "origin/todo" directly to examine it or +You can also check out `origin/todo` directly to examine it or write a one-off patch. See <<detached-head,detached head>>. -Note that the name "origin" is just the name that git uses by default +Note that the name "origin" is just the name that Git uses by default to refer to the repository that you cloned from. [[how-git-stores-references]] @@ -386,17 +388,17 @@ Naming branches, tags, and other references Branches, remote-tracking branches, and tags are all references to commits. All references are named with a slash-separated path name -starting with "refs"; the names we've been using so far are actually +starting with `refs`; the names we've been using so far are actually shorthand: - - The branch "test" is short for "refs/heads/test". - - The tag "v2.6.18" is short for "refs/tags/v2.6.18". - - "origin/master" is short for "refs/remotes/origin/master". + - The branch `test` is short for `refs/heads/test`. + - The tag `v2.6.18` is short for `refs/tags/v2.6.18`. + - `origin/master` is short for `refs/remotes/origin/master`. The full name is occasionally useful if, for example, there ever exists a tag and a branch with the same name. -(Newly created refs are actually stored in the .git/refs directory, +(Newly created refs are actually stored in the `.git/refs` directory, under the path given by their name. However, for efficiency reasons they may also be packed together in a single file; see linkgit:git-pack-refs[1]). @@ -405,7 +407,7 @@ As another useful shortcut, the "HEAD" of a repository can be referred to just using the name of that repository. So, for example, "origin" is usually a shortcut for the HEAD branch in the repository "origin". -For the complete list of paths which git checks for references, and +For the complete list of paths which Git checks for references, and the order it uses to decide which to choose when there are multiple references with the same shorthand name, see the "SPECIFYING REVISIONS" section of linkgit:gitrevisions[7]. @@ -418,7 +420,7 @@ Eventually the developer cloned from will do additional work in her repository, creating new commits and advancing the branches to point at the new commits. -The command "git fetch", with no arguments, will update all of the +The command `git fetch`, with no arguments, will update all of the remote-tracking branches to the latest version found in her repository. It will not touch any of your own branches--not even the "master" branch that was created for you on clone. @@ -431,43 +433,49 @@ You can also track branches from repositories other than the one you cloned from, using linkgit:git-remote[1]: ------------------------------------------------- -$ git remote add linux-nfs git://linux-nfs.org/pub/nfs-2.6.git -$ git fetch linux-nfs -* refs/remotes/linux-nfs/master: storing branch 'master' ... - commit: bf81b46 +$ git remote add staging git://git.kernel.org/.../gregkh/staging.git +$ git fetch staging +... +From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging + * [new branch] master -> staging/master + * [new branch] staging-linus -> staging/staging-linus + * [new branch] staging-next -> staging/staging-next ------------------------------------------------- New remote-tracking branches will be stored under the shorthand name -that you gave "git remote add", in this case linux-nfs: +that you gave `git remote add`, in this case `staging`: ------------------------------------------------- $ git branch -r -linux-nfs/master -origin/master + origin/HEAD -> origin/master + origin/master + staging/master + staging/staging-linus + staging/staging-next ------------------------------------------------- -If you run "git fetch <remote>" later, the remote-tracking branches for the -named <remote> will be updated. +If you run `git fetch <remote>` later, the remote-tracking branches +for the named `<remote>` will be updated. -If you examine the file .git/config, you will see that git has added +If you examine the file `.git/config`, you will see that Git has added a new stanza: ------------------------------------------------- $ cat .git/config ... -[remote "linux-nfs"] - url = git://linux-nfs.org/pub/nfs-2.6.git - fetch = +refs/heads/*:refs/remotes/linux-nfs/* +[remote "staging"] + url = git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git + fetch = +refs/heads/*:refs/remotes/staging/* ... ------------------------------------------------- -This is what causes git to track the remote's branches; you may modify -or delete these configuration options by editing .git/config with a +This is what causes Git to track the remote's branches; you may modify +or delete these configuration options by editing `.git/config` with a text editor. (See the "CONFIGURATION FILE" section of linkgit:git-config[1] for details.) [[exploring-git-history]] -Exploring git history +Exploring Git history ===================== Git is best thought of as a tool for storing the history of a @@ -499,7 +507,7 @@ Bisecting: 3537 revisions left to test after this [65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6] ------------------------------------------------- -If you run "git branch" at this point, you'll see that git has +If you run `git branch` at this point, you'll see that Git has temporarily moved you in "(no branch)". HEAD is now detached from any branch and points directly to a commit (with commit id 65934...) that is reachable from "master" but not from v2.6.18. Compile and test it, @@ -511,7 +519,7 @@ Bisecting: 1769 revisions left to test after this [7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings ------------------------------------------------- -checks out an older version. Continue like this, telling git at each +checks out an older version. Continue like this, telling Git at each stage whether the version it gives you is good or bad, and notice that the number of revisions left to test is cut approximately in half each time. @@ -545,24 +553,24 @@ id, and check it out with: $ git reset --hard fb47ddb2db... ------------------------------------------------- -then test, run "bisect good" or "bisect bad" as appropriate, and +then test, run `bisect good` or `bisect bad` as appropriate, and continue. -Instead of "git bisect visualize" and then "git reset --hard -fb47ddb2db...", you might just want to tell git that you want to skip +Instead of `git bisect visualize` and then `git reset --hard +fb47ddb2db...`, you might just want to tell Git that you want to skip the current commit: ------------------------------------------------- $ git bisect skip ------------------------------------------------- -In this case, though, git may not eventually be able to tell the first +In this case, though, Git may not eventually be able to tell the first bad one between some first skipped commits and a later bad commit. There are also ways to automate the bisecting process if you have a test script that can tell a good from a bad commit. See -linkgit:git-bisect[1] for more information about this and other "git -bisect" features. +linkgit:git-bisect[1] for more information about this and other `git +bisect` features. [[naming-commits]] Naming commits @@ -591,7 +599,7 @@ $ git show HEAD~4 # the great-great-grandparent ------------------------------------------------- Recall that merge commits may have more than one parent; by default, -^ and ~ follow the first parent listed in the commit, but you can +`^` and `~` follow the first parent listed in the commit, but you can also choose: ------------------------------------------------- @@ -640,7 +648,7 @@ running $ git tag stable-1 1b2e1d63ff ------------------------------------------------- -You can use stable-1 to refer to the commit 1b2e1d63ff. +You can use `stable-1` to refer to the commit 1b2e1d63ff. This creates a "lightweight" tag. If you would also like to include a comment with the tag, and possibly sign it cryptographically, then you @@ -669,7 +677,7 @@ $ git log -S'foo()' # commits which add or remove any file data ------------------------------------------------- And of course you can combine all of these; the following finds -commits since v2.5 which touch the Makefile or any file under fs: +commits since v2.5 which touch the `Makefile` or any file under `fs`: ------------------------------------------------- $ git log v2.5.. Makefile fs/ @@ -681,11 +689,11 @@ You can also ask git log to show patches: $ git log -p ------------------------------------------------- -See the "--pretty" option in the linkgit:git-log[1] man page for more +See the `--pretty` option in the linkgit:git-log[1] man page for more display options. Note that git log starts with the most recent commit and works -backwards through the parents; however, since git history can contain +backwards through the parents; however, since Git history can contain multiple independent lines of development, the particular order that commits are listed in may be somewhat arbitrary. @@ -732,7 +740,7 @@ $ git show v2.5:fs/locks.c ------------------------------------------------- Before the colon may be anything that names a commit, and after it -may be any path to a file tracked by git. +may be any path to a file tracked by Git. [[history-examples]] Examples @@ -742,8 +750,8 @@ Examples Counting the number of commits on a branch ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Suppose you want to know how many commits you've made on "mybranch" -since it diverged from "origin": +Suppose you want to know how many commits you've made on `mybranch` +since it diverged from `origin`: ------------------------------------------------- $ git log --pretty=oneline origin..mybranch | wc -l @@ -780,9 +788,9 @@ $ git rev-list master e05db0fd4f31dde7005f075a84f96b360d05984b ------------------------------------------------- -Or you could recall that the ... operator selects all commits -contained reachable from either one reference or the other but not -both: so +Or you could recall that the `...` operator selects all commits +reachable from either one reference or the other but not +both; so ------------------------------------------------- $ git log origin...master @@ -808,7 +816,7 @@ You could just visually inspect the commits since e05db0fd: $ gitk e05db0fd.. ------------------------------------------------- -Or you can use linkgit:git-name-rev[1], which will give the commit a +or you can use linkgit:git-name-rev[1], which will give the commit a name based on any tag it finds pointing to one of the commit's descendants: @@ -852,8 +860,8 @@ because it outputs only commits that are not reachable from v1.5.0-rc1. As yet another alternative, the linkgit:git-show-branch[1] command lists the commits reachable from its arguments with a display on the left-hand -side that indicates which arguments that commit is reachable from. So, -you can run something like +side that indicates which arguments that commit is reachable from. +So, if you run something like ------------------------------------------------- $ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2 @@ -865,22 +873,22 @@ available ... ------------------------------------------------- -then search for a line that looks like +then a line like ------------------------------------------------- + ++ [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if available ------------------------------------------------- -Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and -from v1.5.0-rc2, but not from v1.5.0-rc0. +shows that e05db0fd is reachable from itself, from v1.5.0-rc1, +and from v1.5.0-rc2, and not from v1.5.0-rc0. [[showing-commits-unique-to-a-branch]] Showing commits unique to a given branch ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Suppose you would like to see all the commits reachable from the branch -head named "master" but not from any other head in your repository. +head named `master` but not from any other head in your repository. We can list all the heads in this repository with linkgit:git-show-ref[1]: @@ -894,7 +902,7 @@ a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master 1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes ------------------------------------------------- -We can get just the branch-head names, and remove "master", with +We can get just the branch-head names, and remove `master`, with the help of the standard utilities cut and grep: ------------------------------------------------- @@ -931,11 +939,20 @@ The linkgit:git-archive[1] command can create a tar or zip archive from any version of a project; for example: ------------------------------------------------- -$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz +$ git archive -o latest.tar.gz --prefix=project/ HEAD ------------------------------------------------- -will use HEAD to produce a tar archive in which each filename is -preceded by "project/". +will use HEAD to produce a gzipped tar archive in which each filename +is preceded by `project/`. The output file format is inferred from +the output file extension if possible, see linkgit:git-archive[1] for +details. + +Versions of Git older than 1.7.7 don't know about the `tar.gz` format, +you'll need to use gzip explicitly: + +------------------------------------------------- +$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz +------------------------------------------------- If you're releasing a new version of a software project, you may want to simultaneously make a changelog to include in the release @@ -984,16 +1001,23 @@ student. The linkgit:git-log[1], linkgit:git-diff-tree[1], and linkgit:git-hash-object[1] man pages may prove helpful. [[Developing-With-git]] -Developing with git +Developing with Git =================== [[telling-git-your-name]] -Telling git your name +Telling Git your name --------------------- -Before creating any commits, you should introduce yourself to git. The -easiest way to do so is to make sure the following lines appear in a -file named .gitconfig in your home directory: +Before creating any commits, you should introduce yourself to Git. +The easiest way to do so is to use linkgit:git-config[1]: + +------------------------------------------------ +$ git config --global user.name 'Your Name Comes Here' +$ git config --global user.email 'you@yourdomain.example.com' +------------------------------------------------ + +Which will add the following to a file named `.gitconfig` in your +home directory: ------------------------------------------------ [user] @@ -1001,8 +1025,9 @@ file named .gitconfig in your home directory: email = you@yourdomain.example.com ------------------------------------------------ -(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for -details on the configuration file.) +See the "CONFIGURATION FILE" section of linkgit:git-config[1] for +details on the configuration file. The file is plain text, so you can +also edit it with your favorite editor. [[creating-a-new-repository]] @@ -1035,35 +1060,29 @@ Creating a new commit takes three steps: 1. Making some changes to the working directory using your favorite editor. - 2. Telling git about your changes. - 3. Creating the commit using the content you told git about + 2. Telling Git about your changes. + 3. Creating the commit using the content you told Git about in step 2. In practice, you can interleave and repeat steps 1 and 2 as many times as you want: in order to keep track of what you want committed -at step 3, git maintains a snapshot of the tree's contents in a +at step 3, Git maintains a snapshot of the tree's contents in a special staging area called "the index." At the beginning, the content of the index will be identical to -that of the HEAD. The command "git diff --cached", which shows +that of the HEAD. The command `git diff --cached`, which shows the difference between the HEAD and the index, should therefore produce no output at that point. Modifying the index is easy: -To update the index with the new contents of a modified file, use - -------------------------------------------------- -$ git add path/to/file -------------------------------------------------- - -To add the contents of a new file to the index, use +To update the index with the contents of a new or modified file, use ------------------------------------------------- $ git add path/to/file ------------------------------------------------- -To remove a file from the index and from the working tree, +To remove a file from the index and from the working tree, use ------------------------------------------------- $ git rm path/to/file @@ -1084,7 +1103,7 @@ $ git diff shows the difference between the working tree and the index file. -Note that "git add" always adds just the current contents of a file +Note that `git add` always adds just the current contents of a file to the index; further changes to the same file will be ignored unless you run `git add` on the file again. @@ -1094,7 +1113,7 @@ When you're ready, just run $ git commit ------------------------------------------------- -and git will prompt you for a commit message and then create the new +and Git will prompt you for a commit message and then create the new commit. Check to make sure it looks like what you expected with ------------------------------------------------- @@ -1136,24 +1155,28 @@ Creating good commit messages Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough -description. Tools that turn commits into email, for example, use -the first line on the Subject line and the rest of the commit in the -body. +description. The text up to the first blank line in a commit +message is treated as the commit title, and that title is used +throughout Git. For example, linkgit:git-format-patch[1] turns a +commit into email, and it uses the title on the Subject line and the +rest of the commit in the body. + [[ignoring-files]] Ignoring files -------------- -A project will often generate files that you do 'not' want to track with git. +A project will often generate files that you do 'not' want to track with Git. This typically includes files generated by a build process or temporary -backup files made by your editor. Of course, 'not' tracking files with git +backup files made by your editor. Of course, 'not' tracking files with Git is just a matter of 'not' calling `git add` on them. But it quickly becomes annoying to have these untracked files lying around; e.g. they make `git add .` practically useless, and they keep showing up in the output of `git status`. -You can tell git to ignore certain files by creating a file called .gitignore -in the top level of your working directory, with contents such as: +You can tell Git to ignore certain files by creating a file called +`.gitignore` in the top level of your working directory, with contents +such as: ------------------------------------------------- # Lines starting with '#' are considered comments. @@ -1177,10 +1200,10 @@ for other users who clone your repository. If you wish the exclude patterns to affect only certain repositories (instead of every repository for a given project), you may instead put -them in a file in your repository named .git/info/exclude, or in any file -specified by the `core.excludesfile` configuration variable. Some git -commands can also take exclude patterns directly on the command line. -See linkgit:gitignore[5] for the details. +them in a file in your repository named `.git/info/exclude`, or in any +file specified by the `core.excludesfile` configuration variable. +Some Git commands can also take exclude patterns directly on the +command line. See linkgit:gitignore[5] for the details. [[how-to-merge]] How to merge @@ -1193,10 +1216,10 @@ linkgit:git-merge[1]: $ git merge branchname ------------------------------------------------- -merges the development in the branch "branchname" into the current +merges the development in the branch `branchname` into the current branch. -A merge is made by combining the changes made in "branchname" and the +A merge is made by combining the changes made in `branchname` and the changes made up to the latest commit in your current branch since their histories forked. The work tree is overwritten by the result of the merge when this combining is done cleanly, or overwritten by a @@ -1224,7 +1247,7 @@ Automatic merge failed; fix conflicts and then commit the result. Conflict markers are left in the problematic files, and after you resolve the conflicts manually, you can update the index -with the contents and run git commit, as you normally would when +with the contents and run Git commit, as you normally would when creating a new file. If you examine the resulting commit using gitk, you will see that it @@ -1235,7 +1258,7 @@ one to the top of the other branch. Resolving a merge ----------------- -When a merge isn't resolved automatically, git leaves the index and +When a merge isn't resolved automatically, Git leaves the index and the working tree in a special state that gives you all the information you need to help resolve the merge. @@ -1271,14 +1294,14 @@ some information about the merge. Normally you can just use this default message unchanged, but you may add additional commentary of your own if desired. -The above is all you need to know to resolve a simple merge. But git +The above is all you need to know to resolve a simple merge. But Git also provides more information to help resolve conflicts: [[conflict-resolution]] Getting conflict-resolution help during a merge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -All of the changes that git was able to merge automatically are +All of the changes that Git was able to merge automatically are already added to the index file, so linkgit:git-diff[1] shows only the conflicts. It uses an unusual syntax: @@ -1318,7 +1341,7 @@ that part is not conflicting and is not shown. Same for stage 3). The diff above shows the differences between the working-tree version of file.txt and the stage 2 and stage 3 versions. So instead of preceding -each line by a single "+" or "-", it now uses two columns: the first +each line by a single `+` or `-`, it now uses two columns: the first column is used for differences between the first parent and the working directory copy, and the second for differences between the second parent and the working directory copy. (See the "COMBINED DIFF FORMAT" section @@ -1410,7 +1433,7 @@ parents, one pointing at each of the two lines of development that were merged. However, if the current branch is a descendant of the other--so every -commit present in the one is already contained in the other--then git +commit present in the one is already contained in the other--then Git just performs a "fast-forward"; the head of the current branch is moved forward to point at the head of the merged-in branch, without any new commits being created. @@ -1436,7 +1459,7 @@ fundamentally different ways to fix the problem: 2. You can go back and modify the old commit. You should never do this if you have already made the history public; - git does not normally expect the "history" of a project to + Git does not normally expect the "history" of a project to change, and cannot correctly perform repeated merges from a branch that has had its history changed. @@ -1461,7 +1484,7 @@ You can also revert an earlier change, for example, the next-to-last: $ git revert HEAD^ ------------------------------------------------- -In this case git will attempt to undo the old change while leaving +In this case Git will attempt to undo the old change while leaving intact any changes made since then. If more recent changes overlap with the changes to be reverted, then you will be asked to fix conflicts manually, just as in the case of <<resolving-a-merge, @@ -1558,18 +1581,12 @@ $ git stash pop Ensuring good performance ------------------------- -On large repositories, git depends on compression to keep the history -information from taking up too much space on disk or in memory. - -This compression is not performed automatically. Therefore you -should occasionally run linkgit:git-gc[1]: - -------------------------------------------------- -$ git gc -------------------------------------------------- - -to recompress the archive. This can be very time-consuming, so -you may prefer to run `git gc` when you are not doing other work. +On large repositories, Git depends on compression to keep the history +information from taking up too much space on disk or in memory. Some +Git commands may automatically run linkgit:git-gc[1], so you don't +have to worry about running it manually. However, compressing a large +repository may take a while, so you may want to call `gc` explicitly +to avoid automatic compression kicking in when it is not convenient. [[ensuring-reliability]] @@ -1582,7 +1599,7 @@ Checking the repository for corruption The linkgit:git-fsck[1] command runs a number of self-consistency checks on the repository, and reports on any problems. This may take some -time. The most common warning by far is about "dangling" objects: +time. ------------------------------------------------- $ git fsck @@ -1597,9 +1614,11 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f ... ------------------------------------------------- -Dangling objects are not a problem. At worst they may take up a little -extra disk space. They can sometimes provide a last-resort method for -recovering lost work--see <<dangling-objects>> for details. +You will see informational messages on dangling objects. They are objects +that still exist in the repository but are no longer referenced by any of +your branches, and can (and will) be removed after a while with `gc`. +You can run `git fsck --no-dangling` to suppress these messages, and still +view real errors. [[recovering-lost-changes]] Recovering lost changes @@ -1609,11 +1628,11 @@ Recovering lost changes Reflogs ^^^^^^^ -Say you modify a branch with `linkgit:git-reset[1] --hard`, and then -realize that the branch was the only reference you had to that point in -history. +Say you modify a branch with <<fixing-mistakes,`git reset --hard`>>, +and then realize that the branch was the only reference you had to +that point in history. -Fortunately, git also keeps a log, called a "reflog", of all the +Fortunately, Git also keeps a log, called a "reflog", of all the previous values of each branch. So in this case you can still find the old history using, for example, @@ -1622,8 +1641,8 @@ $ git log master@{1} ------------------------------------------------- This lists the commits reachable from the previous version of the -"master" branch head. This syntax can be used with any git command -that accepts a commit, not just with git log. Some other examples: +`master` branch head. This syntax can be used with any Git command +that accepts a commit, not just with `git log`. Some other examples: ------------------------------------------------- $ git show master@{2} # See where the branch pointed 2, @@ -1648,7 +1667,7 @@ pruned. See linkgit:git-reflog[1] and linkgit:git-gc[1] to learn how to control this pruning, and see the "SPECIFYING REVISIONS" section of linkgit:gitrevisions[7] for details. -Note that the reflog history is very different from normal git history. +Note that the reflog history is very different from normal Git history. While normal history is shared by every repository that works on the same project, the reflog history is not shared: it tells you only about how the branches in your local repository have changed over time. @@ -1727,8 +1746,8 @@ one step: $ git pull origin master ------------------------------------------------- -In fact, if you have "master" checked out, then this branch has been -configured by "git clone" to get changes from the HEAD branch of the +In fact, if you have `master` checked out, then this branch has been +configured by `git clone` to get changes from the HEAD branch of the origin repository. So often you can accomplish the above with just a simple @@ -1743,11 +1762,11 @@ the current branch. More generally, a branch that is created from a remote-tracking branch will pull by default from that branch. See the descriptions of the -branch.<name>.remote and branch.<name>.merge options in +`branch.<name>.remote` and `branch.<name>.merge` options in linkgit:git-config[1], and the discussion of the `--track` option in linkgit:git-checkout[1], to learn how to control these defaults. -In addition to saving you keystrokes, "git pull" also helps you by +In addition to saving you keystrokes, `git pull` also helps you by producing a default commit message documenting the branch and repository that you pulled from. @@ -1755,7 +1774,7 @@ repository that you pulled from. <<fast-forwards,fast-forward>>; instead, your branch will just be updated to point to the latest commit from the upstream branch.) -The `git pull` command can also be given "." as the "remote" repository, +The `git pull` command can also be given `.` as the "remote" repository, in which case it just merges in a branch from the current repository; so the commands @@ -1764,7 +1783,7 @@ $ git pull . branch $ git merge branch ------------------------------------------------- -are roughly equivalent. The former is actually very commonly used. +are roughly equivalent. [[submitting-patches]] Submitting patches to a project @@ -1780,7 +1799,14 @@ $ git format-patch origin ------------------------------------------------- will produce a numbered series of files in the current directory, one -for each patch in the current branch but not in origin/HEAD. +for each patch in the current branch but not in `origin/HEAD`. + +`git format-patch` can include an initial "cover letter". You can insert +commentary on individual patches after the three dash line which +`format-patch` places after the commit message but before the patch +itself. If you use `git notes` to track your cover letter material, +`git format-patch --notes` will include the commit's notes in a similar +manner. You can then import these into your mail client and send them by hand. However, if you have a lot to send at once, you may prefer to @@ -1795,7 +1821,7 @@ Importing patches to a project Git also provides a tool called linkgit:git-am[1] (am stands for "apply mailbox"), for importing such an emailed series of patches. Just save all of the patch-containing messages, in order, into a -single mailbox file, say "patches.mbox", then run +single mailbox file, say `patches.mbox`, then run ------------------------------------------------- $ git am -3 patches.mbox @@ -1803,18 +1829,18 @@ $ git am -3 patches.mbox Git will apply each patch in order; if any conflicts are found, it will stop, and you can fix the conflicts as described in -"<<resolving-a-merge,Resolving a merge>>". (The "-3" option tells -git to perform a merge; if you would prefer it just to abort and +"<<resolving-a-merge,Resolving a merge>>". (The `-3` option tells +Git to perform a merge; if you would prefer it just to abort and leave your tree and index untouched, you may omit that option.) Once the index is updated with the results of the conflict resolution, instead of creating a new commit, just run ------------------------------------------------- -$ git am --resolved +$ git am --continue ------------------------------------------------- -and git will create the commit for you and continue applying the +and Git will create the commit for you and continue applying the remaining patches from the mailbox. The final result will be a series of commits, one for each patch in @@ -1822,7 +1848,7 @@ the original mailbox, with authorship and commit log message each taken from the message containing each patch. [[public-repositories]] -Public git repositories +Public Git repositories ----------------------- Another way to submit changes to a project is to tell the maintainer @@ -1879,7 +1905,7 @@ We explain how to do this in the following sections. Setting up a public repository ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Assume your personal repository is in the directory ~/proj. We +Assume your personal repository is in the directory `~/proj`. We first create a new clone of the repository and tell `git daemon` that it is meant to be public: @@ -1889,28 +1915,28 @@ $ touch proj.git/git-daemon-export-ok ------------------------------------------------- The resulting directory proj.git contains a "bare" git repository--it is -just the contents of the ".git" directory, without any files checked out +just the contents of the `.git` directory, without any files checked out around it. -Next, copy proj.git to the server where you plan to host the +Next, copy `proj.git` to the server where you plan to host the public repository. You can use scp, rsync, or whatever is most convenient. [[exporting-via-git]] -Exporting a git repository via the git protocol +Exporting a Git repository via the Git protocol ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is the preferred method. If someone else administers the server, they should tell you what -directory to put the repository in, and what git:// URL it will appear -at. You can then skip to the section +directory to put the repository in, and what `git://` URL it will +appear at. You can then skip to the section "<<pushing-changes-to-a-public-repository,Pushing changes to a public repository>>", below. Otherwise, all you need to do is start linkgit:git-daemon[1]; it will listen on port 9418. By default, it will allow access to any directory -that looks like a git directory and contains the magic file +that looks like a Git directory and contains the magic file git-daemon-export-ok. Passing some directory paths as `git daemon` arguments will further restrict the exports to those paths. @@ -1919,13 +1945,13 @@ linkgit:git-daemon[1] man page for details. (See especially the examples section.) [[exporting-via-http]] -Exporting a git repository via http +Exporting a git repository via HTTP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The git protocol gives better performance and reliability, but on a -host with a web server set up, http exports may be simpler to set up. +The Git protocol gives better performance and reliability, but on a +host with a web server set up, HTTP exports may be simpler to set up. -All you need to do is place the newly created bare git repository in +All you need to do is place the newly created bare Git repository in a directory that is exported by the web server, and make some adjustments to give web clients some extra information they need: @@ -1939,7 +1965,7 @@ $ mv hooks/post-update.sample hooks/post-update (For an explanation of the last two lines, see linkgit:git-update-server-info[1] and linkgit:githooks[5].) -Advertise the URL of proj.git. Anybody else should then be able to +Advertise the URL of `proj.git`. Anybody else should then be able to clone or pull from that URL, for example with a command line like: ------------------------------------------------- @@ -1947,9 +1973,9 @@ $ git clone http://yourserver.com/~you/proj.git ------------------------------------------------- (See also -link:howto/setup-git-server-over-http.txt[setup-git-server-over-http] +link:howto/setup-git-server-over-http.html[setup-git-server-over-http] for a slightly more sophisticated setup using WebDAV which also -allows pushing over http.) +allows pushing over HTTP.) [[pushing-changes-to-a-public-repository]] Pushing changes to a public repository @@ -1962,8 +1988,8 @@ access, which you will need to update the public repository with the latest changes created in your private repository. The simplest way to do this is using linkgit:git-push[1] and ssh; to -update the remote branch named "master" with the latest state of your -branch named "master", run +update the remote branch named `master` with the latest state of your +branch named `master`, run ------------------------------------------------- $ git push ssh://yourserver.com/~you/proj.git master:master @@ -1979,31 +2005,37 @@ As with `git fetch`, `git push` will complain if this does not result in a <<fast-forwards,fast-forward>>; see the following section for details on handling this case. -Note that the target of a "push" is normally a +Note that the target of a `push` is normally a <<def_bare_repository,bare>> repository. You can also push to a -repository that has a checked-out working tree, but the working tree -will not be updated by the push. This may lead to unexpected results if -the branch you push to is the currently checked-out branch! +repository that has a checked-out working tree, but a push to update the +currently checked-out branch is denied by default to prevent confusion. +See the description of the receive.denyCurrentBranch option +in linkgit:git-config[1] for details. As with `git fetch`, you may also set up configuration options to -save typing; so, for example, after +save typing; so, for example: + +------------------------------------------------- +$ git remote add public-repo ssh://yourserver.com/~you/proj.git +------------------------------------------------- + +adds the following to `.git/config`: ------------------------------------------------- -$ cat >>.git/config <<EOF [remote "public-repo"] - url = ssh://yourserver.com/~you/proj.git -EOF + url = yourserver.com:proj.git + fetch = +refs/heads/*:refs/remotes/example/* ------------------------------------------------- -you should be able to perform the above push with just +which lets you do the same push with just ------------------------------------------------- $ git push public-repo master ------------------------------------------------- -See the explanations of the remote.<name>.url, branch.<name>.remote, -and remote.<name>.push options in linkgit:git-config[1] for -details. +See the explanations of the `remote.<name>.url`, +`branch.<name>.remote`, and `remote.<name>.push` options in +linkgit:git-config[1] for details. [[forcing-push]] What to do when a push fails @@ -2034,6 +2066,13 @@ branch name with a plus sign: $ git push ssh://yourserver.com/~you/proj.git +master ------------------------------------------------- +Note the addition of the `+` sign. Alternatively, you can use the +`-f` flag to force the remote update, as in: + +------------------------------------------------- +$ git push -f ssh://yourserver.com/~you/proj.git master +------------------------------------------------- + Normally whenever a branch head in a public repository is modified, it is modified to point to a descendant of the commit that it pointed to before. By forcing a push in this situation, you break that convention. @@ -2061,9 +2100,9 @@ all push to and pull from a single shared repository. See linkgit:gitcvs-migration[7] for instructions on how to set this up. -However, while there is nothing wrong with git's support for shared +However, while there is nothing wrong with Git's support for shared repositories, this mode of operation is not generally recommended, -simply because the mode of collaboration that git supports--by +simply because the mode of collaboration that Git supports--by exchanging patches and pulling from public repositories--has so many advantages over the central shared repository: @@ -2087,8 +2126,8 @@ Allowing web browsing of a repository ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The gitweb cgi script provides users an easy way to browse your -project's files and history without having to install git; see the file -gitweb/INSTALL in the git source tree for instructions on setting it up. +project's files and history without having to install Git; see the file +gitweb/INSTALL in the Git source tree for instructions on setting it up. [[sharing-development-examples]] Examples @@ -2098,7 +2137,7 @@ Examples Maintaining topic branches for a Linux subsystem maintainer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This describes how Tony Luck uses git in his role as maintainer of the +This describes how Tony Luck uses Git in his role as maintainer of the IA64 architecture for the Linux kernel. He uses two public branches: @@ -2119,7 +2158,7 @@ To set this up, first create your work tree by cloning Linus's public tree: ------------------------------------------------- -$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work +$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git work $ cd work ------------------------------------------------- @@ -2131,7 +2170,7 @@ linkgit:git-fetch[1] to keep them up-to-date; see Now create the branches in which you are going to work; these start out at the current tip of origin/master branch, and should be set up (using -the --track option to linkgit:git-branch[1]) to merge changes in from +the `--track` option to linkgit:git-branch[1]) to merge changes in from Linus by default. ------------------------------------------------- @@ -2148,9 +2187,9 @@ $ git checkout release && git pull Important note! If you have any local changes in these branches, then this merge will create a commit object in the history (with no local -changes git will simply do a "fast-forward" merge). Many people dislike +changes Git will simply do a "fast-forward" merge). Many people dislike the "noise" that this creates in the Linux history, so you should avoid -doing this capriciously in the "release" branch, as these noisy commits +doing this capriciously in the `release` branch, as these noisy commits will become part of the permanent history when you ask Linus to pull from the release branch. @@ -2161,7 +2200,7 @@ make it easy to push both branches to your public tree. (See ------------------------------------------------- $ cat >> .git/config <<EOF [remote "mytree"] - url = master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git + url = master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux.git push = release push = test EOF @@ -2192,7 +2231,7 @@ patches), and create a new branch from a recent stable tag of Linus's branch. Picking a stable base for your branch will: 1) help you: by avoiding inclusion of unrelated and perhaps lightly tested changes -2) help future bug hunters that use "git bisect" to find problems +2) help future bug hunters that use `git bisect` to find problems ------------------------------------------------- $ git checkout -b speed-up-spinlocks v2.6.35 @@ -2206,23 +2245,23 @@ commit to this branch. $ ... patch ... test ... commit [ ... patch ... test ... commit ]* ------------------------------------------------- -When you are happy with the state of this change, you can pull it into the +When you are happy with the state of this change, you can merge it into the "test" branch in preparation to make it public: ------------------------------------------------- -$ git checkout test && git pull . speed-up-spinlocks +$ git checkout test && git merge speed-up-spinlocks ------------------------------------------------- It is unlikely that you would have any conflicts here ... but you might if you spent a while on this step and had also pulled new versions from upstream. Some time later when enough time has passed and testing done, you can pull the -same branch into the "release" tree ready to go upstream. This is where you +same branch into the `release` tree ready to go upstream. This is where you see the value of keeping each patch (or patch series) in its own branch. It -means that the patches can be moved into the "release" tree in any order. +means that the patches can be moved into the `release` tree in any order. ------------------------------------------------- -$ git checkout release && git pull . speed-up-spinlocks +$ git checkout release && git merge speed-up-spinlocks ------------------------------------------------- After a while, you will have a number of branches, and despite the @@ -2252,7 +2291,7 @@ If it has been merged, then there will be no output.) Once a patch completes the great cycle (moving from test to release, then pulled by Linus, and finally coming back into your local -"origin/master" branch), the branch for this change is no longer needed. +`origin/master` branch), the branch for this change is no longer needed. You detect this when the output from: ------------------------------------------------- @@ -2267,27 +2306,23 @@ $ git branch -d branchname Some changes are so trivial that it is not necessary to create a separate branch and then merge into each of the test and release branches. For -these changes, just apply directly to the "release" branch, and then -merge that into the "test" branch. - -To create diffstat and shortlog summaries of changes to include in a "please -pull" request to Linus you can use: - -------------------------------------------------- -$ git diff --stat origin..release -------------------------------------------------- +these changes, just apply directly to the `release` branch, and then +merge that into the `test` branch. -and +After pushing your work to `mytree`, you can use +linkgit:git-request-pull[1] to prepare a "please pull" request message +to send to Linus: ------------------------------------------------- -$ git log -p origin..release | git shortlog +$ git push mytree +$ git request-pull origin mytree release ------------------------------------------------- Here are some of the scripts that simplify all this even further. ------------------------------------------------- ==== update script ==== -# Update a branch in my GIT tree. If the branch to be updated +# Update a branch in my Git tree. If the branch to be updated # is origin, then pull from kernel.org. Otherwise merge # origin/master branch into test|release branch @@ -2305,7 +2340,7 @@ origin) fi ;; *) - echo "Usage: $0 origin|test|release" 1>&2 + echo "usage: $0 origin|test|release" 1>&2 exit 1 ;; esac @@ -2319,7 +2354,7 @@ pname=$0 usage() { - echo "Usage: $pname branch test|release" 1>&2 + echo "usage: $pname branch test|release" 1>&2 exit 1 } @@ -2345,7 +2380,7 @@ esac ------------------------------------------------- ==== status script ==== -# report on status of my ia64 GIT tree +# report on status of my ia64 Git tree gb=$(tput setab 2) rb=$(tput setab 1) @@ -2401,7 +2436,7 @@ Rewriting history and maintaining patch series Normally commits are only added to a project, never taken away or replaced. Git is designed with this assumption, and violating it will -cause git's merge machinery (for example) to do the wrong thing. +cause Git's merge machinery (for example) to do the wrong thing. However, there is a situation in which it can be useful to violate this assumption. @@ -2443,8 +2478,8 @@ you are rewriting history. Keeping a patch series up to date using git rebase -------------------------------------------------- -Suppose that you create a branch "mywork" on a remote-tracking branch -"origin", and create some commits on top of it: +Suppose that you create a branch `mywork` on a remote-tracking branch +`origin`, and create some commits on top of it: ------------------------------------------------- $ git checkout -b mywork origin @@ -2456,7 +2491,7 @@ $ git commit ------------------------------------------------- You have performed no merges into mywork, so it is just a simple linear -sequence of patches on top of "origin": +sequence of patches on top of `origin`: ................................................ o--o--O <-- origin @@ -2465,7 +2500,7 @@ sequence of patches on top of "origin": ................................................ Some more interesting work has been done in the upstream project, and -"origin" has advanced: +`origin` has advanced: ................................................ o--o--O--o--o--o <-- origin @@ -2473,7 +2508,7 @@ Some more interesting work has been done in the upstream project, and a--b--c <-- mywork ................................................ -At this point, you could use "pull" to merge your changes back in; +At this point, you could use `pull` to merge your changes back in; the result would create a new merge commit, like this: ................................................ @@ -2492,7 +2527,7 @@ $ git rebase origin ------------------------------------------------- This will remove each of your commits from mywork, temporarily saving -them as patches (in a directory named ".git/rebase-apply"), update mywork to +them as patches (in a directory named `.git/rebase-apply`), update mywork to point at the latest version of origin, then apply each of the saved patches to the new mywork. The result will look like: @@ -2512,7 +2547,7 @@ running `git commit`, just run $ git rebase --continue ------------------------------------------------- -and git will continue applying the rest of the patches. +and Git will continue applying the rest of the patches. At any point you may use the `--abort` option to abort this process and return mywork to the state it had before you started the rebase: @@ -2521,6 +2556,12 @@ return mywork to the state it had before you started the rebase: $ git rebase --abort ------------------------------------------------- +If you need to reorder or edit a number of commits in a branch, it may +be easier to use `git rebase -i`, which allows you to reorder and +squash commits, as well as marking them for individual editing during +the rebase. See <<interactive-rebase>> for details, and +<<reordering-patch-series>> for alternatives. + [[rewriting-one-commit]] Rewriting a single commit ------------------------- @@ -2534,72 +2575,89 @@ $ git commit --amend which will replace the old commit by a new commit incorporating your changes, giving you a chance to edit the old commit message first. +This is useful for fixing typos in your last commit, or for adjusting +the patch contents of a poorly staged commit. -You can also use a combination of this and linkgit:git-rebase[1] to -replace a commit further back in your history and recreate the -intervening changes on top of it. First, tag the problematic commit -with - -------------------------------------------------- -$ git tag bad mywork~5 -------------------------------------------------- +If you need to amend commits from deeper in your history, you can +use <<interactive-rebase,interactive rebase's `edit` instruction>>. -(Either gitk or `git log` may be useful for finding the commit.) +[[reordering-patch-series]] +Reordering or selecting from a patch series +------------------------------------------- -Then check out that commit, edit it, and rebase the rest of the series -on top of it (note that we could check out the commit on a temporary -branch, but instead we're using a <<detached-head,detached head>>): +Sometimes you want to edit a commit deeper in your history. One +approach is to use `git format-patch` to create a series of patches +and then reset the state to before the patches: ------------------------------------------------- -$ git checkout bad -$ # make changes here and update the index -$ git commit --amend -$ git rebase --onto HEAD bad mywork +$ git format-patch origin +$ git reset --hard origin ------------------------------------------------- -When you're done, you'll be left with mywork checked out, with the top -patches on mywork reapplied on top of your modified commit. You can -then clean up with +Then modify, reorder, or eliminate patches as needed before applying +them again with linkgit:git-am[1]: ------------------------------------------------- -$ git tag -d bad +$ git am *.patch ------------------------------------------------- -Note that the immutable nature of git history means that you haven't really -"modified" existing commits; instead, you have replaced the old commits with -new commits having new object names. +[[interactive-rebase]] +Using interactive rebases +------------------------- -[[reordering-patch-series]] -Reordering or selecting from a patch series -------------------------------------------- +You can also edit a patch series with an interactive rebase. This is +the same as <<reordering-patch-series,reordering a patch series using +`format-patch`>>, so use whichever interface you like best. -Given one existing commit, the linkgit:git-cherry-pick[1] command -allows you to apply the change introduced by that commit and create a -new commit that records it. So, for example, if "mywork" points to a -series of patches on top of "origin", you might do something like: +Rebase your current HEAD on the last commit you want to retain as-is. +For example, if you want to reorder the last 5 commits, use: ------------------------------------------------- -$ git checkout -b mywork-new origin -$ gitk origin..mywork & +$ git rebase -i HEAD~5 ------------------------------------------------- -and browse through the list of patches in the mywork branch using gitk, -applying them (possibly in a different order) to mywork-new using -cherry-pick, and possibly modifying them as you go using `git commit --amend`. -The linkgit:git-gui[1] command may also help as it allows you to -individually select diff hunks for inclusion in the index (by -right-clicking on the diff hunk and choosing "Stage Hunk for Commit"). - -Another technique is to use `git format-patch` to create a series of -patches, then reset the state to before the patches: +This will open your editor with a list of steps to be taken to perform +your rebase. ------------------------------------------------- -$ git format-patch origin -$ git reset --hard origin -------------------------------------------------- +pick deadbee The oneline of this commit +pick fa1afe1 The oneline of the next commit +... -Then modify, reorder, or eliminate patches as preferred before applying -them again with linkgit:git-am[1]. +# Rebase c0ffeee..deadbee onto c0ffeee +# +# Commands: +# p, pick = use commit +# r, reword = use commit, but edit the commit message +# e, edit = use commit, but stop for amending +# s, squash = use commit, but meld into previous commit +# f, fixup = like "squash", but discard this commit's log message +# x, exec = run command (the rest of the line) using shell +# +# These lines can be re-ordered; they are executed from top to bottom. +# +# If you remove a line here THAT COMMIT WILL BE LOST. +# +# However, if you remove everything, the rebase will be aborted. +# +# Note that empty commits are commented out +------------------------------------------------- + +As explained in the comments, you can reorder commits, squash them +together, edit commit messages, etc. by editing the list. Once you +are satisfied, save the list and close your editor, and the rebase +will begin. + +The rebase will stop where `pick` has been replaced with `edit` or +when a step in the list fails to mechanically resolve conflicts and +needs your help. When you are done editing and/or resolving conflicts +you can continue with `git rebase --continue`. If you decide that +things are getting too hairy, you can always bail out with `git rebase +--abort`. Even after the rebase is complete, you can still recover +the original branch by using the <<reflogs,reflog>>. + +For a more detailed discussion of the procedure and additional tips, +see the "INTERACTIVE MODE" section of linkgit:git-rebase[1]. [[patch-series-tools]] Other tools @@ -2646,7 +2704,7 @@ Git has no way of knowing that the new head is an updated version of the old head; it treats this situation exactly the same as it would if two developers had independently done the work on the old and new heads in parallel. At this point, if someone attempts to merge the new head -in to their branch, git will attempt to merge together the two (old and +in to their branch, Git will attempt to merge together the two (old and new) lines of development, instead of trying to replace the old by the new. The results are likely to be unexpected. @@ -2719,7 +2777,7 @@ linear history: Bisecting between Z and D* would hit a single culprit commit Y*, and understanding why Y* was broken would probably be easier. -Partly for this reason, many experienced git users, even when +Partly for this reason, many experienced Git users, even when working on an otherwise merge-heavy project, keep the history linear by rebasing against the latest upstream version before publishing. @@ -2740,10 +2798,10 @@ arbitrary name: $ git fetch origin todo:my-todo-work ------------------------------------------------- -The first argument, "origin", just tells git to fetch from the -repository you originally cloned from. The second argument tells git -to fetch the branch named "todo" from the remote repository, and to -store it locally under the name refs/heads/my-todo-work. +The first argument, `origin`, just tells Git to fetch from the +repository you originally cloned from. The second argument tells Git +to fetch the branch named `todo` from the remote repository, and to +store it locally under the name `refs/heads/my-todo-work`. You can also fetch branches from other repositories; so @@ -2751,8 +2809,8 @@ You can also fetch branches from other repositories; so $ git fetch git://example.com/proj.git master:example-master ------------------------------------------------- -will create a new branch named "example-master" and store in it the -branch named "master" from the repository at the given URL. If you +will create a new branch named `example-master` and store in it the +branch named `master` from the repository at the given URL. If you already have a branch named example-master, it will attempt to <<fast-forwards,fast-forward>> to the commit given by example.com's master branch. In more detail: @@ -2761,7 +2819,7 @@ master branch. In more detail: git fetch and fast-forwards --------------------------- -In the previous example, when updating an existing branch, "git fetch" +In the previous example, when updating an existing branch, `git fetch` checks to make sure that the most recent commit on the remote branch is a descendant of the most recent commit on your copy of the branch before updating your copy of the branch to point at the new @@ -2787,11 +2845,11 @@ resulting in a situation like: o--o--o <-- new head of the branch ................................................ -In this case, "git fetch" will fail, and print out a warning. +In this case, `git fetch` will fail, and print out a warning. -In that case, you can still force git to update to the new head, as +In that case, you can still force Git to update to the new head, as described in the following section. However, note that in the -situation above this may mean losing the commits labeled "a" and "b", +situation above this may mean losing the commits labeled `a` and `b`, unless you've already created a reference of your own pointing to them. @@ -2806,7 +2864,7 @@ descendant of the old head, you may force the update with: $ git fetch git://example.com/proj.git +master:refs/remotes/example/master ------------------------------------------------- -Note the addition of the "+" sign. Alternatively, you can use the "-f" +Note the addition of the `+` sign. Alternatively, you can use the `-f` flag to force updates of all the fetched branches, as in: ------------------------------------------------- @@ -2820,9 +2878,9 @@ may be lost, as we saw in the previous section. Configuring remote-tracking branches ------------------------------------ -We saw above that "origin" is just a shortcut to refer to the +We saw above that `origin` is just a shortcut to refer to the repository that you originally cloned from. This information is -stored in git configuration variables, which you can see using +stored in Git configuration variables, which you can see using linkgit:git-config[1]: ------------------------------------------------- @@ -2838,48 +2896,34 @@ branch.master.merge=refs/heads/master If there are other repositories that you also use frequently, you can create similar configuration options to save typing; for example, -after ------------------------------------------------- -$ git config remote.example.url git://example.com/proj.git +$ git remote add example git://example.com/proj.git ------------------------------------------------- -then the following two commands will do the same thing: +adds the following to `.git/config`: ------------------------------------------------- -$ git fetch git://example.com/proj.git master:refs/remotes/example/master -$ git fetch example master:refs/remotes/example/master +[remote "example"] + url = git://example.com/proj.git + fetch = +refs/heads/*:refs/remotes/example/* ------------------------------------------------- -Even better, if you add one more option: - -------------------------------------------------- -$ git config remote.example.fetch master:refs/remotes/example/master -------------------------------------------------- +Also note that the above configuration can be performed by directly +editing the file `.git/config` instead of using linkgit:git-remote[1]. -then the following commands will all do the same thing: +After configuring the remote, the following three commands will do the +same thing: ------------------------------------------------- -$ git fetch git://example.com/proj.git master:refs/remotes/example/master -$ git fetch example master:refs/remotes/example/master +$ git fetch git://example.com/proj.git +refs/heads/*:refs/remotes/example/* +$ git fetch example +refs/heads/*:refs/remotes/example/* $ git fetch example ------------------------------------------------- -You can also add a "+" to force the update each time: - -------------------------------------------------- -$ git config remote.example.fetch +master:ref/remotes/example/master -------------------------------------------------- - -Don't do this unless you're sure you won't mind "git fetch" possibly -throwing away commits on 'example/master'. - -Also note that all of the above configuration can be performed by -directly editing the file .git/config instead of using -linkgit:git-config[1]. - See linkgit:git-config[1] for more details on the configuration -options mentioned above. +options mentioned above and linkgit:git-fetch[1] for more details on +the refspec syntax. [[git-concepts]] @@ -2888,7 +2932,7 @@ Git concepts Git is built on a small number of simple but powerful ideas. While it is possible to get things done without understanding them, you will find -git much more intuitive if you do. +Git much more intuitive if you do. We start with the most important, the <<def_object_database,object database>> and the <<def_index,index>>. @@ -2943,7 +2987,7 @@ Commit Object ~~~~~~~~~~~~~ The "commit" object links a physical state of a tree with a description -of how we got there and why. Use the --pretty=raw option to +of how we got there and why. Use the `--pretty=raw` option to linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite commit: @@ -2964,7 +3008,7 @@ As you can see, a commit is defined by: - a tree: The SHA-1 name of a tree object (as defined below), representing the contents of a directory at a certain point in time. -- parent(s): The SHA-1 name of some number of commits which represent the +- parent(s): The SHA-1 name(s) of some number of commits which represent the immediately previous step(s) in the history of the project. The example above has one parent; merge commits may have more than one. A commit with no parents is called a "root" commit, and @@ -2982,10 +3026,10 @@ As you can see, a commit is defined by: Note that a commit does not itself contain any information about what actually changed; all changes are calculated by comparing the contents of the tree referred to by this commit with the trees associated with -its parents. In particular, git does not attempt to record file renames +its parents. In particular, Git does not attempt to record file renames explicitly, though it can identify cases where the existence of the same file data at changing paths suggests a rename. (See, for example, the --M option to linkgit:git-diff[1]). +`-M` option to linkgit:git-diff[1]). A commit is usually created by linkgit:git-commit[1], which creates a commit whose parent is normally the current HEAD, and whose tree is @@ -3021,14 +3065,14 @@ another tree, representing the contents of a subdirectory. Since trees and blobs, like all other objects, are named by the SHA-1 hash of their contents, two trees have the same SHA-1 name if and only if their contents (including, recursively, the contents of all subdirectories) -are identical. This allows git to quickly determine the differences +are identical. This allows Git to quickly determine the differences between two related tree objects, since it can ignore any entries with identical object names. (Note: in the presence of submodules, trees may also have commits as entries. See <<submodules>> for documentation.) -Note that the files all have mode 644 or 755: git actually only pays +Note that the files all have mode 644 or 755: Git actually only pays attention to the executable bit. [[blob-object]] @@ -3036,7 +3080,7 @@ Blob Object ~~~~~~~~~~~ You can use linkgit:git-show[1] to examine the contents of a blob; take, -for example, the blob in the entry for "COPYING" from the tree above: +for example, the blob in the entry for `COPYING` from the tree above: ------------------------------------------------ $ git show 6ff87c4664 @@ -3089,7 +3133,7 @@ sending out a single email that tells the people the name (SHA-1 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... +To assist in this, Git also provides the tag object... [[tag-object]] Tag Object @@ -3119,14 +3163,14 @@ nLE/L9aUXdWeTFPron96DLA= See the linkgit:git-tag[1] command to learn how to create and verify tag objects. (Note that linkgit:git-tag[1] can also be used to create "lightweight tags", which are not tag objects at all, but just simple -references whose names begin with "refs/tags/"). +references whose names begin with `refs/tags/`). [[pack-files]] -How git stores objects efficiently: pack files +How Git stores objects efficiently: pack files ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Newly created objects are initially created in a file named after the -object's SHA-1 hash (stored in .git/objects). +object's SHA-1 hash (stored in `.git/objects`). Unfortunately this system becomes inefficient once a project has a lot of objects. Try this on an old project: @@ -3140,26 +3184,24 @@ The first number is the number of objects which are kept in individual files. The second is the amount of space taken up by those "loose" objects. -You can save space and make git faster by moving these loose objects in +You can save space and make Git faster by moving these loose objects in to a "pack file", which stores a group of objects in an efficient compressed format; the details of how pack files are formatted can be -found in link:technical/pack-format.txt[technical/pack-format.txt]. +found in link:technical/pack-format.html[pack format]. To put the loose objects into a pack, just run git repack: ------------------------------------------------ $ git repack -Generating pack... -Done counting 6020 objects. -Deltifying 6020 objects. - 100% (6020/6020) done -Writing 6020 objects. - 100% (6020/6020) done -Total 6020, written 6020 (delta 4070), reused 0 (delta 0) -Pack pack-3e54ad29d5b2e05838c75df582c65257b8d08e1c created. +Counting objects: 6020, done. +Delta compression using up to 4 threads. +Compressing objects: 100% (6020/6020), done. +Writing objects: 100% (6020/6020), done. +Total 6020 (delta 4070), reused 0 (delta 0) ------------------------------------------------ -You can then run +This creates a single "pack file" in .git/objects/pack/ +containing all currently unpacked objects. You can then run ------------------------------------------------ $ git prune @@ -3167,9 +3209,9 @@ $ git prune to remove any of the "loose" objects that are now contained in the pack. This will also remove any unreferenced objects (which may be -created when, for example, you use "git reset" to remove a commit). +created when, for example, you use `git reset` to remove a commit). You can verify that the loose objects are gone by looking at the -.git/objects directory or by running +`.git/objects` directory or by running ------------------------------------------------ $ git count-objects @@ -3196,7 +3238,7 @@ branch still exists, as does everything it pointed to. The branch pointer itself just doesn't, since you replaced it with another one. There are also other situations that cause dangling objects. For -example, a "dangling blob" may arise because you did a "git add" of a +example, a "dangling blob" may arise because you did a `git add` of a file, but then, before you actually committed it and made it part of the bigger picture, you changed something else in that file and committed that *updated* thing--the old state that you added originally ends up @@ -3239,14 +3281,14 @@ $ git show <dangling-blob/tree-sha-goes-here> ------------------------------------------------ to show what the contents of the blob were (or, for a tree, basically -what the "ls" for that directory was), and that may give you some idea +what the `ls` for that directory was), and that may give you some idea of what the operation was that left that dangling object. Usually, dangling blobs and trees aren't very interesting. They're almost always the result of either being a half-way mergebase (the blob will often even have the conflict markers from a merge in it, if you have had conflicting merges that you fixed up by hand), or simply -because you interrupted a "git fetch" with ^C or something like that, +because you interrupted a `git fetch` with ^C or something like that, leaving _some_ of the new objects in the object database, but just dangling and useless. @@ -3257,28 +3299,22 @@ state, you can just prune all unreachable objects: $ git prune ------------------------------------------------ -and they'll be gone. But you should only run "git prune" on a quiescent +and they'll be gone. (You should only run `git prune` on a quiescent repository--it's kind of like doing a filesystem fsck recovery: you don't want to do that while the filesystem is mounted. - -(The same is true of "git fsck" itself, btw, but since -`git fsck` never actually *changes* the repository, it just reports -on what it found, `git fsck` itself is never 'dangerous' to run. -Running it while somebody is actually changing the repository can cause -confusing and scary messages, but it won't actually do anything bad. In -contrast, running "git prune" while somebody is actively changing the -repository is a *BAD* idea). +`git prune` is designed not to cause any harm in such cases of concurrent +accesses to a repository but you might receive confusing or scary messages.) [[recovering-from-repository-corruption]] Recovering from repository corruption ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -By design, git treats data trusted to it with caution. However, even in -the absence of bugs in git itself, it is still possible that hardware or +By design, Git treats data trusted to it with caution. However, even in +the absence of bugs in Git itself, it is still possible that hardware or operating system errors could corrupt data. The first defense against such problems is backups. You can back up a -git directory using clone, or just using cp, tar, or any other backup +Git directory using clone, or just using cp, tar, or any other backup mechanism. As a last resort, you can search for the corrupted objects and attempt @@ -3295,19 +3331,16 @@ it is with linkgit:git-fsck[1]; this may be time-consuming. Assume the output looks like this: ------------------------------------------------ -$ git fsck --full +$ git fsck --full --no-dangling broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 to blob 4b9458b3786228369c63936db65827de3cc06200 missing blob 4b9458b3786228369c63936db65827de3cc06200 ------------------------------------------------ -(Typically there will be some "dangling object" messages too, but they -aren't interesting.) - Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6 points to it. If you could find just one copy of that missing blob object, possibly in some other repository, you could move it into -.git/objects/4b/9458b3... and be done. Suppose you can't. You can +`.git/objects/4b/9458b3...` and be done. Suppose you can't. You can still examine the tree that pointed to it with linkgit:git-ls-tree[1], which might output something like: @@ -3322,10 +3355,10 @@ $ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 ------------------------------------------------ So now you know that the missing blob was the data for a file named -"myfile". And chances are you can also identify the directory--let's -say it's in "somedirectory". If you're lucky the missing copy might be +`myfile`. And chances are you can also identify the directory--let's +say it's in `somedirectory`. If you're lucky the missing copy might be the same as the copy you have checked out in your working tree at -"somedirectory/myfile"; you can test whether that's right with +`somedirectory/myfile`; you can test whether that's right with linkgit:git-hash-object[1]: ------------------------------------------------ @@ -3364,8 +3397,8 @@ Date: :100644 100644 oldsha... 4b9458b... M somedirectory/myfile ------------------------------------------------ -This tells you that the immediately preceding version of the file was -"newsha", and that the immediately following version was "oldsha". +This tells you that the immediately following version of the file was +"newsha", and that the immediately preceding version was "oldsha". You also know the commit messages that went with the change from oldsha to 4b9458b and with the change from 4b9458b to newsha. @@ -3380,21 +3413,21 @@ $ git hash-object -w <recreated-file> and your repository is good again! -(Btw, you could have ignored the fsck, and started with doing a +(Btw, you could have ignored the `fsck`, and started with doing a ------------------------------------------------ $ git log --raw --all ------------------------------------------------ and just looked for the sha of the missing object (4b9458b..) in that -whole thing. It's up to you - git does *have* a lot of information, it is +whole thing. It's up to you--Git does *have* a lot of information, it is just missing one particular blob version. [[the-index]] The index ----------- -The index is a binary file (generally kept in .git/index) containing a +The index is a binary file (generally kept in `.git/index`) containing a sorted list of path names, each with permissions and the SHA-1 of a blob object; linkgit:git-ls-files[1] can show you the contents of the index: @@ -3429,7 +3462,7 @@ It does this by storing some additional data for each entry (such as the last modified time). This data is not displayed above, and is not stored in the created tree object, but it can be used to determine quickly which files in the working directory differ from what was -stored in the index, and thus save git from having to read all of the +stored in the index, and thus save Git from having to read all of the data from such files to look for changes. 3. It can efficiently represent information about merge conflicts @@ -3493,7 +3526,7 @@ with Git 1.5.2 can look up the submodule commits in the repository and manually check them out; earlier versions won't recognize the submodules at all. -To see how submodule support works, create (for example) four example +To see how submodule support works, create four example repositories that can be used later as a submodule: ------------------------------------------------- @@ -3534,7 +3567,7 @@ $ ls -a The `git submodule add <repo> <path>` command does a couple of things: -- It clones the submodule from <repo> to the given <path> under the +- It clones the submodule from `<repo>` to the given `<path>` under the current directory and by default checks out the master branch. - It adds the submodule's clone path to the linkgit:gitmodules[5] file and adds this file to the index, ready to be committed. @@ -3595,7 +3628,7 @@ working on a branch. ------------------------------------------------- $ git branch -* (no branch) +* (detached from d266b98) master ------------------------------------------------- @@ -3660,13 +3693,13 @@ Did you forget to 'git add'? Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a' ------------------------------------------------- -In older git versions it could be easily forgotten to commit new or modified +In older Git versions it could be easily forgotten to commit new or modified files in a submodule, which silently leads to similar problems as not pushing -the submodule changes. Starting with git 1.7.0 both "git status" and "git diff" +the submodule changes. Starting with Git 1.7.0 both `git status` and `git diff` in the superproject show submodules as modified when they contain new or -modified files to protect against accidentally committing such a state. "git -diff" will also add a "-dirty" to the work tree side when generating patch -output or used with the --submodule option: +modified files to protect against accidentally committing such a state. `git +diff` will also add a `-dirty` to the work tree side when generating patch +output or used with the `--submodule` option: ------------------------------------------------- $ git diff @@ -3702,15 +3735,17 @@ module a NOTE: The changes are still visible in the submodule's reflog. -This is not the case if you did not commit your changes. +If you have uncommitted changes in your submodule working tree, `git +submodule update` will not overwrite them. Instead, you get the usual +warning about not being able switch from a dirty branch. [[low-level-operations]] -Low-level git operations +Low-level Git operations ======================== Many of the higher-level commands were originally implemented as shell -scripts using a smaller core of low-level git commands. These can still -be useful when doing unusual things with git, or just as a way to +scripts using a smaller core of low-level Git commands. These can still +be useful when doing unusual things with Git, or just as a way to understand its inner workings. [[object-manipulation]] @@ -3741,7 +3776,7 @@ between the working tree, the index, and the object database. Git provides low-level operations which perform each of these steps individually. -Generally, all "git" operations work on the index file. Some operations +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 between the index file and either the database or the working directory. Thus there are four main @@ -3760,11 +3795,11 @@ like so: $ git update-index filename ------------------------------------------------- -but to avoid common mistakes with filename globbing etc, the command +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 +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. @@ -3840,7 +3875,7 @@ 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 +need to use the `-f` flag ('before' the `-a` flag or the filename) to 'force' the checkout. @@ -3851,7 +3886,7 @@ from one representation to the other: Tying it all together ~~~~~~~~~~~~~~~~~~~~~ -To commit a tree you have instantiated with "git write-tree", you'd +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. @@ -3863,7 +3898,7 @@ 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", +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 @@ -3878,13 +3913,12 @@ 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 +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. +Here is a picture that illustrates how various pieces fit together: ------------ @@ -3963,27 +3997,26 @@ to see what the top commit was. 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. +Git can help you perform a three-way merge, which can in turn be +used for a many-way merge by repeating the merge procedure several +times. The usual situation is that you only do one three-way merge +(reconciling two lines of history) and commit the result, but if +you like to, you can merge several branches 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 perform a three-way merge, you start with the two commits you +want to merge, find their closest common parent (a third commit), +and compare the trees corresponding to these three commits. -To get the "base" for the merge, you first look up the common parent -of two commits with +To get the "base" for the merge, look up the common parent of two +commits: ------------------------------------------------- $ 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) +This prints the name of a commit they are both based on. You should +now look up the tree objects of those commits, which you can easily +do with ------------------------------------------------- $ git cat-file commit <commitname> | head -1 @@ -4035,9 +4068,9 @@ $ git ls-files --unmerged Each line of the `git ls-files --unmerged` output begins with the blob mode bits, blob SHA-1, '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. +filename. The 'stage number' is Git's way to say which tree it +came from: stage 1 corresponds to the `$orig` tree, stage 2 to +the `HEAD` tree, and stage 3 to the `$target` tree. Earlier we said that trivial merges are done inside `git read-tree -m`. For example, if the file did not change @@ -4047,7 +4080,7 @@ 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`, `merge`, or git's own merge-file, on +program, e.g. `diff3`, `merge`, or Git's own merge-file, on the blob objects from these three stages yourself, like this: ------------------------------------------------ @@ -4059,7 +4092,7 @@ $ git merge-file 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 +the merge result makes sense, you can tell Git what the final merge result for this file is by: ------------------------------------------------- @@ -4068,11 +4101,11 @@ $ git update-index hello.c ------------------------------------------------- When a path is in the "unmerged" state, running `git update-index` for -that path tells git to mark the path resolved. +that path tells Git to mark the path resolved. -The above is the description of a git merge at the lowest level, +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, runs `git cat-file` three times +In practice, nobody, not even Git itself, runs `git cat-file` three times for this. There is a `git merge-index` program that extracts the stages to temporary files and calls a "merge" script on it: @@ -4083,11 +4116,11 @@ $ git merge-index git-merge-one-file hello.c and that is what higher level `git merge -s resolve` is implemented with. [[hacking-git]] -Hacking git +Hacking Git =========== -This chapter covers internal details of the git implementation which -probably only git developers need to understand. +This chapter covers internal details of the Git implementation which +probably only Git developers need to understand. [[object-details]] Object storage format @@ -4105,15 +4138,14 @@ about the data in the object. It's worth noting that the SHA-1 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 SHA-1 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> {plus} <space> {plus} <ascii decimal -size> {plus} <byte\0> {plus} <binary object data>. +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 @@ -4135,7 +4167,7 @@ A good place to start is with the contents of the initial commit, with: $ git checkout e83c5163 ---------------------------------------------------- -The initial revision lays the foundation for almost everything git has +The initial revision lays the foundation for almost everything Git has today, but is small enough to read in one sitting. Note that terminology has changed since that revision. For example, the @@ -4208,21 +4240,22 @@ commits one by one with the function `get_revision()`. If you are interested in more details of the revision walking process, just have a look at the first implementation of `cmd_log()`; call -`git show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you +`git show v1.3.0~155^2~4` and scroll down to that function (note that you no longer need to call `setup_pager()` directly). Nowadays, `git log` is a builtin, which means that it is _contained_ in the command `git`. The source side of a builtin is -- a function called `cmd_<bla>`, typically defined in `builtin-<bla>.c`, - and declared in `builtin.h`, +- a function called `cmd_<bla>`, typically defined in `builtin/<bla.c>` + (note that older versions of Git used to have it in `builtin-<bla>.c` + instead), and declared in `builtin.h`. - an entry in the `commands[]` array in `git.c`, and - an entry in `BUILTIN_OBJECTS` in the `Makefile`. Sometimes, more than one builtin is contained in one source file. For -example, `cmd_whatchanged()` and `cmd_log()` both reside in `builtin-log.c`, +example, `cmd_whatchanged()` and `cmd_log()` both reside in `builtin/log.c`, since they share quite a bit of code. In that case, the commands which are _not_ named like the `.c` file in which they live have to be listed in `BUILT_INS` in the `Makefile`. @@ -4245,10 +4278,10 @@ For the sake of clarity, let's stay with `git cat-file`, because it - is plumbing, and - was around even in the initial commit (it literally went only through - some 20 revisions as `cat-file.c`, was renamed to `builtin-cat-file.c` + some 20 revisions as `cat-file.c`, was renamed to `builtin/cat-file.c` when made a builtin, and then saw less than 10 versions). -So, look into `builtin-cat-file.c`, search for `cmd_cat_file()` and look what +So, look into `builtin/cat-file.c`, search for `cmd_cat_file()` and look what it does. ------------------------------------------------------------------ @@ -4271,9 +4304,9 @@ Two things are interesting here: negative numbers in case of different errors--and 0 on success. - the variable `sha1` in the function signature of `get_sha1()` is `unsigned - char {asterisk}`, but is actually expected to be a pointer to `unsigned + char *`, but is actually expected to be a pointer to `unsigned char[20]`. This variable will contain the 160-bit SHA-1 of the given - commit. Note that whenever a SHA-1 is passed as `unsigned char {asterisk}`, it + commit. Note that whenever a SHA-1 is passed as `unsigned char *`, it is the binary representation, as opposed to the ASCII representation in hex characters, which is passed as `char *`. @@ -4289,7 +4322,7 @@ Now, for the meat: This is how you read a blob (actually, not only a blob, but any type of object). To know how the function `read_object_with_reference()` actually works, find the source code for it (something like `git grep -read_object_with | grep ":[a-z]"` in the git repository), and read +read_object_with | grep ":[a-z]"` in the Git repository), and read the source. To find out how the result can be used, just read on in `cmd_cat_file()`: @@ -4324,7 +4357,7 @@ Another example: Find out what to do in order to make some script a builtin: ------------------------------------------------- -$ git log --no-merges --diff-filter=A builtin-*.c +$ git log --no-merges --diff-filter=A builtin/*.c ------------------------------------------------- You see, Git is actually the best tool to find out about the source of Git @@ -4470,7 +4503,7 @@ $ git bisect bad # if this revision is bad. Making changes -------------- -Make sure git knows who to blame: +Make sure Git knows who to blame: ------------------------------------------------ $ cat >>~/.gitconfig <<\EOF @@ -4520,7 +4553,7 @@ $ git format-patch origin..HEAD # format a patch for each commit $ git am mbox # import patches from the mailbox "mbox" ----------------------------------------------- -Fetch a branch in a different git repository, then merge into the +Fetch a branch in a different Git repository, then merge into the current branch: ----------------------------------------------- @@ -4581,7 +4614,7 @@ The basic requirements: - It must be readable in order, from beginning to end, by someone intelligent with a basic grasp of the UNIX command line, but without - any special knowledge of git. If necessary, any other prerequisites + any special knowledge of Git. If necessary, any other prerequisites should be specifically mentioned as they arise. - Whenever possible, section headings should clearly describe the task they explain how to do, in language that requires no more knowledge @@ -4592,10 +4625,10 @@ Think about how to create a clear chapter dependency graph that will allow people to get to important topics without necessarily reading everything in between. -Scan Documentation/ for other stuff left out; in particular: +Scan `Documentation/` for other stuff left out; in particular: - howto's -- some of technical/? +- some of `technical/`? - hooks - list of commands in linkgit:git[1] @@ -4626,5 +4659,5 @@ Write a chapter on using plumbing and writing scripts. Alternates, clone -reference, etc. More on recovery from repository corruption. See: - http://marc.theaimsgroup.com/?l=git&m=117263864820799&w=2 - http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2 + http://marc.info/?l=git&m=117263864820799&w=2 + http://marc.info/?l=git&m=117147855503798&w=2 |