diff options
Diffstat (limited to 'Documentation')
340 files changed, 21350 insertions, 5791 deletions
diff --git a/Documentation/.gitignore b/Documentation/.gitignore index d62aebd848..2c8b2d612e 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 483008699f..c6e536f180 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, a few 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,20 @@ 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. + - Fixing style violations while working on a real change as a + preparatory clean-up step is good, but otherwise avoid useless code + churn for the sake of conforming to the style. + + "Once it _is_ in the tree, it's not really worth the patch noise to + go and fix it up." + Cf. http://article.gmane.org/gmane.linux.kernel/943020 + +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). @@ -33,12 +42,42 @@ For shell scripts specifically (not exhaustive): - We use tabs for indentation. - - Case arms are indented at the same depth as case and esac lines. + - Case arms are indented at the same depth as case and esac lines, + like this: + + case "$variable" in + pattern1) + do this + ;; + pattern2) + do that + ;; + esac + + - 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. + + (incorrect) + cat hello > world < universe + echo hello >$world + + (correct) + cat hello >world <universe + echo hello >"$world" - 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,19 +103,46 @@ 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". + + (incorrect) + if test -f hello; then + do this + fi + + (correct) + if test -f hello + then + do this + fi + - 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, + and no space inside the parentheses. The opening "{" should also + be on the same line. + + (incorrect) + my_function(){ + ... + + (correct) + my_function () { + ... + - As to use of grep, stick to a subset of BRE (namely, no \{m,n\}, - [::], [==], nor [..]) for portability. + [::], [==], or [..]) for portability. - We do not use \{m,n\}; - We do not use -E; - - We do not use ? nor + (which are \{0,1\} and \{1,\} + - We do not use ? or + (which are \{0,1\} and \{1,\} respectively in BRE) but that goes without saying as these are ERE elements not BRE (note that \? and \+ are not even part of BRE -- making them accessible from BRE is a GNU extension). @@ -85,6 +151,19 @@ For shell scripts specifically (not exhaustive): interface translatable. See "Marking strings for translation" in po/README. + - We do not write our "test" command with "-a" and "-o" and use "&&" + or "||" to concatenate multiple "test" commands instead, because + the use of "-a/-o" is often error-prone. E.g. + + test -n "$x" -a "$a" = "$b" + + is buggy and breaks when $x is "=", but + + test -n "$x" && test "$a" = "$b" + + does not have such a problem. + + For C programs: - We use tabs to indent, and interpret tabs as taking up to @@ -92,11 +171,30 @@ 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 like "char *string, c;". + - Use whitespace around operators and keywords, but not inside + parentheses and not around functions. So: + + while (condition) + func(bar + 1); + + and not: + + while( condition ) + func (bar+1); + - We avoid using braces unnecessarily. I.e. if (bla) { @@ -109,16 +207,116 @@ For C programs: of "else if" statements, it can make sense to add braces to single line blocks. - - We try to avoid assignments inside if(). + - We try to avoid assignments in the condition of an "if" statement. - Try to make your code understandable. You may put comments in, but comments invariably tend to stale out when the code they were describing changes. Often splitting a function into two makes the intention of the code much clearer. + - Multi-line comments include their delimiters on separate lines from + the text. E.g. + + /* + * A very long + * multi-line comment. + */ + + Note however that a comment that explains a translatable string to + translators uses a convention of starting with a magic token + "TRANSLATORS: " immediately after the opening delimiter, even when + it spans multiple lines. We do not add an asterisk at the beginning + of each line, either. E.g. + + /* TRANSLATORS: here is a comment that explains the string + to be translated, that follows immediately after it */ + _("Here is a translatable string explained by the above."); + - Double negation is often harder to understand than no negation at all. + - There are two schools of thought when it comes to comparison, + especially inside a loop. Some people prefer to have the less stable + value on the left hand side and the more stable value on the right hand + side, e.g. if you have a loop that counts variable i down to the + lower bound, + + while (i > lower_bound) { + do something; + i--; + } + + Other people prefer to have the textual order of values match the + actual order of values in their comparison, so that they can + mentally draw a number line from left to right and place these + values in order, i.e. + + while (lower_bound < i) { + do something; + i--; + } + + Both are valid, and we use both. However, the more "stable" the + stable side becomes, the more we tend to prefer the former + (comparison with a constant, "i > 0", is an extreme example). + Just do not mix styles in the same part of the code and mimic + existing styles in the neighbourhood. + + - There are two schools of thought when it comes to splitting a long + logical line into multiple lines. Some people push the second and + subsequent lines far enough to the right with tabs and align them: + + if (the_beginning_of_a_very_long_expression_that_has_to || + span_more_than_a_single_line_of || + the_source_text) { + ... + + while other people prefer to align the second and the subsequent + lines with the column immediately inside the opening parenthesis, + with tabs and spaces, following our "tabstop is always a multiple + of 8" convention: + + if (the_beginning_of_a_very_long_expression_that_has_to || + span_more_than_a_single_line_of || + the_source_text) { + ... + + Both are valid, and we use both. Again, just do not mix styles in + the same part of the code and mimic existing styles in the + neighbourhood. + + - When splitting a long logical line, some people change line before + a binary operator, so that the result looks like a parse tree when + you turn your head 90-degrees counterclockwise: + + if (the_beginning_of_a_very_long_expression_that_has_to + || span_more_than_a_single_line_of_the_source_text) { + + while other people prefer to leave the operator at the end of the + line: + + if (the_beginning_of_a_very_long_expression_that_has_to || + span_more_than_a_single_line_of_the_source_text) { + + Both are valid, but we tend to use the latter more, unless the + expression gets fairly complex, in which case the former tends to + be easier to read. Again, just do not mix styles in the same part + of the code and mimic existing styles in the neighbourhood. + + - When splitting a long logical line, with everything else being + equal, it is preferable to split after the operator at higher + level in the parse tree. That is, this is more preferable: + + if (a_very_long_variable * that_is_used_in + + a_very_long_expression) { + ... + + than + + if (a_very_long_variable * + that_is_used_in + a_very_long_expression) { + ... + - Some clever tricks, like using the !! operator with arithmetic constructs, can be extremely confusing to others. Avoid them, unless there is a compelling reason to use them. @@ -130,20 +328,25 @@ For C programs: - When you come up with an API, document it. - - The first #include in C files, except in platform specific - compat/ implementations, should be git-compat-util.h or another - header file that includes it, such as cache.h or builtin.h. + - The first #include in C files, except in platform specific compat/ + implementations, must be either "git-compat-util.h", "cache.h" or + "builtin.h". You do not have to include more than one of these. + + - A C file must directly include the header files that declare the + functions and the types it uses, except for the functions and types + that are made available to it by including one of the header files + it must include by the previous rule. - 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. @@ -151,19 +354,125 @@ For C programs: - 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. + +Error Messages + + - Do not end error messages with a full stop. + + - Do not capitalize ("unable to open %s", not "Unable to open %s") + + - Say what the error is first ("cannot open %s", not "%s: cannot open") + + +Externally Visible Names + + - For configuration variable names, follow the existing convention: + + . The section name indicates the affected subsystem. + + . The subsection name, if any, indicates which of an unbounded set + of things to set the value for. + + . The variable name describes the effect of tweaking this knob. + + The section and variable names that consist of multiple words are + formed by concatenating the words without punctuations (e.g. `-`), + and are broken using bumpyCaps in documentation as a hint to the + reader. + + When choosing the variable namespace, do not use variable name for + specifying possibly unbounded set of things, most notably anything + an end user can freely come up with (e.g. branch names). Instead, + use subsection names or variable values, like the existing variable + branch.<name>.description does. + + 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> --sort=<key> --abbrev[=<n>] + If a placeholder has multiple words, they are separated by dashes: + <new-branch-name> + --template=<template-directory> + Possibility of multiple occurrences is indicated by three dots: <file>... (One or more of <file>.) @@ -180,12 +489,12 @@ Writing Documentation: (Zero or more of <patch>. Note that the dots are inside, not outside the brackets.) - Multiple alternatives are indicated with vertical bar: + Multiple alternatives are indicated with vertical bars: [-q | --quiet] [--utf8 | --no-utf8] Parentheses are used for grouping: - [(<rev>|<range>)...] + [(<rev> | <range>)...] (Any number of either <rev> or <range>. Parens are needed to make it clear that "..." pertains to both <rev> and <range>.) @@ -202,3 +511,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 d40e211f22..3e39e2815b 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -1,63 +1,124 @@ -MAN1_TXT= \ - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ - $(wildcard git-*.txt)) \ - gitk.txt gitweb.txt git.txt -MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \ - gitrepository-layout.txt gitweb.conf.txt -MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \ - gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \ - gitdiffcore.txt gitnamespaces.txt gitrevisions.txt gitworkflows.txt +# Guard against environment variables +MAN1_TXT = +MAN5_TXT = +MAN7_TXT = +TECH_DOCS = +ARTICLES = +SP_ARTICLES = +OBSOLETE_HTML = + +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 += giteveryday.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 += everyday.html +OBSOLETE_HTML += git-remote-helpers.html +DOC_HTML = $(MAN_HTML) $(OBSOLETE_HTML) -ARTICLES = howto-index -ARTICLES += everyday +ARTICLES += howto-index ARTICLES += git-tools ARTICLES += git-bisect-lk2009 # with their own formatting rules. -SP_ARTICLES = 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/keep-canonical-history-correct +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 = +ASCIIDOC_HTML = xhtml11 +ASCIIDOC_DOCBOOK = docbook +ASCIIDOC_CONF = -f asciidoc.conf +ASCIIDOC_COMMON = $(ASCIIDOC) $(ASCIIDOC_EXTRA) $(ASCIIDOC_CONF) \ + -agit_version=$(GIT_VERSION) +TXT_TO_HTML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_HTML) +TXT_TO_XML = $(ASCIIDOC_COMMON) -b $(ASCIIDOC_DOCBOOK) MANPAGE_XSL = manpage-normal.xsl +XMLTO = xmlto XMLTO_EXTRA = -INSTALL?=install +INSTALL ?= install RM ?= rm -f MAN_REPO = ../../git-manpages HTML_REPO = ../../git-htmldocs -infodir?=$(prefix)/share/info -MAKEINFO=makeinfo -INSTALL_INFO=install-info -DOCBOOK2X_TEXI=docbook2x-texi -DBLATEX=dblatex +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 @@ -66,12 +127,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? @@ -81,9 +136,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 @@ -124,14 +176,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 = @@ -163,8 +216,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) @@ -209,7 +260,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 $@+ $@ @@ -233,19 +288,37 @@ 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 $@+ $< && \ + $(TXT_TO_HTML) -d manpage -o $@+ $< && \ + mv $@+ $@ + +$(OBSOLETE_HTML): %.html : %.txto asciidoc.conf + $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ + $(TXT_TO_HTML) -o $@+ $< && \ mv $@+ $@ manpage-base-url.xsl: manpage-base-url.xsl.in @@ -253,26 +326,25 @@ manpage-base-url.xsl: manpage-base-url.xsl.in %.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 $@+ $< && \ + $(TXT_TO_XML) -d manpage -o $@+ $< && \ mv $@+ $@ user-manual.xml: user-manual.txt user-manual.conf $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ - $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b docbook -d book -o $@+ $< && \ + $(TXT_TO_XML) -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 - $(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.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)$(TXT_TO_HTML) $*.txt XSLT = docbook.xsl XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css @@ -294,7 +366,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 @@ -315,24 +387,26 @@ $(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 - $(QUIET_ASCIIDOC)$(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 $*.txt + $(QUIET_ASCIIDOC)$(TXT_TO_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 - >$@+ && \ + sed -e '1,/^$$/d' $< | \ + $(TXT_TO_HTML) - >$@+ && \ mv $@+ $@ 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. +# 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 @@ -350,4 +424,7 @@ require-htmlrepo:: quick-install-html: require-htmlrepo '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REPO) $(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 ebf20e22a7..d41984df0b 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 e1e24b3295..7d8fb85e1b 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 6f0bde156a..cd08d8174e 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 0ce6316d75..ccbad794c0 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 adb7ccab0a..7b152a6fdc 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 0000000000..be68524cff --- /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 0000000000..7a7e9d6fd1 --- /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 0000000000..703fbf1d60 --- /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 0000000000..326670df6e --- /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 0000000000..4db1770e38 --- /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 index be3001afe2..58100bf04e 100644 --- a/Documentation/RelNotes/1.7.10.txt +++ b/Documentation/RelNotes/1.7.10.txt @@ -1,64 +1,198 @@ 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 - * Improved handling of views, labels and branches in git-p4 (in contrib). - - * Updated command line arguments completion script for zsh (in contrib). - - * "vcs-svn"/"svn-fe" learned to read dumps with svn-deltas and - support incremental imports. + * 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 bracketed string other than "PATCH" at the beginning can be kept. + 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!). + 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 source repository's HEAD does not point to a branch. - - * The commands in the "git diff" family and "git apply --stat" that - count the number of files changed and the number of lines - inserted/deleted have been updated to match the output from - "diffstat". This also opens the door to i18n this line. + 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 MERGE_AUTOEDIT=no to retain the historical behaviour. + 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 projects to be clicked, which in turn shows the + 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 - * During "git upload-pack" in respose to "git fetch", unnecessary calls - to parse_object() have been eliminated, to help performance in - repositories with excessive number of refs. + * 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 +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 slowly getting removed, to make it - possible to cleanly restructure the overall refs API. + * 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. @@ -69,36 +203,17 @@ 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). - * The error message emitted when we see an empty loose object was - not phrased correctly. - (merge 33e42de mm/empty-loose-error-message later to maint). - - * "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. - (merge 3f6d56d jc/maint-commit-ignore-i-t-a later to maint). - - * Search box in "gitweb" did not accept non-ASCII characters correctly. - (merge 84d9e2d jn/gitweb-search-utf-8 later to maint). - - * 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). - (merge 84d7273 jk/prompt-fallback-to-tty later to maint). - - * 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. - (merge f026358 jc/maint-mailmap-output later to maint). - - * "checkout -b" did not allow switching out of an unborn branch. - (merge abe1998 jc/checkout-out-of-unborn later to maint). - ---- -exec >/var/tmp/1 -O=v1.7.9-249-gaa47ec9 -echo O=$(git describe) -git log --first-parent --oneline ^maint $O.. -echo -git shortlog --no-merges ^maint $O.. + * 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 0000000000..577eccaacd --- /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 0000000000..f0cfd02d6f --- /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 0000000000..64494f89d9 --- /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 0000000000..3a640c2d4d --- /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 0000000000..0a2ed855c5 --- /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 0000000000..ba7d3c3966 --- /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 0000000000..e7e79d999b --- /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 0000000000..15b954ca4b --- /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 0000000000..b8f04af19f --- /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 0000000000..69255745e6 --- /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 0000000000..ecda427a35 --- /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 0000000000..c6da3cc939 --- /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 0000000000..010d8c7de4 --- /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 cf3f455ced..7796df3fe4 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.7.txt b/Documentation/RelNotes/1.7.7.7.txt new file mode 100644 index 0000000000..e79118d063 --- /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.8.2.txt b/Documentation/RelNotes/1.7.8.2.txt index e74f4ef1ef..b9c66aa1b7 100644 --- a/Documentation/RelNotes/1.7.8.2.txt +++ b/Documentation/RelNotes/1.7.8.2.txt @@ -12,11 +12,11 @@ Fixes since v1.7.8.1 * The configuration file parser used for sizes (e.g. bigFileThreshold) did not correctly interpret 'g' suffix. - * The replacement implemention for snprintf used on platforms with + * 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 techinically correct but not friendly to people who are trying + 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. diff --git a/Documentation/RelNotes/1.7.8.5.txt b/Documentation/RelNotes/1.7.8.5.txt new file mode 100644 index 0000000000..011fd2a428 --- /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 0000000000..d9bf2b741a --- /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 index b4d90bba0f..249311361e 100644 --- a/Documentation/RelNotes/1.7.8.txt +++ b/Documentation/RelNotes/1.7.8.txt @@ -9,7 +9,7 @@ Updates since v1.7.7 * Updates to bash completion scripts. * The build procedure has been taught to take advantage of computed - dependency automatically when the complier supports it. + 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". @@ -31,7 +31,7 @@ Updates since v1.7.7 * Variants of "git cherry-pick" and "git revert" that take multiple commits learned to "--continue" and "--abort". - * "git daemon" gives more human readble error messages to clients + * "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". diff --git a/Documentation/RelNotes/1.7.9.2.txt b/Documentation/RelNotes/1.7.9.2.txt new file mode 100644 index 0000000000..e500da75dd --- /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 0000000000..91c65012f9 --- /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 0000000000..e5217a1889 --- /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 0000000000..95cc2bbf2c --- /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 0000000000..74bf8825e2 --- /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 0000000000..59667d0f2a --- /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.8.0.1.txt b/Documentation/RelNotes/1.8.0.1.txt new file mode 100644 index 0000000000..1f372fa0b5 --- /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 0000000000..8497e051de --- /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 0000000000..92b1e4b363 --- /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 0000000000..43883c14f0 --- /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 0000000000..6cde07ba29 --- /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 0000000000..5ab7b18906 --- /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 0000000000..681cb35c0a --- /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 0000000000..22af1d1643 --- /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 0000000000..efa68aef22 --- /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 0000000000..c15cf2e805 --- /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 0000000000..d6f9555923 --- /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 0000000000..769a6fc06c --- /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 0000000000..708df1ae19 --- /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 0000000000..613948251a --- /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 0000000000..fc606ae116 --- /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 0000000000..fc3ea185a5 --- /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 0000000000..26ae142c3d --- /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 0000000000..9ba4f4da0f --- /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 0000000000..56f106e262 --- /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 0000000000..ead568e7f1 --- /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 0000000000..3aa25a2743 --- /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 0000000000..9adccb1efb --- /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 0000000000..03f3d17751 --- /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 0000000000..7bc4c5dcc0 --- /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 0000000000..215bd1a7a2 --- /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 0000000000..02f681b710 --- /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 0000000000..7236aaf232 --- /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 0000000000..3ac4984f10 --- /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 0000000000..3de2dd0f19 --- /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 0000000000..d18c40389e --- /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 0000000000..9191ce948f --- /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.6.txt b/Documentation/RelNotes/1.8.5.6.txt new file mode 100644 index 0000000000..92ff92b1e6 --- /dev/null +++ b/Documentation/RelNotes/1.8.5.6.txt @@ -0,0 +1,34 @@ +Git v1.8.5.6 Release Notes +========================== + +Fixes since v1.8.5.5 +-------------------- + + * We used to allow committing a path ".Git/config" with Git that is + running on a case sensitive filesystem, but an attempt to check out + such a path with Git that runs on a case insensitive filesystem + would have clobbered ".git/config", which is definitely not what + the user would have expected. Git now prevents you from tracking + a path with ".Git" (in any case combination) as a path component. + + * On Windows, certain path components that are different from ".git" + are mapped to ".git", e.g. "git~1/config" is treated as if it were + ".git/config". HFS+ has a similar issue, where certain unicode + codepoints are ignored, e.g. ".g\u200cit/config" is treated as if + it were ".git/config". Pathnames with these potential issues are + rejected on the affected systems. Git on systems that are not + affected by this issue (e.g. Linux) can also be configured to + reject them to ensure cross platform interoperability of the hosted + projects. + + * "git fsck" notices a tree object that records such a path that can + be confused with ".git", and with receive.fsckObjects configuration + set to true, an attempt to "git push" such a tree object will be + rejected. Such a path may not be a problem on a well behaving + filesystem but in order to protect those on HFS+ and on case + insensitive filesystems, this check is enabled on all platforms. + +A big "thanks!" for bringing this issue to us goes to our friends in +the Mercurial land, namely, Matt Mackall and Augie Fackler. + +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 0000000000..602df0cac2 --- /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 0000000000..752d79127a --- /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/RelNotes/1.9.1.txt b/Documentation/RelNotes/1.9.1.txt new file mode 100644 index 0000000000..5b0602053c --- /dev/null +++ b/Documentation/RelNotes/1.9.1.txt @@ -0,0 +1,59 @@ +Git v1.9.1 Release Notes +======================== + +Fixes since v1.9.0 +------------------ + + * "git clean -d pathspec" did not use the given pathspec correctly + and ended up cleaning too much. + + * "git difftool" misbehaved when the repository is bound to the + working tree with the ".git file" mechanism, where a textual file + ".git" tells us where it is. + + * "git push" did not pay attention to branch.*.pushremote if it is + defined earlier than remote.pushdefault; the order of these two + variables in the configuration file should not matter, but it did + by mistake. + + * Codepaths that parse timestamps in commit objects have been + tightened. + + * "git diff --external-diff" incorrectly fed the submodule directory + in the working tree to the external diff driver when it knew it is + the same as one of the versions being compared. + + * "git reset" needs to refresh the index when working in a working + tree (it can also be used to match the index to the HEAD in an + otherwise bare repository), but it failed to set up the working + tree properly, causing GIT_WORK_TREE to be ignored. + + * "git check-attr" when working on a repository with a working tree + did not work well when the working tree was specified via the + --work-tree (and obviously with --git-dir) option. + + * "merge-recursive" was broken in 1.7.7 era and stopped working in + an empty (temporary) working tree, when there are renames + involved. This has been corrected. + + * "git rev-parse" was loose in rejecting command line arguments + that do not make sense, e.g. "--default" without the required + value for that option. + + * include.path variable (or any variable that expects a path that + can use ~username expansion) in the configuration file is not a + boolean, but the code failed to check it. + + * "git diff --quiet -- pathspec1 pathspec2" sometimes did not return + correct status value. + + * Attempting to deepen a shallow repository by fetching over smart + HTTP transport failed in the protocol exchange, when no-done + extension was used. The fetching side waited for the list of + shallow boundary commits after the sending end stopped talking to + it. + + * Allow "git cmd path/", when the 'path' is where a submodule is + bound to the top-level working tree, to match 'path', despite the + extra and unnecessary trailing slash (such a slash is often + given by command line completion). diff --git a/Documentation/RelNotes/1.9.2.txt b/Documentation/RelNotes/1.9.2.txt new file mode 100644 index 0000000000..47a34ca964 --- /dev/null +++ b/Documentation/RelNotes/1.9.2.txt @@ -0,0 +1,67 @@ +Git v1.9.2 Release Notes +======================== + +Fixes since v1.9.1 +------------------ + + * Documentation and in-code comments had many instances of mistaken + use of "nor", which have been corrected. + + * "git fetch --prune", when the right-hand-side of multiple fetch + refspecs overlap (e.g. storing "refs/heads/*" to + "refs/remotes/origin/*", while storing "refs/frotz/*" to + "refs/remotes/origin/fr/*"), aggressively thought that lack of + "refs/heads/fr/otz" on the origin site meant we should remove + "refs/remotes/origin/fr/otz" from us, without checking their + "refs/frotz/otz" first. + + Note that such a configuration is inherently unsafe (think what + should happen when "refs/heads/fr/otz" does appear on the origin + site), but that is not a reason not to be extra careful. + + * "git update-ref --stdin" did not fail a request to create a ref + when the ref already existed. + + * "git diff --no-index -Mq a b" fell into an infinite loop. + + * When it is not necessary to edit a commit log message (e.g. "git + commit -m" is given a message without specifying "-e"), we used to + disable the spawning of the editor by overriding GIT_EDITOR, but + this means all the uses of the editor, other than to edit the + commit log message, are also affected. + + * "git status --porcelain --branch" showed its output with labels + "ahead/behind/gone" translated to the user's locale. + + * "git mv" that moves a submodule forgot to adjust the array that + uses to keep track of which submodules were to be moved to update + its configuration. + + * Length limit for the pathname used when removing a path in a deep + subdirectory has been removed to avoid buffer overflows. + + * The test helper lib-terminal always run an actual test_expect_* + when included, which screwed up with the use of skil-all that may + have to be done later. + + * "git index-pack" used a wrong variable to name the keep-file in an + error message when the file cannot be written or closed. + + * "rebase -i" produced a broken insn sheet when the title of a commit + happened to contain '\n' (or ended with '\c') due to a careless use + of 'echo'. + + * There were a few instances of 'git-foo' remaining in the + documentation that should have been spelled 'git foo'. + + * Serving objects from a shallow repository needs to write a + new file to hold the temporary shallow boundaries but it was not + cleaned when we exit due to die() or a signal. + + * When "git stash pop" stops after failing to apply the stash + (e.g. due to conflicting changes), the stash is not dropped. State + that explicitly in the output to let the users know. + + * The labels in "git status" output that describe the nature of + conflicts (e.g. "both deleted") were limited to 20 bytes, which was + too short for some l10n (e.g. fr). diff --git a/Documentation/RelNotes/1.9.3.txt b/Documentation/RelNotes/1.9.3.txt new file mode 100644 index 0000000000..17b05ca7b5 --- /dev/null +++ b/Documentation/RelNotes/1.9.3.txt @@ -0,0 +1,21 @@ +Git v1.9.3 Release Notes +======================== + +Fixes since v1.9.2 +------------------ + + * "git p4" dealing with changes in binary files were broken by a + change in 1.9 release. + + * The shell prompt script (in contrib/), when using the PROMPT_COMMAND + interface, used an unsafe construct when showing the branch name in + $PS1. + + * "git rebase" used a POSIX shell construct FreeBSD /bin/sh does not + work well with. + + * Some more Unicode codepoints defined in Unicode 6.3 as having + zero width have been taught to our display column counting logic. + + * Some tests used shell constructs that did not work well on + FreeBSD. diff --git a/Documentation/RelNotes/1.9.4.txt b/Documentation/RelNotes/1.9.4.txt new file mode 100644 index 0000000000..e1d1835436 --- /dev/null +++ b/Documentation/RelNotes/1.9.4.txt @@ -0,0 +1,16 @@ +Git v1.9.4 Release Notes +======================== + +Fixes since v1.9.3 +------------------ + + * Commands that take pathspecs on the command line misbehaved when + the pathspec is given as an absolute pathname (which is a + practice not particularly encouraged) that points at a symbolic + link in the working tree. + + * An earlier fix to the shell prompt script (in contrib/) for using + the PROMPT_COMMAND interface did not correctly check if the extra + code path needs to trigger, causing the branch name not to appear + when 'promptvars' option is disabled in bash or PROMPT_SUBST is + unset in zsh. diff --git a/Documentation/RelNotes/1.9.5.txt b/Documentation/RelNotes/1.9.5.txt new file mode 100644 index 0000000000..8d6ac0cf53 --- /dev/null +++ b/Documentation/RelNotes/1.9.5.txt @@ -0,0 +1,34 @@ +Git v1.9.5 Release Notes +======================== + +Fixes since v1.9.4 +------------------ + + * We used to allow committing a path ".Git/config" with Git that is + running on a case sensitive filesystem, but an attempt to check out + such a path with Git that runs on a case insensitive filesystem + would have clobbered ".git/config", which is definitely not what + the user would have expected. Git now prevents you from tracking + a path with ".Git" (in any case combination) as a path component. + + * On Windows, certain path components that are different from ".git" + are mapped to ".git", e.g. "git~1/config" is treated as if it were + ".git/config". HFS+ has a similar issue, where certain unicode + codepoints are ignored, e.g. ".g\u200cit/config" is treated as if + it were ".git/config". Pathnames with these potential issues are + rejected on the affected systems. Git on systems that are not + affected by this issue (e.g. Linux) can also be configured to + reject them to ensure cross platform interoperability of the hosted + projects. + + * "git fsck" notices a tree object that records such a path that can + be confused with ".git", and with receive.fsckObjects configuration + set to true, an attempt to "git push" such a tree object will be + rejected. Such a path may not be a problem on a well behaving + filesystem but in order to protect those on HFS+ and on case + insensitive filesystems, this check is enabled on all platforms. + +A big "thanks!" for bringing this issue to us goes to our friends in +the Mercurial land, namely, Matt Mackall and Augie Fackler. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.0.0.txt b/Documentation/RelNotes/2.0.0.txt new file mode 100644 index 0000000000..2617372a0c --- /dev/null +++ b/Documentation/RelNotes/2.0.0.txt @@ -0,0 +1,364 @@ +Git v2.0 Release Notes +====================== + +Backward compatibility notes +---------------------------- + +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 is now 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. + +You can use the configuration variable "push.default" to change +this. If you are an old-timer who wants to keep using the +"matching" semantics, you can set the variable to "matching", for +example. Read the documentation for other possibilities. + +When "git add -u" and "git add -A" are run inside a subdirectory +without specifying which paths to add on the command line, they +operate on the entire tree for consistency with "git commit -a" and +other commands (these commands used to operate only on the current +subdirectory). Say "git add -u ." or "git add -A ." if you want to +limit the operation to the current directory. + +"git add <path>" is the same as "git add -A <path>" now, so that +"git add dir/" will notice paths you removed from the directory and +record the removal. In older versions of Git, "git add <path>" used +to ignore removals. You can say "git add --ignore-removal <path>" to +add only added or modified paths in <path>, if you really want to. + +The "-q" option to "git diff-files", which does *NOT* mean "quiet", +has been removed (it told Git to ignore deletion, which you can do +with "git diff-files --diff-filter=d"). + +"git request-pull" lost a few "heuristics" that often led to mistakes. + +The default prefix for "git svn" has changed in Git 2.0. For a long +time, "git svn" created its remote-tracking branches directly under +refs/remotes, but it now places them under refs/remotes/origin/ unless +it is told otherwise with its "--prefix" option. + + +Updates since v1.9 series +------------------------- + +UI, Workflows & Features + + * The "multi-mail" post-receive hook (in contrib/) has been updated + to a more recent version from upstream. + + * The "remote-hg/bzr" remote-helper interfaces (used to be in + contrib/) are no more. They are now maintained separately as + third-party plug-ins in their own repositories. + + * "git gc --aggressive" learned "--depth" option and + "gc.aggressiveDepth" configuration variable to allow use of a less + insane depth than the built-in default value of 250. + + * "git log" learned the "--show-linear-break" option to show where a + single strand-of-pearls is broken in its output. + + * The "rev-parse --parseopt" mechanism used by scripted Porcelains to + parse command-line options and to give help text learned to take + the argv-help (the placeholder string for an option parameter, + e.g. "key-id" in "--gpg-sign=<key-id>"). + + * The pattern to find where the function begins in C/C++ used in + "diff" and "grep -p" has been updated to improve viewing C++ + sources. + + * "git rebase" learned to interpret a lone "-" as "@{-1}", the + branch that we were previously on. + + * "git commit --cleanup=<mode>" learned a new mode, scissors. + + * "git tag --list" output can be sorted using "version sort" with + "--sort=version:refname". + + * Discard the accumulated "heuristics" to guess from which branch the + result wants to be pulled from and make sure that what the end user + specified is not second-guessed by "git request-pull", to avoid + mistakes. When you pushed out your 'master' branch to your public + repository as 'for-linus', use the new "master:for-linus" syntax to + denote the branch to be pulled. + + * "git grep" learned to behave in a way similar to native grep when + "-h" (no header) and "-c" (count) options are given. + + * "git push" via transport-helper interface has been updated to + allow forced ref updates in a way similar to the natively + supported transports. + + * The "simple" mode is the default for "git push". + + * "git add -u" and "git add -A", when run without any pathspec, is a + tree-wide operation even when run inside a subdirectory of a + working tree. + + * "git add <path>" is the same as "git add -A <path>" now. + + * "core.statinfo" configuration variable, which is a + never-advertised synonym to "core.checkstat", has been removed. + + * The "-q" option to "git diff-files", which does *NOT* mean + "quiet", has been removed (it told Git to ignore deletion, which + you can do with "git diff-files --diff-filter=d"). + + * Server operators can loosen the "tips of refs only" restriction for + the remote archive service with the uploadarchive.allowUnreachable + configuration option. + + * The progress indicators from various time-consuming commands have + been marked for i18n/l10n. + + * "git notes -C <blob>" diagnoses as an error an attempt to use an + object that is not a blob. + + * "git config" learned to read from the standard input when "-" is + given as the value to its "--file" parameter (attempting an + operation to update the configuration in the standard input is + rejected, of course). + + * Trailing whitespaces in .gitignore files, unless they are quoted + for fnmatch(3), e.g. "path\ ", are warned and ignored. Strictly + speaking, this is a backward-incompatible change, but very unlikely + to bite any sane user and adjusting should be obvious and easy. + + * Many commands that create commits, e.g. "pull" and "rebase", + learned to take the "--gpg-sign" option on the command line. + + * "git commit" can be told to always GPG sign the resulting commit + by setting the "commit.gpgsign" configuration variable to "true" + (the command-line option "--no-gpg-sign" should override it). + + * "git pull" can be told to only accept fast-forward by setting the + new "pull.ff" configuration variable. + + * "git reset" learned the "-N" option, which does not reset the index + fully for paths the index knows about but the tree-ish the command + resets to does not (these paths are kept as intend-to-add entries). + + +Performance, Internal Implementation, etc. + + * The compilation options to port to AIX and to MSVC have been + updated. + + * We started using wildmatch() in place of fnmatch(3) a few releases + ago; complete the process and stop using fnmatch(3). + + * Uses of curl's "multi" interface and "easy" interface do not mix + well when we attempt to reuse outgoing connections. Teach the RPC + over HTTP code, used in the smart HTTP transport, not to use the + "easy" interface. + + * The bitmap-index feature from JGit has been ported, which should + significantly improve performance when serving objects from a + repository that uses it. + + * The way "git log --cc" shows a combined diff against multiple + parents has been optimized. + + * The prefixcmp() and suffixcmp() functions are gone. Use + starts_with() and ends_with(), and also consider if skip_prefix() + suits your needs better when using the former. + + +Also contains various documentation updates and code clean-ups. Many +of them came from flurry of activities as GSoC candidate microproject +exercises. + + +Fixes since v1.9 series +----------------------- + +Unless otherwise noted, all the fixes since v1.9 in the maintenance +track are contained in this release (see the maintenance releases' +notes for details). + + * "git p4" was broken in 1.9 release to deal with changes in binary + files. + (merge 749b668 cl/p4-use-diff-tree later to maint). + + * The shell prompt script (in contrib/), when using the PROMPT_COMMAND + interface, used an unsafe construct when showing the branch name in + $PS1. + (merge 1e4119c8 rh/prompt-pcmode-avoid-eval-on-refname later to maint). + + * "git rebase" used a POSIX shell construct FreeBSD's /bin/sh does not + work well with. + (merge 8cd6596 km/avoid-non-function-return-in-rebase later to maint). + + * zsh prompt (in contrib/) leaked unnecessary error messages. + + * Bash completion (in contrib/) did not complete the refs and remotes + correctly given "git pu<TAB>" when "pu" is aliased to "push". + + * Some more Unicode code points, defined in Unicode 6.3 as having zero + width, have been taught to our display column counting logic. + (merge d813ab9 tb/unicode-6.3-zero-width later to maint). + + * Some tests used shell constructs that did not work well on FreeBSD + (merge ff7a1c6 km/avoid-bs-in-shell-glob later to maint). + (merge 00764ca km/avoid-cp-a later to maint). + + * "git update-ref --stdin" did not fail a request to create a ref + when the ref already existed. + (merge b9d56b5 mh/update-ref-batch-create-fix later to maint). + + * "git diff --no-index -Mq a b" fell into an infinite loop. + (merge ad1c3fb jc/fix-diff-no-index-diff-opt-parse later to maint). + + * "git fetch --prune", when the right-hand side of multiple fetch + refspecs overlap (e.g. storing "refs/heads/*" to + "refs/remotes/origin/*", while storing "refs/frotz/*" to + "refs/remotes/origin/fr/*"), aggressively thought that lack of + "refs/heads/fr/otz" on the origin site meant we should remove + "refs/remotes/origin/fr/otz" from us, without checking their + "refs/frotz/otz" first. + + Note that such a configuration is inherently unsafe (think what + should happen when "refs/heads/fr/otz" does appear on the origin + site), but that is not a reason not to be extra careful. + (merge e6f6371 cn/fetch-prune-overlapping-destination later to maint). + + * "git status --porcelain --branch" showed its output with labels + "ahead/behind/gone" translated to the user's locale. + (merge 7a76c28 mm/status-porcelain-format-i18n-fix later to maint). + + * A stray environment variable $prefix could have leaked into and + affected the behaviour of the "subtree" script (in contrib/). + + * When it is not necessary to edit a commit log message (e.g. "git + commit -m" is given a message without specifying "-e"), we used to + disable the spawning of the editor by overriding GIT_EDITOR, but + this means all the uses of the editor, other than to edit the + commit log message, are also affected. + (merge b549be0 bp/commit-p-editor later to maint). + + * "git mv" that moves a submodule forgot to adjust the array that + uses to keep track of which submodules were to be moved to update + its configuration. + (merge fb8a4e8 jk/mv-submodules-fix later to maint). + + * Length limit for the pathname used when removing a path in a deep + subdirectory has been removed to avoid buffer overflows. + (merge 2f29e0c mh/remove-subtree-long-pathname-fix later to maint). + + * The test helper lib-terminal always run an actual test_expect_* + when included, which screwed up with the use of skil-all that may + have to be done later. + (merge 7e27173 jk/lib-terminal-lazy later to maint). + + * "git index-pack" used a wrong variable to name the keep-file in an + error message when the file cannot be written or closed. + (merge de983a0 nd/index-pack-error-message later to maint). + + * "rebase -i" produced a broken insn sheet when the title of a commit + happened to contain '\n' (or ended with '\c') due to a careless use + of 'echo'. + (merge cb1aefd us/printf-not-echo later to maint). + + * There were a few instances of 'git-foo' remaining in the + documentation that should have been spelled 'git foo'. + (merge 3c3e6f5 rr/doc-merge-strategies later to maint). + + * Serving objects from a shallow repository needs to write a + new file to hold the temporary shallow boundaries, but it was not + cleaned when we exit due to die() or a signal. + (merge 7839632 jk/shallow-update-fix later to maint). + + * When "git stash pop" stops after failing to apply the stash + (e.g. due to conflicting changes), the stash is not dropped. State + that explicitly in the output to let the users know. + (merge 2d4c993 jc/stash-pop-not-popped later to maint). + + * The labels in "git status" output that describe the nature of + conflicts (e.g. "both deleted") were limited to 20 bytes, which was + too short for some l10n (e.g. fr). + (merge c7cb333 jn/wt-status later to maint). + + * "git clean -d pathspec" did not use the given pathspec correctly + and ended up cleaning too much. + (merge 1f2e108 jk/clean-d-pathspec later to maint). + + * "git difftool" misbehaved when the repository is bound to the + working tree with the ".git file" mechanism, where a textual file + ".git" tells us where it is. + (merge fcfec8b da/difftool-git-files later to maint). + + * "git push" did not pay attention to "branch.*.pushremote" if it is + defined earlier than "remote.pushdefault"; the order of these two + variables in the configuration file should not matter, but it did + by mistake. + (merge 98b406f jk/remote-pushremote-config-reading later to maint). + + * Code paths that parse timestamps in commit objects have been + tightened. + (merge f80d1f9 jk/commit-dates-parsing-fix later to maint). + + * "git diff --external-diff" incorrectly fed the submodule directory + in the working tree to the external diff driver when it knew that it + is the same as one of the versions being compared. + (merge aba4727 tr/diff-submodule-no-reuse-worktree later to maint). + + * "git reset" needs to refresh the index when working in a working + tree (it can also be used to match the index to the HEAD in an + otherwise bare repository), but it failed to set up the working + tree properly, causing GIT_WORK_TREE to be ignored. + (merge b7756d4 nd/reset-setup-worktree later to maint). + + * "git check-attr" when working on a repository with a working tree + did not work well when the working tree was specified via the + "--work-tree" (and obviously with "--git-dir") option. + (merge cdbf623 jc/check-attr-honor-working-tree later to maint). + + * "merge-recursive" was broken in 1.7.7 era and stopped working in + an empty (temporary) working tree, when there are renames + involved. This has been corrected. + (merge 6e2068a bk/refresh-missing-ok-in-merge-recursive later to maint.) + + * "git rev-parse" was loose in rejecting command-line arguments + that do not make sense, e.g. "--default" without the required + value for that option. + (merge a43219f ds/rev-parse-required-args later to maint.) + + * "include.path" variable (or any variable that expects a path that + can use ~username expansion) in the configuration file is not a + boolean, but the code failed to check it. + (merge 67beb60 jk/config-path-include-fix later to maint.) + + * Commands that take pathspecs on the command line misbehaved when + the pathspec is given as an absolute pathname (which is a + practice not particularly encouraged) that points at a symbolic + link in the working tree. + (merge 6127ff6 mw/symlinks later to maint.) + + * "git diff --quiet -- pathspec1 pathspec2" sometimes did not return + the correct status value. + (merge f34b205 nd/diff-quiet-stat-dirty later to maint.) + + * Attempting to deepen a shallow repository by fetching over smart + HTTP transport failed in the protocol exchange, when the no-done + extension was used. The fetching side waited for the list of + shallow boundary commits after the sending side stopped talking to + it. + (merge 0232852 nd/http-fetch-shallow-fix later to maint.) + + * Allow "git cmd path/", when the 'path' is where a submodule is + bound to the top-level working tree, to match 'path', despite the + extra and unnecessary trailing slash (such a slash is often + given by command-line completion). + (merge 2e70c01 nd/submodule-pathspec-ending-with-slash later to maint.) + + * Documentation and in-code comments had many instances of mistaken + use of "nor", which have been corrected. + (merge 235e8d5 jl/nor-or-nand-and later to maint). diff --git a/Documentation/RelNotes/2.0.1.txt b/Documentation/RelNotes/2.0.1.txt new file mode 100644 index 0000000000..ce5579db3e --- /dev/null +++ b/Documentation/RelNotes/2.0.1.txt @@ -0,0 +1,115 @@ +Git v2.0.1 Release Notes +======================== + + * We used to unconditionally disable the pager in the pager process + we spawn to feed out output, but that prevented people who want to + run "less" within "less" from doing so. + + * Tools that read diagnostic output in our standard error stream do + not want to see terminal control sequence (e.g. erase-to-eol). + Detect them by checking if the standard error stream is connected + to a tty. + * Reworded the error message given upon a failure to open an existing + loose object file due to e.g. permission issues; it was reported as + the object being corrupt, but that is not quite true. + + * "git log -2master" is a common typo that shows two commits starting + from whichever random branch that is not 'master' that happens to + be checked out currently. + + * The "%<(10,trunc)%s" pretty format specifier in the log family of + commands is used to truncate the string to a given length (e.g. 10 + in the example) with padding to column-align the output, but did + not take into account that number of bytes and number of display + columns are different. + + * The "mailmap.file" configuration option did not support the tilde + expansion (i.e. ~user/path and ~/path). + + * The completion scripts (in contrib/) did not know about quite a few + options that are common between "git merge" and "git pull", and a + couple of options unique to "git merge". + + * "--ignore-space-change" option of "git apply" ignored the spaces + at the beginning of line too aggressively, which is inconsistent + with the option of the same name "diff" and "git diff" have. + + * "git blame" miscounted number of columns needed to show localized + timestamps, resulting in jaggy left-side-edge of the source code + lines in its output. + + * "git blame" assigned the blame to the copy in the working-tree if + the repository is set to core.autocrlf=input and the file used CRLF + line endings. + + * "git commit --allow-empty-message -C $commit" did not work when the + commit did not have any log message. + + * "git diff --find-copies-harder" sometimes pretended as if the mode + bits have changed for paths that are marked with assume-unchanged + bit. + + * "git format-patch" did not enforce the rule that the "--follow" + option from the log/diff family of commands must be used with + exactly one pathspec. + + * "git gc --auto" was recently changed to run in the background to + give control back early to the end-user sitting in front of the + terminal, but it forgot that housekeeping involving reflogs should + be done without other processes competing for accesses to the refs. + + * "git grep -O" to show the lines that hit in the pager did not work + well with case insensitive search. We now spawn "less" with its + "-I" option when it is used as the pager (which is the default). + + * We used to disable threaded "git index-pack" on platforms without + thread-safe pread(); use a different workaround for such + platforms to allow threaded "git index-pack". + + * The error reporting from "git index-pack" has been improved to + distinguish missing objects from type errors. + + * "git mailinfo" used to read beyond the end of header string while + parsing an incoming e-mail message to extract the patch. + + * On a case insensitive filesystem, merge-recursive incorrectly + deleted the file that is to be renamed to a name that is the same + except for case differences. + + * "git pack-objects" unnecessarily copied the previous contents when + extending the hashtable, even though it will populate the table + from scratch anyway. + + * "git rerere forget" did not work well when merge.conflictstyle + was set to a non-default value. + + * "git remote rm" and "git remote prune" can involve removing many + refs at once, which is not a very efficient thing to do when very + many refs exist in the packed-refs file. + + * "git log --exclude=<glob> --all | git shortlog" worked as expected, + but "git shortlog --exclude=<glob> --all", which is supposed to be + identical to the above pipeline, was not accepted at the command + line argument parser level. + + * The autostash mode of "git rebase -i" did not restore the dirty + working tree state if the user aborted the interactive rebase by + emptying the insn sheet. + + * "git show -s" (i.e. show log message only) used to incorrectly emit + an extra blank line after a merge commit. + + * "git status", even though it is a read-only operation, tries to + update the index with refreshed lstat(2) info to optimize future + accesses to the working tree opportunistically, but this could + race with a "read-write" operation that modify the index while it + is running. Detect such a race and avoid overwriting the index. + + * "git status" (and "git commit") behaved as if changes in a modified + submodule are not there if submodule.*.ignore configuration is set, + which was misleading. The configuration is only to unclutter diff + output during the course of development, and should not to hide + changes in the "status" output to cause the users forget to commit + them. + + * The mode to run tests with HTTP server tests disabled was broken. diff --git a/Documentation/RelNotes/2.0.2.txt b/Documentation/RelNotes/2.0.2.txt new file mode 100644 index 0000000000..8e8321b2ef --- /dev/null +++ b/Documentation/RelNotes/2.0.2.txt @@ -0,0 +1,32 @@ +Git v2.0.2 Release Notes +======================== + + * Documentation for "git submodule sync" forgot to say that the subcommand + can take the "--recursive" option. + + * Mishandling of patterns in .gitignore that has trailing SPs quoted + with backslashes (e.g. ones that end with "\ ") have been + corrected. + + * Recent updates to "git repack" started to duplicate objects that + are in packfiles marked with .keep flag into the new packfile by + mistake. + + * "git clone -b brefs/tags/bar" would have mistakenly thought we were + following a single tag, even though it was a name of the branch, + because it incorrectly used strstr(). + + * "%G" (nothing after G) is an invalid pretty format specifier, but + the parser did not notice it as garbage. + + * Code to avoid adding the same alternate object store twice was + subtly broken for a long time, but nobody seems to have noticed. + + * A handful of code paths had to read the commit object more than + once when showing header fields that are usually not parsed. The + internal data structure to keep track of the contents of the commit + object has been updated to reduce the need for this double-reading, + and to allow the caller find the length of the object. + + * During "git rebase --merge", a conflicted patch could not be + skipped with "--skip" if the next one also conflicted. diff --git a/Documentation/RelNotes/2.0.3.txt b/Documentation/RelNotes/2.0.3.txt new file mode 100644 index 0000000000..4047b46bbe --- /dev/null +++ b/Documentation/RelNotes/2.0.3.txt @@ -0,0 +1,17 @@ +Git v2.0.3 Release Notes +======================== + + * An ancient rewrite passed a wrong pointer to a curl library + function in a rarely used code path. + + * "filter-branch" left an empty single-parent commit that results when + all parents of a merge commit gets mapped to the same commit, even + under "--prune-empty". + + * "log --show-signature" incorrectly decided the color to paint a + mergetag that was and was not correctly validated. + + * "log --show-signature" did not pay attention to "--graph" option. + +Also a lot of fixes to the tests and some updates to the docs are +included. diff --git a/Documentation/RelNotes/2.0.4.txt b/Documentation/RelNotes/2.0.4.txt new file mode 100644 index 0000000000..7e340921a2 --- /dev/null +++ b/Documentation/RelNotes/2.0.4.txt @@ -0,0 +1,5 @@ +Git v2.0.4 Release Notes +======================== + + * An earlier update to v2.0.2 broken output from "git diff-tree", + which is fixed in this release. diff --git a/Documentation/RelNotes/2.0.5.txt b/Documentation/RelNotes/2.0.5.txt new file mode 100644 index 0000000000..3a16f697e8 --- /dev/null +++ b/Documentation/RelNotes/2.0.5.txt @@ -0,0 +1,34 @@ +Git v2.0.5 Release Notes +======================== + +Fixes since v2.0.4 +------------------ + + * We used to allow committing a path ".Git/config" with Git that is + running on a case sensitive filesystem, but an attempt to check out + such a path with Git that runs on a case insensitive filesystem + would have clobbered ".git/config", which is definitely not what + the user would have expected. Git now prevents you from tracking + a path with ".Git" (in any case combination) as a path component. + + * On Windows, certain path components that are different from ".git" + are mapped to ".git", e.g. "git~1/config" is treated as if it were + ".git/config". HFS+ has a similar issue, where certain unicode + codepoints are ignored, e.g. ".g\u200cit/config" is treated as if + it were ".git/config". Pathnames with these potential issues are + rejected on the affected systems. Git on systems that are not + affected by this issue (e.g. Linux) can also be configured to + reject them to ensure cross platform interoperability of the hosted + projects. + + * "git fsck" notices a tree object that records such a path that can + be confused with ".git", and with receive.fsckObjects configuration + set to true, an attempt to "git push" such a tree object will be + rejected. Such a path may not be a problem on a well behaving + filesystem but in order to protect those on HFS+ and on case + insensitive filesystems, this check is enabled on all platforms. + +A big "thanks!" for bringing this issue to us goes to our friends in +the Mercurial land, namely, Matt Mackall and Augie Fackler. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.1.0.txt b/Documentation/RelNotes/2.1.0.txt new file mode 100644 index 0000000000..ae4753728e --- /dev/null +++ b/Documentation/RelNotes/2.1.0.txt @@ -0,0 +1,391 @@ +Git v2.1 Release Notes +====================== + +Backward compatibility notes +---------------------------- + + * The default value we give to the environment variable LESS has been + changed from "FRSX" to "FRX", losing "S" (chop long lines instead + of wrapping). Existing users who prefer not to see line-wrapped + output may want to set + + $ git config core.pager "less -S" + + to restore the traditional behaviour. It is expected that people + find output from most subcommands easier to read with the new + default, except for "blame" which tends to produce really long + lines. To override the new default only for "git blame", you can + do this: + + $ git config pager.blame "less -S" + + * A few disused directories in contrib/ have been retired. + + +Updates since v2.0 +------------------ + +UI, Workflows & Features + + * Since the very beginning of Git, we gave the LESS environment a + default value "FRSX" when we spawn "less" as the pager. "S" (chop + long lines instead of wrapping) has been removed from this default + set of options, because it is more or less a personal taste thing, + as opposed to the others that have good justifications (i.e. "R" is + very much justified because many kinds of output we produce are + colored and "FX" is justified because output we produce is often + shorter than a page). + + * The logic and data used to compute the display width needed for + UTF-8 strings have been updated to match Unicode 7.0 better. + + * HTTP-based transports learned to better propagate the error messages from + the webserver to the client coming over the HTTP transport. + + * The completion script for bash (in contrib/) has been updated to + better handle aliases that define a complex sequence of commands. + + * The "core.preloadindex" configuration variable is enabled by default, + allowing modern platforms to take advantage of their + multiple cores. + + * "git clone" applies the "if cloning from a local disk, physically + copy the repository using hardlinks, unless otherwise told not to with + --no-local" optimization when the url.*.insteadOf mechanism rewrites a + remote-repository "git clone $URL" into a + clone from a local disk. + + * "git commit --date=<date>" option learned more + timestamp formats, including "--date=now". + + * The `core.commentChar` configuration variable is used to specify a + custom comment character (other than the default "#") for + the commit message editor. This can be set to `auto` to attempt to + choose a different character that does not conflict with any that + already starts a line in the message being edited, for cases like + "git commit --amend". + + * "git format-patch" learned --signature-file=<file> to add the contents + of a file as a signature to the mail message it produces. + + * "git grep" learned the grep.fullname configuration variable to force + "--full-name" to be the default. This may cause regressions for + scripted users who do not expect this new behaviour. + + * "git imap-send" learned to ask the credential helper for auth + material. + + * "git log" and friends now understand the value "auto" for the + "log.decorate" configuration variable to enable the "--decorate" + option automatically when the output is sent to tty. + + * "git merge" without an argument, even when there is an upstream + defined for the current branch, refused to run until + merge.defaultToUpstream is set to true. Flip the default of that + configuration variable to true. + + * "git mergetool" learned to drive the vimdiff3 backend. + + * mergetool.prompt used to default to 'true', always asking "do you + really want to run the tool on this path?". The default has been + changed to 'false'. However, the prompt will still appear if + mergetool used its autodetection system to guess which tool to use. + Users who explicitly specify or configure a tool will no longer see + the prompt by default. + + Strictly speaking, this is a backward incompatible change and + users need to explicitly set the variable to 'true' if they want + to be prompted to confirm running the tool on each path. + + * "git replace" learned the "--edit" subcommand to create a + replacement by editing an existing object. + + * "git replace" learned a "--graft" option to rewrite the parents of a + commit. + + * "git send-email" learned "--to-cover" and "--cc-cover" options, to + tell it to copy To: and Cc: headers found in the first input file + when emitting later input files. + + * "git svn" learned to cope with malformed timestamps with only one + digit in the hour part, e.g. 2014-01-07T5:01:02.048176Z, emitted + by some broken subversion server implementations. + + * "git tag" when editing the tag message shows the name of the tag + being edited as a comment in the editor. + + * "git tag" learned to pay attention to "tag.sort" configuration, to + be used as the default sort order when no --sort=<value> option + is given. + + * A new "git verify-commit" command, to check GPG signatures in signed + commits, in a way similar to "git verify-tag" is used to check + signed tags, was added. + + +Performance, Internal Implementation, etc. + + * Build procedure for 'subtree' (in contrib/) has been cleaned up. + + * Support for the profile-feedback build, which has + bit-rotted for quite a while, has been updated. + + * An experimental format to use two files (the base file and + incremental changes relative to it) to represent the index has been + introduced; this may reduce I/O cost of rewriting a large index + when only small part of the working tree changes. + + * Effort to shrink the size of patches Windows folks maintain on top + by upstreaming them continues. More tests that are not applicable + to the Windows environment are identified and either skipped or + made more portable. + + * Eradication of "test $condition -a $condition" from our scripts + continues. + + * The `core.deltabasecachelimit` used to default to 16 MiB , but this + proved to be too small, and has been bumped to 96 MiB. + + * "git blame" has been optimized greatly by reorganising the data + structure that is used to keep track of the work to be done. + + * "git diff" that compares 3-or-more trees (e.g. parents and the + result of a merge) has been optimized. + + * The API to update/delete references are being converted to handle + updates to multiple references in a transactional way. As an + example, "update-ref --stdin [-z]" has been updated to use this + API. + + * skip_prefix() and strip_suffix() API functions are used a lot more + widely throughout the codebase now. + + * Parts of the test scripts can be skipped by using a range notation, + e.g. "sh t1234-test.sh --run='1-4 6 8-'" to omit test piece 5 and 7 + and run everything else. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.0 +---------------- + +Unless otherwise noted, all the fixes since v2.0 in the maintenance +track are contained in this release (see the maintenance releases' +notes for details). + + * We used to unconditionally disable the pager in the pager process + we spawn to feed out output, but that prevented people who want to + run "less" within "less" from doing so. + (merge c0459ca je/pager-do-not-recurse later to maint). + + * Tools that read diagnostic output in our standard error stream do + not want to see terminal control sequence (e.g. erase-to-eol). + Detect them by checking if the standard error stream is connected + to a tty. + (merge 38de156 mn/sideband-no-ansi later to maint). + + * Mishandling of patterns in .gitignore that have trailing SPs quoted + with backslashes (e.g. ones that end with "\ ") has been + corrected. + (merge 97c1364be6b pb/trim-trailing-spaces later to maint). + + * Reworded the error message given upon a failure to open an existing + loose object file due to e.g. permission issues; it was reported as + the object being corrupt, but that is not quite true. + (merge d6c8a05 jk/report-fail-to-read-objects-better later to maint). + + * "git log -2master" is a common typo that shows two commits starting + from whichever random branch that is not 'master' that happens to + be checked out currently. + (merge e3fa568 jc/revision-dash-count-parsing later to maint). + + * Code to avoid adding the same alternate object store twice was + subtly broken for a long time, but nobody seems to have noticed. + (merge 80b4785 rs/fix-alt-odb-path-comparison later to maint). + (merge 539e750 ek/alt-odb-entry-fix later to maint). + + * The "%<(10,trunc)%s" pretty format specifier in the log family of + commands is used to truncate the string to a given length (e.g. 10 + in the example) with padding to column-align the output, but did + not take into account that number of bytes and number of display + columns are different. + (merge 7d50987 as/pretty-truncate later to maint). + + * "%G" (nothing after G) is an invalid pretty format specifier, but + the parser did not notice it as garbage. + (merge 958b2eb jk/pretty-G-format-fixes later to maint). + + * A handful of code paths had to read the commit object more than + once when showing header fields that are usually not parsed. The + internal data structure to keep track of the contents of the commit + object has been updated to reduce the need for this double-reading, + and to allow the caller find the length of the object. + (merge 218aa3a jk/commit-buffer-length later to maint). + + * The "mailmap.file" configuration option did not support tilde + expansion (i.e. ~user/path and ~/path). + (merge 9352fd5 ow/config-mailmap-pathname later to maint). + + * The completion scripts (in contrib/) did not know about quite a few + options that are common between "git merge" and "git pull", and a + couple of options unique to "git merge". + (merge 8fee872 jk/complete-merge-pull later to maint). + + * The unix-domain socket used by the sample credential cache daemon + tried to unlink an existing stale one at a wrong path, if the path + to the socket was given as an overlong path that does not fit in + the sun_path member of the sockaddr_un structure. + (merge 2869b3e rs/fix-unlink-unix-socket later to maint). + + * An ancient rewrite passed a wrong pointer to a curl library + function in a rarely used code path. + (merge 479eaa8 ah/fix-http-push later to maint). + + * "--ignore-space-change" option of "git apply" ignored the spaces + at the beginning of lines too aggressively, which is inconsistent + with the option of the same name that "diff" and "git diff" have. + (merge 14d3bb4 jc/apply-ignore-whitespace later to maint). + + * "git blame" miscounted the number of columns needed to show localized + timestamps, resulting in a jaggy left-side-edge for the source code + lines in its output. + (merge dd75553 jx/blame-align-relative-time later to maint). + + * "git blame" assigned the blame to the copy in the working-tree if + the repository is set to core.autocrlf=input and the file used CRLF + line endings. + (merge 4d4813a bc/blame-crlf-test later to maint). + + * "git clone -b brefs/tags/bar" would have mistakenly thought we were + following a single tag, even though it was a name of the branch, + because it incorrectly used strstr(). + (merge 60a5f5f jc/fix-clone-single-starting-at-a-tag later to maint). + + * "git commit --allow-empty-message -C $commit" did not work when the + commit did not have any log message. + (merge 076cbd6 jk/commit-C-pick-empty later to maint). + + * "git diff --find-copies-harder" sometimes pretended as if the mode + bits have changed for paths that are marked with the assume-unchanged + bit. + (merge 5304810 jk/diff-files-assume-unchanged later to maint). + + * "filter-branch" left an empty single-parent commit that results when + all parents of a merge commit get mapped to the same commit, even + under "--prune-empty". + (merge 79bc4ef cb/filter-branch-prune-empty-degenerate-merges later to maint). + + * "git format-patch" did not enforce the rule that the "--follow" + option from the log/diff family of commands must be used with + exactly one pathspec. + (merge dd63f16 jk/diff-follow-must-take-one-pathspec later to maint). + + * "git gc --auto" was recently changed to run in the background to + give control back early to the end-user sitting in front of the + terminal, but it forgot that housekeeping involving reflogs should + be done without other processes competing for accesses to the refs. + (merge 62aad18 nd/daemonize-gc later to maint). + + * "git grep -O" to show the lines that hit in the pager did not work + well with case insensitive search. We now spawn "less" with its + "-I" option when it is used as the pager (which is the default). + (merge f7febbe sk/spawn-less-case-insensitively-from-grep-O-i later to maint). + + * We used to disable threaded "git index-pack" on platforms without + thread-safe pread(); use a different workaround for such + platforms to allow threaded "git index-pack". + (merge 3953949 nd/index-pack-one-fd-per-thread later to maint). + + * The error reporting from "git index-pack" has been improved to + distinguish missing objects from type errors. + (merge 77583e7 jk/index-pack-report-missing later to maint). + + * "log --show-signature" incorrectly decided the color to paint a + mergetag that was and was not correctly validated. + (merge 42c55ce mg/fix-log-mergetag-color later to maint). + + * "log --show-signature" did not pay attention to the "--graph" option. + (merge cf3983d zk/log-graph-showsig later to maint). + + * "git mailinfo" used to read beyond the ends of header strings while + parsing an incoming e-mail message to extract the patch. + (merge b1a013d rs/mailinfo-header-cmp later to maint). + + * On a case insensitive filesystem, merge-recursive incorrectly + deleted the file that is to be renamed to a name that is the same + except for case differences. + (merge baa37bf dt/merge-recursive-case-insensitive later to maint). + + * Merging changes into a file that ends in an incomplete line made the + last line into a complete one, even when the other branch did not + change anything around the end of file. + (merge ba31180 mk/merge-incomplete-files later to maint). + + * "git pack-objects" unnecessarily copied the previous contents when + extending the hashtable, even though it will populate the table + from scratch anyway. + (merge fb79947 rs/pack-objects-no-unnecessary-realloc later to maint). + + * Recent updates to "git repack" started to duplicate objects that + are in packfiles marked with the .keep flag into the new packfile by + mistake. + (merge d078d85 jk/repack-pack-keep-objects later to maint). + + * "git rerere forget" did not work well when merge.conflictstyle + was set to a non-default value. + (merge de3d8bb fc/rerere-conflict-style later to maint). + + * "git remote rm" and "git remote prune" can involve removing many + refs at once, which is not a very efficient thing to do when very + many refs exist in the packed-refs file. + (merge e6bea66 jl/remote-rm-prune later to maint). + + * "git log --exclude=<glob> --all | git shortlog" worked as expected, + but "git shortlog --exclude=<glob> --all", which is supposed to be + identical to the above pipeline, was not accepted at the command + line argument parser level. + (merge eb07774 jc/shortlog-ref-exclude later to maint). + + * The autostash mode of "git rebase -i" did not restore the dirty + working tree state if the user aborted the interactive rebase by + emptying the insn sheet. + (merge ddb5432 rr/rebase-autostash-fix later to maint). + + * "git rebase --fork-point" did not filter out patch-identical + commits correctly. + + * During "git rebase --merge", a conflicted patch could not be + skipped with "--skip" if the next one also conflicted. + (merge 95104c7 bc/fix-rebase-merge-skip later to maint). + + * "git show -s" (i.e. show log message only) used to incorrectly emit + an extra blank line after a merge commit. + (merge ad2f725 mk/show-s-no-extra-blank-line-for-merges later to maint). + + * "git status", even though it is a read-only operation, tries to + update the index with refreshed lstat(2) info to optimize future + accesses to the working tree opportunistically, but this could + race with a "read-write" operation that modifies the index while it + is running. Detect such a race and avoid overwriting the index. + (merge 426ddee ym/fix-opportunistic-index-update-race later to maint). + + * "git status" (and "git commit") behaved as if changes in a modified + submodule are not there if submodule.*.ignore configuration is set, + which was misleading. The configuration is only to unclutter diff + output during the course of development, and not to hide + changes in the "status" output to cause the users forget to commit + them. + (merge c215d3d jl/status-added-submodule-is-never-ignored later to maint). + + * Documentation for "git submodule sync" forgot to say that the subcommand + can take the "--recursive" option. + (merge 9393ae7 mc/doc-submodule-sync-recurse later to maint). + + * "git update-index --cacheinfo" in 2.0 release crashed on a + malformed command line. + (merge c8e1ee4 jc/rev-parse-argh-dashed-multi-words later to maint). + + * The mode to run tests with HTTP server tests disabled was broken. + (merge afa53fe na/no-http-test-in-the-middle later to maint). diff --git a/Documentation/RelNotes/2.1.1.txt b/Documentation/RelNotes/2.1.1.txt new file mode 100644 index 0000000000..830fc3cc6d --- /dev/null +++ b/Documentation/RelNotes/2.1.1.txt @@ -0,0 +1,44 @@ +Git v2.1.1 Release Notes +======================== + + * Git 2.0 had a regression where "git fetch" into a shallowly + cloned repository from a repository with bitmap object index + enabled did not work correctly. This has been corrected. + + * Git 2.0 had a regression which broke (rarely used) "git diff-tree + -t". This has been corrected. + + * "git log --pretty/format=" with an empty format string did not + mean the more obvious "No output whatsoever" but "Use default + format", which was counterintuitive. Now it means "nothing shown + for the log message part". + + * "git -c section.var command" and "git -c section.var= command" + should pass the configuration differently (the former should be a + boolean true, the latter should be an empty string), but they + didn't work that way. Now it does. + + * Applying a patch not generated by Git in a subdirectory used to + check the whitespace breakage using the attributes for incorrect + paths. Also whitespace checks were performed even for paths + excluded via "git apply --exclude=<path>" mechanism. + + * "git bundle create" with date-range specification were meant to + exclude tags outside the range, but it did not work correctly. + + * "git add x" where x that used to be a directory has become a + symbolic link to a directory misbehaved. + + * The prompt script checked $GIT_DIR/ref/stash file to see if there + is a stash, which was a no-no. + + * "git checkout -m" did not switch to another branch while carrying + the local changes forward when a path was deleted from the index. + + * With sufficiently long refnames, fast-import could have overflown + an on-stack buffer. + + * After "pack-refs --prune" packed refs at the top-level, it failed + to prune them. + + * "git gc --auto" triggered from "git fetch --quiet" was not quiet. diff --git a/Documentation/RelNotes/2.1.2.txt b/Documentation/RelNotes/2.1.2.txt new file mode 100644 index 0000000000..abc3b8928a --- /dev/null +++ b/Documentation/RelNotes/2.1.2.txt @@ -0,0 +1,20 @@ +Git v2.1.2 Release Notes +======================== + + * "git push" over HTTP transport had an artificial limit on number of + refs that can be pushed imposed by the command line length. + + * When receiving an invalid pack stream that records the same object + twice, multiple threads got confused due to a race. + + * An attempt to remove the entire tree in the "git fast-import" input + stream caused it to misbehave. + + * Reachability check (used in "git prune" and friends) did not add a + detached HEAD as a starting point to traverse objects still in use. + + * "git config --add section.var val" used to lose existing + section.var whose value was an empty string. + + * "git fsck" failed to report that it found corrupt objects via its + exit status in some cases. diff --git a/Documentation/RelNotes/2.1.3.txt b/Documentation/RelNotes/2.1.3.txt new file mode 100644 index 0000000000..acc9ebb886 --- /dev/null +++ b/Documentation/RelNotes/2.1.3.txt @@ -0,0 +1,26 @@ +Git v2.1.3 Release Notes +======================== + + * Some MUAs mangled a line in a message that begins with "From " to + ">From " when writing to a mailbox file and feeding such an input to + "git am" used to lose such a line. + + * "git daemon" (with NO_IPV6 build configuration) used to incorrectly + use the hostname even when gethostbyname() reported that the given + hostname is not found. + + * Newer versions of 'meld' breaks the auto-detection we use to see if + they are new enough to support the `--output` option. + + * "git pack-objects" forgot to disable the codepath to generate + object recheability bitmap when it needs to split the resulting + pack. + + * "gitweb" used deprecated CGI::startfrom, which was removed from + CGI.pm as of 4.04; use CGI::start_from instead. + + * "git log" documentation had an example section marked up not + quite correctly, which passed AsciiDoc but failed with + AsciiDoctor. + +Also contains some documentation updates. diff --git a/Documentation/RelNotes/2.1.4.txt b/Documentation/RelNotes/2.1.4.txt new file mode 100644 index 0000000000..d16e5f041f --- /dev/null +++ b/Documentation/RelNotes/2.1.4.txt @@ -0,0 +1,34 @@ +Git v2.1.4 Release Notes +======================== + +Fixes since v2.1.3 +------------------ + + * We used to allow committing a path ".Git/config" with Git that is + running on a case sensitive filesystem, but an attempt to check out + such a path with Git that runs on a case insensitive filesystem + would have clobbered ".git/config", which is definitely not what + the user would have expected. Git now prevents you from tracking + a path with ".Git" (in any case combination) as a path component. + + * On Windows, certain path components that are different from ".git" + are mapped to ".git", e.g. "git~1/config" is treated as if it were + ".git/config". HFS+ has a similar issue, where certain unicode + codepoints are ignored, e.g. ".g\u200cit/config" is treated as if + it were ".git/config". Pathnames with these potential issues are + rejected on the affected systems. Git on systems that are not + affected by this issue (e.g. Linux) can also be configured to + reject them to ensure cross platform interoperability of the hosted + projects. + + * "git fsck" notices a tree object that records such a path that can + be confused with ".git", and with receive.fsckObjects configuration + set to true, an attempt to "git push" such a tree object will be + rejected. Such a path may not be a problem on a well behaving + filesystem but in order to protect those on HFS+ and on case + insensitive filesystems, this check is enabled on all platforms. + +A big "thanks!" for bringing this issue to us goes to our friends in +the Mercurial land, namely, Matt Mackall and Augie Fackler. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.2.0.txt b/Documentation/RelNotes/2.2.0.txt new file mode 100644 index 0000000000..e98ecbcff6 --- /dev/null +++ b/Documentation/RelNotes/2.2.0.txt @@ -0,0 +1,313 @@ +Git v2.2 Release Notes +====================== + +Updates since v2.1 +------------------ + +Ports + + * Building on older MacOS X systems automatically sets + the necessary NO_APPLE_COMMON_CRYPTO build-time option. + + * Building with NO_PTHREADS has been resurrected. + + * Compilation options have been updated a bit to better support the + z/OS port. + + +UI, Workflows & Features + + * "git archive" learned to filter what gets archived with a pathspec. + + * "git config --edit --global" starts from a skeletal per-user + configuration file contents, instead of a total blank, when the + user does not already have any global config. This immediately + reduces the need to later ask "Have you forgotten to set + core.user?", and we can add more to the template as we gain + more experience. + + * "git stash list -p" used to be almost always a no-op because each + stash entry is represented as a merge commit. It learned to show + the difference between the base commit version and the working tree + version, which is in line with what "git stash show" gives. + + * Sometimes users want to report a bug they experience on their + repository, but they are not at liberty to share the contents of + the repository. "fast-export" was taught an "--anonymize" option + to replace blob contents, names of people, paths and log + messages with bland and simple strings to help them. + + * "git difftool" learned an option to stop feeding paths to the + diff backend when it exits with a non-zero status. + + * "git grep" learned to paint (or not paint) partial matches on + context lines when showing "grep -C<num>" output in color. + + * "log --date=iso" uses a slight variant of the ISO 8601 format that is + more human readable. A new "--date=iso-strict" option gives + datetime output that conforms more strictly. + + * The logic "git prune" uses is more resilient against various corner + cases. + + * A broken reimplementation of Git could write an invalid index that + records both stage #0 and higher-stage entries for the same path. + We now notice and reject such an index, as there is no sensible + fallback (we do not know if the broken tool wanted to resolve and + forgot to remove the higher-stage entries, or if it wanted to unresolve + and forgot to remove the stage #0 entry). + + * The temporary files "git mergetool" uses are renamed to avoid too + many dots in them (e.g. a temporary file for "hello.c" used to be + named e.g. "hello.BASE.4321.c" but now uses underscore instead, + e.g. "hello_BASE_4321.c", to allow us to have multiple variants). + + * The temporary files "git mergetool" uses can be placed in a newly + created temporary directory, instead of the current directory, by + setting the mergetool.writeToTemp configuration variable. + + * "git mergetool" understands "--tool bc" now, as version 4 of + BeyondCompare can be driven the same way as its version 3 and it + feels awkward to say "--tool bc3" to run version 4. + + * The "pre-receive" and "post-receive" hooks are no longer required + to consume their input fully (not following this requirement used + to result in intermittent errors in "git push"). + + * The pretty-format specifier "%d", which expands to " (tagname)" + for a tagged commit, gained a cousin "%D" that just gives the + "tagname" without frills. + + * "git push" learned "--signed" push, that allows a push (i.e. + request to update the refs on the other side to point at a new + history, together with the transmission of necessary objects) to be + signed, so that it can be verified and audited, using the GPG + signature of the person who pushed, that the tips of branches at a + public repository really point the commits the pusher wanted to, + without having to "trust" the server. + + * "git interpret-trailers" is a new filter to programmatically edit + the tail end of the commit log messages, e.g. "Signed-off-by:". + + * "git help everyday" shows the "Everyday Git in 20 commands or so" + document, whose contents have been updated to match more modern + Git practice. + + * On the "git svn" front, work progresses to reduce memory consumption and + to improve handling of mergeinfo. + + +Performance, Internal Implementation, Development Support etc. + + * The API to manipulate the "refs" has been restructured to make it + more transactional, with the eventual goal to allow all-or-none + atomic updates and migrating the storage to something other than + the traditional filesystem based one (e.g. databases). + + * The lockfile API and its users have been cleaned up. + + * We no longer attempt to keep track of individual dependencies to + the header files in the build procedure, relying instead on automated + dependency generation support from modern compilers. + + * In tests, we have been using NOT_{MINGW,CYGWIN} test prerequisites + long before negated prerequisites e.g. !MINGW were invented. + The former has been converted to the latter to avoid confusion. + + * Optimized looking up a remote's configuration in a repository with very many + remotes defined. + + * There are cases where you lock and open to write a file, close it + to show the updated contents to an external processes, and then have + to update the file again while still holding the lock; now the + lockfile API has support for such an access pattern. + + * The API to allocate the structure to keep track of commit + decoration has been updated to make it less cumbersome to use. + + * An in-core caching layer to let us avoid reading the same + configuration files several times has been added. A few commands + have been converted to use this subsystem. + + * Various code paths have been cleaned up and simplified by using + the "strbuf", "starts_with()", and "skip_prefix()" APIs more. + + * A few codepaths that died when large blobs that would not fit in + core are involved in their operation have been taught to punt + instead, by e.g. marking a too-large blob as not to be diffed. + + * A few more code paths in "commit" and "checkout" have been taught + to repopulate the cache-tree in the index, to help speed up later + "write-tree" (used in "commit") and "diff-index --cached" (used in + "status"). + + * A common programming mistake to assign the same short option name + to two separate options is detected by the parse_options() API to help + developers. + + * The code path to write out the packed-refs file has been optimized, + which especially matters in a repository with a large number of + refs. + + * The check to see if a ref $F can be created by making sure no + existing ref has $F/ as its prefix has been optimized, which + especially matters in a repository with a large number of existing + refs. + + * "git fsck" was taught to check the contents of tag objects a bit more. + + * "git hash-object" was taught a "--literally" option to help + debugging. + + * When running a required clean filter, we do not have to mmap the + original before feeding the filter. Instead, stream the file + contents directly to the filter and process its output. + + * The scripts in the test suite can be run with the "-x" option to show + a shell-trace of each command they run. + + * The "run-command" API learned to manage the argv and environment + arrays for child process, alleviating the need for the callers to + allocate and deallocate them. + + * Some people use AsciiDoctor, instead of AsciiDoc, to format our + documentation set; the documentation has been adjusted to be usable + by both, as AsciiDoctor is pickier than AsciiDoc about its input + mark-up. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.1 +---------------- + +Unless otherwise noted, all the fixes since v2.1 in the maintenance +track are contained in this release (see the maintenance releases' +notes for details). + + * "git log --pretty/format=" with an empty format string did not + mean the more obvious "No output whatsoever" but "Use default + format", which was counterintuitive. + + * "git -c section.var command" and "git -c section.var= command" + should pass the configuration value differently (the former should be a + boolean true, the latter should be an empty string). + + * Applying a patch not generated by Git in a subdirectory used to + check for whitespace breakage using the attributes of incorrect + paths. Also whitespace checks were performed even for paths + excluded via the "git apply --exclude=<path>" mechanism. + + * "git bundle create" with a date-range specification was meant to + exclude tags outside the range, but it didn't. + + * "git add x" where x used to be a directory and is now a + symbolic link to a directory misbehaved. + + * The prompt script checked the $GIT_DIR/ref/stash file to see if there + is a stash, which was a no-no. + + * Pack-protocol documentation had a minor typo. + + * "git checkout -m" did not switch to another branch while carrying + the local changes forward when a path was deleted from the index. + + * "git daemon" (with NO_IPV6 build configuration) used to incorrectly + use the hostname even when gethostbyname() reported that the given + hostname is not found. + (merge 107efbe rs/daemon-fixes later to maint). + + * With sufficiently long refnames, "git fast-import" could have + overflowed an on-stack buffer. + + * After "pack-refs --prune" packed refs at the top-level, it failed + to prune them. + + * Progress output from "git gc --auto" was visible in "git fetch -q". + + * We used to pass -1000 to poll(2), expecting it to also mean "no + timeout", which should be spelled as -1. + + * "git rebase" documentation was unclear that it is required to + specify on what <upstream> the rebase is to be done when telling it + to first check out <branch>. + (merge 95c6826 so/rebase-doc later to maint). + + * "git push" over HTTP transport had an artificial limit on the number of + refs that can be pushed, imposed by the command line length. + (merge 26be19b jk/send-pack-many-refspecs later to maint). + + * When receiving an invalid pack stream that records the same object + twice, multiple threads got confused due to a race. + (merge ab791dd jk/index-pack-threading-races later to maint). + + * An attempt to remove the entire tree in the "git fast-import" input + stream caused it to misbehave. + (merge 2668d69 mb/fast-import-delete-root later to maint). + + * Reachability check (used in "git prune" and friends) did not add a + detached HEAD as a starting point to traverse objects still in use. + (merge c40fdd0 mk/reachable-protect-detached-head later to maint). + + * "git config --add section.var val" when section.var already has an + empty-string value used to lose the empty-string value. + (merge c1063be ta/config-add-to-empty-or-true-fix later to maint). + + * "git fsck" failed to report that it found corrupt objects via its + exit status in some cases. + (merge 30d1038 jk/fsck-exit-code-fix later to maint). + + * Use of the "--verbose" option used to break "git branch --merged". + (merge 12994dd jk/maint-branch-verbose-merged later to maint). + + * Some MUAs mangle a line in a message that begins with "From " to + ">From " when writing to a mailbox file, and feeding such an input + to "git am" used to lose such a line. + (merge 85de86a jk/mbox-from-line later to maint). + + * "rev-parse --verify --quiet $name" is meant to quietly exit with a + non-zero status when $name is not a valid object name, but still + gave error messages in some cases. + + * A handful of C source files have been updated to include + "git-compat-util.h" as the first thing, to conform better to our + coding guidelines. + (merge 1c4b660 da/include-compat-util-first-in-c later to maint). + + * The t7004 test, which tried to run Git with small stack space, has been + updated to use a bit larger stack to avoid false breakage on some + platforms. + (merge b9a1907 sk/tag-contains-wo-recursion later to maint). + + * A few documentation pages had example sections marked up not quite + correctly, which passed AsciiDoc but failed with AsciiDoctor. + (merge c30c43c bc/asciidoc-pretty-formats-fix later to maint). + (merge f8a48af bc/asciidoc later to maint). + + * "gitweb" used deprecated CGI::startfrom, which was removed from + CGI.pm as of 4.04; use CGI::start_from instead. + (merge 4750f4b rm/gitweb-start-form later to maint). + + * Newer versions of 'meld' break the auto-detection we use to see if + they are new enough to support the `--output` option. + (merge b12d045 da/mergetool-meld later to maint). + + * "git pack-objects" forgot to disable the codepath to generate the + object reachability bitmap when it needs to split the resulting + pack. + (merge 2113471 jk/pack-objects-no-bitmap-when-splitting later to maint). + + * The code to use cache-tree trusted the on-disk data too much and + fell into an infinite loop upon seeing an incorrectly recorded + index file. + (merge 729dbbd jk/cache-tree-protect-from-broken-libgit2 later to maint). + + * "git fetch" into a repository where branch B was deleted earlier, + back when it had reflog enabled, and then branch B/C is fetched + into it without reflog enabled, which is arguably an unlikely + corner case, unnecessarily failed. + (merge aae828b jk/fetch-reflog-df-conflict later to maint). + + * "git log --first-parent -L..." used to crash. + (merge a8787c5 tm/line-log-first-parent later to maint). diff --git a/Documentation/RelNotes/2.2.1.txt b/Documentation/RelNotes/2.2.1.txt new file mode 100644 index 0000000000..d5a3cd9e73 --- /dev/null +++ b/Documentation/RelNotes/2.2.1.txt @@ -0,0 +1,34 @@ +Git v2.2.1 Release Notes +======================== + +Fixes since v2.2 +---------------- + + * We used to allow committing a path ".Git/config" with Git that is + running on a case sensitive filesystem, but an attempt to check out + such a path with Git that runs on a case insensitive filesystem + would have clobbered ".git/config", which is definitely not what + the user would have expected. Git now prevents you from tracking + a path with ".Git" (in any case combination) as a path component. + + * On Windows, certain path components that are different from ".git" + are mapped to ".git", e.g. "git~1/config" is treated as if it were + ".git/config". HFS+ has a similar issue, where certain unicode + codepoints are ignored, e.g. ".g\u200cit/config" is treated as if + it were ".git/config". Pathnames with these potential issues are + rejected on the affected systems. Git on systems that are not + affected by this issue (e.g. Linux) can also be configured to + reject them to ensure cross platform interoperability of the hosted + projects. + + * "git fsck" notices a tree object that records such a path that can + be confused with ".git", and with receive.fsckObjects configuration + set to true, an attempt to "git push" such a tree object will be + rejected. Such a path may not be a problem on a well behaving + filesystem but in order to protect those on HFS+ and on case + insensitive filesystems, this check is enabled on all platforms. + +A big "thanks!" for bringing this issue to us goes to our friends in +the Mercurial land, namely, Matt Mackall and Augie Fackler. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.2.2.txt b/Documentation/RelNotes/2.2.2.txt new file mode 100644 index 0000000000..b19a35d94f --- /dev/null +++ b/Documentation/RelNotes/2.2.2.txt @@ -0,0 +1,63 @@ +Git v2.2.2 Release Notes +======================== + +Fixes since v2.2.1 +------------------ + + * "git checkout $treeish $path", when $path in the index and the + working tree already matched what is in $treeish at the $path, + still overwrote the $path unnecessarily. + + * "git config --get-color" did not parse its command line arguments + carefully. + + * open() emulated on Windows platforms did not give EISDIR upon + an attempt to open a directory for writing. + + * A few code paths used abs() when they should have used labs() on + long integers. + + * "gitweb" used to depend on a behaviour recent CGI.pm deprecated. + + * "git init" (hence "git clone") initialized the per-repository + configuration file .git/config with x-bit by mistake. + + * Git 2.0 was supposed to make the "simple" mode for the default of + "git push", but it didn't. + + * "Everyday" document had a broken link. + + * The build procedure did not bother fixing perl and python scripts + when NO_PERL and NO_PYTHON build-time configuration changed. + + * The code that reads the reflog from the newer to the older entries + did not handle an entry that crosses a boundary of block it uses to + read them correctly. + + * "git apply" was described in the documentation to take --ignore-date + option, which it does not. + + * Traditionally we tried to avoid interpreting date strings given by + the user as future dates, e.g. GIT_COMMITTER_DATE=2014-12-10 when + used early November 2014 was taken as "October 12, 2014" because it + is likely that a date in the future, December 10, is a mistake. + This heuristics has been loosened to allow people to express future + dates (most notably, --until=<date> may want to be far in the + future) and we no longer tiebreak by future-ness of the date when + + (1) ISO-like format is used, and + (2) the string can make sense interpreted as both y-m-d and y-d-m. + + Git may still have to use the heuristics to tiebreak between dd/mm/yy + and mm/dd/yy, though. + + * The code to abbreviate an object name to its short unique prefix + has been optimized when no abbreviation was requested. + + * "git add --ignore-errors ..." did not ignore an error to + give a file that did not exist. + + * Git did not correctly read an overlong refname from a packed refs + file. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.3.0.txt b/Documentation/RelNotes/2.3.0.txt new file mode 100644 index 0000000000..e3c639c840 --- /dev/null +++ b/Documentation/RelNotes/2.3.0.txt @@ -0,0 +1,300 @@ +Git v2.3 Release Notes +====================== + +This one ended up to be a release with lots of small corrections and +improvements without big uncomfortably exciting features. The recent +security fix that went to 2.2.1 and older maintenance tracks is also +contained in this update. + + +Updates since v2.2 +------------------ + +Ports + + * Recent gcc toolchain on Cygwin started throwing compilation warning, + which has been squelched. + + * A few updates to build on platforms that lack tv_nsec, + clock_gettime, CLOCK_MONOTONIC and HMAC_CTX_cleanup (e.g. older + RHEL) have been added. + + +UI, Workflows & Features + + * It was cumbersome to use "GIT_SSH" mechanism when the user wanted + to pass an extra set of arguments to the underlying ssh. A new + environment variable GIT_SSH_COMMAND can be used for this. + + * A request to store an empty note via "git notes" meant to remove + note from the object but with --allow-empty we will store a + (surprise!) note that is empty. + + * "git interpret-trailers" learned to properly handle the + "Conflicts:" block at the end. + + * "git am" learned "--message-id" option to copy the message ID of + the incoming e-mail to the log message of resulting commit. + + * "git clone --reference=<over there>" learned the "--dissociate" + option to go with it; it borrows objects from the reference object + store while cloning only to reduce network traffic and then + dissociates the resulting clone from the reference by performing + local copies of borrowed objects. + + * "git send-email" learned "--transfer-encoding" option to force a + non-fault Content-Transfer-Encoding header (e.g. base64). + + * "git send-email" normally identifies itself via X-Mailer: header in + the message it sends out. A new command line flag --no-xmailer + allows the user to squelch the header. + + * "git push" into a repository with a working tree normally refuses + to modify the branch that is checked out. The command learned to + optionally do an equivalent of "git reset --hard" only when there + is no change to the working tree and the index instead, which would + be useful to "deploy" by pushing into a repository. + + * "git new-workdir" (in contrib/) can be used to populate an empty + and existing directory now. + + * Credential helpers are asked in turn until one of them give + positive response, which is cumbersome to turn off when you need to + run Git in an automated setting. The credential helper interface + learned to allow a helper to say "stop, don't ask other helpers." + Also GIT_TERMINAL_PROMPT environment can be set to false to disable + our built-in prompt mechanism for passwords. + + * "git branch -d" (delete) and "git branch -m" (move) learned to + honor "-f" (force) flag; unlike many other subcommands, the way to + force these have been with separate "-D/-M" options, which was + inconsistent. + + * "diff-highlight" filter (in contrib/) allows its color output to be + customized via configuration variables. + + * "git imap-send" learned to take "-v" (verbose) and "-q" (quiet) + command line options. + + * "git remote add $name $URL" is now allowed when "url.$URL.insteadOf" + is already defined. + + * "git imap-send" now can be built to use cURL library to talk to + IMAP servers (if the library is recent enough, of course). + This allows you to use authenticate method other than CRAM-MD5, + among other things. + + * "git imap-send" now allows GIT_CURL_VERBOSE environment variable to + control the verbosity when talking via the cURL library. + + * The prompt script (in contrib/) learned to optionally hide prompt + when in an ignored directory by setting GIT_PS1_HIDE_IF_PWD_IGNORED + shell variable. + + +Performance, Internal Implementation, Development Support etc. + + * Earlier we made "rev-list --object-edge" more aggressively list the + objects at the edge commits, in order to reduce number of objects　 + fetched into a shallow repository, but the change affected cases + other than "fetching into a shallow repository" and made it + unusably slow (e.g. fetching into a normal repository should not + have to suffer the overhead from extra processing). Limit it to a + more specific case by introducing --objects-edge-aggressive, a new + option to rev-list. + + * Squelched useless compiler warnings on Mac OS X regarding the + crypto API. + + * The procedure to generate unicode table has been simplified. + + * Some filesystems assign filemodes in a strange way, fooling then + automatic "filemode trustability" check done during a new + repository creation. The initialization codepath has been hardened + against this issue. + + * The codepath in "git remote update --prune" to drop many refs has + been optimized. + + * The API into get_merge_bases*() family of functions was easy to + misuse, which has been corrected to make it harder to do so. + + * Long overdue departure from the assumption that S_IFMT is shared by + everybody made in 2005, which was necessary to port to z/OS. + + * "git push" and "git fetch" did not communicate an overlong refname + correctly. Now it uses 64kB sideband to accommodate longer ones. + + * Recent GPG changes the keyring format and drops support for RFC1991 + formatted signatures, breaking our existing tests. + + * "git-prompt" (in contrib/) used a variable from the global scope, + possibly contaminating end-user's namespace. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.2 +---------------- + +Unless otherwise noted, all the fixes since v2.2 in the maintenance +track are contained in this release (see the maintenance releases' +notes for details). + + * "git http-push" over WebDAV (aka dumb http-push) was broken in + v2.2.2 when parsing a symbolic ref, resulting in a bogus request + that gets rejected by recent versions of cURL library. + (merge f6786c8 jk/http-push-symref-fix later to maint). + + * The logic in "git bisect bad HEAD" etc. to avoid forcing the test + of the common ancestor of bad and good commits was broken. + (merge 07913d5 cc/bisect-rev-parsing later to maint). + + * "git checkout-index --temp=$target $path" did not work correctly + for paths outside the current subdirectory in the project. + (merge 74c4de5 es/checkout-index-temp later to maint). + + * The report from "git checkout" on a branch that builds on another + local branch by setting its branch.*.merge to branch name (not a + full refname) incorrectly said that the upstream is gone. + (merge 05e7368 jc/checkout-local-track-report later to maint). + + * With The git-prompt support (in contrib/), using the exit status of + the last command in the prompt, e.g. PS1='$(__git_ps1) $? ', did + not work well, because the helper function stomped on the exit + status. + (merge 6babe76 tf/prompt-preserve-exit-status later to maint). + + * Recent update to "git commit" broke amending an existing commit + with bogus author/committer lines without a valid e-mail address. + (merge c83a509 jk/commit-date-approxidate later to maint). + + * The lockfile API used to get confused which file to clean up when + the process moved the $cwd after creating a lockfile. + (merge fa137f6 nd/lockfile-absolute later to maint). + + * Traditionally we tried to avoid interpreting date strings given by + the user as future dates, e.g. GIT_COMMITTER_DATE=2014-12-10 when + used early November 2014 was taken as "October 12, 2014" because it + is likely that a date in the future, December 10, is a mistake. + This heuristics has been loosened to allow people to express future + dates (most notably, --until=<date> may want to be far in the + future) and we no longer tiebreak by future-ness of the date when + + (1) ISO-like format is used, and + (2) the string can make sense interpreted as both y-m-d and y-d-m. + + Git may still have to use the heuristics to tiebreak between dd/mm/yy + and mm/dd/yy, though. + (merge d372395 jk/approxidate-avoid-y-d-m-over-future-dates later to maint). + + * Git did not correctly read an overlong refname from a packed refs + file. + (merge ea41783 jk/read-packed-refs-without-path-max later to maint). + + * "git apply" was described in the documentation to take --ignore-date + option, which it does not. + (merge 0cef4e7 rw/apply-does-not-take-ignore-date later to maint). + + * "git add -i" did not notice when the interactive command input + stream went away and kept asking the same question. + (merge a8bec7a jk/add-i-read-error later to maint). + + * "git send-email" did not handle RFC 2047 encoded headers quite + right. + (merge ab47e2a rd/send-email-2047-fix later to maint). + + * New tag object format validation added in 2.2 showed garbage after + a tagname it reported in its error message. + (merge a1e920a js/fsck-tag-validation later to maint). + + * The code that reads the reflog from the newer to the older entries + did not handle an entry that crosses a boundary of block it uses to + read them correctly. + (merge 69216bf jk/for-each-reflog-ent-reverse later to maint). + + * "git diff -B -M" after making a new copy B out of an existing file + A and then editing A extensively ought to report that B was created + by copying A and A was modified, which is what "git diff -C" + reports, but it instead said A was renamed to B and A was edited + heavily in place. This was not just incoherent but also failed to + apply with "git apply". The report has been corrected to match what + "git diff -C" produces for this case. + (merge 6936b58 jc/diff-b-m later to maint). + + * In files we pre-populate for the user to edit with commented hints, + a line of hint that is indented with a tab used to show as '#' (or + any comment char), ' ' (space), and then the hint text that began + with the tab, which some editors flag as an indentation error (tab + following space). We now omit the space after the comment char in + such a case. + (merge d55aeb7 jc/strbuf-add-lines-avoid-sp-ht-sequence later to maint). + + * "git ls-tree" does not support path selection based on negative + pathspecs, but did not error out when negative pathspecs are given. + (merge f1f6224 nd/ls-tree-pathspec later to maint). + + * The function sometimes returned a non-freeable memory and some + other times returned a piece of memory that must be freed, leading + to inevitable leaks. + (merge 59362e5 jc/exec-cmd-system-path-leak-fix later to maint). + + * The code to abbreviate an object name to its short unique prefix + has been optimized when no abbreviation was requested. + (merge 61e704e mh/find-uniq-abbrev later to maint). + + * "git add --ignore-errors ..." did not ignore an error to + give a file that did not exist. + (merge 1d31e5a mg/add-ignore-errors later to maint). + + * "git checkout $treeish $path", when $path in the index and the + working tree already matched what is in $treeish at the $path, + still overwrote the $path unnecessarily. + (merge c5326bd jk/checkout-from-tree later to maint). + + * "git config --get-color" did not parse its command line arguments + carefully. + (merge cb35722 jk/colors-fix later to maint). + + * open() emulated on Windows platforms did not give EISDIR upon + an attempt to open a directory for writing. + (merge ba6fad0 js/windows-open-eisdir-error later to maint). + + * A few code paths used abs() when they should have used labs() on + long integers. + (merge 83915ba rs/maint-config-use-labs later to maint). + (merge 31a8aa1 rs/receive-pack-use-labs later to maint). + + * "gitweb" used to depend on a behaviour recent CGI.pm deprecated. + (merge 13dbf46 jk/gitweb-with-newer-cgi-multi-param later to maint). + + * "git init" (hence "git clone") initialized the per-repository + configuration file .git/config with x-bit by mistake. + (merge 1f32ecf mh/config-flip-xbit-back-after-checking later to maint). + + * Recent update in Git 2.2 started creating objects/info/packs and + info/refs files with permission bits tighter than user's umask. + (merge d91175b jk/prune-packed-server-info later to maint). + + * Git 2.0 was supposed to make the "simple" mode for the default of + "git push", but it didn't. + (merge 00a6fa0 jk/push-simple later to maint). + + * "Everyday" document had a broken link. + (merge 366c8d4 po/everyday-doc later to maint). + + * A few test fixes. + (merge 880ef58 jk/no-perl-tests later to maint). + + * The build procedure did not bother fixing perl and python scripts + when NO_PERL and NO_PYTHON build-time configuration changed. + (merge ca2051d jk/rebuild-perl-scripts-with-no-perl-seting-change later to maint). + + * The usage string of "git log" command was marked incorrectly for + l10n. + (merge e66dc0c km/log-usage-string-i18n later to maint). + + * "git for-each-ref" mishandled --format="%(upstream:track)" when a + branch is marked to have forked from a non-existing branch. + (merge b6160d9 rc/for-each-ref-tracking later to maint). diff --git a/Documentation/RelNotes/2.3.1.txt b/Documentation/RelNotes/2.3.1.txt new file mode 100644 index 0000000000..cf96186288 --- /dev/null +++ b/Documentation/RelNotes/2.3.1.txt @@ -0,0 +1,52 @@ +Git v2.3.1 Release Notes +======================== + +Fixes since v2.3 +---------------- + + * The interactive "show a list and let the user choose from it" + interface "add -i" used showed and prompted to the user even when + the candidate list was empty, against which the only "choice" the + user could have made was to choose nothing. + + * "git apply --whitespace=fix" used to under-allocate the memory + when the fix resulted in a longer text than the original patch. + + * "git log --help" used to show rev-list options that are irrelevant + to the "log" command. + + * The error message from "git commit", when a non-existing author + name was given as value to the "--author=" parameter, has been + reworded to avoid misunderstanding. + + * A broken pack .idx file in the receiving repository prevented the + dumb http transport from fetching a good copy of it from the other + side. + + * The documentation incorrectly said that C(opy) and R(ename) are the + only ones that can be followed by the score number in the output in + the --raw format. + + * Fix a misspelled conditional that is always true. + + * Code to read branch name from various files in .git/ directory + would have misbehaved if the code to write them left an empty file. + + * The "git push" documentation made the "--repo=<there>" option + easily misunderstood. + + * After attempting and failing a password-less authentication + (e.g. kerberos), libcURL refuses to fall back to password based + Basic authentication without a bit of help/encouragement. + + * Setting diff.submodule to 'log' made "git format-patch" produce + broken patches. + + * "git rerere" (invoked internally from many mergy operations) did + not correctly signal errors when told to update the working tree + files and failed to do so for whatever reason. + + * "git blame HEAD -- missing" failed to correctly say "HEAD" when it + tried to say "No such path 'missing' in HEAD". + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.3.2.txt b/Documentation/RelNotes/2.3.2.txt new file mode 100644 index 0000000000..93462e45c2 --- /dev/null +++ b/Documentation/RelNotes/2.3.2.txt @@ -0,0 +1,79 @@ +Git v2.3.2 Release Notes +======================== + +Fixes since v2.3.1 +------------------ + + * "update-index --refresh" used to leak when an entry cannot be + refreshed for whatever reason. + + * "git fast-import" used to crash when it could not close and + conclude the resulting packfile cleanly. + + * "git blame" died, trying to free an uninitialized piece of memory. + + * "git merge-file" did not work correctly in a subdirectory. + + * "git submodule add" failed to squash "path/to/././submodule" to + "path/to/submodule". + + * In v2.2.0, we broke "git prune" that runs in a repository that + borrows from an alternate object store. + + * Certain older vintages of cURL give irregular output from + "curl-config --vernum", which confused our build system. + + * An earlier workaround to squelch unhelpful deprecation warnings + from the compiler on Mac OSX unnecessarily set minimum required + version of the OS, which the user might want to raise (or lower) + for other reasons. + + * Longstanding configuration variable naming rules has been added to + the documentation. + + * The credential helper for Windows (in contrib/) used to mishandle + a user name with an at-sign in it. + + * Older GnuPG implementations may not correctly import the keyring + material we prepare for the tests to use. + + * Clarify in the documentation that "remote.<nick>.pushURL" and + "remote.<nick>.URL" are there to name the same repository accessed + via different transports, not two separate repositories. + + * The pack bitmap support did not build with older versions of GCC. + + * Reading configuration from a blob object, when it ends with a lone + CR, use to confuse the configuration parser. + + * We didn't format an integer that wouldn't fit in "int" but in + "uintmax_t" correctly. + + * "git push --signed" gave an incorrectly worded error message when + the other side did not support the capability. + + * "git fetch" over a remote-helper that cannot respond to "list" + command could not fetch from a symbolic reference e.g. HEAD. + + * The insn sheet "git rebase -i" creates did not fully honor + core.abbrev settings. + + * The tests that wanted to see that file becomes unreadable after + running "chmod a-r file", and the tests that wanted to make sure it + is not run as root, we used "can we write into the / directory?" as + a cheap substitute, but on some platforms that is not a good + heuristics. The tests and their prerequisites have been updated to + check what they really require. + + * The configuration variable 'mailinfo.scissors' was hard to + discover in the documentation. + + * Correct a breakage to git-svn around v2.2 era that triggers + premature closing of FileHandle. + + * Even though we officially haven't dropped Perl 5.8 support, the + Getopt::Long package that came with it does not support "--no-" + prefix to negate a boolean option; manually add support to help + people with older Getopt::Long package. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.3.3.txt b/Documentation/RelNotes/2.3.3.txt new file mode 100644 index 0000000000..5ef12644c2 --- /dev/null +++ b/Documentation/RelNotes/2.3.3.txt @@ -0,0 +1,39 @@ +Git v2.3.3 Release Notes +======================== + +Fixes since v2.3.2 +------------------ + + * A corrupt input to "git diff -M" used cause us to segfault. + + * The borrowed code in kwset API did not follow our usual convention + to use "unsigned char" to store values that range from 0-255. + + * Description given by "grep -h" for its --exclude-standard option + was phrased poorly. + + * Documentaton for "git remote add" mentioned "--tags" and + "--no-tags" and it was not clear that fetch from the remote in + the future will use the default behaviour when neither is given + to override it. + + * "git diff --shortstat --dirstat=changes" showed a dirstat based on + lines that was never asked by the end user in addition to the + dirstat that the user asked for. + + * The interaction between "git submodule update" and the + submodule.*.update configuration was not clearly documented. + + * "git apply" was not very careful about reading from, removing, + updating and creating paths outside the working tree (under + --index/--cached) or the current directory (when used as a + replacement for GNU patch). + + * "git daemon" looked up the hostname even when "%CH" and "%IP" + interpolations are not requested, which was unnecessary. + + * The "interpolated-path" option of "git daemon" inserted any string + client declared on the "host=" capability request without checking. + Sanitize and limit %H and %CH to a saner and a valid DNS name. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.3.4.txt b/Documentation/RelNotes/2.3.4.txt new file mode 100644 index 0000000000..094c7b853b --- /dev/null +++ b/Documentation/RelNotes/2.3.4.txt @@ -0,0 +1,32 @@ +Git v2.3.4 Release Notes +======================== + +Fixes since v2.3.3 +------------------ + + * The 'color.status.unmerged' configuration was not described. + + * "git log --decorate" did not reset colors correctly around the + branch names. + + * "git -C '' subcmd" refused to work in the current directory, unlike + "cd ''" which silently behaves as a no-op. + + * "git imap-send" learned to optionally talk with an IMAP server via + libcURL; because there is no other option when Git is built with + NO_OPENSSL option, use that codepath by default under such + configuration. + + * A workaround for certain build of GPG that triggered false breakage + in a test has been added. + + * "git rebase -i" recently started to include the number of + commits in the insn sheet to be processed, but on a platform + that prepends leading whitespaces to "wc -l" output, the numbers + are shown with extra whitespaces that aren't necessary. + + * We did not parse username followed by literal IPv6 address in SSH + transport URLs, e.g. ssh://user@[2001:db8::1]:22/repo.git + correctly. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.3.5.txt b/Documentation/RelNotes/2.3.5.txt new file mode 100644 index 0000000000..5b309db689 --- /dev/null +++ b/Documentation/RelNotes/2.3.5.txt @@ -0,0 +1,44 @@ +Git v2.3.5 Release Notes +======================== + +Fixes since v2.3.4 +------------------ + + * The prompt script (in contrib/) did not show the untracked sign + when working in a subdirectory without any untracked files. + + * Even though "git grep --quiet" is run merely to ask for the exit + status, we spawned the pager regardless. Stop doing that. + + * Recommend format-patch and send-email for those who want to submit + patches to this project. + + * An failure early in the "git clone" that started creating the + working tree and repository could have resulted in some directories + and files left without getting cleaned up. + + * "git fetch" that fetches a commit using the allow-tip-sha1-in-want + extension could have failed to fetch all the requested refs. + + * The split-index mode introduced at v2.3.0-rc0~41 was broken in the + codepath to protect us against a broken reimplementation of Git + that writes an invalid index with duplicated index entries, etc. + + * "git prune" used to largely ignore broken refs when deciding which + objects are still being used, which could spread an existing small + damage and make it a larger one. + + * "git tag -h" used to show the "--column" and "--sort" options + that are about listing in a wrong section. + + * The transfer.hiderefs support did not quite work for smart-http + transport. + + * The code that reads from the ctags file in the completion script + (in contrib/) did not spell ${param/pattern/string} substitution + correctly, which happened to work with bash but not with zsh. + + * The explanation on "rebase --preserve-merges", "pull --rebase=preserve", + and "push --force-with-lease" in the documentation was unclear. + +Also contains typofixes, documentation updates and trivial code clean-ups. diff --git a/Documentation/RelNotes/2.3.6.txt b/Documentation/RelNotes/2.3.6.txt new file mode 100644 index 0000000000..432f770ef3 --- /dev/null +++ b/Documentation/RelNotes/2.3.6.txt @@ -0,0 +1,13 @@ +Git v2.3.6 Release Notes +======================== + +Fixes since v2.3.5 +------------------ + + * "diff-highlight" (in contrib/) used to show byte-by-byte + differences, which meant that multi-byte characters can be chopped + in the middle. It learned to pay attention to character boundaries + (assuming the UTF-8 payload). + +Also contains typofixes, documentation updates and trivial code +clean-ups. diff --git a/Documentation/RelNotes/2.3.7.txt b/Documentation/RelNotes/2.3.7.txt new file mode 100644 index 0000000000..fc95812cb3 --- /dev/null +++ b/Documentation/RelNotes/2.3.7.txt @@ -0,0 +1,21 @@ +Git v2.3.7 Release Notes +======================== + +Fixes since v2.3.6 +------------------ + + * An earlier update to the parser that disects a URL broke an + address, followed by a colon, followed by an empty string (instead + of the port number), e.g. ssh://example.com:/path/to/repo. + + * The completion script (in contrib/) contaminated global namespace + and clobbered on a shell variable $x. + + * The "git push --signed" protocol extension did not limit what the + "nonce" that is a server-chosen string can contain or how long it + can be, which was unnecessarily lax. Limit both the length and the + alphabet to a reasonably small space that can still have enough + entropy. + +Also contains typofixes, documentation updates and trivial code +clean-ups. diff --git a/Documentation/RelNotes/2.4.0.txt b/Documentation/RelNotes/2.4.0.txt new file mode 100644 index 0000000000..cde64be535 --- /dev/null +++ b/Documentation/RelNotes/2.4.0.txt @@ -0,0 +1,514 @@ +Git 2.4 Release Notes +===================== + +Backward compatibility warning(s) +--------------------------------- + +This release has a few changes in the user-visible output from +Porcelain commands. These are not meant to be parsed by scripts, but +users still may want to be aware of the changes: + + * The output from "git log --decorate" (and, more generally, the "%d" + format specifier used in the "--format=<string>" parameter to the + "git log" family of commands) has changed. It used to list "HEAD" + just like other branches; e.g., + + $ git log --decorate -1 master + commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD, master) + ... + + This release changes the output slightly when HEAD refers to a + branch whose name is also shown in the output. The above is now + shown as: + + $ git log --decorate -1 master + commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD -> master) + ... + + * The phrasing "git branch" uses to describe a detached HEAD has been + updated to agree with the phrasing used by "git status": + + - When HEAD is at the same commit as when it was originally + detached, they now both show "detached at <commit object name>". + + - When HEAD has moved since it was originally detached, they now + both show "detached from <commit object name>". + + Previously, "git branch" always used "from". + + +Updates since v2.3 +------------------ + +Ports + + * Our default I/O size (8 MiB) for large files was too large for some + platforms with smaller SSIZE_MAX, leading to read(2)/write(2) + failures. + + * We did not check the curl library version before using the + CURLOPT_PROXYAUTH feature, which did not exist in older versions of + the library. + + * We now detect number of CPUs on older BSD-derived systems. + + * Portability fixes and workarounds for shell scripts have been added + to help BSD-derived systems. + + +UI, Workflows & Features + + * The command usage info strings given by "git cmd -h" and in + documentation have been tweaked for consistency. + + * The "sync" subcommand of "git p4" now allows users to exclude + subdirectories like its "clone" subcommand does. + + * "git log --invert-grep --grep=WIP" will show only commits that do + not have the string "WIP" in their messages. + + * "git push" has been taught an "--atomic" option that makes a push + that updates more than one ref an "all-or-none" affair. + + * Extending the "push to deploy" feature that was added in 2.3, the + behaviour of "git push" when updating the branch that is checked + out can now be tweaked by a "push-to-checkout" hook. + + * HTTP-based transports now send Accept-Language when making + requests. The languages to accept are inferred from environment + variables on the client side (LANGUAGE, etc). + + * "git send-email" used to accept a mistaken "y" (or "yes") as an + answer to "What encoding do you want to use [UTF-8]?" without + questioning. Now it asks for confirmation when the answer looks too + short to be a valid encoding name. + + * When "git apply --whitespace=fix" fixed whitespace errors in the + common context lines, the command reports that it did so. + + * "git status" now allows the "-v" option to be given twice, in which + case it also shows the differences in the working tree that are not + staged to be committed. + + * "git cherry-pick" used to clean up the log message even when it is + merely replaying an existing commit. It now replays the message + verbatim unless you are editing the message of the resulting + commit. + + * "git archive" can now be told to set the 'text' attribute in the + resulting zip archive. + + * Output from "git log --decorate" now distinguishes between a + detached HEAD vs. a HEAD that points at a branch. + + This is a potentially backward-incompatible change; see above for + more information. + + * When HEAD was detached when at commit xyz and hasn't been moved + since it was detached, "git status" would report "detached at xyz" + whereas "git branch" would report "detached from xyz". Now the + output of "git branch" agrees with that of "git status". + + This is a potentially backward-incompatible change; see above for + more information. + + * "git -C '' subcmd" now works in the current directory (analogously + to "cd ''") rather than dying with an error message. + (merge 6a536e2 kn/git-cd-to-empty later to maint). + + * The versionsort.prereleaseSuffix configuration variable can be used + to specify that, for example, v1.0-pre1 comes before v1.0. + + * A new "push.followTags" configuration turns the "--follow-tags" + option on by default for the "git push" command. + + * "git log --graph --no-walk A B..." is a nonsensical combination of + options: "--no-walk" requests discrete points in the history, while + "--graph" asks to draw connections between these discrete points. + Forbid the use of these options together. + + * "git rev-list --bisect --first-parent" does not work (yet) and can + even cause SEGV; forbid it. "git log --bisect --first-parent" would + not be useful until "git bisect --first-parent" materializes, so + also forbid it for now. + + +Performance, Internal Implementation, Development Support etc. + + * Slightly change the implementation of the N_() macro to help us + detect mistakes. + + * Restructure the implementation of "reflog expire" to fit better + with the recently updated reference API. + + * The transport-helper did not pass transport options such as + verbosity, progress, cloning, etc. to import and export based + helpers, like it did for fetch and push based helpers, robbing them + of the chance to honor the wish of the end-users better. + + * The tests that wanted to see that a file becomes unreadable after + running "chmod a-r file", and the tests that wanted to make sure + that they are not run as root, used "can we write into the / + directory?" as a cheap substitute. But on some platforms that is + not a good heuristic. The tests and their prerequisites have been + updated to check what they really require. + (merge f400e51 jk/sanity later to maint). + + * Various issues around "reflog expire", e.g. using --updateref when + expiring a reflog for a symbolic reference, have been corrected + and/or made saner. + + * The documentation for the strbuf API had been split between the API + documentation and the header file. Consolidate the documentation in + strbuf.h. + + * The error handling functions and conventions are now documented in + the API manual (in api-error-handling.txt). + + * Optimize gitattribute look-up, mostly useful in "git grep" on a + project that does not use many attributes, by avoiding it when we + (should) know that the attributes are not defined in the first + place. + + * Typofix in comments. + (merge ef2956a ak/git-pm-typofix later to maint). + + * Code clean-up. + (merge 0b868f0 sb/hex-object-name-is-at-most-41-bytes-long later to maint). + (merge 5d30851 dp/remove-duplicated-header-inclusion later to maint). + + * Simplify the ref transaction API for verifying that "the ref should + be pointing at this object". + + * Simplify the code in "git daemon" that parses out and holds + hostnames used in request interpolation. + + * Restructure the "git push" codepath to make it easier to add new + configuration bits. + + * The run-command interface made it easy to make a pipe for us to + read from a process, wait for the process to finish, and then + attempt to read its output. But this pattern can lead to deadlock. + So introduce a helper to do this correctly (i.e., first read, and + then wait the process to finish) and also add code to prevent such + abuse in the run-command helper. + + * People often forget to chain the commands in their test together + with &&, letting a failure from an earlier command in the test go + unnoticed. The new GIT_TEST_CHAIN_LINT mechanism allows you to + catch such a mistake more easily. + + +Also contains various documentation updates and code clean-ups. + + +Fixes since v2.3 +---------------- + +Unless otherwise noted, all the fixes since v2.3 in the maintenance +track are contained in this release (see the maintenance releases' +notes for details). + + * "git blame HEAD -- missing" failed to correctly say "HEAD" when it + tried to say "No such path 'missing' in HEAD". + (merge a46442f jk/blame-commit-label later to maint). + + * "git rerere" (invoked internally from many mergy operations) did + not correctly signal errors when it attempted to update the working + tree files but failed for whatever reason. + (merge 89ea903 jn/rerere-fail-on-auto-update-failure later to maint). + + * Setting diff.submodule to 'log' made "git format-patch" produce + broken patches. + (merge 339de50 dk/format-patch-ignore-diff-submodule later to maint). + + * After attempting and failing a password-less authentication (e.g., + Kerberos), libcURL refuses to fall back to password-based Basic + authentication without a bit of help/encouragement. + (merge 4dbe664 bc/http-fallback-to-password-after-krb-fails later to maint). + + * The "git push" documentation for the "--repo=<there>" option was + easily misunderstood. + (merge 57b92a7 mg/push-repo-option-doc later to maint). + + * Code to read a branch name from various files in the .git/ + directory would have overrun array limits if asked to read an empty + file. + (merge 66ec904 jk/status-read-branch-name-fix later to maint). + + * Remove a superfluous conditional that is always true. + (merge 94ee8e2 jk/remote-curl-an-array-in-struct-cannot-be-null later to maint). + + * The "git diff --raw" documentation incorrectly implied that C(opy) + and R(ename) are the only statuses that can be followed by a score + number. + (merge ac1c2d9 jc/diff-format-doc later to maint). + + * A broken pack .idx file in the receiving repository prevented the + dumb http transport from fetching a good copy of it from the other + side. + (merge 8b9c2dd jk/dumb-http-idx-fetch-fix later to maint). + + * The error message from "git commit", when a non-existing author + name was given as value to the "--author=" parameter, has been + reworded to avoid misunderstanding. + (merge 1044b1f mg/commit-author-no-match-malformed-message later to maint). + + * "git log --help" used to show rev-list options that are irrelevant + to the "log" command. + (merge 3cab02d jc/doc-log-rev-list-options later to maint). + + * "git apply --whitespace=fix" used to under-allocate memory when the + fix resulted in a longer text than the original patch. + (merge 407a792 jc/apply-ws-fix-expands later to maint). + + * The interactive "show a list and let the user choose from it" + interface used by "git add -i" unnecessarily prompted the user even + when the candidate list was empty, against which the only "choice" + the user could have made was to choose nothing. + (merge a9c4641 ak/add-i-empty-candidates later to maint). + + * The todo list created by "git rebase -i" did not fully honor + core.abbrev settings. + (merge edb72d5 ks/rebase-i-abbrev later to maint). + + * "git fetch" over a remote-helper that cannot respond to the "list" + command could not fetch from a symbolic reference (e.g., HEAD). + (merge 33cae54 mh/deref-symref-over-helper-transport later to maint). + + * "git push --signed" gave an incorrectly worded error message when + the other side did not support the capability. + + * The "git push --signed" protocol extension did not limit what the + "nonce" (a server-chosen string) could contain nor how long it + could be, which was unnecessarily lax. Limit both the length and + the alphabet to a reasonably small space that can still have enough + entropy. + (merge afcb6ee jc/push-cert later to maint). + + * The completion script (in contrib/) clobbered the shell variable $x + in the global shell namespace. + (merge 852ff1c ma/bash-completion-leaking-x later to maint). + + * We incorrectly formatted a "uintmax_t" integer that doesn't fit in + "int". + (merge d306f3d jk/decimal-width-for-uintmax later to maint). + + * The configuration parser used to be confused when reading + configuration from a blob object that ends with a lone CR. + (merge 1d0655c jk/config-no-ungetc-eof later to maint). + + * The pack bitmap support did not build with older versions of GCC. + (merge bd4e882 jk/pack-bitmap later to maint). + + * The documentation wasn't clear that "remote.<nick>.pushURL" and + "remote.<nick>.URL" are there to name the same repository accessed + via different transports, not two separate repositories. + (merge 697f652 jc/remote-set-url-doc later to maint). + + * Older GnuPG implementations may not correctly import the keyring + material we prepare for the tests to use. + (merge 1f985d6 ch/new-gpg-drops-rfc-1991 later to maint). + + * The credential helper for Windows (in contrib/) used to mishandle + user names that contain an at-sign. + (merge 13d261e av/wincred-with-at-in-username-fix later to maint). + + * "diff-highlight" (in contrib/) used to show byte-by-byte + differences, which could cause multi-byte characters to be chopped + in the middle. It learned to pay attention to character boundaries + (assuming UTF-8). + (merge 8d00662 jk/colors later to maint). + + * Document longstanding configuration variable naming rules in + CodingGuidelines. + (merge 35840a3 jc/conf-var-doc later to maint). + + * An earlier workaround to squelch unhelpful deprecation warnings + from the compiler on OS X unnecessarily set a minimum required + version of the OS, which the user might want to raise (or lower) + for other reasons. + (merge 88c03eb es/squelch-openssl-warnings-on-macosx later to maint). + + * Certain older vintages of cURL give irregular output from + "curl-config --vernum", which confused our build system. + (merge 3af6792 tc/curl-vernum-output-broken-in-7.11 later to maint). + + * In v2.2.0, we broke "git prune" that runs in a repository that + borrows from an alternate object store. + (merge b0a4264 jk/prune-mtime later to maint). + + * "git submodule add" failed to squash "path/to/././submodule" to + "path/to/submodule". + (merge 8196e72 ps/submodule-sanitize-path-upon-add later to maint). + + * "git merge-file" did not work correctly when invoked in a + subdirectory. + (merge 204a8ff ab/merge-file-prefix later to maint). + + * "git blame" could die trying to free an uninitialized piece of + memory. + (merge e600592 es/blame-commit-info-fix later to maint). + + * "git fast-import" used to crash when it could not close and + finalize the resulting packfile cleanly. + (merge 5e915f3 jk/fast-import-die-nicely-fix later to maint). + + * "update-index --refresh" used to leak memory when an entry could + not be refreshed for whatever reason. + (merge bc1c2ca sb/plug-leak-in-make-cache-entry later to maint). + + * The "interpolated-path" option of "git daemon" inserted any string + the client declared on the "host=" capability request without + checking. Sanitize and limit %H and %CH to a saner and a valid DNS + name. + (merge b485373 jk/daemon-interpolate later to maint). + + * "git daemon" unnecessarily looked up the hostname even when "%CH" + and "%IP" interpolations were not requested. + (merge dc8edc8 rs/daemon-interpolate later to maint). + + * We relied on "--no-" prefix handling in Perl's Getopt::Long + package, even though that support didn't exist in Perl 5.8 (which + we still support). Manually add support to help people with older + Getopt::Long packages. + (merge f471494 km/send-email-getopt-long-workarounds later to maint). + + * "git apply" was not very careful about reading from, removing, + updating and creating paths outside the working tree (under + --index/--cached) or the current directory (when used as a + replacement for GNU patch). + (merge e0d201b jc/apply-beyond-symlink later to maint). + + * Correct a breakage in git-svn, introduced around the v2.2 era, that + can cause FileHandles to be closed prematurely. + (merge e426311 ew/svn-maint-fixes later to maint). + + * We did not parse usernames followed by literal IPv6 addresses + correctly in SSH transport URLs; e.g., + ssh://user@[2001:db8::1]:22/repo.git. + (merge 6b6c5f7 tb/connect-ipv6-parse-fix later to maint). + + * The configuration variable 'mailinfo.scissors' was hard to + discover in the documentation. + (merge afb5de7 mm/am-c-doc later to maint). + + * The interaction between "git submodule update" and the + submodule.*.update configuration was not clearly documented. + (merge 5c31acf ms/submodule-update-config-doc later to maint). + + * "git diff --shortstat" used together with "--dirstat=changes" or + "--dirstat=files" incorrectly output dirstat information twice. + (merge ab27389 mk/diff-shortstat-dirstat-fix later to maint). + + * The manpage for "git remote add" mentioned "--tags" and "--no-tags" + but did not explain what happens if neither option is provided. + (merge aaba0ab mg/doc-remote-tags-or-not later to maint). + + * The description of "--exclude-standard option" in the output of + "git grep -h" was phrased poorly. + (merge 77fdb8a nd/grep-exclude-standard-help-fix later to maint). + + * "git rebase -i" recently started to include the number of commits + in the todo list, but that output included extraneous whitespace on + a platform that prepends leading whitespaces to its "wc -l" output. + (merge 2185d3b es/rebase-i-count-todo later to maint). + + * The borrowed code in the kwset API did not follow our usual + convention to use "unsigned char" to store values that range from + 0-255. + (merge 189c860 bw/kwset-use-unsigned later to maint). + + * A corrupt input to "git diff -M" used to cause it to segfault. + (merge 4d6be03 jk/diffcore-rename-duplicate later to maint). + + * Certain builds of GPG triggered false breakages in a test. + (merge 3f88c1b mg/verify-commit later to maint). + + * "git imap-send" learned to optionally talk with an IMAP server via + libcURL. Because there is no other option when Git is built with + the NO_OPENSSL option, use libcURL by default in that case. + (merge dcd01ea km/imap-send-libcurl-options later to maint). + + * "git log --decorate" did not reset colors correctly around the + branch names. + (merge 5ee8758 jc/decorate-leaky-separator-color later to maint). + + * The code that reads from the ctags file in the completion script + (in contrib/) did not spell ${param/pattern/string} substitution + correctly, which happened to work with bash but not with zsh. + (merge db8d750 js/completion-ctags-pattern-substitution-fix later to maint). + + * The transfer.hiderefs support did not quite work for smart-http + transport. + (merge 8ddf3ca jk/smart-http-hide-refs later to maint). + + * In the "git tag -h" output, move the documentation for the + "--column" and "--sort" options to the "Tag listing options" + section. + (merge dd059c6 jk/tag-h-column-is-a-listing-option later to maint). + + * "git prune" used to largely ignore broken refs when deciding which + objects are still being used, which could cause reference + corruption to lead to object loss. + (merge ea56c4e jk/prune-with-corrupt-refs later to maint). + + * The split-index mode introduced in v2.3.0-rc0~41 was broken in the + codepath to protect us against a broken reimplementation of Git + that writes an invalid index with duplicated index entries, etc. + (merge 03f15a7 tg/fix-check-order-with-split-index later to maint). + + * "git fetch", when fetching a commit using the + allow-tip-sha1-in-want extension, could have failed to fetch all of + the requested refs. + (merge 32d0462 jk/fetch-pack later to maint). + + * An failure early in the "git clone" that started creating the + working tree and repository could have resulted in the failure to + clean up some directories and files. + (merge 16eff6c jk/cleanup-failed-clone later to maint). + + * Recommend format-patch and send-email for those who want to submit + patches to this project. + (merge b25c469 jc/submitting-patches-mention-send-email later to maint). + + * Do not spawn the pager when "git grep" is run with "--quiet". + (merge c2048f0 ws/grep-quiet-no-pager later to maint). + + * The prompt script (in contrib/) did not show the untracked sign + when working in a subdirectory without any untracked files. + (merge 9bdc517 ct/prompt-untracked-fix later to maint). + + * An earlier update to the URL parser broke an address that contains + a colon but an empty string for the port number, like + ssh://example.com:/path/to/repo. + (merge 6b6c5f7 tb/connect-ipv6-parse-fix later to maint). + + * Code cleanups and documentation updates. + (merge 2ce63e9 rs/simple-cleanups later to maint). + (merge 33baa69 rj/no-xopen-source-for-cygwin later to maint). + (merge 817d03e jc/diff-test-updates later to maint). + (merge eb32c66 ak/t5516-typofix later to maint). + (merge bcd57cb mr/doc-clean-f-f later to maint). + (merge 0d6accc mg/doc-status-color-slot later to maint). + (merge 53e53c7 sg/completion-remote later to maint). + (merge 8fa7975 ak/git-done-help-cleanup later to maint). + (merge 9a6f128 rs/deflate-init-cleanup later to maint). + (merge 6f75d45 rs/use-isxdigit later to maint). + (merge 376e4b3 jk/test-annoyances later to maint). + (merge 7032054 nd/doc-git-index-version later to maint). + (merge e869c5e tg/test-index-v4 later to maint). + (merge 599d223 jk/simplify-csum-file-sha1fd-check later to maint). + (merge 260d585 sg/completion-gitcomp-nl-for-refs later to maint). + (merge 777c55a jc/report-path-error-to-dir later to maint). + (merge fddfaf8 ph/push-doc-cas later to maint). + (merge d50d31e ss/pull-rebase-preserve later to maint). + (merge c8c3f1d pt/enter-repo-comment-fix later to maint). + (merge d7bfb9e jz/gitweb-conf-doc-fix later to maint). + (merge f907282 jk/cherry-pick-docfix later to maint). + (merge d3c0811 iu/fix-parse-options-h-comment later to maint). + (merge 6c3b2af jg/cguide-we-cannot-count later to maint). + (merge 2b8bd44 jk/pack-corruption-post-mortem later to maint). + (merge 9585cb8 jn/doc-fast-import-no-16-octopus-limit later to maint). + (merge 5dcd1b1 ps/grep-help-all-callback-arg later to maint). + (merge f1f4c84 va/fix-git-p4-tests later to maint). diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 0dbf2c9843..98fc4cc1d0 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,107 @@ 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. See +t/README for guidance. + +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 +Learn to use format-patch and send-email if possible. These commands +are optimized for the workflow of sending patches, avoiding many ways +your existing e-mail client that is optimized for "multipart/*" mime +type e-mails to corrupt and render your patches unusable. + +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 +181,11 @@ 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 line and the diffstat. For +patches requiring multiple iterations of review and discussion, +an explanation of changes between each iteration can be kept in +Git-notes and inserted automatically following the three-dash +line via `git format-patch --notes`. 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 +213,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 @@ -251,17 +263,17 @@ pretty simple: if you can certify the below: person who certified (a), (b) or (c) and I have not modified it. - (d) I understand and agree that this project and the contribution - are public and that a record of the contribution (including all - personal information I submit with it, including my sign-off) is - maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. + (d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. then you just add a line saying - Signed-off-by: Random J Developer <random@developer.example.org> + 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 +302,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 @@ -314,7 +346,7 @@ suggests to the contributors: spend their time to improve your patch. Go back to step (2). (4) The list forms consensus that the last round of your patch is - good. Send it to the list and cc the maintainer. + good. Send it to the maintainer and cc the list. (5) A topic branch is created with the patch and is merged to 'next', and cooked further and eventually graduates to 'master'. @@ -334,7 +366,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 aea8627be0..2c16c536ba 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 d4a51da464..b299b59023 100644 --- a/Documentation/blame-options.txt +++ b/Documentation/blame-options.txt @@ -4,33 +4,20 @@ --root:: Do not treat root commits as boundaries. This can also be - controlled via the `blame.showroot` config option. + controlled via the `blame.showRoot` config option. --show-stats:: 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,7 +97,7 @@ 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 diff --git a/Documentation/cat-texi.perl b/Documentation/cat-texi.perl index 828ec62554..87437f8a95 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 abeb82b2c6..2e5ceaf719 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1,19 +1,21 @@ 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; we say then that the variable is +multivalued. Syntax ~~~~~~ @@ -24,7 +26,7 @@ blank lines are ignored. The file consists of sections and variables. A section begins with the name of the section in square brackets and continues until the next -section begins. Section names are not case sensitive. Only alphanumeric +section begins. Section names are case-insensitive. Only alphanumeric characters, `-` and `.` are allowed in section names. Each variable must belong to some section, which means that there must be a section header before the first setting of a variable. @@ -39,8 +41,8 @@ in the section header, like in the example below: -------- Subsection names are case sensitive and can contain any characters except -newline (doublequote `"` and backslash have to be escaped as `\"` and `\\`, -respectively). Section headers cannot span multiple +newline (doublequote `"` and backslash can be included by escaping them +as `\"` and `\\`, respectively). Section headers cannot span multiple lines. Variables may belong directly to a section or to a given subsection. You can have `[section]` if you have `[section "subsection"]`, but you don't need to. @@ -52,37 +54,40 @@ 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. - -Leading and trailing whitespace in a variable value is discarded. -Internal whitespace within a variable value is retained verbatim. - -The values following the equals sign in variable assign are all either -a string, an integer, or a boolean. Boolean values may be given as yes/no, -1/0, true/false or on/off. Case is not significant in boolean values, when -converting value to the canonical form using '--bool' type specifier; -'git config' will ensure that the output is "true" or "false". - -String values may be entirely or partially enclosed in double quotes. -You need to enclose variable values in double quotes if you want to -preserve leading or trailing whitespace, or if the variable value contains -comment characters (i.e. it contains '#' or ';'). -Double quote `"` and backslash `\` characters in variable values must -be escaped: use `\"` for `"` and `\\` for `\`. +'name = value' (or just 'name', which is a short-hand to say that +the variable is the boolean "true"). +The variable names are case-insensitive, allow only alphanumeric characters +and `-`, and must start with an alphabetic character. + +A line that defines a value can be continued to the next line by +ending it with a `\`; the backquote and the end-of-line are +stripped. Leading whitespaces after 'name =', the remainder of the +line after the first comment character '#' or ';', and trailing +whitespaces of the line are discarded unless they are enclosed in +double quotes. Internal whitespaces within the value are retained +verbatim. + +Inside double quotes, double quote `"` and backslash `\` characters +must be escaped: use `\"` for `"` and `\\` for `\`. The following escape sequences (beside `\"` and `\\`) are recognized: `\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB) -and `\b` for backspace (BS). No other char escape sequence, nor octal -char sequences are valid. +and `\b` for backspace (BS). Other char escape sequences (including octal +escape sequences) are invalid. -Variable values ending in a `\` are continued on the next line in the -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 ~~~~~~~ @@ -106,13 +111,77 @@ 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 + + +Values +~~~~~~ + +Values of many variables are treated as a simple string, but there +are variables that take values of specific types and there are rules +as to how to spell them. + +boolean:: + + When a variable is said to take a boolean value, many + synonyms are accepted for 'true' and 'false'; these are all + case-insensitive. + + true;; Boolean true can be spelled as `yes`, `on`, `true`, + or `1`. Also, a variable defined without `= <value>` + is taken as true. + + false;; Boolean false can be spelled as `no`, `off`, + `false`, or `0`. ++ +When converting value to the canonical form using '--bool' type +specifier; 'git config' will ensure that the output is "true" or +"false" (spelled in lowercase). + +integer:: + The value for many variables that specify various sizes can + be suffixed with `k`, `M`,... to mean "scale the number by + 1024", "by 1024x1024", etc. + +color:: + The value for a variables that takes a color is a list of + colors (at most two) and attributes (at most one), separated + by spaces. The colors accepted are `normal`, `black`, + `red`, `green`, `yellow`, `blue`, `magenta`, `cyan` and + `white`; the attributes are `bold`, `dim`, `ul`, `blink` and + `reverse`. The first color given is the foreground; the + second is the background. The position of the attribute, if + any, doesn't matter. Attributes may be turned off specifically + by prefixing them with `no` (e.g., `noreverse`, `noul`, etc). ++ +Colors (foreground and background) may also be given as numbers between +0 and 255; these use ANSI 256-color mode (but note that not all +terminals may support this). If your terminal supports it, you may also +specify 24-bit RGB values as hex, like `#ff0ab3`. ++ +The attributes are meant to be reset at the beginning of each item +in the colored output, so setting color.decorate.branch to `black` +will paint that branch name in a plain `black`, even if the previous +thing on the same output line (e.g. opening parenthesis before the +list of branch names in `log --decorate` output) is set to be +painted with `bold` or some other attribute. + + Variables ~~~~~~~~~ Note that this list is non-comprehensive and not necessarily complete. For command-specific variables, you will find a more detailed description -in the appropriate manual page. You will find a description of non-core -porcelain configuration variables in the respective porcelain documentation. +in the appropriate manual page. + +Other git-related tools may and do use their own variables. When +inventing new variables for use in your own tool, make sure their +names do not conflict with those that are used by Git itself and +other popular tools, and describe them in your documentation. + advice.*:: These variables control various optional help messages designed to @@ -120,18 +189,47 @@ advice.*:: 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. + pushUpdateRejected:: + Set this variable to 'false' if you want to disable + 'pushNonFFCurrent', + '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. + 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. + 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. resolveConflict:: - Advices shown by various commands when conflicts + Advice shown by various commands when conflicts prevent the operation from being performed. implicitIdentity:: Advice on how to set your identity configuration when @@ -141,40 +239,68 @@ advice.*:: 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. + 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 tree are ignored; useful on broken filesystems like FAT. - See linkgit:git-update-index[1]. + Tells Git if the executable bit of files in the working tree + is to be honored. + -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:: +Some filesystems lose the executable bit when a file that is +marked as executable is checked out, or checks out an +non-executable file with executable bit on. +linkgit:git-clone[1] or linkgit:git-init[1] probe the filesystem +to see if it handles the executable bit correctly +and this variable is automatically set as necessary. ++ +A repository, however, may be on a filesystem that handles +the filemode correctly, and this variable is set to 'true' +when created, but later may be made accessible from another +environment that loses the filemode (e.g. exporting ext4 via +CIFS mount, visiting a Cygwin created repository with +Git for Windows or Eclipse). +In such a case it may be necessary to set this variable to 'false'. +See linkgit:git-update-index[1]. ++ +The default is true (when core.filemode is not specified in the config file). + +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". + 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 +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.protectHFS:: + If set to true, do not allow checkout of paths that would + be considered equivalent to `.git` on an HFS+ filesystem. + Defaults to `true` on Mac OS, and `false` elsewhere. + +core.protectNTFS:: + If set to true, do not allow checkout of paths that would + cause problems with the NTFS filesystem, e.g. conflict with + 8.3 "short" names. + Defaults to `true` on Windows, and `false` elsewhere. + core.trustctime:: If false, the ctime differences between the index and the working tree are ignored; useful when the inode change time @@ -182,7 +308,13 @@ core.trustctime:: crawlers and some backup systems). See linkgit:git-update-index[1]. True by default. -core.quotepath:: +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 "unusual" characters in the pathname by enclosing the @@ -203,20 +335,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 @@ -226,7 +358,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 @@ -271,7 +403,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; @@ -287,14 +419,19 @@ This is useful for excluding servers inside a firewall from proxy use, while defaulting to a common proxy for external domains. 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 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]. - False by default. + If true, Git will avoid using lstat() calls to detect if files have + changed by setting the "assume-unchanged" bit for those tracked files + which it has updated identically in both the index and working tree. ++ +When files are modified outside of Git, the user will need to stage +the modified files explicitly (e.g. see 'Examples' section in +linkgit:git-update-index[1]). +Git will not normally detect changes to those files. ++ +This is useful on systems where lstat() calls are very slow, such as +CIFS/Microsoft Windows. ++ +False by default. core.preferSymlinkRefs:: Instead of the default "symref" format for HEAD @@ -317,7 +454,7 @@ false), while all other repositories are assumed to be bare (bare core.worktree:: Set the path to the root of the working tree. This can be overridden by the GIT_WORK_TREE environment - variable and the '--work-tree' command line option. + variable and the '--work-tree' command-line option. The value can be an absolute path or relative to the path to the .git directory, which is either specified by --git-dir or GIT_DIR, or automatically discovered. @@ -330,7 +467,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 @@ -339,7 +476,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 @@ -362,7 +499,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 @@ -373,17 +510,17 @@ 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. -1 is the zlib default. 0 means no compression, and 1..9 are various speed/size tradeoffs, 9 being slowest. If set, this provides a default to other compression variables, - such as 'core.loosecompression' and 'pack.compression'. + such as 'core.looseCompression' and 'pack.compression'. -core.loosecompression:: +core.looseCompression:: An integer -1..9, indicating the compression level for objects that are not in a pack file. -1 is the zlib default. 0 means no compression, and 1..9 are various speed/size tradeoffs, 9 being @@ -425,7 +562,7 @@ core.deltaBaseCacheLimit:: to avoid unpacking and decompressing frequently used base objects multiple times. + -Default is 16 MiB on all platforms. This should be reasonable +Default is 96 MiB on all platforms. This should be reasonable for all users/operating systems, except on the largest projects. You probably do not need to adjust this value. + @@ -435,7 +572,8 @@ core.bigFileThreshold:: Files larger than this size are stored deflated, without attempting delta compression. Storing large files without delta compression avoids excessive memory usage, at the - slight expense of increased disk usage. + slight expense of increased disk usage. Additionally files + larger than this size are always treated as binary. + Default is 512 MiB on all platforms. This should be reasonable for most projects as source code and other text files can still @@ -443,27 +581,31 @@ be delta compressed, but larger binary media files won't be. + Common unit suffixes of 'k', 'm', or 'g' are supported. -core.excludesfile:: +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]. - -core.askpass:: + '.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 ask for a password can be told to use an external program given via the value of this variable. Can be overridden by the 'GIT_ASKPASS' environment variable. If not set, fall back to the value of the 'SSH_ASKPASS' environment variable or, failing that, a simple password prompt. The external program shall be given a suitable prompt as - command line argument and write the password on its STDOUT. + command-line argument and write the password on its STDOUT. -core.attributesfile:: +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 @@ -471,29 +613,45 @@ 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 '#'). ++ +If set to "auto", `git-commit` would select a character that is not +the beginning character of any line in existing commit messages. + sequence.editor:: - Text editor used by `git rebase -i` for editing the rebase insn file. + 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 `FRX` +(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=FRX less -S`. The environment does not set the +`S` option but the command line does, instructing less to truncate +long lines. Similarly, setting `core.pager` to `less -+F` will +deactivate the `F` option specified by the environment from the +command-line, deactivating the "quit if one screen" behavior of +`less`. One can specifically activate some flags for particular +commands: for example, setting `pager.blame` to `less -S` enables +line truncation only for `git blame`. ++ +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 @@ -507,8 +665,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 @@ -520,10 +679,10 @@ 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:: +core.fsyncObjectFiles:: This boolean will enable 'fsync()' when writing object files. + This is a total waste of time and effort on a filesystem that orders @@ -531,14 +690,14 @@ data writes properly, but can be useful for filesystems that do not use journalling (traditional UNIX filesystems) or that only journal metadata and not file contents (OS X's HFS+, or Linux ext3 with "data=writeback"). -core.preloadindex:: +core.preloadIndex:: Enable parallel index preload for operations like 'git diff' + 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. When enabled, Git will do the index comparison to the filesystem data in parallel, allowing -overlapping IO's. +overlapping IO's. Defaults to true. core.createObject:: You can set this to 'link', in which case a hardlink followed by @@ -568,23 +727,22 @@ core.abbrev:: for abbreviated object names to stay unique for sufficiently long time. -add.ignore-errors:: add.ignoreErrors:: +add.ignore-errors (deprecated):: 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 - `add.ignore-errors`, which does not follow the usual naming - convention for configuration variables. Newer versions of git - honor `add.ignoreErrors` as well. + option of linkgit:git-add[1]. `add.ignore-errors` is deprecated, + as it does not follow the usual naming convention for configuration + variables. alias.*:: Command aliases for the linkgit:git[1] command wrapper - e.g. after defining "alias.last = cat-file commit HEAD", the invocation "git last" is equivalent to "git cat-file commit HEAD". To avoid confusion and troubles with script usage, aliases that - 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. + A quote pair or a backslash can be used to quote them. + If the alias expansion is prefixed with an exclamation point, it will be treated as a shell command. For example, defining @@ -603,7 +761,7 @@ am.keepcr:: by giving '--no-keep-cr' from the command line. See linkgit:git-am[1], linkgit:git-mailsplit[1]. -apply.ignorewhitespace:: +apply.ignoreWhitespace:: When set to 'change', tells 'git apply' to ignore changes in whitespace, in the same way as the '--ignore-space-change' option. @@ -615,7 +773,7 @@ apply.whitespace:: Tells 'git apply' how to handle whitespaces, in the same way as the '--whitespace' option. See linkgit:git-apply[1]. -branch.autosetupmerge:: +branch.autoSetupMerge:: Tells 'git branch' and 'git checkout' to set up new branches so that linkgit:git-pull[1] will appropriately merge from the starting point branch. Note that even if this option is not set, @@ -627,9 +785,9 @@ branch.autosetupmerge:: local branch or remote-tracking branch. This option defaults to true. -branch.autosetuprebase:: +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 @@ -638,14 +796,29 @@ branch.autosetuprebase:: remote-tracking branches. When `always`, rebase will be set to true for all tracking branches. - See "branch.autosetupmerge" for details on how to set up a + See "branch.autoSetupMerge" for details on how to set up a branch to track another branch. 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 @@ -662,10 +835,10 @@ 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:: +branch.<name>.mergeOptions:: Sets default options for merging into branch <name>. The syntax and supported options are the same as those of linkgit:git-merge[1], but option values containing whitespace characters are currently not @@ -677,10 +850,20 @@ branch.<name>.rebase:: "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 specified command is evaluated in shell with the URLs passed @@ -692,8 +875,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 @@ -704,16 +887,9 @@ 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 -two) and attributes (at most one), separated by spaces. The colors -accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`, -`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`, -`blink` and `reverse`. The first color given is the foreground; the -second is the background. The position of the attribute, if any, -doesn't matter. color.diff:: Whether to use ANSI escape sequences to add color to patches. @@ -723,7 +899,7 @@ color.diff:: commands will only use color when output is to the terminal. Defaults to false. + -This does not affect linkgit:git-format-patch[1] nor the +This does not affect linkgit:git-format-patch[1] or the 'git-diff-{asterisk}' plumbing commands. Can be overridden on the command line with the `--color[=<when>]` option. @@ -733,8 +909,7 @@ color.diff.<slot>:: of `plain` (context text), `meta` (metainformation), `frag` (hunk header), 'func' (function in hunk header), `old` (removed lines), `new` (added lines), `commit` (commit headers), or `whitespace` - (highlighting whitespace errors). The values of these variables may be - specified as in color.branch.<slot>. + (highlighting whitespace errors). color.decorate.<slot>:: Use customized color for 'git log --decorate' output. `<slot>` is one @@ -760,34 +935,36 @@ color.grep.<slot>:: `linenumber`;; line number prefix (when using `-n`) `match`;; - matching text + matching text (same as setting `matchContext` and `matchSelected`) +`matchContext`;; + matching text in context lines +`matchSelected`;; + matching text in selected lines `selected`;; non-matching text in selected lines `separator`;; separators between fields on a line (`:`, `-`, and `=`) and between hunks (`--`) -- -+ -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. color.pager:: A boolean to enable/disable colored output when the pager is in use (default is true). -color.showbranch:: +color.showBranch:: A boolean to enable/disable color in the output of linkgit:git-show-branch[1]. May be set to `always`, `false` (or `never`) or `auto` (or `true`), in which case colors are used @@ -804,22 +981,96 @@ 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), - `branch` (the current branch), or + `untracked` (files which are not tracked by Git), + `branch` (the current branch), `nobranch` (the color the 'no branch' warning is shown in, defaulting - to red). The values of these variables may be specified as in - color.branch.<slot>. + to red), or + `unmerged` (files which have unmerged changes). color.ui:: This variable determines the default value for variables such 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 @@ -828,7 +1079,7 @@ 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:: @@ -871,12 +1122,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 @@ -894,7 +1139,7 @@ fetch.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 @@ -904,6 +1149,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 @@ -928,16 +1177,20 @@ format.cc:: by mail. See the --to and --cc options in linkgit:git-format-patch[1]. -format.subjectprefix:: +format.subjectPrefix:: The default for format-patch is to output files with the '[PATCH]' subject prefix. Use this variable to change that prefix. 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. +format.signatureFile:: + Works just like format.signature except the contents of the + file specified by this variable will be used as the signature. + format.suffix:: The default for format-patch is to output files with the suffix `.patch`. Use this variable to change that suffix (make sure to @@ -953,17 +1206,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. +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. + +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 @@ -975,6 +1233,11 @@ filter.<driver>.smudge:: object to a worktree file upon checkout. See linkgit:gitattributes[5] for details. +gc.aggressiveDepth:: + The depth parameter used in the delta compression + algorithm used by 'git gc --aggressive'. This defaults + to 250. + gc.aggressiveWindow:: The window size parameter used in the delta compression algorithm used by 'git gc --aggressive'. This defaults @@ -987,13 +1250,17 @@ gc.auto:: light-weight garbage collection from time to time. The default value is 6700. Setting this to 0 disables it. -gc.autopacklimit:: +gc.autoPackLimit:: When there are more than this many packs that are not marked with `*.keep` file in the repository, `git gc --auto` consolidates them into one larger pack. The default value is 50. Setting this to 0 disables it. -gc.packrefs:: +gc.autoDetach:: + Make `git gc --auto` return immediately and run in background + if the system supports it. Default is true. + +gc.packRefs:: Running `git pack-refs` in a repository renders it unclonable by Git versions prior to 1.5.1.2 over dumb transports such as HTTP. This variable determines whether @@ -1001,38 +1268,38 @@ gc.packrefs:: to enable it within all non-bare repos or it can be set to a boolean value. The default is `true`. -gc.pruneexpire:: +gc.pruneExpire:: When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'. Override the grace period with this config variable. The value "now" may be used to disable this grace period and always prune unreachable objects immediately. -gc.reflogexpire:: -gc.<pattern>.reflogexpire:: +gc.reflogExpire:: +gc.<pattern>.reflogExpire:: 'git reflog expire' removes reflog entries older than this time; defaults to 90 days. With "<pattern>" (e.g. "refs/stash") in the middle the setting applies only to the refs that match the <pattern>. -gc.reflogexpireunreachable:: -gc.<ref>.reflogexpireunreachable:: +gc.reflogExpireUnreachable:: +gc.<ref>.reflogExpireUnreachable:: 'git reflog expire' removes reflog entries older than this time and are not reachable from the current tip; defaults to 30 days. With "<pattern>" (e.g. "refs/stash") in the middle, the setting applies only to the refs that match the <pattern>. -gc.rerereresolved:: +gc.rerereResolved:: Records of conflicted merge you resolved earlier are kept for this many days when 'git rerere gc' is run. The default is 60 days. See linkgit:git-rerere[1]. -gc.rerereunresolved:: +gc.rerereUnresolved:: Records of conflicted merge you have not resolved are kept for this many days when 'git rerere gc' is run. The default is 15 days. See linkgit:git-rerere[1]. -gitcvs.commitmsgannotation:: +gitcvs.commitMsgAnnotation:: Append this string to each commit message. Set to empty string to disable this feature. Defaults to "via git-CVS emulator". @@ -1040,22 +1307,22 @@ gitcvs.enabled:: Whether the CVS server interface is enabled for this repository. See linkgit:git-cvsserver[1]. -gitcvs.logfile:: +gitcvs.logFile:: Path to a log file where the CVS server interface well... logs various stuff. See linkgit:git-cvsserver[1]. 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 the client might otherwise do. If the attributes do not allow - the file type to be determined, then 'gitcvs.allbinary' is + the file type to be determined, then 'gitcvs.allBinary' is used. See linkgit:gitattributes[5]. -gitcvs.allbinary:: +gitcvs.allBinary:: This is used if 'gitcvs.usecrlfattr' does not resolve the correct '-kb' mode to use. If true, all unresolved files are sent to the client in @@ -1065,26 +1332,26 @@ gitcvs.allbinary:: then the contents of the file are examined to decide if it is binary, similar to 'core.autocrlf'. -gitcvs.dbname:: +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 (`;`). Default: '%Ggitcvs.%m.sqlite' -gitcvs.dbdriver:: +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'. See linkgit:git-cvsserver[1]. -gitcvs.dbuser, gitcvs.dbpass:: - Database user and password. Only useful if setting 'gitcvs.dbdriver', +gitcvs.dbUser, gitcvs.dbPass:: + Database user and password. Only useful if setting 'gitcvs.dbDriver', since SQLite has no concept of database users and/or passwords. - 'gitcvs.dbuser' supports variable substitution (see + 'gitcvs.dbUser' supports variable substitution (see linkgit:git-cvsserver[1] for details). gitcvs.dbTableNamePrefix:: @@ -1095,7 +1362,7 @@ gitcvs.dbTableNamePrefix:: characters will be replaced with underscores. All gitcvs variables except for 'gitcvs.usecrlfattr' and -'gitcvs.allbinary' can also be specified as +'gitcvs.allBinary' can also be specified as 'gitcvs.<access_method>.<varname>' (where 'access_method' is one of "ext" and "pserver") to make them apply only for the given access method. @@ -1113,35 +1380,47 @@ gitweb.highlight:: gitweb.patches:: gitweb.pickaxe:: gitweb.remote_heads:: -gitweb.showsizes:: +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 + 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 + 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:: +gui.commitMsgWidth:: Defines how wide the commit message window is in the linkgit:git-gui[1]. "75" is the default. -gui.diffcontext:: +gui.diffContext:: Specifies how many context lines should be used in calls to diff made by the linkgit:git-gui[1]. The default is "5". +gui.displayUntracked:: + Determines if linkgit::git-gui[1] shows untracked files + in the file list. The default is "true". + gui.encoding:: Specifies the default encoding to use for displaying of file contents in linkgit:git-gui[1] and linkgit:gitk[1]. @@ -1150,16 +1429,16 @@ gui.encoding:: If this option is not set, the tools default to the locale encoding. -gui.matchtrackingbranch:: +gui.matchTrackingBranch:: Determines if new branches created with linkgit:git-gui[1] should default to tracking remote branches with matching names or not. Default: "false". -gui.newbranchtemplate:: +gui.newBranchTemplate:: Is used as suggested name when creating new branches using the linkgit:git-gui[1]. -gui.pruneduringfetch:: +gui.pruneDuringFetch:: "true" if linkgit:git-gui[1] should prune remote-tracking branches when performing a fetch. The default value is "false". @@ -1167,17 +1446,17 @@ gui.trustmtime:: Determines if linkgit:git-gui[1] should trust the file modification timestamp or not. By default the timestamps are not trusted. -gui.spellingdictionary:: +gui.spellingDictionary:: Specifies the dictionary used for spell checking commit messages in the linkgit:git-gui[1]. When set to "none" spell checking is turned off. -gui.fastcopyblame:: +gui.fastCopyBlame:: If true, 'git gui blame' uses `-C` instead of `-C -C` for original location detection. It makes blame significantly faster on huge repositories at the expense of less thorough copy detection. -gui.copyblamethreshold:: +gui.copyBlameThreshold:: Specifies the threshold to use in 'git gui blame' original location detection, measured in alphanumeric characters. See the linkgit:git-blame[1] manual for more information on copy detection. @@ -1197,22 +1476,22 @@ guitool.<name>.cmd:: 'FILENAME', and the name of the current branch as 'CUR_BRANCH' (if the head is detached, 'CUR_BRANCH' is empty). -guitool.<name>.needsfile:: +guitool.<name>.needsFile:: Run the tool only if a diff is selected in the GUI. It guarantees that 'FILENAME' is not empty. -guitool.<name>.noconsole:: +guitool.<name>.noConsole:: Run the command silently, without creating a window to display its output. -guitool.<name>.norescan:: +guitool.<name>.noRescan:: Don't rescan the working directory for changes after the tool finishes execution. guitool.<name>.confirm:: Show a confirmation dialog before actually running the tool. -guitool.<name>.argprompt:: +guitool.<name>.argPrompt:: Request a string argument from the user, and pass it to the tool through the 'ARGS' environment variable. Since requesting an argument implies confirmation, the 'confirm' option has no effect @@ -1220,13 +1499,13 @@ guitool.<name>.argprompt:: the dialog uses a built-in generic prompt; otherwise the exact value of the variable is used. -guitool.<name>.revprompt:: +guitool.<name>.revPrompt:: Request a single valid revision from the user, and set the 'REVISION' environment variable. In other aspects this option - is similar to 'argprompt', and can be used together with it. + is similar to 'argPrompt', and can be used together with it. -guitool.<name>.revunmerged:: - Show only unmerged branches in the 'revprompt' subdialog. +guitool.<name>.revUnmerged:: + Show only unmerged branches in the 'revPrompt' subdialog. This is useful for tools similar to merge or rebase, but not for things like checkout or reset. @@ -1236,7 +1515,7 @@ guitool.<name>.title:: guitool.<name>.prompt:: Specifies the general prompt string to display at the top of - the dialog, before subsections for 'argprompt' and 'revprompt'. + the dialog, before subsections for 'argPrompt' and 'revPrompt'. The default value includes the actual command. help.browser:: @@ -1248,7 +1527,7 @@ help.format:: Values 'man', 'info', 'web' and 'html' are supported. 'man' is the default. 'web' and 'html' are the same. -help.autocorrect:: +help.autoCorrect:: Automatically correct and execute mistyped commands after waiting for the given number of deciseconds (0.1 sec). If more than one command can be deduced from the entered text, nothing @@ -1257,18 +1536,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:: +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 + 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. No cookies will be stored in the file. + 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 @@ -1286,7 +1576,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. @@ -1301,6 +1591,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. @@ -1331,17 +1629,62 @@ http.noEPSV:: support EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV' environment variable. Default is false (curl will use EPSV). -http.useragent:: +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 @@ -1355,7 +1698,11 @@ imap:: The configuration variables in the 'imap' section are described in linkgit:git-imap-send[1]. -init.templatedir:: +index.version:: + Specify the version with which new index files should be + initialized. This does not affect existing repositories. + +init.templateDir:: Specify the directory from which templates will be copied. (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) @@ -1371,7 +1718,7 @@ instaweb.local:: If true the web server started by linkgit:git-instaweb[1] will be bound to the local IP (127.0.0.1). -instaweb.modulepath:: +instaweb.modulePath:: The default module path for linkgit:git-instaweb[1] to use instead of /usr/lib/apache2/modules. Only used if httpd is Apache. @@ -1380,24 +1727,24 @@ instaweb.port:: The port number to bind the gitweb httpd to. See linkgit:git-instaweb[1]. -interactive.singlekey:: +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 - is not available. + is not available; requires the Perl module Term::ReadKey. 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. @@ -1408,12 +1755,23 @@ log.decorate:: specified, the full ref name (including prefix) will be printed. This is the same as the log commands '--decorate' option. -log.showroot:: +log.showRoot:: If true, the initial commit will be shown as a big creation event. This is equivalent to a diff against an empty tree. Tools like 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`. + +mailinfo.scissors:: + If true, makes linkgit:git-mailinfo[1] (and therefore + linkgit:git-am[1]) act by default as if the --scissors option + was provided on the command-line. When active, this features + removes everything from the message body before a scissors + line (i.e. consisting mainly of ">8", "8<" and "-"). + mailmap.file:: The location of an augmenting mailmap file. The default mailmap, located in the root of the repository, is loaded @@ -1422,6 +1780,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]. @@ -1460,6 +1826,15 @@ mergetool.<tool>.trustExitCode:: if the file has been updated, otherwise the user is prompted to indicate the success of the merge. +mergetool.meld.hasOutput:: + Older versions of `meld` do not support the `--output` option. + Git will attempt to detect whether `meld` supports `--output` + by inspecting the output of `meld --help`. Configuring + `mergetool.meld.hasOutput` will make Git skip these checks and + use the configured value instead. Setting `mergetool.meld.hasOutput` + to `true` tells Git to unconditionally use the `--output` option, + and `false` avoids using `--output`. + mergetool.keepBackup:: After performing a merge, the original file with conflict markers can be saved as a file with a `.orig` extension. If this variable @@ -1467,12 +1842,18 @@ 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 exited. Defaults to `false`. +mergetool.writeToTemp:: + Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of + conflicting files in the worktree by default. Git will attempt + to use a temporary directory for these files when set `true`. + Defaults to `false`. + mergetool.prompt:: Prompt before each invocation of the merge resolution program. @@ -1495,7 +1876,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. @@ -1533,10 +1914,11 @@ pack.depth:: maximum depth is given on the command line. Defaults to 50. pack.windowMemory:: - The window memory size limit used by linkgit:git-pack-objects[1] - when no limit is given on the command line. The value can be - suffixed with "k", "m", or "g". Defaults to 0, meaning no - limit. + The maximum size of memory that is consumed by each thread + in linkgit:git-pack-objects[1] for pack window memory when + no limit is given on the command line. The value can be + suffixed with "k", "m", or "g". When left unconfigured (or + set explicitly to 0), there will be no limit. pack.compression:: An integer -1..9, indicating the compression level for objects @@ -1575,7 +1957,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:: @@ -1587,29 +1969,49 @@ 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 supported. +pack.useBitmaps:: + When true, git will use pack bitmaps (if available) when packing + to stdout (e.g., during the server side of a fetch). Defaults to + true. You should not generally need to turn this off unless + you are debugging pack bitmaps. + +pack.writeBitmaps (deprecated):: + This is a deprecated synonym for `repack.writeBitmaps`. + +pack.writeBitmapHashCache:: + When true, git will include a "hash cache" section in the bitmap + index (if one is written). This cache can be used to feed git's + delta heuristics, potentially leading to better deltas between + bitmapped and non-bitmapped objects (e.g., when serving a fetch + between an older, bitmapped pack and objects that have been + pushed since the last gc). The downside is that it consumes 4 + bytes per object of disk space, and that JGit's bitmap + implementation does not understand it, causing it to complain if + Git and JGit are used on the same repository. Defaults to false. + 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`. @@ -1617,18 +2019,32 @@ 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). @@ -1641,31 +2057,110 @@ 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: -+ -* `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. + 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 (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 has 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 used to be the default, but not since Git 2.0 (`simple` is the +new default). + +-- + +push.followTags:: + If set to true enable '--follow-tags' option by default. You + may override this configuration at time of push by specifying + '--no-follow-tags'. + rebase.stat:: Whether to show a diffstat of what changed upstream since the last rebase. False by default. -rebase.autosquash:: +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.advertiseAtomic:: + By default, git-receive-pack will advertise the atomic push + capability to its clients. If you don't want to this capability + to be advertised, set this variable 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 it by setting this variable to false. +receive.certNonceSeed:: + By setting this variable to a string, `git receive-pack` + will accept a `git push --signed` and verifies it by using + a "nonce" protected by HMAC using this string as a secret + key. + +receive.certNonceSlop:: + When a `git push --signed` sent a push certificate with a + "nonce" that was issued by a receive-pack serving the same + repository within this many seconds, export the "nonce" + found in the certificate to `GIT_PUSH_CERT_NONCE` to the + hooks (instead of what the receive-pack asked the sending + side to include). This may allow writing checks in + `pre-receive` and `post-receive` a bit easier. Instead of + checking `GIT_PUSH_CERT_NONCE_SLOP` environment variable + that records by how many seconds the nonce is stale to + decide if they want to accept the certificate, they only + can check `GIT_PUSH_CERT_NONCE_STATUS` is `OK`. + 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 @@ -1699,6 +2194,17 @@ receive.denyCurrentBranch:: print a warning of such a push to stderr, but allow the push to proceed. If set to false or "ignore", allow such pushes with no message. Defaults to "refuse". ++ +Another option is "updateInstead" which will update the working +tree if pushing into the current branch. This option is +intended for synchronizing working directories when one side is not easily +accessible via interactive ssh (e.g. a live web site, hence the requirement +that the working directory be clean). This mode also comes in handy when +developing inside a VM to test and fix code on different Operating Systems. ++ +By default, "updateInstead" will refuse the push if the working tree or +the index have any difference from the HEAD, but the `push-to-checkout` +hook can be used to customize this. See linkgit:githooks[5]. receive.denyNonFastForwards:: If set to true, git-receive-pack will deny a ref update which is @@ -1706,10 +2212,28 @@ receive.denyNonFastForwards:: even if that push is forced. This configuration variable is set when initializing a shared repository. -receive.updateserverinfo:: +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]. @@ -1732,7 +2256,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 @@ -1752,7 +2276,7 @@ remote.<name>.uploadpack:: The default program to execute on the remote side when fetching. See option \--upload-pack of linkgit:git-fetch-pack[1]. -remote.<name>.tagopt:: +remote.<name>.tagOpt:: Setting this value to \--no-tags disables automatic tag following when fetching from remote <name>. Setting it to \--tags will fetch every tag from remote <name>, even if they are not reachable from remote @@ -1761,22 +2285,43 @@ 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]. -repack.usedeltabaseoffset:: +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:: +repack.packKeptObjects:: + If set to true, makes `git repack` act as if + `--pack-kept-objects` was passed. See linkgit:git-repack[1] for + details. Defaults to `false` normally, but `true` if a bitmap + index is being written (either via `--write-bitmap-index` or + `repack.writeBitmaps`). + +repack.writeBitmaps:: + When true, git will write a bitmap index when packing all + objects to disk (e.g., when `git repack -a` is run). This + index can speed up the "counting objects" phase of subsequent + packs created for clones and fetches, at the cost of some disk + space and extra time spent on the initial repack. Defaults to + false. + +rerere.autoUpdate:: When set to true, `git-rerere` updates the index with the resulting contents after it cleanly resolves conflicts using previously recorded resolution. Defaults to false. @@ -1795,12 +2340,16 @@ sendemail.identity:: values in the 'sendemail' section. The default identity is the value of 'sendemail.identity'. -sendemail.smtpencryption:: +sendemail.smtpEncryption:: See linkgit:git-send-email[1] for description. Note that this setting is not subject to the 'identity' mechanism. -sendemail.smtpssl:: - Deprecated alias for 'sendemail.smtpencryption = ssl'. +sendemail.smtpssl (deprecated):: + 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 @@ -1808,31 +2357,34 @@ sendemail.<identity>.*:: identity is selected, through command-line or 'sendemail.identity'. -sendemail.aliasesfile:: -sendemail.aliasfiletype:: +sendemail.aliasesFile:: +sendemail.aliasFileType:: +sendemail.annotate:: sendemail.bcc:: sendemail.cc:: -sendemail.cccmd:: -sendemail.chainreplyto:: +sendemail.ccCmd:: +sendemail.chainReplyTo:: sendemail.confirm:: -sendemail.envelopesender:: +sendemail.envelopeSender:: sendemail.from:: -sendemail.multiedit:: +sendemail.multiEdit:: sendemail.signedoffbycc:: -sendemail.smtppass:: +sendemail.smtpPass:: sendemail.suppresscc:: -sendemail.suppressfrom:: +sendemail.suppressFrom:: sendemail.to:: -sendemail.smtpdomain:: -sendemail.smtpserver:: -sendemail.smtpserverport:: -sendemail.smtpserveroption:: -sendemail.smtpuser:: +sendemail.smtpDomain:: +sendemail.smtpServer:: +sendemail.smtpServerPort:: +sendemail.smtpServerOption:: +sendemail.smtpUser:: sendemail.thread:: +sendemail.transferEncoding:: sendemail.validate:: +sendemail.xmailer:: See linkgit:git-send-email[1] for description. -sendemail.signedoffcc:: +sendemail.signedoffcc (deprecated):: Deprecated alias for 'sendemail.signedoffbycc'. showbranch.default:: @@ -1842,15 +2394,30 @@ 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 contain only untracked files, are shown with the directory name only. Showing untracked files means that Git needs to lstat() all - all the files in the whole repository, which might be slow on some + the files in the whole repository, which might be slow on some systems. So, this variable controls how the commands displays the untracked files. Possible values are: + @@ -1864,33 +2431,54 @@ If this variable is not specified, it defaults to 'normal'. This variable can be overridden with the -u|--untracked-files option of linkgit:git-status[1] and linkgit:git-commit[1]. -status.submodulesummary:: +status.submoduleSummary:: Defaults to false. 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`. The only + exception to that rule is that status and commit will show staged + submodule changes. 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:: + The path within this project and URL for a submodule. These + variables are initially populated by 'git submodule init'. See + linkgit:git-submodule[1] and linkgit:gitmodules[5] for + details. + submodule.<name>.update:: - The path within this project, URL, and the updating strategy - for a submodule. These variables are initially populated - by 'git submodule init'; edit them to override the - URL and other values found in the `.gitmodules` file. See - linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. + The default update procedure for a submodule. This variable + is populated by `git submodule init` from the + linkgit:gitmodules[5] file. See description of 'update' + command in linkgit:git-submodule[1]. + +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 - command line option to "git fetch" and "git pull". + command-line option to "git fetch" and "git pull". This setting will override that from in the linkgit:gitmodules[5] file. submodule.<name>.ignore:: Defines under what circumstances "git status" and the diff family show a submodule as modified. When set to "all", it will never be considered - modified, "dirty" will ignore all changes to the submodules work tree and + modified (but it will nonetheless show up in the output of status and + commit when it has been staged), "dirty" will ignore all changes + to the submodules work tree and takes only differences between the HEAD of the submodule and the commit recorded in the superproject into account. "untracked" will additionally let submodules with modified tracked files in their work tree show up. @@ -1898,7 +2486,13 @@ 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. + +tag.sort:: + This variable controls the sort ordering of tags when displayed by + linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the + value of this variable will be used as the default. tar.umask:: This variable can be used to restrict the permission bits of @@ -1912,18 +2506,56 @@ transfer.fsckObjects:: 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. +uploadarchive.allowUnreachable:: + If true, allow clients to use `git archive --remote` to request + any tree, whether reachable from the ref tips or not. See the + discussion in the `SECURITY` section of + linkgit:git-upload-archive[1] for more details. Defaults to + `false`. + +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. @@ -1934,11 +2566,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:: @@ -1951,12 +2583,24 @@ user.name:: Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_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. +user.signingKey:: + 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. + +versionsort.prereleaseSuffix:: + When version sort is used in linkgit:git-tag[1], prerelease + tags (e.g. "1.0-rc1") may appear after the main release + "1.0". By specifying the suffix "-rc" in this variable, + "1.0-rc1" will appear before "1.0". ++ +This variable can be specified multiple times, once per suffix. The +order of suffixes in the config file determines the sorting order +(e.g. if "-pre" appears before "-rc" in the config file then 1.0-preXX +is sorted before 1.0-rcXX). The sorting order between different +suffixes is undefined if they are in multiple config files. 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 c000f08a9d..ccd1fc8122 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 1aed79e7dc..6eaa45271c 100644 --- a/Documentation/diff-config.txt +++ b/Documentation/diff-config.txt @@ -1,4 +1,4 @@ -diff.autorefreshindex:: +diff.autoRefreshIndex:: When using 'git diff' to compare with work tree files, do not consider stat-only change as changed. Instead, silently run `git update-index --refresh` to @@ -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,9 +73,13 @@ 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:: +diff.mnemonicPrefix:: If set, 'git diff' uses a prefix pair that is different from the standard "a/" and "b/" depending on what is being compared. When this configuration is in effect, reverse diff output also swaps @@ -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. @@ -118,7 +148,7 @@ diff.<driver>.textconv:: conversion is used to generate a human-readable diff. See linkgit:gitattributes[5] for details. -diff.<driver>.wordregex:: +diff.<driver>.wordRegex:: The regular expression that the diff driver should use to split words in a line. 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-format.txt b/Documentation/diff-format.txt index 15c7e794f4..85b08909ce 100644 --- a/Documentation/diff-format.txt +++ b/Documentation/diff-format.txt @@ -66,7 +66,8 @@ be committed) Status letters C and R are always followed by a score (denoting the percentage of similarity between the source and target of the move or -copy), and are the only ones to be so. +copy). Status letter M may be followed by a score (denoting the +percentage of dissimilarity) for file rewrites. <sha1> is shown as all 0's if a file is new on the filesystem and it is out of sync with the index. diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt index c57460c03d..843a20bac2 100644 --- a/Documentation/diff-generate-patch.txt +++ b/Documentation/diff-generate-patch.txt @@ -174,8 +174,8 @@ added, from the point of view of that parent). In the above example output, the function signature was changed from both files (hence two `-` removals from both file1 and file2, plus `++` to mean one line that was added does not appear -in either file1 nor file2). Also eight other lines are the same -from file1 but do not appear in file2 (hence prefixed with `{plus}`). +in either file1 or file2). Also eight other lines are the same +from file1 but do not appear in file2 (hence prefixed with `+`). When shown by `git diff-tree -c`, it compares the parents of a merge commit with the merge result (i.e. file1..fileN are the diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 9f7cba2be6..ccd499867b 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 @@ -52,20 +57,49 @@ endif::git-format-patch[] --patience:: Generate a diff using the "patience diff" algorithm. +--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. 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. + 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. + 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 @@ -156,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. @@ -272,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). + @@ -296,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>]:: @@ -318,7 +358,7 @@ endif::git-log[] --irreversible-delete:: Omit the preimage for deletes, i.e. print only the header but not the diff between the preimage and `/dev/null`. The resulting patch - is not meant to be applied with `patch` nor `git apply`; this is + is not meant to be applied with `patch` or `git apply`; this is solely for people who want to just concentrate on reviewing the text after the change. In addition, the output obviously lack enough information to apply such a patch in reverse, even manually, @@ -348,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 @@ -363,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:: @@ -404,6 +469,9 @@ 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. @@ -445,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.txto b/Documentation/everyday.txto new file mode 100644 index 0000000000..c5047d8f9b --- /dev/null +++ b/Documentation/everyday.txto @@ -0,0 +1,9 @@ +Everyday Git With 20 Commands Or So +=================================== + +This document has been moved to linkgit:giteveryday[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/fetch-options.txt b/Documentation/fetch-options.txt index 39d326abc6..45583d8454 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,34 +51,43 @@ 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 - behavior for a remote may be specified with the remote.<name>.tagopt + behavior for a remote may be specified with the remote.<name>.tagOpt setting. See linkgit:git-config[1]. ifndef::git-pull[] +--refmap=<refspec>:: + When fetching refs listed on the command line, use the + specified refspec (can be given more than once) to map the + refs to remote-tracking branches, instead of the values of + `remote.*.fetch` configuration variables for the remote + repository. See section on "Configured Remote-tracking + Branches" for details. + -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 9c1d395722..f2eb9076d7 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -8,10 +8,10 @@ git-add - Add file contents to the index 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>...] +'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] + [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] + [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] + [--] [<pathspec>...] DESCRIPTION ----------- @@ -49,12 +49,18 @@ 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` - and `dir/file2`) can be given to add all files in the - directory, recursively. + and `dir/file2`) can be given to update the index to + match the current state of the directory as a whole (e.g. + specifying `dir` will record not just a file `dir/file1` + modified in the working tree, a file `dir/file2` added to + the working tree, but also a file `dir/file3` removed from + the working tree. Note that older versions of Git used + to ignore removed files; use `--no-all` option if you want + to add modified or new files but ignore removed ones. -n:: --dry-run:: @@ -100,23 +106,38 @@ 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 when `-u` option is used, all +tracked files in the entire working tree are updated (old versions +of Git used to limit the update to the current directory and its +subdirectories). -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 when `-A` option is used, all +files in the entire working tree are updated (old versions +of Git used to limit the update to the current directory and its +subdirectories). + +--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 users who are used to older +versions of Git, whose "git add <pathspec>..." was a synonym +for "git add --no-all <pathspec>...", i.e. ignored removed files. -N:: --intent-to-add:: @@ -152,10 +173,10 @@ subdirectories. Configuration ------------- -The optional configuration variable `core.excludesfile` indicates a path to a +The optional configuration variable `core.excludesFile` indicates a path to a file containing patterns of file names to exclude from git-add, similar to $GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to -those in info/exclude. See linkgit:gitrepository-layout[5]. +those in info/exclude. See linkgit:gitignore[5]. EXAMPLES @@ -279,9 +300,9 @@ patch:: y - stage this hunk n - do not stage this hunk - q - quit; do not stage this hunk nor any of the remaining ones + q - quit; do not stage this hunk or any of the remaining ones a - stage this hunk and all later hunks in the file - d - do not stage this hunk nor any of the later hunks in the file + d - do not stage this hunk or any of the later hunks in the file g - select a hunk to go to / - search for a hunk matching the given regex j - leave this hunk undecided, see next undecided hunk @@ -296,7 +317,7 @@ After deciding the fate for all hunks, if there is any hunk that was chosen, the index is updated with the selected hunks. + You can omit having to type return here, by setting the configuration -variable `interactive.singlekey` to `true`. +variable `interactive.singleKey` to `true`. diff:: diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index ee6cca2e13..0d8ba48f79 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -9,12 +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>] - [--exclude=<path>] [--reject] [-q | --quiet] - [--scissors | --no-scissors] + [--exclude=<path>] [--include=<path>] [--reject] [-q | --quiet] + [--[no-]scissors] [-S[<keyid>]] [--patch-format=<format>] [(<mbox> | <Maildir>)...] 'git am' (--continue | --skip | --abort) @@ -43,8 +43,7 @@ OPTIONS --keep-non-patch:: Pass `-b` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]). ---keep-cr:: ---no-keep-cr:: +--[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 @@ -53,11 +52,23 @@ OPTIONS -c:: --scissors:: Remove everything in body before a scissors line (see - linkgit:git-mailinfo[1]). + linkgit:git-mailinfo[1]). Can be activated by default using + the `mailinfo.scissors` configuration variable. --no-scissors:: Ignore scissors lines (see linkgit:git-mailinfo[1]). +-m:: +--message-id:: + Pass the `-m` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]), + so that the Message-ID header is added to the commit message. + The `am.messageid` configuration variable can be used to specify + the default behaviour. + +--no-message-id:: + Do not add the Message-ID header to the commit message. + `no-message-id` is useful to override `am.messageid`. + -q:: --quiet:: Be quiet. Only print error messages. @@ -84,7 +95,6 @@ default. You can use `--no-utf8` to override this. it is supposed to apply to and we have those blobs available locally. ---ignore-date:: --ignore-space-change:: --ignore-whitespace:: --whitespace=<option>:: @@ -92,11 +102,18 @@ default. You can use `--no-utf8` to override this. -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 the patch. +--patch-format:: + By default the command will try to detect the patch format + automatically. This option allows the user to bypass the automatic + detection and specify the patch format that the patch(es) should be + interpreted as. Valid formats are mbox, stgit, stgit-series and hg. + -i:: --interactive:: Run interactively. @@ -119,6 +136,10 @@ default. You can use `--no-utf8` to override this. Skip the current patch. This is only meaningful when restarting an aborted patch. +-S[<keyid>]:: +--gpg-sign[=<keyid>]:: + GPG-sign commits. + --continue:: -r:: --resolved:: @@ -132,7 +153,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'. @@ -176,7 +197,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, @@ -189,6 +210,11 @@ commits, like running 'git am' on the wrong branch or an error in the commits that is more easily fixed by changing the mailbox (e.g. errors in the "From:" lines). +HOOKS +----- +This command can run `applypatch-msg`, `pre-applypatch`, +and `post-applypatch` hooks. See linkgit:githooks[5] for more +information. SEE ALSO -------- diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt index afd2c9ae59..d9ed6a1a4e 100644 --- a/Documentation/git-apply.txt +++ b/Documentation/git-apply.txt @@ -9,14 +9,14 @@ 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] [--ignore-space-change | --ignore-whitespace ] [--whitespace=(nowarn|warn|fix|error|error-all)] [--exclude=<path>] [--include=<path>] [--directory=<root>] - [--verbose] [<patch>...] + [--verbose] [--unsafe-paths] [<patch>...] DESCRIPTION ----------- @@ -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. @@ -220,10 +229,20 @@ For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh` can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by running `git apply --directory=modules/git-gui`. +--unsafe-paths:: + By default, a patch that affects outside the working area + (either a Git controlled working tree, or the current working + directory when "git apply" is used as a replacement of GNU + patch) is rejected as a mistake (or a mischief). ++ +When `git apply` is used as a "better GNU patch", the user can pass +the `--unsafe-paths` option to override this safety check. This option +has no effect when `--index` or `--cached` is in use. + Configuration ------------- -apply.ignorewhitespace:: +apply.ignoreWhitespace:: Set to 'change' if you want changes in whitespace to be ignored by default. Set to one of: no, none, never, false if you want changes in whitespace to be significant. diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt index f4504ba9bf..163b9f6f41 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 ac7006e640..cfa1e4ebe4 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. @@ -64,7 +65,10 @@ OPTIONS --remote=<repo>:: Instead of making a tar archive from the local repository, - retrieve a tar archive from a remote repository. + retrieve a tar archive from a remote repository. Note that the + remote repository may place restrictions on which sha1 + expressions may be allowed in `<tree-ish>`. See + linkgit:git-upload-archive[1] for details. --exec=<git-upload-archive>:: Used with --remote to specify the path to the @@ -120,6 +124,7 @@ tar.<format>.remote:: user-defined formats, but true for the "tar.gz" and "tgz" formats. +[[ATTRIBUTES]] ATTRIBUTES ---------- @@ -128,7 +133,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. @@ -160,7 +165,7 @@ EXAMPLES Same as above, but the format is inferred from the output file. -`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 --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. diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt index 8a2ba37904..0f0c6ff082 100644 --- a/Documentation/git-bisect-lk2009.txt +++ b/Documentation/git-bisect-lk2009.txt @@ -119,7 +119,7 @@ developed and maintained during years or even tens of years by a lot of people. And as there are often many people who depend (sometimes critically) on such software, regressions are a really big problem. -One such software is the linux kernel. And if we look at the linux +One such software is the Linux kernel. And if we look at the Linux kernel, we can see that a lot of time and effort is spent to fight regressions. The release cycle start with a 2 weeks long merge window. Then the first release candidate (rc) version is tagged. And @@ -132,7 +132,7 @@ regressions. And this time is more than 80% of the release cycle time. But this is not the end of the fight yet, as of course it continues after the release. -And then this is what Ingo Molnar (a well known linux kernel +And then this is what Ingo Molnar (a well known Linux kernel developer) says about his use of git bisect: _____________ @@ -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 e4f46bc18d..4cb52a7302 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -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 @@ -117,7 +117,7 @@ $ git bisect visualize `view` may also be used as a synonym for `visualize`. If the 'DISPLAY' environment variable is not set, 'git log' is used -instead. You can also give command line options such as `-p` and +instead. You can also give command-line options such as `-p` and `--stat`. ------------ @@ -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, @@ -284,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: @@ -291,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: @@ -302,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" @@ -351,6 +354,7 @@ 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 @@ -368,6 +372,7 @@ $ git bisect run sh -c ' 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 diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index 9516914236..9f23a861ce 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,17 +18,25 @@ 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 -a text string in the diff. A small example: +a text string in the diff. A small example of the pickaxe interface +that searches for `blame_usage`: ----------------------------------------------------------------------------- $ git log --pretty=oneline -S'blame_usage' @@ -96,7 +104,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 +132,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 +171,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 0427e80a35..359619b552 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -10,8 +10,11 @@ SYNOPSIS [verse] 'git branch' [--color[=<when>] | --no-color] [-r | -a] [--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>] @@ -19,13 +22,15 @@ SYNOPSIS 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. This list mode is also -activated by the `--list` option (see below). -<pattern> restricts the output to matching branches, 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. +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 @@ -42,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 +`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 @@ -59,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 @@ -107,6 +113,14 @@ 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. @@ -120,11 +134,18 @@ OPTIONS use `git branch --list <pattern>` to list matching branches. -v:: +-vv:: --verbose:: 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. @@ -136,7 +157,8 @@ OPTIONS -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, @@ -144,35 +166,46 @@ OPTIONS upstream when the new branch is checked out. + This behavior is the default when the start point is a remote-tracking branch. -Set the branch.autosetupmerge configuration variable to `false` if you +Set the branch.autoSetupMerge configuration variable to `false` if you want `git checkout` and `git branch` to always behave as if '--no-track' were given. Set it to `always` if you want this behavior when the start-point is either a local or remote-tracking branch. --no-track:: Do not set up "upstream" configuration, even if the - branch.autosetupmerge configuration variable is true. + 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. +-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. +--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 92b01ec25d..0417562eb7 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 2fb95bbd19..f6a16f4300 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 5abdbaa51c..00e2aa2df2 100644 --- a/Documentation/git-check-attr.txt +++ b/Documentation/git-check-attr.txt @@ -31,8 +31,9 @@ OPTIONS 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 @@ -48,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: @@ -56,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 -------- diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt new file mode 100644 index 0000000000..e35cd0489b --- /dev/null +++ b/Documentation/git-check-ignore.txt @@ -0,0 +1,119 @@ +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. + +By default, tracked files are not shown at all since they are not +subject to exclude rules; but see `--no-index'. + +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 0000000000..39028ee1a3 --- /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 103e7b128d..fc02959ba4 100644 --- a/Documentation/git-check-ref-format.txt +++ b/Documentation/git-check-ref-format.txt @@ -18,14 +18,14 @@ 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 @@ -40,9 +40,9 @@ git imposes the following rules on how references are named: . They cannot have ASCII control characters (i.e. bytes whose values are lower than \040, or \177 `DEL`), space, tilde `~`, - caret `{caret}`, or colon `:` anywhere. + caret `^`, or colon `:` anywhere. -. They cannot have question-mark `?`, asterisk `{asterisk}`, or open +. They cannot have question-mark `?`, asterisk `*`, or open bracket `[` anywhere. See the `--refspec-pattern` option below for an exception to this rule. @@ -54,6 +54,8 @@ git imposes the following rules on how references are named: . 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 @@ -62,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 @@ -83,8 +85,7 @@ typed the branch name. OPTIONS ------- ---allow-onelevel:: ---no-allow-onelevel:: +--[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`. @@ -92,9 +93,9 @@ OPTIONS --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 `{asterisk}` + enabled, <refname> is allowed to contain a single `*` in place of a one full pathname component (e.g., - `foo/{asterisk}/bar` but not `foo/bar{asterisk}`). + `foo/*/bar` but not `foo/bar*`). --normalize:: Normalize 'refname' by removing any leading slash (`/`) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index c0a96e6c1e..d5041082e8 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 @@ -111,7 +144,7 @@ explicitly give a name with '-b' in such a case. --no-track:: Do not set up "upstream" configuration, even if the - branch.autosetupmerge configuration variable is true. + branch.autoSetupMerge configuration variable is true. -l:: Create the new branch's reflog; see linkgit:git-branch[1] for @@ -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, @@ -171,7 +210,7 @@ the conflicted merge in the specified paths. --conflict=<style>:: The same as --merge option above, but changes the way the conflicting hunks are presented, overriding the - merge.conflictstyle configuration variable. Possible values are + merge.conflictStyle configuration variable. Possible values are "merge" (default) and "diff3" (in addition to what is shown by "merge" style, shows the original contents). @@ -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 fed5097e00..1147c71da6 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -8,7 +8,8 @@ git-cherry-pick - Apply the changes introduced by some existing commits SYNOPSIS -------- [verse] -'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>... +'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] + [-S[<key-id>]] <commit>... 'git cherry-pick' --continue 'git cherry-pick' --quit 'git cherry-pick' --abort @@ -47,7 +48,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:: @@ -98,11 +101,40 @@ effect to your index in a row. --signoff:: Add Signed-off-by line at the end of the commit message. +-S[<key-id>]:: +--gpg-sign[=<key-id>]:: + GPG-sign commits. + --ff:: If the current HEAD is the same as the parent of the 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 cause `cherry-pick` to stop so the user can + examine the commit. 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] @@ -130,7 +162,16 @@ EXAMPLES 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 @@ -151,7 +192,7 @@ EXAMPLES 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 f6c19c734d..0ea921a593 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 79fb984144..641681f61a 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,24 @@ 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 delete files or directories + unless given -f, -n or -i. Git will refuse to delete directories + with .git sub directory or file unless a second -f + is given. This affects also git submodules where the storage area + of the removed submodule under .git/modules/ is not removed until + -f is given twice. + +-i:: +--interactive:: + Show what would be done and clean files interactively. See + ``Interactive mode'' for details. -n:: --dry-run:: @@ -60,9 +70,74 @@ OPTIONS 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-separated + 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 6e22522c4f..f1f2a3f7ea 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -12,9 +12,9 @@ SYNOPSIS 'git clone' [--template=<template_directory>] [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] - [--separate-git-dir <git dir>] + [--dissociate] [--separate-git-dir <git dir>] [--depth <depth>] [--[no-]single-branch] - [--recursive|--recurse-submodules] [--] <repository> + [--recursive | --recurse-submodules] [--] <repository> [<directory>] DESCRIPTION @@ -29,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 @@ -42,22 +43,24 @@ 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. --no-hardlinks:: - Optimize the cloning process from a repository on a - local filesystem by copying files under `.git/objects` - directory. + Force the cloning process from a repository on a local + filesystem to copy the files under the `.git/objects` + directory instead of using hardlinks. This may be desirable + if you are trying to make a back-up of your repository. --shared:: -s:: @@ -70,9 +73,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. @@ -95,7 +98,14 @@ objects from the source repository into a pack in the cloned repository. require fewer objects to be copied from the repository being cloned, reducing network and local storage costs. + -*NOTE*: see the NOTE for the `--shared` option. +*NOTE*: see the NOTE for the `--shared` option, and also the +`--dissociate` option. + +--dissociate:: + Borrow the objects from reference repositories specified + with the `--reference` options only to reduce network + transfer and stop borrowing from them after a clone is made + by making necessary local copies of borrowed objects. --quiet:: -q:: @@ -119,7 +129,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` @@ -147,9 +157,10 @@ objects from the source repository into a pack in the cloned repository. -b <name>:: Instead of pointing the newly created HEAD to the branch pointed to by the cloned repository's HEAD, point to `<name>` branch - instead. `--branch` can also take tags and treat them like - detached HEAD. In a non-bare repository, this is the branch - that will be checked out. + 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>:: @@ -174,20 +185,20 @@ objects from the source repository into a pack in the cloned repository. --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. - ---single-branch:: + 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:: @@ -201,8 +212,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. @@ -227,8 +238,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 ------------ @@ -245,10 +256,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 ------------ @@ -259,13 +270,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 0000000000..03d18465d4 --- /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 cfb9906bb5..f5f2a8d326 100644 --- a/Documentation/git-commit-tree.txt +++ b/Documentation/git-commit-tree.txt @@ -10,7 +10,9 @@ SYNOPSIS -------- [verse] 'git commit-tree' <tree> [(-p <parent>)...] < changelog -'git commit-tree' [(-p <parent>)...] [(-m <message>)...] [(-F <file>)...] <tree> +'git commit-tree' [(-p <parent>)...] [-S[<keyid>]] [(-m <message>)...] + [(-F <file>)...] <tree> + DESCRIPTION ----------- @@ -30,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 @@ -45,13 +47,21 @@ OPTIONS Each '-p' indicates the id of a parent commit object. -m <message>:: - A paragraph in the commig log message. This can be given more than + 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 ------------------ @@ -72,13 +82,13 @@ 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 the hostname used for outgoing mail (taken +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). @@ -88,15 +98,6 @@ 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 ---------- diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 5cc84a1391..617e29b38b 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[<key-id>]] [--] [<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,54 @@ 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`, `scissors` 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. +scissors:: + Same as `whitespace`, except that everything from (and + including) the line + "`# ------------------------ >8 ------------------------`" + is truncated if the message is to be edited. "`#`" can be + customized with core.commentChar. +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 +238,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, @@ -211,9 +250,10 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].) -o:: --only:: - Make a commit only from the paths specified on the + Make a commit by taking the updated working tree contents + of the paths specified on the command line, disregarding any contents that have been - staged so far. This is the default mode of operation of + staged for other paths. This is the default mode of operation of 'git commit' if any paths are given on the command line, in which case this option can be omitted. If this option is specified together with '--amend', then @@ -244,6 +284,10 @@ configuration variable documented in linkgit:git-config[1]. would be committed at the bottom of the commit message template. Note that this diff output doesn't have its lines prefixed with '#'. ++ +If specified twice, show in addition the unified diff between +what would be committed and the worktree files, i.e. the unstaged +changes to tracked files. -q:: --quiet:: @@ -265,6 +309,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 +336,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 +430,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 +450,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 e7ecf5d803..02ec096faa 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,11 +248,15 @@ 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*. -You can override these rules either by command line options or by environment +You can override these rules either by command-line options or by environment variables. The '--global' and the '--system' options will limit the file used to the global or system-wide file respectively. The GIT_CONFIG environment variable has a similar effect, but you can specify any filename you want. @@ -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 23c80cea64..2ff35683e5 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 neither 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 index 11edc5a173..7051c6bdf8 100644 --- a/Documentation/git-credential-cache--daemon.txt +++ b/Documentation/git-credential-cache--daemon.txt @@ -3,12 +3,12 @@ git-credential-cache--daemon(1) NAME ---- -git-credential-cache--daemon - temporarily store user credentials in memory +git-credential-cache--daemon - Temporarily store user credentials in memory SYNOPSIS -------- [verse] -git credential-cache--daemon <socket> +git credential-cache--daemon [--debug] <socket> DESCRIPTION ----------- @@ -21,6 +21,10 @@ 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. +If the `--debug` option is specified, the daemon does not close its +stderr stream, and may output extra diagnostics to it even after it has +begun listening for clients. + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-credential-cache.txt b/Documentation/git-credential-cache.txt index f3d09c5d51..89b730632d 100644 --- a/Documentation/git-credential-cache.txt +++ b/Documentation/git-credential-cache.txt @@ -3,7 +3,7 @@ git-credential-cache(1) NAME ---- -git-credential-cache - helper to temporarily store passwords in memory +git-credential-cache - Helper to temporarily store passwords in memory SYNOPSIS -------- @@ -14,13 +14,13 @@ git config credential.helper 'cache [options]' DESCRIPTION ----------- -This command caches credentials in memory for use by future git +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 +be used as a credential helper by other parts of Git. See linkgit:gitcredentials[7] or `EXAMPLES` below. OPTIONS diff --git a/Documentation/git-credential-store.txt b/Documentation/git-credential-store.txt index 31093467d1..bc97071e76 100644 --- a/Documentation/git-credential-store.txt +++ b/Documentation/git-credential-store.txt @@ -3,7 +3,7 @@ git-credential-store(1) NAME ---- -git-credential-store - helper to store credentials on disk +git-credential-store - Helper to store credentials on disk SYNOPSIS -------- @@ -20,7 +20,7 @@ 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. +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 @@ -29,7 +29,7 @@ linkgit:gitcredentials[7] or `EXAMPLES` below. OPTIONS ------- ---store=<path>:: +--file=<path>:: Use `<path>` to store credentials. The file will have its filesystem permissions set to prevent other users on the system @@ -63,11 +63,11 @@ stored on its own line as a URL like: https://user:pass@example.com ------------------------------ -When git needs authentication for a particular URL context, +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] +to Git. See the discussion of configuration in linkgit:gitcredentials[7] for more information. GIT diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt new file mode 100644 index 0000000000..b211440373 --- /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 7f79cec3f8..00154b6c85 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 6695ab3b4b..00a0679a28 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 +http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or +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 import, 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 827bc988ed..db4d7a917c 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. @@ -110,7 +110,7 @@ to allow writes to, for example: authdb = /etc/cvsserver/passwd ------ -The format of these files is username followed by the crypted password, +The format of these files is username followed by the encrypted password, for example: ------ @@ -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`. @@ -154,15 +154,15 @@ with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean [gitcvs] enabled=1 # optional for debugging - logfile=/path/to/logfile + logFile=/path/to/logfile ------ 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,16 +252,16 @@ 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:: +gitcvs.dbName:: Database name. The exact meaning depends on the selected database driver, for SQLite this is a filename. Supports variable substitution (see below). May not contain semicolons (`;`). Default: '%Ggitcvs.%m.sqlite' -gitcvs.dbdriver:: +gitcvs.dbDriver:: Used DBI driver. You can specify any available driver for this here, but it might not work. cvsserver is tested with 'DBD::SQLite', reported to work with @@ -271,12 +271,12 @@ gitcvs.dbdriver:: Default: 'SQLite' gitcvs.dbuser:: - Database user. Only useful if setting `dbdriver`, since + Database user. Only useful if setting `dbDriver`, since SQLite has no concept of database users. Supports variable substitution (see below). -gitcvs.dbpass:: - Database password. Only useful if setting `dbdriver`, since +gitcvs.dbPass:: + Database password. Only useful if setting `dbDriver`, since SQLite has no concept of database passwords. gitcvs.dbTableNamePrefix:: @@ -288,17 +288,17 @@ All variables can also be set per access method, see <<configaccessmethod,above> Variable substitution ^^^^^^^^^^^^^^^^^^^^^ -In `dbdriver` and `dbuser` you can use the following variables: +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. @@ -376,16 +413,16 @@ about end-of-line conversion. Alternatively, if `gitcvs.usecrlfattr` config is not enabled or the attributes do not allow automatic detection for a filename, then -the server uses the `gitcvs.allbinary` config for the default setting. -If `gitcvs.allbinary` is set, then file not otherwise +the server uses the `gitcvs.allBinary` config for the default setting. +If `gitcvs.allBinary` is set, then file not otherwise specified will default to '-kb' mode. Otherwise the '-k' mode -is left blank. But if `gitcvs.allbinary` is set to "guess", then +is left blank. But if `gitcvs.allBinary` is set to "guess", then the correct '-k' mode will be guessed based on the contents of the file. For best consistency with 'cvs', it is probably best to override the defaults by setting `gitcvs.usecrlfattr` to true, -and `gitcvs.allbinary` to "guess". +and `gitcvs.allBinary` to "guess". Dependencies ------------ diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt index 31b28fc29f..a69b3616ec 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. @@ -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>:: @@ -159,10 +169,9 @@ the facility of inet daemon to achieve the same before spawning --forbid-override=<service>:: Allow/forbid overriding the site-wide default with per repository configuration. By default, all the services - are overridable. + may be overridden. ---informative-errors:: ---no-informative-errors:: +--[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 @@ -171,6 +180,21 @@ the facility of inet daemon to achieve the same before spawning 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 @@ -180,7 +204,7 @@ SERVICES -------- These services can be globally enabled/disabled using the -command line options of this command. If a finer-grained +command-line options of this command. If finer-grained control is desired (e.g. to allow 'git archive' to be run against only in a few selected repositories the daemon serves), the per-repository configuration file can be used to enable or @@ -204,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 039cce2e98..d20ca402a1 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 c0b7c581ad..a86cf62e68 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 f8d0819113..bbab35fcaf 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 @@ -148,8 +158,8 @@ $ git diff --name-status <2> $ git diff arch/i386 include/asm-i386 <3> ------------ + -<1> Show only modification, rename and copy, but not addition -nor deletion. +<1> Show only modification, rename, and copy, but not addition +or deletion. <2> Show only names and the nature of change, but not actual diff output. <3> Limit diff output to named subtrees. diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt index 19d473c070..333cf6ff91 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 diff 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. @@ -74,6 +91,15 @@ with custom merge tool commands and has the same value as `$MERGED`. the default diff tool will be read from the configured `diff.guitool` variable instead of `diff.tool`. +--[no-]trust-exit-code:: + 'git-difftool' invokes a diff tool individually on each file. + Errors reported by the diff tool are ignored by default. + Use `--trust-exit-code` to make 'git-difftool' exit when an + invoked diff tool returns a non-zero exit code. ++ +'git-difftool' will forward the exit code of the invoked tool when +'--trust-exit-code' is used. + See linkgit:git-diff[1] for the full list of supported options. CONFIG VARIABLES @@ -99,6 +125,11 @@ See the `--tool=<tool>` option above for more details. difftool.prompt:: Prompt before each invocation of the diff tool. +difftool.trustExitCode:: + Exit difftool if the invoked diff tool returns a non-zero exit status. ++ +See the `--trust-exit-code` option above for more details. + SEE ALSO -------- linkgit:git-diff[1]:: diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt index f37eada63a..929e496af8 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 @@ -101,12 +105,21 @@ marks the same across runs. in the commit (as opposed to just listing the files which are different from the commit's first parent). +--anonymize:: + Anonymize the contents of the repository while still retaining + the shape of the history and stored tree. See the section on + `ANONYMIZING` below. + +--refspec:: + Apply the specified refspec to each ref exported. Multiple of them can + be specified. + [<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,13 +146,73 @@ referenced by that revision range contains the string 'refs/heads/master'. +ANONYMIZING +----------- + +If the `--anonymize` option is given, git will attempt to remove all +identifying information from the repository while still retaining enough +of the original tree and history patterns to reproduce some bugs. The +goal is that a git bug which is found on a private repository will +persist in the anonymized repository, and the latter can be shared with +git developers to help solve the bug. + +With this option, git will replace all refnames, paths, blob contents, +commit and tag messages, names, and email addresses in the output with +anonymized data. Two instances of the same string will be replaced +equivalently (e.g., two commits with the same author will have the same +anonymized author in the output, but bear no resemblance to the original +author string). The relationship between commits, branches, and tags is +retained, as well as the commit timestamps (but the commit messages and +refnames bear no resemblance to the originals). The relative makeup of +the tree is retained (e.g., if you have a root tree with 10 files and 3 +trees, so will the output), but their names and the contents of the +files will be replaced. + +If you think you have found a git bug, you can start by exporting an +anonymized stream of the whole repository: + +--------------------------------------------------- +$ git fast-export --anonymize --all >anon-stream +--------------------------------------------------- + +Then confirm that the bug persists in a repository created from that +stream (many bugs will not, as they really do depend on the exact +repository contents): + +--------------------------------------------------- +$ git init anon-repo +$ cd anon-repo +$ git fast-import <../anon-stream +$ ... test your bug ... +--------------------------------------------------- + +If the anonymized repository shows the bug, it may be worth sharing +`anon-stream` along with a regular bug report. Note that the anonymized +stream compresses very well, so gzipping it is encouraged. If you want +to examine the stream to see that it does not contain any private data, +you can peruse it directly before sending. You may also want to try: + +--------------------------------------------------- +$ perl -pe 's/\d+/X/g' <anon-stream | sort -u | less +--------------------------------------------------- + +which shows all of the unique lines (with numbers converted to "X", to +collapse "User 0", "User 1", etc into "User X"). This produces a much +smaller output, and it is usually easy to quickly confirm that there is +no private data in the stream. + + 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. +SEE ALSO +-------- +linkgit:git-fast-import[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index ec6ef31197..690fed3ea4 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,30 +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. ---done:: - Require a `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. +--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 @@ -117,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 @@ -223,7 +231,7 @@ Date Formats ~~~~~~~~~~~~ The following date formats are supported. A frontend should select the format it will use for this import by passing the format name -in the \--date-format=<fmt> command line option. +in the \--date-format=<fmt> command-line option. `raw`:: This is the Git native format and is `<time> SP <offutc>`. @@ -243,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 @@ -263,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. @@ -279,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 @@ -340,7 +348,7 @@ and control the current import process. More detailed discussion `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. + `--done` command-line option or `feature done` command. `cat-blob`:: Causes fast-import to print a blob in 'cat-file --batch' @@ -353,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 @@ -372,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? .... @@ -422,14 +430,14 @@ 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>` 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. +that was selected by the \--date-format=<fmt> command-line option. See ``Date Formats'' above for the set of supported formats, and their syntax. @@ -437,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 @@ -450,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 @@ -473,31 +483,32 @@ Marks must be declared (via `mark`) before they can be used. * Any valid Git SHA-1 expression that resolves to a commit. See ``SPECIFYING REVISIONS'' in linkgit:gitrevisions[7] for details. +* The special null SHA-1 (40 zeros) specifies that the branch is to be + removed. + The special case of restarting an incremental import from the 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 commit are permitted by fast-import, thereby establishing an n-way merge. -However Git's other tools never create commits with more than 15 -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` @@ -553,8 +564,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: @@ -661,8 +676,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. @@ -675,7 +690,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>`) @@ -688,13 +703,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` @@ -725,7 +740,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 .... @@ -770,11 +785,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). @@ -942,6 +957,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 @@ -975,7 +993,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 @@ -991,6 +1009,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 @@ -1040,7 +1061,9 @@ 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. + 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` ~~~~~~~~ @@ -1061,7 +1084,7 @@ Option commands must be the first commands on the input (not counting feature commands), to give an option command after any non-option command is an error. -The following commandline options change import semantics and may therefore +The following command-line options change import semantics and may therefore not be passed as option: * date-format @@ -1075,10 +1098,39 @@ not be passed as option: 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 +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 @@ -1385,6 +1437,10 @@ operator can use this facility to peek at the objects and refs from an import in progress, at the cost of some added running time and worse compression. +SEE ALSO +-------- +linkgit:git-fast-export[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index ed1bdaacd1..93b5067946 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 b41d7c1de1..e62d9a0717 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -17,26 +17,31 @@ SYNOPSIS DESCRIPTION ----------- -Fetches named heads or tags from one or more other repositories, -along with the objects necessary to complete them. - -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. - -'git fetch' can fetch from either a single named repository, +Fetch branches and/or tags (collectively, "refs") from one or more +other repositories, along with the objects necessary to complete their +histories. Remote-tracking branches are updated (see the description +of <refspec> below for ways to control this behavior). + +By default, any tag that points into the histories being fetched is +also 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 or by +configuring remote.<name>.tagOpt. By using a refspec that fetches tags +explicitly, you can fetch tags that do not point into branches you +are interested in as well. + +'git fetch' can fetch from either a single named repository or URL, 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. + +The names of refs that are fetched, together with the object names +they point at, are written to `.git/FETCH_HEAD`. This information +may be used by scripts or other git commands, such as linkgit:git-pull[1]. + OPTIONS ------- include::fetch-options.txt[] @@ -46,6 +51,55 @@ include::pull-fetch-param.txt[] include::urls-remotes.txt[] +CONFIGURED REMOTE-TRACKING BRANCHES[[CRTB]] +------------------------------------------- + +You often interact with the same remote repository by +regularly and repeatedly fetching from it. In order to keep track +of the progress of such a remote repository, `git fetch` allows you +to configure `remote.<repository>.fetch` configuration variables. + +Typically such a variable may look like this: + +------------------------------------------------ +[remote "origin"] + fetch = +refs/heads/*:refs/remotes/origin/* +------------------------------------------------ + +This configuration is used in two ways: + +* When `git fetch` is run without specifying what branches + and/or tags to fetch on the command line, e.g. `git fetch origin` + or `git fetch`, `remote.<repository>.fetch` values are used as + the refspecs---they specify which refs to fetch and which local refs + to update. The example above will fetch + all branches that exist in the `origin` (i.e. any ref that matches + the left-hand side of the value, `refs/heads/*`) and update the + corresponding remote-tracking branches in the `refs/remotes/origin/*` + hierarchy. + +* When `git fetch` is run with explicit branches and/or tags + to fetch on the command line, e.g. `git fetch origin master`, the + <refspec>s given on the command line determine what are to be + fetched (e.g. `master` in the example, + which is a short-hand for `master:`, which in turn means + "fetch the 'master' branch but I do not explicitly say what + remote-tracking branch to update with it from the command line"), + and the example command will + fetch _only_ the 'master' branch. The `remote.<repository>.fetch` + values determine which + remote-tracking branch, if any, is updated. When used in this + way, the `remote.<repository>.fetch` values do not have any + effect in deciding _what_ gets fetched (i.e. the values are not + used as refspecs when the command-line lists refspecs); they are + only used to decide _where_ the refs that are fetched are stored + by acting as a mapping. + +The latter use of the `remote.<repository>.fetch` values can be +overridden by giving the `--refmap=<refspec>` parameter(s) on the +command line. + + EXAMPLES -------- @@ -73,6 +127,19 @@ the local repository by fetching from the branches (respectively) The `pu` branch will be updated even if it is does not fast-forward, because it is prefixed with a plus sign; `tmp` will not be. +* Peek at a remote's branch, without configuring the remote in your local +repository: ++ +------------------------------------------------ +$ git fetch git://git.kernel.org/pub/scm/git/git.git maint +$ git log FETCH_HEAD +------------------------------------------------ ++ +The first command fetches the `maint` branch from the repository at +`git://git.kernel.org/pub/scm/git/git.git` and the second command uses +`FETCH_HEAD` to examine the branch with linkgit:git-log[1]. The fetched +objects will eventually be removed by git's built-in housekeeping (see +linkgit:git-gc[1]). BUGS ---- @@ -80,7 +147,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 0f2f117383..73fd9e8230 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 +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 (i.e. in a single-threaded manner), though it + _is_ possible to write filters that include their own parallelism, + in the scripts executed against each commit. + +* The 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 32aff954a2..bb1232a52c 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 c872b883ba..42408752d0 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 @@ -102,9 +114,10 @@ Fields that have name-email-date tuple as its value (`author`, and `date` to extract the named component. The complete message in a commit and tag object is `contents`. -Its first line is `contents:subject`, the remaining lines -are `contents:body` and the optional GPG signature -is `contents:signature`. +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`). @@ -116,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)`. @@ -206,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 6ea9be775c..bb3ea9372f 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -14,13 +14,14 @@ SYNOPSIS [(--attach|--inline)[=<boundary>] | --no-attach] [-s | --signoff] [--signature=<signature> | --no-signature] + [--signature-file=<file>] [-n | --numbered | -N | --no-numbered] [--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 +46,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 +59,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 +138,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,6 +167,15 @@ 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. @@ -175,6 +188,21 @@ will want to ensure that threading is disabled for `git send-email`. 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. @@ -183,17 +211,32 @@ will want to ensure that threading is disabled for `git send-email`. `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. +--signature-file=<file>:: + Works just like --signature except the signature is read from a file. + --suffix=.<sfx>:: Instead of using `.patch` as the suffix for generated filenames, use specified suffix. A common alternative is @@ -203,6 +246,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,13 +273,14 @@ attachments, and sign off patches with configuration variables. ------------ [format] headers = "Organization: git-foo\n" - subjectprefix = CHANGE + subjectPrefix = CHANGE suffix = .txt numbered = auto to = <email> cc = <email> attach [ = mime-boundary-string ] - signoff = true + signOff = true + coverletter = auto ------------ @@ -365,7 +410,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 @@ -397,7 +442,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 @@ -501,8 +547,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 6c47395ad2..25c431d3c5 100644 --- a/Documentation/git-fsck.txt +++ b/Documentation/git-fsck.txt @@ -11,7 +11,7 @@ SYNOPSIS [verse] 'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] [--[no-]full] [--strict] [--verbose] [--lost-found] - [--[no-]progress] [<object>*] + [--[no-]dangling] [--[no-]progress] [<object>*] DESCRIPTION ----------- @@ -23,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. @@ -51,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. @@ -59,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. @@ -73,8 +77,7 @@ 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. ---progress:: ---no-progress:: +--[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 @@ -84,7 +87,7 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless DISCUSSION ---------- -git-fsck tests SHA1 and general object sanity, and it does full tracking +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 diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index 815afcb922..52234987f9 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 ----------- @@ -54,16 +54,17 @@ all loose objects are combined into a single pack using `git repack -d -l`. Setting the value of `gc.auto` to 0 disables automatic packing of loose objects. + -If the number of packs exceeds the value of `gc.autopacklimit`, +If the number of packs exceeds the value of `gc.autoPackLimit`, then existing packs (except those marked with a `.keep` file) are consolidated into a single pack by using the `-A` option of -'git repack'. Setting `gc.autopacklimit` to 0 disables +'git repack'. Setting `gc.autoPackLimit` to 0 disables 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'. @@ -96,18 +101,18 @@ branches: ------------ [gc "refs/remotes/*"] reflogExpire = never - reflogexpireUnreachable = 3 days + reflogExpireUnreachable = 3 days ------------ -The optional configuration variable 'gc.rerereresolved' indicates +The optional configuration variable 'gc.rerereResolved' indicates how long records of conflicted merge you resolved earlier are kept. This defaults to 60 days. -The optional configuration variable 'gc.rerereunresolved' indicates +The optional configuration variable 'gc.rerereUnresolved' indicates how long records of conflicted merge you have not resolved are kept. This defaults to 15 days. -The optional configuration variable 'gc.packrefs' determines if +The optional configuration variable 'gc.packRefs' determines if 'git gc' runs 'git pack-refs'. This can be set to "notbare" to enable it within all non-bare repos or it can be set to a boolean value. This defaults to true. @@ -119,6 +124,9 @@ the value, the more time is spent optimizing the delta compression. See the documentation for the --window' option in linkgit:git-repack[1] for more details. This defaults to 250. +Similarly, the optional configuration variable 'gc.aggressiveDepth' +controls --depth option in linkgit:git-repack[1]. This defaults to 250. + The optional configuration variable 'gc.pruneExpire' controls how old the unreferenced loose objects have to be before they are pruned. The default is "2 weeks ago". diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt index 6a8b1e3a7d..31811f16bd 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>...] - [ [--exclude-standard] [--cached | --no-index | --untracked] | <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,19 @@ 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'. + +grep.fullName:: + If set to true, enable '--full-name' option by default. OPTIONS @@ -49,7 +64,7 @@ OPTIONS blobs registered in the index file. --no-index:: - Search files in the current directory that is not managed 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 @@ -68,6 +83,13 @@ OPTIONS --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 @@ -245,11 +267,11 @@ 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`. diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt index 0041994443..8144527ae0 100644 --- a/Documentation/git-gui.txt +++ b/Documentation/git-gui.txt @@ -102,7 +102,7 @@ Examples 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 4b0a502e8e..02c1f12685 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 9e0b3f6811..3956525218 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:: @@ -66,9 +80,9 @@ CONFIGURATION VARIABLES help.format ~~~~~~~~~~~ -If no command line option is passed, the 'help.format' configuration +If no command-line option is passed, the 'help.format' configuration variable will be checked. The following values are supported for this -variable; they make 'git help' behave as their corresponding command +variable; they make 'git help' behave as their corresponding command- line option: * "man" corresponds to '-m|--man', @@ -79,15 +93,15 @@ help.browser, web.browser and browser.<tool>.path ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 'help.browser', 'web.browser' and 'browser.<tool>.path' will also -be checked if the 'web' format is chosen (either by command line +be checked if the 'web' format is chosen (either by command-line option or configuration variable). See '-w|--web' in the OPTIONS section above and linkgit:git-web{litdd}browse[1]. man.viewer ~~~~~~~~~~ -The 'man.viewer' config variable will be checked if the 'man' format -is chosen. The following values are currently supported: +The 'man.viewer' configuration variable will be checked if the 'man' +format is chosen. The following values are currently supported: * "man": use the 'man' program as usual, * "woman": use 'emacsclient' to launch the "woman" mode in emacs @@ -110,7 +124,7 @@ For example, this configuration: viewer = woman ------------------------------------------------ -will try to use konqueror first. But this may fail (for example if +will try to use konqueror first. But this may fail (for example, if DISPLAY is not set) and in that case emacs' woman mode will be tried. If everything fails, or if no viewer is configured, the viewer specified diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt index f4e0741c11..d422ba4b59 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: + @@ -158,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 ----------- @@ -183,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 070cd1e6ed..21a33d2c41 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,7 @@ 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. diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt index 875d2831a5..5d1e4c80cd 100644 --- a/Documentation/git-imap-send.txt +++ b/Documentation/git-imap-send.txt @@ -9,7 +9,7 @@ git-imap-send - Send a collection of patches from stdin to an IMAP folder SYNOPSIS -------- [verse] -'git imap-send' +'git imap-send' [-v] [-q] [--[no-]curl] DESCRIPTION @@ -26,6 +26,28 @@ Typical usage is something like: git format-patch --signoff --stdout --attach origin | git imap-send +OPTIONS +------- + +-v:: +--verbose:: + Be verbose. + +-q:: +--quiet:: + Be quiet. + +--curl:: + Use libcurl to communicate with the IMAP server, unless tunneling + into it. Ignored if Git was built without the USE_CURL_FOR_IMAP_SEND + option set. + +--no-curl:: + Talk to the IMAP server using git's own IMAP routines instead of + using libcurl. Ignored if Git was built with the NO_OPENSSL option + set. + + CONFIGURATION ------------- @@ -38,18 +60,17 @@ Variables imap.folder:: The folder to drop the mails into, which is typically the Drafts folder. For example: "INBOX.Drafts", "INBOX/Drafts" or - "[Gmail]/Drafts". Required to use imap-send. + "[Gmail]/Drafts". Required. imap.tunnel:: Command used to setup a tunnel to the IMAP server through which commands will be piped instead of using a direct network connection - to the server. Required when imap.host is not set to use imap-send. + to the server. Required when imap.host is not set. imap.host:: A URL identifying the server. Use a `imap://` prefix for non-secure connections and a `imaps://` prefix for secure connections. - Ignored when imap.tunnel is set, but required to use imap-send - otherwise. + Ignored when imap.tunnel is set, but required otherwise. imap.user:: The username to use when logging in to the server. @@ -76,7 +97,10 @@ imap.preformattedHTML:: imap.authMethod:: Specify authenticate method for authentication with IMAP server. - Current supported method is 'CRAM-MD5' only. + If Git was built with the NO_CURL option, or if your curl version is older + than 7.34.0, or if you're running git-imap-send with the `--no-curl` + option, the only supported method is 'CRAM-MD5'. If this is not set + then 'git imap-send' uses the basic IMAP plaintext LOGIN command. Examples ~~~~~~~~ @@ -97,7 +121,7 @@ Using direct mode: host = imap://imap.example.com user = bob pass = p4ssw0rd -.......................... +......................... Using direct mode with SSL: @@ -109,7 +133,7 @@ Using direct mode with SSL: pass = p4ssw0rd port = 123 sslverify = false -.......................... +......................... EXAMPLE diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt index 909687fed4..7a4e055520 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 a21e346789..648a6cd78a 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 9ac2bbaa56..8174d27efd 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. @@ -43,7 +43,7 @@ OPTIONS -q:: --quiet:: -Only print error and warning messages, all other output will be suppressed. +Only print error and warning messages; all other output will be suppressed. --bare:: @@ -57,89 +57,96 @@ 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 -is reinitialization, the repository will be moved to the specified -path. +Instead of initializing the repository as a directory to either `$GIT_DIR` or +`./.git/`, create a text file there containing the path to the actual +repository. This file acts as filesystem-agnostic Git symbolic link to the +repository. ++ +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 is given: ++ +-- +'umask' (or 'false'):: - - 'umask' (or 'false'): Use permissions reported by umask(2). The default, - when `--shared` is not specified. +Use permissions reported by umask(2). The default, when `--shared` is not +specified. - - 'group' (or 'true'): Make the repository group-writable, (and g+sx, since - the git group may be not the primary group of all users). - This is used to loosen the permissions of an otherwise safe umask(2) value. - Note that the umask still applies to the other permission bits (e.g. if - umask is '0022', using 'group' will not remove read privileges from other - (non-group) users). See '0xxx' for how to exactly specify the repository - permissions. +'group' (or 'true'):: - - 'all' (or 'world' or 'everybody'): Same as 'group', but make the repository - readable by all users. +Make the repository group-writable, (and g+sx, since the git group may be not +the primary group of all users). This is used to loosen the permissions of an +otherwise safe umask(2) value. Note that the umask still applies to the other +permission bits (e.g. if umask is '0022', using 'group' will not remove read +privileges from other (non-group) users). See '0xxx' for how to exactly specify +the repository permissions. - - '0xxx': '0xxx' is an octal number and each file will have mode '0xxx'. - '0xxx' will override users' umask(2) value (and not only loosen permissions - as 'group' and 'all' does). '0640' will create a repository which is - group-readable, but not group-writable or accessible to others. '0660' will - create a repo that is readable and writable to the current user and group, - but inaccessible to others. +'all' (or 'world' or 'everybody'):: -By default, the configuration flag receive.denyNonFastForwards is enabled +Same as 'group', but make the repository readable by all users. + +'0xxx':: + +'0xxx' is an octal number and each file will have mode '0xxx'. '0xxx' will +override users' umask(2) value (and not only loosen permissions as 'group' and +'all' does). '0640' will create a repository which is group-readable, but not +group-writable or accessible to others. '0660' will create a repo that is +readable and writable to the current user and group, but inaccessible to others. +-- + +By default, the configuration flag `receive.denyNonFastForwards` is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it. -If you name a (possibly non-existent) directory at the end of the command -line, the command is run inside the directory (possibly after creating it). +If you provide a 'directory', the command is run inside it. If this directory +does not exist, it will be created. -- - TEMPLATE DIRECTORY ------------------ The template directory contains files and directories that will be copied to the `$GIT_DIR` after it is created. -The template directory used will (in order): +The template directory will be one of the following (in order): - - The argument given with the `--template` option. + - the argument given with the `--template` option; - - The contents of the `$GIT_TEMPLATE_DIR` environment variable. + - the contents of the `$GIT_TEMPLATE_DIR` environment variable; - - The `init.templatedir` configuration variable. + - the `init.templateDir` configuration variable; or - - The default template directory: `/usr/share/git-core/templates`. + - the default template directory: `/usr/share/git-core/templates`. -The default template directory includes some directory structure, some -suggested "exclude patterns", and copies of sample "hook" files. -The suggested patterns and hook files are all modifiable and extensible. +The default template directory includes some directory structure, suggested +"exclude patterns" (see linkgit:gitignore[5]), and sample hook files (see linkgit:githooks[5]). 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 $ git init <1> $ git add . <2> +$ git commit <3> ---------------- + -<1> prepare /path/to/my/codebase/.git directory -<2> add all existing file to the index +<1> Create a /path/to/my/codebase/.git directory. +<2> Add all existing files to the index. +<3> Record the pristine state as the first commit in the history. GIT --- diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt index f3eef510f2..cc75b25022 100644 --- a/Documentation/git-instaweb.txt +++ b/Documentation/git-instaweb.txt @@ -76,7 +76,7 @@ You may specify configuration in your .git/config httpd = apache2 -f port = 4321 browser = konqueror - modulepath = /usr/lib/apache2/modules + modulePath = /usr/lib/apache2/modules ----------------------------------------------------------------------- diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt new file mode 100644 index 0000000000..d6d9231b50 --- /dev/null +++ b/Documentation/git-interpret-trailers.txt @@ -0,0 +1,314 @@ +git-interpret-trailers(1) +========================= + +NAME +---- +git-interpret-trailers - help add structured information into commit messages + +SYNOPSIS +-------- +[verse] +'git interpret-trailers' [--trim-empty] [(--trailer <token>[(=|:)<value>])...] [<file>...] + +DESCRIPTION +----------- +Help adding 'trailers' lines, that look similar to RFC 822 e-mail +headers, at the end of the otherwise free-form part of a commit +message. + +This command reads some patches or commit messages from either the +<file> arguments or the standard input if no <file> is specified. Then +this command applies the arguments passed using the `--trailer` +option, if any, to the commit message part of each input file. The +result is emitted on the standard output. + +Some configuration variables control the way the `--trailer` arguments +are applied to each commit message and the way any existing trailer in +the commit message is changed. They also make it possible to +automatically add some trailers. + +By default, a '<token>=<value>' or '<token>:<value>' argument given +using `--trailer` will be appended after the existing trailers only if +the last trailer has a different (<token>, <value>) pair (or if there +is no existing trailer). The <token> and <value> parts will be trimmed +to remove starting and trailing whitespace, and the resulting trimmed +<token> and <value> will appear in the message like this: + +------------------------------------------------ +token: value +------------------------------------------------ + +This means that the trimmed <token> and <value> will be separated by +`': '` (one colon followed by one space). + +By default the new trailer will appear at the end of all the existing +trailers. If there is no existing trailer, the new trailer will appear +after the commit message part of the output, and, if there is no line +with only spaces at the end of the commit message part, one blank line +will be added before the new trailer. + +Existing trailers are extracted from the input message by looking for +a group of one or more lines that contain a colon (by default), where +the group is preceded by one or more empty (or whitespace-only) lines. +The group must either be at the end of the message or be the last +non-whitespace lines before a line that starts with '---'. Such three +minus signs start the patch part of the message. + +When reading trailers, there can be whitespaces before and after the +token, the separator and the value. There can also be whitespaces +inside the token and the value. + +Note that 'trailers' do not follow and are not intended to follow many +rules for RFC 822 headers. For example they do not follow the line +folding rules, the encoding rules and probably many other rules. + +OPTIONS +------- +--trim-empty:: + If the <value> part of any trailer contains only whitespace, + the whole trailer will be removed from the resulting message. + This apply to existing trailers as well as new trailers. + +--trailer <token>[(=|:)<value>]:: + Specify a (<token>, <value>) pair that should be applied as a + trailer to the input messages. See the description of this + command. + +CONFIGURATION VARIABLES +----------------------- + +trailer.separators:: + This option tells which characters are recognized as trailer + separators. By default only ':' is recognized as a trailer + separator, except that '=' is always accepted on the command + line for compatibility with other git commands. ++ +The first character given by this option will be the default character +used when another separator is not specified in the config for this +trailer. ++ +For example, if the value for this option is "%=$", then only lines +using the format '<token><sep><value>' with <sep> containing '%', '=' +or '$' and then spaces will be considered trailers. And '%' will be +the default separator used, so by default trailers will appear like: +'<token>% <value>' (one percent sign and one space will appear between +the token and the value). + +trailer.where:: + This option tells where a new trailer will be added. ++ +This can be `end`, which is the default, `start`, `after` or `before`. ++ +If it is `end`, then each new trailer will appear at the end of the +existing trailers. ++ +If it is `start`, then each new trailer will appear at the start, +instead of the end, of the existing trailers. ++ +If it is `after`, then each new trailer will appear just after the +last trailer with the same <token>. ++ +If it is `before`, then each new trailer will appear just before the +first trailer with the same <token>. + +trailer.ifexists:: + This option makes it possible to choose what action will be + performed when there is already at least one trailer with the + same <token> in the message. ++ +The valid values for this option are: `addIfDifferentNeighbor` (this +is the default), `addIfDifferent`, `add`, `overwrite` or `doNothing`. ++ +With `addIfDifferentNeighbor`, a new trailer will be added only if no +trailer with the same (<token>, <value>) pair is above or below the line +where the new trailer will be added. ++ +With `addIfDifferent`, a new trailer will be added only if no trailer +with the same (<token>, <value>) pair is already in the message. ++ +With `add`, a new trailer will be added, even if some trailers with +the same (<token>, <value>) pair are already in the message. ++ +With `replace`, an existing trailer with the same <token> will be +deleted and the new trailer will be added. The deleted trailer will be +the closest one (with the same <token>) to the place where the new one +will be added. ++ +With `doNothing`, nothing will be done; that is no new trailer will be +added if there is already one with the same <token> in the message. + +trailer.ifmissing:: + This option makes it possible to choose what action will be + performed when there is not yet any trailer with the same + <token> in the message. ++ +The valid values for this option are: `add` (this is the default) and +`doNothing`. ++ +With `add`, a new trailer will be added. ++ +With `doNothing`, nothing will be done. + +trailer.<token>.key:: + This `key` will be used instead of <token> in the trailer. At + the end of this key, a separator can appear and then some + space characters. By default the only valid separator is ':', + but this can be changed using the `trailer.separators` config + variable. ++ +If there is a separator, then the key will be used instead of both the +<token> and the default separator when adding the trailer. + +trailer.<token>.where:: + This option takes the same values as the 'trailer.where' + configuration variable and it overrides what is specified by + that option for trailers with the specified <token>. + +trailer.<token>.ifexist:: + This option takes the same values as the 'trailer.ifexist' + configuration variable and it overrides what is specified by + that option for trailers with the specified <token>. + +trailer.<token>.ifmissing:: + This option takes the same values as the 'trailer.ifmissing' + configuration variable and it overrides what is specified by + that option for trailers with the specified <token>. + +trailer.<token>.command:: + This option can be used to specify a shell command that will + be called to automatically add or modify a trailer with the + specified <token>. ++ +When this option is specified, the behavior is as if a special +'<token>=<value>' argument were added at the beginning of the command +line, where <value> is taken to be the standard output of the +specified command with any leading and trailing whitespace trimmed +off. ++ +If the command contains the `$ARG` string, this string will be +replaced with the <value> part of an existing trailer with the same +<token>, if any, before the command is launched. ++ +If some '<token>=<value>' arguments are also passed on the command +line, when a 'trailer.<token>.command' is configured, the command will +also be executed for each of these arguments. And the <value> part of +these arguments, if any, will be used to replace the `$ARG` string in +the command. + +EXAMPLES +-------- + +* Configure a 'sign' trailer with a 'Signed-off-by' key, and then + add two of these trailers to a message: ++ +------------ +$ git config trailer.sign.key "Signed-off-by" +$ cat msg.txt +subject + +message +$ cat msg.txt | git interpret-trailers --trailer 'sign: Alice <alice@example.com>' --trailer 'sign: Bob <bob@example.com>' +subject + +message + +Signed-off-by: Alice <alice@example.com> +Signed-off-by: Bob <bob@example.com> +------------ + +* Extract the last commit as a patch, and add a 'Cc' and a + 'Reviewed-by' trailer to it: ++ +------------ +$ git format-patch -1 +0001-foo.patch +$ git interpret-trailers --trailer 'Cc: Alice <alice@example.com>' --trailer 'Reviewed-by: Bob <bob@example.com>' 0001-foo.patch >0001-bar.patch +------------ + +* Configure a 'sign' trailer with a command to automatically add a + 'Signed-off-by: ' with the author information only if there is no + 'Signed-off-by: ' already, and show how it works: ++ +------------ +$ git config trailer.sign.key "Signed-off-by: " +$ git config trailer.sign.ifmissing add +$ git config trailer.sign.ifexists doNothing +$ git config trailer.sign.command 'echo "$(git config user.name) <$(git config user.email)>"' +$ git interpret-trailers <<EOF +> EOF + +Signed-off-by: Bob <bob@example.com> +$ git interpret-trailers <<EOF +> Signed-off-by: Alice <alice@example.com> +> EOF + +Signed-off-by: Alice <alice@example.com> +------------ + +* Configure a 'fix' trailer with a key that contains a '#' and no + space after this character, and show how it works: ++ +------------ +$ git config trailer.separators ":#" +$ git config trailer.fix.key "Fix #" +$ echo "subject" | git interpret-trailers --trailer fix=42 +subject + +Fix #42 +------------ + +* Configure a 'see' trailer with a command to show the subject of a + commit that is related, and show how it works: ++ +------------ +$ git config trailer.see.key "See-also: " +$ git config trailer.see.ifExists "replace" +$ git config trailer.see.ifMissing "doNothing" +$ git config trailer.see.command "git log -1 --oneline --format=\"%h (%s)\" --abbrev-commit --abbrev=14 \$ARG" +$ git interpret-trailers <<EOF +> subject +> +> message +> +> see: HEAD~2 +> EOF +subject + +message + +See-also: fe3187489d69c4 (subject of related commit) +------------ + +* Configure a commit template with some trailers with empty values + (using sed to show and keep the trailing spaces at the end of the + trailers), then configure a commit-msg hook that uses + 'git interpret-trailers' to remove trailers with empty values and + to add a 'git-version' trailer: ++ +------------ +$ sed -e 's/ Z$/ /' >commit_template.txt <<EOF +> ***subject*** +> +> ***message*** +> +> Fixes: Z +> Cc: Z +> Reviewed-by: Z +> Signed-off-by: Z +> EOF +$ git config commit.template commit_template.txt +$ cat >.git/hooks/commit-msg <<EOF +> #!/bin/sh +> git interpret-trailers --trim-empty --trailer "git-version: \$(git describe)" "\$1" > "\$1.new" +> mv "\$1.new" "\$1" +> EOF +$ chmod +x .git/hooks/commit-msg +------------ + +SEE ALSO +-------- +linkgit:git-commit[1], linkgit:git-format-patch[1], linkgit:git-config[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 249fc878ec..18bc716a0c 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,7 +102,7 @@ include::diff-options.txt[] include::diff-generate-patch.txt[] -Examples +EXAMPLES -------- `git log --no-merges`:: @@ -98,12 +111,12 @@ Examples `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`:: @@ -112,9 +125,9 @@ Examples 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. @@ -132,30 +145,38 @@ Examples `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:: @@ -163,19 +184,19 @@ log.date:: `--date` option.) Defaults to "default", which means to write dates like `Sat May 8 19:35:34 2010 -0500`. -log.showroot:: - If `false`, 'git log' and related commands will not treat the +log.showRoot:: + 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 c406a11001..0000000000 --- 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 4b28292811..e26f01fb1d 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 @@ -185,15 +185,15 @@ specifies the format of exclude patterns. These exclude patterns come from these places, in order: - 1. The command line flag --exclude=<pattern> specifies a + 1. The command-line flag --exclude=<pattern> specifies a single pattern. Patterns are ordered in the same order they appear in the command line. - 2. The command line flag --exclude-from=<file> specifies a + 2. The command-line flag --exclude-from=<file> specifies a file containing a list of patterns. Patterns are ordered in the same order they appear in the file. - 3. The command line flag --exclude-per-directory=<name> specifies + 3. The command-line flag --exclude-per-directory=<name> specifies a name of the file in each directory 'git ls-files' examines, normally `.gitignore`. Files in deeper directories take precedence. Patterns are ordered in the diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 7a9b86a58a..2e22915eb8 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 97e7a8e9e7..0947084140 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 @@ -66,6 +66,11 @@ conversion, even with this flag. -n:: Disable all charset re-coding of the metadata. +-m:: +--message-id:: + Copy the Message-ID header at the end of the commit message. This + is useful in order to associate commits with mailing list discussions. + --scissors:: Remove everything in body before a scissors line. A line that mainly consists of scissors (either ">8" or "8<") and perforation diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt index b295bf8330..808426faac 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 d7db2a3737..d2fc12ec77 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:: diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt index e0df1b3340..02676fb391 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 c5f84b6495..58731c1942 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 3ceefb8a1f..1f94908e3c 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] - [-s <strategy>] [-X <strategy-option>] + [-s <strategy>] [-X <strategy-option>] [-S[<key-id>]] [--[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. @@ -98,9 +101,8 @@ commit or stash your changes before running 'git merge'. Specifying more than one commit will create a merge with 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 -that the current branch is configured to use as its upstream. +If no commit is given from the command line, 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 +172,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 +204,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: ------------ @@ -206,7 +232,7 @@ Barbie's remark on your side. The only thing you can tell is that your side wants to say it is hard and you'd prefer to go shopping, while the other side wants to claim it is easy. -An alternative style can be used by setting the "merge.conflictstyle" +An alternative style can be used by setting the "merge.conflictStyle" configuration variable to "diff3". In "diff3" style, the above conflict may look like this: @@ -303,7 +329,7 @@ CONFIGURATION ------------- include::merge-config.txt[] -branch.<name>.mergeoptions:: +branch.<name>.mergeOptions:: Sets default options for merging into branch <name>. The syntax and supported options are the same as those of 'git merge', but option values containing whitespace characters are currently not supported. diff --git a/Documentation/git-mergetool--lib.txt b/Documentation/git-mergetool--lib.txt index f98a41b87c..055550b2bc 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 2a49de7cfe..e846c2ed7f 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,15 +64,20 @@ 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 program. + This is the default if the merge resolution program is + explicitly specified with the `--tool` option or with the + `merge.tool` configuration variable. --prompt:: - Prompt before each invocation of the merge resolution program. - This is the default behaviour; the option is provided to - override any configuration settings. + Prompt before each invocation of the merge resolution program + to give the user a chance to skip the path. TEMPORARY FILES --------------- diff --git a/Documentation/git-mktag.txt b/Documentation/git-mktag.txt index 65e167a5c5..3ca158b05e 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 e3c8448614..e4531325cd 100644 --- a/Documentation/git-mv.txt +++ b/Documentation/git-mv.txt @@ -13,7 +13,7 @@ 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 [-v] [-f] [-n] [-k] <source> <destination> git mv [-v] [-f] [-n] [-k] <source> ... <destination directory> @@ -34,7 +34,7 @@ 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:: @@ -44,6 +44,26 @@ OPTIONS --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 ad1d1468c9..ca28fb8e2a 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 e8319eac69..851518d531 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -9,12 +9,12 @@ SYNOPSIS -------- [verse] 'git notes' [list [<object>]] -'git notes' add [-f] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] +'git notes' add [-f] [--allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] 'git notes' copy [-f] ( --stdin | <from-object> <to-object> ) -'git notes' append [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] -'git notes' edit [<object>] +'git notes' append [--allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>] +'git notes' edit [--allow-empty] [<object>] 'git notes' show [<object>] -'git notes' merge [-v | -q] [-s <strategy> ] <notes_ref> +'git notes' merge [-v | -q] [-s <strategy> ] <notes-ref> 'git notes' merge --commit [-v | -q] 'git notes' merge --abort [-v | -q] 'git notes' remove [--ignore-missing] [--stdin] [<object>...] @@ -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 @@ -151,6 +155,10 @@ OPTIONS Like '-C', but with '-c' the editor is invoked, so that the user can further edit the note message. +--allow-empty:: + Allow an empty note object to be stored. The default behavior is + to automatically remove empty notes. + --ref <ref>:: Manipulate the notes tree in <ref>. This overrides 'GIT_NOTES_REF' and the "core.notesRef" configuration. The ref @@ -283,7 +291,7 @@ arbitrary files using 'git hash-object': ------------ $ cc *.c $ blob=$(git hash-object -w a.out) -$ git notes --ref=built add -C "$blob" HEAD +$ git notes --ref=built add --allow-empty -C "$blob" HEAD ------------ (You cannot simply use `git notes --ref=built add -F a.out HEAD` @@ -371,16 +379,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 index 8b92cc0f8d..a1664b9f68 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -18,33 +18,26 @@ SYNOPSIS DESCRIPTION ----------- This command provides a way to interact with p4 repositories -using git. +using Git. -Create a new git repository from an existing p4 repository using +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 +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 ------- -* Create an alias for 'git p4', using the full path to the 'git-p4' - script if needed: -+ ------------- -$ git config --global alias.p4 '!git-p4' ------------- - * Clone a repository: + ------------ $ git p4 clone //depot/path/project ------------ -* Do some work in the newly created git repository: +* Do some work in the newly created Git repository: + ------------ $ cd project @@ -52,7 +45,7 @@ $ vi foo.h $ git commit -a -m "edited foo.h" ------------ -* Update the git repository with recent changes from p4, rebasing your +* Update the Git repository with recent changes from p4, rebasing your work on top: + ------------ @@ -71,21 +64,21 @@ COMMANDS Clone ~~~~~ -Generally, 'git p4 clone' is used to create a new git directory +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'. +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'. +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 +To reproduce the entire p4 history in Git, use the '@all' modifier on the depot path: ------------ $ git p4 clone //depot/path/project@all @@ -95,13 +88,13 @@ $ 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: +be included in the Git repository using: ------------ $ git p4 sync ------------ -This command finds new changes in p4 and imports them as git commits. +This command finds new changes in p4 and imports them as Git commits. -P4 repositories can be added to an existing git repository using +P4 repositories can be added to an existing Git repository using 'git p4 sync' too: ------------ $ mkdir repo-git @@ -110,14 +103,19 @@ $ 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 +'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 +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. +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 @@ -134,13 +132,13 @@ $ git p4 rebase Submit ~~~~~~ -Submitting changes from a git repository back to the p4 repository +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 +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 +To submit all changes that are in the current Git branch but not in the 'p4/master' branch, use: ------------ $ git p4 submit @@ -156,7 +154,7 @@ 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 +according to the author of the Git commit. This option requires admin privileges in p4, which can be granted using 'p4 protect'. @@ -165,24 +163,34 @@ OPTIONS General options ~~~~~~~~~~~~~~~ -All commands except clone accept this option. +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 <branch>:: - Import changes into given branch. If the branch starts with - 'refs/', it will be used as is, otherwise the path 'refs/heads/' - will be prepended. The default branch is 'master'. If used - with an initial clone, no HEAD will be checked out. +--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 repository: ++ ---- $ git init $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2 @@ -200,12 +208,13 @@ git repository: --silent:: Do not print any progress information. ---verbose:: - Provide more progress information. - --detect-labels:: Query p4 for labels associated with the depot paths, and add - them as tags in git. + 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/', @@ -221,46 +230,43 @@ git repository: specifier. --keep-path:: - The mapping of file names from the p4 depot path to git, by + 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, + 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'. + 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. +-/ <path>:: + Exclude selected depot paths when cloning or syncing. + 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 + 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. ---verbose:: - Provide more progress information. - --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[<n>]:: +-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 @@ -270,6 +276,40 @@ These options can be used to modify 'git p4 submit' behavior. 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 ----------------- @@ -289,12 +329,12 @@ p4 revision specifier on the end: "//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". + 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. + updated version of the file is the one that appears in Git. See 'p4 help revisions' for the full syntax of p4 revision specifiers. @@ -303,23 +343,27 @@ 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. Git-p4 can consult the client -spec when given the '--use-client-spec' option or useClientSpec -variable. - -The full syntax for a p4 view is documented in 'p4 help views'. Git-p4 +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 +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. +'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 +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. @@ -327,7 +371,7 @@ 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 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 @@ -337,7 +381,7 @@ 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. +subdirectories in p4, and to generate these as branches in Git. For example, if the P4 repository structure is: ---- @@ -359,7 +403,7 @@ 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 +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 @@ -367,15 +411,17 @@ 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 +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 +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. @@ -413,9 +459,9 @@ git-p4.client:: Clone and sync variables ~~~~~~~~~~~~~~~~~~~~~~~~ git-p4.syncFromOrigin:: - Because importing commits from other git repositories is much faster + 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', + 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. @@ -430,11 +476,23 @@ git-p4.branchList:: 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 @@ -444,16 +502,18 @@ git-p4.useClientSpec:: Submit variables ~~~~~~~~~~~~~~~~ git-p4.detectRenames:: - Detect renames. See linkgit:git-diff[1]. + 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]. + 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]. + Detect copies harder. See linkgit:git-diff[1]. A boolean. git-p4.preserveUser:: - On submit, re-author changes to reflect the git author, + On submit, re-author changes to reflect the Git author, regardless of who invokes 'git p4 submit'. git-p4.allowMissingP4Users:: @@ -483,14 +543,30 @@ git-p4.skipUserNameCheck:: 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. +* 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 + 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 diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt index 20c8551d6a..c2f76fb1ea 100644 --- a/Documentation/git-pack-objects.txt +++ b/Documentation/git-pack-objects.txt @@ -13,7 +13,7 @@ SYNOPSIS [--no-reuse-delta] [--delta-base-offset] [--non-empty] [--local] [--incremental] [--window=<n>] [--depth=<n>] [--revs [--unpacked | --all]] [--stdout | base-name] - [--keep-true-parents] < object-list + [--shallow] [--keep-true-parents] < object-list DESCRIPTION @@ -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:: @@ -65,6 +64,8 @@ base-name:: the same way as 'git rev-list' with the `--objects` flag uses its `commit` arguments to build the list of objects it outputs. The objects on the resulting list are packed. + Besides revisions, `--not` or `--shallow <SHA-1>` lines are + also accepted. --unpacked:: This implies `--revs`. When processing the list of @@ -80,7 +81,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 +186,19 @@ 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. +--shallow:: + Optimize a pack that will be provided to a client with a shallow + repository. This option, combined with \--thin, can result in a + smaller pack at the cost of speed. + --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 +208,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 +218,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 a3c6677bfa..154081f2de 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 90268f02e7..31efc587ee 100644 --- a/Documentation/git-patch-id.txt +++ b/Documentation/git-patch-id.txt @@ -8,14 +8,14 @@ git-patch-id - Compute unique ID for a patch SYNOPSIS -------- [verse] -'git patch-id' < <patch> +'git patch-id' [--stable | --unstable] < <patch> DESCRIPTION ----------- -A "patch ID" is nothing but a SHA1 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. +A "patch ID" is nothing but a sum of SHA-1 of the file diffs 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. IOW, you can use this thing to look for likely duplicate commits. @@ -27,6 +27,33 @@ This can be used to make a mapping from patch ID to commit ID. OPTIONS ------- + +--stable:: + Use a "stable" sum of hashes as the patch ID. With this option: + - Reordering file diffs that make up a patch does not affect the ID. + In particular, two patches produced by comparing the same two trees + with two different settings for "-O<orderfile>" result in the same + patch ID signature, thereby allowing the computed result to be used + as a key to index some meta-information about the change between + the two trees; + + - Result is different from the value produced by git 1.9 and older + or produced when an "unstable" hash (see --unstable below) is + configured - even when used on a diff output taken without any use + of "-O<orderfile>", thereby making existing databases storing such + "unstable" or historical patch-ids unusable. + + This is the default if patchid.stable is set to true. + +--unstable:: + Use an "unstable" hash as the patch ID. With this option, + the result produced is compatible with the patch-id value produced + by git 1.9 and older. Users with pre-existing databases storing + patch-ids produced by git 1.9 and older (who do not deal with reordered + patches) may want to use this option. + + This is the default. + <patch>:: The diff to create the ID of. diff --git a/Documentation/git-peek-remote.txt b/Documentation/git-peek-remote.txt deleted file mode 100644 index 87ea3fb054..0000000000 --- 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 80dc022ede..9fed59a317 100644 --- a/Documentation/git-prune-packed.txt +++ b/Documentation/git-prune-packed.txt @@ -1,5 +1,5 @@ git-prune-packed(1) -===================== +=================== NAME ---- @@ -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 80d01b0571..7a493c80f7 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]. @@ -54,12 +56,12 @@ OPTIONS EXAMPLE ------- -To prune objects not used by your repository nor another that +To prune objects not used by your repository or another that 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 0f18ec891a..712ab4baed 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,26 @@ 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 set to preserve, rebase with the `--preserve-merges` option passed +to `git rebase` so that locally created merge commits will not be flattened. ++ +When false, merge the current branch into the upstream branch. + -See `pull.rebase`, `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 +225,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 +235,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 aede48877f..863c30c4c2 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -9,9 +9,11 @@ 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] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>] + [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] + [-u | --set-upstream] [--signed] + [--force-with-lease[=<refname>[:<expect>]]] + [--no-verify] [<repository> [<refspec>...]] DESCRIPTION ----------- @@ -23,6 +25,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 linkgit:git-config[1] for the meaning of `push.default`). + OPTIONS[[OPTIONS]] ------------------ @@ -33,11 +46,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 +57,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,16 +78,22 @@ 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. + Push all branches (i.e. refs under `refs/heads/`); cannot be + used with other <refspec>. + +--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 @@ -100,6 +124,26 @@ 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. This can also be specified + with configuration variable 'push.followTags'. For more + information, see 'push.followTags' in linkgit:git-config[1]. + + +--signed:: + GPG-sign the push request to update refs on the receiving + side, to allow it to be checked by the hooks and/or be + logged. See linkgit:git-receive-pack[1] for the details + on the receiving end. + +--[no-]atomic:: + Use an atomic transaction on the remote side if available. + Either all refs are updated, or on error, no refs are updated. + If the server does not support atomic pushes the push will fail. + --receive-pack=<git-receive-pack>:: --exec=<git-receive-pack>:: Path to the 'git-receive-pack' program on the remote @@ -107,30 +151,77 @@ 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 overrides this restriction if the current value of the +remote ref is 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 the remote ref is updated +only if the "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. ++ +`--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. - ---repo=<repository>:: - This option is only relevant if no <repository> argument is - passed in the invocation. In this case, 'git push' derives the - remote name from the current branch: If it tracks a remote - branch, then that remote repository is pushed to. Otherwise, - the name "origin" is used. For this latter case, this option - can be used to override the name "origin". In other words, - the difference between these two commands + 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. + --------------------------- -git push public #1 -git push --repo=public #2 --------------------------- +This flag disables these checks, and can cause the remote repository +to lose commits; use it with care. + -is that #1 always pushes to "public" whereas #2 pushes to "public" -only if the current branch does not track a remote branch. This is -useful if you write an alias or script around 'git push'. +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 equivalent to the <repository> argument. If both + are specified, the command-line argument takes precedence. -u:: --set-upstream:: @@ -139,8 +230,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,10 +252,21 @@ 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:: - Check whether all submodule commits used by the revisions to be - pushed are available on a remote tracking branch. Otherwise the - push will be aborted and the command will exit with non-zero status. +--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[] @@ -174,7 +275,7 @@ 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 @@ -196,7 +297,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 @@ -206,7 +307,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: + @@ -269,7 +370,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. @@ -282,7 +384,7 @@ will now start building on top of B. The command by default does not allow an update that is not a fast-forward to prevent such loss of history. -If you do not want to lose your work (history from X to B) nor the work by +If you do not want to lose your work (history from X to B) or the work by the other person (history from X to A), you would need to first fetch the history from the repository, create a history that contains changes done by both parties, and push the result back. @@ -339,11 +441,14 @@ Examples configured for the current branch). `git push origin`:: - Without additional configuration, works like - `git push origin :`. + Without additional configuration, pushes the current branch to + the configured upstream (`remote.origin.merge` configuration + variable) if it has the same name as the current branch, and + errors out without pushing otherwise. + 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 @@ -366,11 +471,23 @@ the ones in the examples below) can be configured as the default for 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`:: Push the current branch to the remote ref matching `master` in the @@ -388,7 +505,7 @@ the ones in the examples below) can be configured as the default for 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 7f112f3dcd..d64388cb8e 100644 --- a/Documentation/git-quiltimport.txt +++ b/Documentation/git-quiltimport.txt @@ -1,5 +1,5 @@ git-quiltimport(1) -================ +================== NAME ---- @@ -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 c4bde6509e..fa1d557e5b 100644 --- a/Documentation/git-read-tree.txt +++ b/Documentation/git-read-tree.txt @@ -57,7 +57,7 @@ OPTIONS -n:: --dry-run:: Check if the command would error out, without updating the index - nor the files in the working tree for real. + or the files in the working tree for real. -v:: Show the progress of checking files out. @@ -283,7 +283,7 @@ merge. The different stages represent the "result tree" (stage 0, aka you are trying to merge (stage 2 and 3 respectively). The order of stages 1, 2 and 3 (hence the order of three -<tree-ish> command line arguments) are significant when you +<tree-ish> command-line arguments) are significant when you start a 3-way merge with an index file that is already populated. Here is an outline of how the algorithm works: diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 504945c691..47984e84ed 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>] - [<upstream>] [<branch>] -'git rebase' [-i | --interactive] [options] --onto <newbase> +'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] + [<upstream> [<branch>]] +'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] --root [<branch>] -'git rebase' --continue | --skip | --abort +'git rebase' --continue | --skip | --abort | --edit-todo DESCRIPTION ----------- @@ -21,15 +21,17 @@ If <branch> is specified, 'git rebase' will perform an automatic it remains on the current branch. If <upstream> is not specified, the upstream configured in -branch.<name>.remote and branch.<name>.merge options will be used; see -linkgit:git-config[1] for details. If you are currently not on any -branch or if the current branch does not have a configured upstream, -the rebase will abort. +branch.<name>.remote and branch.<name>.merge options will be used (see +linkgit:git-config[1] for details) and the `--fork-point` option is +assumed. If you are currently not on any branch or if the current +branch does not have a configured upstream, the rebase will abort. All changes made by commits in the current branch but that are not in <upstream> are saved to a temporary area. This is the same set -of commits that would be shown by `git log <upstream>..HEAD` (or -`git log HEAD`, if --root is specified). +of commits that would be shown by `git log <upstream>..HEAD`; or by +`git log 'fork_point'..HEAD`, if `--fork-point` is active (see the +description on `--fork-point` below); or by `git log HEAD`, if the +`--root` option is specified. The current branch is reset to <upstream>, or <newbase> if the --onto option was supplied. This has the exact same effect as @@ -179,7 +181,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 @@ -205,12 +207,15 @@ rebase.stat:: Whether to show a diffstat of what changed upstream since the last rebase. False by default. -rebase.autosquash:: +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 +243,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 +279,13 @@ 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. + +-S[<keyid>]:: +--gpg-sign[=<keyid>]:: + GPG-sign commits. -q:: --quiet:: @@ -302,17 +318,29 @@ which makes little sense. -f:: --force-rebase:: - Force the rebase even if the current branch is a descendant - of the commit you are rebasing onto. Normally non-interactive rebase will - exit with the message "Current branch is up to date" in such a - situation. - Incompatible with the --interactive option. + Force a rebase even if the current branch is up-to-date and + the command without `--force` would return without doing anything. + 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 reflog to find a better common ancestor between <upstream> + and <branch> when calculating which commits have been + introduced by <branch>. ++ +When --fork-point is active, 'fork_point' will be used instead of +<upstream> to calculate the set of commits to rebase, where +'fork_point' is the result of `git merge-base --fork-point <upstream> +<branch>` command (see linkgit:git-merge-base[1]). If 'fork_point' +ends up being empty, the <upstream> will be used as a fallback. ++ +If either <upstream> or --root is given on the command line, then the +default is `--no-fork-point`, otherwise the default is `--fork-point`. --ignore-whitespace:: --whitespace=<option>:: @@ -334,20 +362,44 @@ link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details). -p:: --preserve-merges:: - Instead of ignoring merges, try to recreate them. + Recreate merge commits instead of flattening the history by replaying + commits a merge commit introduces. Merge conflict resolutions or manual + amendments to merge commits are not preserved. + 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,14 +409,23 @@ 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. + If the '--autosquash' option is enabled by default using the -configuration variable `rebase.autosquash`, this option can be +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 +436,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 +470,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 +578,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 +690,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 +727,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 +735,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 b1f7dc643a..000ee8dba2 100644 --- a/Documentation/git-receive-pack.txt +++ b/Documentation/git-receive-pack.txt @@ -53,6 +53,56 @@ the update. Refs to be created will have sha1-old equal to 0\{40}, while refs to be deleted will have sha1-new equal to 0\{40}, otherwise sha1-old and sha1-new should be valid objects in the repository. +When accepting a signed push (see linkgit:git-push[1]), the signed +push certificate is stored in a blob and an environment variable +`GIT_PUSH_CERT` can be consulted for its object name. See the +description of `post-receive` hook for an example. In addition, the +certificate is verified using GPG and the result is exported with +the following environment variables: + +`GIT_PUSH_CERT_SIGNER`:: + The name and the e-mail address of the owner of the key that + signed the push certificate. + +`GIT_PUSH_CERT_KEY`:: + The GPG key ID of the key that signed the push certificate. + +`GIT_PUSH_CERT_STATUS`:: + The status of GPG verification of the push certificate, + using the same mnemonic as used in `%G?` format of `git log` + family of commands (see linkgit:git-log[1]). + +`GIT_PUSH_CERT_NONCE`:: + The nonce string the process asked the signer to include + in the push certificate. If this does not match the value + recorded on the "nonce" header in the push certificate, it + may indicate that the certificate is a valid one that is + being replayed from a separate "git push" session. + +`GIT_PUSH_CERT_NONCE_STATUS`:: +`UNSOLICITED`;; + "git push --signed" sent a nonce when we did not ask it to + send one. +`MISSING`;; + "git push --signed" did not send any nonce header. +`BAD`;; + "git push --signed" sent a bogus nonce. +`OK`;; + "git push --signed" sent the nonce we asked it to send. +`SLOP`;; + "git push --signed" sent a nonce different from what we + asked it to send now, but in a previous session. See + `GIT_PUSH_CERT_NONCE_SLOP` environment variable. + +`GIT_PUSH_CERT_NONCE_SLOP`:: + "git push --signed" sent a nonce different from what we + asked it to send now, but in a different session whose + starting time is different by this many seconds from the + current session. Only meaningful when + `GIT_PUSH_CERT_NONCE_STATUS` says `SLOP`. + Also read about `receive.certNonceSlop` variable in + linkgit:git-config[1]. + This hook is called before any refname is updated and before any fast-forward checks are performed. @@ -101,9 +151,14 @@ the update. Refs that were created will have sha1-old equal to 0\{40}, otherwise sha1-old and sha1-new should be valid objects in the repository. +The `GIT_PUSH_CERT*` environment variables can be inspected, just as +in `pre-receive` hook, after accepting a signed push. + Using this hook, it is easy to generate mails describing the updates to the repository. This example script sends one mail message per -ref listing the commits pushed to the repository: +ref listing the commits pushed to the repository, and logs the push +certificates of signed pushes with good signatures to a logger +service: #!/bin/sh # mail out commit update information. @@ -119,6 +174,14 @@ ref listing the commits pushed to the repository: fi | mail -s "Changes to ref $ref" commit-list@mydomain done + # log signed push certificate, if any + if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G + then + ( + echo expected nonce is ${GIT_PUSH_NONCE} + git cat-file blob ${GIT_PUSH_CERT} + ) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain + fi exit 0 The exit code from this hook invocation is ignored, however a diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt index 976dc14937..5e7908e4f7 100644 --- a/Documentation/git-reflog.txt +++ b/Documentation/git-reflog.txt @@ -17,80 +17,113 @@ The command takes various subcommands, and different options depending on the subcommand: [verse] -'git reflog expire' [--dry-run] [--stale-fix] [--verbose] - [--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>... -'git reflog delete' ref@\{specifier\}... 'git reflog' ['show'] [log-options] [<ref>] +'git reflog expire' [--expire=<time>] [--expire-unreachable=<time>] + [--rewrite] [--updateref] [--stale-fix] + [--dry-run] [--verbose] [--all | <refs>...] +'git reflog delete' [--rewrite] [--updateref] + [--dry-run] [--verbose] ref@\{specifier\}... + +Reference logs, or "reflogs", record when the tips of branches and +other references were updated in the local repository. Reflogs are +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 in this local repository", and so on. See +linkgit:gitrevisions[7] for more details. + +This command manages the information recorded in the reflogs. + +The "show" subcommand (which is also the default, in the absence of +any subcommands) shows the log of the reference provided in the +command-line (or `HEAD`, by default). The reflog covers all recent +actions, and in addition the `HEAD` reflog records branch switching. +`git reflog show` is an alias for `git log -g --abbrev-commit +--pretty=oneline`; see linkgit:git-log[1] for more information. + +The "expire" subcommand prunes older reflog entries. Entries older +than `expire` time, or entries older than `expire-unreachable` time +and not reachable from the current tip, are removed from the reflog. +This is typically not used directly by end users -- instead, see +linkgit:git-gc[1]. + +The "delete" subcommand deletes single entries from the reflog. Its +argument must be an _exact_ entry (e.g. "`git reflog delete +master@{2}`"). This subcommand is also typically not used directly by +end users. -Reflog is a mechanism to record when the tip of branches are -updated. This command is to manage the information recorded in it. -The subcommand "expire" is used to prune older reflog entries. -Entries older than `expire` time, or entries older than -`expire-unreachable` time and not reachable from the current -tip, are removed from the reflog. This is typically not used -directly by the end users -- instead, see linkgit:git-gc[1]. - -The subcommand "show" (which is also the default, in the absence of any -subcommands) will take all the normal log options, and show the log of -the reference provided in the command-line (or `HEAD`, by default). -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]. +OPTIONS +------- -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. +Options for `show` +~~~~~~~~~~~~~~~~~~ -To delete single entries from the reflog, use the subcommand "delete" -and specify the _exact_ entry (e.g. "`git reflog delete master@\{2\}`"). +`git reflog show` accepts any of the options accepted by `git log`. -OPTIONS -------- +Options for `expire` +~~~~~~~~~~~~~~~~~~~~ ---stale-fix:: - This revamps the logic -- the definition of "broken commit" - becomes: a commit that is not reachable from any of the refs and - there is a missing object among the commit, tree, or blob - objects reachable from it that is not reachable from any of the - refs. -+ -This computation involves traversing all the reachable objects, i.e. it -has the same cost as 'git prune'. Fortunately, once this is run, we -should not have to ever worry about missing objects, because the current -prune and pack-objects know about reflogs and protect objects referred by -them. +--all:: + Process the reflogs of all references. --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. + Prune entries older than the specified time. If this option is + not specified, the expiration time is taken from the + configuration setting `gc.reflogExpire`, 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. - ---all:: - Instead of listing <refs> explicitly, prune all refs. + Prune entries older than `<time>` that are not reachable from + the current tip of the branch. If this option is not + specified, the expiration time is taken from the configuration + setting `gc.reflogExpireUnreachable`, which in turn defaults + to 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`). --updateref:: - Update the ref with the sha1 of the top reflog entry (i.e. - <ref>@\{0\}) after expiring or deleting. + Update the reference to the value of the top reflog entry (i.e. + <ref>@\{0\}) if the previous top entry was pruned. (This + option is ignored for symbolic references.) --rewrite:: - While expiring or deleting, adjust each reflog entry to ensure - that the `old` sha1 field points to the `new` sha1 field of the - previous entry. + If a reflog entry's predecessor is pruned, adjust its "old" + SHA-1 to be equal to the "new" SHA-1 field of the entry that + now precedes it. + +--stale-fix:: + Prune any reflog entries that point to "broken commits". A + broken commit is a commit that is not reachable from any of + the reference tips and that refers, directly or indirectly, to + a missing commit, tree, or blob object. ++ +This computation involves traversing all the reachable objects, i.e. it +has the same cost as 'git prune'. It is primarily intended to fix +corruption caused by garbage collecting using older versions of Git, +which didn't protect objects referred to by reflogs. + +-n:: +--dry-run:: + Do not actually prune any entries; just show what would have + been pruned. --verbose:: Print extra information on screen. + +Options for `delete` +~~~~~~~~~~~~~~~~~~~~ + +`git reflog delete` accepts options `--updateref`, `--rewrite`, `-n`, +`--dry-run`, and `--verbose`, with the same meanings as when they are +used with `expire`. + + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote-ext.txt b/Documentation/git-remote-ext.txt index 8a8e1d775d..b25d0b5996 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,10 +116,9 @@ 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> +SEE ALSO +-------- +linkgit:gitremote-helpers[1] GIT --- diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt index f095d57d09..e700bafa47 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 @@ -50,9 +50,9 @@ EXAMPLES `git push fd::7,8/bar master`:: Same as above. -Documentation --------------- -Documentation by Ilari Liusvaara and the git list <git@vger.kernel.org> +SEE ALSO +-------- +linkgit:gitremote-helpers[1] GIT --- diff --git a/Documentation/git-remote-helpers.txto b/Documentation/git-remote-helpers.txto new file mode 100644 index 0000000000..49233f5d26 --- /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 index 2a67d456a3..f791d73c05 100644 --- a/Documentation/git-remote-testgit.txt +++ b/Documentation/git-remote-testgit.txt @@ -19,11 +19,11 @@ 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.py'. +'git-remote-testgit'. SEE ALSO -------- -linkgit:git-remote-helpers[1] +linkgit:gitremote-helpers[1] GIT --- diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 5a8c5061f3..4c6d6de7b7 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -3,23 +3,23 @@ git-remote(1) NAME ---- -git-remote - manage set of tracked repositories +git-remote - Manage set of tracked repositories 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 @@ -58,6 +58,9 @@ remote repository. With `--no-tags` option, `git fetch <name>` does not import tags from the remote repository. + +By default, only tags on fetched branches are imported +(see linkgit:git-fetch[1]). ++ With `-t <branch>` option, instead of the default glob refspec for the remote to track all branches under the `refs/remotes/<name>/` namespace, a refspec to track only `<branch>` @@ -67,14 +70,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 +88,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 +104,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 @@ -129,17 +133,25 @@ branches, adds to that list. 'set-url':: -Changes URL remote points to. Sets first URL remote points to matching +Changes URLs for the remote. Sets first URL for remote <name> that matches regex <oldurl> (first URL if no <oldurl> is given) to <newurl>. If -<oldurl> doesn't match any URL, error occurs and nothing is changed. +<oldurl> doesn't match any URL, an error occurs and nothing is changed. + With '--push', push URLs are manipulated instead of fetch URLs. + -With '--add', instead of changing some URL, new URL is added. +With '--add', instead of changing existing URLs, new URL is added. ++ +With '--delete', instead of changing existing URLs, all URLs matching +regex <url> are deleted for remote <name>. Trying to delete all +non-push URLs is an error. + -With '--delete', instead of changing some URL, all URLs matching -regex <url> are deleted. Trying to delete all non-push URLs is an -error. +Note that the push URL and the fetch URL, even though they can +be set differently, must still refer to the same place. What you +pushed to the push URL should be what you would see if you +immediately fetched from the fetch URL. If you are trying to +fetch from one place (e.g. your upstream) and push to another (e.g. +your publishing repository), use two separate remotes. + 'show':: @@ -186,18 +198,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 40af321153..0e0bd363d6 100644 --- a/Documentation/git-repack.txt +++ b/Documentation/git-repack.txt @@ -9,12 +9,12 @@ git-repack - Pack unpacked objects in a repository SYNOPSIS -------- [verse] -'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [--window=<n>] [--depth=<n>] +'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [--window=<n>] [--depth=<n>] 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 @@ -110,6 +110,21 @@ other objects in that pack they already have locally. The default is unlimited, unless the config variable `pack.packSizeLimit` is set. +-b:: +--write-bitmap-index:: + Write a reachability bitmap index as part of the repack. This + only makes sense when used with `-a` or `-A`, as the bitmaps + must be able to refer to all reachable objects. This option + overrides the setting of `pack.writeBitmaps`. + +--pack-kept-objects:: + Include objects in `.keep` files when repacking. Note that we + still do not delete `.keep` packs after `pack-objects` finishes. + This means that we may duplicate objects, but this makes the + option safe to use when there are concurrent pushes or fetches. + This option is generally only useful if you are writing bitmaps + with `-b` or `pack.writeBitmaps`, as it ensures that the + bitmapped packfile has the necessary objects. Configuration ------------- diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt index 17df525275..8fff598fd6 100644 --- a/Documentation/git-replace.txt +++ b/Documentation/git-replace.txt @@ -9,21 +9,28 @@ SYNOPSIS -------- [verse] 'git replace' [-f] <object> <replacement> +'git replace' [-f] --edit <object> +'git replace' [-f] --graft <commit> [<parent>...] '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 +57,79 @@ 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. +--edit <object>:: + Edit an object's content interactively. The existing content + for <object> is pretty-printed into a temporary file, an + editor is launched on the file, and the result is parsed to + create a new object of the same type as <object>. A + replacement ref is then created to replace <object> with the + newly created object. See linkgit:git-var[1] for details about + how the editor will be chosen. + +--raw:: + When editing, provide the raw object contents rather than + pretty-printed ones. Currently this only affects trees, which + will be shown in their binary form. This is harder to work with, + but can help when repairing a tree that is so corrupted it + cannot be pretty-printed. Note that you may need to configure + your editor to cleanly read and write binary data. + +--graft <commit> [<parent>...]:: + Create a graft commit. A new commit is created with the same + content as <commit> except that its parents will be + [<parent>...] instead of <commit>'s parents. A replacement ref + is then created to replace <commit> with the newly created + commit. See contrib/convert-grafts-to-replace-refs.sh for an + example script based on this option that can convert grafts to + replace refs. + -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. The `--edit` option can +also be used with 'git replace' to create a replacement object by +editing an existing object. + +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,14 +138,17 @@ 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-commit[1] +linkgit:git-var[1] linkgit:git[1] GIT diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt deleted file mode 100644 index 9ec115b9e0..0000000000 --- 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-request-pull.txt b/Documentation/git-request-pull.txt index b99681ce85..283577b0b6 100644 --- a/Documentation/git-request-pull.txt +++ b/Documentation/git-request-pull.txt @@ -13,22 +13,65 @@ SYNOPSIS DESCRIPTION ----------- -Summarizes the changes between two commits to the standard output, and includes -the given URL in the generated summary. +Generate a request asking your upstream project to pull changes into +their tree. The request, printed to the standard output, summarizes +the changes and indicates from where they can be pulled. + +The upstream project is expected to have the commit named by +`<start>` and the output asks it to integrate the changes you made +since that commit, up to the commit named by `<end>`, by visiting +the repository named by `<url>`. + OPTIONS ------- -p:: - Show patch text + Include patch text in the output. <start>:: - Commit to start at. + Commit to start at. This names a commit that is already in + the upstream history. <url>:: - URL to include in the summary. + The repository URL to be pulled from. <end>:: - Commit to end at; defaults to HEAD. + Commit to end at (defaults to HEAD). This names the commit + at the tip of the history you are asking to be pulled. ++ +When the repository named by `<url>` has the commit at a tip of a +ref that is different from the ref you have locally, you can use the +`<local>:<remote>` syntax, to have its local name, a colon `:`, and +its remote name. + + +EXAMPLE +------- + +Imagine that you built your work on your `master` branch on top of +the `v1.0` release, and want it to be integrated to the project. +First you push that change to your public repository for others to +see: + + git push https://git.ko.xz/project master + +Then, you run this command: + + git request-pull v1.0 https://git.ko.xz/project master + +which will produce a request to the upstream, summarizing the +changes between the `v1.0` release and your `master`, to pull it +from your public repository. + +If you pushed your change to a branch whose name is different from +the one you have locally, e.g. + + git push https://git.ko.xz/project master:for-linus + +then you can ask that to be pulled with + + git request-pull v1.0 https://git.ko.xz/project master:for-linus + GIT --- diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt index a6253ba617..9ee083c415 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,34 +37,39 @@ 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 -`gc.rerereunresolved` and `gc.rerereresolved` configuration +`gc.rerereUnresolved` and `gc.rerereResolved` configuration variables respectively. @@ -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 b674866e6d..25432d9257 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' (--soft | --mixed | --hard | --merge | --keep) [-q] [<commit>] +'git reset' [-q] [<tree-ish>] [--] <paths>... +'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...] +'git reset' [--soft | --mixed [-N] | --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 or the current branch.) + This means that `git reset <paths>` is the opposite of `git add @@ -34,24 +34,24 @@ 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:: - Does not touch the index file nor the working tree at all (but + Does not touch the index file or the working tree at all (but resets the head to <commit>, just like all modes do). This leaves all your changed files "Changes to be committed", as 'git status' would put it. @@ -60,6 +60,9 @@ section of linkgit:git-add[1] to learn how to operate the `\--patch` mode. Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action. ++ +If `-N` is specified, removed paths are marked as intent-to-add (see +linkgit:git-add[1]). --hard:: Resets the index and working tree. Any changes to tracked files in the @@ -115,7 +118,7 @@ and changes with these files are distracting. <2> Somebody asks you to pull, and the changes sounds worthy of merging. <3> However, you already dirtied the index (i.e. your index does not match the HEAD commit). But you know the pull you are going -to make does not affect frotz.c nor filfre.c, so you revert the +to make does not affect frotz.c or filfre.c, so you revert the index changes for these two files. Your changes in working tree remain there. <4> Then you can pull and merge, leaving frotz.c and filfre.c diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt index 38fafcaa6b..5b119220bf 100644 --- a/Documentation/git-rev-list.txt +++ b/Documentation/git-rev-list.txt @@ -40,13 +40,14 @@ SYNOPSIS [ \--right-only ] [ \--cherry-mark ] [ \--cherry-pick ] - [ \--encoding[=<encoding>] ] + [ \--encoding=<encoding> ] [ \--(author|committer|grep)=<pattern> ] [ \--regexp-ignore-case | -i ] [ \--extended-regexp | -E ] [ \--fixed-strings | -F ] - [ \--date=(local|relative|default|iso|rfc|short) ] - [ [\--objects | \--objects-edge] [ \--unpacked ] ] + [ \--date=(local|relative|default|iso|iso-strict|rfc|short) ] + [ [ \--objects | \--objects-edge | \--objects-edge-aggressive ] + [ \--unpacked ] ] [ \--pretty | \--header ] [ \--bisect ] [ \--bisect-vars ] @@ -55,6 +56,7 @@ SYNOPSIS [ \--reverse ] [ \--walk-reflogs ] [ \--no-walk ] [ \--do-walk ] + [ \--use-bitmap-index ] <commit>... [ \-- <paths>... ] DESCRIPTION @@ -99,7 +101,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 8023dc086d..d6de42f74e 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,19 +71,50 @@ 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:: Only meaningful in `--verify` mode. Do not output an error message if the first argument is not a valid object name; instead exit with non-zero status silently. + SHA-1s for valid object names are printed to stdout on success. --sq:: Usually the output is made one line per flag and @@ -83,8 +130,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 +154,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 +169,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 + accumulated 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 +227,31 @@ 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. + +--shared-index-path:: + Show the path to the shared index file in split index mode, or + empty if not in split-index mode. + +Other Options +~~~~~~~~~~~~~ --since=datestring:: --after=datestring:: @@ -180,10 +266,6 @@ print a message to stderr and exit with nonzero status. <args>...:: Flags and parameters to be parsed. ---resolve-git-dir <path>:: - Check if <path> is a valid git-dir or a git-file pointing to a valid - git-dir. If <path> is a valid git-dir the resolved path to git-dir will - be printed. include::revisions.txt[] @@ -207,26 +289,28 @@ Input Format 'git rev-parse --parseopt' input format is fully text based. It has two parts, separated by a line that contains only `--`. The lines before the separator -(should be more than one) are used for the usage. +(should be one or more) are used for the usage. The lines after the separator describe the options. Each line of options has this format: ------------ -<opt_spec><flags>* SP+ help LF +<opt-spec><flags>*<arg-hint>? SP+ help LF ------------ -`<opt_spec>`:: +`<opt-spec>`:: its format is the short option character, then the long option name separated by a comma. Both parts are not required, though at least one is necessary. `h,help`, `dry-run` and `f` are all three correct - `<opt_spec>`. + `<opt-spec>`. `<flags>`:: `<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 @@ -234,6 +318,12 @@ Each line of options has this format: * Use `!` to not make the corresponding negated long option available. +`<arg-hint>`:: + `<arg-hint>`, if specified, is used as a name of the argument in the + help output, for options that take arguments. `<arg-hint>` is + terminated by the first whitespace. It is customary to use a + dash to separate words in a multi-word argument hint. + The remainder of the line, after stripping the spaces, is used as the help associated to the option. @@ -254,6 +344,8 @@ h,help show the help foo some nifty option --foo bar= some cool option --bar with an argument +baz=arg another cool option --baz with a named argument +qux?path qux may take a path argument but has meaning by itself An option group Header C? option C with an optional argument" @@ -261,6 +353,28 @@ C? option C with an optional argument" eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)" ------------ + +Usage text +~~~~~~~~~~ + +When `"$@"` is `-h` or `--help` in the above example, the following +usage text would be shown: + +------------ +usage: some-command [options] <args>... + + some-command does foo and bar! + + -h, --help show the help + --foo some nifty option --foo + --bar ... some cool option --bar with an argument + --baz <arg> another cool option --baz with a named argument + --qux[=<path>] qux may take a path argument but has meaning by itself + +An option group Header + -C[...] option C with an optional argument +------------ + SQ-QUOTE -------- @@ -300,12 +414,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 b699a3458e..cceb5f2f7f 100644 --- a/Documentation/git-revert.txt +++ b/Documentation/git-revert.txt @@ -8,7 +8,7 @@ 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] [-S[<key-id>]] <commit>... 'git revert' --continue 'git revert' --quit 'git revert' --abort @@ -27,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 @@ -59,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:: @@ -80,6 +80,10 @@ more details. This is useful when reverting more than one commits' effect to your index in a row. +-S[<key-id>]:: +--gpg-sign[=<key-id>]:: + GPG-sign commits. + -s:: --signoff:: Add Signed-off-by line at the end of the commit message. @@ -105,7 +109,7 @@ EXAMPLES 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 665ad4ddab..f1efc116eb 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,6 +134,27 @@ 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`:: @@ -142,7 +162,7 @@ EXAMPLES `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`:: @@ -150,6 +170,15 @@ of files and subdirectories under the `Documentation/` directory. (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 327233c85b..804554609d 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -20,7 +20,7 @@ files in the directory), or directly as a revision list. In the last case, any format accepted by linkgit:git-format-patch[1] can be passed to git send-email. -The header of the email is configurable by command line options. If not +The header of the email is configurable via command-line options. If not specified on the command line, the user will be prompted with a ReadLine enabled interface to provide the necessary information. @@ -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,17 +68,17 @@ 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. + -See the CONFIGURATION section for 'sendemail.multiedit'. +See the CONFIGURATION section for 'sendemail.multiEdit'. --from=<address>:: Specify the sender of the emails. If not specified on the command line, the value of the 'sendemail.from' configuration option is used. If - neither the command line option nor 'sendemail.from' are set, then the + neither the command-line option nor 'sendemail.from' are set, then the user will be prompted for the value. The default for the prompt will be the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not set, as returned by "git var -l". @@ -126,6 +127,25 @@ 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. + +--transfer-encoding=(7bit|8bit|quoted-printable|base64):: + Specify the transfer encoding to be used to send the message over SMTP. + 7bit will fail upon encountering a non-ASCII message. quoted-printable + can be useful when the repository contains files that contain carriage + returns, but makes the raw patch email file (as saved from a MUA) much + harder to inspect manually. base64 is even more fool proof, but also + even more opaque. Default is the value of the 'sendemail.transferEncoding' + configuration value; if that is unspecified, git will use 8bit and not + add a Content-Transfer-Encoding header. + +--xmailer:: +--no-xmailer:: + Add (or prevent adding) the "X-Mailer:" header. By default, + the header is added, but it can be turned off by setting the + `sendemail.xmailer` configuration variable to `false`. Sending ~~~~~~~ @@ -136,39 +156,39 @@ Sending subscribed to a list. In order to use the 'From' address, set the value to "auto". If you use the sendmail binary, you must have suitable privileges for the -f parameter. Default is the value of the - 'sendemail.envelopesender' configuration variable; if that is + 'sendemail.envelopeSender' configuration variable; if that is unspecified, choosing the envelope sender is left to your MTA. --smtp-encryption=<encryption>:: Specify the encryption to use, either 'ssl' or 'tls'. Any other value reverts to plain SMTP. Default is the value of - 'sendemail.smtpencryption'. + 'sendemail.smtpEncryption'. --smtp-domain=<FQDN>:: Specifies the Fully Qualified Domain Name (FQDN) used in the HELO/EHLO command to the SMTP server. Some servers require the FQDN to match your IP address. If not set, git send-email attempts to determine your FQDN automatically. Default is the value of - 'sendemail.smtpdomain'. + 'sendemail.smtpDomain'. --smtp-pass[=<password>]:: Password for SMTP-AUTH. The argument is optional: If no argument is specified, then the empty string is used as - the password. Default is the value of 'sendemail.smtppass', + the password. Default is the value of 'sendemail.smtpPass', however '--smtp-pass' always overrides this value. + 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. +'--smtp-user' or a 'sendemail.smtpUser'), but no password has been +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. `smtp.example.com` or a raw IP address). Alternatively it can specify a full pathname of a sendmail-like program instead; the program must support the `-i` option. Default value can - be specified by the 'sendemail.smtpserver' configuration + be specified by the 'sendemail.smtpServer' configuration option; the built-in default is `/usr/sbin/sendmail` or `/usr/lib/sendmail` if such program is available, or `localhost` otherwise. @@ -179,11 +199,11 @@ user is prompted for a password while the input is masked for privacy. submission port 587, or the common SSL smtp port 465); symbolic port names (e.g. "submission" instead of 587) are also accepted. The port can also be set with the - 'sendemail.smtpserverport' configuration variable. + 'sendemail.smtpServerPort' configuration variable. --smtp-server-option=<option>:: If set, specifies the outgoing SMTP server option to use. - Default value can be specified by the 'sendemail.smtpserveroption' + Default value can be specified by the 'sendemail.smtpServerOption' configuration option. + The --smtp-server-option option must be repeated for each option you want @@ -193,11 +213,26 @@ must be used for each option. --smtp-ssl:: Legacy alias for '--smtp-encryption ssl'. +--smtp-ssl-cert-path:: + Path to a store of trusted CA certificates for SMTP SSL/TLS + certificate validation (either a directory that has been processed + by 'c_rehash', or a single file containing one or more PEM format + certificates concatenated together: see verify(1) -CAfile and + -CApath for more information on these). Set it to an empty string + to disable certificate verification. Defaults to the value of the + 'sendemail.smtpsslcertpath' configuration variable, if set, or the + backing SSL library's compiled-in default otherwise (which should + be the best choice on most platforms). + --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'), + 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 ~~~~~~~~~~ @@ -212,14 +247,14 @@ Automating Specify a command to execute once per patch file which should generate patch file specific "Cc:" entries. Output of this command must be single email address per line. - Default is the value of 'sendemail.cccmd' configuration value. + Default is the value of 'sendemail.ccCmd' configuration value. --[no-]chain-reply-to:: If this is set, each email will be sent as a reply to the previous email sent. If disabled with "--no-chain-reply-to", all emails after the first will be sent as replies to the first email sent. When using this, it is recommended that the first file given be an overview of the - entire patch series. Disabled by default, but the 'sendemail.chainreplyto' + entire patch series. Disabled by default, but the 'sendemail.chainReplyTo' configuration variable can be used to enable it. --identity=<identity>:: @@ -233,6 +268,18 @@ Automating cc list. Default is the value of 'sendemail.signedoffbycc' configuration value; if that is unspecified, default to --signed-off-by-cc. +--[no-]cc-cover:: + If this is set, emails found in Cc: headers in the first patch of + the series (typically the cover letter) are added to the cc list + for each email set. Default is the value of 'sendemail.cccover' + configuration value; if that is unspecified, default to --no-cc-cover. + +--[no-]to-cover:: + If this is set, emails found in To: headers in the first patch of + the series (typically the cover letter) are added to the to list + for each email set. Default is the value of 'sendemail.tocover' + configuration value; if that is unspecified, default to --no-to-cover. + --suppress-cc=<category>:: Specify an additional category of recipients to suppress the auto-cc of: @@ -257,7 +304,7 @@ specified, as well as 'body' if --no-signed-off-cc is specified. --[no-]suppress-from:: If this is set, do not add the From: address to the cc: list. - Default is the value of 'sendemail.suppressfrom' configuration + Default is the value of 'sendemail.suppressFrom' configuration value; if that is unspecified, default to --no-suppress-from. --[no-]thread:: @@ -330,15 +377,15 @@ default to '--validate'. CONFIGURATION ------------- -sendemail.aliasesfile:: +sendemail.aliasesFile:: To avoid typing long email addresses, point this to one or more - email aliases files. You must also supply 'sendemail.aliasfiletype'. + email aliases files. You must also supply 'sendemail.aliasFileType'. -sendemail.aliasfiletype:: - Format of the file(s) specified in sendemail.aliasesfile. Must be +sendemail.aliasFileType:: + Format of the file(s) specified in sendemail.aliasesFile. Must be one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'. -sendemail.multiedit:: +sendemail.multiEdit:: If true (default), a single editor instance will be spawned to edit files you have to edit (patches when '--annotate' is used, and the summary when '--compose' is used). If false, files will be edited one @@ -357,10 +404,10 @@ To use 'git send-email' to send your patches through the GMail SMTP server, edit ~/.gitconfig to specify your account settings: [sendemail] - smtpencryption = tls - smtpserver = smtp.gmail.com - smtpuser = yourname@gmail.com - smtpserverport = 587 + smtpEncryption = tls + smtpServer = smtp.gmail.com + smtpUser = yourname@gmail.com + smtpServerPort = 587 Once your commits are ready to be sent to the mailing list, run the following commands: diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt index bd3eaa69bf..45c7725dc3 100644 --- a/Documentation/git-send-pack.txt +++ b/Documentation/git-send-pack.txt @@ -3,13 +3,13 @@ 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 -------- [verse] -'git send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...] +'git send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [--atomic] [<host>:]<directory> [<ref>...] DESCRIPTION ----------- @@ -35,6 +35,16 @@ OPTIONS Instead of explicitly specifying which refs to update, update all heads that locally exist. +--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. + --dry-run:: Do everything except actually send the updates. @@ -52,6 +62,11 @@ OPTIONS Send a "thin" pack, which records objects in deltified form based on objects not included in the pack to reduce network traffic. +--atomic:: + Use an atomic transaction for updating the refs. If any of the refs + fails to update then the entire push will fail without changing any + refs. + <host>:: A remote host to house the repository. When this part is specified, 'git-receive-pack' is invoked via @@ -77,7 +92,8 @@ this flag. Without '--all' and without any '<ref>', the heads that exist both on the local side and on the remote side are updated. -When one or more '<ref>' are specified explicitly, it can be either a +When one or more '<ref>' are specified explicitly (whether on the +command line or via `--stdin`), it can be either a single pattern, or a pair of such pattern separated by a colon ":" (this means that a ref name cannot have a colon in it). A single pattern '<name>' is just a shorthand for '<name>:<name>'. diff --git a/Documentation/git-sh-i18n--envsubst.txt b/Documentation/git-sh-i18n--envsubst.txt index 5c3ec327bb..2ffaf9392e 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 5e5f1c8964..4f67c4cde6 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 @@ -82,6 +84,12 @@ 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 9b9250600f..e4bdd2235c 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. + +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. -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. +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 ff3755b4c7..31af7f2736 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 a8e77b5350..b91d4e545b 100644 --- a/Documentation/git-show-branch.txt +++ b/Documentation/git-show-branch.txt @@ -25,13 +25,13 @@ and/or refs/tags) semi-visually. It cannot show more than 29 branches and commits at a time. It uses `showbranch.default` multi-valued configuration items if -no <rev> nor <glob> is given on the command line. +no <rev> or <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 2dcbbb2454..fbdc8adae5 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 fcee0008a9..2a6f89b235 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,14 +34,14 @@ 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:: @@ -50,8 +52,8 @@ OPTIONS -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,7 +75,7 @@ OPTIONS --exclude-existing[=<pattern>]:: Make 'git show-ref' act as a filter that reads refs from stdin of the - form "`{caret}(?:<anything>\s)?<refname>(?:{backslash}{caret}{})?$`" + form "`^(?:<anything>\s)?<refname>(?:\^{})?$`" and performs the following actions on each: (1) strip "{caret}{}" at the end of line if any; (2) ignore if pattern is provided and does not head-match refname; @@ -87,7 +89,7 @@ OPTIONS Show references matching one or more patterns. Patterns are matched from the end of the full name, and only complete parts are matched, e.g. 'master' matches 'refs/heads/master', 'refs/remotes/origin/master', - 'refs/tags/jedi/master' but not 'refs/heads/mymaster' nor + 'refs/tags/jedi/master' but not 'refs/heads/mymaster' or 'refs/remotes/master/jedi'. OUTPUT @@ -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 1e38819e67..4e617e6979 100644 --- a/Documentation/git-show.txt +++ b/Documentation/git-show.txt @@ -45,6 +45,15 @@ include::pretty-options.txt[] include::pretty-formats.txt[] +COMMON DIFF OPTIONS +------------------- + +:git-log: 1 +include::diff-options.txt[] + +include::diff-generate-patch.txt[] + + EXAMPLES -------- @@ -52,10 +61,10 @@ EXAMPLES 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`. diff --git a/Documentation/git-stage.txt b/Documentation/git-stage.txt index ba3fe0d7f5..25bcda936d 100644 --- a/Documentation/git-stage.txt +++ b/Documentation/git-stage.txt @@ -1,5 +1,5 @@ git-stage(1) -============== +============ NAME ---- diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index 43af38aa4b..375213fe46 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -13,10 +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 [--patch] [-k|--[no-]keep-index] [-q|--quiet] +'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 ----------- @@ -36,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] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]:: +save [-p|--patch] [-k|--[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 @@ -66,7 +67,7 @@ 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. @@ -74,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. @@ -93,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>]:: @@ -111,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>]:: @@ -143,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 3d51717bbe..5221f950ce 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,40 @@ 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. + +-v:: +--verbose:: + In addition to the names of files that have been changed, also + show the textual changes that are staged to be committed + (i.e., like the output of `git diff --cached`). If `-v` is specified + twice, then also show the changes in the working tree that + have not yet been staged (i.e., like the output of `git diff`). + -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]. @@ -68,7 +85,7 @@ configuration variable documented in linkgit:git-config[1]. only changes to the commits stored in the superproject are shown (this was the behavior before 1.7.0). Using "all" hides all changes to submodules (and suppresses the output of submodule summaries when the config option - `status.submodulesummary` is set). + `status.submoduleSummary` is set). --ignored:: Show ignored files as well. @@ -77,16 +94,23 @@ 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 ------ The output from this command is designed to be used as a commit -template comment, and all the output lines are prefixed with '#'. +template comment. 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,18 +122,18 @@ 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 +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 interior special characters backslash-escaped. -For paths with merge conflicts, `X` and 'Y' show the modification +For paths with merge conflicts, `X` and `Y` show the modification states of each side of the merge. For paths that do not have merge conflicts, `X` shows the status of the index, and `Y` shows the status of the work tree. For untracked paths, `XY` are `??`. Other status @@ -158,7 +182,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 +201,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 ------------- @@ -191,10 +215,16 @@ If the config variable `status.relativePaths` is set to false, then all paths shown are relative to the repository root, not to the current directory. -If `status.submodulesummary` is set to a non zero number or true (identical +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 a80d94650d..6c6e989074 100644 --- a/Documentation/git-stripspace.txt +++ b/Documentation/git-stripspace.txt @@ -10,11 +10,12 @@ SYNOPSIS -------- [verse] 'git stripspace' [-s | --strip-comments] < input +'git stripspace' [-c | --comment-lines] < input DESCRIPTION ----------- -Clean the input in the manner used by 'git' for text such as commit +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: @@ -35,7 +36,13 @@ OPTIONS ------- -s:: --strip-comments:: - Skip and remove all 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 -------- diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index b72964947a..2c25916f8f 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -9,16 +9,18 @@ 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] deinit [-f|--force] [--] <path>... +'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] + [-f|--force] [--rebase|--merge] [--reference <repository>] + [--depth <depth>] [--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>...] +'git submodule' [--quiet] sync [--recursive] [--] [<path>...] DESCRIPTION @@ -43,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'). @@ -75,6 +77,8 @@ 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 ./ @@ -91,7 +95,7 @@ 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. @@ -112,7 +116,6 @@ 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 submodules, and show their status as well. @@ -123,8 +126,10 @@ 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`. @@ -135,24 +140,65 @@ 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`, `merge` or `none`. + +-- +Update the registered submodules to match what the superproject +expects by cloning missing submodules and updating the working tree of +the submodules. The "updating" can be done in several ways depending +on command line options and the value of `submodule.<name>.update` +configuration variable. Supported update procedures are: + + checkout;; the commit recorded in the superproject will be + checked out in the submodule on a detached HEAD. This is + done when `--checkout` option is given, or no option is + given, and `submodule.<name>.update` is unset, or if it is + set to 'checkout'. ++ +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. + + rebase;; the current branch of the submodule will be rebased + onto the commit recorded in the superproject. This is done + when `--rebase` option is given, or no option is given, and + `submodule.<name>.update` is set to 'rebase'. + + merge;; the commit recorded in the superproject will be merged + into the current branch in the submodule. This is done + when `--merge` option is given, or no option is given, and + `submodule.<name>.update` is set to 'merge'. + + custom command;; arbitrary shell command that takes a single + argument (the sha1 of the commit recorded in the + superproject) is executed. This is done when no option is + given, and `submodule.<name>.update` has the form of + '!command'. + +When no option is given and `submodule.<name>.update` is set to 'none', +the submodule is not updated. + 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. -+ + If `--recursive` is specified, this command will recurse into the registered submodules, and update any nested submodules within. -+ -If the configuration key `submodule.$name.update` is set to `none` the -submodule with name `$name` will not be updated by default. This can be -overriden by adding `--checkout` to the command. - +-- summary:: Show commit summary between the given commit (defaults to HEAD) and working tree/index. For a submodule in question, a series of commits @@ -190,7 +236,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. @@ -207,13 +253,21 @@ OPTIONS -b:: --branch:: Branch of repository to add as submodule. + The name of the branch is recorded as `submodule.<name>.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 update, throw away local changes in submodules when - switching to a different commit. + When running deinit the submodule work trees will be removed even if + they contain local changes. + When running update (only effective with the checkout procedure), + throw away local changes in submodules when 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 @@ -233,11 +287,51 @@ 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`. ++ +Use this option to integrate changes from the upstream subproject with +your submodule's current HEAD. Alternatively, you can run `git pull` +from the submodule, which is equivalent except for the remote branch +name: `update --remote` uses the default upstream repository and +`submodule.<name>.branch`, while `git pull` uses the submodule's +`branch.<name>.merge`. Prefer `submodule.<name>.branch` if you want +to distribute the default upstream branch with the superproject and +`branch.<name>.merge` if you want a more native feel while working in +the submodule itself. + -N:: --no-fetch:: This option is only valid for the update command. Don't fetch new objects from the remote site. +--checkout:: + This option is only valid for the update command. + Checkout the commit recorded in the superproject on a detached HEAD + in the submodule. This is the default behavior, the main use of + this option is to override `submodule.$name.update` when set to + a value other than `checkout`. + If the key `submodule.$name.update` is either not explicitly set or + set to `checkout`, this option is implicit. + --merge:: This option is only valid for the update command. Merge the commit recorded in the superproject into the current branch @@ -262,6 +356,11 @@ OPTIONS 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, @@ -276,6 +375,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 34ee785064..39e9a181cc 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 @@ -70,8 +70,8 @@ COMMANDS --username=<user>;; For transports that SVN handles authentication for (http, https, and plain svn), specify the username. For other - transports (eg svn+ssh://), you must include the username in - the URL, eg svn+ssh://foo@svn.bar.com/project + transports (e.g. svn+ssh://), you must include the username in + the URL, e.g. svn+ssh://foo@svn.bar.com/project --prefix=<prefix>;; This allows one to specify a prefix which is prepended to the names of remotes if trunk/branches/tags are @@ -79,12 +79,30 @@ 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. + By default, the prefix is set to 'origin/'. ++ +NOTE: Before Git v2.0, the default prefix was "" (no prefix). This +meant that SVN-tracking refs were put at "refs/remotes/*", which is +incompatible with how Git's own remote-tracking refs are organized. +If you still want the old default, you can get it by passing +`--prefix ""` on the command line (`--prefix=""` may not work if +your Perl's Getopt::Long is < v2.37). + --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 +118,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. @@ -127,8 +148,8 @@ the same local timezone. [verse] config key: svn-remote.<name>.ignore-paths + -If the ignore-paths config key is set and the command line option is -also given, both regular expressions will be used. +If the ignore-paths configuration key is set, and the command-line +option is also given, both regular expressions will be used. + Examples: + @@ -146,6 +167,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; @@ -182,6 +218,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;; @@ -189,18 +228,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. @@ -215,6 +252,10 @@ and have no uncommitted changes. config key: svn-remote.<name>.commiturl config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options) + +Note that the SVN URL of the commiturl config key includes the SVN branch. +If you rather want to set the commit URL for an entire SVN repository use +svn-remote.<name>.pushurl instead. ++ Using this option for any other purpose (don't ask) is very strongly discouraged. @@ -239,8 +280,8 @@ first have already been pushed into 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 if "no" or "quit", without - commiting anything to SVN. + 'git svn dcommit' returns immediately if answer is "no" or "quit", without + committing anything to SVN. 'branch':: Create a branch in the SVN repository. @@ -254,13 +295,15 @@ first have already been pushed into SVN. 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 @@ -281,6 +324,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'. @@ -311,7 +359,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 -- @@ -323,24 +371,36 @@ 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 tree 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. ++ +-B;; +--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. ++ +-A;; +--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. @@ -363,7 +423,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 @@ -401,8 +461,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. @@ -415,9 +475,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>;; @@ -495,9 +556,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 @@ -553,25 +614,12 @@ config key: svn.authorsfile Make 'git svn' less verbose. Specify a second time to make it even less verbose. ---repack[=<n>]:: ---repack-flags=<flags>:: - These should help keep disk usage sane for large fetches with - many revisions. -+ ---repack takes an optional argument for the number of revisions -to fetch before repacking. This defaults to repacking every -1000 commits fetched if no argument is specified. -+ ---repack-flags are passed directly to 'git repack'. -+ -[verse] -config key: svn.repack -config key: svn.repackflags - -m:: --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 @@ -582,7 +630,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 @@ -593,14 +641,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. @@ -621,10 +669,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] @@ -639,7 +696,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 @@ -648,7 +705,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 @@ -688,7 +745,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 @@ -732,7 +789,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): @@ -741,15 +799,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 ------------------------------------------------------------------------ @@ -757,15 +815,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. ------------------------------------------------------------------------ @@ -779,7 +839,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 @@ -787,31 +847,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 -------------- @@ -819,22 +881,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. @@ -853,7 +961,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. @@ -863,12 +971,27 @@ 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 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/* @@ -879,18 +1002,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 @@ -919,14 +1048,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 a45d4c4f29..ef68ad2b71 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. diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 53ff5f6cf7..f5b267e1e3 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,7 +33,7 @@ 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 @@ -41,6 +42,17 @@ committer identity for the current user is used to find the 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 ------- @@ -83,8 +95,31 @@ OPTIONS 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. +--sort=<type>:: + Sort in a specific order. Supported type is "refname" + (lexicographic order), "version:refname" or "v:refname" (tag + names are treated as versions). The "version:refname" sort + order can also be affected by the + "versionsort.prereleaseSuffix" configuration variable. Prepend + "-" to reverse sort order. When this option is not given, the + sort order defaults to the value configured for the 'tag.sort' + variable if it exists, or lexicographic order otherwise. See + linkgit:git-config[1]. + +--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>:: @@ -114,16 +149,22 @@ OPTIONS 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: ------------------------------------- [user] - signingkey = <gpg-key-id> + signingKey = <gpg-key-id> ------------------------------------- @@ -230,7 +271,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 @@ -281,6 +322,7 @@ include::date-formats.txt[] SEE ALSO -------- linkgit:git-check-ref-format[1]. +linkgit:git-config[1]. GIT --- diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt deleted file mode 100644 index 346e7a2079..0000000000 --- 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 a96403cb8c..78a0d955ec 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 ff23494e70..12cb108b85 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 a3081f4e23..aff01798cd 100644 --- a/Documentation/git-update-index.txt +++ b/Documentation/git-update-index.txt @@ -12,14 +12,14 @@ SYNOPSIS 'git update-index' [--add] [--remove | --force-remove] [--replace] [--refresh] [-q] [--unmerged] [--ignore-missing] - [(--cacheinfo <mode> <object> <file>)...] + [(--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>...] @@ -68,8 +68,12 @@ OPTIONS --ignore-missing:: Ignores missing files during a --refresh +--cacheinfo <mode>,<object>,<path>:: --cacheinfo <mode> <object> <path>:: - Directly insert the specified info into the index. + Directly insert the specified info into the index. For + backward compatibility, you can also give these three + arguments as three separate parameters, but new users are + encouraged to use a single-parameter form. --index-info:: Read index information from stdin. @@ -77,22 +81,19 @@ OPTIONS --chmod=(+|-)x:: Set the execute permissions on the updated files. ---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 - 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 +--[no-]assume-unchanged:: + When this flag is specified, the object names recorded + for the paths are not updated. Instead, this option + sets/unsets the "assume unchanged" bit for the + paths. When the "assume unchanged" bit is on, the user + promises not to change the file and allows Git to assume + that the working tree file matches what is recorded in + the index. If you want to change the working tree file, + you need to unset the bit to tell Git. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs). + -This option can be also used as a coarse file-level mechanism -to ignore uncommitted changes in tracked files (akin to what -`.gitignore` does for untracked files). Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, @@ -102,8 +103,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,10 +143,33 @@ 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. +--split-index:: +--no-split-index:: + Enable or disable split index mode. If enabled, the index is + split into two files, $GIT_DIR/index and $GIT_DIR/sharedindex.<SHA-1>. + Changes are accumulated in $GIT_DIR/index while the shared + index file contains all index entries stays unchanged. If + split-index mode is already enabled and `--split-index` is + given again, all changes in $GIT_DIR/index are pushed back to + the shared index file. This mode is designed for very large + indexes that take a significant amount of time to read or write. + \--:: Do not interpret any more arguments as options. @@ -177,7 +200,7 @@ merging. To pretend you have a file with mode and sha1 at path, say: ---------------- -$ git update-index --cacheinfo mode sha1 path +$ git update-index --cacheinfo <mode>,<sha1>,<path> ---------------- '--info-only' is used to register files without placing them in the object @@ -235,7 +258,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 +272,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 +293,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 d377a35243..c8f5ae5cb3 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,64 @@ 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; i.e., surrounded by double-quotes and with backslash escapes. +Use 40 "0" characters or the empty string to specify a zero value. To +specify a missing value, omit the value and its preceding SP entirely. + +Alternatively, use `-z` to specify in NUL-terminated format, 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 + +In this format, use 40 "0" to specify a zero value, and use the empty +string to specify a missing value. + +In either format, values can be specified in any form that Git +recognizes as an object name. Commands in 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. + +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 +131,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 4d52d3833a..cbef61ba88 100644 --- a/Documentation/git-upload-archive.txt +++ b/Documentation/git-upload-archive.txt @@ -14,12 +14,44 @@ 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 is meant to be used to get an archive from a remote repository. +SECURITY +-------- + +In order to protect the privacy of objects that have been removed from +history but may not yet have been pruned, `git-upload-archive` avoids +serving archives for commits and trees that are not reachable from the +repository's refs. However, because calculating object reachability is +computationally expensive, `git-upload-archive` implements a stricter +but easier-to-check set of rules: + + 1. Clients may request a commit or tree that is pointed to directly by + a ref. E.g., `git archive --remote=origin v1.0`. + + 2. Clients may request a sub-tree within a commit or tree using the + `ref:path` syntax. E.g., `git archive --remote=origin v1.0:Documentation`. + + 3. Clients may _not_ use other sha1 expressions, even if the end + result is reachable. E.g., neither a relative commit like `master^` + nor a literal sha1 like `abcd1234` is allowed, even if the result + is reachable from the refs. + +Note that rule 3 disallows many cases that do not have any privacy +implications. These rules are subject to change in future versions of +git, and the server accessed by `git archive --remote` may or may not +follow these exact rules. + +If the config option `uploadArchive.allowUnreachable` is true, these +rules are ignored, and clients may use arbitrary sha1 expressions. +This is useful if you do not care about the privacy of unreachable +objects, or if your object database is already publicly available for +access via non-smart-http. + OPTIONS ------- <directory>:: diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt index 71f16083d6..0abc806ea9 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. diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt index 5317cc2474..44ff9541df 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-commit.txt b/Documentation/git-verify-commit.txt new file mode 100644 index 0000000000..9413e2802a --- /dev/null +++ b/Documentation/git-verify-commit.txt @@ -0,0 +1,28 @@ +git-verify-commit(1) +==================== + +NAME +---- +git-verify-commit - Check the GPG signature of commits + +SYNOPSIS +-------- +[verse] +'git verify-commit' <commit>... + +DESCRIPTION +----------- +Validates the gpg signature created by 'git commit -S'. + +OPTIONS +------- +-v:: +--verbose:: + Print the contents of the commit object before validating it. + +<commit>...:: + SHA-1 identifiers of Git commit objects. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt index cd230769fd..526ba7be9c 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 5ff76e892a..f88ba96f02 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 c2bc87bc61..16ede5b4c3 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 @@ -60,7 +62,7 @@ CONF.VAR (from -c option) and web.browser ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The web browser can be specified using a configuration variable passed -with the -c (or --config) command line option, or the 'web.browser' +with the -c (or --config) command-line option, or the 'web.browser' configuration variable if the former is not used. browser.<tool>.path @@ -85,7 +87,7 @@ the URLs passed as arguments. Note about konqueror -------------------- -When 'konqueror' is specified by a command line option or a +When 'konqueror' is specified by a command-line option or a configuration variable, we launch 'kfmclient' to try to open the HTML man page on an already opened konqueror in a new tab if possible. diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt index 76c7f7eec5..8b63ceb00e 100644 --- a/Documentation/git-whatchanged.txt +++ b/Documentation/git-whatchanged.txt @@ -13,43 +13,17 @@ 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 -------- @@ -58,7 +32,7 @@ Examples 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 a12d15fb98..c71e818cf4 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] +'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>] - [-c <name>=<value>] - [--help] <command> [<args>] + <command> [<args>] DESCRIPTION ----------- @@ -22,46 +22,195 @@ 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. +linkgit:giteveryday[7] 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 the 'master' branch of the `git.git` repository. Documentation for older releases are available here: -* link:v1.7.9.1/git.html[documentation for release 1.7.9.1] +* link:v2.4.0/git.html[documentation for release 2.4] * release notes for + link:RelNotes/2.4.0.txt[2.4]. + +* link:v2.3.7/git.html[documentation for release 2.3.7] + +* release notes for + link:RelNotes/2.3.7.txt[2.3.7], + link:RelNotes/2.3.6.txt[2.3.6], + link:RelNotes/2.3.5.txt[2.3.5], + link:RelNotes/2.3.4.txt[2.3.4], + link:RelNotes/2.3.3.txt[2.3.3], + link:RelNotes/2.3.2.txt[2.3.2], + link:RelNotes/2.3.1.txt[2.3.1], + link:RelNotes/2.3.0.txt[2.3]. + +* link:v2.2.2/git.html[documentation for release 2.2.2] + +* release notes for + link:RelNotes/2.2.2.txt[2.2.2], + link:RelNotes/2.2.1.txt[2.2.1], + link:RelNotes/2.2.0.txt[2.2]. + +* link:v2.1.4/git.html[documentation for release 2.1.4] + +* release notes for + link:RelNotes/2.1.4.txt[2.1.4], + link:RelNotes/2.1.3.txt[2.1.3], + link:RelNotes/2.1.2.txt[2.1.2], + link:RelNotes/2.1.1.txt[2.1.1], + link:RelNotes/2.1.0.txt[2.1]. + +* link:v2.0.5/git.html[documentation for release 2.0.5] + +* release notes for + link:RelNotes/2.0.5.txt[2.0.5], + link:RelNotes/2.0.4.txt[2.0.4], + link:RelNotes/2.0.3.txt[2.0.3], + link:RelNotes/2.0.2.txt[2.0.2], + link:RelNotes/2.0.1.txt[2.0.1], + link:RelNotes/2.0.0.txt[2.0.0]. + +* link:v1.9.5/git.html[documentation for release 1.9.5] + +* release notes for + link:RelNotes/1.9.5.txt[1.9.5], + link:RelNotes/1.9.4.txt[1.9.4], + link:RelNotes/1.9.3.txt[1.9.3], + link:RelNotes/1.9.2.txt[1.9.2], + link:RelNotes/1.9.1.txt[1.9.1], + link:RelNotes/1.9.0.txt[1.9.0]. + +* link:v1.8.5.6/git.html[documentation for release 1.8.5.6] + +* release notes for + link:RelNotes/1.8.5.6.txt[1.8.5.6], + 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.4/git.html[documentation for release 1.7.8.4] +* 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.6/git.html[documentation for release 1.7.7.6] +* 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], @@ -302,12 +451,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 @@ -315,29 +464,48 @@ 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. The <name> is expected in the same format as listed by 'git config' (subkeys separated by dots). ++ +Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets +`foo.bar` to the boolean true value (just like `[foo]bar` would in a +config file). Including the equals but with an empty value (like `git -c +foo.bar= ...`) sets `foo.bar` to the empty string. --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:: @@ -347,7 +515,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 @@ -363,7 +531,7 @@ help ...`. more detailed discussion). --namespace=<path>:: - Set the git namespace. See linkgit:gitnamespaces[7] for more + Set the Git namespace. See linkgit:gitnamespaces[7] for more details. Equivalent to setting the `GIT_NAMESPACE` environment variable. @@ -373,32 +541,34 @@ help ...`. 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. - -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. +--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)" -See also the link:howto-index.html[howto] documents for some useful -examples. +--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)" -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) @@ -435,7 +605,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 @@ -493,10 +663,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: ------------ # @@ -511,13 +680,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 @@ -556,7 +725,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:: @@ -592,19 +761,25 @@ 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 index file. If not specified, the default of `$GIT_DIR/index` is used. +'GIT_INDEX_VERSION':: + This environment variable allows the specification of an index + version for new repositories. It won't affect existing index + files. By default index file version 2 or 3 is used. See + linkgit:git-update-index[1] for more information. + 'GIT_OBJECT_DIRECTORY':: If the object storage directory is specified via this environment variable then the sha1 directories are created @@ -612,47 +787,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). - This can also be controlled by the '--work-tree' command line + 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. + 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':: @@ -663,13 +844,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 @@ -683,7 +864,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 @@ -694,6 +875,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 ~~~~~ @@ -704,65 +894,168 @@ 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. +'GIT_SSH_COMMAND':: + If either of these environment variables is set then 'git fetch' + and 'git push' will use the specified command instead of 'ssh' + when they need to connect to a remote system. + The 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, -then set GIT_SSH to refer to the shell script. +`$GIT_SSH_COMMAND` takes precedence over `$GIT_SSH`, and is interpreted +by the shell, which allows additional arguments to be included. +`$GIT_SSH` on the other hand must be just the path to a program +(which can be a wrapper shell script, if additional arguments are +needed). + Usually it is easier to configure any desired options through your 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' + 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_TERMINAL_PROMPT':: + If this environment variable is set to `0`, git will not prompt + on the terminal (e.g., when asking for HTTP authentication). + +'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 - 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 - 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 - as a file path and will try to write the trace messages - into it. + Enables general trace messages, e.g. alias expansion, built-in + command execution and external command execution. ++ +If this variable is set to "1", "2" or "true" (comparison +is case insensitive), trace messages will be printed to +stderr. ++ +If the variable is set to an integer value greater than 2 +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 the variable is set to an absolute path +(starting with a '/' character), Git will interpret this +as a file path and will try to write the trace messages +into it. ++ +Unsetting the variable, or setting it to empty, "0" or +"false" (case insensitive) disables trace messages. + +'GIT_TRACE_PACK_ACCESS':: + Enables trace messages for 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. + See 'GIT_TRACE' for available trace output options. + +'GIT_TRACE_PACKET':: + Enables trace messages for 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". + See 'GIT_TRACE' for available trace output options. + +'GIT_TRACE_PERFORMANCE':: + Enables performance related trace messages, e.g. total execution + time of each Git command. + See 'GIT_TRACE' for available trace output options. + +'GIT_TRACE_SETUP':: + Enables trace messages printing the .git, working tree and current + working directory after Git has completed its setup phase. + See 'GIT_TRACE' for available trace output options. + +'GIT_TRACE_SHALLOW':: + Enables trace messages that can help debugging fetching / + cloning of shallow repositories. + See 'GIT_TRACE' for available trace output options. + +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. + +`GIT_REF_PARANOIA`:: + If set to `1`, include broken or badly named refs when iterating + over lists of refs. In a normal, non-corrupted repository, this + does nothing. However, enabling it may help git to detect and + abort some operations in the presence of broken refs. Git sets + this variable automatically when performing destructive + operations like linkgit:git-prune[1]. You should not need to set + it yourself unless you want to be paranoid about making sure + an operation has touched every ref (e.g., because you are + cloning a repository to make a backup). + 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 @@ -779,7 +1072,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 @@ -789,9 +1082,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. @@ -808,12 +1101,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.openhub.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. @@ -827,7 +1145,7 @@ subscribed to the list to send a message there. SEE ALSO -------- linkgit:gittutorial[7], linkgit:gittutorial-2[7], -link:everyday.html[Everyday Git], linkgit:gitcvs-migration[7], +linkgit:giteveryday[7], linkgit:gitcvs-migration[7], linkgit:gitglossary[7], linkgit:gitcore-tutorial[7], linkgit:gitcli[7], link:user-manual.html[The Git User's Manual], linkgit:gitworkflows[7] diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index a85b187e04..70899b3023 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 @@ -74,7 +80,9 @@ Attributes which should be version-controlled and distributed to other 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]). +`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). -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. +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. + +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:: @@ -411,8 +440,8 @@ Unspecified:: A path to which the `diff` attribute is unspecified first gets its contents inspected, and if it looks like - text, it is treated as text. Otherwise it would - generate `Binary files differ`. + text and is smaller than core.bigFileThreshold, it is treated + as text. Otherwise it would generate `Binary files differ`. String:: @@ -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. @@ -575,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: @@ -588,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 @@ -609,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: @@ -619,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 @@ -634,7 +665,7 @@ data by examining the beginning of the contents. However, sometimes you may want to override its decision, either because a blob contains binary data later in the file, or because the content, while technically composed of text characters, is opaque to a human reader. For example, -many postscript files contain only ascii characters, but produce noisy +many postscript files contain only ASCII characters, but produce noisy and meaningless diffs. The simplest way to mark a file as binary is to unset the diff @@ -644,12 +675,12 @@ 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 example, you might want to use `textconv` to convert postscript files to -an ascii representation for human viewing, but otherwise treat them as +an ASCII representation for human viewing, but otherwise treat them as binary files. You cannot specify both `-diff` and `diff=ps` attributes. The solution is to use the `diff.*.binary` config option: @@ -800,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. @@ -832,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 @@ -899,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 ------------ @@ -930,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. diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index f734f97b8e..dfe7d83727 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,74 +25,104 @@ 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 ~~~~~~~~~~~~~ Commands which have the enhanced option parser activated all understand a -couple of magic command line options: +couple of magic command-line options: -h:: gives a pretty printed usage of the command. + --------------------------------------------- $ 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 fb0d5692a4..8475c07932 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,8 +968,8 @@ would be different) ---------------- Updating from ae3a2da... to a80b4aa.... Fast-forward (no commit created; -m option ignored) - example | 1 + - hello | 1 + + example | 1 + + hello | 1 + 2 files changed, 2 insertions(+) ---------------- @@ -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]. +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 @@ -1701,7 +1667,7 @@ linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:gitcvs-migration[7], linkgit:git-help[1], -link:everyday.html[Everyday git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/gitcredentials.txt b/Documentation/gitcredentials.txt index 066f825f2e..1c75be0803 100644 --- a/Documentation/gitcredentials.txt +++ b/Documentation/gitcredentials.txt @@ -3,7 +3,7 @@ gitcredentials(7) NAME ---- -gitcredentials - providing usernames and passwords to git +gitcredentials - providing usernames and passwords to Git SYNOPSIS -------- @@ -18,13 +18,13 @@ 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 +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 +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 @@ -32,7 +32,7 @@ strategies to ask the user for usernames and passwords: 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 +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 @@ -59,7 +59,7 @@ for a password. It is generally configured by adding this to your config: username = me --------------------------------------- -Credential helpers, on the other hand, are external programs from which git can +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. @@ -79,7 +79,7 @@ store:: 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 +you can tell Git to use it by putting its name into the credential.helper variable. 1. Find a helper. @@ -95,7 +95,7 @@ credential-foo $ git help credential-foo ------------------------------------------- -3. Tell git to use it. +3. Tell Git to use it. + ------------------------------------------- $ git config --global credential.helper foo @@ -103,7 +103,7 @@ $ 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, or nothing. Once Git has acquired both a username and a password, no more helpers will be tried. @@ -114,7 +114,7 @@ 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 +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: @@ -133,18 +133,18 @@ context would not match: username = foo -------------------------------------- -because the hostnames differ. Nor would it match `foo.example.com`; git +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. +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 +`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: @@ -164,7 +164,7 @@ username:: useHttpPath:: - By default, git does not consider the "path" component of an http URL + 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 @@ -175,7 +175,7 @@ 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 +which you keep credentials. See the documentation for Git's link:technical/api-credentials.html[credentials API] for details. GIT diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt index aeb0cdc973..b06e852a85 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: @@ -117,7 +117,7 @@ Importing a CVS archive ----------------------- First, install version 2.1 or higher of cvsps from -link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make +http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make sure it is in your path. Then cd to a checked out CVS working directory of the project you are interested in and run linkgit:git-cvsimport[1]: @@ -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. @@ -194,7 +194,7 @@ linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:gitcore-tutorial[7], linkgit:gitglossary[7], -link:everyday.html[Everyday Git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt index 370624c171..c8b3e51c84 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/everyday.txt b/Documentation/giteveryday.txt index ae413e52a5..7be6e64846 100644 --- a/Documentation/everyday.txt +++ b/Documentation/giteveryday.txt @@ -1,22 +1,37 @@ -Everyday GIT With 20 Commands Or So -=================================== +giteveryday(7) +=============== -<<Individual Developer (Standalone)>> commands are essential for -anybody who makes a commit, even for somebody who works alone. +NAME +---- +giteveryday - A useful minimum set of commands for Everyday Git -If you work with other people, you will need commands listed in -the <<Individual Developer (Participant)>> section as well. +SYNOPSIS +-------- -People who play the <<Integrator>> role need to learn some more -commands in addition to the above. +Everyday Git With 20 Commands Or So -<<Repository Administration>> commands are for system -administrators who are responsible for the care and feeding -of git repositories. +DESCRIPTION +----------- +Git users can broadly be grouped into four categories for the purposes of +describing here a small set of useful command for everyday Git. -Individual Developer (Standalone)[[Individual Developer (Standalone)]] ----------------------------------------------------------------------- +* <<STANDALONE,Individual Developer (Standalone)>> commands are essential + for anybody who makes a commit, even for somebody who works alone. + +* If you work with other people, you will need commands listed in + the <<PARTICIPANT,Individual Developer (Participant)>> section as well. + +* People who play the <<INTEGRATOR,Integrator>> role need to learn some + more commands in addition to the above. + +* <<ADMINISTRATION,Repository Administration>> commands are for system + administrators who are responsible for the care and feeding + of Git repositories. + + +Individual Developer (Standalone)[[STANDALONE]] +----------------------------------------------- A standalone individual developer does not exchange patches with other people, and works alone in a single repository, using the @@ -24,8 +39,6 @@ following commands. * linkgit:git-init[1] to create a new repository. - * linkgit:git-show-branch[1] to see where you are. - * linkgit:git-log[1] to see what happened. * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch @@ -45,7 +58,7 @@ following commands. * linkgit:git-rebase[1] to maintain topic branches. - * linkgit:git-tag[1] to mark known point. + * linkgit:git-tag[1] to mark a known point. Examples ~~~~~~~~ @@ -75,37 +88,34 @@ $ edit/compile/test $ git diff HEAD <4> $ git commit -a -s <5> $ edit/compile/test -$ git reset --soft HEAD^ <6> -$ edit/compile/test -$ git diff ORIG_HEAD <7> -$ git commit -a -c ORIG_HEAD <8> -$ git checkout master <9> -$ git merge alsa-audio <10> -$ git log --since='3 days ago' <11> -$ git log v2.43.. curses/ <12> +$ git diff HEAD^ <6> +$ git commit -a --amend <7> +$ git checkout master <8> +$ git merge alsa-audio <9> +$ git log --since='3 days ago' <10> +$ git log v2.43.. curses/ <11> ------------ + <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. -<6> take the last commit back, keeping what is in the working tree. -<7> look at the changes since the premature commit we took back. -<8> redo the commit undone in the previous step, using the message -you originally wrote. -<9> switch to the master branch. -<10> merge a topic branch into your master branch. -<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. -<12> view only the changes that touch what's in `curses/` +<5> commit everything, as you have tested, with your sign-off. +<6> look at all your changes including the previous commit. +<7> amend the previous commit, adding all your new changes, +using your original message. +<8> switch to the master branch. +<9> merge a topic branch into your master branch. +<10> review commit logs; other forms to limit output can be +combined and include `-10` (to show up to 10 commits), +`--until=2005-12-10`, etc. +<11> view only the changes that touch what's in `curses/` directory, since `v2.43` tag. -Individual Developer (Participant)[[Individual Developer (Participant)]] ------------------------------------------------------------------------- +Individual Developer (Participant)[[PARTICIPANT]] +------------------------------------------------- A developer working as a participant in a group project needs to learn how to communicate with others, and uses these commands in @@ -123,6 +133,13 @@ addition to the ones needed by a standalone developer. * linkgit:git-format-patch[1] to prepare e-mail submission, if you adopt Linux kernel-style public forum workflow. + * linkgit:git-send-email[1] to send your e-mail submission without + corruption by your MUA. + + * linkgit:git-request-pull[1] to create a summary of changes + for your upstream to pull. + + Examples ~~~~~~~~ @@ -131,28 +148,34 @@ Clone the upstream and work on it. Feed changes to upstream.:: ------------ $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6 $ cd my2.6 -$ edit/compile/test; git commit -a -s <1> -$ git format-patch origin <2> -$ git pull <3> -$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4> -$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5> -$ git reset --hard ORIG_HEAD <6> -$ git gc <7> -$ git fetch --tags <8> +$ git checkout -b mine master <1> +$ edit/compile/test; git commit -a -s <2> +$ git format-patch master <3> +$ git send-email --to="person <email@example.com>" 00*.patch <4> +$ git checkout master <5> +$ git pull <6> +$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <7> +$ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git <8> +$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <9> +$ git reset --hard ORIG_HEAD <10> +$ git gc <11> ------------ + -<1> repeat as needed. -<2> extract patches from your branch for e-mail submission. -<3> `git pull` fetches from `origin` by default and merges into the +<1> checkout a new branch `mine` from master. +<2> repeat as needed. +<3> extract patches from your branch, relative to master, +<4> and email them. +<5> return to `master`, ready to see what's new +<6> `git pull` fetches from `origin` by default and merges into the current branch. -<4> immediately after pulling, look at the changes done upstream +<7> immediately after pulling, look at the changes done upstream since last time we checked, only in the area we are interested in. -<5> fetch from a specific branch from a specific repository and merge. -<6> revert the pull. -<7> garbage collect leftover objects from reverted pull. -<8> from time to time, obtain official tags from the `origin` -and store them under `.git/refs/tags/`. +<8> check the branch names in an external repository (if not known). +<9> fetch from a specific branch `ALL` from a specific repository +and merge it. +<10> revert the pull. +<11> garbage collect leftover objects from reverted pull. Push into another repository.:: @@ -166,7 +189,7 @@ remote.origin.fetch refs/heads/*:refs/remotes/origin/* branch.master.remote origin branch.master.merge refs/heads/master satellite$ git config remote.origin.push \ - master:refs/remotes/satellite/master <3> + +refs/heads/*:refs/remotes/satellite/* <3> satellite$ edit/compile/test/commit satellite$ git push origin <4> @@ -181,11 +204,12 @@ machine. <2> clone sets these configuration variables by default. It arranges `git pull` to fetch and store the branches of mothership machine to local `remotes/origin/*` remote-tracking branches. -<3> arrange `git push` to push local `master` branch to -`remotes/satellite/master` branch of the mothership machine. -<4> push will stash our work away on `remotes/satellite/master` -remote-tracking branch on the mothership machine. You could use this -as a back-up method. +<3> arrange `git push` to push all local branches to +their corresponding branch of the mothership machine. +<4> push will stash all our work away on `remotes/satellite/*` +remote-tracking branches on the mothership machine. You could use this +as a back-up method. Likewise, you can pretend that mothership +"fetched" from you (useful when access is one sided). <5> on mothership machine, merge the work done on the satellite machine into the master branch. @@ -195,17 +219,22 @@ Branch off of a specific tag.:: $ git checkout -b private2.6.14 v2.6.14 <1> $ edit/compile/test; git commit -a $ git checkout master -$ git format-patch -k -m --stdout v2.6.14..private2.6.14 | - git am -3 -k <2> +$ git cherry-pick v2.6.14..private2.6.14 <2> ------------ + <1> create a private branch based on a well known (but somewhat behind) tag. <2> forward port all changes in `private2.6.14` branch to `master` branch -without a formal "merging". +without a formal "merging". Or longhand + +`git format-patch -k -m --stdout v2.6.14..private2.6.14 | + git am -3 -k` +An alternate participant submission mechanism is using the +`git request-pull` or pull-request mechanisms (e.g as used on +GitHub (www.github.com) to notify your upstream of your +contribution. -Integrator[[Integrator]] +Integrator[[INTEGRATOR]] ------------------------ A fairly central person acting as the integrator in a group @@ -213,6 +242,13 @@ project receives changes made by others, reviews and integrates them and publishes the result for others to use, using these commands in addition to the ones needed by participants. +This section can also be used by those who respond to `git +request-pull` or pull-request on GitHub (www.github.com) to +integrate the work of others into their history. An sub-area +lieutenant for a repository will act both as a participant and +as an integrator. + + * linkgit:git-am[1] to apply patches e-mailed in from your contributors. @@ -229,19 +265,19 @@ commands in addition to the ones needed by participants. Examples ~~~~~~~~ -My typical GIT day.:: +A typical integrator's Git day.:: + ------------ $ git status <1> -$ git show-branch <2> +$ git branch --no-merged master <2> $ mailx <3> & s 2 3 4 5 ./+to-apply & s 7 8 ./+hold-linus & q $ git checkout -b topic/one master -$ git am -3 -i -s -u ./+to-apply <4> +$ git am -3 -i -s ./+to-apply <4> $ compile/test -$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5> +$ git checkout -b hold/linus && git am -3 -i -s ./+hold-linus <5> $ git checkout topic/one && git rebase master <6> $ git checkout pu && git reset --hard next <7> $ git merge topic/one topic/two && git merge hold/linus <8> @@ -249,51 +285,51 @@ $ git checkout maint $ git cherry-pick master~4 <9> $ compile/test $ git tag -s -m "GIT 0.99.9x" v0.99.9x <10> -$ git fetch ko && git show-branch master maint 'tags/ko-*' <11> -$ git push ko <12> -$ git push ko v0.99.9x <13> +$ git fetch ko && for branch in master maint next pu <11> + do + git show-branch ko/$branch $branch <12> + done +$ git push --follow-tags ko <13> ------------ + -<1> see what I was in the middle of doing, if any. -<2> see what topic branches I have and think about how ready -they are. +<1> see what you were in the middle of doing, if anything. +<2> see which branches haven't been merged into `master` yet. +Likewise for any other integration branches e.g. `maint`, `next` +and `pu` (potential updates). <3> read mails, save ones that are applicable, and save others -that are not quite ready. -<4> apply them, interactively, with my sign-offs. -<5> create topic branch as needed and apply, again with my -sign-offs. +that are not quite ready (other mail readers are available). +<4> apply them, interactively, with your sign-offs. +<5> create topic branch as needed and apply, again with sign-offs. <6> rebase internal topic branch that has not been merged to the -master, nor exposed as a part of a stable branch. +master or exposed as a part of a stable branch. <7> restart `pu` every time from the next. <8> and bundle topic branches still cooking. <9> backport a critical fix. <10> create a signed tag. -<11> make sure I did not accidentally rewind master beyond what I -already pushed out. `ko` shorthand points at the repository I have -at kernel.org, and looks like this: +<11> make sure master was not accidentally rewound beyond that +already pushed out. `ko` shorthand points at the Git maintainer's +repository at kernel.org, and looks like this: + ------------ -$ cat .git/remotes/ko -URL: kernel.org:/pub/scm/git/git.git -Pull: master:refs/tags/ko-master -Pull: next:refs/tags/ko-next -Pull: maint:refs/tags/ko-maint -Push: master -Push: next -Push: +pu -Push: maint +(in .git/config) +[remote "ko"] + url = kernel.org:/pub/scm/git/git.git + fetch = refs/heads/*:refs/remotes/ko/* + push = refs/heads/master + push = refs/heads/next + push = +refs/heads/pu + push = refs/heads/maint ------------ + -In the output from `git show-branch`, `master` should have -everything `ko-master` has, and `next` should have -everything `ko-next` has. - -<12> push out the bleeding edge. -<13> push the tag out, too. +<12> In the output from `git show-branch`, `master` should have +everything `ko/master` has, and `next` should have +everything `ko/next` has, etc. +<13> push out the bleeding edge, together with new tags that point +into the pushed history. -Repository Administration[[Repository Administration]] ------------------------------------------------------- +Repository Administration[[ADMINISTRATION]] +------------------------------------------- A repository administrator uses the following tools to set up and maintain access to the repository by developers. @@ -304,9 +340,19 @@ 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 + * linkgit:git-http-backend[1] provides a server side implementation + of Git-over-HTTP ("Smart http") allowing both fetch and push services. + + * linkgit:gitweb[1] provides a web front-end to Git repositories, + which can be set-up using the linkgit:git-instaweb[1] script. + +link:howto/update-hook-example.html[update hook howto] has a good example of managing a shared central repository. +In addition there are a number of other widely deployed hosting, browsing +and reviewing solutions such as: + + * gitolite, gerrit code review, cgit and others. Examples ~~~~~~~~ @@ -332,25 +378,28 @@ 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 - type = UNLISTED - port = 9418 - socket_type = stream - wait = no - user = nobody - server = /usr/bin/git-daemon - server_args = --inetd --export-all --base-path=/pub/scm - log_on_failure += USERID + disable = no + type = UNLISTED + port = 9418 + socket_type = stream + wait = no + user = nobody + server = /usr/bin/git-daemon + server_args = --inetd --export-all --base-path=/pub/scm + log_on_failure += USERID } ------------ + Check your xinetd(8) documentation and setup, this is from a Fedora system. Others might be different. -Give push/pull only access to developers.:: +Give push/pull only access to developers using git-over-ssh.:: + +e.g. those using: +`$ git push/pull ssh://host.xz/pub/scm/project` + ------------ $ grep git /etc/passwd <1> @@ -363,8 +412,8 @@ $ grep git /etc/shells <2> ------------ + <1> log-in shell is set to /usr/bin/git-shell, which does not -allow anything but `git push` and `git pull`. The users should -get an ssh access to the machine. +allow anything but `git push` and `git pull`. The users require +ssh access to the machine. <2> in many distributions /etc/shells needs to list what is used as the login shell. @@ -401,13 +450,6 @@ for branch policy control. david is the release manager and is the only person who can create and push version tags. -HTTP server to support dumb protocol transfer.:: -+ ------------- -dev$ git update-server-info <1> -dev$ ftp user@isp.example.com <2> -ftp> cp -r .git /home/user/myproject.git ------------- -+ -<1> make sure your info/refs and objects/info/packs are up-to-date -<2> upload to public HTTP server hosted by your ISP. +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitglossary.txt b/Documentation/gitglossary.txt index d77a45aed6..212e254adc 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], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index 28edefa202..7ba0ac965d 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 ~~~~~~~~~~~~~ @@ -173,9 +175,38 @@ if the merge failed due to conflicts. This hook can be used in conjunction with a corresponding pre-commit hook to save and restore any form of metadata associated with the working tree -(eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl +(e.g.: 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,13 +334,43 @@ 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 'git send-pack' on the other end, so you can simply `echo` messages for the user. +push-to-checkout +~~~~~~~~~~~~~~~~ + +This hook is invoked by 'git-receive-pack' on the remote repository, +which happens when a 'git push' is done on a local repository, when +the push tries to update the branch that is currently checked out +and the `receive.denyCurrentBranch` configuration variable is set to +`updateInstead`. Such a push by default is refused if the working +tree and the index of the remote repository has any difference from +the currently checked out commit; when both the working tree and the +index match the current commit, they are updated to match the newly +pushed tip of the branch. This hook is to be used to override the +default behaviour. + +The hook receives the commit with which the tip of the current +branch is going to be updated. It can exit with a non-zero status +to refuse the push (when it does so, it must not modify the index or +the working tree). Or it can make any necessary changes to the +working tree and to the index to bring them to the desired state +when the tip of the current branch is updated to the new commit, and +exit with a zero status. + +For example, the hook can simply run `git read-tree -u -m HEAD "$1"` +in order to emulate 'git fetch' that is run in the reverse direction +with `git push`, as the two-tree form of `read-tree -u -m` is +essentially the same as `git checkout` that switches branches while +keeping the local changes in the working tree that do not interfere +with the difference between the branches. + + pre-auto-gc ~~~~~~~~~~~ @@ -336,7 +397,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 2e7328b830..473623d631 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): @@ -38,24 +38,32 @@ precedence, the last matching pattern decides the outcome): * Patterns read from `$GIT_DIR/info/exclude`. * Patterns read from the file specified by the configuration - variable 'core.excludesfile'. + 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,35 @@ 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 + - Trailing spaces are ignored unless they are quoted with backslash + ("`\`"). + + - 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,14 +113,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. - -To ignore uncommitted changes in a file that is already tracked, -use 'git update-index {litdd}assume-unchanged'. +not tracked by Git remain untracked. To stop tracking a file that is currently tracked, use 'git rm --cached'. @@ -148,13 +181,27 @@ 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:gitrepository-layout[5], +linkgit:git-check-ignore[1] GIT --- diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index a17a354936..7ae50aa26a 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.) + +--ancestry-path:: -<revs>:: + 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:: @@ -98,8 +166,21 @@ gitk --max-count=100 --all \-- Makefile:: Files ----- -Gitk creates the .gitk file in your $HOME directory to store preferences -such as display options, font, and colors. +User configuration and preferences are stored at: + +* '$XDG_CONFIG_HOME/git/gitk' if it exists, otherwise +* '$HOME/.gitk' if it exists + +If neither of the above exist then '$XDG_CONFIG_HOME/git/gitk' is created and +used by default. If '$XDG_CONFIG_HOME' is not set it defaults to +'$HOME/.config' in all cases. + +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 -------- @@ -108,10 +189,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 4040941e55..ac70eca321 100644 --- a/Documentation/gitmodules.txt +++ b/Documentation/gitmodules.txt @@ -13,36 +13,45 @@ $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 - superproject will be checked out in the submodule on a detached HEAD. - If 'rebase', the current branch of the submodule will be rebased onto - the commit specified in the superproject. If 'merge', the commit - specified in the superproject will be merged into the current branch - in the submodule. - This config option is overridden if 'git submodule update' is given - the '--merge' or '--rebase' options. + Defines the default update procedure for the named submodule, + i.e. how the submodule is updated by "git submodule update" + command in the superproject. This is only used by `git + submodule init` to initialize the configuration variable of + the same name. Allowed values here are 'checkout', 'rebase', + 'merge' or 'none'. See description of 'update' command in + linkgit:git-submodule[1] for their meaning. Note that the + '!command' form is intentionally ignored here for security + reasons. + +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 @@ -55,7 +64,9 @@ submodule.<name>.fetchRecurseSubmodules:: submodule.<name>.ignore:: Defines under what circumstances "git status" and the diff family show a submodule as modified. When set to "all", it will never be considered - modified, "dirty" will ignore all changes to the submodules work tree and + modified (but will nonetheless show up in the output of status and + commit when it has been staged), "dirty" will ignore all changes + to the submodules work tree and takes only differences between the HEAD of the submodule and the commit recorded in the superproject into account. "untracked" will additionally let submodules with modified tracked files in their work tree show up. @@ -65,7 +76,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 +96,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 index c6713cf5d7..7685e3651a 100644 --- a/Documentation/gitnamespaces.txt +++ b/Documentation/gitnamespaces.txt @@ -29,7 +29,7 @@ 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 +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 diff --git a/Documentation/git-remote-helpers.txt b/Documentation/gitremote-helpers.txt index 674797cd83..8edf72cf53 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/gitremote-helpers.txt @@ -1,9 +1,9 @@ -git-remote-helpers(1) -===================== +gitremote-helpers(1) +==================== NAME ---- -git-remote-helpers - Helper programs to interact with remote repositories +gitremote-helpers - Helper programs to interact with remote repositories SYNOPSIS -------- @@ -14,17 +14,17 @@ 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 +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. +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 +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, @@ -35,6 +35,37 @@ 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 ------------ @@ -54,56 +85,20 @@ 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 +The operations a helper supports are declared to Git in the response to the `capabilities` command (see COMMANDS, below). -'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. - -'connect':: - For fetching and pushing using git's native packfile protocol - that requires a bidirectional, full-duplex connection. - -'push':: - For listing remote refs and pushing specified objects from the - local object store to remote refs. - -'fetch':: - For listing remote refs and fetching the associated history to - the local object store. - -'import':: - For listing remote refs and fetching the associated history as - a fast-import stream. - -'refspec' <refspec>:: - This modifies the 'import' capability, allowing the produced - fast-import stream to modify refs in 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. -+ -A helper advertising the capability -`refspec refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}` -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 {asterisk}:{asterisk}`. +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 the - packfile protocol. + 'git upload-pack', etc for communication using + git's native packfile protocol. This + requires a bidirectional, full-duplex connection. + Supported commands: 'connect'. @@ -113,16 +108,31 @@ Supported commands: 'connect'. + Supported commands: 'list for-push', 'push'. -If a helper advertises both 'connect' and 'push', git will use -'connect' if possible and fall back to 'push' if the helper requests -so when connecting (see the 'connect' command under COMMANDS). +'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 - packfile protocol. + Git's native packfile protocol. This + requires a bidirectional, full-duplex connection. + Supported commands: 'connect'. @@ -138,57 +148,81 @@ Supported commands: 'list', 'fetch'. + Supported commands: 'list', 'import'. -If a helper advertises 'connect', git will use it if possible and +'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'. +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>:: - This modifies the 'import' capability. + 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 -`refspec refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}` -in its capabilities is saying that, when it handles -`import refs/heads/topic`, the stream it outputs will update the -`refs/svn/origin/branches/topic` ref. +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 {asterisk}:{asterisk}`. - -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. +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. -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. +'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'. -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 -------- @@ -198,9 +232,11 @@ 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). + 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> @@ -210,9 +246,20 @@ Commands are given by the caller on the helper's standard input, one per line. 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. +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 @@ -222,6 +269,8 @@ commands to the helper. 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>:: @@ -230,12 +279,15 @@ Supported if the helper has the "option" capability. 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. + 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>:: @@ -286,8 +338,29 @@ 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 @@ -313,10 +386,9 @@ capabilities reported by the helper. 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. +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 @@ -324,6 +396,10 @@ REF LIST ATTRIBUTES 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 @@ -358,12 +434,32 @@ OPTIONS 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 force' \{'true'|'false'\}:: + Request the helper to perform a force update. Defaults to + 'false'. + +'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-ext[1] + +linkgit:git-remote-fd[1] + linkgit:git-remote-testgit[1] +linkgit:git-fast-import[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt index 5c891f1169..79653f3134 100644 --- a/Documentation/gitrepository-layout.txt +++ b/Documentation/gitrepository-layout.txt @@ -12,12 +12,24 @@ $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 @@ -93,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 @@ -102,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 @@ -125,7 +143,7 @@ branches:: 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 @@ -137,6 +155,10 @@ index:: The current index file for the repository. It is usually not found in a bare repository. +sharedindex.<SHA-1>:: + The shared index part, to be referenced by $GIT_DIR/index and + other temporary index files. Only valid in split index mode. + info:: Additional information about the repository is recorded in this directory. @@ -158,14 +180,22 @@ info/grafts:: per line describes a commit and its fake parents by listing their 40-byte hexadecimal object names separated by a space and terminated by a newline. ++ +Note that the grafts mechanism is outdated and can lead to problems +transferring objects between repositories; see linkgit:git-replace[1] +for a more flexible and robust system to do the same thing. 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 for URL and default refnames for use when interacting with remote repositories via 'git fetch', @@ -189,6 +219,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 fc4789f98e..c0ed6d1925 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 e00a4d2170..30d2119565 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: @@ -42,25 +42,25 @@ $ git commit -a -m "add emphasis" 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. @@ -368,17 +368,18 @@ situation: ------------------------------------------------ $ git status -# On branch master -# Changes to be committed: -# (use "git reset HEAD <file>..." to unstage) -# -# new file: closing.txt -# -# Changes not staged for commit: -# (use "git add <file>..." to update what will be committed) -# -# modified: file.txt -# +On branch master +Changes to be committed: + (use "git reset HEAD <file>..." to unstage) + + new file: closing.txt + +Changes not staged for commit: + (use "git add <file>..." to update what will be committed) + (use "git checkout -- <file>..." to discard changes in working directory) + + modified: file.txt + ------------------------------------------------ Since the current state of closing.txt is cached in the index file, @@ -403,21 +404,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 linkgit:giteveryday[7]. 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 +428,7 @@ linkgit:gitcvs-migration[7], linkgit:gitcore-tutorial[7], linkgit:gitglossary[7], linkgit:git-help[1], -link:everyday.html[Everyday git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index dee050567e..b00c67df46 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 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 -------------- @@ -107,14 +107,15 @@ summary of the situation with 'git status': ------------------------------------------------ $ git status -# On branch master -# Changes to be committed: -# (use "git reset HEAD <file>..." to unstage) -# -# modified: file1 -# modified: file2 -# modified: file3 -# +On branch master +Changes to be committed: +Your branch is up-to-date with 'origin/master'. + (use "git reset HEAD <file>..." to unstage) + + modified: file1 + modified: file2 + modified: file3 + ------------------------------------------------ If you need to make any further adjustments, do so now, and then add any @@ -139,9 +140,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 +181,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 +277,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 +321,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 +423,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 +451,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 +519,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 +555,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 +593,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 +624,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 +637,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 +657,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] + * linkgit:giteveryday[7]: Everyday Git with 20 Commands Or So. * linkgit:gitcvs-migration[7]: Git for CVS users. @@ -666,7 +669,7 @@ linkgit:gitcore-tutorial[7], linkgit:gitglossary[7], linkgit:git-help[1], linkgit:gitworkflows[7], -link:everyday.html[Everyday git], +linkgit:giteveryday[7], link:user-manual.html[The Git User's Manual] GIT diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt index 7aba497b74..a096e7ddf7 100644 --- a/Documentation/gitweb.conf.txt +++ b/Documentation/gitweb.conf.txt @@ -3,7 +3,7 @@ gitweb.conf(5) NAME ---- -gitweb.conf - Gitweb (git web interface) configuration file +gitweb.conf - Gitweb (Git web interface) configuration file SYNOPSIS -------- @@ -79,7 +79,7 @@ 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 +of Git repository management tools) in a separate file, e.g. in '/etc/gitweb-gitolite.conf'. To include it, put -------------------------------------------------- @@ -111,7 +111,7 @@ and installing gitweb. Location of repositories ~~~~~~~~~~~~~~~~~~~~~~~~ The configuration variables described below control how gitweb finds -git repositories, and how repositories are displayed and accessed. +Git repositories, and how repositories are displayed and accessed. See also "Repositories" and later subsections in linkgit:gitweb[1] manpage. @@ -159,7 +159,7 @@ 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` + 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. @@ -200,7 +200,7 @@ 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" +See also more involved example in "Controlling access to Git repositories" subsection on linkgit:gitweb[1] manpage. $strict_export:: @@ -222,18 +222,18 @@ 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 + 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 + 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, + 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. @@ -244,7 +244,7 @@ $highlight_bin:: 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 hightlighting. + 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` @@ -336,15 +336,33 @@ $home_link_str:: 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. Other popular choice it to - set it to the name of site. + 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[]. + 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 @@ -436,7 +454,7 @@ $fallback_encoding:: detection. + *Note* that rename and especially copy detection can be quite -CPU-intensive. Note also that non git tools can have problems with +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'). @@ -451,7 +469,7 @@ looks does contain variables configuring administrative side of gitweb 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 + 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 @@ -464,7 +482,7 @@ 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. +time by setting the `GITWEB_BASE_URL` build-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. @@ -499,6 +517,13 @@ $maxload:: 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. @@ -605,13 +630,13 @@ need to set this element to empty list i.e. `[]`. override:: If this field has a true value then the given feature is - overriddable, which means that it can be configured + 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. +config variable in the per-repository Git configuration file. + -*Note* that no feature is overriddable by default. +*Note* that no feature is overridable by default. sub:: Internal detail of implementation. What is important is that @@ -681,7 +706,7 @@ show-sizes:: I/O. Enabled by default. + This feature can be configured on a per-repository basis via -repository's `gitweb.showsizes` configuration variable (boolean). +repository's `gitweb.showSizes` configuration variable (boolean). patches:: Enable and configure "patches" view, which displays list of commits in email @@ -749,14 +774,14 @@ 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 + 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 +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. + @@ -775,7 +800,7 @@ filesystem (i.e. "$projectroot/$project"), `%h` to the current hash (\'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 +Git hosting site set it to the following to enable graphical log (using the third party tool *git-browser*): + ---------------------------------------------------------------------- @@ -789,26 +814,26 @@ This adds a link titled "graphiclog" after the "summary" link, leading to Project specific override is not supported. timed:: - Enable displaying how much time and how many git commands it took to + 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. + 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 timezone for dates + 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 timezone (for if the client -hasn't selected some other timezone and saved it in a cookie), a name of cookie -where to store selected timezone, and a CSS class used to mark up +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) timezone, +Typical gitweb config files will only change starting (default) time zone, and leave other elements at their default values: + --------------------------------------------------------------------------- @@ -818,12 +843,49 @@ $feature{'javascript-timezone'}{'default'}[0] = "utc"; The example configuration presented here is guaranteed to be backwards and forward compatible. + -Timezone values can be "local" (for local timezone that browser uses), "utc" +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 -timezones in the form of "+/-HHMM", such as "+0200". +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 -------- @@ -842,7 +904,7 @@ the following in your GITWEB_CONFIG file: $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 +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: @@ -850,6 +912,13 @@ 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 diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt index 605a085326..cd9c8951b2 100644 --- a/Documentation/gitweb.txt +++ b/Documentation/gitweb.txt @@ -7,14 +7,14 @@ gitweb - Git web interface (web frontend to Git repositories) SYNOPSIS -------- -To get started with gitweb, run linkgit:git-instaweb[1] from a git repository. +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. It's features include: +Gitweb provides a web interface to Git repositories. Its features include: * Viewing multiple Git repositories with common root. * Browsing every revision of the repository. @@ -54,13 +54,13 @@ 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 +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 +`$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 repository in gitweb is path to it's `$GIT_DIR` (it's object +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". @@ -84,7 +84,7 @@ 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 +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). + @@ -111,7 +111,7 @@ 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 +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 @@ -151,9 +151,9 @@ as projects list file, which means that you can set `$projects_list` to its filename. -Controlling access to git repositories +Controlling access to Git repositories ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -By default all git repositories under `$projectroot` are visible and +By default all Git repositories under `$projectroot` are visible and available to gitweb. You can however configure how gitweb controls access to repositories. @@ -206,7 +206,7 @@ $export_auth_hook = sub { 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 +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: @@ -504,7 +504,7 @@ repositories, you can configure Apache like this: 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 cloneable GIT URL and as browseable gitweb interface. If you then +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. @@ -584,7 +584,7 @@ $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/pub/git"; 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 +the server will be able to browse through gitweb Git repositories found in '~/public_git/' with the following url: http://git.example.org/~<user>/ @@ -673,7 +673,7 @@ 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 +will give raw access to the project's Git dir (so that the project can be cloned), while http://git.example.com/project diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt index 5e4f362ff8..f16c414ea7 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 3595b586bc..bf383c2e8c 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -1,13 +1,13 @@ [[def_alternate_object_database]]alternate object database:: Via the alternates mechanism, a <<def_repository,repository>> can inherit part of its <<def_object_database,object database>> - from another object database, which is called "alternate". + from another object database, which is called an "alternate". [[def_bare_repository]]bare repository:: 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,30 @@ 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. ++ +Note that the grafts mechanism is outdated and can lead to problems +transferring objects between repositories; see linkgit:git-replace[1] +for a more flexible and robust system to do the same thing. [[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 +202,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 +226,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 +253,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 +266,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 +277,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 +297,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 +306,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 +317,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 characters 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 +403,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 +443,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 +467,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 +491,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 +500,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 +516,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 +528,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 +540,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 +556,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 34aa30c5b9..167b363668 100755 --- a/Documentation/howto-index.sh +++ b/Documentation/howto-index.sh @@ -1,18 +1,18 @@ #!/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 for txt do - title=`expr "$txt" : '.*/\(.*\)\.txt$'` - from=`sed -ne ' + title=$(expr "$txt" : '.*/\(.*\)\.txt$') + from=$(sed -ne ' /^$/q /^From:[ ]/{ s/// @@ -21,9 +21,9 @@ do s/^/by / p } - ' "$txt"` + ' "$txt") - abstract=`sed -ne ' + abstract=$(sed -ne ' /^Abstract:[ ]/{ s/^[^ ]*// x @@ -39,11 +39,11 @@ do x p q - }' "$txt"` + }' "$txt") if grep 'Content-type: text/asciidoc' >/dev/null $txt then - file=`expr "$txt" : '\(.*\)\.txt$'`.html + file=$(expr "$txt" : '\(.*\)\.txt$').html else file="$txt" fi diff --git a/Documentation/howto/keep-canonical-history-correct.txt b/Documentation/howto/keep-canonical-history-correct.txt new file mode 100644 index 0000000000..35d48ef714 --- /dev/null +++ b/Documentation/howto/keep-canonical-history-correct.txt @@ -0,0 +1,216 @@ +From: Junio C Hamano <gitster@pobox.com> +Date: Wed, 07 May 2014 13:15:39 -0700 +Subject: Beginner question on "Pull is mostly evil" +Abstract: This how-to explains a method for keeping a + project's history correct when using git pull. +Content-type: text/asciidoc + +Keep authoritative canonical history correct with git pull +========================================================== + +Sometimes a new project integrator will end up with project history +that appears to be "backwards" from what other project developers +expect. This howto presents a suggested integration workflow for +maintaining a central repository. + +Suppose that that central repository has this history: + +------------ + ---o---o---A +------------ + +which ends at commit `A` (time flows from left to right and each node +in the graph is a commit, lines between them indicating parent-child +relationship). + +Then you clone it and work on your own commits, which leads you to +have this history in *your* repository: + +------------ + ---o---o---A---B---C +------------ + +Imagine your coworker did the same and built on top of `A` in *his* +repository in the meantime, and then pushed it to the +central repository: + +------------ + ---o---o---A---X---Y---Z +------------ + +Now, if you `git push` at this point, because your history that leads +to `C` lacks `X`, `Y` and `Z`, it will fail. You need to somehow make +the tip of your history a descendant of `Z`. + +One suggested way to solve the problem is "fetch and then merge", aka +`git pull`. When you fetch, your repository will have a history like +this: + +------------ + ---o---o---A---B---C + \ + X---Y---Z +------------ + +Once you run merge after that, while still on *your* branch, i.e. `C`, +you will create a merge `M` and make the history look like this: + +------------ + ---o---o---A---B---C---M + \ / + X---Y---Z +------------ + +`M` is a descendant of `Z`, so you can push to update the central +repository. Such a merge `M` does not lose any commit in both +histories, so in that sense it may not be wrong, but when people want +to talk about "the authoritative canonical history that is shared +among the project participants", i.e. "the trunk", they often view +it as "commits you see by following the first-parent chain", and use +this command to view it: + +------------ + $ git log --first-parent +------------ + +For all other people who observed the central repository after your +coworker pushed `Z` but before you pushed `M`, the commit on the trunk +used to be `o-o-A-X-Y-Z`. But because you made `M` while you were on +`C`, `M`'s first parent is `C`, so by pushing `M` to advance the +central repository, you made `X-Y-Z` a side branch, not on the trunk. + +You would rather want to have a history of this shape: + +------------ + ---o---o---A---X---Y---Z---M' + \ / + B-----------C +------------ + +so that in the first-parent chain, it is clear that the project first +did `X` and then `Y` and then `Z` and merged a change that consists of +two commits `B` and `C` that achieves a single goal. You may have +worked on fixing the bug #12345 with these two patches, and the merge +`M'` with swapped parents can say in its log message "Merge +fix-bug-12345". Having a way to tell `git pull` to create a merge +but record the parents in reverse order may be a way to do so. + +Note that I said "achieves a single goal" above, because this is +important. "Swapping the merge order" only covers a special case +where the project does not care too much about having unrelated +things done on a single merge but cares a lot about first-parent +chain. + +There are multiple schools of thought about the "trunk" management. + + 1. Some projects want to keep a completely linear history without any + merges. Obviously, swapping the merge order would not match their + taste. You would need to flatten your history on top of the + updated upstream to result in a history of this shape instead: ++ +------------ + ---o---o---A---X---Y---Z---B---C +------------ ++ +with `git pull --rebase` or something. + + 2. Some projects tolerate merges in their history, but do not worry + too much about the first-parent order, and allow fast-forward + merges. To them, swapping the merge order does not hurt, but + it is unnecessary. + + 3. Some projects want each commit on the "trunk" to do one single + thing. The output of `git log --first-parent` in such a project + would show either a merge of a side branch that completes a single + theme, or a single commit that completes a single theme by itself. + If your two commits `B` and `C` (or they may even be two groups of + commits) were solving two independent issues, then the merge `M'` + we made in the earlier example by swapping the merge order is + still not up to the project standard. It merges two unrelated + efforts `B` and `C` at the same time. + +For projects in the last category (Git itself is one of them), +individual developers would want to prepare a history more like +this: + +------------ + C0--C1--C2 topic-c + / + ---o---o---A master + \ + B0--B1--B2 topic-b +------------ + +That is, keeping separate topics on separate branches, perhaps like +so: + +------------ + $ git clone $URL work && cd work + $ git checkout -b topic-b master + $ ... work to create B0, B1 and B2 to complete one theme + $ git checkout -b topic-c master + $ ... same for the theme of topic-c +------------ + +And then + +------------ + $ git checkout master + $ git pull --ff-only +------------ + +would grab `X`, `Y` and `Z` from the upstream and advance your master +branch: + +------------ + C0--C1--C2 topic-c + / + ---o---o---A---X---Y---Z master + \ + B0--B1--B2 topic-b +------------ + +And then you would merge these two branches separately: + +------------ + $ git merge topic-b + $ git merge topic-c +------------ + +to result in + +------------ + C0--C1---------C2 + / \ + ---o---o---A---X---Y---Z---M---N + \ / + B0--B1-----B2 +------------ + +and push it back to the central repository. + +It is very much possible that while you are merging topic-b and +topic-c, somebody again advanced the history in the central repository +to put `W` on top of `Z`, and make your `git push` fail. + +In such a case, you would rewind to discard `M` and `N`, update the +tip of your 'master' again and redo the two merges: + +------------ + $ git reset --hard origin/master + $ git pull --ff-only + $ git merge topic-b + $ git merge topic-c +------------ + +The procedure will result in a history that looks like this: + +------------ + C0--C1--------------C2 + / \ + ---o---o---A---X---Y---Z---W---M'--N' + \ / + B0--B1---------B2 +------------ + +See also http://git-blame.blogspot.com/2013/09/fun-with-first-parent-history.html diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index 8823a37067..ca4378740c 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,93 +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/cook 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. - - [** OBSOLETE **] Optionally rebase topics that do not have any commit - in next yet, when they 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 - - [** OBSOLETE **] 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 and other mirrors. + 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 @@ -274,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 0000000000..d7de5a3e9e --- /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 74a1c0c4ba..02cb5f758d 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. @@ -133,7 +139,7 @@ You fetch from upstream, but not merge. $ git fetch upstream This leaves the updated upstream head in .git/FETCH_HEAD but -does not touch your .git/HEAD nor .git/refs/heads/master. +does not touch your .git/HEAD or .git/refs/heads/master. You run "git rebase" now. $ git rebase FETCH_HEAD master @@ -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 48c67568d3..25378f68d3 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 323b513ed0..1b3b188d3c 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 0000000000..9c4cd0915f --- /dev/null +++ b/Documentation/howto/recover-corrupted-object-harder.txt @@ -0,0 +1,479 @@ +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). + + +The adventure continues... +-------------------------- + +I ended up doing this again! Same entity, new hardware. The assumption +at this point is that the old disk corrupted the packfile, and then the +corruption was migrated to the new hardware (because it was done by +rsync or similar, and no fsck was done at the time of migration). + +This time, the affected blob was over 20 megabytes, which was far too +large to do a brute-force on. I followed the instructions above to +create the `zlib` file. I then used the `inflate` program below to pull +the corrupted data from that. Examining that output gave me a hint about +where in the file the corruption was. But now I was working with the +file itself, not the zlib contents. So knowing the sha1 of the object +and the approximate area of the corruption, I used the `sha1-munge` +program below to brute-force the correct byte. + +Here's the inflate program (it's essentially `gunzip` but without the +`.gz` header processing): + +-------------------------- +#include <stdio.h> +#include <string.h> +#include <zlib.h> +#include <stdlib.h> + +int main(int argc, char **argv) +{ + /* + * oversized so we can read the whole buffer in; + * this could actually be switched to streaming + * to avoid any memory limitations + */ + static unsigned char buf[25 * 1024 * 1024]; + static unsigned char out[25 * 1024 * 1024]; + int len; + z_stream z; + int ret; + + len = read(0, buf, sizeof(buf)); + 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); + if (ret != Z_OK && ret != Z_STREAM_END) + fprintf(stderr, "initial inflate failed (%d)\n", ret); + + fprintf(stderr, "outputting %lu bytes", z.total_out); + fwrite(out, 1, z.total_out, stdout); + return 0; +} +-------------------------- + +And here is the `sha1-munge` program: + +-------------------------- +#include <stdio.h> +#include <unistd.h> +#include <string.h> +#include <signal.h> +#include <openssl/sha.h> +#include <stdlib.h> + +/* eye candy */ +static int counter = 0; +static void progress(int sig) +{ + fprintf(stderr, "\r%d", counter); + alarm(1); +} + +static const signed char hexval_table[256] = { + -1, -1, -1, -1, -1, -1, -1, -1, /* 00-07 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 08-0f */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 10-17 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 18-1f */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 20-27 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 28-2f */ + 0, 1, 2, 3, 4, 5, 6, 7, /* 30-37 */ + 8, 9, -1, -1, -1, -1, -1, -1, /* 38-3f */ + -1, 10, 11, 12, 13, 14, 15, -1, /* 40-47 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 48-4f */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 50-57 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 58-5f */ + -1, 10, 11, 12, 13, 14, 15, -1, /* 60-67 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 68-67 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 70-77 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 78-7f */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 80-87 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 88-8f */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 90-97 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* 98-9f */ + -1, -1, -1, -1, -1, -1, -1, -1, /* a0-a7 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* a8-af */ + -1, -1, -1, -1, -1, -1, -1, -1, /* b0-b7 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* b8-bf */ + -1, -1, -1, -1, -1, -1, -1, -1, /* c0-c7 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* c8-cf */ + -1, -1, -1, -1, -1, -1, -1, -1, /* d0-d7 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* d8-df */ + -1, -1, -1, -1, -1, -1, -1, -1, /* e0-e7 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* e8-ef */ + -1, -1, -1, -1, -1, -1, -1, -1, /* f0-f7 */ + -1, -1, -1, -1, -1, -1, -1, -1, /* f8-ff */ +}; + +static inline unsigned int hexval(unsigned char c) +{ +return hexval_table[c]; +} + +static int get_sha1_hex(const char *hex, unsigned char *sha1) +{ + int i; + for (i = 0; i < 20; i++) { + unsigned int val; + /* + * hex[1]=='\0' is caught when val is checked below, + * but if hex[0] is NUL we have to avoid reading + * past the end of the string: + */ + if (!hex[0]) + return -1; + val = (hexval(hex[0]) << 4) | hexval(hex[1]); + if (val & ~0xff) + return -1; + *sha1++ = val; + hex += 2; + } + return 0; +} + +int main(int argc, char **argv) +{ + /* oversized so we can read the whole buffer in */ + static unsigned char buf[25 * 1024 * 1024]; + char header[32]; + int header_len; + unsigned char have[20], want[20]; + int start, len; + SHA_CTX orig; + unsigned i, j; + + if (!argv[1] || get_sha1_hex(argv[1], want)) { + fprintf(stderr, "usage: sha1-munge <sha1> [start] <file.in\n"); + return 1; + } + + if (argv[2]) + start = atoi(argv[2]); + else + start = 0; + + len = read(0, buf, sizeof(buf)); + header_len = sprintf(header, "blob %d", len) + 1; + fprintf(stderr, "using header: %s\n", header); + + /* + * We keep a running sha1 so that if you are munging + * near the end of the file, we do not have to re-sha1 + * the unchanged earlier bytes + */ + SHA1_Init(&orig); + SHA1_Update(&orig, header, header_len); + if (start) + SHA1_Update(&orig, buf, start); + + signal(SIGALRM, progress); + alarm(1); + + for (i = start; i < len; i++) { + unsigned char c; + SHA_CTX x; + +#if 0 + /* + * deletion -- this would not actually work in practice, + * I think, because we've already committed to a + * particular size in the header. Ditto for addition + * below. In those cases, you'd have to do the whole + * sha1 from scratch, or possibly keep three running + * "orig" sha1 computations going. + */ + memcpy(&x, &orig, sizeof(x)); + SHA1_Update(&x, buf + i + 1, len - i - 1); + SHA1_Final(have, &x); + if (!memcmp(have, want, 20)) + printf("i=%d, deletion\n", i); +#endif + + /* + * replacement -- note that this tries each of the 256 + * possible bytes. If you suspect a single-bit flip, + * it would be much shorter to just try the 8 + * bit-flipped variants. + */ + c = buf[i]; + for (j = 0; j <= 0xff; j++) { + buf[i] = j; + + memcpy(&x, &orig, sizeof(x)); + SHA1_Update(&x, buf + i, len - i); + SHA1_Final(have, &x); + if (!memcmp(have, want, 20)) + printf("i=%d, j=%02x\n", i, j); + } + buf[i] = c; + +#if 0 + /* addition */ + for (j = 0; j <= 0xff; j++) { + unsigned char extra = j; + memcpy(&x, &orig, sizeof(x)); + SHA1_Update(&x, &extra, 1); + SHA1_Update(&x, buf + i, len - i); + SHA1_Final(have, &x); + if (!memcmp(have, want, 20)) + printf("i=%d, addition=%02x", i, j); + } +#endif + + SHA1_Update(&orig, buf + i, 1); + counter++; + } + + alarm(0); + fprintf(stderr, "\r%d\n", counter); + return 0; +} +-------------------------- diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt index 6fd711996a..462255ed5d 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: @@ -50,7 +54,7 @@ where C and D are to fix what was broken in A and B, and you may already have some other changes on the mainline after W. If you merge the updated side branch (with D at its tip), none of the -changes made in A nor B will be in the result, because they were reverted +changes made in A or B will be in the result, because they were reverted by W. That is what Alan saw. Linus explains the situation: @@ -86,7 +90,7 @@ with: $ git revert W This history would (ignoring possible conflicts between what W and W..Y -changed) be equivalent to not having W nor Y at all in the history: +changed) be equivalent to not having W or Y at all in the history: ---o---o---o---M---x---x-------x---- / @@ -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 093c656048..149508e13b 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. @@ -137,7 +137,7 @@ $ make clean test ;# make sure it did not cause other breakage. ------------------------------------------------ Everything is in the good order. I do not need the temporary branch -nor tag anymore, so remove them: +or tag anymore, so remove them: ------------------------------------------------ $ rm -f .git/refs/tags/pu-anchor @@ -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 6d3eb8ed00..bd1027433b 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 622ee5c8dd..f44e5e9458 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 . @@ -173,7 +181,7 @@ On Debian: Most tests should pass. -A command line tool to test WebDAV is cadaver. If you prefer GUIs, for +A command-line tool to test WebDAV is cadaver. If you prefer GUIs, for example, konqueror can open WebDAV URLs as "webdav://..." or "webdavs://...". @@ -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 b7f8d416d6..a5193b1e5c 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 4e2f75cb61..7af2e52cf3 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 2933056120..1ae8d1214e 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 index 98c0033a55..bbf040eda8 100644 --- a/Documentation/howto/using-signed-tag-in-pull-request.txt +++ b/Documentation/howto/using-signed-tag-in-pull-request.txt @@ -7,8 +7,8 @@ Abstract: Beginning v1.7.9, a contributor can push a signed tag to her later validate it. Content-type: text/asciidoc -Using signed tag in pull requests -================================= +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 @@ -23,7 +23,7 @@ Earlier, a typical pull request may have started like this: Froboz 3.2 (2011-09-30 14:20:57 -0700) - are available in the git repository at: + are available in the Git repository at: example.com:/git/froboz.git for-xyzzy ------------ @@ -107,7 +107,7 @@ The resulting msg.txt file begins like so: Froboz 3.2 (2011-09-30 14:20:57 -0700) - are available in the git repository at: + are available in the Git repository at: example.com:/git/froboz.git tags/frotz-for-xyzzy diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt index 625d3154ea..e9a1d5d25a 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-webdoc.sh b/Documentation/install-webdoc.sh index 76d69a907b..ed8b4ff3e5 100755 --- a/Documentation/install-webdoc.sh +++ b/Documentation/install-webdoc.sh @@ -18,17 +18,17 @@ do else echo >&2 "# install $h $T/$h" rm -f "$T/$h" - mkdir -p `dirname "$T/$h"` + mkdir -p $(dirname "$T/$h") cp "$h" "$T/$h" fi done -strip_leading=`echo "$T/" | sed -e 's|.|.|g'` +strip_leading=$(echo "$T/" | sed -e 's|.|.|g') for th in \ "$T"/*.html "$T"/*.txt \ "$T"/howto/*.txt "$T"/howto/*.html \ "$T"/technical/*.txt "$T"/technical/*.html do - h=`expr "$th" : "$strip_leading"'\(.*\)'` + h=$(expr "$th" : "$strip_leading"'\(.*\)') case "$h" in RelNotes-*.txt | index.html) continue ;; esac diff --git a/Documentation/line-range-format.txt b/Documentation/line-range-format.txt new file mode 100644 index 0000000000..d7f26039ca --- /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 288f04e70c..4a8c276529 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 861bd6f553..8a0e52f8ee 100644 --- a/Documentation/merge-config.txt +++ b/Documentation/merge-config.txt @@ -1,4 +1,4 @@ -merge.conflictstyle:: +merge.conflictStyle:: Specify the style in which conflicted hunks are written out to working tree files upon merge. The default is "merge", which shows a `<<<<<<<` conflict marker, changes made by one side, @@ -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 f2f1d0f51c..f08e9b80c5 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -8,14 +8,18 @@ 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). The `--edit` 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. + 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 @@ -24,13 +28,19 @@ 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:: @@ -53,23 +63,17 @@ merge. --squash:: --no-squash:: - Produce the working tree and index state as if a real - merge happened (except for the merge information), - but do not actually make a commit or - move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to - cause the next `git commit` command to create a merge - commit. This allows you to create a single commit on - top of the current branch whose effect is the same as - merging another branch (or more in case of an octopus). + Produce the working tree and index state as if a real merge + happened (except for the merge information), but do not actually + make a commit, move the `HEAD`, or record `$GIT_DIR/MERGE_HEAD` + (to cause the next `git commit` command to create a merge + commit). This allows you to create a single commit on top of + the current branch whose effect is the same as merging another + branch (or more in case of an octopus). + 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 @@ -83,6 +87,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 595a3cf1a7..7bbd19b300 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -1,10 +1,10 @@ MERGE STRATEGIES ---------------- -The merge mechanism ('git-merge' and 'git-pull' commands) allows the +The merge mechanism (`git merge` and `git pull` commands) allows the backend 'merge strategies' to be chosen with `-s` option. Some strategies can also take their own options, which can be passed by giving `-X<option>` -arguments to 'git-merge' and/or 'git-pull'. +arguments to `git merge` and/or `git pull`. resolve:: This can only resolve two heads (i.e. the current branch @@ -20,7 +20,7 @@ recursive:: merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without - causing mis-merges by tests done on actual merge commits + causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when @@ -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 880b6f2e6f..dcf7429a47 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -75,10 +75,10 @@ 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 +true parent commits, without taking grafts or history simplification into account. * 'format:<string>' @@ -95,7 +95,7 @@ would show something like this: The author of fe6e0ee was Junio C Hamano, 23 hours ago The title was >>t4119: test autocomputing -p<n> for traditional diff input.<< --------- +------- + The placeholders are: @@ -106,56 +106,90 @@ 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 +- '%ai': author date, ISO 8601-like format +- '%aI': author date, strict 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]) -- '%cd': committer date +- '%cE': committer email (respecting .mailmap, see + linkgit:git-shortlog[1] or linkgit:git-blame[1]) +- '%cd': committer date (format respects --date= option) - '%cD': committer date, RFC2822 style - '%cr': committer date, relative - '%ct': committer date, UNIX timestamp -- '%ci': committer date, ISO 8601 format +- '%ci': committer date, ISO 8601-like format +- '%cI': committer date, strict ISO 8601 format - '%d': ref names, like the --decorate option of linkgit:git-log[1] +- '%D': ref names without the " (", ")" wrapping. - '%e': encoding - '%s': subject - '%f': sanitized subject line, suitable for a filename - '%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]) +- '%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]) +- '%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 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. +`git log -g`). The `%d` and `%D` placeholders 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 2a3dc8664f..74aa01a0ec 100644 --- a/Documentation/pretty-options.txt +++ b/Documentation/pretty-options.txt @@ -3,9 +3,13 @@ Pretty-print the contents of the commit logs in a given format, where '<format>' can be one of 'oneline', 'short', 'medium', - 'full', 'fuller', 'email', 'raw' and 'format:<string>'. See - the "PRETTY FORMATS" section for some additional details for each - format. When omitted, the format defaults to 'medium'. + 'full', 'fuller', 'email', 'raw', 'format:<string>' + and 'tformat:<string>'. When '<format>' is none of the above, + and has '%placeholder' in it, it acts as if + '--pretty=tformat:<format>' were given. ++ +See the "PRETTY FORMATS" section for some additional details for each +format. When '=<format>' part is omitted, it defaults to 'medium'. + Note: you can specify the default pretty format in the repository configuration (see linkgit:git-config[1]). @@ -28,7 +32,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 @@ -39,7 +43,7 @@ people using 80-column terminals. Show the notes (see linkgit:git-notes[1]) that annotate the commit, when showing the commit log message. This is the default for `git log`, `git show` and `git whatchanged` commands when - there is no `--pretty`, `--format` nor `--oneline` option given + there is no `--pretty`, `--format`, or `--oneline` option given on the command line. + By default, the notes shown are from the notes refs listed in the @@ -66,3 +70,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 beba065252..0000000000 --- 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 5dd6e5a0c7..1ebbf1d738 100644 --- a/Documentation/pull-fetch-param.txt +++ b/Documentation/pull-fetch-param.txt @@ -12,9 +12,23 @@ ifndef::git-pull[] endif::git-pull[] <refspec>:: - The format of a <refspec> parameter is an optional plus - `{plus}`, followed by the source ref <src>, followed - by a colon `:`, followed by the destination ref <dst>. + Specifies which refs to fetch and which local refs to update. + When no <refspec>s appear on the command line, the refs to fetch + are read from `remote.<repository>.fetch` variables instead +ifndef::git-pull[] + (see <<CRTB,CONFIGURED REMOTE-TRACKING BRANCHES>> below). +endif::git-pull[] +ifdef::git-pull[] + (see linkgit:git-fetch[1]). +endif::git-pull[] ++ +The format of a <refspec> parameter is an optional plus +`+`, followed by the source ref <src>, followed +by a colon `:`, followed by the destination ref <dst>. +The colon can be omitted when <dst> is empty. ++ +`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`; +it requests fetching everything up to the given tag. + The remote ref that matches <src> is fetched, and if <dst> is not empty string, the local @@ -24,50 +38,34 @@ is updated even if it does not result in a fast-forward update. + [NOTE] -If the remote branch from which you want to pull is -modified in non-linear ways such as being rewound and -rebased frequently, then a pull will attempt a merge with -an older version of itself, likely conflict, and fail. -It is under these conditions that you would want to use -the `+` sign to indicate non-fast-forward updates will -be needed. There is currently no easy way to determine -or declare that a branch will be made available in a -repository with this behavior; the pulling user simply +When the remote branch you want to fetch is known to +be rewound and rebased regularly, it is expected that +its new tip will not be descendant of its previous tip +(as stored in your remote-tracking branch the last time +you fetched). You would want +to use the `+` sign to indicate non-fast-forward updates +will be needed for such branches. There is no way to +determine or declare that a branch will be made available +in a repository with this behavior; the pulling user simply must know this is the expected usage pattern for a branch. -+ -[NOTE] -You never do your own development on branches that appear -on the right hand side of a <refspec> colon on `Pull:` lines; -they are to be updated by 'git fetch'. If you intend to do -development derived from a remote branch `B`, have a `Pull:` -line to track it (i.e. `Pull: B:remote-B`), and have a separate -branch `my-B` to do your development on top of it. The latter -is created by `git branch my-B remote-B` (or its equivalent `git -checkout -b my-B remote-B`). Run `git fetch` to keep track of -the progress of the remote side, and when you see something new -on the remote branch, merge it into your development branch with -`git pull . remote-B`, while you are on `my-B` branch. +ifdef::git-pull[] + [NOTE] There is a difference between listing multiple <refspec> directly on 'git pull' command line and having multiple -`Pull:` <refspec> lines for a <repository> and running +`remote.<repository>.fetch` entries in your configuration +for a <repository> and running a 'git pull' command without any explicit <refspec> parameters. -<refspec> listed explicitly on the command line are always +<refspec>s listed explicitly on the command line are always merged into the current branch after fetching. In other words, -if you list more than one remote refs, you would be making -an Octopus. While 'git pull' run without any explicit <refspec> -parameter takes default <refspec>s from `Pull:` lines, it -merges only the first <refspec> found into the current branch, -after fetching all the remote refs. This is because making an +if you list more than one remote ref, 'git pull' will create +an Octopus merge. On the other hand, if you do not list any +explicit <refspec> parameter on the command line, 'git pull' +will fetch all the <refspec>s it finds in the +`remote.<repository>.fetch` configuration and merge +only the first <refspec> found into the current branch. +This is because making an Octopus from remote refs is rarely done, while keeping track of multiple remote heads in one-go by fetching more than one is often useful. -+ -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 +endif::git-pull[] diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 39e6207269..77ac439234 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -3,79 +3,103 @@ 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 is +matched as if it were 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. + +--invert-grep:: + Limit the commits output to ones with log message that do not + match the pattern specified with `--grep=<pattern>`. -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 +107,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. @@ -100,61 +123,73 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit). because merges into a topic branch tend to be only about adjusting to updated upstream from time to time, and this option allows you to ignore the individual commits - brought in to your history by such a merge. + brought in to your history by such a merge. Cannot be + combined with --bisect. --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 + accumulated 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. + +--reflog:: + Pretend as if all objects mentioned by reflogs are listed on the + command line as `<commit>`. +--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 - line. + line. Cannot be combined with --first-parent. 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 +197,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 +242,37 @@ 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). + and '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 excluded boundary commits. Boundary commits are + prefixed with `-`. - Output uninteresting commits at the boundary, which are usually - not shown. +ifdef::git-rev-list[] +--use-bitmap-index:: + + Try to speed up the traversal using the pack bitmap index (if + one is available). Note that when traversing with `--objects`, + trees and blobs will not have their associated path printed. +endif::git-rev-list[] -- @@ -252,11 +287,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 +297,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 +334,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". Despite appearing interesting, `P` is - TREESAME to all parents. +* `E` changes `quux` to ``xyzzy'', and its merge `P` combines the + strings to ``quux xyzzy''. `P` is TREESAME to `O`, but not to `E`. -'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 +* `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 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 +391,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 +403,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 +415,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 +460,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 +470,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 +480,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 +488,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 +515,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 +533,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 +546,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. +one. Cannot be combined with --first-parent. --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 +603,87 @@ 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. +ifdef::git-rev-list[] --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 a ``thin'' pack, which records objects in deltified form based on objects contained in these excluded commits to reduce network traffic. ---unpacked:: +--objects-edge-aggressive:: + Similar to `--objects-edge`, but it tries harder to find excluded + commits at the cost of increased time. This is used instead of + `--objects-edge` to build ``thin'' packs for shallow repositories. - Only useful with '--objects'; print the object IDs that are not - in packs. +--indexed-objects:: + Pretend as if all trees and blobs used by the index are listed + on the command line. Note that you probably want to use + `--objects`, too. ---no-walk:: +--unpacked:: + Only useful with `--objects`; print the object IDs that are not + in packs. +endif::git-rev-list[] - 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. + Cannot be combined with `--graph`. --do-walk:: - - Overrides a previous --no-walk. + Overrides a previous `--no-walk`. Commit Formatting ~~~~~~~~~~~~~~~~~ @@ -639,46 +697,50 @@ endif::git-rev-list[] include::pretty-options.txt[] --relative-date:: - Synonym for `--date=relative`. ---date=(relative|local|default|iso|rfc|short|raw):: - +--date=(relative|local|default|iso|iso-strict|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 a ISO 8601-like format. +The differences to the strict ISO 8601 format are: + + - a space instead of the `T` date/time delimiter + - a space between time and time zone + - no colon between hours and minutes of the time zone + + -`--date=iso` (or `--date=iso8601`) shows timestamps in ISO 8601 format. +`--date=iso-strict` (or `--date=iso8601-strict`) shows timestamps in strict +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 +750,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,39 +779,44 @@ 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 to be drawn properly. + Cannot be combined with `--no-walk`. + 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. + +--show-linear-break[=<barrier>]:: + When --graph is not used, all history branches are flattened + which can make it hard to see that the two consecutive commits + do not belong to a linear branch. This option puts a barrier + in between them in that case. If `<barrier>` is specified, it + is the string that will be shown instead of the default one. 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 +824,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 b290b617d4..07961185fe 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,15 @@ 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 (configured with `branch.<name>.remote` and + `branch.<name>.merge`). 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 +108,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 +116,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 +232,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/technical/api-allocation-growing.txt b/Documentation/technical/api-allocation-growing.txt index 43dbe09f73..5a59b54844 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,25 @@ 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. + +If you need to specify the number of elements to allocate explicitly +then use the macro `REALLOC_ARRAY(item, alloc)` instead of `ALLOC_GROW`. diff --git a/Documentation/technical/api-argv-array.txt b/Documentation/technical/api-argv-array.txt index 49b3d52952..1a797812fb 100644 --- a/Documentation/technical/api-argv-array.txt +++ b/Documentation/technical/api-argv-array.txt @@ -37,10 +37,19 @@ Functions `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. diff --git a/Documentation/technical/api-builtin.txt b/Documentation/technical/api-builtin.txt index b0cafe87be..22a39b9299 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,19 +14,22 @@ 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> }, + where options is the bitwise-or of: `RUN_SETUP`:: + If there is not a Git directory to work on, abort. 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. - 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. +`RUN_SETUP_GENTLY`:: + If there is a Git directory, chdir as per RUN_SETUP, otherwise, + don't chdir anywhere. `USE_PAGER`:: @@ -39,7 +42,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 0000000000..0d8b99b368 --- /dev/null +++ b/Documentation/technical/api-config.txt @@ -0,0 +1,324 @@ +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`. + +Querying For Specific Variables +------------------------------- + +For programs wanting to query for specific variables in a non-callback +manner, the config API provides two functions `git_config_get_value` +and `git_config_get_value_multi`. They both read values from an internal +cache generated previously from reading the config files. + +`int git_config_get_value(const char *key, const char **value)`:: + + Finds the highest-priority value for the configuration variable `key`, + stores the pointer to it in `value` and returns 0. When the + configuration variable `key` is not found, returns 1 without touching + `value`. The caller should not free or modify `value`, as it is owned + by the cache. + +`const struct string_list *git_config_get_value_multi(const char *key)`:: + + Finds and returns the value list, sorted in order of increasing priority + for the configuration variable `key`. When the configuration variable + `key` is not found, returns NULL. The caller should not free or modify + the returned pointer, as it is owned by the cache. + +`void git_config_clear(void)`:: + + Resets and invalidates the config cache. + +The config API also provides type specific API functions which do conversion +as well as retrieval for the queried variable, including: + +`int git_config_get_int(const char *key, int *dest)`:: + + Finds and parses the value to an integer for the configuration variable + `key`. Dies on error; otherwise, stores the value of the parsed integer in + `dest` and returns 0. When the configuration variable `key` is not found, + returns 1 without touching `dest`. + +`int git_config_get_ulong(const char *key, unsigned long *dest)`:: + + Similar to `git_config_get_int` but for unsigned longs. + +`int git_config_get_bool(const char *key, int *dest)`:: + + Finds and parses the value into a boolean value, for the configuration + variable `key` 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, + stores the value of the parsed result in `dest` and returns 0. When the + configuration variable `key` is not found, returns 1 without touching + `dest`. + +`int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest)`:: + + Similar to `git_config_get_bool`, except that integers are copied as-is, + and `is_bool` flag is unset. + +`int git_config_get_maybe_bool(const char *key, int *dest)`:: + + Similar to `git_config_get_bool`, except that it returns -1 on error + rather than dying. + +`int git_config_get_string_const(const char *key, const char **dest)`:: + + Allocates and copies the retrieved string into the `dest` parameter for + the configuration variable `key`; if NULL string is given, prints an + error message and returns -1. When the configuration variable `key` is + not found, returns 1 without touching `dest`. + +`int git_config_get_string(const char *key, char **dest)`:: + + Similar to `git_config_get_string_const`, except that retrieved value + copied into the `dest` parameter is a mutable string. + +`int git_config_get_pathname(const char *key, const char **dest)`:: + + Similar to `git_config_get_string`, but expands `~` or `~user` into + the user's home directory when found at the beginning of the path. + +`git_die_config(const char *key, const char *err, ...)`:: + + First prints the error message specified by the caller in `err` and then + dies printing the line number and the file name of the highest priority + value for the configuration variable `key`. + +`void git_die_config_linenr(const char *key, const char *filename, int linenr)`:: + + Helper function which formats the die error message according to the + parameters entered. Used by `git_die_config()`. It can be used by callers + handling `git_config_get_value_multi()` to print the correct error message + for the desired value. + +See test-config.c for usage examples. + +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. + +Custom Configsets +----------------- + +A `config_set` can be used to construct an in-memory cache for +config-like files that the caller specifies (i.e., files like `.gitmodules`, +`~/.gitconfig` etc.). For example, + +--------------------------------------- +struct config_set gm_config; +git_configset_init(&gm_config); +int b; +/* we add config files to the config_set */ +git_configset_add_file(&gm_config, ".gitmodules"); +git_configset_add_file(&gm_config, ".gitmodules_alt"); + +if (!git_configset_get_bool(gm_config, "submodule.frotz.ignore", &b)) { + /* hack hack hack */ +} + +/* when we are done with the configset */ +git_configset_clear(&gm_config); +---------------------------------------- + +Configset API provides functions for the above mentioned work flow, including: + +`void git_configset_init(struct config_set *cs)`:: + + Initializes the config_set `cs`. + +`int git_configset_add_file(struct config_set *cs, const char *filename)`:: + + Parses the file and adds the variable-value pairs to the `config_set`, + dies if there is an error in parsing the file. Returns 0 on success, or + -1 if the file does not exist or is inaccessible. The user has to decide + if he wants to free the incomplete configset or continue using it when + the function returns -1. + +`int git_configset_get_value(struct config_set *cs, const char *key, const char **value)`:: + + Finds the highest-priority value for the configuration variable `key` + and config set `cs`, stores the pointer to it in `value` and returns 0. + When the configuration variable `key` is not found, returns 1 without + touching `value`. The caller should not free or modify `value`, as it + is owned by the cache. + +`const struct string_list *git_configset_get_value_multi(struct config_set *cs, const char *key)`:: + + Finds and returns the value list, sorted in order of increasing priority + for the configuration variable `key` and config set `cs`. When the + configuration variable `key` is not found, returns NULL. The caller + should not free or modify the returned pointer, as it is owned by the cache. + +`void git_configset_clear(struct config_set *cs)`:: + + Clears `config_set` structure, removes all saved variable-value pairs. + +In addition to above functions, the `config_set` API provides type specific +functions in the vein of `git_config_get_int` and family but with an extra +parameter, pointer to struct `config_set`. +They all behave similarly to the `git_config_get*()` family described in +"Querying For Specific Variables" above. + +Writing Config Files +-------------------- + +Git gives multiple entry points in the Config API to write config values to +files namely `git_config_set_in_file` and `git_config_set`, which write to +a specific config file or to `.git/config` respectively. They both take a +key/value pair as parameter. +In the end they both call `git_config_set_multivar_in_file` which takes four +parameters: + +- the name of the file, as a string, to which key/value pairs will be written. + +- the name of key, as a string. 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 variable, as a string. If value is equal to NULL, it will + remove the matching key from the config file. + +- the value regex, as a string. It will disregard key/value pairs where value + does not match. + +- a multi_replace value, as an int. If value is equal to zero, nothing or only + one matching key/value is replaced, else all matching key/values (regardless + how many) are removed, before the new pair is written. + +It returns 0 on success. + +Also, there are functions `git_config_rename_section` and +`git_config_rename_section_in_file` with parameters `old_name` and `new_name` +for renaming or removing sections in the config files. If NULL is passed +through `new_name` parameter, the section will be removed from the config file. diff --git a/Documentation/technical/api-credentials.txt b/Documentation/technical/api-credentials.txt index 21ca6a2553..e44426dd04 100644 --- a/Documentation/technical/api-credentials.txt +++ b/Documentation/technical/api-credentials.txt @@ -6,8 +6,52 @@ 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`:: @@ -21,14 +65,17 @@ Data Structures 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. +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`:: @@ -72,7 +119,7 @@ Functions 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: @@ -113,7 +160,7 @@ int foo_login(struct foo_connection *f) break; default: /* - * Some other error occured. We don't know if the + * Some other error occurred. We don't know if the * credential is good or bad, so report nothing to the * credential subsystem. */ @@ -130,13 +177,15 @@ int foo_login(struct foo_connection *f) Credential Helpers ------------------ -Credential helpers are programs executed by git to fetch or save +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 +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. The string is transformed -by git into a command to be executed using these rules: +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. @@ -192,47 +241,17 @@ appended to its command line, which is one of: 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 credential is split into a set of named attributes. -Attributes are provided to the helper, one 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 will send the following attributes (but may not send all of -them for a given credential; for example, a `host` attribute makes no -sense when dealing with a non-network protocol): - -`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. +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. +attributes will overwrite those already known about by Git. If a helper +outputs a `quit` attribute with a value of `true` or `1`, no further +helpers will be consulted, nor will the user be prompted (if no +credential has been provided, the operation will then fail). For a `store` or `erase` operation, the helper's output is ignored. If it fails to perform the requested operation, it may complain to @@ -243,3 +262,10 @@ 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 2d2ebc04b7..8b001de0db 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 add6f435b5..7f8e78d916 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-error-handling.txt b/Documentation/technical/api-error-handling.txt new file mode 100644 index 0000000000..ceeedd485c --- /dev/null +++ b/Documentation/technical/api-error-handling.txt @@ -0,0 +1,75 @@ +Error reporting in git +====================== + +`die`, `usage`, `error`, and `warning` report errors of various +kinds. + +- `die` is for fatal application errors. It prints a message to + the user and exits with status 128. + +- `usage` is for errors in command line usage. After printing its + message, it exits with status 129. (See also `usage_with_options` + in the link:api-parse-options.html[parse-options API].) + +- `error` is for non-fatal library errors. It prints a message + to the user and returns -1 for convenience in signaling the error + to the caller. + +- `warning` is for reporting situations that probably should not + occur but which the user (and Git) can continue to work around + without running into too many problems. Like `error`, it + returns -1 after reporting the situation to the caller. + +Customizable error handlers +--------------------------- + +The default behavior of `die` and `error` is to write a message to +stderr and then exit or return as appropriate. This behavior can be +overridden using `set_die_routine` and `set_error_routine`. For +example, "git daemon" uses set_die_routine to write the reason `die` +was called to syslog before exiting. + +Library errors +-------------- + +Functions return a negative integer on error. Details beyond that +vary from function to function: + +- Some functions return -1 for all errors. Others return a more + specific value depending on how the caller might want to react + to the error. + +- Some functions report the error to stderr with `error`, + while others leave that for the caller to do. + +- errno is not meaningful on return from most functions (except + for thin wrappers for system calls). + +Check the function's API documentation to be sure. + +Caller-handled errors +--------------------- + +An increasing number of functions take a parameter 'struct strbuf *err'. +On error, such functions append a message about what went wrong to the +'err' strbuf. The message is meant to be complete enough to be passed +to `die` or `error` as-is. For example: + + if (ref_transaction_commit(transaction, &err)) + die("%s", err.buf); + +The 'err' parameter will be untouched if no error occurred, so multiple +function calls can be chained: + + t = ref_transaction_begin(&err); + if (!t || + ref_transaction_update(t, "HEAD", ..., &err) || + ret_transaction_commit(t, &err)) + die("%s", err.buf); + +The 'err' parameter must be a pointer to a valid strbuf. To silence +a message, pass a strbuf that is explicitly ignored: + + if (thing_that_can_fail_in_an_ignorable_way(..., &err)) + /* This failure is okay. */ + strbuf_reset(&err); diff --git a/Documentation/technical/api-gitattributes.txt b/Documentation/technical/api-gitattributes.txt index ce363b6305..2602668677 100644 --- a/Documentation/technical/api-gitattributes.txt +++ b/Documentation/technical/api-gitattributes.txt @@ -99,7 +99,7 @@ static void setup_check(void) The attribute is Unset, by listing the name of the attribute prefixed with a dash - for the path. } else if (ATTR_UNSET(value)) { - The attribute is not set nor unset for the path. + The attribute is neither set nor unset for the path. } else if (!strcmp(value, "input")) { If none of ATTR_TRUE(), ATTR_FALSE(), or ATTR_UNSET() is true, the value is a string set in the gitattributes diff --git a/Documentation/technical/api-hash.txt b/Documentation/technical/api-hash.txt deleted file mode 100644 index e5061e0677..0000000000 --- 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 0000000000..ad7a5bddd2 --- /dev/null +++ b/Documentation/technical/api-hashmap.txt @@ -0,0 +1,280 @@ +hashmap API +=========== + +The hashmap API is a generic implementation of hash-based key-value mappings. + +Data Structures +--------------- + +`struct hashmap`:: + + The hash table structure. Members can be used as follows, but should + not be modified directly: ++ +The `size` member keeps track of the total number of entries (0 means the +hashmap is empty). ++ +`tablesize` is the allocated size of the hash table. A non-0 value indicates +that the hashmap is initialized. It may also be useful for statistical purposes +(i.e. `size / tablesize` is the current load factor). ++ +`cmpfn` stores the comparison function specified in `hashmap_init()`. In +advanced scenarios, it may be useful to change this, e.g. to switch between +case-sensitive and case-insensitive lookup. + +`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. + +`unsigned int sha1hash(const unsigned char *sha1)`:: + + Converts a cryptographic hash (e.g. SHA-1) into an int-sized hash code + for use in hash tables. Cryptographic hashes are supposed to have + uniform distribution, so in contrast to `memhash()`, this just copies + the first `sizeof(int)` bytes without shuffling any bits. Note that + the results will be different on big-endian and little-endian + platforms, so they should not be stored or transferred over the net. + +`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_from_hash(const struct hashmap *map, unsigned int hash, const void *keydata)`:: + + Returns the hashmap entry for the specified hash code and key data, + or NULL if not found. ++ +`map` is the hashmap structure. ++ +`hash` is the hash code of the entry to look up. ++ +If an entry with matching hash code is found, `keydata` is passed to +`hashmap_cmp_fn` to decide whether the entry matches the key. The +`entry_or_key` parameter points to a bogus hashmap_entry structure that +should not be used in the comparison. + +`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). + +`const char *strintern(const char *string)`:: +`const void *memintern(const void *data, size_t len)`:: + + Returns the unique, interned version of the specified string or data, + similar to the `String.intern` API in Java and .NET, respectively. + Interned strings remain valid for the entire lifetime of the process. ++ +Can be used as `[x]strdup()` or `xmemdupz` replacement, except that interned +strings / data must not be modified or freed. ++ +Interned strings are best used for short strings with high probability of +duplicates. ++ +Uses a hashmap to store the pool of interned strings. + +Usage example +------------- + +Here's a simple usage example that maps long keys to double values. +------------ +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 d6fc90ac7e..18142b6d29 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 af7cc2e395..eda8c195c1 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-lockfile.txt b/Documentation/technical/api-lockfile.txt index dd894043ae..93b5f23e4c 100644 --- a/Documentation/technical/api-lockfile.txt +++ b/Documentation/technical/api-lockfile.txt @@ -3,20 +3,132 @@ lockfile API The lockfile API serves two purposes: -* Mutual exclusion. When we write out a new index file, first - we create a new file `$GIT_DIR/index.lock`, write the new - contents into it, and rename it to the final destination - `$GIT_DIR/index`. We try to create the `$GIT_DIR/index.lock` - file with O_EXCL so that we can notice and fail when somebody - else is already trying to update the index file. - -* Automatic cruft removal. After we create the "lock" file, we - may decide to `die()`, and we would want to make sure that we - remove the file that has not been committed to its final - destination. This is done by remembering the lockfiles we - created in a linked list and cleaning them up from an - `atexit(3)` handler. Outstanding lockfiles are also removed - when the program dies on a signal. +* Mutual exclusion and atomic file updates. When we want to change a + file, we create a lockfile `<filename>.lock`, write the new file + contents into it, and then rename the lockfile to its final + destination `<filename>`. We create the `<filename>.lock` file with + `O_CREAT|O_EXCL` so that we can notice and fail if somebody else has + already locked the file, then atomically rename the lockfile to its + final destination to commit the changes and unlock the file. + +* Automatic cruft removal. If the program exits after we lock a file + but before the changes have been committed, we want to make sure + that we remove the lockfile. This is done by remembering the + lockfiles we have created in a linked list and setting up an + `atexit(3)` handler and a signal handler that clean up the + lockfiles. This mechanism ensures that outstanding lockfiles are + cleaned up if the program exits (including when `die()` is called) + or if the program dies on a signal. + +Please note that lockfiles only block other writers. Readers do not +block, but they are guaranteed to see either the old contents of the +file or the new contents of the file (assuming that the filesystem +implements `rename(2)` atomically). + + +Calling sequence +---------------- + +The caller: + +* Allocates a `struct lock_file` either as a static variable or on the + heap, initialized to zeros. Once you use the structure to call the + `hold_lock_file_*` family of functions, it belongs to the lockfile + subsystem and its storage must remain valid throughout the life of + the program (i.e. you cannot use an on-stack variable to hold this + structure). + +* Attempts to create a lockfile by passing that variable and the path + of the final destination (e.g. `$GIT_DIR/index`) to + `hold_lock_file_for_update` or `hold_lock_file_for_append`. + +* Writes new content for the destination file by either: + + * writing to the file descriptor returned by the `hold_lock_file_*` + functions (also available via `lock->fd`). + + * calling `fdopen_lock_file` to get a `FILE` pointer for the open + file and writing to the file using stdio. + +When finished writing, the caller can: + +* Close the file descriptor and rename the lockfile to its final + destination by calling `commit_lock_file` or `commit_lock_file_to`. + +* Close the file descriptor and remove the lockfile by calling + `rollback_lock_file`. + +* Close the file descriptor without removing or renaming the lockfile + by calling `close_lock_file`, and later call `commit_lock_file`, + `commit_lock_file_to`, `rollback_lock_file`, or `reopen_lock_file`. + +Even after the lockfile is committed or rolled back, the `lock_file` +object must not be freed or altered by the caller. However, it may be +reused; just pass it to another call of `hold_lock_file_for_update` or +`hold_lock_file_for_append`. + +If the program exits before you have called one of `commit_lock_file`, +`commit_lock_file_to`, `rollback_lock_file`, or `close_lock_file`, an +`atexit(3)` handler will close and remove the lockfile, rolling back +any uncommitted changes. + +If you need to close the file descriptor you obtained from a +`hold_lock_file_*` function yourself, do so by calling +`close_lock_file`. You should never call `close(2)` or `fclose(3)` +yourself! Otherwise the `struct lock_file` structure would still think +that the file descriptor needs to be closed, and a commit or rollback +would result in duplicate calls to `close(2)`. Worse yet, if you close +and then later open another file descriptor for a completely different +purpose, then a commit or rollback might close that unrelated file +descriptor. + + +Error handling +-------------- + +The `hold_lock_file_*` functions return a file descriptor on success +or -1 on failure (unless `LOCK_DIE_ON_ERROR` is used; see below). On +errors, `errno` describes the reason for failure. Errors can be +reported by passing `errno` to one of the following helper functions: + +unable_to_lock_message:: + + Append an appropriate error message to a `strbuf`. + +unable_to_lock_error:: + + Emit an appropriate error message using `error()`. + +unable_to_lock_die:: + + Emit an appropriate error message and `die()`. + +Similarly, `commit_lock_file`, `commit_lock_file_to`, and +`close_lock_file` return 0 on success. On failure they set `errno` +appropriately, do their best to roll back the lockfile, and return -1. + + +Flags +----- + +The following flags can be passed to `hold_lock_file_for_update` or +`hold_lock_file_for_append`: + +LOCK_NO_DEREF:: + + Usually symbolic links in the destination path are resolved + and the lockfile is created by adding ".lock" to the resolved + path. If `LOCK_NO_DEREF` is set, then the lockfile is created + by adding ".lock" to the path argument itself. This option is + used, for example, when locking a symbolic reference, which + for backwards-compatibility reasons can be a symbolic link + containing the name of the referred-to-reference. + +LOCK_DIE_ON_ERROR:: + + If a lock is already taken for the file, `die()` with an error + message. If this option is not specified, trying to lock a + file that is already locked returns -1 to the caller. The functions @@ -24,51 +136,85 @@ The functions hold_lock_file_for_update:: - Take a pointer to `struct lock_file`, the filename of - the final destination (e.g. `$GIT_DIR/index`) and a flag - `die_on_error`. Attempt to create a lockfile for the - destination and return the file descriptor for writing - to the file. If `die_on_error` flag is true, it dies if - a lock is already taken for the file; otherwise it - returns a negative integer to the caller on failure. + Take a pointer to `struct lock_file`, the path of the file to + be locked (e.g. `$GIT_DIR/index`) and a flags argument (see + above). Attempt to create a lockfile for the destination and + return the file descriptor for writing to the file. + +hold_lock_file_for_append:: + + Like `hold_lock_file_for_update`, but before returning copy + the existing contents of the file (if any) to the lockfile and + position its write pointer at the end of the file. + +fdopen_lock_file:: + + Associate a stdio stream with the lockfile. Return NULL + (*without* rolling back the lockfile) on error. The stream is + closed automatically when `close_lock_file` is called or when + the file is committed or rolled back. + +get_locked_file_path:: + + Return the path of the file that is locked by the specified + lock_file object. The caller must free the memory. commit_lock_file:: - Take a pointer to the `struct lock_file` initialized - with an earlier call to `hold_lock_file_for_update()`, - close the file descriptor and rename the lockfile to its - final destination. Returns 0 upon success, a negative - value on failure to close(2) or rename(2). + Take a pointer to the `struct lock_file` initialized with an + earlier call to `hold_lock_file_for_update` or + `hold_lock_file_for_append`, close the file descriptor, and + rename the lockfile to its final destination. Return 0 upon + success. On failure, roll back the lock file and return -1, + with `errno` set to the value from the failing call to + `close(2)` or `rename(2)`. It is a bug to call + `commit_lock_file` for a `lock_file` object that is not + currently locked. + +commit_lock_file_to:: + + Like `commit_lock_file()`, except that it takes an explicit + `path` argument to which the lockfile should be renamed. The + `path` must be on the same filesystem as the lock file. rollback_lock_file:: - Take a pointer to the `struct lock_file` initialized - with an earlier call to `hold_lock_file_for_update()`, - close the file descriptor and remove the lockfile. + Take a pointer to the `struct lock_file` initialized with an + earlier call to `hold_lock_file_for_update` or + `hold_lock_file_for_append`, close the file descriptor and + remove the lockfile. It is a NOOP to call + `rollback_lock_file()` for a `lock_file` object that has + already been committed or rolled back. close_lock_file:: - Take a pointer to the `struct lock_file` initialized - with an earlier call to `hold_lock_file_for_update()`, - and close the file descriptor. Returns 0 upon success, - a negative value on failure to close(2). - -Because the structure is used in an `atexit(3)` handler, its -storage has to stay throughout the life of the program. It -cannot be an auto variable allocated on the stack. - -Call `commit_lock_file()` or `rollback_lock_file()` when you are -done writing to the file descriptor. If you do not call either -and simply `exit(3)` from the program, an `atexit(3)` handler -will close and remove the lockfile. - -If you need to close the file descriptor you obtained from -`hold_lock_file_for_update` function yourself, do so by calling -`close_lock_file()`. You should never call `close(2)` yourself! -Otherwise the `struct -lock_file` structure still remembers that the file descriptor -needs to be closed, and a later call to `commit_lock_file()` or -`rollback_lock_file()` will result in duplicate calls to -`close(2)`. Worse yet, if you `close(2)`, open another file -descriptor for completely different purpose, and then call -`commit_lock_file()` or `rollback_lock_file()`, they may close -that unrelated file descriptor. + + Take a pointer to the `struct lock_file` initialized with an + earlier call to `hold_lock_file_for_update` or + `hold_lock_file_for_append`. Close the file descriptor (and + the file pointer if it has been opened using + `fdopen_lock_file`). Return 0 upon success. On failure to + `close(2)`, return a negative value and roll back the lock + file. Usually `commit_lock_file`, `commit_lock_file_to`, or + `rollback_lock_file` should eventually be called if + `close_lock_file` succeeds. + +reopen_lock_file:: + + Re-open a lockfile that has been closed (using + `close_lock_file`) but not yet committed or rolled back. This + can be used to implement a sequence of operations like the + following: + + * Lock file. + + * Write new contents to lockfile, then `close_lock_file` to + cause the contents to be written to disk. + + * Pass the name of the lockfile to another program to allow it + (and nobody else) to inspect the contents you wrote, while + still holding the lock yourself. + + * `reopen_lock_file` to reopen the lockfile. Make further + updates to the contents. + + * `commit_lock_file` to make the final version permanent. diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt index 4b92514f60..1f2db31312 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,22 +116,22 @@ 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 @@ -157,10 +160,6 @@ There are some macros to easily define options: `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. - If used, set `ptr_var` to `ptr`. - `OPT_STRING(short, long, &str_var, arg_str, description)`:: Introduce an option with string argument. The string argument is put into `str_var`. @@ -173,6 +172,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` @@ -215,10 +218,10 @@ 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, @@ -242,10 +245,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 @@ -268,10 +271,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 dbbea95db7..02adfd45d3 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 c54b17db69..5d245aa9d1 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 996da0503a..55b878ade8 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 f18b4f4817..a9fdb45b93 100644 --- a/Documentation/technical/api-run-command.txt +++ b/Documentation/technical/api-run-command.txt @@ -13,6 +13,10 @@ produces in the caller in order to process it. Functions --------- +`child_process_init`:: + + Initialize a struct child_process variable. + `start_command`:: Start a sub-process. Takes a pointer to a `struct child_process` @@ -55,10 +59,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`:: @@ -98,8 +100,8 @@ command to run in a sub-process. The caller: -1. allocates and clears (memset(&chld, 0, sizeof(chld));) a - struct child_process variable; +1. allocates and clears (using child_process_init() or + CHILD_PROCESS_INIT) a struct child_process variable; 2. initializes the members; 3. calls start_command(); 4. processes the data; @@ -111,6 +113,13 @@ terminated), of which .argv[0] is the program name to run (usually without a path). If the command to run is a git command, set argv[0] to the command name without the 'git-' prefix and set .git_cmd = 1. +Note that the ownership of the memory pointed to by .argv stays with the +caller, but it should survive until `finish_command` completes. If the +.argv member is NULL, `start_command` will point it at the .args +`argv_array` (so you may use one or the other, but you must use exactly +one). The memory in .args will be cleaned up automatically during +`finish_command` (or during `start_command` when it is unsuccessful). + The members .in, .out, .err are used to redirect stdin, stdout, stderr as follows: @@ -160,6 +169,11 @@ string pointers (NULL terminated) in .env: . If the string does not contain '=', it names an environment variable that will be removed from the child process's environment. +If the .env member is NULL, `start_command` will point it at the +.env_array `argv_array` (so you may use one or the other, but not both). +The memory in .env_array will be cleaned up automatically during +`finish_command` (or during `start_command` when it is unsuccessful). + To specify a new initial working directory for the sub-process, specify it in the .dir member. diff --git a/Documentation/technical/api-setup.txt b/Documentation/technical/api-setup.txt index 4f63a04d7d..540e455689 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 index 4a4bae8109..3e75497a37 100644 --- a/Documentation/technical/api-sha1-array.txt +++ b/Documentation/technical/api-sha1-array.txt @@ -1,7 +1,7 @@ sha1-array API ============== -The sha1-array API provides storage and manipulation of sets of SHA1 +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. @@ -11,7 +11,7 @@ Data Structures `struct sha1_array`:: - A single array of SHA1 hashes. This should be initialized by + 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, @@ -25,9 +25,6 @@ Functions the array (but note that some operations below may lose this ordering). -`sha1_array_sort`:: - Sort the elements in the array. - `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 diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt deleted file mode 100644 index afe2759951..0000000000 --- a/Documentation/technical/api-strbuf.txt +++ /dev/null @@ -1,272 +0,0 @@ -strbuf API -========== - -strbuf's are meant to be used with all the usual C string and memory -APIs. Given that the length of the buffer is known, it's often better to -use the mem* functions than a str* one (memchr vs. strchr e.g.). -Though, one has to be careful about the fact that str* functions often -stop on NULs and that strbufs may have embedded NULs. - -An strbuf is NUL terminated for convenience, but no function in the -strbuf API actually relies on the string being free of NULs. - -strbufs has some invariants that are very important to keep in mind: - -. The `buf` member is never NULL, so it can be used in any usual C -string operations safely. strbuf's _have_ to be initialized either by -`strbuf_init()` or by `= STRBUF_INIT` before the invariants, though. -+ -Do *not* assume anything on what `buf` really is (e.g. if it is -allocated memory or not), use `strbuf_detach()` to unwrap a memory -buffer from its strbuf shell in a safe way. That is the sole supported -way. This will give you a malloced buffer that you can later `free()`. -+ -However, it is totally safe to modify anything in the string pointed by -the `buf` member, between the indices `0` and `len-1` (inclusive). - -. The `buf` member is a byte array that has at least `len + 1` bytes - allocated. The extra byte is used to store a `'\0'`, allowing the - `buf` member to be a valid C-string. Every strbuf function ensure this - invariant is preserved. -+ -NOTE: It is OK to "play" with the buffer directly if you work it this - way: -+ ----- -strbuf_grow(sb, SOME_SIZE); <1> -strbuf_setlen(sb, sb->len + SOME_OTHER_SIZE); ----- -<1> Here, the memory array starting at `sb->buf`, and of length -`strbuf_avail(sb)` is all yours, and you can be sure that -`strbuf_avail(sb)` is at least `SOME_SIZE`. -+ -NOTE: `SOME_OTHER_SIZE` must be smaller or equal to `strbuf_avail(sb)`. -+ -Doing so is safe, though if it has to be done in many places, adding the -missing API to the strbuf module is the way to go. -+ -WARNING: Do _not_ assume that the area that is yours is of size `alloc -- 1` even if it's true in the current implementation. Alloc is somehow a -"private" member that should not be messed with. Use `strbuf_avail()` -instead. - -Data structures ---------------- - -* `struct strbuf` - -This is the string buffer structure. The `len` member can be used to -determine the current length of the string, and `buf` member provides access to -the string itself. - -Functions ---------- - -* Life cycle - -`strbuf_init`:: - - Initialize the structure. The second parameter can be zero or a bigger - number to allocate memory, in case you want to prevent further reallocs. - -`strbuf_release`:: - - Release a string buffer and the memory it used. You should not use the - string buffer after using this function, unless you initialize it again. - -`strbuf_detach`:: - - Detach the string from the strbuf and returns it; you now own the - storage the string occupies and it is your responsibility from then on - to release it with `free(3)` when you are done with it. - -`strbuf_attach`:: - - Attach a string to a buffer. You should specify the string to attach, - the current length of the string and the amount of allocated memory. - The amount must be larger than the string length, because the string you - pass is supposed to be a NUL-terminated string. This string _must_ be - malloc()ed, and after attaching, the pointer cannot be relied upon - anymore, and neither be free()d directly. - -`strbuf_swap`:: - - Swap the contents of two string buffers. - -* Related to the size of the buffer - -`strbuf_avail`:: - - Determine the amount of allocated but unused memory. - -`strbuf_grow`:: - - Ensure that at least this amount of unused memory is available after - `len`. This is used when you know a typical size for what you will add - and want to avoid repetitive automatic resizing of the underlying buffer. - This is never a needed operation, but can be critical for performance in - some cases. - -`strbuf_setlen`:: - - Set the length of the buffer to a given value. This function does *not* - allocate new memory, so you should not perform a `strbuf_setlen()` to a - length that is larger than `len + strbuf_avail()`. `strbuf_setlen()` is - just meant as a 'please fix invariants from this strbuf I just messed - with'. - -`strbuf_reset`:: - - Empty the buffer by setting the size of it to zero. - -* Related to the contents of the buffer - -`strbuf_rtrim`:: - - Strip whitespace from the end of a string. - -`strbuf_cmp`:: - - Compare two buffers. Returns an integer less than, equal to, or greater - than zero if the first buffer is found, respectively, to be less than, - to match, or be greater than the second buffer. - -* Adding data to the buffer - -NOTE: All of the functions in this section will grow the buffer as necessary. -If they fail for some reason other than memory shortage and the buffer hadn't -been allocated before (i.e. the `struct strbuf` was set to `STRBUF_INIT`), -then they will free() it. - -`strbuf_addch`:: - - Add a single character to the buffer. - -`strbuf_insert`:: - - Insert data to the given position of the buffer. The remaining contents - will be shifted, not overwritten. - -`strbuf_remove`:: - - Remove given amount of data from a given position of the buffer. - -`strbuf_splice`:: - - Remove the bytes between `pos..pos+len` and replace it with the given - data. - -`strbuf_add`:: - - Add data of given length to the buffer. - -`strbuf_addstr`:: - -Add a NUL-terminated string to the buffer. -+ -NOTE: This function will *always* be implemented as an inline or a macro -that expands to: -+ ----- -strbuf_add(..., s, strlen(s)); ----- -+ -Meaning that this is efficient to write things like: -+ ----- -strbuf_addstr(sb, "immediate string"); ----- - -`strbuf_addbuf`:: - - Copy the contents of an other buffer at the end of the current one. - -`strbuf_adddup`:: - - Copy part of the buffer from a given position till a given length to the - end of the buffer. - -`strbuf_expand`:: - - This function can be used to expand a format string containing - placeholders. To that end, it parses the string and calls the specified - function for every percent sign found. -+ -The callback function is given a pointer to the character after the `%` -and a pointer to the struct strbuf. It is expected to add the expanded -version of the placeholder to the strbuf, e.g. to add a newline -character if the letter `n` appears after a `%`. The function returns -the length of the placeholder recognized and `strbuf_expand()` skips -over it. -+ -The format `%%` is automatically expanded to a single `%` as a quoting -mechanism; callers do not need to handle the `%` placeholder themselves, -and the callback function will not be invoked for this placeholder. -+ -All other characters (non-percent and not skipped ones) are copied -verbatim to the strbuf. If the callback returned zero, meaning that the -placeholder is unknown, then the percent sign is copied, too. -+ -In order to facilitate caching and to make it possible to give -parameters to the callback, `strbuf_expand()` passes a context pointer, -which can be used by the programmer of the callback as she sees fit. - -`strbuf_expand_dict_cb`:: - - Used as callback for `strbuf_expand()`, expects an array of - struct strbuf_expand_dict_entry as context, i.e. pairs of - placeholder and replacement string. The array needs to be - terminated by an entry with placeholder set to NULL. - -`strbuf_addbuf_percentquote`:: - - Append the contents of one strbuf to another, quoting any - percent signs ("%") into double-percents ("%%") in the - destination. This is useful for literal data to be fed to either - strbuf_expand or to the *printf family of functions. - -`strbuf_addf`:: - - Add a formatted string to the buffer. - -`strbuf_fread`:: - - Read a given size of data from a FILE* pointer to the buffer. -+ -NOTE: The buffer is rewound if the read fails. If -1 is returned, -`errno` must be consulted, like you would do for `read(3)`. -`strbuf_read()`, `strbuf_read_file()` and `strbuf_getline()` has the -same behaviour as well. - -`strbuf_read`:: - - Read the contents of a given file descriptor. The third argument can be - used to give a hint about the file size, to avoid reallocs. - -`strbuf_read_file`:: - - Read the contents of a file, specified by its path. The third argument - can be used to give a hint about the file size, to avoid reallocs. - -`strbuf_readlink`:: - - Read the target of a symbolic link, specified by its path. The third - argument can be used to give a hint about the size, to avoid reallocs. - -`strbuf_getline`:: - - Read a line from a FILE* pointer. The second argument specifies the line - terminator character, typically `'\n'`. - -`stripspace`:: - - Strip whitespace from a buffer. The second parameter controls if - comments are considered contents to be removed or not. - -`launch_editor`:: - - Launch the user preferred editor to edit a file and fill the buffer - with the file's contents upon the user completing their editing. The - third argument can be used to set the environment which the editor is - run in. If the buffer is NULL the editor is launched as usual but the - file's contents are not read into the buffer upon completion. diff --git a/Documentation/technical/api-string-list.txt b/Documentation/technical/api-string-list.txt index ce24eb96f5..c08402b12e 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,27 +21,34 @@ 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 `string_list_lookup` for sorted lists. -. Can sort an unsorted list using `sort_string_list`. +. Can sort an unsorted list using `string_list_sort`. + +. 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++) @@ -60,6 +68,25 @@ Functions * General ones (works with sorted and unsorted lists as well) +`string_list_init`:: + + Initialize the members of the string_list, set `strdup_strings` + member according to the value of the second parameter. + +`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 @@ -83,7 +110,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 @@ -94,15 +123,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`:: +`string_list_sort`:: - Make an unsorted list sorted. + Sort the list's entries by string value in `strcmp()` order. `unsorted_string_list_has_string`:: @@ -122,6 +168,25 @@ counterpart for sorted lists, which performs a binary search. 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 --------------- @@ -140,3 +205,5 @@ Represents the list itself. You should not tamper with it. . Setting the `strdup_strings` member to 1 will strdup() the strings before adding them, see above. +. The `compare_strings_fn` member is used to specify a custom compare + function, otherwise `strcmp()` is used as the default function. diff --git a/Documentation/technical/api-trace.txt b/Documentation/technical/api-trace.txt new file mode 100644 index 0000000000..097a651d96 --- /dev/null +++ b/Documentation/technical/api-trace.txt @@ -0,0 +1,97 @@ +trace API +========= + +The trace API can be used to print debug messages to stderr or a file. Trace +code is inactive unless explicitly enabled by setting `GIT_TRACE*` environment +variables. + +The trace implementation automatically adds `timestamp file:line ... \n` to +all trace messages. E.g.: + +------------ +23:59:59.123456 git.c:312 trace: built-in: git 'foo' +00:00:00.000001 builtin/foo.c:99 foo: some message +------------ + +Data Structures +--------------- + +`struct trace_key`:: + + Defines a trace key (or category). The default (for API functions that + don't take a key) is `GIT_TRACE`. ++ +E.g. to define a trace key controlled by environment variable `GIT_TRACE_FOO`: ++ +------------ +static struct trace_key trace_foo = TRACE_KEY_INIT(FOO); + +static void trace_print_foo(const char *message) +{ + trace_print_key(&trace_foo, message); +} +------------ ++ +Note: don't use `const` as the trace implementation stores internal state in +the `trace_key` structure. + +Functions +--------- + +`int trace_want(struct trace_key *key)`:: + + Checks whether the trace key is enabled. Used to prevent expensive + string formatting before calling one of the printing APIs. + +`void trace_disable(struct trace_key *key)`:: + + Disables tracing for the specified key, even if the environment + variable was set. + +`void trace_printf(const char *format, ...)`:: +`void trace_printf_key(struct trace_key *key, const char *format, ...)`:: + + Prints a formatted message, similar to printf. + +`void trace_argv_printf(const char **argv, const char *format, ...)``:: + + Prints a formatted message, followed by a quoted list of arguments. + +`void trace_strbuf(struct trace_key *key, const struct strbuf *data)`:: + + Prints the strbuf, without additional formatting (i.e. doesn't + choke on `%` or even `\0`). + +`uint64_t getnanotime(void)`:: + + Returns nanoseconds since the epoch (01/01/1970), typically used + for performance measurements. ++ +Currently there are high precision timer implementations for Linux (using +`clock_gettime(CLOCK_MONOTONIC)`) and Windows (`QueryPerformanceCounter`). +Other platforms use `gettimeofday` as time source. + +`void trace_performance(uint64_t nanos, const char *format, ...)`:: +`void trace_performance_since(uint64_t start, const char *format, ...)`:: + + Prints the elapsed time (in nanoseconds), or elapsed time since + `start`, followed by a formatted message. Enabled via environment + variable `GIT_TRACE_PERFORMANCE`. Used for manual profiling, e.g.: ++ +------------ +uint64_t start = getnanotime(); +/* code section to measure */ +trace_performance_since(start, "foobar"); +------------ ++ +------------ +uint64_t t = 0; +for (;;) { + /* ignore */ + t -= getnanotime(); + /* code section to measure */ + t += getnanotime(); + /* ignore */ +} +trace_performance(t, "frotz"); +------------ diff --git a/Documentation/technical/bitmap-format.txt b/Documentation/technical/bitmap-format.txt new file mode 100644 index 0000000000..f8c18a0f7a --- /dev/null +++ b/Documentation/technical/bitmap-format.txt @@ -0,0 +1,164 @@ +GIT bitmap v1 format +==================== + + - A header appears at the beginning: + + 4-byte signature: {'B', 'I', 'T', 'M'} + + 2-byte version number (network byte order) + The current implementation only supports version 1 + of the bitmap index (the same one as JGit). + + 2-byte flags (network byte order) + + The following flags are supported: + + - BITMAP_OPT_FULL_DAG (0x1) REQUIRED + This flag must always be present. It implies that the bitmap + index has been generated for a packfile with full closure + (i.e. where every single object in the packfile can find + its parent links inside the same packfile). This is a + requirement for the bitmap index format, also present in JGit, + that greatly reduces the complexity of the implementation. + + - BITMAP_OPT_HASH_CACHE (0x4) + If present, the end of the bitmap file contains + `N` 32-bit name-hash values, one per object in the + pack. The format and meaning of the name-hash is + described below. + + 4-byte entry count (network byte order) + + The total count of entries (bitmapped commits) in this bitmap index. + + 20-byte checksum + + The SHA1 checksum of the pack this bitmap index belongs to. + + - 4 EWAH bitmaps that act as type indexes + + Type indexes are serialized after the hash cache in the shape + of four EWAH bitmaps stored consecutively (see Appendix A for + the serialization format of an EWAH bitmap). + + There is a bitmap for each Git object type, stored in the following + order: + + - Commits + - Trees + - Blobs + - Tags + + In each bitmap, the `n`th bit is set to true if the `n`th object + in the packfile is of that type. + + The obvious consequence is that the OR of all 4 bitmaps will result + in a full set (all bits set), and the AND of all 4 bitmaps will + result in an empty bitmap (no bits set). + + - N entries with compressed bitmaps, one for each indexed commit + + Where `N` is the total amount of entries in this bitmap index. + Each entry contains the following: + + - 4-byte object position (network byte order) + The position **in the index for the packfile** where the + bitmap for this commit is found. + + - 1-byte XOR-offset + The xor offset used to compress this bitmap. For an entry + in position `x`, a XOR offset of `y` means that the actual + bitmap representing this commit is composed by XORing the + bitmap for this entry with the bitmap in entry `x-y` (i.e. + the bitmap `y` entries before this one). + + Note that this compression can be recursive. In order to + XOR this entry with a previous one, the previous entry needs + to be decompressed first, and so on. + + The hard-limit for this offset is 160 (an entry can only be + xor'ed against one of the 160 entries preceding it). This + number is always positive, and hence entries are always xor'ed + with **previous** bitmaps, not bitmaps that will come afterwards + in the index. + + - 1-byte flags for this bitmap + At the moment the only available flag is `0x1`, which hints + that this bitmap can be re-used when rebuilding bitmap indexes + for the repository. + + - The compressed bitmap itself, see Appendix A. + +== Appendix A: Serialization format for an EWAH bitmap + +Ewah bitmaps are serialized in the same protocol as the JAVAEWAH +library, making them backwards compatible with the JGit +implementation: + + - 4-byte number of bits of the resulting UNCOMPRESSED bitmap + + - 4-byte number of words of the COMPRESSED bitmap, when stored + + - N x 8-byte words, as specified by the previous field + + This is the actual content of the compressed bitmap. + + - 4-byte position of the current RLW for the compressed + bitmap + +All words are stored in network byte order for their corresponding +sizes. + +The compressed bitmap is stored in a form of run-length encoding, as +follows. It consists of a concatenation of an arbitrary number of +chunks. Each chunk consists of one or more 64-bit words + + H L_1 L_2 L_3 .... L_M + +H is called RLW (run length word). It consists of (from lower to higher +order bits): + + - 1 bit: the repeated bit B + + - 32 bits: repetition count K (unsigned) + + - 31 bits: literal word count M (unsigned) + +The bitstream represented by the above chunk is then: + + - K repetitions of B + + - The bits stored in `L_1` through `L_M`. Within a word, bits at + lower order come earlier in the stream than those at higher + order. + +The next word after `L_M` (if any) must again be a RLW, for the next +chunk. For efficient appending to the bitstream, the EWAH stores a +pointer to the last RLW in the stream. + + +== Appendix B: Optional Bitmap Sections + +These sections may or may not be present in the `.bitmap` file; their +presence is indicated by the header flags section described above. + +Name-hash cache +--------------- + +If the BITMAP_OPT_HASH_CACHE flag is set, the end of the bitmap contains +a cache of 32-bit values, one per object in the pack. The value at +position `i` is the hash of the pathname at which the `i`th object +(counting in index order) in the pack can be found. This can be fed +into the delta heuristics to compare objects with similar pathnames. + +The hash algorithm used is: + + hash = 0; + while ((c = *name++)) + if (!isspace(c)) + hash = (hash >> 2) + (c << 24); + +Note that this hashing scheme is tied to the BITMAP_OPT_HASH_CACHE flag. +If implementations want to choose a different hashing scheme, they are +free to do so, but MUST allocate a new header flag (because comparing +hashes made under two different schemes would be pointless). diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt new file mode 100644 index 0000000000..229f845dfa --- /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 2617. +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 +---------- + +http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)] +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 8930b3fabc..35112e4966 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,25 @@ 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. + + Interpretation of index entries in split index mode is completely + different. See below for details. + == Extensions === Cached tree @@ -148,8 +164,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 +178,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 @@ -184,3 +201,35 @@ GIT index format - At most three 160-bit object names of the entry in stages from 1 to 3 (nothing is written for a missing stage). +=== Split index + + In split index mode, the majority of index entries could be stored + in a separate file. This extension records the changes to be made on + top of that to produce the final index. + + The signature for this extension is { 'l', 'i', 'n', 'k' }. + + The extension consists of: + + - 160-bit SHA-1 of the shared index file. The shared index file path + is $GIT_DIR/sharedindex.<SHA-1>. If all 160 bits are zero, the + index does not require a shared index file. + + - An ewah-encoded delete bitmap, each bit represents an entry in the + shared index. If a bit is set, its corresponding entry in the + shared index will be removed from the final index. Note, because + a delete operation changes index entry positions, but we do need + original positions in replace phase, it's best to just mark + entries for removal, then do a mass deletion after replacement. + + - An ewah-encoded replace bitmap, each bit represents an entry in + the shared index. If a bit is set, its corresponding entry in the + shared index will be replaced with an entry in this index + file. All replaced entries are stored in sorted order in this + index. The first "1" bit in the replace bitmap corresponds to the + first index entry, the second "1" bit to the second entry and so + on. Replaced entries may have empty path names to save space. + + The remaining index entries after replaced ones will be added to the + final index. These added entries are also sorted by entry name then + stage. diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt index 1803e64e46..8e5bf60be3 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 103eb5d989..95a07db6e8 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 546980c0a4..462e20645f 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -117,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 @@ -134,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 @@ -160,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^{}" @@ -173,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 @@ -208,9 +212,9 @@ out of what the server said it could do with the first 'want' line. want-list = first-want *additional-want - shallow-line = PKT_LINE("shallow" SP obj-id) + shallow-line = PKT-LINE("shallow" SP obj-id) - depth-request = PKT_LINE("deepen" SP depth) + depth-request = PKT-LINE("deepen" SP depth) first-want = PKT-LINE("want" SP obj-id SP capability-list LF) additional-want = PKT-LINE("want" SP obj-id LF) @@ -227,17 +231,16 @@ 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 tip of the history, if any, as a 'deepen' line. A depth of 0 is the same as not making a depth request. The client does not want to receive -any commits beyond this depth, nor objects needed only to complete -those commits. Commits whose parents are not received as a result are -defined as shallow and marked as such in the server. This information -is sent back to the client in the next step. +any commits beyond this depth, nor does it want objects needed only to +complete those commits. Commits whose parents are not received as a +result are defined as shallow and marked as such in the server. This +information is sent back to the client in the next step. Once all the 'want's and 'shallow's (and optional 'deepen') are transferred, clients MUST send a flush-pkt, to tell the server side @@ -259,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 @@ -333,7 +338,8 @@ during a prior round. This helps to ensure that at least one common ancestor is found before we give up entirely. Once the 'done' line is read from the client, the server will either -send a final 'ACK obj-id' or it will send a 'NAK'. The server only sends +send a final 'ACK obj-id' or it will send a 'NAK'. 'obj-id' is the object +name of the last commit determined to be common. The server only sends ACK after 'done' if there is at least one common base and multi_ack or multi_ack_detailed is enabled. The server always sends NAK after 'done' if there is no common base found. @@ -351,7 +357,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 @@ -367,7 +373,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 @@ -419,7 +425,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 @@ -459,7 +465,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 | push-cert ) [pack-file] + + shallow = PKT-LINE("shallow" SP obj-id LF) command-list = PKT-LINE(command NUL capability-list LF) *PKT-LINE(command LF) @@ -473,12 +481,27 @@ references. old-id = obj-id new-id = obj-id + push-cert = PKT-LINE("push-cert" NUL capability-list LF) + PKT-LINE("certificate version 0.1" LF) + PKT-LINE("pusher" SP ident LF) + PKT-LINE("pushee" SP url LF) + PKT-LINE("nonce" SP nonce LF) + PKT-LINE(LF) + *PKT-LINE(command LF) + *PKT-LINE(gpg-signature-lines LF) + PKT-LINE("push-cert-end" LF) + pack-file = "PACK" 28*(OCTET) ---- If the receiving end does not support delete-refs, the sending end MUST NOT ask for delete command. +If the receiving end does not support push-cert, the sending end +MUST NOT send a push-cert command. When a push-cert command is +sent, command-list MUST NOT be sent; the commands recorded in the +push certificate is used instead. + The pack-file MUST NOT be sent if the only command used is 'delete'. A pack-file MUST be sent if either create or update command is used, @@ -493,6 +516,34 @@ was being processed (the obj-id is still the same as the old-id), and it will run any update hooks to make sure that the update is acceptable. If all of that is fine, the server will then update the references. +Push Certificate +---------------- + +A push certificate begins with a set of header lines. After the +header and an empty line, the protocol commands follow, one per +line. + +Currently, the following header fields are defined: + +`pusher` ident:: + Identify the GPG key in "Human Readable Name <email@address>" + format. + +`pushee` url:: + The repository URL (anonymized, if the URL contains + authentication material) the user who ran `git push` + intended to push into. + +`nonce` nonce:: + The 'nonce' string the receiving repository asked the + pushing user to include in the certificate, to prevent + replay attacks. + +The GPG signature lines are a detached signature for the contents +recorded in the push certificate before the signature block begins. +The detached signature is used to certify that the commands were +given by the pusher, who must be the signer. + Report Status ------------- diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index b15517fa06..4f8a7bfb4c 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -18,11 +18,13 @@ 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 -recognized by the receive-pack (push to server) process. +The 'atomic', 'report-status', 'delete-refs', 'quiet', and 'push-cert' +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. @@ -68,17 +70,50 @@ ends. Without multi_ack the client would have sent that c-b-a chain anyway, interleaved with S-R-Q. +multi_ack_detailed +------------------ +This is an extension of multi_ack that permits client to better +understand the server's in-memory state. See pack-protocol.txt, +section "Packfile Negotiation" for more information. + +no-done +------- +This capability should only be used with the smart HTTP protocol. If +multi_ack_detailed and no-done are both present, then the sender is +free to immediately send a pack following its first "ACK obj-id ready" +message. + +Without no-done in the smart HTTP protocol, the server session would +end and the client has to make another trip to send "done" before +the server can send the pack. no-done removes the last round and +thus slightly reduces latency. + 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 +158,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 programmatically assume the presence +or absence of particular features. + shallow ------- @@ -168,7 +217,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 +234,37 @@ 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). + +atomic +------ + +If the server sends the 'atomic' capability it is capable of accepting +atomic pushes. If the pushing client requests this capability, the server +will update the refs in one atomic transaction. Either all refs are +updated or none. + +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. + +push-cert=<nonce> +----------------- + +The receive-pack server that advertises this capability is willing +to accept a signed push certificate, and asks the <nonce> to be +included in the push certificate. A send-pack client MUST NOT +send a push-cert packet unless the receive-pack server advertises +this capability. diff --git a/Documentation/technical/protocol-common.txt b/Documentation/technical/protocol-common.txt index d30a1b9510..889985f707 100644 --- a/Documentation/technical/protocol-common.txt +++ b/Documentation/technical/protocol-common.txt @@ -36,10 +36,10 @@ 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 `.`. +. They cannot end with a slash `/` or a dot `.`. . They cannot end with the sequence `.lock`. diff --git a/Documentation/technical/racy-git.txt b/Documentation/technical/racy-git.txt index 53aa0c82c2..242a044db9 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 681efe4219..9b5a0bc186 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 559263af48..5183b15422 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 24c84100b0..c79d4a7c47 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 00f7e79c44..282758e768 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 289019478d..9ccb24677e 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 339b30919e..d87294de2f 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 f13a846131..68978f5338 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]. @@ -414,12 +416,11 @@ REVISIONS" section of linkgit:gitrevisions[7]. Updating a repository with git fetch ------------------------------------ -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. +After you clone a repository and commit a few changes of your own, you +may wish to check the original repository for updates. -The command "git fetch", with no arguments, will update all of the -remote-tracking branches to the latest version found in her +The `git-fetch` command, with no arguments, will update all of the +remote-tracking branches to the latest version found in the original repository. It will not touch any of your own branches--not even the "master" branch that was created for you on clone. @@ -431,43 +432,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 +506,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 +518,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 +552,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 +598,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 +647,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 +676,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 +688,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 +739,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 +749,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 +787,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 +815,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 +859,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 +872,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 +901,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 +938,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 +1000,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 +1024,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 +1059,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 +1102,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 +1112,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 +1154,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 +1199,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 +1215,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 +1246,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 +1257,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 +1293,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 +1340,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 +1432,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 +1458,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 +1483,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 +1580,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 +1598,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 +1613,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 +1627,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 +1640,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 +1666,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 +1745,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 +1761,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 +1773,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 +1782,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,13 +1798,20 @@ $ 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 use the linkgit:git-send-email[1] script to automate the process. -Consult the mailing list for your project first to determine how they -prefer such patches be handled. +Consult the mailing list for your project first to determine +their requirements for submitting patches. [[importing-patches]] Importing patches to a project @@ -1795,7 +1820,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 +1828,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 +1847,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 +1904,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 +1914,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 +1944,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 +1964,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 +1972,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 +1987,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 +2004,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 +2065,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 +2099,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 +2125,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 +2136,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 +2157,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 +2169,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 +2186,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 +2199,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 +2230,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 +2244,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 +Sometime 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 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 +2290,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 +2305,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 +2339,7 @@ origin) fi ;; *) - echo "Usage: $0 origin|test|release" 1>&2 + echo "usage: $0 origin|test|release" 1>&2 exit 1 ;; esac @@ -2319,7 +2353,7 @@ pname=$0 usage() { - echo "Usage: $pname branch test|release" 1>&2 + echo "usage: $pname branch test|release" 1>&2 exit 1 } @@ -2345,7 +2379,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 +2435,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 +2477,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 +2490,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 +2499,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 +2507,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 +2526,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 +2546,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 +2555,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 +2574,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"). +This will open your editor with a list of steps to be taken to perform +your rebase. -Another technique is to use `git format-patch` to create a series of -patches, then reset the state to before the patches: - -------------------------------------------------- -$ 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 +2703,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 +2776,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 +2797,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 +2808,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 +2818,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 +2844,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 +2863,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 +2877,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 +2895,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 +2931,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 +2986,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 +3007,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 +3025,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 +3064,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 +3079,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 +3132,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 +3162,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 +3183,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 +3208,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 +3237,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 +3280,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 +3298,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 +3330,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 +3354,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 +3396,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 +3412,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 +3461,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 +3525,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 +3566,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 +3627,7 @@ working on a branch. ------------------------------------------------- $ git branch -* (no branch) +* (detached from d266b98) master ------------------------------------------------- @@ -3660,13 +3692,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 +3734,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 +3775,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 +3794,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 +3874,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 +3885,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 +3897,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 +3912,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 +3996,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,19 +4067,19 @@ $ 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 -from `$orig` to `HEAD` nor `$target`, or if the file changed +from `$orig` to `HEAD` or `$target`, or if the file changed from `$orig` to `HEAD` and `$orig` to `$target` the same way, obviously the final outcome is what is in `HEAD`. What the above example shows is that file `hello.c` was changed from `$orig` to `HEAD` and `$orig` to `$target` in a different way. You could resolve this by running your favorite 3-way merge -program, e.g. `diff3`, `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 +4091,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 +4100,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 +4115,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 +4137,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 +4166,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 @@ -4199,30 +4230,31 @@ Most of what `git rev-list` did is contained in `revision.c` and controls how and what revisions are walked, and more. The original job of `git rev-parse` is now taken by the function -`setup_revisions()`, which parses the revisions and the common command line +`setup_revisions()`, which parses the revisions and the common command-line options for the revision walker. This information is stored in the struct -`rev_info` for later consumption. You can do your own command line option +`rev_info` for later consumption. You can do your own command-line option parsing after calling `setup_revisions()`. After that, you have to call `prepare_revision_walk()` for initialization, and then you can get the 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 +4277,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 +4303,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 +4321,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 +4356,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 +4502,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 +4552,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 +4613,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 +4624,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 +4658,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 |