diff options
Diffstat (limited to 'Documentation')
330 files changed, 52095 insertions, 0 deletions
diff --git a/Documentation/.gitattributes b/Documentation/.gitattributes new file mode 100644 index 0000000000..ddb030137d --- /dev/null +++ b/Documentation/.gitattributes @@ -0,0 +1 @@ +*.txt whitespace diff --git a/Documentation/.gitignore b/Documentation/.gitignore new file mode 100644 index 0000000000..1c3a9fead5 --- /dev/null +++ b/Documentation/.gitignore @@ -0,0 +1,11 @@ +*.xml +*.html +*.[1-8] +*.made +*.texi +git.info +gitman.info +howto-index.txt +doc.dep +cmds-*.txt +manpage-base-url.xsl diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines new file mode 100644 index 0000000000..b8bf618a30 --- /dev/null +++ b/Documentation/CodingGuidelines @@ -0,0 +1,134 @@ +Like other projects, we also have some guidelines to keep to the +code. For git in general, three rough rules are: + + - Most importantly, we never say "It's in POSIX; we'll happily + ignore your needs should your system not conform to it." + We live in the real world. + + - However, we often say "Let's stay away from that construct, + it's not even in POSIX". + + - In spite of the above two rules, we sometimes say "Although + this is not in POSIX, it (is so convenient | makes the code + much more readable | has other good characteristics) and + practically all the platforms we care about support it, so + let's use it". + + Again, we live in the real world, and it is sometimes a + judgement call, the decision based more on real world + constraints people face than what the paper standard says. + + +As for more concrete guidelines, just imitate the existing code +(this is a good guideline, no matter which project you are +contributing to). It is always preferable to match the _local_ +convention. New code added to git suite is expected to match +the overall style of existing code. Modifications to existing +code is expected to match the style the surrounding code already +uses (even if it doesn't match the overall style of existing code). + +But if you must have a list of rules, here they are. + +For shell scripts specifically (not exhaustive): + + - We prefer $( ... ) for command substitution; unlike ``, it + properly nests. It should have been the way Bourne spelled + it from day one, but unfortunately isn't. + + - We use ${parameter-word} and its [-=?+] siblings, and their + colon'ed "unset or null" form. + + - We use ${parameter#word} and its [#%] siblings, and their + doubled "longest matching" form. + + - We use Arithmetic Expansion $(( ... )). + + - No "Substring Expansion" ${parameter:offset:length}. + + - No shell arrays. + + - No strlen ${#parameter}. + + - No regexp ${parameter/pattern/string}. + + - We do not use Process Substitution <(list) or >(list). + + - We prefer "test" over "[ ... ]". + + - We do not write the noiseword "function" in front of shell + functions. + + - As to use of grep, stick to a subset of BRE (namely, no \{m,n\}, + [::], [==], nor [..]) for portability. + + - We do not use \{m,n\}; + + - We do not use -E; + + - We do not use ? nor + (which are \{0,1\} and \{1,\} + respectively in BRE) but that goes without saying as these + are ERE elements not BRE (note that \? and \+ are not even part + of BRE -- making them accessible from BRE is a GNU extension). + +For C programs: + + - We use tabs to indent, and interpret tabs as taking up to + 8 spaces. + + - We try to keep to at most 80 characters per line. + + - When declaring pointers, the star sides with the variable + name, i.e. "char *string", not "char* string" or + "char * string". This makes it easier to understand code + like "char *string, c;". + + - We avoid using braces unnecessarily. I.e. + + if (bla) { + x = 1; + } + + is frowned upon. A gray area is when the statement extends + over a few lines, and/or you have a lengthy comment atop of + it. Also, like in the Linux kernel, if there is a long list + of "else if" statements, it can make sense to add braces to + single line blocks. + + - We try to avoid assignments inside if(). + + - Try to make your code understandable. You may put comments + in, but comments invariably tend to stale out when the code + they were describing changes. Often splitting a function + into two makes the intention of the code much clearer. + + - Double negation is often harder to understand than no negation + at all. + + - Some clever tricks, like using the !! operator with arithmetic + constructs, can be extremely confusing to others. Avoid them, + unless there is a compelling reason to use them. + + - Use the API. No, really. We have a strbuf (variable length + string), several arrays with the ALLOC_GROW() macro, a + string_list for sorted string lists, a hash map (mapping struct + objects) named "struct decorate", amongst other things. + + - When you come up with an API, document it. + + - The first #include in C files, except in platform specific + compat/ implementations, should be git-compat-util.h or another + header file that includes it, such as cache.h or builtin.h. + + - If you are planning a new command, consider writing it in shell + or perl first, so that changes in semantics can be easily + changed and discussed. Many git commands started out like + that, and a few are still scripts. + + - Avoid introducing a new dependency into git. This means you + usually should stay away from scripting languages not already + used in the git core command set (unless your command is clearly + separate from it, such as an importer to convert random-scm-X + repositories to git). + + - When we pass <string, length> pair to functions, we should try to + pass them in that order. diff --git a/Documentation/Makefile b/Documentation/Makefile new file mode 100644 index 0000000000..4797b2dc35 --- /dev/null +++ b/Documentation/Makefile @@ -0,0 +1,340 @@ +MAN1_TXT= \ + $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \ + $(wildcard git-*.txt)) \ + gitk.txt git.txt +MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \ + gitrepository-layout.txt +MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \ + gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \ + gitdiffcore.txt gitworkflows.txt + +MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) +MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT)) +MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT)) + +DOC_HTML=$(MAN_HTML) + +ARTICLES = howto-index +ARTICLES += everyday +ARTICLES += git-tools +ARTICLES += git-bisect-lk2009 +# with their own formatting rules. +SP_ARTICLES = howto/revert-branch-rebase howto/using-merge-subtree user-manual +API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) +SP_ARTICLES += $(API_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 +ASCIIDOC_EXTRA = +MANPAGE_XSL = manpage-normal.xsl +XMLTO_EXTRA = +INSTALL?=install +RM ?= rm -f +DOC_REF = origin/man +HTML_REF = origin/html + +infodir?=$(prefix)/share/info +MAKEINFO=makeinfo +INSTALL_INFO=install-info +DOCBOOK2X_TEXI=docbook2x-texi +DBLATEX=dblatex +ifndef PERL_PATH + PERL_PATH = /usr/bin/perl +endif + +-include ../config.mak.autogen +-include ../config.mak + +# +# For asciidoc ... +# -7.1.2, no extra settings are needed. +# 8.0-, set ASCIIDOC8. +# + +# +# For docbook-xsl ... +# -1.68.1, set ASCIIDOC_NO_ROFF? (based on changelog from 1.73.0) +# 1.69.0, no extra settings are needed? +# 1.69.1-1.71.0, set DOCBOOK_SUPPRESS_SP? +# 1.71.1, no extra settings are needed? +# 1.72.0, set DOCBOOK_XSL_172. +# 1.73.0-, set ASCIIDOC_NO_ROFF +# + +# +# If you had been using DOCBOOK_XSL_172 in an attempt to get rid +# of 'the ".ft C" problem' in your generated manpages, and you +# instead ended up with weird characters around callouts, try +# using ASCIIDOC_NO_ROFF instead (it works fine with ASCIIDOC8). +# + +ifdef ASCIIDOC8 +ASCIIDOC_EXTRA += -a asciidoc7compatible -a no-inline-literal +endif +ifdef DOCBOOK_XSL_172 +ASCIIDOC_EXTRA += -a git-asciidoc-no-roff +MANPAGE_XSL = manpage-1.72.xsl +else + ifdef ASCIIDOC_NO_ROFF + # docbook-xsl after 1.72 needs the regular XSL, but will not + # pass-thru raw roff codes from asciidoc.conf, so turn them off. + ASCIIDOC_EXTRA += -a git-asciidoc-no-roff + endif +endif +ifdef MAN_BOLD_LITERAL +XMLTO_EXTRA += -m manpage-bold-literal.xsl +endif +ifdef DOCBOOK_SUPPRESS_SP +XMLTO_EXTRA += -m manpage-suppress-sp.xsl +endif + +# Newer DocBook stylesheet emits warning cruft in the output when +# this is not set, and if set it shows an absolute link. Older +# stylesheets simply ignore this parameter. +# +# Distros may want to use MAN_BASE_URL=file:///path/to/git/docs/ +# or similar. +ifndef MAN_BASE_URL +MAN_BASE_URL = file://$(htmldir)/ +endif +XMLTO_EXTRA += -m manpage-base-url.xsl + +# If your target system uses GNU groff, it may try to render +# apostrophes as a "pretty" apostrophe using unicode. This breaks +# cut&paste, so you should set GNU_ROFF to force them to be ASCII +# apostrophes. Unfortunately does not work with non-GNU roff. +ifdef GNU_ROFF +XMLTO_EXTRA += -m manpage-quote-apos.xsl +endif + +SHELL_PATH ?= $(SHELL) +# Shell quote; +SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH)) + +# +# Please note that there is a minor bug in asciidoc. +# 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! +# + +QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir +QUIET_SUBDIR1 = + +ifneq ($(findstring $(MAKEFLAGS),w),w) +PRINT_DIR = --no-print-directory +else # "make -w" +NO_SUBDIR = : +endif + +ifneq ($(findstring $(MAKEFLAGS),s),s) +ifndef V + QUIET_ASCIIDOC = @echo ' ' ASCIIDOC $@; + QUIET_XMLTO = @echo ' ' XMLTO $@; + QUIET_DB2TEXI = @echo ' ' DB2TEXI $@; + QUIET_MAKEINFO = @echo ' ' MAKEINFO $@; + QUIET_DBLATEX = @echo ' ' DBLATEX $@; + QUIET_XSLTPROC = @echo ' ' XSLTPROC $@; + QUIET_GEN = @echo ' ' GEN $@; + QUIET_STDERR = 2> /dev/null + QUIET_SUBDIR0 = +@subdir= + QUIET_SUBDIR1 = ;$(NO_SUBDIR) echo ' ' SUBDIR $$subdir; \ + $(MAKE) $(PRINT_DIR) -C $$subdir + export V +endif +endif + +all: html man + +html: $(DOC_HTML) + +$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7): asciidoc.conf + +man: man1 man5 man7 +man1: $(DOC_MAN1) +man5: $(DOC_MAN5) +man7: $(DOC_MAN7) + +info: git.info gitman.info + +pdf: user-manual.pdf + +install: install-man + +install-man: man + $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir) + $(INSTALL) -d -m 755 $(DESTDIR)$(man5dir) + $(INSTALL) -d -m 755 $(DESTDIR)$(man7dir) + $(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(man1dir) + $(INSTALL) -m 644 $(DOC_MAN5) $(DESTDIR)$(man5dir) + $(INSTALL) -m 644 $(DOC_MAN7) $(DESTDIR)$(man7dir) + +install-info: info + $(INSTALL) -d -m 755 $(DESTDIR)$(infodir) + $(INSTALL) -m 644 git.info gitman.info $(DESTDIR)$(infodir) + if test -r $(DESTDIR)$(infodir)/dir; then \ + $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\ + $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) gitman.info ;\ + else \ + echo "No directory found in $(DESTDIR)$(infodir)" >&2 ; \ + fi + +install-pdf: pdf + $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir) + $(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir) + +install-html: html + '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir) + +../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE + $(QUIET_SUBDIR0)../ $(QUIET_SUBDIR1) GIT-VERSION-FILE + +-include ../GIT-VERSION-FILE + +# +# Determine "include::" file references in asciidoc files. +# +doc.dep : $(wildcard *.txt) build-docdep.perl + $(QUIET_GEN)$(RM) $@+ $@ && \ + $(PERL_PATH) ./build-docdep.perl >$@+ $(QUIET_STDERR) && \ + mv $@+ $@ + +-include doc.dep + +cmds_txt = cmds-ancillaryinterrogators.txt \ + cmds-ancillarymanipulators.txt \ + cmds-mainporcelain.txt \ + cmds-plumbinginterrogators.txt \ + cmds-plumbingmanipulators.txt \ + cmds-synchingrepositories.txt \ + cmds-synchelpers.txt \ + cmds-purehelpers.txt \ + cmds-foreignscminterface.txt + +$(cmds_txt): cmd-list.made + +cmd-list.made: cmd-list.perl ../command-list.txt $(MAN1_TXT) + $(QUIET_GEN)$(RM) $@ && \ + $(PERL_PATH) ./cmd-list.perl ../command-list.txt $(QUIET_STDERR) && \ + date >$@ + +clean: + $(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 + $(RM) *.texi *.texi+ *.texi++ git.info gitman.info + $(RM) howto-index.txt howto/*.html doc.dep + $(RM) technical/api-*.html technical/api-index.txt + $(RM) $(cmds_txt) *.made + $(RM) manpage-base-url.xsl + +$(MAN_HTML): %.html : %.txt + $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ + $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \ + $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ + mv $@+ $@ + +manpage-base-url.xsl: manpage-base-url.xsl.in + sed "s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|" $< > $@ + +%.1 %.5 %.7 : %.xml manpage-base-url.xsl + $(QUIET_XMLTO)$(RM) $@ && \ + xmlto -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $< + +%.xml : %.txt + $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ + $(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \ + $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ + mv $@+ $@ + +user-manual.xml: user-manual.txt user-manual.conf + $(QUIET_ASCIIDOC)$(ASCIIDOC) $(ASCIIDOC_EXTRA) -b docbook -d book $< + +technical/api-index.txt: technical/api-index-skel.txt \ + technical/api-index.sh $(patsubst %,%.txt,$(API_DOCS)) + $(QUIET_GEN)cd technical && '$(SHELL_PATH_SQ)' ./api-index.sh + +$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt + $(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ + $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt + +XSLT = docbook.xsl +XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css + +user-manual.html: user-manual.xml + $(QUIET_XSLTPROC)xsltproc $(XSLTOPTS) -o $@ $(XSLT) $< + +git.info: user-manual.texi + $(QUIET_MAKEINFO)$(MAKEINFO) --no-split -o $@ user-manual.texi + +user-manual.texi: user-manual.xml + $(QUIET_DB2TEXI)$(RM) $@+ $@ && \ + $(DOCBOOK2X_TEXI) user-manual.xml --encoding=UTF-8 --to-stdout >$@++ && \ + $(PERL_PATH) fix-texi.perl <$@++ >$@+ && \ + rm $@++ && \ + mv $@+ $@ + +user-manual.pdf: user-manual.xml + $(QUIET_DBLATEX)$(RM) $@+ $@ && \ + $(DBLATEX) -o $@+ -p /etc/asciidoc/dblatex/asciidoc-dblatex.xsl -s /etc/asciidoc/dblatex/asciidoc-dblatex.sty $< && \ + mv $@+ $@ + +gitman.texi: $(MAN_XML) cat-texi.perl + $(QUIET_DB2TEXI)$(RM) $@+ $@ && \ + ($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --encoding=UTF-8 \ + --to-stdout $(xml) &&) true) > $@++ && \ + $(PERL_PATH) cat-texi.perl $@ <$@++ >$@+ && \ + rm $@++ && \ + mv $@+ $@ + +gitman.info: gitman.texi + $(QUIET_MAKEINFO)$(MAKEINFO) --no-split --no-validate $*.texi + +$(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml + $(QUIET_DB2TEXI)$(RM) $@+ $@ && \ + $(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@+ && \ + mv $@+ $@ + +howto-index.txt: howto-index.sh $(wildcard howto/*.txt) + $(QUIET_GEN)$(RM) $@+ $@ && \ + '$(SHELL_PATH_SQ)' ./howto-index.sh $(wildcard howto/*.txt) >$@+ && \ + mv $@+ $@ + +$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt + $(QUIET_ASCIIDOC)$(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 $*.txt + +WEBDOC_DEST = /pub/software/scm/git/docs + +$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt + $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ + sed -e '1,/^$$/d' $< | $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 - >$@+ && \ + mv $@+ $@ + +install-webdoc : html + '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(WEBDOC_DEST) + +quick-install: quick-install-man + +quick-install-man: + '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir) + +quick-install-html: + '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir) + +.PHONY: .FORCE-GIT-VERSION-FILE diff --git a/Documentation/RelNotes-1.5.0.1.txt b/Documentation/RelNotes-1.5.0.1.txt new file mode 100644 index 0000000000..fea3f9935b --- /dev/null +++ b/Documentation/RelNotes-1.5.0.1.txt @@ -0,0 +1,42 @@ +GIT v1.5.0.1 Release Notes +========================== + +Fixes since v1.5.0 +------------------ + +* Documentation updates + + - Clarifications and corrections to 1.5.0 release notes. + + - The main documentation did not link to git-remote documentation. + + - Clarified introductory text of git-rebase documentation. + + - Converted remaining mentions of update-index on Porcelain + documents to git-add/git-rm. + + - Some i18n.* configuration variables were incorrectly + described as core.*; fixed. + +* Bugfixes + + - git-add and git-update-index on a filesystem on which + executable bits are unreliable incorrectly reused st_mode + bits even when the path changed between symlink and regular + file. + + - git-daemon marks the listening sockets with FD_CLOEXEC so + that it won't be leaked into the children. + + - segfault from git-blame when the mandatory pathname + parameter was missing was fixed; usage() message is given + instead. + + - git-rev-list did not read $GIT_DIR/config file, which means + that did not honor i18n.logoutputencoding correctly. + +* Tweaks + + - sliding mmap() inefficiently mmaped the same region of a + packfile with an access pattern that used objects in the + reverse order. This has been made more efficient. diff --git a/Documentation/RelNotes-1.5.0.2.txt b/Documentation/RelNotes-1.5.0.2.txt new file mode 100644 index 0000000000..b061e50ff0 --- /dev/null +++ b/Documentation/RelNotes-1.5.0.2.txt @@ -0,0 +1,65 @@ +GIT v1.5.0.2 Release Notes +========================== + +Fixes since v1.5.0.1 +-------------------- + +* Bugfixes + + - Automated merge conflict handling when changes to symbolic + links conflicted were completely broken. The merge-resolve + strategy created a regular file with conflict markers in it + in place of the symbolic link. The default strategy, + merge-recursive was even more broken. It removed the path + that was pointed at by the symbolic link. Both of these + problems have been fixed. + + - 'git diff maint master next' did not correctly give combined + diff across three trees. + + - 'git fast-import' portability fix for Solaris. + + - 'git show-ref --verify' without arguments did not error out + but segfaulted. + + - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra + slashes after a/ and b/. + + - 'git format-patch' produced too long filenames if the commit + message had too long line at the beginning. + + - Running 'make all' and then without changing anything + running 'make install' still rebuilt some files. This + was inconvenient when building as yourself and then + installing as root (especially problematic when the source + directory is on NFS and root is mapped to nobody). + + - 'git-rerere' failed to deal with two unconflicted paths that + sorted next to each other. + + - 'git-rerere' attempted to open(2) a symlink and failed if + there was a conflict. Since a conflicting change to a + symlink would not benefit from rerere anyway, the command + now ignores conflicting changes to symlinks. + + - 'git-repack' did not like to pass more than 64 arguments + internally to underlying 'rev-list' logic, which made it + impossible to repack after accumulating many (small) packs + in the repository. + + - 'git-diff' to review the combined diff during a conflicted + merge were not reading the working tree version correctly + when changes to a symbolic link conflicted. It should have + read the data using readlink(2) but read from the regular + file the symbolic link pointed at. + + - 'git-remote' did not like period in a remote's name. + +* Documentation updates + + - added and clarified core.bare, core.legacyheaders configurations. + + - updated "git-clone --depth" documentation. + + +* Assorted git-gui fixes. diff --git a/Documentation/RelNotes-1.5.0.3.txt b/Documentation/RelNotes-1.5.0.3.txt new file mode 100644 index 0000000000..cd500f96bf --- /dev/null +++ b/Documentation/RelNotes-1.5.0.3.txt @@ -0,0 +1,58 @@ +GIT v1.5.0.3 Release Notes +========================== + +Fixes since v1.5.0.2 +-------------------- + +* Bugfixes + + - 'git.el' honors the commit coding system from the configuration. + + - 'blameview' in contrib/ correctly digs deeper when a line is + clicked. + + - 'http-push' correctly makes sure the remote side has leading + path. Earlier it started in the middle of the path, and + incorrectly. + + - 'git-merge' did not exit with non-zero status when the + working tree was dirty and cannot fast forward. It does + now. + + - 'cvsexportcommit' does not lose yet-to-be-used message file. + + - int-vs-size_t typefix when running combined diff on files + over 2GB long. + + - 'git apply --whitespace=strip' should not touch unmodified + lines. + + - 'git-mailinfo' choke when a logical header line was too long. + + - 'git show A..B' did not error out. Negative ref ("not A" in + this example) does not make sense for the purpose of the + command, so now it errors out. + + - 'git fmt-merge-msg --file' without file parameter did not + correctly error out. + + - 'git archimport' barfed upon encountering a commit without + summary. + + - 'git index-pack' did not protect itself from getting a short + read out of pread(2). + + - 'git http-push' had a few buffer overruns. + + - Build dependency fixes to rebuild fetch.o when other headers + change. + +* Documentation updates + + - user-manual updates. + + - Options to 'git remote add' were described insufficiently. + + - Configuration format.suffix was not documented. + + - Other formatting and spelling fixes. diff --git a/Documentation/RelNotes-1.5.0.4.txt b/Documentation/RelNotes-1.5.0.4.txt new file mode 100644 index 0000000000..feefa5dfd4 --- /dev/null +++ b/Documentation/RelNotes-1.5.0.4.txt @@ -0,0 +1,22 @@ +GIT v1.5.0.4 Release Notes +========================== + +Fixes since v1.5.0.3 +-------------------- + +* Bugfixes + + - git.el does not add duplicate sign-off lines. + + - git-commit shows the full stat of the resulting commit, not + just about the files in the current directory, when run from + a subdirectory. + + - "git-checkout -m '@{8 hours ago}'" had a funny failure from + eval; fixed. + + - git-gui updates. + +* Documentation updates + +* User manual updates diff --git a/Documentation/RelNotes-1.5.0.5.txt b/Documentation/RelNotes-1.5.0.5.txt new file mode 100644 index 0000000000..eeec3d73d0 --- /dev/null +++ b/Documentation/RelNotes-1.5.0.5.txt @@ -0,0 +1,26 @@ +GIT v1.5.0.5 Release Notes +========================== + +Fixes since v1.5.0.3 +-------------------- + +* Bugfixes + + - git-merge (hence git-pull) did not refuse fast-forwarding + when the working tree had local changes that would have + conflicted with it. + + - git.el does not add duplicate sign-off lines. + + - git-commit shows the full stat of the resulting commit, not + just about the files in the current directory, when run from + a subdirectory. + + - "git-checkout -m '@{8 hours ago}'" had a funny failure from + eval; fixed. + + - git-gui updates. + +* Documentation updates + +* User manual updates diff --git a/Documentation/RelNotes-1.5.0.6.txt b/Documentation/RelNotes-1.5.0.6.txt new file mode 100644 index 0000000000..c02015ad5f --- /dev/null +++ b/Documentation/RelNotes-1.5.0.6.txt @@ -0,0 +1,21 @@ +GIT v1.5.0.6 Release Notes +========================== + +Fixes since v1.5.0.5 +-------------------- + +* Bugfixes + + - a handful small fixes to gitweb. + + - build procedure for user-manual is fixed not to require locally + installed stylesheets. + + - "git commit $paths" on paths whose earlier contents were + already updated in the index were failing out. + +* Documentation + + - user-manual has better cross references. + + - gitweb installation/deployment procedure is now documented. diff --git a/Documentation/RelNotes-1.5.0.7.txt b/Documentation/RelNotes-1.5.0.7.txt new file mode 100644 index 0000000000..670ad32b85 --- /dev/null +++ b/Documentation/RelNotes-1.5.0.7.txt @@ -0,0 +1,18 @@ +GIT v1.5.0.7 Release Notes +========================== + +Fixes since v1.5.0.6 +-------------------- + +* Bugfixes + + - git-upload-pack failed to close unused pipe ends, resulting + in many zombies to hang around. + + - git-rerere was recording the contents of earlier hunks + duplicated in later hunks. This prevented resolving the same + conflict when performing the same merge the other way around. + +* Documentation + + - a few documentation fixes from Debian package maintainer. diff --git a/Documentation/RelNotes-1.5.0.txt b/Documentation/RelNotes-1.5.0.txt new file mode 100644 index 0000000000..daf4bdb0d7 --- /dev/null +++ b/Documentation/RelNotes-1.5.0.txt @@ -0,0 +1,469 @@ +GIT v1.5.0 Release Notes +======================== + +Old news +-------- + +This section is for people who are upgrading from ancient +versions of git. Although all of the changes in this section +happened before the current v1.4.4 release, they are summarized +here in the v1.5.0 release notes for people who skipped earlier +versions. + +As of git v1.5.0 there are some optional features that changes +the repository to allow data to be stored and transferred more +efficiently. These features are not enabled by default, as they +will make the repository unusable with older versions of git. +Specifically, the available options are: + + - There is a configuration variable core.legacyheaders that + changes the format of loose objects so that they are more + efficient to pack and to send out of the repository over git + native protocol, since v1.4.2. However, loose objects + written in the new format cannot be read by git older than + that version; people fetching from your repository using + older clients over dumb transports (e.g. http) using older + versions of git will also be affected. + + To let git use the new loose object format, you have to + set core.legacyheaders to false. + + - Since v1.4.3, configuration repack.usedeltabaseoffset allows + packfile to be created in more space efficient format, which + cannot be read by git older than that version. + + To let git use the new format for packfiles, you have to + set repack.usedeltabaseoffset to true. + +The above two new features are not enabled by default and you +have to explicitly ask for them, because they make repositories +unreadable by older versions of git, and in v1.5.0 we still do +not enable them by default for the same reason. We will change +this default probably 1 year after 1.4.2's release, when it is +reasonable to expect everybody to have new enough version of +git. + + - 'git pack-refs' appeared in v1.4.4; this command allows tags + to be accessed much more efficiently than the traditional + 'one-file-per-tag' format. Older git-native clients can + still fetch from a repository that packed and pruned refs + (the server side needs to run the up-to-date version of git), + but older dumb transports cannot. Packing of refs is done by + an explicit user action, either by use of "git pack-refs + --prune" command or by use of "git gc" command. + + - 'git -p' to paginate anything -- many commands do pagination + by default on a tty. Introduced between v1.4.1 and v1.4.2; + this may surprise old timers. + + - 'git archive' superseded 'git tar-tree' in v1.4.3; + + - 'git cvsserver' was new invention in v1.3.0; + + - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were + seriously enhanced during v1.4.0 timeperiod. + + - 'gitweb' became part of git.git during v1.4.0 timeperiod and + seriously modified since then. + + - reflog is an v1.4.0 invention. This allows you to name a + revision that a branch used to be at (e.g. "git diff + master@{yesterday} master" allows you to see changes since + yesterday's tip of the branch). + + +Updates in v1.5.0 since v1.4.4 series +------------------------------------- + +* Index manipulation + + - git-add is to add contents to the index (aka "staging area" + for the next commit), whether the file the contents happen to + be is an existing one or a newly created one. + + - git-add without any argument does not add everything + anymore. Use 'git-add .' instead. Also you can add + otherwise ignored files with an -f option. + + - git-add tries to be more friendly to users by offering an + interactive mode ("git-add -i"). + + - git-commit <path> used to refuse to commit if <path> was + different between HEAD and the index (i.e. update-index was + used on it earlier). This check was removed. + + - git-rm is much saner and safer. It is used to remove paths + from both the index file and the working tree, and makes sure + you are not losing any local modification before doing so. + + - git-reset <tree> <paths>... can be used to revert index + entries for selected paths. + + - git-update-index is much less visible. Many suggestions to + use the command in git output and documentation have now been + replaced by simpler commands such as "git add" or "git rm". + + +* Repository layout and objects transfer + + - The data for origin repository is stored in the configuration + file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly + created clones. The latter is still supported and there is + no need to convert your existing repository if you are + already comfortable with your workflow with the layout. + + - git-clone always uses what is known as "separate remote" + layout for a newly created repository with a working tree. + + A repository with the separate remote layout starts with only + one default branch, 'master', to be used for your own + development. Unlike the traditional layout that copied all + the upstream branches into your branch namespace (while + renaming their 'master' to your 'origin'), the new layout + puts upstream branches into local "remote-tracking branches" + with their own namespace. These can be referenced with names + such as "origin/$upstream_branch_name" and are stored in + .git/refs/remotes rather than .git/refs/heads where normal + branches are stored. + + This layout keeps your own branch namespace less cluttered, + avoids name collision with your upstream, makes it possible + to automatically track new branches created at the remote + after you clone from it, and makes it easier to interact with + more than one remote repository (you can use "git remote" to + add other repositories to track). There might be some + surprises: + + * 'git branch' does not show the remote tracking branches. + It only lists your own branches. Use '-r' option to view + the tracking branches. + + * If you are forking off of a branch obtained from the + upstream, you would have done something like 'git branch + my-next next', because traditional layout dropped the + tracking branch 'next' into your own branch namespace. + With the separate remote layout, you say 'git branch next + origin/next', which allows you to use the matching name + 'next' for your own branch. It also allows you to track a + remote other than 'origin' (i.e. where you initially cloned + from) and fork off of a branch from there the same way + (e.g. "git branch mingw j6t/master"). + + Repositories initialized with the traditional layout continue + to work. + + - New branches that appear on the origin side after a clone is + made are also tracked automatically. This is done with an + wildcard refspec "refs/heads/*:refs/remotes/origin/*", which + older git does not understand, so if you clone with 1.5.0, + you would need to downgrade remote.*.fetch in the + configuration file to specify each branch you are interested + in individually if you plan to fetch into the repository with + older versions of git (but why would you?). + + - Similarly, wildcard refspec "refs/heads/*:refs/remotes/me/*" + can be given to "git-push" command to update the tracking + branches that is used to track the repository you are pushing + from on the remote side. + + - git-branch and git-show-branch know remote tracking branches + (use the command line switch "-r" to list only tracked branches). + + - git-push can now be used to delete a remote branch or a tag. + This requires the updated git on the remote side (use "git + push <remote> :refs/heads/<branch>" to delete "branch"). + + - git-push more aggressively keeps the transferred objects + packed. Earlier we recommended to monitor amount of loose + objects and repack regularly, but you should repack when you + accumulated too many small packs this way as well. Updated + git-count-objects helps you with this. + + - git-fetch also more aggressively keeps the transferred objects + packed. This behavior of git-push and git-fetch can be + tweaked with a single configuration transfer.unpacklimit (but + usually there should not be any need for a user to tweak it). + + - A new command, git-remote, can help you manage your remote + tracking branch definitions. + + - You may need to specify explicit paths for upload-pack and/or + receive-pack due to your ssh daemon configuration on the + other end. This can now be done via remote.*.uploadpack and + remote.*.receivepack configuration. + + +* Bare repositories + + - Certain commands change their behavior in a bare repository + (i.e. a repository without associated working tree). We use + a fairly conservative heuristic (if $GIT_DIR is ".git", or + ends with "/.git", the repository is not bare) to decide if a + repository is bare, but "core.bare" configuration variable + can be used to override the heuristic when it misidentifies + your repository. + + - git-fetch used to complain updating the current branch but + this is now allowed for a bare repository. So is the use of + 'git-branch -f' to update the current branch. + + - Porcelain-ish commands that require a working tree refuses to + work in a bare repository. + + +* Reflog + + - Reflog records the history from the view point of the local + repository. In other words, regardless of the real history, + the reflog shows the history as seen by one particular + repository (this enables you to ask "what was the current + revision in _this_ repository, yesterday at 1pm?"). This + facility is enabled by default for repositories with working + trees, and can be accessed with the "branch@{time}" and + "branch@{Nth}" notation. + + - "git show-branch" learned showing the reflog data with the + new -g option. "git log" has -g option to view reflog + entries in a more verbose manner. + + - git-branch knows how to rename branches and moves existing + reflog data from the old branch to the new one. + + - In addition to the reflog support in v1.4.4 series, HEAD + reference maintains its own log. "HEAD@{5.minutes.ago}" + means the commit you were at 5 minutes ago, which takes + branch switching into account. If you want to know where the + tip of your current branch was at 5 minutes ago, you need to + explicitly say its name (e.g. "master@{5.minutes.ago}") or + omit the refname altogether i.e. "@{5.minutes.ago}". + + - The commits referred to by reflog entries are now protected + against pruning. The new command "git reflog expire" can be + used to truncate older reflog entries and entries that refer + to commits that have been pruned away previously with older + versions of git. + + Existing repositories that have been using reflog may get + complaints from fsck-objects and may not be able to run + git-repack, if you had run git-prune from older git; please + run "git reflog expire --stale-fix --all" first to remove + reflog entries that refer to commits that are no longer in + the repository when that happens. + + +* Crufts removal + + - We used to say "old commits are retrievable using reflog and + 'master@{yesterday}' syntax as long as you haven't run + git-prune". We no longer have to say the latter half of the + above sentence, as git-prune does not remove things reachable + from reflog entries. + + - There is a toplevel garbage collector script, 'git-gc', that + runs periodic cleanup functions, including 'git-repack -a -d', + 'git-reflog expire', 'git-pack-refs --prune', and 'git-rerere + gc'. + + - The output from fsck ("fsck-objects" is called just "fsck" + now, but the old name continues to work) was needlessly + alarming in that it warned missing objects that are reachable + only from dangling objects. This has been corrected and the + output is much more useful. + + +* Detached HEAD + + - You can use 'git-checkout' to check out an arbitrary revision + or a tag as well, instead of named branches. This will + dissociate your HEAD from the branch you are currently on. + + A typical use of this feature is to "look around". E.g. + + $ git checkout v2.6.16 + ... compile, test, etc. + $ git checkout v2.6.17 + ... compile, test, etc. + + - After detaching your HEAD, you can go back to an existing + branch with usual "git checkout $branch". Also you can + start a new branch using "git checkout -b $newbranch" to + start a new branch at that commit. + + - You can even pull from other repositories, make merges and + commits while your HEAD is detached. Also you can use "git + reset" to jump to arbitrary commit, while still keeping your + HEAD detached. + + Remember that a detached state is volatile, i.e. it will be forgotten + as soon as you move away from it with the checkout or reset command, + unless a branch is created from it as mentioned above. It is also + possible to rescue a lost detached state from the HEAD reflog. + + +* Packed refs + + - Repositories with hundreds of tags have been paying large + overhead, both in storage and in runtime, due to the + traditional one-ref-per-file format. A new command, + git-pack-refs, can be used to "pack" them in more efficient + representation (you can let git-gc do this for you). + + - Clones and fetches over dumb transports are now aware of + packed refs and can download from repositories that use + them. + + +* Configuration + + - configuration related to color setting are consolidated under + color.* namespace (older diff.color.*, status.color.* are + still supported). + + - 'git-repo-config' command is accessible as 'git-config' now. + + +* Updated features + + - git-describe uses better criteria to pick a base ref. It + used to pick the one with the newest timestamp, but now it + picks the one that is topologically the closest (that is, + among ancestors of commit C, the ref T that has the shortest + output from "git-rev-list T..C" is chosen). + + - git-describe gives the number of commits since the base ref + between the refname and the hash suffix. E.g. the commit one + before v2.6.20-rc6 in the kernel repository is: + + v2.6.20-rc5-306-ga21b069 + + which tells you that its object name begins with a21b069, + v2.6.20-rc5 is an ancestor of it (meaning, the commit + contains everything -rc5 has), and there are 306 commits + since v2.6.20-rc5. + + - git-describe with --abbrev=0 can be used to show only the + name of the base ref. + + - git-blame learned a new option, --incremental, that tells it + to output the blames as they are assigned. A sample script + to use it is also included as contrib/blameview. + + - git-blame starts annotating from the working tree by default. + + +* Less external dependency + + - We no longer require the "merge" program from the RCS suite. + All 3-way file-level merges are now done internally. + + - The original implementation of git-merge-recursive which was + in Python has been removed; we have a C implementation of it + now. + + - git-shortlog is no longer a Perl script. It no longer + requires output piped from git-log; it can accept revision + parameters directly on the command line. + + +* I18n + + - We have always encouraged the commit message to be encoded in + UTF-8, but the users are allowed to use legacy encoding as + appropriate for their projects. This will continue to be the + case. However, a non UTF-8 commit encoding _must_ be + explicitly set with i18n.commitencoding in the repository + where a commit is made; otherwise git-commit-tree will + complain if the log message does not look like a valid UTF-8 + string. + + - The value of i18n.commitencoding in the originating + repository is recorded in the commit object on the "encoding" + header, if it is not UTF-8. git-log and friends notice this, + and reencodes the message to the log output encoding when + displaying, if they are different. The log output encoding + is determined by "git log --encoding=<encoding>", + i18n.logoutputencoding configuration, or i18n.commitencoding + configuration, in the decreasing order of preference, and + defaults to UTF-8. + + - Tools for e-mailed patch application now default to -u + behavior; i.e. it always re-codes from the e-mailed encoding + to the encoding specified with i18n.commitencoding. This + unfortunately forces projects that have happily been using a + legacy encoding without setting i18n.commitencoding to set + the configuration, but taken with other improvement, please + excuse us for this very minor one-time inconvenience. + + +* e-mailed patches + + - See the above I18n section. + + - git-format-patch now enables --binary without being asked. + git-am does _not_ default to it, as sending binary patch via + e-mail is unusual and is harder to review than textual + patches and it is prudent to require the person who is + applying the patch to explicitly ask for it. + + - The default suffix for git-format-patch output is now ".patch", + not ".txt". This can be changed with --suffix=.txt option, + or setting the config variable "format.suffix" to ".txt". + + +* Foreign SCM interfaces + + - git-svn now requires the Perl SVN:: libraries, the + command-line backend was too slow and limited. + + - the 'commit' subcommand of git-svn has been renamed to + 'set-tree', and 'dcommit' is the recommended replacement for + day-to-day work. + + - git fast-import backend. + + +* User support + + - Quite a lot of documentation updates. + + - Bash completion scripts have been updated heavily. + + - Better error messages for often used Porcelainish commands. + + - Git GUI. This is a simple Tk based graphical interface for + common Git operations. + + +* Sliding mmap + + - We used to assume that we can mmap the whole packfile while + in use, but with a large project this consumes huge virtual + memory space and truly huge ones would not fit in the + userland address space on 32-bit platforms. We now mmap huge + packfile in pieces to avoid this problem. + + +* Shallow clones + + - There is a partial support for 'shallow' repositories that + keeps only recent history. A 'shallow clone' is created by + specifying how deep that truncated history should be + (e.g. "git clone --depth 5 git://some.where/repo.git"). + + Currently a shallow repository has number of limitations: + + - Cloning and fetching _from_ a shallow clone are not + supported (nor tested -- so they might work by accident but + they are not expected to). + + - Pushing from nor into a shallow clone are not expected to + work. + + - Merging inside a shallow repository would work as long as a + merge base is found in the recent history, but otherwise it + will be like merging unrelated histories and may result in + huge conflicts. + + but this would be more than adequate for people who want to + look at near the tip of a big project with a deep history and + send patches in e-mail format. diff --git a/Documentation/RelNotes-1.5.1.1.txt b/Documentation/RelNotes-1.5.1.1.txt new file mode 100644 index 0000000000..91471213bd --- /dev/null +++ b/Documentation/RelNotes-1.5.1.1.txt @@ -0,0 +1,65 @@ +GIT v1.5.1.1 Release Notes +========================== + +Fixes since v1.5.1 +------------------ + +* Documentation updates + + - The --left-right option of rev-list and friends is documented. + + - The documentation for cvsimport has been majorly improved. + + - "git-show-ref --exclude-existing" was documented. + +* Bugfixes + + - The implementation of -p option in "git cvsexportcommit" had + the meaning of -C (context reduction) option wrong, and + loosened the context requirements when it was told to be + strict. + + - "git cvsserver" did not behave like the real cvsserver when + client side removed a file from the working tree without + doing anything else on the path. In such a case, it should + restore it from the checked out revision. + + - "git fsck" issued an alarming error message on detached + HEAD. It is not an error since at least 1.5.0. + + - "git send-email" produced of References header of unbounded length; + fixed this with line-folding. + + - "git archive" to download from remote site should not + require you to be in a git repository, but it incorrectly + did. + + - "git apply" ignored -p<n> for "diff --git" formatted + patches. + + - "git rerere" recorded a conflict that had one side empty + (the other side adds) incorrectly; this made merging in the + other direction fail to use previously recorded resolution. + + - t4200 test was broken where "wc -l" pads its output with + spaces. + + - "git branch -m old new" to rename branch did not work + without a configuration file in ".git/config". + + - The sample hook for notification e-mail was misnamed. + + - gitweb did not show type-changing patch correctly in the + blobdiff view. + + - git-svn did not error out with incorrect command line options. + + - git-svn fell into an infinite loop when insanely long commit + message was found. + + - git-svn dcommit and rebase was confused by patches that were + merged from another branch that is managed by git-svn. + + - git-svn used to get confused when globbing remote branch/tag + spec (e.g. "branches = proj/branches/*:refs/remotes/origin/*") + is used and there was a plain file that matched the glob. diff --git a/Documentation/RelNotes-1.5.1.2.txt b/Documentation/RelNotes-1.5.1.2.txt new file mode 100644 index 0000000000..d88456306c --- /dev/null +++ b/Documentation/RelNotes-1.5.1.2.txt @@ -0,0 +1,50 @@ +GIT v1.5.1.2 Release Notes +========================== + +Fixes since v1.5.1.1 +-------------------- + +* Bugfixes + + - "git clone" over http from a repository that has lost the + loose refs by running "git pack-refs" were broken (a code to + deal with this was added to "git fetch" in v1.5.0, but it + was missing from "git clone"). + + - "git diff a/ b/" incorrectly fell in "diff between two + filesystem objects" codepath, when the user most likely + wanted to limit the extent of output to two tracked + directories. + + - git-quiltimport had the same bug as we fixed for + git-applymbox in v1.5.1.1 -- it gave an alarming "did not + have any patch" message (but did not actually fail and was + harmless). + + - various git-svn fixes. + + - Sample update hook incorrectly always refused requests to + delete branches through push. + + - git-blame on a very long working tree path had buffer + overrun problem. + + - git-apply did not like to be fed two patches in a row that created + and then modified the same file. + + - git-svn was confused when a non-project was stored directly under + trunk/, branches/ and tags/. + + - git-svn wants the Error.pm module that was at least as new + as what we ship as part of git; install ours in our private + installation location if the one on the system is older. + + - An earlier update to command line integer parameter parser was + botched and made 'update-index --cacheinfo' completely useless. + + +* Documentation updates + + - Various documentation updates from J. Bruce Fields, Frank + Lichtenheld, Alex Riesen and others. Andrew Ruder started a + war on undocumented options. diff --git a/Documentation/RelNotes-1.5.1.3.txt b/Documentation/RelNotes-1.5.1.3.txt new file mode 100644 index 0000000000..876408b65a --- /dev/null +++ b/Documentation/RelNotes-1.5.1.3.txt @@ -0,0 +1,45 @@ +GIT v1.5.1.3 Release Notes +========================== + +Fixes since v1.5.1.2 +-------------------- + +* Bugfixes + + - git-add tried to optimize by finding common leading + directories across its arguments but botched, causing very + confused behaviour. + + - unofficial rpm.spec file shipped with git was letting + ETC_GITCONFIG set to /usr/etc/gitconfig. Tweak the official + Makefile to make it harder for distro people to make the + same mistake, by setting the variable to /etc/gitconfig if + prefix is set to /usr. + + - git-svn inconsistently stripped away username from the URL + only when svnsync_props was in use. + + - git-svn got confused when handling symlinks on Mac OS. + + - git-send-email was not quoting recipient names that have + period '.' in them. Also it did not allow overriding + envelope sender, which made it impossible to send patches to + certain subscriber-only lists. + + - built-in write_tree() routine had a sequence that renamed a + file that is still open, which some systems did not like. + + - when memory is very tight, sliding mmap code to read + packfiles incorrectly closed the fd that was still being + used to read the pack. + + - import-tars contributed front-end for fastimport was passing + wrong directory modes without checking. + + - git-fastimport trusted its input too much and allowed to + create corrupt tree objects with entries without a name. + + - git-fetch needlessly barfed when too long reflog action + description was given by the caller. + +Also contains various documentation updates. diff --git a/Documentation/RelNotes-1.5.1.4.txt b/Documentation/RelNotes-1.5.1.4.txt new file mode 100644 index 0000000000..df2f66ccb5 --- /dev/null +++ b/Documentation/RelNotes-1.5.1.4.txt @@ -0,0 +1,30 @@ +GIT v1.5.1.4 Release Notes +========================== + +Fixes since v1.5.1.3 +-------------------- + +* Bugfixes + + - "git-http-fetch" did not work around a bug in libcurl + earlier than 7.16 (curl_multi_remove_handle() was broken). + + - "git cvsserver" handles a file that was once removed and + then added again correctly. + + - import-tars script (in contrib/) handles GNU tar archives + that contain pathnames longer than 100 bytes (long-link + extension) correctly. + + - xdelta test program did not build correctly. + + - gitweb sometimes tried incorrectly to apply function to + decode utf8 twice, resulting in corrupt output. + + - "git blame -C" mishandled text at the end of a group of + lines. + + - "git log/rev-list --boundary" did not produce output + correctly without --left-right option. + + - Many documentation updates. diff --git a/Documentation/RelNotes-1.5.1.5.txt b/Documentation/RelNotes-1.5.1.5.txt new file mode 100644 index 0000000000..b0ab8eb371 --- /dev/null +++ b/Documentation/RelNotes-1.5.1.5.txt @@ -0,0 +1,42 @@ +GIT v1.5.1.5 Release Notes +========================== + +Fixes since v1.5.1.4 +-------------------- + +* Bugfixes + + - git-send-email did not understand aliases file for mutt, which + allows leading whitespaces. + + - git-format-patch emitted Content-Type and Content-Transfer-Encoding + headers for non ASCII contents, but failed to add MIME-Version. + + - git-name-rev had a buffer overrun with a deep history. + + - contributed script import-tars did not get the directory in + tar archives interpreted correctly. + + - git-svn was reported to segfault for many people on list and + #git; hopefully this has been fixed. + + - "git-svn clone" does not try to minimize the URL + (i.e. connect to higher level hierarchy) by default, as this + can prevent clone to fail if only part of the repository + (e.g. 'trunk') is open to public. + + - "git checkout branch^0" did not detach the head when you are + already on 'branch'; backported the fix from the 'master'. + + - "git-config section.var" did not correctly work when + existing configuration file had both [section] and [section "name"] + next to each other. + + - "git clone ../other-directory" was fooled if the current + directory $PWD points at is a symbolic link. + + - (build) tree_entry_extract() function was both static inline + and extern, which caused trouble compiling with Forte12 + compilers on Sun. + + - Many many documentation fixes and updates. diff --git a/Documentation/RelNotes-1.5.1.6.txt b/Documentation/RelNotes-1.5.1.6.txt new file mode 100644 index 0000000000..55f3ac13e3 --- /dev/null +++ b/Documentation/RelNotes-1.5.1.6.txt @@ -0,0 +1,45 @@ +GIT v1.5.1.6 Release Notes +========================== + +Fixes since v1.5.1.4 +-------------------- + +* Bugfixes + + - git-send-email did not understand aliases file for mutt, which + allows leading whitespaces. + + - git-format-patch emitted Content-Type and Content-Transfer-Encoding + headers for non ASCII contents, but failed to add MIME-Version. + + - git-name-rev had a buffer overrun with a deep history. + + - contributed script import-tars did not get the directory in + tar archives interpreted correctly. + + - git-svn was reported to segfault for many people on list and + #git; hopefully this has been fixed. + + - git-svn also had a bug to crash svnserve by sending a bad + sequence of requests. + + - "git-svn clone" does not try to minimize the URL + (i.e. connect to higher level hierarchy) by default, as this + can prevent clone to fail if only part of the repository + (e.g. 'trunk') is open to public. + + - "git checkout branch^0" did not detach the head when you are + already on 'branch'; backported the fix from the 'master'. + + - "git-config section.var" did not correctly work when + existing configuration file had both [section] and [section "name"] + next to each other. + + - "git clone ../other-directory" was fooled if the current + directory $PWD points at is a symbolic link. + + - (build) tree_entry_extract() function was both static inline + and extern, which caused trouble compiling with Forte12 + compilers on Sun. + + - Many many documentation fixes and updates. diff --git a/Documentation/RelNotes-1.5.1.txt b/Documentation/RelNotes-1.5.1.txt new file mode 100644 index 0000000000..daed367270 --- /dev/null +++ b/Documentation/RelNotes-1.5.1.txt @@ -0,0 +1,371 @@ +GIT v1.5.1 Release Notes +======================== + +Updates since v1.5.0 +-------------------- + +* Deprecated commands and options. + + - git-diff-stages and git-resolve have been removed. + +* New commands and options. + + - "git log" and friends take --reverse, which instructs them + to give their output in the order opposite from their usual. + They typically output from new to old, but with this option + their output would read from old to new. "git shortlog" + usually lists older commits first, but with this option, + they are shown from new to old. + + - "git log --pretty=format:<string>" to allow more flexible + custom log output. + + - "git diff" learned --ignore-space-at-eol. This is a weaker + form of --ignore-space-change. + + - "git diff --no-index pathA pathB" can be used as diff + replacement with git specific enhancements. + + - "git diff --no-index" can read from '-' (standard input). + + - "git diff" also learned --exit-code to exit with non-zero + status when it found differences. In the future we might + want to make this the default but that would be a rather big + backward incompatible change; it will stay as an option for + now. + + - "git diff --quiet" is --exit-code with output turned off, + meant for scripted use to quickly determine if there is any + tree-level difference. + + - Textual patch generation with "git diff" without -w/-b + option has been significantly optimized. "git blame" got + faster because of the same change. + + - "git log" and "git rev-list" has been optimized + significantly when they are used with pathspecs. + + - "git branch --track" can be used to set up configuration + variables to help it easier to base your work on branches + you track from a remote site. + + - "git format-patch --attach" now emits attachments. Use + --inline to get an inlined multipart/mixed. + + - "git name-rev" learned --refs=<pattern>, to limit the tags + used for naming the given revisions only to the ones + matching the given pattern. + + - "git remote update" is to run "git fetch" for defined remotes + to update tracking branches. + + - "git cvsimport" can now take '-d' to talk with a CVS + repository different from what are recorded in CVS/Root + (overriding it with environment CVSROOT does not work). + + - "git bundle" can help sneaker-netting your changes between + repositories. + + - "git mergetool" can help 3-way file-level conflict + resolution with your favorite graphical merge tools. + + - A new configuration "core.symlinks" can be used to disable + symlinks on filesystems that do not support them; they are + checked out as regular files instead. + + - You can name a commit object with its first line of the + message. The syntax to use is ':/message text'. E.g. + + $ git show ":/object name: introduce ':/<oneline prefix>' notation" + + means the same thing as: + + $ git show 28a4d940443806412effa246ecc7768a21553ec7 + + - "git bisect" learned a new command "run" that takes a script + to run after each revision is checked out to determine if it + is good or bad, to automate the bisection process. + + - "git log" family learned a new traversal option --first-parent, + which does what the name suggests. + + +* Updated behavior of existing commands. + + - "git-merge-recursive" used to barf when there are more than + one common ancestors for the merge, and merging them had a + rename/rename conflict. This has been fixed. + + - "git fsck" does not barf on corrupt loose objects. + + - "git rm" does not remove newly added files without -f. + + - "git archimport" allows remapping when coming up with git + branch names from arch names. + + - git-svn got almost a rewrite. + + - core.autocrlf configuration, when set to 'true', makes git + to convert CRLF at the end of lines in text files to LF when + reading from the filesystem, and convert in reverse when + writing to the filesystem. The variable can be set to + 'input', in which case the conversion happens only while + reading from the filesystem but files are written out with + LF at the end of lines. Currently, which paths to consider + 'text' (i.e. be subjected to the autocrlf mechanism) is + decided purely based on the contents, but the plan is to + allow users to explicitly override this heuristic based on + paths. + + - The behavior of 'git-apply', when run in a subdirectory, + without --index nor --cached were inconsistent with that of + the command with these options. This was fixed to match the + behavior with --index. A patch that is meant to be applied + with -p1 from the toplevel of the project tree can be + applied with any custom -p<n> option. A patch that is not + relative to the toplevel needs to be applied with -p<n> + option with or without --index (or --cached). + + - "git diff" outputs a trailing HT when pathnames have embedded + SP on +++/--- header lines, in order to help "GNU patch" to + parse its output. "git apply" was already updated to accept + this modified output format since ce74618d (Sep 22, 2006). + + - "git cvsserver" runs hooks/update and honors its exit status. + + - "git cvsserver" can be told to send everything with -kb. + + - "git diff --check" also honors the --color output option. + + - "git name-rev" used to stress the fact that a ref is a tag too + much, by saying something like "v1.2.3^0~22". It now says + "v1.2.3~22" in such a case (it still says "v1.2.3^0" if it does + not talk about an ancestor of the commit that is tagged, which + makes sense). + + - "git rev-list --boundary" now shows boundary markers for the + commits omitted by --max-age and --max-count condition. + + - The configuration mechanism now reads $(prefix)/etc/gitconfig. + + - "git apply --verbose" shows what preimage lines were wanted + when it couldn't find them. + + - "git status" in a read-only repository got a bit saner. + + - "git fetch" (hence "git clone" and "git pull") are less + noisy when the output does not go to tty. + + - "git fetch" between repositories with many refs were slow + even when there are not many changes that needed + transferring. This has been sped up by partially rewriting + the heaviest parts in C. + + - "git mailinfo" which splits an e-mail into a patch and the + meta-information was rewritten, thanks to Don Zickus. It + handles nested multipart better. The command was broken for + a brief period on 'master' branch since 1.5.0 but the + breakage is fixed now. + + - send-email learned configurable bcc and chain-reply-to. + + - "git remote show $remote" also talks about branches that + would be pushed if you run "git push remote". + + - Using objects from packs is now seriously optimized by clever + use of a cache. This should be most noticeable in git-log + family of commands that involve reading many tree objects. + In addition, traversing revisions while filtering changes + with pathspecs is made faster by terminating the comparison + between the trees as early as possible. + + +* Hooks + + - The part to send out notification e-mails was removed from + the sample update hook, as it was not an appropriate place + to do so. The proper place to do this is the new post-receive + hook. An example hook has been added to contrib/hooks/. + + +* Others + + - git-revert, git-gc and git-cherry-pick are now built-ins. + +Fixes since v1.5.0 +------------------ + +These are all in v1.5.0.x series. + +* Documentation updates + + - Clarifications and corrections to 1.5.0 release notes. + + - The main documentation did not link to git-remote documentation. + + - Clarified introductory text of git-rebase documentation. + + - Converted remaining mentions of update-index on Porcelain + documents to git-add/git-rm. + + - Some i18n.* configuration variables were incorrectly + described as core.*; fixed. + + - added and clarified core.bare, core.legacyheaders configurations. + + - updated "git-clone --depth" documentation. + + - user-manual updates. + + - Options to 'git remote add' were described insufficiently. + + - Configuration format.suffix was not documented. + + - Other formatting and spelling fixes. + + - user-manual has better cross references. + + - gitweb installation/deployment procedure is now documented. + + +* Bugfixes + + - git-upload-pack closes unused pipe ends; earlier this caused + many zombies to hang around. + + - git-rerere was recording the contents of earlier hunks + duplicated in later hunks. This prevented resolving the same + conflict when performing the same merge the other way around. + + - git-add and git-update-index on a filesystem on which + executable bits are unreliable incorrectly reused st_mode + bits even when the path changed between symlink and regular + file. + + - git-daemon marks the listening sockets with FD_CLOEXEC so + that it won't be leaked into the children. + + - segfault from git-blame when the mandatory pathname + parameter was missing was fixed; usage() message is given + instead. + + - git-rev-list did not read $GIT_DIR/config file, which means + that did not honor i18n.logoutputencoding correctly. + + - Automated merge conflict handling when changes to symbolic + links conflicted were completely broken. The merge-resolve + strategy created a regular file with conflict markers in it + in place of the symbolic link. The default strategy, + merge-recursive was even more broken. It removed the path + that was pointed at by the symbolic link. Both of these + problems have been fixed. + + - 'git diff maint master next' did not correctly give combined + diff across three trees. + + - 'git fast-import' portability fix for Solaris. + + - 'git show-ref --verify' without arguments did not error out + but segfaulted. + + - 'git diff :tracked-file `pwd`/an-untracked-file' gave an extra + slashes after a/ and b/. + + - 'git format-patch' produced too long filenames if the commit + message had too long line at the beginning. + + - Running 'make all' and then without changing anything + running 'make install' still rebuilt some files. This + was inconvenient when building as yourself and then + installing as root (especially problematic when the source + directory is on NFS and root is mapped to nobody). + + - 'git-rerere' failed to deal with two unconflicted paths that + sorted next to each other. + + - 'git-rerere' attempted to open(2) a symlink and failed if + there was a conflict. Since a conflicting change to a + symlink would not benefit from rerere anyway, the command + now ignores conflicting changes to symlinks. + + - 'git-repack' did not like to pass more than 64 arguments + internally to underlying 'rev-list' logic, which made it + impossible to repack after accumulating many (small) packs + in the repository. + + - 'git-diff' to review the combined diff during a conflicted + merge were not reading the working tree version correctly + when changes to a symbolic link conflicted. It should have + read the data using readlink(2) but read from the regular + file the symbolic link pointed at. + + - 'git-remote' did not like period in a remote's name. + + - 'git.el' honors the commit coding system from the configuration. + + - 'blameview' in contrib/ correctly digs deeper when a line is + clicked. + + - 'http-push' correctly makes sure the remote side has leading + path. Earlier it started in the middle of the path, and + incorrectly. + + - 'git-merge' did not exit with non-zero status when the + working tree was dirty and cannot fast forward. It does + now. + + - 'cvsexportcommit' does not lose yet-to-be-used message file. + + - int-vs-size_t typefix when running combined diff on files + over 2GB long. + + - 'git apply --whitespace=strip' should not touch unmodified + lines. + + - 'git-mailinfo' choke when a logical header line was too long. + + - 'git show A..B' did not error out. Negative ref ("not A" in + this example) does not make sense for the purpose of the + command, so now it errors out. + + - 'git fmt-merge-msg --file' without file parameter did not + correctly error out. + + - 'git archimport' barfed upon encountering a commit without + summary. + + - 'git index-pack' did not protect itself from getting a short + read out of pread(2). + + - 'git http-push' had a few buffer overruns. + + - Build dependency fixes to rebuild fetch.o when other headers + change. + + - git.el does not add duplicate sign-off lines. + + - git-commit shows the full stat of the resulting commit, not + just about the files in the current directory, when run from + a subdirectory. + + - "git-checkout -m '@{8 hours ago}'" had a funny failure from + eval; fixed. + + - git-merge (hence git-pull) did not refuse fast-forwarding + when the working tree had local changes that would have + conflicted with it. + + - a handful small fixes to gitweb. + + - build procedure for user-manual is fixed not to require locally + installed stylesheets. + + - "git commit $paths" on paths whose earlier contents were + already updated in the index were failing out. + + +* Tweaks + + - sliding mmap() inefficiently mmaped the same region of a + packfile with an access pattern that used objects in the + reverse order. This has been made more efficient. diff --git a/Documentation/RelNotes-1.5.2.1.txt b/Documentation/RelNotes-1.5.2.1.txt new file mode 100644 index 0000000000..ebf20e22a7 --- /dev/null +++ b/Documentation/RelNotes-1.5.2.1.txt @@ -0,0 +1,53 @@ +GIT v1.5.2.1 Release Notes +========================== + +Fixes since v1.5.2 +------------------ + +* Bugfixes + + - Temporary files that are used when invoking external diff + programs did not tolerate a long TMPDIR. + + - git-daemon did not notice when it could not write into its + pid file. + + - git-status did not honor core.excludesFile configuration like + git-add did. + + - git-annotate did not work from a subdirectory while + git-blame did. + + - git-cvsserver should have disabled access to a repository + with "gitcvs.pserver.enabled = false" set even when + "gitcvs.enabled = true" was set at the same time. It + didn't. + + - git-cvsimport did not work correctly in a repository with + its branch heads were packed with pack-refs. + + - ident unexpansion to squash "$Id: xxx $" that is in the + repository copy removed incorrect number of bytes. + + - git-svn misbehaved when the subversion repository did not + provide MD5 checksums for files. + + - git rebase (and git am) misbehaved on commits that have '\n' + (literally backslash and en, not a linefeed) in the title. + + - code to decode base85 used in binary patches had one error + return codepath wrong. + + - RFC2047 Q encoding output by git-format-patch used '_' for a + space, which is not understood by some programs. It uses =20 + which is safer. + + - 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.5.2.2.txt b/Documentation/RelNotes-1.5.2.2.txt new file mode 100644 index 0000000000..7bfa341750 --- /dev/null +++ b/Documentation/RelNotes-1.5.2.2.txt @@ -0,0 +1,61 @@ +GIT v1.5.2.2 Release Notes +========================== + +Fixes since v1.5.2.1 +-------------------- + +* Usability fix + + - git-gui is shipped with its updated blame interface. It is + rumored that the older one was not just unusable but was + active health hazard, but this one is actually pretty. + Please see for yourself. + +* Bugfixes + + - "git checkout fubar" was utterly confused when there is a + branch fubar and a tag fubar at the same time. It correctly + checks out the branch fubar now. + + - "git clone /path/foo" to clone a local /path/foo.git + repository left an incorrect configuration. + + - "git send-email" correctly unquotes RFC 2047 quoted names in + the patch-email before using their values. + + - We did not accept number of seconds since epoch older than + year 2000 as a valid timestamp. We now interpret positive + integers more than 8 digits as such, which allows us to + express timestamps more recent than March 1973. + + - git-cvsimport did not work when you have GIT_DIR to point + your repository at a nonstandard location. + + - Some systems (notably, Solaris) lack hstrerror() to make + h_errno human readable; prepare a replacement + implementation. + + - .gitignore file listed git-core.spec but what we generate is + git.spec, and nobody noticed for a long time. + + - "git-merge-recursive" does not try to run file level merge + on binary files. + + - "git-branch --track" did not create tracking configuration + correctly when the branch name had slash in it. + + - The email address of the user specified with user.email + configuration was overridden by EMAIL environment variable. + + - The tree parser did not warn about tree entries with + nonsense file modes, and assumed they must be blobs. + + - "git log -z" without any other request to generate diff still + invoked the diff machinery, wasting cycles. + +* Documentation + + - Many updates to fix stale or missing documentation. + + - Although our documentation was primarily meant to be formatted + with AsciiDoc7, formatting with AsciiDoc8 is supported better. diff --git a/Documentation/RelNotes-1.5.2.3.txt b/Documentation/RelNotes-1.5.2.3.txt new file mode 100644 index 0000000000..addb22955b --- /dev/null +++ b/Documentation/RelNotes-1.5.2.3.txt @@ -0,0 +1,27 @@ +GIT v1.5.2.3 Release Notes +========================== + +Fixes since v1.5.2.2 +-------------------- + + * Bugfixes + + - Version 2 pack index format was introduced in version 1.5.2 + to support pack files that has offset that cannot be + represented in 32-bit. The runtime code to validate such + an index mishandled such an index for an empty pack. + + - Commit walkers (most notably, fetch over http protocol) + tried to traverse commit objects contained in trees (aka + subproject); they shouldn't. + + - A build option NO_R_TO_GCC_LINKER was not explained in Makefile + comment correctly. + + * Documentation Fixes and Updates + + - git-config --regexp was not documented properly. + + - git-repack -a was not documented properly. + + - git-remote -n was not documented properly. diff --git a/Documentation/RelNotes-1.5.2.4.txt b/Documentation/RelNotes-1.5.2.4.txt new file mode 100644 index 0000000000..75cff475f6 --- /dev/null +++ b/Documentation/RelNotes-1.5.2.4.txt @@ -0,0 +1,28 @@ +GIT v1.5.2.4 Release Notes +========================== + +Fixes since v1.5.2.3 +-------------------- + + * Bugfixes + + - "git-gui" bugfixes, including a handful fixes to run it + better on Cygwin/MSYS. + + - "git checkout" failed to switch back and forth between + branches, one of which has "frotz -> xyzzy" symlink and + file "xyzzy/filfre", while the other one has a file + "frotz/filfre". + + - "git prune" used to segfault upon seeing a commit that is + referred to by a tree object (aka "subproject"). + + - "git diff --name-status --no-index" mishandled an added file. + + - "git apply --reverse --whitespace=warn" still complained + about whitespaces that a forward application would have + introduced. + + * Documentation Fixes and Updates + + - A handful documentation updates. diff --git a/Documentation/RelNotes-1.5.2.5.txt b/Documentation/RelNotes-1.5.2.5.txt new file mode 100644 index 0000000000..e8281c72a0 --- /dev/null +++ b/Documentation/RelNotes-1.5.2.5.txt @@ -0,0 +1,30 @@ +GIT v1.5.2.5 Release Notes +========================== + +Fixes since v1.5.2.4 +-------------------- + + * Bugfixes + + - "git add -u" had a serious data corruption problem in one + special case (when the changes to a subdirectory's files + consist only deletion of files). + + - "git add -u <path>" did not work from a subdirectory. + + - "git apply" left an empty directory after all its files are + renamed away. + + - "git $anycmd foo/bar", when there is a file 'foo' in the + working tree, complained that "git $anycmd foo/bar --" form + should be used to disambiguate between revs and files, + which was completely bogus. + + - "git checkout-index" and other commands that checks out + files to the work tree tried unlink(2) on directories, + which is a sane thing to do on sane systems, but not on + Solaris when you are root. + + * Documentation Fixes and Updates + + - A handful documentation fixes. diff --git a/Documentation/RelNotes-1.5.2.txt b/Documentation/RelNotes-1.5.2.txt new file mode 100644 index 0000000000..e8328d090a --- /dev/null +++ b/Documentation/RelNotes-1.5.2.txt @@ -0,0 +1,197 @@ +GIT v1.5.2 Release Notes +======================== + +Updates since v1.5.1 +-------------------- + +* Plumbing level superproject support. + + You can include a subdirectory that has an independent git + repository in your index and tree objects of your project + ("superproject"). This plumbing (i.e. "core") level + superproject support explicitly excludes recursive behaviour. + + The "subproject" entries in the index and trees of a superproject + are incompatible with older versions of git. Experimenting with + the plumbing level support is encouraged, but be warned that + unless everybody in your project updates to this release or + later, using this feature would make your project + inaccessible by people with older versions of git. + +* Plumbing level gitattributes support. + + The gitattributes mechanism allows you to add 'attributes' to + paths in your project, and affect the way certain git + operations work. Currently you can influence if a path is + considered a binary or text (the former would be treated by + 'git diff' not to produce textual output; the latter can go + through the line endings conversion process in repositories + with core.autocrlf set), expand and unexpand '$Id$' keyword + with blob object name, specify a custom 3-way merge driver, + and specify a custom diff driver. You can also apply + arbitrary filter to contents on check-in/check-out codepath + but this feature is an extremely sharp-edged razor and needs + to be handled with caution (do not use it unless you + understand the earlier mailing list discussion on keyword + expansion). These conversions apply when checking files in + or out, and exporting via git-archive. + +* The packfile format now optionally supports 64-bit index. + + This release supports the "version 2" format of the .idx + file. This is automatically enabled when a huge packfile + needs more than 32-bit to express offsets of objects in the + pack. + +* Comes with an updated git-gui 0.7.1 + +* Updated gitweb: + + - can show combined diff for merges; + - uses font size of user's preference, not hardcoded in pixels; + - can now 'grep'; + +* New commands and options. + + - "git bisect start" can optionally take a single bad commit and + zero or more good commits on the command line. + + - "git shortlog" can optionally be told to wrap its output. + + - "subtree" merge strategy allows another project to be merged in as + your subdirectory. + + - "git format-patch" learned a new --subject-prefix=<string> + option, to override the built-in "[PATCH]". + + - "git add -u" is a quick way to do the first stage of "git + commit -a" (i.e. update the index to match the working + tree); it obviously does not make a commit. + + - "git clean" honors a new configuration, "clean.requireforce". When + set to true, this makes "git clean" a no-op, preventing you + from losing files by typing "git clean" when you meant to + say "make clean". You can still say "git clean -f" to + override this. + + - "git log" family of commands learned --date={local,relative,default} + option. --date=relative is synonym to the --relative-date. + --date=local gives the timestamp in local timezone. + +* Updated behavior of existing commands. + + - When $GIT_COMMITTER_EMAIL or $GIT_AUTHOR_EMAIL is not set + but $EMAIL is set, the latter is used as a substitute. + + - "git diff --stat" shows size of preimage and postimage blobs + for binary contents. Earlier it only said "Bin". + + - "git lost-found" shows stuff that are unreachable except + from reflogs. + + - "git checkout branch^0" now detaches HEAD at the tip commit + on the named branch, instead of just switching to the + branch (use "git checkout branch" to switch to the branch, + as before). + + - "git bisect next" can be used after giving only a bad commit + without giving a good one (this starts bisection half-way to + the root commit). We used to refuse to operate without a + good and a bad commit. + + - "git push", when pushing into more than one repository, does + not stop at the first error. + + - "git archive" does not insist you to give --format parameter + anymore; it defaults to "tar". + + - "git cvsserver" can use backends other than sqlite. + + - "gitview" (in contrib/ section) learned to better support + "git-annotate". + + - "git diff $commit1:$path2 $commit2:$path2" can now report + mode changes between the two blobs. + + - Local "git fetch" from a repository whose object store is + one of the alternates (e.g. fetching from the origin in a + repository created with "git clone -l -s") avoids + downloading objects unnecessarily. + + - "git blame" uses .mailmap to canonicalize the author name + just like "git shortlog" does. + + - "git pack-objects" pays attention to pack.depth + configuration variable. + + - "git cherry-pick" and "git revert" does not use .msg file in + the working tree to prepare commit message; instead it uses + $GIT_DIR/MERGE_MSG as other commands do. + +* Builds + + - git-p4import has never been installed; now there is an + installation option to do so. + + - gitk and git-gui can be configured out. + + - Generated documentation pages automatically get version + information from GIT_VERSION. + + - Parallel build with "make -j" descending into subdirectory + was fixed. + +* Performance Tweaks + + - Optimized "git-rev-list --bisect" (hence "git-bisect"). + + - Optimized "git-add $path" in a large directory, most of + whose contents are ignored. + + - Optimized "git-diff-tree" for reduced memory footprint. + + - The recursive merge strategy updated a worktree file that + was changed identically in two branches, when one of them + renamed it. We do not do that when there is no rename, so + match that behaviour. This avoids excessive rebuilds. + + - The default pack depth has been increased to 50, as the + recent addition of delta_base_cache makes deeper delta chains + much less expensive to access. Depending on the project, it was + reported that this reduces the resulting pack file by 10% + or so. + + +Fixes since v1.5.1 +------------------ + +All of the fixes in v1.5.1 maintenance series are included in +this release, unless otherwise noted. + +* Bugfixes + + - Switching branches with "git checkout" refused to work when + a path changes from a file to a directory between the + current branch and the new branch, in order not to lose + possible local changes in the directory that is being turned + into a file with the switch. We now allow such a branch + switch after making sure that there is no locally modified + file nor un-ignored file in the directory. This has not + been backported to 1.5.1.x series, as it is rather an + intrusive change. + + - Merging branches that have a file in one and a directory in + another at the same path used to get quite confused. We + handle such a case a bit more carefully, even though that is + still left as a conflict for the user to sort out. This + will not be backported to 1.5.1.x series, as it is rather an + intrusive change. + + - git-fetch had trouble with a remote with insanely large number + of refs. + + - "git clean -d -X" now does not remove non-excluded directories. + + - rebasing (without -m) a series that changes a symlink to a directory + in the middle of a path confused git-apply greatly and refused to + operate. diff --git a/Documentation/RelNotes-1.5.3.1.txt b/Documentation/RelNotes-1.5.3.1.txt new file mode 100644 index 0000000000..7ff546c743 --- /dev/null +++ b/Documentation/RelNotes-1.5.3.1.txt @@ -0,0 +1,10 @@ +GIT v1.5.3.1 Release Notes +========================== + +Fixes since v1.5.3 +------------------ + +This is solely to fix the generated RPM's dependencies. We used +to have git-p4 package but we do not anymore. As suggested on +the mailing list, this release makes git-core "Obsolete" git-p4, +so that yum update would not complain. diff --git a/Documentation/RelNotes-1.5.3.2.txt b/Documentation/RelNotes-1.5.3.2.txt new file mode 100644 index 0000000000..4bbde3cab4 --- /dev/null +++ b/Documentation/RelNotes-1.5.3.2.txt @@ -0,0 +1,58 @@ +GIT v1.5.3.2 Release Notes +========================== + +Fixes since v1.5.3.1 +-------------------- + + * git-push sent thin packs by default, which was not good for + the public distribution server (no point in saving transfer + while pushing; no point in making the resulting pack less + optimum). + + * git-svn sometimes terminated with "Malformed network data" when + talking over svn:// protocol. + + * git-send-email re-issued the same message-id about 10% of the + time if you fired off 30 messages within a single second. + + * git-stash was not terminating the log message of commits it + internally creates with LF. + + * git-apply failed to check the size of the patch hunk when its + beginning part matched the remainder of the preimage exactly, + even though the preimage recorded in the hunk was much larger + (therefore the patch should not have applied), leading to a + segfault. + + * "git rm foo && git commit foo" complained that 'foo' needs to + be added first, instead of committing the removal, which was a + nonsense. + + * git grep -c said "/dev/null: 0". + + * git-add -u failed to recognize a blob whose type changed + between the index and the work tree. + + * The limit to rename detection has been tightened a lot to + reduce performance problems with a huge change. + + * cvsimport and svnimport barfed when the input tried to move + a tag. + + * "git apply -pN" did not chop the right number of directories. + + * "git svnimport" did not like SVN tags with funny characters in them. + + * git-gui 0.8.3, with assorted fixes, including: + + - font-chooser on X11 was unusable with large number of fonts; + - a diff that contained a deleted symlink made it barf; + - an untracked symbolic link to a directory made it fart; + - a file with % in its name made it vomit; + + +Documentation updates +--------------------- + +User manual has been somewhat restructured. I think the new +organization is much easier to read. diff --git a/Documentation/RelNotes-1.5.3.3.txt b/Documentation/RelNotes-1.5.3.3.txt new file mode 100644 index 0000000000..d213846951 --- /dev/null +++ b/Documentation/RelNotes-1.5.3.3.txt @@ -0,0 +1,31 @@ +GIT v1.5.3.3 Release Notes +========================== + +Fixes since v1.5.3.2 +-------------------- + + * git-quiltimport did not like it when a patch described in the + series file does not exist. + + * p4 importer missed executable bit in some cases. + + * The default shell on some FreeBSD did not execute the + argument parsing code correctly and made git unusable. + + * git-svn incorrectly spawned pager even when the user + explicitly asked not to. + + * sample post-receive hook overquoted the envelope sender + value. + + * git-am got confused when the patch contained a change that is + only about type and not contents. + + * git-mergetool did not show our and their version of the + conflicted file when started from a subdirectory of the + project. + + * git-mergetool did not pass correct options when invoking diff3. + + * git-log sometimes invoked underlying "diff" machinery + unnecessarily. diff --git a/Documentation/RelNotes-1.5.3.4.txt b/Documentation/RelNotes-1.5.3.4.txt new file mode 100644 index 0000000000..b04b3a45a5 --- /dev/null +++ b/Documentation/RelNotes-1.5.3.4.txt @@ -0,0 +1,35 @@ +GIT v1.5.3.4 Release Notes +========================== + +Fixes since v1.5.3.3 +-------------------- + + * Change to "git-ls-files" in v1.5.3.3 that was introduced to support + partial commit of removal better had a segfaulting bug, which was + diagnosed and fixed by Keith and Carl. + + * Performance improvements for rename detection has been backported + from the 'master' branch. + + * "git-for-each-ref --format='%(numparent)'" was not working + correctly at all, and --format='%(parent)' was not working for + merge commits. + + * Sample "post-receive-hook" incorrectly sent out push + notification e-mails marked as "From: " the committer of the + commit that happened to be at the tip of the branch that was + pushed, not from the person who pushed. + + * "git-remote" did not exit non-zero status upon error. + + * "git-add -i" did not respond very well to EOF from tty nor + bogus input. + + * "git-rebase -i" squash subcommand incorrectly made the + author of later commit the author of resulting commit, + instead of taking from the first one in the squashed series. + + * "git-stash apply --index" was not documented. + + * autoconfiguration learned that "ar" command is found as "gas" on + some systems. diff --git a/Documentation/RelNotes-1.5.3.5.txt b/Documentation/RelNotes-1.5.3.5.txt new file mode 100644 index 0000000000..7ff1d5d0d1 --- /dev/null +++ b/Documentation/RelNotes-1.5.3.5.txt @@ -0,0 +1,94 @@ +GIT v1.5.3.5 Release Notes +========================== + +Fixes since v1.5.3.4 +-------------------- + + * Comes with git-gui 0.8.4. + + * "git-config" silently ignored options after --list; now it will + error out with a usage message. + + * "git-config --file" failed if the argument used a relative path + as it changed directories before opening the file. + + * "git-config --file" now displays a proper error message if it + cannot read the file specified on the command line. + + * "git-config", "git-diff", "git-apply" failed if run from a + subdirectory with relative GIT_DIR and GIT_WORK_TREE set. + + * "git-blame" crashed if run during a merge conflict. + + * "git-add -i" did not handle single line hunks correctly. + + * "git-rebase -i" and "git-stash apply" failed if external diff + drivers were used for one or more files in a commit. They now + avoid calling the external diff drivers. + + * "git-log --follow" did not work unless diff generation (e.g. -p) + was also requested. + + * "git-log --follow -B" did not work at all. Fixed. + + * "git-log -M -B" did not correctly handle cases of very large files + being renamed and replaced by very small files in the same commit. + + * "git-log" printed extra newlines between commits when a diff + was generated internally (e.g. -S or --follow) but not displayed. + + * "git-push" error message is more helpful when pushing to a + repository with no matching refs and none specified. + + * "git-push" now respects + (force push) on wildcard refspecs, + matching the behavior of git-fetch. + + * "git-filter-branch" now updates the working directory when it + has finished filtering the current branch. + + * "git-instaweb" no longer fails on Mac OS X. + + * "git-cvsexportcommit" didn't always create new parent directories + before trying to create new child directories. Fixed. + + * "git-fetch" printed a scary (but bogus) error message while + fetching a tag that pointed to a tree or blob. The error did + not impact correctness, only user perception. The bogus error + is no longer printed. + + * "git-ls-files --ignored" did not properly descend into non-ignored + directories that themselves contained ignored files if d_type + was not supported by the filesystem. This bug impacted systems + such as AFS. Fixed. + + * Git segfaulted when reading an invalid .gitattributes file. Fixed. + + * post-receive-email example hook was fixed for non-fast-forward + updates. + + * Documentation updates for supported (but previously undocumented) + options of "git-archive" and "git-reflog". + + * "make clean" no longer deletes the configure script that ships + with the git tarball, making multiple architecture builds easier. + + * "git-remote show origin" spewed a warning message from Perl + when no remote is defined for the current branch via + branch.<name>.remote configuration settings. + + * Building with NO_PERL_MAKEMAKER excessively rebuilt contents + of perl/ subdirectory by rewriting perl.mak. + + * http.sslVerify configuration settings were not used in scripted + Porcelains. + + * "git-add" leaked a bit of memory while scanning for files to add. + + * A few workarounds to squelch false warnings from recent gcc have + been added. + + * "git-send-pack $remote frotz" segfaulted when there is nothing + named 'frotz' on the local end. + + * "git-rebase --interactive" did not handle its "--strategy" option + properly. diff --git a/Documentation/RelNotes-1.5.3.6.txt b/Documentation/RelNotes-1.5.3.6.txt new file mode 100644 index 0000000000..069a2b2cf9 --- /dev/null +++ b/Documentation/RelNotes-1.5.3.6.txt @@ -0,0 +1,48 @@ +GIT v1.5.3.6 Release Notes +========================== + +Fixes since v1.5.3.5 +-------------------- + + * git-cvsexportcommit handles root commits better. + + * git-svn dcommit used to clobber when sending a series of + patches. + + * git-svn dcommit failed after attempting to rebase when + started with a dirty index; now it stops upfront. + + * git-grep sometimes refused to work when your index was + unmerged. + + * "git-grep -A1 -B2" acted as if it was told to run "git -A1 -B21". + + * git-hash-object did not honor configuration variables, such as + core.compression. + + * git-index-pack choked on a huge pack on 32-bit machines, even when + large file offsets are supported. + + * atom feeds from git-web said "10" for the month of November. + + * a memory leak in commit walker was plugged. + + * When git-send-email inserted the original author's From: + address in body, it did not mark the message with + Content-type: as needed. + + * git-revert and git-cherry-pick incorrectly refused to start + when the work tree was dirty. + + * git-clean did not honor core.excludesfile configuration. + + * git-add mishandled ".gitignore" files when applying them to + subdirectories. + + * While importing a too branchy history, git-fastimport did not + honor delta depth limit properly. + + * Support for zlib implementations that lack ZLIB_VERNUM and definition + of deflateBound() has been added. + + * Quite a lot of documentation clarifications. diff --git a/Documentation/RelNotes-1.5.3.7.txt b/Documentation/RelNotes-1.5.3.7.txt new file mode 100644 index 0000000000..2f690616c8 --- /dev/null +++ b/Documentation/RelNotes-1.5.3.7.txt @@ -0,0 +1,45 @@ +GIT v1.5.3.7 Release Notes +========================== + +Fixes since v1.5.3.6 +-------------------- + + * git-send-email added 8-bit contents to the payload without + marking it as 8-bit in a CTE header. + + * "git-bundle create a.bndl HEAD" dereferenced the symref and + did not record the ref as 'HEAD'; this prevented a bundle + from being used as a normal source of git-clone. + + * The code to reject nonsense command line of the form + "git-commit -a paths..." and "git-commit --interactive + paths..." were broken. + + * Adding a signature that is not ASCII-only to an original + commit that is ASCII-only would make the result non-ASCII. + "git-format-patch -s" did not mark such a message correctly + with MIME encoding header. + + * git-add sometimes did not mark the resulting index entry + stat-clean. This affected only cases when adding the + contents with the same length as the previously staged + contents, and the previous staging made the index entry + "racily clean". + + * git-commit did not honor GIT_INDEX_FILE the user had in the + environment. + + * When checking out a revision, git-checkout did not report where the + updated HEAD is if you happened to have a file called HEAD in the + work tree. + + * "git-rev-list --objects" mishandled a tree that points at a + submodule. + + * "git cvsimport" was not ready for packed refs that "git gc" can + produce and gave incorrect results. + + * Many scripted Porcelains were confused when you happened to have a + file called "HEAD" in your work tree. + +Also it contains updates to the user manual and documentation. diff --git a/Documentation/RelNotes-1.5.3.8.txt b/Documentation/RelNotes-1.5.3.8.txt new file mode 100644 index 0000000000..0e3ff58a46 --- /dev/null +++ b/Documentation/RelNotes-1.5.3.8.txt @@ -0,0 +1,25 @@ +GIT v1.5.3.8 Release Notes +========================== + +Fixes since v1.5.3.7 +-------------------- + + * Some documentation used "email.com" as an example domain. + + * git-svn fix to handle funky branch and project names going over + http/https correctly. + + * git-svn fix to tone down a needlessly alarming warning message. + + * git-clone did not correctly report errors while fetching over http. + + * git-send-email added redundant Message-Id: header to the outgoing + e-mail when the patch text already had one. + + * a read-beyond-end-of-buffer bug in configuration file updater was fixed. + + * git-grep used to show the same hit repeatedly for unmerged paths. + + * After amending the patch title in "git-am -i", the command did not + report the patch it applied with the updated title. + diff --git a/Documentation/RelNotes-1.5.3.txt b/Documentation/RelNotes-1.5.3.txt new file mode 100644 index 0000000000..0668d3c0ca --- /dev/null +++ b/Documentation/RelNotes-1.5.3.txt @@ -0,0 +1,366 @@ +GIT v1.5.3 Release Notes +======================== + +Updates since v1.5.2 +-------------------- + +* The commit walkers other than http are officially deprecated, + but still supported for now. + +* The submodule support has Porcelain layer. + + Note that the current submodule support is minimal and this is + deliberately so. A design decision we made is that operations + at the supermodule level do not recurse into submodules by + default. The expectation is that later we would add a + mechanism to tell git which submodules the user is interested + in, and this information might be used to determine the + recursive behaviour of certain commands (e.g. "git checkout" + and "git diff"), but currently we haven't agreed on what that + mechanism should look like. Therefore, if you use submodules, + you would probably need "git submodule update" on the + submodules you care about after running a "git checkout" at + the supermodule level. + +* There are a handful pack-objects changes to help you cope better + with repositories with pathologically large blobs in them. + +* For people who need to import from Perforce, a front-end for + fast-import is in contrib/fast-import/. + +* Comes with git-gui 0.8.2. + +* Comes with updated gitk. + +* New commands and options. + + - "git log --date=<format>" can use more formats: iso8601, rfc2822. + + - The hunk header output from "git diff" family can be customized + with the attributes mechanism. See gitattributes(5) for details. + + - "git stash" allows you to quickly save away your work in + progress and replay it later on an updated state. + + - "git rebase" learned an "interactive" mode that let you + pick and reorder which commits to rebuild. + + - "git fsck" can save its findings in $GIT_DIR/lost-found, without a + separate invocation of "git lost-found" command. The blobs stored by + lost-found are stored in plain format to allow you to grep in them. + + - $GIT_WORK_TREE environment variable can be used together with + $GIT_DIR to work in a subdirectory of a working tree that is + not located at "$GIT_DIR/..". + + - Giving "--file=<file>" option to "git config" is the same as + running the command with GIT_CONFIG=<file> environment. + + - "git log" learned a new option "--follow", to follow + renaming history of a single file. + + - "git filter-branch" lets you rewrite the revision history of + specified branches. You can specify a number of filters to + modify the commits, files and trees. + + - "git cvsserver" learned new options (--base-path, --export-all, + --strict-paths) inspired by "git daemon". + + - "git daemon --base-path-relaxed" can help migrating a repository URL + that did not use to use --base-path to use --base-path. + + - "git commit" can use "-t templatefile" option and commit.template + configuration variable to prime the commit message given to you in the + editor. + + - "git submodule" command helps you manage the projects from + the superproject that contain them. + + - In addition to core.compression configuration option, + core.loosecompression and pack.compression options can + independently tweak zlib compression levels used for loose + and packed objects. + + - "git ls-tree -l" shows size of blobs pointed at by the + tree entries, similar to "/bin/ls -l". + + - "git rev-list" learned --regexp-ignore-case and + --extended-regexp options to tweak its matching logic used + for --grep filtering. + + - "git describe --contains" is a handier way to call more + obscure command "git name-rev --tags". + + - "git gc --aggressive" tells the command to spend more cycles + to optimize the repository harder. + + - "git repack" learned a "window-memory" limit which + dynamically reduces the window size to stay within the + specified memory usage. + + - "git repack" can be told to split resulting packs to avoid + exceeding limit specified with "--max-pack-size". + + - "git fsck" gained --verbose option. This is really really + verbose but it might help you identify exact commit that is + corrupt in your repository. + + - "git format-patch" learned --numbered-files option. This + may be useful for MH users. + + - "git format-patch" learned format.subjectprefix configuration + variable, which serves the same purpose as "--subject-prefix" + option. + + - "git tag -n -l" shows tag annotations while listing tags. + + - "git cvsimport" can optionally use the separate-remote layout. + + - "git blame" can be told to see through commits that change + whitespaces and indentation levels with "-w" option. + + - "git send-email" can be told not to thread the messages when + sending out more than one patches. + + - "git send-email" can also be told how to find whom to cc the + message to for each message via --cc-cmd. + + - "git config" learned NUL terminated output format via -z to + help scripts. + + - "git add" learned "--refresh <paths>..." option to selectively refresh + the cached stat information. + + - "git init -q" makes the command quieter. + + - "git -p command" now has a cousin of opposite sex, "git --no-pager + command". + +* Updated behavior of existing commands. + + - "gitweb" can offer multiple snapshot formats. + + ***NOTE*** Unfortunately, this changes the format of the + $feature{snapshot}{default} entry in the per-site + configuration file 'gitweb_config.perl'. It used to be a + three-element tuple that describe a single format; with the + new configuration item format, you only have to say the name + of the format ('tgz', 'tbz2' or 'zip'). Please update the + your configuration file accordingly. + + - "git clone" uses -l (hardlink files under .git) by default when + cloning locally. + + - URL used for "git clone" and friends can specify nonstandard SSH port + by using ssh://host:port/path/to/repo syntax. + + - "git bundle create" can now create a bundle without negative refs, + i.e. "everything since the beginning up to certain points". + + - "git diff" (but not the plumbing level "git diff-tree") now + recursively descends into trees by default. + + - "git diff" does not show differences that come only from + stat-dirtiness in the form of "diff --git" header anymore. + It runs "update-index --refresh" silently as needed. + + - "git tag -l" used to match tags by globbing its parameter as if it + has wildcard '*' on both ends, which made "git tag -l gui" to match + tag 'gitgui-0.7.0'; this was very annoying. You now have to add + asterisk on the sides you want to wildcard yourself. + + - The editor to use with many interactive commands can be + overridden with GIT_EDITOR environment variable, or if it + does not exist, with core.editor configuration variable. As + before, if you have neither, environment variables VISUAL + and EDITOR are consulted in this order, and then finally we + fall back on "vi". + + - "git rm --cached" does not complain when removing a newly + added file from the index anymore. + + - Options to "git log" to affect how --grep/--author options look for + given strings now have shorter abbreviations. -i is for ignore case, + and -E is for extended regexp. + + - "git log" learned --log-size to show the number of bytes in + the log message part of the output to help qgit. + + - "git log --name-status" does not require you to give "-r" anymore. + As a general rule, Porcelain commands should recurse when showing + diff. + + - "git format-patch --root A" can be used to format everything + since the beginning up to A. This was supported with + "git format-patch --root A A" for a long time, but was not + properly documented. + + - "git svn dcommit" retains local merge information. + + - "git svnimport" allows an empty string to be specified as the + trunk/ directory. This is necessary to suck data from a SVN + repository that doe not have trunk/ branches/ and tags/ organization + at all. + + - "git config" to set values also honors type flags like --bool + and --int. + + - core.quotepath configuration can be used to make textual git + output to emit most of the characters in the path literally. + + - "git mergetool" chooses its backend more wisely, taking + notice of its environment such as use of X, Gnome/KDE, etc. + + - "gitweb" shows merge commits a lot nicer than before. The + default view uses more compact --cc format, while the UI + allows to choose normal diff with any parent. + + - snapshot files "gitweb" creates from a repository at + $path/$project/.git are more useful. We use $project part + in the filename, which we used to discard. + + - "git cvsimport" creates lightweight tags; there is no + interesting information we can record in an annotated tag, + and the handcrafted ones the old code created was not + properly formed anyway. + + - "git push" pretends that you immediately fetched back from + the remote by updating corresponding remote tracking + branches if you have any. + + - The diffstat given after a merge (or a pull) honors the + color.diff configuration. + + - "git commit --amend" is now compatible with various message source + options such as -m/-C/-c/-F. + + - "git apply --whitespace=strip" removes blank lines added at + the end of the file. + + - "git fetch" over git native protocols with "-v" option shows + connection status, and the IP address of the other end, to + help diagnosing problems. + + - We used to have core.legacyheaders configuration, when + set to false, allowed git to write loose objects in a format + that mimics the format used by objects stored in packs. It + turns out that this was not so useful. Although we will + continue to read objects written in that format, we do not + honor that configuration anymore and create loose objects in + the legacy/traditional format. + + - "--find-copies-harder" option to diff family can now be + spelled as "-C -C" for brevity. + + - "git mailsplit" (hence "git am") can read from Maildir + formatted mailboxes. + + - "git cvsserver" does not barf upon seeing "cvs login" + request. + + - "pack-objects" honors "delta" attribute set in + .gitattributes. It does not attempt to deltify blobs that + come from paths with delta attribute set to false. + + - "new-workdir" script (in contrib) can now be used with a + bare repository. + + - "git mergetool" learned to use gvimdiff. + + - "gitview" (in contrib) has a better blame interface. + + - "git log" and friends did not handle a commit log message + that is larger than 16kB; they do now. + + - "--pretty=oneline" output format for "git log" and friends + deals with "malformed" commit log messages that have more + than one lines in the first paragraph better. We used to + show the first line, cutting the title at mid-sentence; we + concatenate them into a single line and treat the result as + "oneline". + + - "git p4import" has been demoted to contrib status. For + a superior option, checkout the "git p4" front end to + "git fast-import" (also in contrib). The man page and p4 + rpm have been removed as well. + + - "git mailinfo" (hence "am") now tries to see if the message + is in utf-8 first, instead of assuming iso-8859-1, if + incoming e-mail does not say what encoding it is in. + +* Builds + + - old-style function definitions (most notably, a function + without parameter defined with "func()", not "func(void)") + have been eradicated. + + - "git tag" and "git verify-tag" have been rewritten in C. + +* Performance Tweaks + + - "git pack-objects" avoids re-deltification cost by caching + small enough delta results it creates while looking for the + best delta candidates. + + - "git pack-objects" learned a new heuristic to prefer delta + that is shallower in depth over the smallest delta + possible. This improves both overall packfile access + performance and packfile density. + + - diff-delta code that is used for packing has been improved + to work better on big files. + + - when there are more than one pack files in the repository, + the runtime used to try finding an object always from the + newest packfile; it now tries the same packfile as we found + the object requested the last time, which exploits the + locality of references. + + - verifying pack contents done by "git fsck --full" got boost + by carefully choosing the order to verify objects in them. + + - "git read-tree -m" to read into an already populated index + has been optimized vastly. The effect of this can be seen + when switching branches that have differences in only a + handful paths. + + - "git add paths..." and "git commit paths..." has also been + heavily optimized. + +Fixes since v1.5.2 +------------------ + +All of the fixes in v1.5.2 maintenance series are included in +this release, unless otherwise noted. + +* Bugfixes + + - "gitweb" had trouble handling non UTF-8 text with older + Encode.pm Perl module. + + - "git svn" misparsed the data from the commits in the repository when + the user had "color.diff = true" in the configuration. This has been + fixed. + + - There was a case where "git svn dcommit" clobbered changes made on the + SVN side while committing multiple changes. + + - "git-write-tree" had a bad interaction with racy-git avoidance and + gitattributes mechanisms. + + - "git --bare command" overrode existing GIT_DIR setting and always + made it treat the current working directory as GIT_DIR. + + - "git ls-files --error-unmatch" does not complain if you give the + same path pattern twice by mistake. + + - "git init" autodetected core.filemode but not core.symlinks, which + made a new directory created automatically by "git clone" cumbersome + to use on filesystems that require these configurations to be set. + + - "git log" family of commands behaved differently when run as "git + log" (no pathspec) and as "git log --" (again, no pathspec). This + inconsistency was introduced somewhere in v1.3.0 series but now has + been corrected. + + - "git rebase -m" incorrectly displayed commits that were skipped. diff --git a/Documentation/RelNotes-1.5.4.1.txt b/Documentation/RelNotes-1.5.4.1.txt new file mode 100644 index 0000000000..d4e44b8b09 --- /dev/null +++ b/Documentation/RelNotes-1.5.4.1.txt @@ -0,0 +1,17 @@ +GIT v1.5.4.1 Release Notes +========================== + +Fixes since v1.5.4 +------------------ + + * "git-commit -C $tag" used to work but rewrite in C done in + 1.5.4 broke it. + + * An entry in the .gitattributes file that names a pattern in a + subdirectory of the directory it is in did not match + correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should + match "a/b/foo.c" but it didn't). + + * Customized color specification was parsed incorrectly when + numeric color values are used. This was fixed in 1.5.4.1. + diff --git a/Documentation/RelNotes-1.5.4.2.txt b/Documentation/RelNotes-1.5.4.2.txt new file mode 100644 index 0000000000..21d0df59fb --- /dev/null +++ b/Documentation/RelNotes-1.5.4.2.txt @@ -0,0 +1,43 @@ +GIT v1.5.4.2 Release Notes +========================== + +Fixes since v1.5.4 +------------------ + + * The configuration parser was not prepared to see string + valued variables misspelled as boolean and segfaulted. + + * Temporary files left behind due to interrupted object + transfers were not cleaned up with "git prune". + + * "git config --unset" was confused when the unset variables + were spelled with continuation lines in the config file. + + * The merge message detection in "git cvsimport" did not catch + a message that began with "Merge...". + + * "git status" suggests "git rm --cached" for unstaging the + earlier "git add" before the initial commit. + + * "git status" output was incorrect during a partial commit. + + * "git bisect" refused to start when the HEAD was detached. + + * "git bisect" allowed a wildcard character in the commit + message expanded while writing its log file. + + * Manual pages were not formatted correctly with docbook xsl + 1.72; added a workaround. + + * "git-commit -C $tag" used to work but rewrite in C done in + 1.5.4 broke it. This was fixed in 1.5.4.1. + + * An entry in the .gitattributes file that names a pattern in a + subdirectory of the directory it is in did not match + correctly (e.g. pattern "b/*.c" in "a/.gitattributes" should + match "a/b/foo.c" but it didn't). This was fixed in 1.5.4.1. + + * Customized color specification was parsed incorrectly when + numeric color values are used. This was fixed in 1.5.4.1. + + * http transport misbehaved when linked with curl-gnutls. diff --git a/Documentation/RelNotes-1.5.4.3.txt b/Documentation/RelNotes-1.5.4.3.txt new file mode 100644 index 0000000000..b0fc67fb2a --- /dev/null +++ b/Documentation/RelNotes-1.5.4.3.txt @@ -0,0 +1,27 @@ +GIT v1.5.4.3 Release Notes +========================== + +Fixes since v1.5.4.2 +-------------------- + + * RPM spec used to pull in everything with 'git'. This has been + changed so that 'git' package contains just the core parts, + and we now supply 'git-all' metapackage to slurp in everything. + This should match end user's expectation better. + + * When some refs failed to update, git-push reported "failure" + which was unclear if some other refs were updated or all of + them failed atomically (the answer is the former). Reworded + the message to clarify this. + + * "git clone" from a repository whose HEAD was misconfigured + did not set up the remote properly. Now it tries to do + better. + + * Updated git-push documentation to clarify what "matching" + means, in order to reduce user confusion. + + * Updated git-add documentation to clarify "add -u" operates in + the current subdirectory you are in, just like other commands. + + * git-gui updates to work on OSX and Windows better. diff --git a/Documentation/RelNotes-1.5.4.4.txt b/Documentation/RelNotes-1.5.4.4.txt new file mode 100644 index 0000000000..323c1a88c7 --- /dev/null +++ b/Documentation/RelNotes-1.5.4.4.txt @@ -0,0 +1,66 @@ +GIT v1.5.4.4 Release Notes +========================== + +Fixes since v1.5.4.3 +-------------------- + + * Building and installing with an overtight umask such as 077 made + installed templates unreadable by others, while the rest of the install + are done in a way that is friendly to umask 022. + + * "git cvsexportcommit -w $cvsdir" misbehaved when GIT_DIR is set to a + relative directory. + + * "git http-push" had an invalid memory access that could lead it to + segfault. + + * When "git rebase -i" gave control back to the user for a commit that is + marked to be edited, it just said "modify it with commit --amend", + without saying what to do to continue after modifying it. Give an + explicit instruction to run "rebase --continue" to be more helpful. + + * "git send-email" in 1.5.4.3 issued a bogus empty In-Reply-To: header. + + * "git bisect" showed mysterious "won't bisect on seeked tree" error message. + This was leftover from Cogito days to prevent "bisect" starting from a + cg-seeked state. We still keep the Cogito safety, but running "git bisect + start" when another bisect was in effect will clean up and start over. + + * "git push" with an explicit PATH to receive-pack did not quite work if + receive-pack was not on usual PATH. We earlier fixed the same issue + with "git fetch" and upload-pack, but somehow forgot to do so in the + other direction. + + * git-gui's info dialog was not displayed correctly when the user tries + to commit nothing (i.e. without staging anything). + + * "git revert" did not properly fail when attempting to run with a + dirty index. + + * "git merge --no-commit --no-ff <other>" incorrectly made commits. + + * "git merge --squash --no-ff <other>", which is a nonsense combination + of options, was not rejected. + + * "git ls-remote" and "git remote show" against an empty repository + failed, instead of just giving an empty result (regression). + + * "git fast-import" did not handle a renamed path whose name needs to be + quoted, due to a bug in unquote_c_style() function. + + * "git cvsexportcommit" was confused when multiple files with the same + basename needed to be pushed out in the same commit. + + * "git daemon" did not send early errors to syslog. + + * "git log --merge" did not work well with --left-right option. + + * "git svn" prompted for client cert password every time it accessed the + server. + + * The reset command in "git fast-import" data stream was documented to + end with an optional LF, but it actually required one. + + * "git svn dcommit/rebase" did not honor --rewrite-root option. + +Also included are a handful documentation updates. diff --git a/Documentation/RelNotes-1.5.4.5.txt b/Documentation/RelNotes-1.5.4.5.txt new file mode 100644 index 0000000000..bbd130e36d --- /dev/null +++ b/Documentation/RelNotes-1.5.4.5.txt @@ -0,0 +1,56 @@ +GIT v1.5.4.5 Release Notes +========================== + +Fixes since v1.5.4.4 +-------------------- + + * "git fetch there" when the URL information came from the Cogito style + branches/there file did not update refs/heads/there (regression in + 1.5.4). + + * Bogus refspec configuration such as "remote.there.fetch = =" were not + detected as errors (regression in 1.5.4). + + * You couldn't specify a custom editor whose path contains a whitespace + via GIT_EDITOR (and core.editor). + + * The subdirectory filter to "git filter-branch" mishandled a history + where the subdirectory becomes empty and then later becomes non-empty. + + * "git shortlog" gave an empty line if the original commit message was + malformed (e.g. a botched import from foreign SCM). Now it finds the + first non-empty line and uses it for better information. + + * When the user fails to give a revision parameter to "git svn", an error + from the Perl interpreter was issued because the script lacked proper + error checking. + + * After "git rebase" stopped due to conflicts, if the user played with + "git reset" and friends, "git rebase --abort" failed to go back to the + correct commit. + + * Additional work trees prepared with git-new-workdir (in contrib/) did + not share git-svn metadata directory .git/svn with the original. + + * "git-merge-recursive" did not mark addition of the same path with + different filemodes correctly as a conflict. + + * "gitweb" gave malformed URL when pathinfo stype paths are in use. + + * "-n" stands for "--no-tags" again for "git fetch". + + * "git format-patch" did not detect the need to add 8-bit MIME header + when the user used format.header configuration. + + * "rev~" revision specifier used to mean "rev", which was inconsistent + with how "rev^" worked. Now "rev~" is the same as "rev~1" (hence it + also is the same as "rev^1"), and "rev~0" is the same as "rev^0" + (i.e. it has to be a commit). + + * "git quiltimport" did not grok empty lines, lines in "file -pNNN" + format to specify the prefix levels and lines with trailing comments. + + * "git rebase -m" triggered pre-commit verification, which made + "rebase --continue" impossible. + +As usual, it also comes with many documentation fixes and clarifications. diff --git a/Documentation/RelNotes-1.5.4.6.txt b/Documentation/RelNotes-1.5.4.6.txt new file mode 100644 index 0000000000..3e3c3e55a3 --- /dev/null +++ b/Documentation/RelNotes-1.5.4.6.txt @@ -0,0 +1,43 @@ +GIT v1.5.4.6 Release Notes +========================== + +I personally do not think there is any reason anybody should want to +run v1.5.4.X series these days, because 'master' version is always +more stable than any tagged released version of git. + +This is primarily to futureproof "git-shell" to accept requests +without a dash between "git" and subcommand name (e.g. "git +upload-pack") which the newer client will start to make sometime in +the future. + +Fixes since v1.5.4.5 +-------------------- + + * Command line option "-n" to "git-repack" was not correctly parsed. + + * Error messages from "git-apply" when the patchfile cannot be opened + have been improved. + + * Error messages from "git-bisect" when given nonsense revisions have + been improved. + + * reflog syntax that uses time e.g. "HEAD@{10 seconds ago}:path" did not + stop parsing at the closing "}". + + * "git rev-parse --symbolic-full-name ^master^2" printed solitary "^", + but it should print nothing. + + * "git apply" did not enforce "match at the beginning" correctly. + + * a path specification "a/b" in .gitattributes file should not match + "sub/a/b", but it did. + + * "git log --date-order --topo-order" did not override the earlier + date-order with topo-order as expected. + + * "git fast-export" did not export octopus merges correctly. + + * "git archive --prefix=$path/" mishandled gitattributes. + +As usual, it also comes with many documentation fixes and clarifications. + diff --git a/Documentation/RelNotes-1.5.4.7.txt b/Documentation/RelNotes-1.5.4.7.txt new file mode 100644 index 0000000000..9065a0e273 --- /dev/null +++ b/Documentation/RelNotes-1.5.4.7.txt @@ -0,0 +1,10 @@ +GIT v1.5.4.7 Release Notes +========================== + +Fixes since 1.5.4.7 +------------------- + + * Removed support for an obsolete gitweb request URI, whose + implementation ran "git diff" Porcelain, instead of using plumbing, + which would have run an external diff command specified in the + repository configuration as the gitweb user. diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt new file mode 100644 index 0000000000..f1323b6174 --- /dev/null +++ b/Documentation/RelNotes-1.5.4.txt @@ -0,0 +1,377 @@ +GIT v1.5.4 Release Notes +======================== + +Removal +------- + + * "git svnimport" was removed in favor of "git svn". It is still there + in the source tree (contrib/examples) but unsupported. + + * As git-commit and git-status have been rewritten, "git runstatus" + helper script lost all its users and has been removed. + + +Temporarily disabled +-------------------- + + * "git http-push" is known not to work well with cURL library older + than 7.16, and we had reports of repository corruption. It is + disabled on such platforms for now. Unfortunately, 1.5.3.8 shares + the same issue. In other words, this does not mean you will be + fine if you stick to an older git release. For now, please do not + use http-push from older git with cURL older than 7.16 if you + value your data. A proper fix will hopefully materialize in + later versions. + + +Deprecation notices +------------------- + + * From v1.6.0, git will by default install dashed form of commands + (e.g. "git-commit") outside of users' normal $PATH, and will install + only selected commands ("git" itself, and "gitk") in $PATH. This + implies: + + - Using dashed forms of git commands (e.g. "git-commit") from the + command line has been informally deprecated since early 2006, but + now it officially is, and will be removed in the future. Use + dash-less forms (e.g. "git commit") instead. + + - Using dashed forms from your scripts, without first prepending the + return value from "git --exec-path" to the scripts' PATH, has been + informally deprecated since early 2006, but now it officially is. + + - Use of dashed forms with "PATH=$(git --exec-path):$PATH; export + PATH" early in your script is not deprecated with this change. + + Users are strongly encouraged to adjust their habits and scripts now + to prepare for this change. + + * The post-receive hook was introduced in March 2007 to supersede + the post-update hook, primarily to overcome the command line length + limitation of the latter. Use of post-update hook will be deprecated + in future versions of git, starting from v1.6.0. + + * "git lost-found" was deprecated in favor of "git fsck"'s --lost-found + option, and will be removed in the future. + + * "git peek-remote" is deprecated, as "git ls-remote" was written in C + and works for all transports; "git peek-remote" will be removed in + the future. + + * "git repo-config" which was an old name for "git config" command + has been supported without being advertised for a long time. The + next feature release will remove it. + + * From v1.6.0, the repack.usedeltabaseoffset config option will default + to true, which will give denser packfiles (i.e. more efficient storage). + The downside is that git older than version 1.4.4 will not be able + to directly use a repository packed using this setting. + + * From v1.6.0, the pack.indexversion config option will default to 2, + which is slightly more efficient, and makes repacking more immune to + data corruptions. Git older than version 1.5.2 may revert to version 1 + of the pack index with a manual "git index-pack" to be able to directly + access corresponding pack files. + + +Updates since v1.5.3 +-------------------- + + * Comes with much improved gitk, with i18n. + + * Comes with git-gui 0.9.2 with i18n. + + * gitk is now merged as a subdirectory of git.git project, in + preparation for its i18n. + + * progress displays from many commands are a lot nicer to the eye. + Transfer commands show throughput data. + + * many commands that pay attention to per-directory .gitignore now do + so lazily, which makes the usual case go much faster. + + * Output processing for '--pretty=format:<user format>' has been + optimized. + + * Rename detection of diff family while detecting exact matches has + been greatly optimized. + + * Rename detection of diff family tries to make more natural looking + pairing. Earlier, if multiple identical rename sources were + found in the preimage, the source used was picked pretty much at random. + + * Value "true" for color.diff and color.status configuration used to + mean "always" (even when the output is not going to a terminal). + This has been corrected to mean the same thing as "auto". + + * "git diff" Porcelain now respects diff.external configuration, which + is another way to specify GIT_EXTERNAL_DIFF. + + * "git diff" can be told to use different prefixes other than + "a/" and "b/" e.g. "git diff --src-prefix=l/ --dst-prefix=k/". + + * "git diff" sometimes did not quote paths with funny + characters properly. + + * "git log" (and any revision traversal commands) misbehaved + when --diff-filter is given but was not asked to actually + produce diff. + + * HTTP proxy can be specified per remote repository using + remote.*.httpproxy configuration, or global http.proxy configuration + variable. + + * Various Perforce importer updates. + + * Example update and post-receive hooks have been improved. + + * Any command that wants to take a commit object name can now use + ":/string" syntax to name a commit. + + * "git reset" is now built-in and its output can be squelched with -q. + + * "git reset --hard" does not make any sense in a bare + repository, but did not error out; fixed. + + * "git send-email" can optionally talk over ssmtp and use SMTP-AUTH. + + * "git rebase" learned --whitespace option. + + * In "git rebase", when you decide not to replay a particular change + after the command stopped with a conflict, you can say "git rebase + --skip" without first running "git reset --hard", as the command now + runs it for you. + + * "git rebase --interactive" mode can now work on detached HEAD. + + * Other minor to serious bugs in "git rebase -i" have been fixed. + + * "git rebase" now detaches head during its operation, so after a + successful "git rebase" operation, the reflog entry branch@{1} for + the current branch points at the commit before the rebase was + started. + + * "git rebase -i" also triggers rerere to help your repeated merges. + + * "git merge" can call the "post-merge" hook. + + * "git pack-objects" can optionally run deltification with multiple + threads. + + * "git archive" can optionally substitute keywords in files marked with + export-subst attribute. + + * "git cherry-pick" made a misguided attempt to repeat the original + command line in the generated log message, when told to cherry-pick a + commit by naming a tag that points at it. It does not anymore. + + * "git for-each-ref" learned %(xxxdate:<date-format>) syntax to show the + various date fields in different formats. + + * "git gc --auto" is a low-impact way to automatically run a variant of + "git repack" that does not lose unreferenced objects (read: safer + than the usual one) after the user accumulates too many loose + objects. + + * "git clean" has been rewritten in C. + + * You need to explicitly set clean.requireForce to "false" to allow + "git clean" without -f to do any damage (lack of the configuration + variable used to mean "do not require -f option to lose untracked + files", but we now use the safer default). + + * The kinds of whitespace errors "git diff" and "git apply" notice (and + fix) can be controlled via 'core.whitespace' configuration variable + and 'whitespace' attribute in .gitattributes file. + + * "git push" learned --dry-run option to show what would happen if a + push is run. + + * "git push" does not update a tracking ref on the local side when the + remote refused to update the corresponding ref. + + * "git push" learned --mirror option. This is to push the local refs + one-to-one to the remote, and deletes refs from the remote that do + not exist anymore in the repository on the pushing side. + + * "git push" can remove a corrupt ref at the remote site with the usual + ":ref" refspec. + + * "git remote" knows --mirror mode. This is to set up configuration to + push into a remote repository to store local branch heads to the same + branch on the remote side, and remove branch heads locally removed + from local repository at the same time. Suitable for pushing into a + back-up repository. + + * "git remote" learned "rm" subcommand. + + * "git cvsserver" can be run via "git shell". Also, "cvs" is + recognized as a synonym for "git cvsserver", so that CVS users + can be switched to git just by changing their login shell. + + * "git cvsserver" acts more like receive-pack by running post-receive + and post-update hooks. + + * "git am" and "git rebase" are far less verbose. + + * "git pull" learned to pass --[no-]ff option to underlying "git + merge". + + * "git pull --rebase" is a different way to integrate what you fetched + into your current branch. + + * "git fast-export" produces data-stream that can be fed to fast-import + to reproduce the history recorded in a git repository. + + * "git add -i" takes pathspecs to limit the set of files to work on. + + * "git add -p" is a short-hand to go directly to the selective patch + subcommand in the interactive command loop and to exit when done. + + * "git add -i" UI has been colorized. The interactive prompt + and menu can be colored by setting color.interactive + configuration. The diff output (including the hunk picker) + are colored with color.diff configuration. + + * "git commit --allow-empty" allows you to create a single-parent + commit that records the same tree as its parent, overriding the usual + safety valve. + + * "git commit --amend" can amend a merge that does not change the tree + from its first parent. + + * "git commit" used to unconditionally strip comment lines that + began with '#' and removed excess blank lines. This behavior has + been made configurable. + + * "git commit" has been rewritten in C. + + * "git stash random-text" does not create a new stash anymore. It was + a UI mistake. Use "git stash save random-text", or "git stash" + (without extra args) for that. + + * "git stash clear extra-text" does not clear the whole stash + anymore. It is tempting to expect "git stash clear stash@{2}" + to drop only a single named stash entry, and it is rude to + discard everything when that is asked (but not provided). + + * "git prune --expire <time>" can exempt young loose objects from + getting pruned. + + * "git branch --contains <commit>" can list branches that are + descendants of a given commit. + + * "git log" learned --early-output option to help interactive GUI + implementations. + + * "git bisect" learned "skip" action to mark untestable commits. + + * "git bisect visualize" learned a shorter synonym "git bisect view". + + * "git bisect visualize" runs "git log" in a non-windowed + environments. It also can be told what command to run (e.g. "git + bisect visualize tig"). + + * "git format-patch" learned "format.numbered" configuration variable + to automatically turn --numbered option on when more than one commits + are formatted. + + * "git ls-files" learned "--exclude-standard" to use the canned set of + exclude files. + + * "git tag -a -f existing" begins the editor session using the existing + annotation message. + + * "git tag -m one -m bar" (multiple -m options) behaves similarly to + "git commit"; the parameters to -m options are formatted as separate + paragraphs. + + * The format "git show" outputs an annotated tag has been updated to + include "Tagger: " and "Date: " lines from the tag itself. Strictly + speaking this is a backward incompatible change, but this is a + reasonable usability fix and people's scripts shouldn't have been + relying on the exact output from "git show" Porcelain anyway. + + * "git cvsimport" did not notice errors from underlying "cvsps" + and produced a corrupt import silently. + + * "git cvsexportcommit" learned -w option to specify and switch to the + CVS working directory. + + * "git checkout" from a subdirectory learned to use "../path" to allow + checking out a path outside the current directory without cd'ing up. + + * "git checkout" from and to detached HEAD leaves a bit more + information in the reflog. + + * "git send-email --dry-run" shows full headers for easier diagnosis. + + * "git merge-ours" is now built-in. + + * "git svn" learned "info" and "show-externals" subcommands. + + * "git svn" run from a subdirectory failed to read settings from the + .git/config. + + * "git svn" learned --use-log-author option, which picks up more + descriptive name from From: and Signed-off-by: lines in the commit + message. + + * "git svn" wasted way too much disk to record revision mappings + between svn and git; a new representation that is much more compact + for this information has been introduced to correct this. + + * "git svn" left temporary index files it used without cleaning them + up; this was corrected. + + * "git status" from a subdirectory now shows relative paths, which + makes copy-and-pasting for git-checkout/git-add/git-rm easier. The + traditional behavior to show the full path relative to the top of + the work tree can be had by setting status.relativepaths + configuration variable to false. + + * "git blame" kept text for each annotated revision in core needlessly; + this has been corrected. + + * "git shortlog" learned to default to HEAD when the standard input is + a terminal and the user did not give any revision parameter. + + * "git shortlog" learned "-e" option to show e-mail addresses as well as + authors' names. + + * "git help" learned "-w" option to show documentation in browsers. + + * In addition there are quite a few internal clean-ups. Notably: + + - many fork/exec have been replaced with run-command API, + brought from the msysgit effort. + + - introduction and more use of the option parser API. + + - enhancement and more use of the strbuf API. + + * Makefile tweaks to support HP-UX is in. + +Fixes since v1.5.3 +------------------ + +All of the fixes in v1.5.3 maintenance series are included in +this release, unless otherwise noted. + +These fixes are only in v1.5.4 and not backported to v1.5.3 maintenance +series. + + * The way "git diff --check" behaves is much more consistent with the way + "git apply --whitespace=warn" works. + + * "git svn" talking with the SVN over HTTP will correctly quote branch + and project names. + + * "git config" did not work correctly on platforms that define + REG_NOMATCH to an even number. + + * Recent versions of AsciiDoc 8 has a change to break our + documentation; a workaround has been implemented. + + * "git diff --color-words" colored context lines in a wrong color. diff --git a/Documentation/RelNotes-1.5.5.1.txt b/Documentation/RelNotes-1.5.5.1.txt new file mode 100644 index 0000000000..7de419708f --- /dev/null +++ b/Documentation/RelNotes-1.5.5.1.txt @@ -0,0 +1,44 @@ +GIT v1.5.5.1 Release Notes +========================== + +Fixes since v1.5.5 +------------------ + + * "git archive --prefix=$path/" mishandled gitattributes. + + * "git fetch -v" that fetches into FETCH_HEAD did not report the summary + the same way as done for updating the tracking refs. + + * "git svn" misbehaved when the configuration file customized the "git + log" output format using format.pretty. + + * "git submodule status" leaked an unnecessary error message. + + * "git log --date-order --topo-order" did not override the earlier + date-order with topo-order as expected. + + * "git bisect good $this" did not check the validity of the revision + given properly. + + * "url.<there>.insteadOf" did not work correctly. + + * "git clean" ran inside subdirectory behaved as if the directory was + explicitly specified for removal by the end user from the top level. + + * "git bisect" from a detached head leaked an unnecessary error message. + + * "git bisect good $a $b" when $a is Ok but $b is bogus should have + atomically failed before marking $a as good. + + * "git fmt-merge-msg" did not clean up leading empty lines from commit + log messages like "git log" family does. + + * "git am" recorded a commit with empty Subject: line without + complaining. + + * when given a commit log message whose first paragraph consists of + multiple lines, "git rebase" squashed it into a single line. + + * "git remote add $bogus_name $url" did not complain properly. + +Also comes with various documentation updates. diff --git a/Documentation/RelNotes-1.5.5.2.txt b/Documentation/RelNotes-1.5.5.2.txt new file mode 100644 index 0000000000..391a7b02ea --- /dev/null +++ b/Documentation/RelNotes-1.5.5.2.txt @@ -0,0 +1,27 @@ +GIT v1.5.5.2 Release Notes +========================== + +Fixes since v1.5.5.1 +-------------------- + + * "git repack -n" was mistakenly made no-op earlier. + + * "git imap-send" wanted to always have imap.host even when use of + imap.tunnel made it unnecessary. + + * reflog syntax that uses time e.g. "HEAD@{10 seconds ago}:path" did not + stop parsing at the closing "}". + + * "git rev-parse --symbolic-full-name ^master^2" printed solitary "^", + but it should print nothing. + + * "git commit" did not detect when it failed to write tree objects. + + * "git fetch" sometimes transferred too many objects unnecessarily. + + * a path specification "a/b" in .gitattributes file should not match + "sub/a/b". + + * various gitweb fixes. + +Also comes with various documentation updates. diff --git a/Documentation/RelNotes-1.5.5.3.txt b/Documentation/RelNotes-1.5.5.3.txt new file mode 100644 index 0000000000..f22f98b734 --- /dev/null +++ b/Documentation/RelNotes-1.5.5.3.txt @@ -0,0 +1,12 @@ +GIT v1.5.5.3 Release Notes +========================== + +Fixes since v1.5.5.2 +-------------------- + + * "git send-email --compose" did not notice that non-ascii contents + needed some MIME magic. + + * "git fast-export" did not export octopus merges correctly. + +Also comes with various documentation updates. diff --git a/Documentation/RelNotes-1.5.5.4.txt b/Documentation/RelNotes-1.5.5.4.txt new file mode 100644 index 0000000000..2d0279ecce --- /dev/null +++ b/Documentation/RelNotes-1.5.5.4.txt @@ -0,0 +1,7 @@ +GIT v1.5.5.4 Release Notes +========================== + +Fixes since v1.5.5.4 +-------------------- + + * "git name-rev --all" used to segfault. diff --git a/Documentation/RelNotes-1.5.5.5.txt b/Documentation/RelNotes-1.5.5.5.txt new file mode 100644 index 0000000000..30fa3615c7 --- /dev/null +++ b/Documentation/RelNotes-1.5.5.5.txt @@ -0,0 +1,11 @@ +GIT v1.5.5.5 Release Notes +========================== + +I personally do not think there is any reason anybody should want to +run v1.5.5.X series these days, because 'master' version is always +more stable than any tagged released version of git. + +This is primarily to futureproof "git-shell" to accept requests +without a dash between "git" and subcommand name (e.g. "git +upload-pack") which the newer client will start to make sometime in +the future. diff --git a/Documentation/RelNotes-1.5.5.6.txt b/Documentation/RelNotes-1.5.5.6.txt new file mode 100644 index 0000000000..d5e85cb70e --- /dev/null +++ b/Documentation/RelNotes-1.5.5.6.txt @@ -0,0 +1,10 @@ +GIT v1.5.5.6 Release Notes +========================== + +Fixes since 1.5.5.5 +------------------- + + * Removed support for an obsolete gitweb request URI, whose + implementation ran "git diff" Porcelain, instead of using plumbing, + which would have run an external diff command specified in the + repository configuration as the gitweb user. diff --git a/Documentation/RelNotes-1.5.5.txt b/Documentation/RelNotes-1.5.5.txt new file mode 100644 index 0000000000..2932212488 --- /dev/null +++ b/Documentation/RelNotes-1.5.5.txt @@ -0,0 +1,207 @@ +GIT v1.5.5 Release Notes +======================== + +Updates since v1.5.4 +-------------------- + +(subsystems) + + * Comes with git-gui 0.10.1 + +(portability) + + * We shouldn't ask for BSD group ownership semantics by setting g+s bit + on directories on older BSD systems that refuses chmod() by non root + users. BSD semantics is the default there anyway. + + * Bunch of portability improvement patches coming from an effort to port + to Solaris has been applied. + +(performance) + + * On platforms with suboptimal qsort(3) implementation, there + is an option to use more reasonable substitute we ship with + our software. + + * New configuration variable "pack.packsizelimit" can be used + in place of command line option --max-pack-size. + + * "git fetch" over the native git protocol used to make a + connection to find out the set of current remote refs and + another to actually download the pack data. We now use only + one connection for these tasks. + + * "git commit" does not run lstat(2) more than necessary + anymore. + +(usability, bells and whistles) + + * Bash completion script (in contrib) are aware of more commands and + options. + + * You can be warned when core.autocrlf conversion is applied in + such a way that results in an irreversible conversion. + + * A catch-all "color.ui" configuration variable can be used to + enable coloring of all color-capable commands, instead of + individual ones such as "color.status" and "color.branch". + + * The commands refused to take absolute pathnames where they + require pathnames relative to the work tree or the current + subdirectory. They now can take absolute pathnames in such a + case as long as the pathnames do not refer outside of the + work tree. E.g. "git add $(pwd)/foo" now works. + + * Error messages used to be sent to stderr, only to get hidden, + when $PAGER was in use. They now are sent to stdout along + with the command output to be shown in the $PAGER. + + * A pattern "foo/" in .gitignore file now matches a directory + "foo". Pattern "foo" also matches as before. + + * bash completion's prompt helper function can talk about + operation in-progress (e.g. merge, rebase, etc.). + + * Configuration variables "url.<usethis>.insteadof = <otherurl>" can be + used to tell "git-fetch" and "git-push" to use different URL than what + is given from the command line. + + * "git add -i" behaves better even before you make an initial commit. + + * "git am" refused to run from a subdirectory without a good reason. + + * After "git apply --whitespace=fix" fixes whitespace errors in a patch, + a line before the fix can appear as a context or preimage line in a + later patch, causing the patch not to apply. The command now knows to + see through whitespace fixes done to context lines to successfully + apply such a patch series. + + * "git branch" (and "git checkout -b") to branch from a local branch can + optionally set "branch.<name>.merge" to mark the new branch to build on + the other local branch, when "branch.autosetupmerge" is set to + "always", or when passing the command line option "--track" (this option + was ignored when branching from local branches). By default, this does + not happen when branching from a local branch. + + * "git checkout" to switch to a branch that has "branch.<name>.merge" set + (i.e. marked to build on another branch) reports how much the branch + and the other branch diverged. + + * When "git checkout" has to update a lot of paths, it used to be silent + for 4 seconds before it showed any progress report. It is now a bit + more impatient and starts showing progress report early. + + * "git commit" learned a new hook "prepare-commit-msg" that can + inspect what is going to be committed and prepare the commit + log message template to be edited. + + * "git cvsimport" can now take more than one -M options. + + * "git describe" learned to limit the tags to be used for + naming with --match option. + + * "git describe --contains" now barfs when the named commit + cannot be described. + + * "git describe --exact-match" describes only commits that are tagged. + + * "git describe --long" describes a tagged commit as $tag-0-$sha1, + instead of just showing the exact tagname. + + * "git describe" warns when using a tag whose name and path contradict + with each other. + + * "git diff" learned "--relative" option to limit and output paths + relative to the current directory when working in a subdirectory. + + * "git diff" learned "--dirstat" option to show birds-eye-summary of + changes more concisely than "--diffstat". + + * "git format-patch" learned --cover-letter option to generate a cover + letter template. + + * "git gc" learned --quiet option. + + * "git gc" now automatically prunes unreachable objects that are two + weeks old or older. + + * "git gc --auto" can be disabled more easily by just setting gc.auto + to zero. It also tolerates more packfiles by default. + + * "git grep" now knows "--name-only" is a synonym for the "-l" option. + + * "git help <alias>" now reports "'git <alias>' is alias to <what>", + instead of saying "No manual entry for git-<alias>". + + * "git help" can use different backends to show manual pages and this can + be configured using "man.viewer" configuration. + + * "gitk" does not restore window position from $HOME/.gitk anymore (it + still restores the size). + + * "git log --grep=<what>" learned "--fixed-strings" option to look for + <what> without treating it as a regular expression. + + * "git gui" learned an auto-spell checking. + + * "git push <somewhere> HEAD" and "git push <somewhere> +HEAD" works as + expected; they push the current branch (and only the current branch). + In addition, HEAD can be written as the value of "remote.<there>.push" + configuration variable. + + * When the configuration variable "pack.threads" is set to 0, "git + repack" auto detects the number of CPUs and uses that many threads. + + * "git send-email" learned to prompt for passwords + interactively. + + * "git send-email" learned an easier way to suppress CC + recipients. + + * "git stash" learned "pop" command, that applies the latest stash and + removes it from the stash, and "drop" command to discard the named + stash entry. + + * "git submodule" learned a new subcommand "summary" to show the + symmetric difference between the HEAD version and the work tree version + of the submodule commits. + + * Various "git cvsimport", "git cvsexportcommit", "git cvsserver", + "git svn" and "git p4" improvements. + +(internal) + + * Duplicated code between git-help and git-instaweb that + launches user's preferred browser has been refactored. + + * It is now easier to write test scripts that records known + breakages. + + * "git checkout" is rewritten in C. + + * "git remote" is rewritten in C. + + * Two conflict hunks that are separated by a very short span of common + lines are now coalesced into one larger hunk, to make the result easier + to read. + + * Run-command API's use of file descriptors is documented clearer and + is more consistent now. + + * diff output can be sent to FILE * that is different from stdout. This + will help reimplementing more things in C. + +Fixes since v1.5.4 +------------------ + +All of the fixes in v1.5.4 maintenance series are included in +this release, unless otherwise noted. + + * "git-http-push" did not allow deletion of remote ref with the usual + "push <remote> :<branch>" syntax. + + * "git-rebase --abort" did not go back to the right location if + "git-reset" was run during the "git-rebase" session. + + * "git imap-send" without setting imap.host did not error out but + segfaulted. diff --git a/Documentation/RelNotes-1.5.6.1.txt b/Documentation/RelNotes-1.5.6.1.txt new file mode 100644 index 0000000000..4864b16445 --- /dev/null +++ b/Documentation/RelNotes-1.5.6.1.txt @@ -0,0 +1,28 @@ +GIT v1.5.6.1 Release Notes +========================== + +Fixes since v1.5.6 +------------------ + +* Last minute change broke loose object creation on AIX. + +* (performance fix) We used to make $GIT_DIR absolute path early in the + programs but keeping it relative to the current directory internally + gives 1-3 per-cent performance boost. + +* bash completion knows the new --graph option to git-log family. + + +* git-diff -c/--cc showed unnecessary "deletion" lines at the context + boundary. + +* git-for-each-ref ignored %(object) and %(type) requests for tag + objects. + +* git-merge usage had a typo. + +* Rebuilding of git-svn metainfo database did not take rewriteRoot + option into account. + +* Running "git-rebase --continue/--skip/--abort" before starting a + rebase gave nonsense error messages. diff --git a/Documentation/RelNotes-1.5.6.2.txt b/Documentation/RelNotes-1.5.6.2.txt new file mode 100644 index 0000000000..5902a85a78 --- /dev/null +++ b/Documentation/RelNotes-1.5.6.2.txt @@ -0,0 +1,40 @@ +GIT v1.5.6.2 Release Notes +========================== + +Futureproof +----------- + + * "git-shell" accepts requests without a dash between "git" and + subcommand name (e.g. "git upload-pack") which the newer client will + start to make sometime in the future. + +Fixes since v1.5.6.1 +-------------------- + +* "git clone" from a remote that is named with url.insteadOf setting in + $HOME/.gitconfig did not work well. + +* "git describe --long --tags" segfaulted when the described revision was + tagged with a lightweight tag. + +* "git diff --check" did not report the result via its exit status + reliably. + +* When remote side used to have branch 'foo' and git-fetch finds that now + it has branch 'foo/bar', it refuses to lose the existing remote tracking + branch and its reflog. The error message has been improved to suggest + pruning the remote if the user wants to proceed and get the latest set + of branches from the remote, including such 'foo/bar'. + +* "git reset file" should mean the same thing as "git reset HEAD file", + but we required disambiguating -- even when "file" is not ambiguous. + +* "git show" segfaulted when an annotated tag that points at another + annotated tag was given to it. + +* Optimization for a large import via "git-svn" introduced in v1.5.6 had a + serious memory and temporary file leak, which made it unusable for + moderately large import. + +* "git-svn" mangled remote nickname used in the configuration file + unnecessarily. diff --git a/Documentation/RelNotes-1.5.6.3.txt b/Documentation/RelNotes-1.5.6.3.txt new file mode 100644 index 0000000000..942611299d --- /dev/null +++ b/Documentation/RelNotes-1.5.6.3.txt @@ -0,0 +1,52 @@ +GIT v1.5.6.3 Release Notes +========================== + +Fixes since v1.5.6.2 +-------------------- + +* Setting core.sharerepository to traditional "true" value was supposed to make + the repository group writable but should not affect permission for others. + However, since 1.5.6, it was broken to drop permission for others when umask is + 022, making the repository unreadable by others. + +* Setting GIT_TRACE will report spawning of external process via run_command(). + +* Using an object with very deep delta chain pinned memory needed for extracting + intermediate base objects unnecessarily long, leading to excess memory usage. + +* Bash completion script did not notice '--' marker on the command + line and tried the relatively slow "ref completion" even when + completing arguments after one. + +* Registering a non-empty blob racily and then truncating the working + tree file for it confused "racy-git avoidance" logic into thinking + that the path is now unchanged. + +* The section that describes attributes related to git-archive were placed + in a wrong place in the gitattributes(5) manual page. + +* "git am" was not helpful to the users when it detected that the committer + information is not set up properly yet. + +* "git clone" had a leftover debugging fprintf(). + +* "git clone -q" was not quiet enough as it used to and gave object count + and progress reports. + +* "git clone" marked downloaded packfile with .keep; this could be a + good thing if the remote side is well packed but otherwise not, + especially for a project that is not really big. + +* "git daemon" used to call syslog() from a signal handler, which + could raise signals of its own but generally is not reentrant. This + was fixed by restructuring the code to report syslog() after the handler + returns. + +* When "git push" tries to remove a remote ref, and corresponding + tracking ref is missing, we used to report error (i.e. failure to + remove something that does not exist). + +* "git mailinfo" (hence "git am") did not handle commit log messages in a + MIME multipart mail correctly. + +Contains other various documentation fixes. diff --git a/Documentation/RelNotes-1.5.6.4.txt b/Documentation/RelNotes-1.5.6.4.txt new file mode 100644 index 0000000000..d8968f1ecb --- /dev/null +++ b/Documentation/RelNotes-1.5.6.4.txt @@ -0,0 +1,47 @@ +GIT v1.5.6.4 Release Notes +========================== + +Fixes since v1.5.6.3 +-------------------- + +* Various commands could overflow its internal buffer on a platform + with small PATH_MAX value in a repository that has contents with + long pathnames. + +* There wasn't a way to make --pretty=format:%<> specifiers to honor + .mailmap name rewriting for authors and committers. Now you can with + %aN and %cN. + +* Bash completion wasted too many cycles; this has been optimized to be + usable again. + +* Bash completion lost ref part when completing something like "git show + pu:Makefile". + +* "git-cvsserver" did not clean up its temporary working area after annotate + request. + +* "git-daemon" called syslog() from its signal handler, which was a + no-no. + +* "git-fetch" into an empty repository used to remind that the fetch will + be huge by saying "no common commits", but this was an unnecessary + noise; it is already known by the user anyway. + +* "git-http-fetch" would have segfaulted when pack idx file retrieved + from the other side was corrupt. + +* "git-index-pack" used too much memory when dealing with a deep delta chain. + +* "git-mailinfo" (hence "git-am") did not correctly handle in-body [PATCH] + line to override the commit title taken from the mail Subject header. + +* "git-rebase -i -p" lost parents that are not involved in the history + being rewritten. + +* "git-rm" lost track of where the index file was when GIT_DIR was + specified as a relative path. + +* "git-rev-list --quiet" was not quiet as advertised. + +Contains other various documentation fixes. diff --git a/Documentation/RelNotes-1.5.6.5.txt b/Documentation/RelNotes-1.5.6.5.txt new file mode 100644 index 0000000000..47ca172462 --- /dev/null +++ b/Documentation/RelNotes-1.5.6.5.txt @@ -0,0 +1,29 @@ +GIT v1.5.6.5 Release Notes +========================== + +Fixes since v1.5.6.4 +-------------------- + +* "git cvsimport" used to spit out "UNKNOWN LINE..." diagnostics to stdout. + +* "git commit -F filename" and "git tag -F filename" run from subdirectories + did not read the right file. + +* "git init --template=" with blank "template" parameter linked files + under root directories to .git, which was a total nonsense. Instead, it + means "I do not want to use anything from the template directory". + +* "git diff-tree" and other diff plumbing ignored diff.renamelimit configuration + variable when the user explicitly asked for rename detection. + +* "git name-rev --name-only" did not work when "--stdin" option was in effect. + +* "git show-branch" mishandled its 8th branch. + +* Addition of "git update-index --ignore-submodules" that happened during + 1.5.6 cycle broke "git update-index --ignore-missing". + +* "git send-email" did not parse charset from an existing Content-type: + header properly. + +Contains other various documentation fixes. diff --git a/Documentation/RelNotes-1.5.6.6.txt b/Documentation/RelNotes-1.5.6.6.txt new file mode 100644 index 0000000000..79da23db5a --- /dev/null +++ b/Documentation/RelNotes-1.5.6.6.txt @@ -0,0 +1,10 @@ +GIT v1.5.6.6 Release Notes +========================== + +Fixes since 1.5.6.5 +------------------- + + * Removed support for an obsolete gitweb request URI, whose + implementation ran "git diff" Porcelain, instead of using plumbing, + which would have run an external diff command specified in the + repository configuration as the gitweb user. diff --git a/Documentation/RelNotes-1.5.6.txt b/Documentation/RelNotes-1.5.6.txt new file mode 100644 index 0000000000..e143d8d61b --- /dev/null +++ b/Documentation/RelNotes-1.5.6.txt @@ -0,0 +1,115 @@ +GIT v1.5.6 Release Notes +======================== + +Updates since v1.5.5 +-------------------- + +(subsystems) + +* Comes with updated gitk and git-gui. + +(portability) + +* git will build on AIX better than before now. + +* core.ignorecase configuration variable can be used to work better on + filesystems that are not case sensitive. + +* "git init" now autodetects the case sensitivity of the filesystem and + sets core.ignorecase accordingly. + +* cpio is no longer used; neither "curl" binary (libcurl is still used). + +(documentation) + +* Many freestanding documentation pages have been converted and made + available to "git help" (aka "man git<something>") as section 7 of + the manual pages. This means bookmarks to some HTML documentation + files may need to be updated (eg "tutorial.html" became + "gittutorial.html"). + +(performance) + +* "git clone" was rewritten in C. This will hopefully help cloning a + repository with insane number of refs. + +* "git rebase --onto $there $from $branch" used to switch to the tip of + $branch only to immediately reset back to $from, smudging work tree + files unnecessarily. This has been optimized. + +* Object creation codepath in "git-svn" has been optimized by enhancing + plumbing commands git-cat-file and git-hash-object. + +(usability, bells and whistles) + +* "git add -p" (and the "patch" subcommand of "git add -i") can choose to + apply (or not apply) mode changes independently from contents changes. + +* "git bisect help" gives longer and more helpful usage information. + +* "git bisect" does not use a special branch "bisect" anymore; instead, it + does its work on a detached HEAD. + +* "git branch" (and "git checkout -b") can be told to set up + branch.<name>.rebase automatically, so that later you can say "git pull" + and magically cause "git pull --rebase" to happen. + +* "git branch --merged" and "git branch --no-merged" can be used to list + branches that have already been merged (or not yet merged) to the + current branch. + +* "git cherry-pick" and "git revert" can add a sign-off. + +* "git commit" mentions the author identity when you are committing + somebody else's changes. + +* "git diff/log --dirstat" output is consistent between binary and textual + changes. + +* "git filter-branch" rewrites signed tags by demoting them to annotated. + +* "git format-patch --no-binary" can produce a patch that lack binary + changes (i.e. cannot be used to propagate the whole changes) meant only + for reviewing. + +* "git init --bare" is a synonym for "git --bare init" now. + +* "git gc --auto" honors a new pre-auto-gc hook to temporarily disable it. + +* "git log --pretty=tformat:<custom format>" gives a LF after each entry, + instead of giving a LF between each pair of entries which is how + "git log --pretty=format:<custom format>" works. + +* "git log" and friends learned the "--graph" option to show the ancestry + graph at the left margin of the output. + +* "git log" and friends can be told to use date format that is different + from the default via 'log.date' configuration variable. + +* "git send-email" now can send out messages outside a git repository. + +* "git send-email --compose" was made aware of rfc2047 quoting. + +* "git status" can optionally include output from "git submodule + summary". + +* "git svn" learned --add-author-from option to propagate the authorship + by munging the commit log message. + +* new object creation and looking up in "git svn" has been optimized. + +* "gitweb" can read from a system-wide configuration file. + +(internal) + +* "git unpack-objects" and "git receive-pack" is now more strict about + detecting breakage in the objects they receive over the wire. + + +Fixes since v1.5.5 +------------------ + +All of the fixes in v1.5.5 maintenance series are included in +this release, unless otherwise noted. + +And there are too numerous small fixes to otherwise note here ;-) diff --git a/Documentation/RelNotes-1.6.0.1.txt b/Documentation/RelNotes-1.6.0.1.txt new file mode 100644 index 0000000000..49d7a1cafa --- /dev/null +++ b/Documentation/RelNotes-1.6.0.1.txt @@ -0,0 +1,36 @@ +GIT v1.6.0.1 Release Notes +========================== + +Fixes since v1.6.0 +------------------ + +* "git diff --cc" did not honor content mangling specified by + gitattributes and core.autocrlf when reading from the work tree. + +* "git diff --check" incorrectly detected new trailing blank lines when + whitespace check was in effect. + +* "git for-each-ref" tried to dereference NULL when asked for '%(body)" on + a tag with a single incomplete line as its payload. + +* "git format-patch" peeked before the beginning of a string when + "format.headers" variable is empty (a misconfiguration). + +* "git help help" did not work correctly. + +* "git mailinfo" (hence "git am") was unhappy when MIME multipart message + contained garbage after the finishing boundary. + +* "git mailinfo" also was unhappy when the "From: " line only had a bare + e-mail address. + +* "git merge" did not refresh the index correctly when a merge resulted in + a fast-forward. + +* "git merge" did not resolve a truly trivial merges that can be done + without content level merges. + +* "git svn dcommit" to a repository with URL that has embedded usernames + did not work correctly. + +Contains other various documentation fixes. diff --git a/Documentation/RelNotes-1.6.0.2.txt b/Documentation/RelNotes-1.6.0.2.txt new file mode 100644 index 0000000000..51b32f5d94 --- /dev/null +++ b/Documentation/RelNotes-1.6.0.2.txt @@ -0,0 +1,87 @@ +GIT v1.6.0.2 Release Notes +========================== + +Fixes since v1.6.0.1 +-------------------- + +* Installation on platforms that needs .exe suffix to git-* programs were + broken in 1.6.0.1. + +* Installation on filesystems without symbolic links support did not + work well. + +* In-tree documentations and test scripts now use "git foo" form to set a + better example, instead of the "git-foo" form (which is an acceptable + form if you have "PATH=$(git --exec-path):$PATH" in your script) + +* Many commands did not use the correct working tree location when used + with GIT_WORK_TREE environment settings. + +* Some systems needs to use compatibility fnmach and regex libraries + independent from each other; the compat/ area has been reorganized to + allow this. + + +* "git apply --unidiff-zero" incorrectly applied a -U0 patch that inserts + a new line before the second line. + +* "git blame -c" did not exactly work like "git annotate" when range + boundaries are involved. + +* "git checkout file" when file is still unmerged checked out contents from + a random high order stage, which was confusing. + +* "git clone $there $here/" with extra trailing slashes after explicit + local directory name $here did not work as expected. + +* "git diff" on tracked contents with CRLF line endings did not drive "less" + intelligently when showing added or removed lines. + +* "git diff --dirstat -M" did not add changes in subdirectories up + correctly for renamed paths. + +* "git diff --cumulative" did not imply "--dirstat". + +* "git for-each-ref refs/heads/" did not work as expected. + +* "git gui" allowed users to feed patch without any context to be applied. + +* "git gui" botched parsing "diff" output when a line that begins with two + dashes and a space gets removed or a line that begins with two pluses + and a space gets added. + +* "git gui" translation updates and i18n fixes. + +* "git index-pack" is more careful against disk corruption while completing + a thin pack. + +* "git log -i --grep=pattern" did not ignore case; neither "git log -E + --grep=pattern" triggered extended regexp. + +* "git log --pretty="%ad" --date=short" did not use short format when + showing the timestamp. + +* "git log --author=author" match incorrectly matched with the + timestamp part of "author " line in commit objects. + +* "git log -F --author=author" did not work at all. + +* Build procedure for "git shell" that used stub versions of some + functions and globals was not understood by linkers on some platforms. + +* "git stash" was fooled by a stat-dirty but otherwise unmodified paths + and refused to work until the user refreshed the index. + +* "git svn" was broken on Perl before 5.8 with recent fixes to reduce + use of temporary files. + +* "git verify-pack -v" did not work correctly when given more than one + packfile. + +Also contains many documentation updates. + +-- +exec >/var/tmp/1 +O=v1.6.0.1-78-g3632cfc +echo O=$(git describe maint) +git shortlog --no-merges $O..maint diff --git a/Documentation/RelNotes-1.6.0.3.txt b/Documentation/RelNotes-1.6.0.3.txt new file mode 100644 index 0000000000..ae0577836a --- /dev/null +++ b/Documentation/RelNotes-1.6.0.3.txt @@ -0,0 +1,117 @@ +GIT v1.6.0.3 Release Notes +========================== + +Fixes since v1.6.0.2 +-------------------- + +* "git archive --format=zip" did not honor core.autocrlf while + --format=tar did. + +* Continuing "git rebase -i" was very confused when the user left modified + files in the working tree while resolving conflicts. + +* Continuing "git rebase -i" was also very confused when the user left + some staged changes in the index after "edit". + +* "git rebase -i" now honors the pre-rebase hook, just like the + other rebase implementations "git rebase" and "git rebase -m". + +* "git rebase -i" incorrectly aborted when there is no commit to replay. + +* Behaviour of "git diff --quiet" was inconsistent with "diff --exit-code" + with the output redirected to /dev/null. + +* "git diff --no-index" on binary files no longer outputs a bogus + "diff --git" header line. + +* "git diff" hunk header patterns with multiple elements separated by LF + were not used correctly. + +* Hunk headers in "git diff" default to using extended regular + expressions, fixing some of the internal patterns on non-GNU + platforms. + +* New config "diff.*.xfuncname" exposes extended regular expressions + for user specified hunk header patterns. + +* "git gc" when ejecting otherwise unreachable objects from packfiles into + loose form leaked memory. + +* "git index-pack" was recently broken and mishandled objects added by + thin-pack completion processing under memory pressure. + +* "git index-pack" was recently broken and misbehaved when run from inside + .git/objects/pack/ directory. + +* "git stash apply sash@{1}" was fixed to error out. Prior versions + would have applied stash@{0} incorrectly. + +* "git stash apply" now offers a better suggestion on how to continue + if the working tree is currently dirty. + +* "git for-each-ref --format=%(subject)" fixed for commits with no + no newline in the message body. + +* "git remote" fixed to protect printf from user input. + +* "git remote show -v" now displays all URLs of a remote. + +* "git checkout -b branch" was confused when branch already existed. + +* "git checkout -q" once again suppresses the locally modified file list. + +* "git clone -q", "git fetch -q" asks remote side to not send + progress messages, actually making their output quiet. + +* Cross-directory renames are no longer used when creating packs. This + allows more graceful behavior on filesystems like sshfs. + +* Stale temporary files under $GIT_DIR/objects/pack are now cleaned up + automatically by "git prune". + +* "git merge" once again removes directories after the last file has + been removed from it during the merge. + +* "git merge" did not allocate enough memory for the structure itself when + enumerating the parents of the resulting commit. + +* "git blame -C -C" no longer segfaults while trying to pass blame if + it encounters a submodule reference. + +* "git rm" incorrectly claimed that you have local modifications when a + path was merely stat-dirty. + +* "git svn" fixed to display an error message when 'set-tree' failed, + instead of a Perl compile error. + +* "git submodule" fixed to handle checking out a different commit + than HEAD after initializing the submodule. + +* The "git commit" error message when there are still unmerged + files present was clarified to match "git write-tree". + +* "git init" was confused when core.bare or core.sharedRepository are set + in system or user global configuration file by mistake. When --bare or + --shared is given from the command line, these now override such + settings made outside the repositories. + +* Some segfaults due to uncaught NULL pointers were fixed in multiple + tools such as apply, reset, update-index. + +* Solaris builds now default to OLD_ICONV=1 to avoid compile warnings; + Solaris 8 does not define NEEDS_LIBICONV by default. + +* "Git.pm" tests relied on unnecessarily more recent version of Perl. + +* "gitweb" triggered undef warning on commits without log messages. + +* "gitweb" triggered undef warnings on missing trees. + +* "gitweb" now removes PATH_INFO from its URLs so users don't have + to manually set the URL in the gitweb configuration. + +* Bash completion removed support for legacy "git-fetch", "git-push" + and "git-pull" as these are no longer installed. Dashless form + ("git fetch") is still however supported. + +Many other documentation updates. diff --git a/Documentation/RelNotes-1.6.0.4.txt b/Documentation/RelNotes-1.6.0.4.txt new file mode 100644 index 0000000000..d522661d31 --- /dev/null +++ b/Documentation/RelNotes-1.6.0.4.txt @@ -0,0 +1,39 @@ +GIT v1.6.0.4 Release Notes +========================== + +Fixes since v1.6.0.3 +-------------------- + +* 'git add -p' said "No changes" when only binary files were changed. + +* 'git archive' did not work correctly in bare repositories. + +* 'git checkout -t -b newbranch' when you are on detached HEAD was broken. + +* when we refuse to detect renames because there are too many new or + deleted files, 'git diff' did not say how many there are. + +* 'git push --mirror' tried and failed to push the stash; there is no + point in sending it to begin with. + +* 'git push' did not update the remote tracking reference if the corresponding + ref on the remote end happened to be already up to date. + +* 'git pull $there $branch:$current_branch' did not work when you were on + a branch yet to be born. + +* when giving up resolving a conflicted merge, 'git reset --hard' failed + to remove new paths from the working tree. + +* 'git send-email' had a small fd leak while scanning directory. + +* 'git status' incorrectly reported a submodule directory as an untracked + directory. + +* 'git svn' used deprecated 'git-foo' form of subcommand invocation. + +* 'git update-ref -d' to remove a reference did not honor --no-deref option. + +* Plugged small memleaks here and there. + +* Also contains many documentation updates. diff --git a/Documentation/RelNotes-1.6.0.5.txt b/Documentation/RelNotes-1.6.0.5.txt new file mode 100644 index 0000000000..a08bb96738 --- /dev/null +++ b/Documentation/RelNotes-1.6.0.5.txt @@ -0,0 +1,56 @@ +GIT v1.6.0.5 Release Notes +========================== + +Fixes since v1.6.0.4 +-------------------- + +* "git checkout" used to crash when your HEAD was pointing at a deleted + branch. + +* "git checkout" from an un-checked-out state did not allow switching out + of the current branch. + +* "git diff" always allowed GIT_EXTERNAL_DIFF and --no-ext-diff was no-op for + the command. + +* Giving 3 or more tree-ish to "git diff" is supposed to show the combined + diff from second and subsequent trees to the first one, but the order was + screwed up. + +* "git fast-export" did not export all tags. + +* "git ls-files --with-tree=<tree>" did not work with options other + than -c, most notably with -m. + +* "git pack-objects" did not make its best effort to honor --max-pack-size + option when a single first object already busted the given limit and + placed many objects in a single pack. + +* "git-p4" fast import frontend was too eager to trigger its keyword expansion + logic, even on a keyword-looking string that does not have closing '$' on the + same line. + +* "git push $there" when the remote $there is defined in $GIT_DIR/branches/$there + behaves more like what cg-push from Cogito used to work. + +* when giving up resolving a conflicted merge, "git reset --hard" failed + to remove new paths from the working tree. + +* "git tag" did not complain when given mutually incompatible set of options. + +* The message constructed in the internal editor was discarded when "git + tag -s" failed to sign the message, which was often caused by the user + not configuring GPG correctly. + +* "make check" cannot be run without sparse; people may have meant to say + "make test" instead, so suggest that. + +* Internal diff machinery had a corner case performance bug that choked on + a large file with many repeated contents. + +* "git repack" used to grab objects out of packs marked with .keep + into a new pack. + +* Many unsafe call to sprintf() style varargs functions are corrected. + +* Also contains quite a few documentation updates. diff --git a/Documentation/RelNotes-1.6.0.6.txt b/Documentation/RelNotes-1.6.0.6.txt new file mode 100644 index 0000000000..64ece1ffd5 --- /dev/null +++ b/Documentation/RelNotes-1.6.0.6.txt @@ -0,0 +1,33 @@ +GIT v1.6.0.6 Release Notes +========================== + +Fixes since 1.6.0.5 +------------------- + + * "git fsck" had a deep recursion that wasted stack space. + + * "git fast-export" and "git fast-import" choked on an old style + annotated tag that lack the tagger information. + + * "git mergetool -- file" did not correctly skip "--" marker that + signals the end of options list. + + * "git show $tag" segfaulted when an annotated $tag pointed at a + nonexistent object. + + * "git show 2>error" when the standard output is automatically redirected + to the pager redirected the standard error to the pager as well; there + was no need to. + + * "git send-email" did not correctly handle list of addresses when + they had quoted comma (e.g. "Lastname, Givenname" <mail@addre.ss>). + + * Logic to discover branch ancestry in "git svn" was unreliable when + the process to fetch history was interrupted. + + * Removed support for an obsolete gitweb request URI, whose + implementation ran "git diff" Porcelain, instead of using plumbing, + which would have run an external diff command specified in the + repository configuration as the gitweb user. + +Also contains numerous documentation typofixes. diff --git a/Documentation/RelNotes-1.6.0.txt b/Documentation/RelNotes-1.6.0.txt new file mode 100644 index 0000000000..de7ef166b6 --- /dev/null +++ b/Documentation/RelNotes-1.6.0.txt @@ -0,0 +1,258 @@ +GIT v1.6.0 Release Notes +======================== + +User visible changes +-------------------- + +With the default Makefile settings, most of the programs are now +installed outside your $PATH, except for "git", "gitk" and +some server side programs that need to be accessible for technical +reasons. Invoking a git subcommand as "git-xyzzy" from the command +line has been deprecated since early 2006 (and officially announced in +1.5.4 release notes); use of them from your scripts after adding +output from "git --exec-path" to the $PATH is still supported in this +release, but users are again strongly encouraged to adjust their +scripts to use "git xyzzy" form, as we will stop installing +"git-xyzzy" hardlinks for built-in commands in later releases. + +An earlier change to page "git status" output was overwhelmingly unpopular +and has been reverted. + +Source changes needed for porting to MinGW environment are now all in the +main git.git codebase. + +By default, packfiles created with this version uses delta-base-offset +encoding introduced in v1.4.4. Pack idx files are using version 2 that +allows larger packs and added robustness thanks to its CRC checking, +introduced in v1.5.2 and v1.4.4.5. If you want to keep your repositories +backwards compatible past these versions, set repack.useDeltaBaseOffset +to false or pack.indexVersion to 1, respectively. + +We used to prevent sample hook scripts shipped in templates/ from +triggering by default by relying on the fact that we install them as +unexecutable, but on some filesystems, this approach does not work. +They are now shipped with ".sample" suffix. If you want to activate +any of these samples as-is, rename them to drop the ".sample" suffix, +instead of running "chmod +x" on them. For example, you can rename +hooks/post-update.sample to hooks/post-update to enable the sample +hook that runs update-server-info, in order to make repositories +friendly to dumb protocols (i.e. HTTP). + +GIT_CONFIG, which was only documented as affecting "git config", but +actually affected all git commands, now only affects "git config". +GIT_LOCAL_CONFIG, also only documented as affecting "git config" and +not different from GIT_CONFIG in a useful way, is removed. + +The ".dotest" temporary area "git am" and "git rebase" use is now moved +inside the $GIT_DIR, to avoid mistakes of adding it to the project by +accident. + +An ancient merge strategy "stupid" has been removed. + + +Updates since v1.5.6 +-------------------- + +(subsystems) + +* git-p4 in contrib learned "allowSubmit" configuration to control on + which branch to allow "submit" subcommand. + +* git-gui learned to stage changes per-line. + +(portability) + +* Changes for MinGW port have been merged, thanks to Johannes Sixt and + gangs. + +* Sample hook scripts shipped in templates/ are now suffixed with + *.sample. + +* perl's in-place edit (-i) does not work well without backup files on Windows; + some tests are rewritten to cope with this. + +(documentation) + +* Updated howto/update-hook-example + +* Got rid of usage of "git-foo" from the tutorial and made typography + more consistent. + +* Disambiguating "--" between revs and paths is finally documented. + +(performance, robustness, sanity etc.) + +* index-pack used too much memory when dealing with a deep delta chain. + This has been optimized. + +* reduced excessive inlining to shrink size of the "git" binary. + +* verify-pack checks the object CRC when using version 2 idx files. + +* When an object is corrupt in a pack, the object became unusable even + when the same object is available in a loose form, We now try harder to + fall back to these redundant objects when able. In particular, "git + repack -a -f" can be used to fix such a corruption as long as necessary + objects are available. + +* Performance of "git-blame -C -C" operation is vastly improved. + +* git-clone does not create refs in loose form anymore (it behaves as + if you immediately ran git-pack-refs after cloning). This will help + repositories with insanely large number of refs. + +* core.fsyncobjectfiles configuration can be used to ensure that the loose + objects created will be fsync'ed (this is only useful on filesystems + that does not order data writes properly). + +* "git commit-tree" plumbing can make Octopus with more than 16 parents. + "git commit" has been capable of this for quite some time. + +(usability, bells and whistles) + +* even more documentation pages are now accessible via "man" and "git help". + +* A new environment variable GIT_CEILING_DIRECTORIES can be used to stop + the discovery process of the toplevel of working tree; this may be useful + when you are working in a slow network disk and are outside any working tree, + as bash-completion and "git help" may still need to run in these places. + +* By default, stash entries never expire. Set reflogexpire in [gc + "refs/stash"] to a reasonable value to get traditional auto-expiration + behaviour back + +* Longstanding latency issue with bash completion script has been + addressed. This will need to be backmerged to 'maint' later. + +* pager.<cmd> configuration variable can be used to enable/disable the + default paging behaviour per command. + +* "git-add -i" has a new action 'e/dit' to allow you edit the patch hunk + manually. + +* git-am records the original tip of the branch in ORIG_HEAD before it + starts applying patches. + +* git-apply can handle a patch that touches the same path more than once + much better than before. + +* git-apply can be told not to trust the line counts recorded in the input + patch but recount, with the new --recount option. + +* git-apply can be told to apply a patch to a path deeper than what the + patch records with --directory option. + +* git-archive can be told to omit certain paths from its output using + export-ignore attributes. + +* git-archive uses the zlib default compression level when creating + zip archive. + +* git-archive's command line options --exec and --remote can take their + parameters as separate command line arguments, similar to other commands. + IOW, both "--exec=path" and "--exec path" are now supported. + +* With -v option, git-branch describes the remote tracking statistics + similar to the way git-checkout reports by how many commits your branch + is ahead/behind. + +* git-branch's --contains option used to always require a commit parameter + to limit the branches with; it now defaults to list branches that + contains HEAD if this parameter is omitted. + +* git-branch's --merged and --no-merged option used to always limit the + branches relative to the HEAD, but they can now take an optional commit + argument that is used in place of HEAD. + +* git-bundle can read the revision arguments from the standard input. + +* git-cherry-pick can replay a root commit now. + +* git-clone can clone from a remote whose URL would be rewritten by + configuration stored in $HOME/.gitconfig now. + +* "git-clone --mirror" is a handy way to set up a bare mirror repository. + +* git-cvsserver learned to respond to "cvs co -c". + +* git-diff --check now checks leftover merge conflict markers. + +* "git-diff -p" learned to grab a better hunk header lines in + BibTex, Pascal/Delphi, and Ruby files and also pays attention to + chapter and part boundary in TeX documents. + +* When remote side used to have branch 'foo' and git-fetch finds that now + it has branch 'foo/bar', it refuses to lose the existing remote tracking + branch and its reflog. The error message has been improved to suggest + pruning the remote if the user wants to proceed and get the latest set + of branches from the remote, including such 'foo/bar'. + +* fast-export learned to export and import marks file; this can be used to + interface with fast-import incrementally. + +* fast-import and fast-export learned to export and import gitlinks. + +* "gitk" left background process behind after being asked to dig very deep + history and the user killed the UI; the process is killed when the UI goes + away now. + +* git-rebase records the original tip of branch in ORIG_HEAD before it is + rewound. + +* "git rerere" can be told to update the index with auto-reused resolution + with rerere.autoupdate configuration variable. + +* git-rev-parse learned $commit^! and $commit^@ notations used in "log" + family. These notations are available in gitk as well, because the gitk + command internally uses rev-parse to interpret its arguments. + +* git-rev-list learned --children option to show child commits it + encountered during the traversal, instead of showing parent commits. + +* git-send-mail can talk not just over SSL but over TLS now. + +* git-shortlog honors custom output format specified with "--pretty=format:". + +* "git-stash save" learned --keep-index option. This lets you stash away the + local changes and bring the changes staged in the index to your working + tree for examination and testing. + +* git-stash also learned branch subcommand to create a new branch out of + stashed changes. + +* git-status gives the remote tracking statistics similar to the way + git-checkout reports by how many commits your branch is ahead/behind. + +* "git-svn dcommit" is now aware of auto-props setting the subversion user + has. + +* You can tell "git status -u" to even more aggressively omit checking + untracked files with --untracked-files=no. + +* Original SHA-1 value for "update-ref -d" is optional now. + +* Error codes from gitweb are made more descriptive where possible, rather + than "403 forbidden" as we used to issue everywhere. + +(internal) + +* git-merge has been reimplemented in C. + + +Fixes since v1.5.6 +------------------ + +All of the fixes in v1.5.6 maintenance series are included in +this release, unless otherwise noted. + + * git-clone ignored its -u option; the fix needs to be backported to + 'maint'; + + * git-mv used to lose the distinction between changes that are staged + and that are only in the working tree, by staging both in the index + after moving such a path. + + * "git-rebase -i -p" rewrote the parents to wrong ones when amending + (either edit or squash) was involved, and did not work correctly + when fast forwarding. + diff --git a/Documentation/RelNotes-1.6.1.1.txt b/Documentation/RelNotes-1.6.1.1.txt new file mode 100644 index 0000000000..8c594ba02f --- /dev/null +++ b/Documentation/RelNotes-1.6.1.1.txt @@ -0,0 +1,59 @@ +GIT v1.6.1.1 Release Notes +========================== + +Fixes since v1.6.1 +------------------ + +* "git add frotz/nitfol" when "frotz" is a submodule should have errored + out, but it didn't. + +* "git apply" took file modes from the patch text and updated the mode + bits of the target tree even when the patch was not about mode changes. + +* "git bisect view" on Cygwin did not launch gitk + +* "git checkout $tree" did not trigger an error. + +* "git commit" tried to remove COMMIT_EDITMSG from the work tree by mistake. + +* "git describe --all" complained when a commit is described with a tag, + which was nonsense. + +* "git diff --no-index --" did not trigger no-index (aka "use git-diff as + a replacement of diff on untracked files") behaviour. + +* "git format-patch -1 HEAD" on a root commit failed to produce patch + text. + +* "git fsck branch" did not work as advertised; instead it behaved the same + way as "git fsck". + +* "git log --pretty=format:%s" did not handle a multi-line subject the + same way as built-in log listers (i.e. shortlog, --pretty=oneline, etc.) + +* "git daemon", and "git merge-file" are more careful when freopen fails + and barf, instead of going on and writing to unopened filehandle. + +* "git http-push" did not like some RFC 4918 compliant DAV server + responses. + +* "git merge -s recursive" mistakenly overwritten an untracked file in the + work tree upon delete/modify conflict. + +* "git merge -s recursive" didn't leave the index unmerged for entries with + rename/delete conflicts. + +* "git merge -s recursive" clobbered untracked files in the work tree. + +* "git mv -k" with more than one erroneous paths misbehaved. + +* "git read-tree -m -u" hence branch switching incorrectly lost a + subdirectory in rare cases. + +* "git rebase -i" issued an unnecessary error message upon a user error of + marking the first commit to be "squash"ed. + +* "git shortlog" did not format a commit message with multi-line + subject correctly. + +Many documentation updates. diff --git a/Documentation/RelNotes-1.6.1.2.txt b/Documentation/RelNotes-1.6.1.2.txt new file mode 100644 index 0000000000..be37cbb858 --- /dev/null +++ b/Documentation/RelNotes-1.6.1.2.txt @@ -0,0 +1,39 @@ +GIT v1.6.1.2 Release Notes +========================== + +Fixes since v1.6.1.1 +-------------------- + +* The logic for rename detection in internal diff used by commands like + "git diff" and "git blame" has been optimized to avoid loading the same + blob repeatedly. + +* We did not allow writing out a blob that is larger than 2GB for no good + reason. + +* "git format-patch -o $dir", when $dir is a relative directory, used it + as relative to the root of the work tree, not relative to the current + directory. + +* v1.6.1 introduced an optimization for "git push" into a repository (A) + that borrows its objects from another repository (B) to avoid sending + objects that are available in repository B, when they are not yet used + by repository A. However the code on the "git push" sender side was + buggy and did not work when repository B had new objects that are not + known by the sender. This caused pushing into a "forked" repository + served by v1.6.1 software using "git push" from v1.6.1 sometimes did not + work. The bug was purely on the "git push" sender side, and has been + corrected. + +* "git status -v" did not paint its diff output in colour even when + color.ui configuration was set. + +* "git ls-tree" learned --full-tree option to help Porcelain scripts that + want to always see the full path regardless of the current working + directory. + +* "git grep" incorrectly searched in work tree paths even when they are + marked as assume-unchanged. It now searches in the index entries. + +* "git gc" with no grace period needlessly ejected packed but unreachable + objects in their loose form, only to delete them right away. diff --git a/Documentation/RelNotes-1.6.1.3.txt b/Documentation/RelNotes-1.6.1.3.txt new file mode 100644 index 0000000000..6f0bde156a --- /dev/null +++ b/Documentation/RelNotes-1.6.1.3.txt @@ -0,0 +1,32 @@ +GIT v1.6.1.3 Release Notes +========================== + +Fixes since v1.6.1.2 +-------------------- + +* "git diff --binary | git apply" pipeline did not work well when + a binary blob is changed to a symbolic link. + +* Some combinations of -b/-w/--ignore-space-at-eol to "git diff" did + not work as expected. + +* "git grep" did not pass the -I (ignore binary) option when + calling out an external grep program. + +* "git log" and friends include HEAD to the set of starting points + when --all is given. This makes a difference when you are not + on any branch. + +* "git mv" to move an untracked file to overwrite a tracked + contents misbehaved. + +* "git merge -s octopus" with many potential merge bases did not + work correctly. + +* RPM binary package installed the html manpages in a wrong place. + +Also includes minor documentation fixes and updates. + + +-- +git shortlog --no-merges v1.6.1.2-33-gc789350.. diff --git a/Documentation/RelNotes-1.6.1.4.txt b/Documentation/RelNotes-1.6.1.4.txt new file mode 100644 index 0000000000..0ce6316d75 --- /dev/null +++ b/Documentation/RelNotes-1.6.1.4.txt @@ -0,0 +1,44 @@ +GIT v1.6.1.4 Release Notes +========================== + +Fixes since v1.6.1.3 +-------------------- + +* .gitignore learned to handle backslash as a quoting mechanism for + comment introduction character "#". + This fix was first merged to 1.6.2.1. + +* "git fast-export" produced wrong output with some parents missing from + commits, when the history is clock-skewed. + +* "git fast-import" sometimes failed to read back objects it just wrote + out and aborted, because it failed to flush stale cached data. + +* "git-ls-tree" and "git-diff-tree" used a pathspec correctly when + deciding to descend into a subdirectory but they did not match the + individual paths correctly. This caused pathspecs "abc/d ab" to match + "abc/0" ("abc/d" made them decide to descend into the directory "abc/", + and then "ab" incorrectly matched "abc/0" when it shouldn't). + This fix was first merged to 1.6.2.3. + +* import-zips script (in contrib) did not compute the common directory + prefix correctly. + This fix was first merged to 1.6.2.2. + +* "git init" segfaulted when given an overlong template location via + the --template= option. + This fix was first merged to 1.6.2.4. + +* "git repack" did not error out when necessary object was missing in the + repository. + +* git-repack (invoked from git-gc) did not work as nicely as it should in + a repository that borrows objects from neighbours via alternates + mechanism especially when some packs are marked with the ".keep" flag + to prevent them from being repacked. + This fix was first merged to 1.6.2.3. + +Also includes minor documentation fixes and updates. + +-- +git shortlog --no-merges v1.6.1.3.. diff --git a/Documentation/RelNotes-1.6.1.txt b/Documentation/RelNotes-1.6.1.txt new file mode 100644 index 0000000000..adb7ccab0a --- /dev/null +++ b/Documentation/RelNotes-1.6.1.txt @@ -0,0 +1,286 @@ +GIT v1.6.1 Release Notes +======================== + +Updates since v1.6.0 +-------------------- + +When some commands (e.g. "git log", "git diff") spawn pager internally, we +used to make the pager the parent process of the git command that produces +output. This meant that the exit status of the whole thing comes from the +pager, not the underlying git command. We swapped the order of the +processes around and you will see the exit code from the command from now +on. + +(subsystems) + +* gitk can call out to git-gui to view "git blame" output; git-gui in turn + can run gitk from its blame view. + +* Various git-gui updates including updated translations. + +* Various gitweb updates from repo.or.cz installation. + +* Updates to emacs bindings. + +(portability) + +* A few test scripts used nonportable "grep" that did not work well on + some platforms, e.g. Solaris. + +* Sample pre-auto-gc script has OS X support. + +* Makefile has support for (ancient) FreeBSD 4.9. + +(performance) + +* Many operations that are lstat(3) heavy can be told to pre-execute + necessary lstat(3) in parallel before their main operations, which + potentially gives much improved performance for cold-cache cases or in + environments with weak metadata caching (e.g. NFS). + +* The underlying diff machinery to produce textual output has been + optimized, which would result in faster "git blame" processing. + +* Most of the test scripts (but not the ones that try to run servers) + can be run in parallel. + +* Bash completion of refnames in a repository with massive number of + refs has been optimized. + +* Cygwin port uses native stat/lstat implementations when applicable, + which leads to improved performance. + +* "git push" pays attention to alternate repositories to avoid sending + unnecessary objects. + +* "git svn" can rebuild an out-of-date rev_map file. + +(usability, bells and whistles) + +* When you mistype a command name, git helpfully suggests what it guesses + you might have meant to say. help.autocorrect configuration can be set + to a non-zero value to accept the suggestion when git can uniquely + guess. + +* The packfile machinery hopefully is more robust when dealing with + corrupt packs if redundant objects involved in the corruption are + available elsewhere. + +* "git add -N path..." adds the named paths as an empty blob, so that + subsequent "git diff" will show a diff as if they are creation events. + +* "git add" gained a built-in synonym for people who want to say "stage + changes" instead of "add contents to the staging area" which amounts + to the same thing. + +* "git apply" learned --include=paths option, similar to the existing + --exclude=paths option. + +* "git bisect" is careful about a user mistake and suggests testing of + merge base first when good is not a strict ancestor of bad. + +* "git bisect skip" can take a range of commits. + +* "git blame" re-encodes the commit metainfo to UTF-8 from i18n.commitEncoding + by default. + +* "git check-attr --stdin" can check attributes for multiple paths. + +* "git checkout --track origin/hack" used to be a syntax error. It now + DWIMs to create a corresponding local branch "hack", i.e. acts as if you + said "git checkout --track -b hack origin/hack". + +* "git checkout --ours/--theirs" can be used to check out one side of a + conflicting merge during conflict resolution. + +* "git checkout -m" can be used to recreate the initial conflicted state + during conflict resolution. + +* "git cherry-pick" can also utilize rerere for conflict resolution. + +* "git clone" learned to be verbose with -v + +* "git commit --author=$name" can look up author name from existing + commits. + +* output from "git commit" has been reworded in a more concise and yet + more informative way. + +* "git count-objects" reports the on-disk footprint for packfiles and + their corresponding idx files. + +* "git daemon" learned --max-connections=<count> option. + +* "git daemon" exports REMOTE_ADDR to record client address, so that + spawned programs can act differently on it. + +* "git describe --tags" favours closer lightweight tags than farther + annotated tags now. + +* "git diff" learned to mimic --suppress-blank-empty from GNU diff via a + configuration option. + +* "git diff" learned to put more sensible hunk headers for Python, + HTML and ObjC contents. + +* "git diff" learned to vary the a/ vs b/ prefix depending on what are + being compared, controlled by diff.mnemonicprefix configuration. + +* "git diff" learned --dirstat-by-file to count changed files, not number + of lines, when summarizing the global picture. + +* "git diff" learned "textconv" filters --- a binary or hard-to-read + contents can be munged into human readable form and the difference + between the results of the conversion can be viewed (obviously this + cannot produce a patch that can be applied, so this is disabled in + format-patch among other things). + +* "--cached" option to "git diff has an easier to remember synonym "--staged", + to ask "what is the difference between the given commit and the + contents staged in the index?" + +* "git for-each-ref" learned "refname:short" token that gives an + unambiguously abbreviated refname. + +* Auto-numbering of the subject lines is the default for "git + format-patch" now. + +* "git grep" learned to accept -z similar to GNU grep. + +* "git help" learned to use GIT_MAN_VIEWER environment variable before + using "man" program. + +* "git imap-send" can optionally talk SSL. + +* "git index-pack" is more careful against disk corruption while + completing a thin pack. + +* "git log --check" and "git log --exit-code" passes their underlying diff + status with their exit status code. + +* "git log" learned --simplify-merges, a milder variant of --full-history; + "gitk --simplify-merges" is easier to view than with --full-history. + +* "git log" learned "--source" to show what ref each commit was reached + from. + +* "git log" also learned "--simplify-by-decoration" to show the + birds-eye-view of the topology of the history. + +* "git log --pretty=format:" learned "%d" format element that inserts + names of tags that point at the commit. + +* "git merge --squash" and "git merge --no-ff" into an unborn branch are + noticed as user errors. + +* "git merge -s $strategy" can use a custom built strategy if you have a + command "git-merge-$strategy" on your $PATH. + +* "git pull" (and "git fetch") can be told to operate "-v"erbosely or + "-q"uietly. + +* "git push" can be told to reject deletion of refs with receive.denyDeletes + configuration. + +* "git rebase" honours pre-rebase hook; use --no-verify to bypass it. + +* "git rebase -p" uses interactive rebase machinery now to preserve the merges. + +* "git reflog expire branch" can be used in place of "git reflog expire + refs/heads/branch". + +* "git remote show $remote" lists remote branches one-per-line now. + +* "git send-email" can be given revision range instead of files and + maildirs on the command line, and automatically runs format-patch to + generate patches for the given revision range. + +* "git submodule foreach" subcommand allows you to iterate over checked + out submodules. + +* "git submodule sync" subcommands allows you to update the origin URL + recorded in submodule directories from the toplevel .gitmodules file. + +* "git svn branch" can create new branches on the other end. + +* "gitweb" can use more saner PATH_INFO based URL. + +(internal) + +* "git hash-object" learned to lie about the path being hashed, so that + correct gitattributes processing can be done while hashing contents + stored in a temporary file. + +* various callers of git-merge-recursive avoid forking it as an external + process. + +* Git class defined in "Git.pm" can be subclasses a bit more easily. + +* We used to link GNU regex library as a compatibility layer for some + platforms, but it turns out it is not necessary on most of them. + +* Some path handling routines used fixed number of buffers used alternately + but depending on the call depth, this arrangement led to hard to track + bugs. This issue is being addressed. + + +Fixes since v1.6.0 +------------------ + +All of the fixes in v1.6.0.X maintenance series are included in this +release, unless otherwise noted. + +* Porcelains implemented as shell scripts were utterly confused when you + entered to a subdirectory of a work tree from sideways, following a + symbolic link (this may need to be backported to older releases later). + +* Tracking symbolic links would work better on filesystems whose lstat() + returns incorrect st_size value for them. + +* "git add" and "git update-index" incorrectly allowed adding S/F when S + is a tracked symlink that points at a directory D that has a path F in + it (we still need to fix a similar nonsense when S is a submodule and F + is a path in it). + +* "git am" after stopping at a broken patch lost --whitespace, -C, -p and + --3way options given from the command line initially. + +* "git diff --stdin" used to take two trees on a line and compared them, + but we dropped support for such a use case long time ago. This has + been resurrected. + +* "git filter-branch" failed to rewrite a tag name with slashes in it. + +* "git http-push" did not understand URI scheme other than opaquelocktoken + when acquiring a lock from the server (this may need to be backported to + older releases later). + +* After "git rebase -p" stopped with conflicts while replaying a merge, + "git rebase --continue" did not work (may need to be backported to older + releases). + +* "git revert" records relative to which parent a revert was made when + reverting a merge. Together with new documentation that explains issues + around reverting a merge and merging from the updated branch later, this + hopefully will reduce user confusion (this may need to be backported to + older releases later). + +* "git rm --cached" used to allow an empty blob that was added earlier to + be removed without --force, even when the file in the work tree has + since been modified. + +* "git push --tags --all $there" failed with generic usage message without + telling saying these two options are incompatible. + +* "git log --author/--committer" match used to potentially match the + timestamp part, exposing internal implementation detail. Also these did + not work with --fixed-strings match at all. + +* "gitweb" did not mark non-ASCII characters imported from external HTML fragments + correctly. + +-- +exec >/var/tmp/1 +O=v1.6.1-rc3-74-gf66bc5f +echo O=$(git describe master) +git shortlog --no-merges $O..master ^maint diff --git a/Documentation/RelNotes-1.6.2.1.txt b/Documentation/RelNotes-1.6.2.1.txt new file mode 100644 index 0000000000..dfa36416af --- /dev/null +++ b/Documentation/RelNotes-1.6.2.1.txt @@ -0,0 +1,19 @@ +GIT v1.6.2.1 Release Notes +========================== + +Fixes since v1.6.2 +------------------ + +* .gitignore learned to handle backslash as a quoting mechanism for + comment introduction character "#". + +* timestamp output in --date=relative mode used to display timestamps that + are long time ago in the default mode; it now uses "N years M months + ago", and "N years ago". + +* git-add -i/-p now works with non-ASCII pathnames. + +* "git hash-object -w" did not read from the configuration file from the + correct .git directory. + +* git-send-email learned to correctly handle multiple Cc: addresses. diff --git a/Documentation/RelNotes-1.6.2.2.txt b/Documentation/RelNotes-1.6.2.2.txt new file mode 100644 index 0000000000..fafa9986b0 --- /dev/null +++ b/Documentation/RelNotes-1.6.2.2.txt @@ -0,0 +1,45 @@ +GIT v1.6.2.2 Release Notes +========================== + +Fixes since v1.6.2.1 +-------------------- + +* A longstanding confusing description of what --pickaxe option of + git-diff does has been clarified in the documentation. + +* "git-blame -S" did not quite work near the commits that were given + on the command line correctly. + +* "git diff --pickaxe-regexp" did not count overlapping matches + correctly. + +* "git diff" did not feed files in work-tree representation to external + diff and textconv. + +* "git-fetch" in a repository that was not cloned from anywhere said + it cannot find 'origin', which was hard to understand for new people. + +* "git-format-patch --numbered-files --stdout" did not have to die of + incompatible options; it now simply ignores --numbered-files as no files + are produced anyway. + +* "git-ls-files --deleted" did not work well with GIT_DIR&GIT_WORK_TREE. + +* "git-read-tree A B C..." without -m option has been broken for a long + time. + +* git-send-email ignored --in-reply-to when --no-thread was given. + +* 'git-submodule add' did not tolerate extra slashes and ./ in the path it + accepted from the command line; it now is more lenient. + +* git-svn misbehaved when the project contained a path that began with + two dashes. + +* import-zips script (in contrib) did not compute the common directory + prefix correctly. + +* miscompilation of negated enum constants by old gcc (2.9) affected the + codepaths to spawn subprocesses. + +Many small documentation updates are included as well. diff --git a/Documentation/RelNotes-1.6.2.3.txt b/Documentation/RelNotes-1.6.2.3.txt new file mode 100644 index 0000000000..4d3c1ac91c --- /dev/null +++ b/Documentation/RelNotes-1.6.2.3.txt @@ -0,0 +1,22 @@ +GIT v1.6.2.3 Release Notes +========================== + +Fixes since v1.6.2.2 +-------------------- + +* Setting an octal mode value to core.sharedrepository configuration to + restrict access to the repository to group members did not work as + advertised. + +* A fairly large and trivial memory leak while rev-list shows list of + reachable objects has been identified and plugged. + +* "git-commit --interactive" did not abort when underlying "git-add -i" + signaled a failure. + +* git-repack (invoked from git-gc) did not work as nicely as it should in + a repository that borrows objects from neighbours via alternates + mechanism especially when some packs are marked with the ".keep" flag + to prevent them from being repacked. + +Many small documentation updates are included as well. diff --git a/Documentation/RelNotes-1.6.2.4.txt b/Documentation/RelNotes-1.6.2.4.txt new file mode 100644 index 0000000000..f4bf1d0986 --- /dev/null +++ b/Documentation/RelNotes-1.6.2.4.txt @@ -0,0 +1,39 @@ +GIT v1.6.2.4 Release Notes +========================== + +Fixes since v1.6.2.3 +-------------------- + +* The configuration parser had a buffer overflow while parsing an overlong + value. + +* pruning reflog entries that are unreachable from the tip of the ref + during "git reflog prune" (hence "git gc") was very inefficient. + +* "git-add -p" lacked a way to say "q"uit to refuse staging any hunks for + the remaining paths. You had to say "d" and then ^C. + +* "git-checkout <tree-ish> <submodule>" did not update the index entry at + the named path; it now does. + +* "git-fast-export" choked when seeing a tag that does not point at commit. + +* "git init" segfaulted when given an overlong template location via + the --template= option. + +* "git-ls-tree" and "git-diff-tree" used a pathspec correctly when + deciding to descend into a subdirectory but they did not match the + individual paths correctly. This caused pathspecs "abc/d ab" to match + "abc/0" ("abc/d" made them decide to descend into the directory "abc/", + and then "ab" incorrectly matched "abc/0" when it shouldn't). + +* "git-merge-recursive" was broken when a submodule entry was involved in + a criss-cross merge situation. + +Many small documentation updates are included as well. + +--- +exec >/var/tmp/1 +echo O=$(git describe maint) +O=v1.6.2.3-38-g318b847 +git shortlog --no-merges $O..maint diff --git a/Documentation/RelNotes-1.6.2.5.txt b/Documentation/RelNotes-1.6.2.5.txt new file mode 100644 index 0000000000..b23f9e95d1 --- /dev/null +++ b/Documentation/RelNotes-1.6.2.5.txt @@ -0,0 +1,21 @@ +GIT v1.6.2.5 Release Notes +========================== + +Fixes since v1.6.2.4 +-------------------- + +* "git apply" mishandled if you fed a git generated patch that renames + file A to B and file B to A at the same time. + +* "git diff -c -p" (and "diff --cc") did not expect to see submodule + differences and instead refused to work. + +* "git grep -e '('" segfaulted, instead of diagnosing a mismatched + parentheses error. + +* "git fetch" generated packs with offset-delta encoding when both ends of + the connection are capable of producing one; this cannot be read by + ancient git and the user should be able to disable this by setting + repack.usedeltabaseoffset configuration to false. + + diff --git a/Documentation/RelNotes-1.6.2.txt b/Documentation/RelNotes-1.6.2.txt new file mode 100644 index 0000000000..ad060f4f89 --- /dev/null +++ b/Documentation/RelNotes-1.6.2.txt @@ -0,0 +1,164 @@ +GIT v1.6.2 Release Notes +======================== + +With the next major release, "git push" into a branch that is +currently checked out will be refused by default. You can choose +what should happen upon such a push by setting the configuration +variable receive.denyCurrentBranch in the receiving repository. + +To ease the transition plan, the receiving repository of such a +push running this release will issue a big warning when the +configuration variable is missing. Please refer to: + + http://git.or.cz/gitwiki/GitFaq#non-bare + http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 + +for more details on the reason why this change is needed and the +transition plan. + +For a similar reason, "git push $there :$killed" to delete the branch +$killed in a remote repository $there, if $killed branch is the current +branch pointed at by its HEAD, gets a large warning. You can choose what +should happen upon such a push by setting the configuration variable +receive.denyDeleteCurrent in the receiving repository. + + +Updates since v1.6.1 +-------------------- + +(subsystems) + +* git-svn updates. + +* gitweb updates, including a new patch view and RSS/Atom feed + improvements. + +* (contrib/emacs) git.el now has commands for checking out a branch, + creating a branch, cherry-picking and reverting commits; vc-git.el + is not shipped with git anymore (it is part of official Emacs). + +(performance) + +* pack-objects autodetects the number of CPUs available and uses threaded + version. + +(usability, bells and whistles) + +* automatic typo correction works on aliases as well + +* @{-1} is a way to refer to the last branch you were on. This is + accepted not only where an object name is expected, but anywhere + a branch name is expected and acts as if you typed the branch name. + E.g. "git branch --track mybranch @{-1}", "git merge @{-1}", and + "git rev-parse --symbolic-full-name @{-1}" would work as expected. + +* When refs/remotes/origin/HEAD points at a remote tracking branch that + has been pruned away, many git operations issued warning when they + internally enumerated the refs. We now warn only when you say "origin" + to refer to that pruned branch. + +* The location of .mailmap file can be configured, and its file format was + enhanced to allow mapping an incorrect e-mail field as well. + +* "git add -p" learned 'g'oto action to jump directly to a hunk. + +* "git add -p" learned to find a hunk with given text with '/'. + +* "git add -p" optionally can be told to work with just the command letter + without Enter. + +* when "git am" stops upon a patch that does not apply, it shows the + title of the offending patch. + +* "git am --directory=<dir>" and "git am --reject" passes these options + to underlying "git apply". + +* "git am" learned --ignore-date option. + +* "git blame" aligns author names better when they are spelled in + non US-ASCII encoding. + +* "git clone" now makes its best effort when cloning from an empty + repository to set up configuration variables to refer to the remote + repository. + +* "git checkout -" is a shorthand for "git checkout @{-1}". + +* "git cherry" defaults to whatever the current branch is tracking (if + exists) when the <upstream> argument is not given. + +* "git cvsserver" can be told not to add extra "via git-CVS emulator" to + the commit log message it serves via gitcvs.commitmsgannotation + configuration. + +* "git cvsserver" learned to handle 'noop' command some CVS clients seem + to expect to work. + +* "git diff" learned a new option --inter-hunk-context to coalesce close + hunks together and show context between them. + +* The definition of what constitutes a word for "git diff --color-words" + can be customized via gitattributes, command line or a configuration. + +* "git diff" learned --patience to run "patience diff" algorithm. + +* "git filter-branch" learned --prune-empty option that discards commits + that do not change the contents. + +* "git fsck" now checks loose objects in alternate object stores, instead + of misreporting them as missing. + +* "git gc --prune" was resurrected to allow "git gc --no-prune" and + giving non-default expiration period e.g. "git gc --prune=now". + +* "git grep -w" and "git grep" for fixed strings have been optimized. + +* "git mergetool" learned -y(--no-prompt) option to disable prompting. + +* "git rebase -i" can transplant a history down to root to elsewhere + with --root option. + +* "git reset --merge" is a new mode that works similar to the way + "git checkout" switches branches, taking the local changes while + switching to another commit. + +* "git submodule update" learned --no-fetch option. + +* "git tag" learned --contains that works the same way as the same option + from "git branch". + + +Fixes since v1.6.1 +------------------ + +All of the fixes in v1.6.1.X maintenance series are included in this +release, unless otherwise noted. + +Here are fixes that this release has, but have not been backported to +v1.6.1.X series. + +* "git-add sub/file" when sub is a submodule incorrectly added the path to + the superproject. + +* "git bundle" did not exclude annotated tags even when a range given + from the command line wanted to. + +* "git filter-branch" unnecessarily refused to work when you had + checked out a different commit from what is recorded in the superproject + index in a submodule. + +* "git filter-branch" incorrectly tried to update a nonexistent work tree + at the end when it is run in a bare repository. + +* "git gc" did not work if your repository was created with an ancient git + and never had any pack files in it before. + +* "git mergetool" used to ignore autocrlf and other attributes + based content rewriting. + +* branch switching and merges had a silly bug that did not validate + the correct directory when making sure an existing subdirectory is + clean. + +* "git -p cmd" when cmd is not a built-in one left the display in funny state + when killed in the middle. diff --git a/Documentation/RelNotes-1.6.3.1.txt b/Documentation/RelNotes-1.6.3.1.txt new file mode 100644 index 0000000000..2400b72ef7 --- /dev/null +++ b/Documentation/RelNotes-1.6.3.1.txt @@ -0,0 +1,10 @@ +GIT v1.6.3.1 Release Notes +========================== + +Fixes since v1.6.3 +------------------ + +* "git checkout -b new-branch" with a staged change in the index + incorrectly primed the in-index cache-tree, resulting a wrong tree + object to be written out of the index. This is a grave regression + since the last 1.6.2.X maintenance release. diff --git a/Documentation/RelNotes-1.6.3.2.txt b/Documentation/RelNotes-1.6.3.2.txt new file mode 100644 index 0000000000..b2f3f0293c --- /dev/null +++ b/Documentation/RelNotes-1.6.3.2.txt @@ -0,0 +1,61 @@ +GIT v1.6.3.2 Release Notes +========================== + +Fixes since v1.6.3.1 +-------------------- + + * A few codepaths picked up the first few bytes from an sha1[] by + casting the (char *) pointer to (int *); GCC 4.4 did not like this, + and aborted compilation. + + * Some unlink(2) failures went undiagnosed. + + * The "recursive" merge strategy misbehaved when faced rename/delete + conflicts while coming up with an intermediate merge base. + + * The low-level merge algorithm did not handle a degenerate case of + merging a file with itself using itself as the common ancestor + gracefully. It should produce the file itself, but instead + produced an empty result. + + * GIT_TRACE mechanism segfaulted when tracing a shell-quoted aliases. + + * OpenBSD also uses st_ctimspec in "struct stat", instead of "st_ctim". + + * With NO_CROSS_DIRECTORY_HARDLINKS, "make install" can be told not to + create hardlinks between $(gitexecdir)/git-$builtin_commands and + $(bindir)/git. + + * command completion code in bash did not reliably detect that we are + in a bare repository. + + * "git add ." in an empty directory complained that pathspec "." did not + match anything, which may be technically correct, but not useful. We + silently make it a no-op now. + + * "git add -p" (and "patch" action in "git add -i") was broken when + the first hunk that adds a line at the top was split into two and + both halves are marked to be used. + + * "git blame path" misbehaved at the commit where path became file + from a directory with some files in it. + + * "git for-each-ref" had a segfaulting bug when dealing with a tag object + created by an ancient git. + + * "git format-patch -k" still added patch numbers if format.numbered + configuration was set. + + * "git grep --color ''" did not terminate. The command also had + subtle bugs with its -w option. + + * http-push had a small use-after-free bug. + + * "git push" was converting OFS_DELTA pack representation into less + efficient REF_DELTA representation unconditionally upon transfer, + making the transferred data unnecessarily larger. + + * "git remote show origin" segfaulted when origin was still empty. + +Many other general usability updates around help text, diagnostic messages +and documentation are included as well. diff --git a/Documentation/RelNotes-1.6.3.3.txt b/Documentation/RelNotes-1.6.3.3.txt new file mode 100644 index 0000000000..1c28398bb6 --- /dev/null +++ b/Documentation/RelNotes-1.6.3.3.txt @@ -0,0 +1,38 @@ +GIT v1.6.3.3 Release Notes +========================== + +Fixes since v1.6.3.2 +-------------------- + + * "git archive" running on Cygwin can get stuck in an infinite loop. + + * "git daemon" did not correctly parse the initial line that carries + virtual host request information. + + * "git diff --textconv" leaked memory badly when the textconv filter + errored out. + + * The built-in regular expressions to pick function names to put on + hunk header lines for java and objc were very inefficiently written. + + * in certain error situations git-fetch (and git-clone) on Windows didn't + detect connection abort and ended up waiting indefinitely. + + * import-tars script (in contrib) did not import symbolic links correctly. + + * http.c used CURLOPT_SSLKEY even on libcURL version 7.9.2, even though + it was only available starting 7.9.3. + + * low-level filelevel merge driver used return value from strdup() + without checking if we ran out of memory. + + * "git rebase -i" left stray closing parenthesis in its reflog message. + + * "git remote show" did not show all the URLs associated with the named + remote, even though "git remote -v" did. Made them consistent by + making the former show all URLs. + + * "whitespace" attribute that is set was meant to detect all errors known + to git, but it told git to ignore trailing carriage-returns. + +Includes other documentation fixes. diff --git a/Documentation/RelNotes-1.6.3.4.txt b/Documentation/RelNotes-1.6.3.4.txt new file mode 100644 index 0000000000..cad461bc76 --- /dev/null +++ b/Documentation/RelNotes-1.6.3.4.txt @@ -0,0 +1,36 @@ +GIT v1.6.3.4 Release Notes +========================== + +Fixes since v1.6.3.3 +-------------------- + + * "git add --no-ignore-errors" did not override configured + add.ignore-errors configuration. + + * "git apply --whitespace=fix" did not fix trailing whitespace on an + incomplete line. + + * "git branch" opened too many commit objects unnecessarily. + + * "git checkout -f $commit" with a path that is a file (or a symlink) in + the work tree to a commit that has a directory at the path issued an + unnecessary error message. + + * "git diff -c/--cc" was very inefficient in coalescing the removed lines + shared between parents. + + * "git diff -c/--cc" showed removed lines at the beginning of a file + incorrectly. + + * "git remote show nickname" did not honor configured + remote.nickname.uploadpack when inspecting the branches at the remote. + + * "git request-pull" when talking to the terminal for a preview + showed some of the output in the pager. + + * "git request-pull start nickname [end]" did not honor configured + remote.nickname.uploadpack when it ran git-ls-remote against the remote + repository to learn the current tip of branches. + +Includes other documentation updates and minor fixes. + diff --git a/Documentation/RelNotes-1.6.3.txt b/Documentation/RelNotes-1.6.3.txt new file mode 100644 index 0000000000..418c685cf8 --- /dev/null +++ b/Documentation/RelNotes-1.6.3.txt @@ -0,0 +1,182 @@ +GIT v1.6.3 Release Notes +======================== + +With the next major release, "git push" into a branch that is +currently checked out will be refused by default. You can choose +what should happen upon such a push by setting the configuration +variable receive.denyCurrentBranch in the receiving repository. + +To ease the transition plan, the receiving repository of such a +push running this release will issue a big warning when the +configuration variable is missing. Please refer to: + + http://git.or.cz/gitwiki/GitFaq#non-bare + http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 + +for more details on the reason why this change is needed and the +transition plan. + +For a similar reason, "git push $there :$killed" to delete the branch +$killed in a remote repository $there, if $killed branch is the current +branch pointed at by its HEAD, gets a large warning. You can choose what +should happen upon such a push by setting the configuration variable +receive.denyDeleteCurrent in the receiving repository. + +When the user does not tell "git push" what to push, it has always +pushed matching refs. For some people it is unexpected, and a new +configuration variable push.default has been introduced to allow +changing a different default behaviour. To advertise the new feature, +a big warning is issued if this is not configured and a git push without +arguments is attempted. + + +Updates since v1.6.2 +-------------------- + +(subsystems) + +* various git-svn updates. + +* git-gui updates, including an update to Russian translation, and a + fix to an infinite loop when showing an empty diff. + +* gitk updates, including an update to Russian translation and improved Windows + support. + +(performance) + +* many uses of lstat(2) in the codepath for "git checkout" have been + optimized out. + +(usability, bells and whistles) + +* Boolean configuration variable yes/no can be written as on/off. + +* rsync:/path/to/repo can be used to run git over rsync for local + repositories. It may not be useful in practice; meant primarily for + testing. + +* http transport learned to prompt and use password when fetching from or + pushing to http://user@host.xz/ URL. + +* (msysgit) progress output that is sent over the sideband protocol can + be handled appropriately in Windows console. + +* "--pretty=<style>" option to the log family of commands can now be + spelled as "--format=<style>". In addition, --format=%formatstring + is a short-hand for --pretty=tformat:%formatstring. + +* "--oneline" is a synonym for "--pretty=oneline --abbrev-commit". + +* "--graph" to the "git log" family can draw the commit ancestry graph + in colors. + +* If you realize that you botched the patch when you are editing hunks + with the 'edit' action in git-add -i/-p, you can abort the editor to + tell git not to apply it. + +* @{-1} is a new way to refer to the last branch you were on introduced in + 1.6.2, but the initial implementation did not teach this to a few + commands. Now the syntax works with "branch -m @{-1} newname". + +* git-archive learned --output=<file> option. + +* git-archive takes attributes from the tree being archived; strictly + speaking, this is an incompatible behaviour change, but is a good one. + Use --worktree-attributes option to allow it to read attributes from + the work tree as before (deprecated git-tar tree command always reads + attributes from the work tree). + +* git-bisect shows not just the number of remaining commits whose goodness + is unknown, but also shows the estimated number of remaining rounds. + +* You can give --date=<format> option to git-blame. + +* "git-branch -r" shows HEAD symref that points at a remote branch in + interest of each tracked remote repository. + +* "git-branch -v -v" is a new way to get list of names for branches and the + "upstream" branch for them. + +* git-config learned -e option to open an editor to edit the config file + directly. + +* git-clone runs post-checkout hook when run without --no-checkout. + +* git-difftool is now part of the officially supported command, primarily + maintained by David Aguilar. + +* git-for-each-ref learned a new "upstream" token. + +* git-format-patch can be told to use attachment with a new configuration, + format.attach. + +* git-format-patch can be told to produce deep or shallow message threads. + +* git-format-patch can be told to always add sign-off with a configuration + variable. + +* git-format-patch learned format.headers configuration to add extra + header fields to the output. This behaviour is similar to the existing + --add-header=<header> option of the command. + +* git-format-patch gives human readable names to the attached files, when + told to send patches as attachments. + +* git-grep learned to highlight the found substrings in color. + +* git-imap-send learned to work around Thunderbird's inability to easily + disable format=flowed with a new configuration, imap.preformattedHTML. + +* git-rebase can be told to rebase the series even if your branch is a + descendant of the commit you are rebasing onto with --force-rebase + option. + +* git-rebase can be told to report diffstat with the --stat option. + +* Output from git-remote command has been vastly improved. + +* "git remote update --prune $remote" updates from the named remote and + then prunes stale tracking branches. + +* git-send-email learned --confirm option to review the Cc: list before + sending the messages out. + +(developers) + +* Test scripts can be run under valgrind. + +* Test scripts can be run with installed git. + +* Makefile learned 'coverage' option to run the test suites with + coverage tracking enabled. + +* Building the manpages with docbook-xsl between 1.69.1 and 1.71.1 now + requires setting DOCBOOK_SUPPRESS_SP to work around a docbook-xsl bug. + This workaround used to be enabled by default, but causes problems + with newer versions of docbook-xsl. In addition, there are a few more + knobs you can tweak to work around issues with various versions of the + docbook-xsl package. See comments in Documentation/Makefile for details. + +* Support for building and testing a subset of git on a system without a + working perl has been improved. + + +Fixes since v1.6.2 +------------------ + +All of the fixes in v1.6.2.X maintenance series are included in this +release, unless otherwise noted. + +Here are fixes that this release has, but have not been backported to +v1.6.2.X series. + +* "git-apply" rejected a patch that swaps two files (i.e. renames A to B + and B to A at the same time). May need to be backported by cherry + picking d8c81df and then 7fac0ee). + +* The initial checkout did not read the attributes from the .gitattribute + file that is being checked out. + +* git-gc spent excessive amount of time to decide if an object appears + in a locally existing pack (if needed, backport by merging 69e020a). diff --git a/Documentation/RelNotes-1.6.4.1.txt b/Documentation/RelNotes-1.6.4.1.txt new file mode 100644 index 0000000000..e439e45b96 --- /dev/null +++ b/Documentation/RelNotes-1.6.4.1.txt @@ -0,0 +1,46 @@ +GIT v1.6.4.1 Release Notes +========================== + +Fixes since v1.6.4 +------------------ + + * An unquoted value in the configuration file, when it contains more than + one whitespaces in a row, got them replaced with a single space. + + * "git am" used to accept a single piece of e-mail per file (not a mbox) + as its input, but multiple input format support in v1.6.4 broke it. + Apparently many people have been depending on this feature. + + * The short help text for "git filter-branch" command was a single long + line, wrapped by terminals, and was hard to read. + + * The "recursive" strategy of "git merge" segfaulted when a merge has + more than one merge-bases, and merging of these merge-bases involves + a rename/rename or a rename/add conflict. + + * "git pull --rebase" did not use the right fork point when the + repository has already fetched from the upstream that rewinds the + branch it is based on in an earlier fetch. + + * Explain the concept of fast-forward more fully in "git push" + documentation, and hint to refer to it from an error message when the + command refuses an update to protect the user. + + * The default value for pack.deltacachesize, used by "git repack", is now + 256M, instead of unbounded. Otherwise a repack of a moderately sized + repository would needlessly eat into swap. + + * Document how "git repack" (hence "git gc") interacts with a repository + that borrows its objects from other repositories (e.g. ones created by + "git clone -s"). + + * "git show" on an annotated tag lacked a delimiting blank line between + the tag itself and the contents of the object it tags. + + * "git verify-pack -v" erroneously reported number of objects with too + deep delta depths as "chain length 0" objects. + + * Long names of authors and committers outside US-ASCII were sometimes + incorrectly shown in "gitweb". + +Other minor documentation updates are included. diff --git a/Documentation/RelNotes-1.6.4.2.txt b/Documentation/RelNotes-1.6.4.2.txt new file mode 100644 index 0000000000..c11ec0115c --- /dev/null +++ b/Documentation/RelNotes-1.6.4.2.txt @@ -0,0 +1,32 @@ +GIT v1.6.4.2 Release Notes +========================== + +Fixes since v1.6.4.1 +-------------------- + +* --date=relative output between 1 and 5 years ago rounded the number of + years when saying X years Y months ago, instead of rounding it down. + +* "git add -p" did not handle changes in executable bits correctly + (a regression around 1.6.3). + +* "git apply" did not honor GNU diff's convention to mark the creation/deletion + event with UNIX epoch timestamp on missing side. + +* "git checkout" incorrectly removed files in a directory pointed by a + symbolic link during a branch switch that replaces a directory with + a symbolic link. + +* "git clean -d -f" happily descended into a subdirectory that is managed by a + separate git repository. It now requires two -f options for safety. + +* "git fetch/push" over http transports had two rather grave bugs. + +* "git format-patch --cover-letter" did not prepare the cover letter file + for use with non-ASCII strings when there are the series contributors with + non-ASCII names. + +* "git pull origin branch" and "git fetch origin && git merge origin/branch" + left different merge messages in the resulting commit. + +Other minor documentation updates are included. diff --git a/Documentation/RelNotes-1.6.4.3.txt b/Documentation/RelNotes-1.6.4.3.txt new file mode 100644 index 0000000000..4f29babdeb --- /dev/null +++ b/Documentation/RelNotes-1.6.4.3.txt @@ -0,0 +1,29 @@ +GIT v1.6.4.3 Release Notes +========================== + +Fixes since v1.6.4.2 +-------------------- + +* "git clone" from an empty repository gave unnecessary error message, + even though it did everything else correctly. + +* "git cvsserver" invoked git commands via "git-foo" style, which has long + been deprecated. + +* "git fetch" and "git clone" had an extra sanity check to verify the + presense of the corresponding *.pack file before downloading *.idx + file by issuing a HEAD request. Github server however sometimes + gave 500 (Internal server error) response to HEAD even if a GET + request for *.pack file to the same URL would have succeeded, and broke + clone over HTTP from some of their repositories. As a workaround, this + verification has been removed (as it is not absolutely necessary). + +* "git grep" did not like relative pathname to refer outside the current + directory when run from a subdirectory. + +* an error message from "git push" was formatted in a very ugly way. + +* "git svn" did not quote the subversion user name correctly when + running its author-prog helper program. + +Other minor documentation updates are included. diff --git a/Documentation/RelNotes-1.6.4.4.txt b/Documentation/RelNotes-1.6.4.4.txt new file mode 100644 index 0000000000..0ead45fc72 --- /dev/null +++ b/Documentation/RelNotes-1.6.4.4.txt @@ -0,0 +1,26 @@ +GIT v1.6.4.4 Release Notes +========================== + +Fixes since v1.6.4.4 +-------------------- + +* The workaround for Github server that sometimes gave 500 (Internal server + error) response to HEAD requests in 1.6.4.3 introduced a regression that + caused re-fetching projects over http to segfault in certain cases due + to uninitialized pointer being freed. + +* "git pull" on an unborn branch used to consider anything in the work + tree and the index discardable. + +* "git diff -b/w" did not work well on the incomplete line at the end of + the file, due to an incorrect hashing of lines in the low-level xdiff + routines. + +* "git checkout-index --prefix=$somewhere" used to work when $somewhere is + a symbolic link to a directory elsewhere, but v1.6.4.2 broke it. + +* "git unpack-objects --strict", invoked when receive.fsckobjects + configuration is set in the receiving repository of "git push", did not + properly check the objects, especially the submodule links, it received. + +Other minor documentation updates are included. diff --git a/Documentation/RelNotes-1.6.4.txt b/Documentation/RelNotes-1.6.4.txt new file mode 100644 index 0000000000..7a904419f7 --- /dev/null +++ b/Documentation/RelNotes-1.6.4.txt @@ -0,0 +1,147 @@ +GIT v1.6.4 Release Notes +======================== + +With the next major release, "git push" into a branch that is +currently checked out will be refused by default. You can choose +what should happen upon such a push by setting the configuration +variable receive.denyCurrentBranch in the receiving repository. + +To ease the transition plan, the receiving repository of such a +push running this release will issue a big warning when the +configuration variable is missing. Please refer to: + + http://git.or.cz/gitwiki/GitFaq#non-bare + http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 + +for more details on the reason why this change is needed and the +transition plan. + +For a similar reason, "git push $there :$killed" to delete the branch +$killed in a remote repository $there, if $killed branch is the current +branch pointed at by its HEAD, gets a large warning. You can choose what +should happen upon such a push by setting the configuration variable +receive.denyDeleteCurrent in the receiving repository. + + +Updates since v1.6.3 +-------------------- + +(subsystems) + + * gitweb Perl style clean-up. + + * git-svn updates, including a new --authors-prog option to map author + names by invoking an external program, 'git svn reset' to unwind + 'git svn fetch', support for more than one branches, documenting + of the useful --minimize-url feature, new "git svn gc" command, etc. + +(portability) + + * We feed iconv with "UTF-8" instead of "utf8"; the former is + understood more widely. Similarly updated test scripts to use + encoding names more widely understood (e.g. use "ISO8859-1" instead + of "ISO-8859-1"). + + * Various portability fixes/workarounds for different vintages of + SunOS, IRIX, and Windows. + + * Git-over-ssh transport on Windows supports PuTTY plink and TortoisePlink. + +(performance) + + * Many repeated use of lstat() are optimized out in "checkout" codepath. + + * git-status (and underlying git-diff-index --cached) are optimized + to take advantage of cache-tree information in the index. + +(usability, bells and whistles) + + * "git add --edit" lets users edit the whole patch text to fine-tune what + is added to the index. + + * "git am" accepts StGIT series file as its input. + + * "git bisect skip" skips to a more randomly chosen place in the hope + to avoid testing a commit that is too close to a commit that is + already known to be untestable. + + * "git cvsexportcommit" learned -k option to stop CVS keywords expansion + + * "git fast-export" learned to handle history simplification more + gracefully. + + * "git fast-export" learned an option --tag-of-filtered-object to handle + dangling tags resulting from history simplification more usefully. + + * "git grep" learned -p option to show the location of the match using the + same context hunk marker "git diff" uses. + + * https transport can optionally be told that the used client + certificate is password protected, in which case it asks the + password only once. + + * "git imap-send" is IPv6 aware. + + * "git log --graph" draws graphs more compactly by using horizontal lines + when able. + + * "git log --decorate" shows shorter refnames by stripping well-known + refs/* prefix. + + * "git push $name" honors remote.$name.pushurl if present before + using remote.$name.url. In other words, the URL used for fetching + and pushing can be different. + + * "git send-email" understands quoted aliases in .mailrc files (might + have to be backported to 1.6.3.X). + + * "git send-email" can fetch the sender address from the configuration + variable "sendmail.from" (and "sendmail.<identity>.from"). + + * "git show-branch" can color its output. + + * "add" and "update" subcommands to "git submodule" learned --reference + option to use local clone with references. + + * "git submodule update" learned --rebase option to update checked + out submodules by rebasing the local changes. + + * "gitweb" can optionally use gravatar to adorn author/committer names. + +(developers) + + * A major part of the "git bisect" wrapper has moved to C. + + * Formatting with the new version of AsciiDoc 8.4.1 is now supported. + +Fixes since v1.6.3 +------------------ + +All of the fixes in v1.6.3.X maintenance series are included in this +release, unless otherwise noted. + +Here are fixes that this release has, but have not been backported to +v1.6.3.X series. + + * "git diff-tree -r -t" used to omit new or removed directories from + the output. df533f3 (diff-tree -r -t: include added/removed + directories in the output, 2009-06-13) may need to be cherry-picked + to backport this fix. + + * The way Git.pm sets up a Repository object was not friendly to callers + that chdir around. It now internally records the repository location + as an absolute path when autodetected. + + * Removing a section with "git config --remove-section", when its + section header has a variable definition on the same line, lost + that variable definition. + + * "git rebase -p --onto" used to always leave side branches of a merge + intact, even when both branches are subject to rewriting. + + * "git repack" used to faithfully follow grafts and considered true + parents recorded in the commit object unreachable from the commit. + After such a repacking, you cannot remove grafts without corrupting + the repository. + + * "git send-email" did not detect erroneous loops in alias expansion. diff --git a/Documentation/RelNotes-1.6.5.1.txt b/Documentation/RelNotes-1.6.5.1.txt new file mode 100644 index 0000000000..309ba181b2 --- /dev/null +++ b/Documentation/RelNotes-1.6.5.1.txt @@ -0,0 +1,20 @@ +GIT v1.6.5.1 Release Notes +========================== + +Fixes since v1.6.5 +------------------ + + * An corrupt pack could make codepath to read objects into an + infinite loop. + + * Download throughput display was always shown in KiB/s but on fast links + it is more appropriate to show it in MiB/s. + + * "git grep -f filename" used uninitialized variable and segfaulted. + + * "git clone -b branch" gave a wrong commit object name to post-checkout + hook. + + * "git pull" over http did not work on msys. + +Other minor documentation updates are included. diff --git a/Documentation/RelNotes-1.6.5.2.txt b/Documentation/RelNotes-1.6.5.2.txt new file mode 100644 index 0000000000..aa7ccce3a2 --- /dev/null +++ b/Documentation/RelNotes-1.6.5.2.txt @@ -0,0 +1,19 @@ +GIT v1.6.5.2 Release Notes +========================== + +Fixes since v1.6.5.1 +-------------------- + + * Installation of templates triggered a bug in busybox when using tar + implementation from it. + + * "git add -i" incorrectly ignored paths that are already in the index + if they matched .gitignore patterns. + + * "git describe --always" should have produced some output even there + were no tags in the repository, but it didn't. + + * "git ls-files" when showing tracked files incorrectly paid attention + to the exclude patterns. + +Other minor documentation updates are included. diff --git a/Documentation/RelNotes-1.6.5.3.txt b/Documentation/RelNotes-1.6.5.3.txt new file mode 100644 index 0000000000..b2fad1b22e --- /dev/null +++ b/Documentation/RelNotes-1.6.5.3.txt @@ -0,0 +1,63 @@ +Git v1.6.5.3 Release Notes +========================== + +Fixes since v1.6.5.2 +-------------------- + + * info/grafts file didn't ignore trailing CR at the end of lines. + + * Packages generated on newer FC were unreadable by older versions of + RPM as the new default is to use stronger hash. + + * output from "git blame" was unreadable when the file ended in an + incomplete line. + + * "git add -i/-p" didn't handle deletion of empty files correctly. + + * "git clone" takes up to two parameters, but did not complain when + given more arguments than necessary and silently ignored them. + + * "git cvsimport" did not read files given as command line arguments + correctly when it is run from a subdirectory. + + * "git diff --color-words -U0" didn't work correctly. + + * The handling of blank lines at the end of file by "git diff/apply + --whitespace" was inconsistent with the other kinds of errors. + They are now colored, warned against, and fixed the same way as others. + + * There was no way to allow blank lines at the end of file without + allowing extra blanks at the end of lines. You can use blank-at-eof + and blank-at-eol whitespace error class to specify them separately. + The old trailing-space error class is now a short-hand to set both. + + * "-p" option to "git format-patch" was supposed to suppress diffstat + generation, but it was broken since 1.6.1. + + * "git imap-send" did not compile cleanly with newer OpenSSL. + + * "git help -a" outside of a git repository was broken. + + * "git ls-files -i" was supposed to be inverse of "git ls-files" without -i + with respect to exclude patterns, but it was broken since 1.6.5.2. + + * "git ls-remote" outside of a git repository over http was broken. + + * "git rebase -i" gave bogus error message when the command word was + misspelled. + + * "git receive-pack" that is run in response to "git push" did not run + garbage collection nor update-server-info, but in larger hosting sites, + these almost always need to be run. To help site administrators, the + command now runs "gc --auto" and "u-s-i" by setting receive.autogc + and receive.updateserverinfo configuration variables, respectively. + + * Release notes spelled the package name with incorrect capitalization. + + * "gitweb" did not escape non-ascii characters correctly in the URL. + + * "gitweb" showed "patch" link even for merge commits. + + * "gitweb" showed incorrect links for blob line numbers in pathinfo mode. + +Other minor documentation updates are included. diff --git a/Documentation/RelNotes-1.6.5.4.txt b/Documentation/RelNotes-1.6.5.4.txt new file mode 100644 index 0000000000..e42f8b2397 --- /dev/null +++ b/Documentation/RelNotes-1.6.5.4.txt @@ -0,0 +1,32 @@ +Git v1.6.5.4 Release Notes +========================== + +Fixes since v1.6.5.3 +-------------------- + + * "git help" (without argument) used to check if you are in a directory + under git control. There was no breakage in behaviour per-se, but this + was unnecessary. + + * "git prune-packed" gave progress output even when its standard error is + not connected to a terminal; this caused cron jobs that run it to + produce crufts. + + * "git pack-objects --all-progress" is an option to ask progress output + from write-object phase _if_ progress output were to be produced, and + shouldn't have forced the progress output. + + * "git apply -p<n> --directory=<elsewhere>" did not work well for a + non-default value of n. + + * "git merge foo HEAD" was misparsed as an old-style invocation of the + command and produced a confusing error message. As it does not specify + any other branch to merge, it shouldn't be mistaken as such. We will + remove the old style "git merge <message> HEAD <commit>..." syntax in + future versions, but not in this release, + + * "git merge -m <message> <branch>..." added the standard merge message + on its own after user-supplied message, which should have overrided the + standard one. + +Other minor documentation updates are included. diff --git a/Documentation/RelNotes-1.6.5.5.txt b/Documentation/RelNotes-1.6.5.5.txt new file mode 100644 index 0000000000..ecfc57d875 --- /dev/null +++ b/Documentation/RelNotes-1.6.5.5.txt @@ -0,0 +1,49 @@ +Git v1.6.5.5 Release Notes +========================== + +Fixes since v1.6.5.4 +-------------------- + + * Manual pages can be formatted with older xmlto again. + + * GREP_OPTIONS exported from user's environment could have broken + our scripted commands. + + * In configuration files, a few variables that name paths can begin with + ~/ and ~username/ and they are expanded as expected. This is not a + bugfix but 1.6.6 will have this and without backporting users cannot + easily use the same ~/.gitconfig across versions. + + * "git diff -B -M" did the same computation to hash lines of contents + twice, and held onto memory after it has used the data in it + unnecessarily before it freed. + + * "git diff -B" and "git diff --dirstat" was not counting newly added + contents correctly. + + * "git format-patch revisions... -- path" issued an incorrect error + message that suggested to use "--" on the command line when path + does not exist in the current work tree (it is a separate matter if + it makes sense to limit format-patch with pathspecs like that + without using the --full-diff option). + + * "git grep -F -i StRiNg" did not work as expected. + + * Enumeration of available merge strategies iterated over the list of + commands in a wrong way, sometimes producing an incorrect result. + + * "git shortlog" did not honor the "encoding" header embedded in the + commit object like "git log" did. + + * Reading progress messages that come from the remote side while running + "git pull" is given precedence over reading the actual pack data to + prevent garbled progress message on the user's terminal. + + * "git rebase" got confused when the log message began with certain + strings that looked like Subject:, Date: or From: header. + + * "git reset" accidentally run in .git/ directory checked out the + work tree contents in there. + + +Other minor documentation updates are included. diff --git a/Documentation/RelNotes-1.6.5.txt b/Documentation/RelNotes-1.6.5.txt new file mode 100644 index 0000000000..ee141c19ad --- /dev/null +++ b/Documentation/RelNotes-1.6.5.txt @@ -0,0 +1,169 @@ +GIT v1.6.5 Release Notes +======================== + +In git 1.7.0, which was planned to be the release after 1.6.5, "git +push" into a branch that is currently checked out will be refused by +default. + +You can choose what should happen upon such a push by setting the +configuration variable receive.denyCurrentBranch in the receiving +repository. + +Also, "git push $there :$killed" to delete the branch $killed in a remote +repository $there, when $killed branch is the current branch pointed at by +its HEAD, will be refused by default. + +You can choose what should happen upon such a push by setting the +configuration variable receive.denyDeleteCurrent in the receiving +repository. + +To ease the transition plan, the receiving repository of such a +push running this release will issue a big warning when the +configuration variable is missing. Please refer to: + + http://git.or.cz/gitwiki/GitFaq#non-bare + http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 + +for more details on the reason why this change is needed and the +transition plan. + +Updates since v1.6.4 +-------------------- + +(subsystems) + + * various updates to gitk, git-svn and gitweb. + +(portability) + + * more improvements on mingw port. + + * mingw will also give FRSX as the default value for the LESS + environment variable when the user does not have one. + + * initial support to compile git on Windows with MSVC. + +(performance) + + * On major platforms, the system can be compiled to use with Linus's + block-sha1 implementation of the SHA-1 hash algorithm, which + outperforms the default fallback implementation we borrowed from + Mozilla. + + * Unnecessary inefficiency in deepening of a shallow repository has + been removed. + + * "git clone" does not grab objects that it does not need (i.e. + referenced only from refs outside refs/heads and refs/tags + hierarchy) anymore. + + * The "git" main binary used to link with libcurl, which then dragged + in a large number of external libraries. When using basic plumbing + commands in scripts, this unnecessarily slowed things down. We now + implement http/https/ftp transfer as a separate executable as we + used to. + + * "git clone" run locally hardlinks or copies the files in .git/ to + newly created repository. It used to give new mtime to copied files, + but this delayed garbage collection to trigger unnecessarily in the + cloned repository. We now preserve mtime for these files to avoid + this issue. + +(usability, bells and whistles) + + * Human writable date format to various options, e.g. --since=yesterday, + master@{2000.09.17}, are taught to infer some omitted input properly. + + * A few programs gave verbose "advice" messages to help uninitiated + people when issuing error messages. An infrastructure to allow + users to squelch them has been introduced, and a few such messages + can be silenced now. + + * refs/replace/ hierarchy is designed to be usable as a replacement + of the "grafts" mechanism, with the added advantage that it can be + transferred across repositories. + + * "git am" learned to optionally ignore whitespace differences. + + * "git am" handles input e-mail files that has CRLF line endings sensibly. + + * "git am" learned "--scissors" option to allow you to discard early part + of an incoming e-mail. + + * "git archive -o output.zip" works without being told what format to + use with an explicit "--format=zip".option. + + * "git checkout", "git reset" and "git stash" learned to pick and + choose to use selected changes you made, similar to "git add -p". + + * "git clone" learned a "-b" option to pick a HEAD to check out + different from the remote's default branch. + + * "git clone" learned --recursive option. + + * "git clone" from a local repository on a different filesystem used to + copy individual object files without preserving the old timestamp, giving + them extra lifetime in the new repository until they gc'ed. + + * "git commit --dry-run $args" is a new recommended way to ask "what would + happen if I try to commit with these arguments." + + * "git commit --dry-run" and "git status" shows conflicted paths in a + separate section to make them easier to spot during a merge. + + * "git cvsimport" now supports password-protected pserver access even + when the password is not taken from ~/.cvspass file. + + * "git fast-export" learned --no-data option that can be useful when + reordering commits and trees without touching the contents of + blobs. + + * "git fast-import" has a pair of new front-end in contrib/ area. + + * "git init" learned to mkdir/chdir into a directory when given an + extra argument (i.e. "git init this"). + + * "git instaweb" optionally can use mongoose as the web server. + + * "git log --decorate" can optionally be told with --decorate=full to + give the reference name in full. + + * "git merge" issued an unnecessarily scary message when it detected + that the merge may have to touch the path that the user has local + uncommitted changes to. The message has been reworded to make it + clear that the command aborted, without doing any harm. + + * "git push" can be told to be --quiet. + + * "git push" pays attention to url.$base.pushInsteadOf and uses a URL + that is derived from the URL used for fetching. + + * informational output from "git reset" that lists the locally modified + paths is made consistent with that of "git checkout $another_branch". + + * "git submodule" learned to give submodule name to scripts run with + "foreach" subcommand. + + * various subcommands to "git submodule" learned --recursive option. + + * "git submodule summary" learned --files option to compare the work + tree vs the commit bound at submodule path, instead of comparing + the index. + + * "git upload-pack", which is the server side support for "git clone" and + "git fetch", can call a new post-upload-pack hook for statistics purposes. + +(developers) + + * With GIT_TEST_OPTS="--root=/p/a/t/h", tests can be run outside the + source directory; using tmpfs may give faster turnaround. + + * With NO_PERL_MAKEMAKER set, DESTDIR= is now honoured, so you can + build for one location, and install into another location to tar it + up. + +Fixes since v1.6.4 +------------------ + +All of the fixes in v1.6.4.X maintenance series are included in this +release, unless otherwise noted. diff --git a/Documentation/RelNotes-1.6.6.txt b/Documentation/RelNotes-1.6.6.txt new file mode 100644 index 0000000000..dc55480a14 --- /dev/null +++ b/Documentation/RelNotes-1.6.6.txt @@ -0,0 +1,240 @@ +Git v1.6.6 Release Notes +======================== + +Notes on behaviour change +------------------------- + + * In this release, "git fsck" defaults to "git fsck --full" and + checks packfiles, and because of this it will take much longer to + complete than before. If you prefer a quicker check only on loose + objects (the old default), you can say "git fsck --no-full". This + has been supported by 1.5.4 and newer versions of git, so it is + safe to write it in your script even if you use slightly older git + on some of your machines. + +Preparing yourselves for compatibility issues in 1.7.0 +------------------------------------------------------ + +In git 1.7.0, which is planned to be the release after 1.6.6, there will +be a handful of behaviour changes that will break backward compatibility. + +These changes were discussed long time ago and existing behaviours have +been identified as more problematic to the userbase than keeping them for +the sake of backward compatibility. + +When necessary, transition strategy for existing users has been designed +not to force them running around setting configuration variables and +updating their scripts in order to either keep the traditional behaviour +or adjust to the new behaviour on the day their sysadmin decides to install +the new version of git. When we switched from "git-foo" to "git foo" in +1.6.0, even though the change had been advertised and the transition +guide had been provided for a very long time, the users procrastinated +during the entire transtion period, and ended up panicking on the day +their sysadmins updated their git installation. We are trying to avoid +repeating that unpleasantness in the 1.7.0 release. + +For changes decided to be in 1.7.0, commands that will be affected +have been much louder to strongly discourage such procrastination. If +you have been using recent versions of git, you would have seen +warnings issued when you exercised features whose behaviour will +change, with a clear instruction on how to keep the existing behaviour +if you want to. You hopefully are already well prepared. + +Of course, we have also been giving "this and that will change in +1.7.0; prepare yourselves" warnings in the release notes and +announcement messages for the past few releases. Let's see how well +users will fare this time. + + * "git push" into a branch that is currently checked out (i.e. pointed by + HEAD in a repository that is not bare) will be refused by default. + + Similarly, "git push $there :$killed" to delete the branch $killed + in a remote repository $there, when $killed branch is the current + branch pointed at by its HEAD, will be refused by default. + + Setting the configuration variables receive.denyCurrentBranch and + receive.denyDeleteCurrent to 'ignore' in the receiving repository + can be used to override these safety features. Versions of git + since 1.6.2 have issued a loud warning when you tried to do these + operations without setting the configuration, so repositories of + people who still need to be able to perform such a push should + already have been future proofed. + + Please refer to: + + http://git.or.cz/gitwiki/GitFaq#non-bare + http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 + + for more details on the reason why this change is needed and the + transition process that already took place so far. + + * "git send-email" will not make deep threads by default when sending a + patch series with more than two messages. All messages will be sent + as a reply to the first message, i.e. cover letter. Git 1.6.6 (this + release) will issue a warning about the upcoming default change, when + it uses the traditional "deep threading" behaviour as the built-in + default. To squelch the warning but still use the "deep threading" + behaviour, give --chain-reply-to option or set sendemail.chainreplyto + to true. + + It has been possible to configure send-email to send "shallow thread" + by setting sendemail.chainreplyto configuration variable to false. + The only thing 1.7.0 release will do is to change the default when + you haven't configured that variable. + + * "git status" will not be "git commit --dry-run". This change does not + affect you if you run the command without pathspec. + + Nobody sane found the current behaviour of "git status Makefile" useful + nor meaningful, and it confused users. "git commit --dry-run" has been + provided as a way to get the current behaviour of this command since + 1.6.5. + + * "git diff" traditionally treated various "ignore whitespace" options + only as a way to filter the patch output. "git diff --exit-code -b" + exited with non-zero status even if all changes were about changing the + ammount of whitespace and nothing else. and "git diff -b" showed the + "diff --git" header line for such a change without patch text. + + In 1.7.0, the "ignore whitespaces" will affect the semantics of the + diff operation itself. A change that does not affect anything but + whitespaces will be reported with zero exit status when run with + --exit-code, and there will not be "diff --git" header for such a + change. + + +Updates since v1.6.5 +-------------------- + +(subsystems) + + * various git-gui updates including new translations, wm states, etc. + + * git-svn updates. + + * "git fetch" over http learned a new mode that is different from the + traditional "dumb commit walker". + +(portability) + + * imap-send can be built on mingw port. + +(performance) + + * "git diff -B" has smaller memory footprint. + +(usability, bells and whistles) + + * The object replace mechanism can be bypassed with --no-replace-objects + global option given to the "git" program. + + * In configuration files, a few variables that name paths can begin with ~/ + and ~username/ and they are expanded as expected. + + * "git subcmd -h" now shows short usage help for many more subcommands. + + * "git bisect reset" can reset to an arbitrary commit. + + * "git checkout frotz" when there is no local branch "frotz" but there + is only one remote tracking branch "frotz" is taken as a request to + start the named branch at the corresponding remote tracking branch. + + * "git commit -c/-C/--amend" can be told with a new "--reset-author" option + to ignore authorship information in the commit it is taking the message + from. + + * "git describe" can be told to add "-dirty" suffix with "--dirty" option. + + * "git diff" learned --submodule option to show a list of one-line logs + instead of differences between the commit object names. + + * "git diff" learned to honor diff.color.func configuration to paint + function name hint printed on the hunk header "@@ -j,k +l,m @@" line + in the specified color. + + * "git fetch" learned --all and --multiple options, to run fetch from + many repositories, and --prune option to remove remote tracking + branches that went stale. These make "git remote update" and "git + remote prune" less necessary (there is no plan to remove "remote + update" nor "remote prune", though). + + * "git fsck" by default checks the packfiles (i.e. "--full" is the + default); you can turn it off with "git fsck --no-full". + + * "git grep" can use -F (fixed strings) and -i (ignore case) together. + + * import-tars contributed fast-import frontend learned more types of + compressed tarballs. + + * "git instaweb" knows how to talk with mod_cgid to apache2. + + * "git log --decorate" shows the location of HEAD as well. + + * "git log" and "git rev-list" learned to take revs and pathspecs from + the standard input with the new "--stdin" option. + + * "--pretty=format" option to "log" family of commands learned: + + . to wrap text with the "%w()" specifier. + . to show reflog information with "%g[sdD]" specifier. + + * "git notes" command to annotate existing commits. + + * "git merge" (and "git pull") learned --ff-only option to make it fail + if the merge does not result in a fast-forward. + + * "git mergetool" learned to use p4merge. + + * "git rebase -i" learned "reword" that acts like "edit" but immediately + starts an editor to tweak the log message without returning control to + the shell, which is done by "edit" to give an opportunity to tweak the + contents. + + * "git send-email" can be told with "--envelope-sender=auto" to use the + same address as "From:" address as the envelope sender address. + + * "git send-email" will issue a warning when it defaults to the + --chain-reply-to behaviour without being told by the user and + instructs to prepare for the change of the default in 1.7.0 release. + + * In "git submodule add <repository> <path>", <path> is now optional and + inferred from <repository> the same way "git clone <repository>" does. + + * "git svn" learned to read SVN 1.5+ and SVK merge tickets. + + * "gitweb" can optionally render its "blame" output incrementally (this + requires JavaScript on the client side). + + * Author names shown in gitweb output are links to search commits by the + author. + + +(developers) + +Fixes since v1.6.5 +------------------ + +All of the fixes in v1.6.5.X maintenance series are included in this +release, unless otherwise noted. + + * Enumeration of available merge strategies iterated over the list of + commands in a wrong way, sometimes producing an incorrect result. + Will backport by merging ed87465 (builtin-merge.c: call + exclude_cmds() correctly., 2009-11-25). + + * "git format-patch revisions... -- path" issued an incorrect error + message that suggested to use "--" on the command line when path + does not exist in the current work tree (it is a separate matter if + it makes sense to limit format-patch with pathspecs like that + without using the --full-diff option). Will backport by merging + 7e93d3b (format-patch: add test for parsing of "--", 2009-11-26). + + * "git shortlog" did not honor the "encoding" header embedded in the + commit object like "git log" did. Will backport by merging 79f7ca0 + (shortlog: respect commit encoding, 2009-11-25). + +--- +exec >/var/tmp/1 +echo O=$(git describe master) +O=v1.6.6-rc1-52-gff86bdd +git shortlog --no-merges $O..master --not maint diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches new file mode 100644 index 0000000000..76fc84d878 --- /dev/null +++ b/Documentation/SubmittingPatches @@ -0,0 +1,537 @@ +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 and should skip the full stop + - the body should provide a meaningful commit message, which: + - uses the imperative, present tense: "change", + not "changed" or "changes". + - includes motivation for the change, and contrasts + its implementation with previous behaviour + - if you want your work included in git.git, add a + "Signed-off-by: Your Name <you@example.com>" line to the + commit message (or just use the option "-s" when + 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. + +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. + + +(1) Make separate commits for logically separate changes. + +Unless your patch is really trivial, you should not be sending +out a patch that was generated between your working tree and +your commit head. Instead, always make a commit with complete +commit message and generate a series of patches from your +repository. It is a good discipline. + +Describe the technical detail of the change(s). + +If your description starts to get too long, that's a sign that you +probably need to split up your commit to finer grained pieces. +That being said, patches which plainly describe the things that +help reviewers check the patch, and future maintainers understand +the code, are the most beautiful patches. Descriptions that summarise +the point in the subject well, and describe the motivation for the +change, the approach taken by the change, and if relevant how this +differs substantially from the prior version, can be found on Usenet +archives back into the late 80's. Consider it like good Netiquette, +but for code. + +Oh, another thing. I am picky about whitespaces. Make sure your +changes do not trigger errors with the sample pre-commit hook shipped +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 + +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. + +Also, variables have to be declared at the beginning of the block +(you can check this with gcc, using the -Wdeclaration-after-statement +option). + +Another thing: NULL pointers shall be written as NULL, not as 0. + + +(2) Generate your patch using git tools out of your commits. + +git based diff tools (git, Cogito, and StGIT included) 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 +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. + +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 +corrupting your patch. Do not cut-n-paste your patch; you can +lose tabs that way if you are not careful. + +It is a common convention to prefix your subject line with +[PATCH]. This lets people easily distinguish patches from other +e-mail discussions. Use of additional markers after PATCH and +the closing bracket to mark the nature of the patch is also +encouraged. E.g. [PATCH/RFC] is often used when the patch is +not ready to be applied but it is for discussion, [PATCH v2], +[PATCH v3] etc. are often seen when you are sending an update to +what you have previously sent. + +"git format-patch" command follows the best current practice to +format the body of an e-mail message. At the beginning of the +patch should come your commit message, ending with the +Signed-off-by: lines, and a line that consists of three dashes, +followed by the diffstat information and the patch itself. If +you are forwarding a patch from somebody else, optionally, at +the beginning of the e-mail message just before the commit +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. + +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 +your e-mail client send format=flowed which would destroy +whitespaces in your patches. Many +popular e-mail applications will not always transmit a MIME +attachment as plain text, making it impossible to comment on +your code. A MIME attachment also takes a bit more time to +process. This does not decrease the likelihood of your +MIME-attached change being accepted, but it makes it more likely +that it will be postponed. + +Exception: If your mailer is mangling patches then someone may ask +you to re-send them using MIME, that is OK. + +Do not PGP sign your patch, at least for now. Most likely, your +maintainer or other people on the list would not have your PGP +key and would not bother obtaining it anyway. Your patch is not +judged by who you are; a good patch from an unknown origin has a +far better chance of being accepted than a patch from a known, +respected origin that is done poorly or does incorrect things. + +If you really really really really want to do a PGP signed +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. + +Note that your maintainer does not necessarily read everything +on the git mailing list. If your patch is for discussion first, +send it "To:" the mailing list, and optionally "cc:" him. If it +is trivially correct or after the list reached a consensus, send +it "To:" the maintainer and optionally "cc:" the list for +inclusion. + +Also note that your maintainer does not actively involve himself in +maintaining what are in contrib/ hierarchy. When you send fixes and +enhancements to them, do not forget to "cc: " the person who primarily +worked on that hierarchy in contrib/. + + +(4) 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 +smaller project it is a good discipline to follow it. + +The sign-off is a simple line at the end of the explanation for +the patch, which certifies that you wrote it or otherwise have +the right to pass it on as a open-source patch. The rules are +pretty simple: if you can certify the below: + + Developer's Certificate of Origin 1.1 + + By making a contribution to this project, I certify that: + + (a) The contribution was created in whole or in part by me and I + have the right to submit it under the open source license + indicated in the file; or + + (b) The contribution is based upon previous work that, to the best + of my knowledge, is covered under an appropriate open source + license and I have the right under that license to submit that + work with modifications, whether created in whole or in part + by me, under the same open source license (unless I am + permitted to submit under a different license), as indicated + in the file; or + + (c) The contribution was provided directly to me by some other + 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. + +then you just add a line saying + + Signed-off-by: Random J Developer <random@developer.example.org> + +This line can be automatically added by git if you run the git-commit +command with the -s option. + +Notice that you can place your own Signed-off-by: line when +forwarding somebody else's patch with the above rules for +D-C-O. Indeed you are encouraged to do so. Do not forget to +place an in-body "From: " line at the beginning to properly attribute +the change to its true author (see (2) above). + +Also notice that a real name is used in the Signed-off-by: line. Please +don't hide your real name. + +Some people also put extra tags at the end. + +"Acked-by:" says that the patch was reviewed by the person who +is more familiar with the issues and the area the patch attempts +to modify. "Tested-by:" says the patch was tested by the person +and found to have the desired effect. + +------------------------------------------------ +An ideal patch flow + +Here is an ideal patch flow for this project the current maintainer +suggests to the contributors: + + (0) You come up with an itch. You code it up. + + (1) Send it to the list and cc people who may need to know about + the change. + + The people who may need to know are the ones whose code you + are butchering. These people happen to be the ones who are + most likely to be knowledgeable enough to help you, but + they have no obligation to help you (i.e. you ask for help, + don't demand). "git log -p -- $area_you_are_modifying" would + help you find out who they are. + + (2) You get comments and suggestions for improvements. You may + even get them in a "on top of your change" patch form. + + (3) Polish, refine, and re-send to the list and the people who + spend their time to improve your patch. Go back to step (2). + + (4) The list forms consensus that the last round of your patch is + good. Send it to the list and cc the maintainer. + + (5) A topic branch is created with the patch and is merged to 'next', + and cooked further and eventually graduates to 'master'. + +In any time between the (2)-(3) cycle, the maintainer may pick it up +from the list and queue it to 'pu', in order to make it easier for +people play with it without having to pick up and apply the patch to +their trees themselves. + +------------------------------------------------ +MUA specific hints + +Some of patches I receive or pick up from the list share common +patterns of breakage. Please make sure your MUA is set up +properly not to corrupt whitespaces. Here are two common ones +I have seen: + +* Empty context lines that do not have _any_ whitespace. + +* Non empty context lines that have one extra whitespace at the + beginning. + +One test you could do yourself if your MUA is set up correctly is: + +* Send the patch to yourself, exactly the way you would, except + To: and Cc: lines, which would not contain the list and + maintainer address. + +* Save that patch to a file in UNIX mailbox format. Call it say + a.patch. + +* Try to apply to the tip of the "master" branch from the + git.git public repository: + + $ git fetch http://kernel.org/pub/scm/git/git.git master:test-apply + $ git checkout test-apply + $ git reset --hard + $ git am a.patch + +If it does not apply correctly, there can be various reasons. + +* Your patch itself does not apply cleanly. That is _bad_ but + does not have much to do with your MUA. Please rebase the + patch appropriately. + +* Your MUA corrupted your patch; "am" would complain that + the patch does not apply. Look at .git/rebase-apply/ subdirectory and + see what 'patch' file contains and check for the common + corruption patterns mentioned above. + +* While you are at it, check what are in 'info' and + 'final-commit' files as well. If what is in 'final-commit' is + not exactly what you would want to see in the commit log + message, it is very likely that your maintainer would end up + hand editing the log message when he applies your patch. + Things like "Hi, this is my first patch.\n", if you really + want to put in the patch e-mail, should come after the + three-dash line that signals the end of the commit message. + + +Pine +---- + +(Johannes Schindelin) + +I don't know how many people still use pine, but for those poor +souls it may be good to mention that the quell-flowed-text is +needed for recent versions. + +... the "no-strip-whitespace-before-send" option, too. AFAIK it +was introduced in 4.60. + +(Linus Torvalds) + +And 4.58 needs at least this. + +--- +diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1) +Author: Linus Torvalds <torvalds@g5.osdl.org> +Date: Mon Aug 15 17:23:51 2005 -0700 + + Fix pine whitespace-corruption bug + + There's no excuse for unconditionally removing whitespace from + the pico buffers on close. + +diff --git a/pico/pico.c b/pico/pico.c +--- a/pico/pico.c ++++ b/pico/pico.c +@@ -219,7 +219,9 @@ PICO *pm; + switch(pico_all_done){ /* prepare for/handle final events */ + case COMP_EXIT : /* already confirmed */ + packheader(); ++#if 0 + stripwhitespace(); ++#endif + c |= COMP_EXIT; + break; + + +(Daniel Barkalow) + +> A patch to SubmittingPatches, MUA specific help section for +> users of Pine 4.63 would be very much appreciated. + +Ah, it looks like a recent version changed the default behavior to do the +right thing, and inverted the sense of the configuration option. (Either +that or Gentoo did it.) So you need to set the +"no-strip-whitespace-before-send" option, unless the option you have is +"strip-whitespace-before-send", in which case you should avoid checking +it. + + +Thunderbird +----------- + +(A Large Angry SCM) + +By default, Thunderbird will both wrap emails as well as flag them as +being 'format=flowed', both of which will make the resulting email unusable +by git. + +Here are some hints on how to successfully submit patches inline using +Thunderbird. + +There are two different approaches. One approach is to configure +Thunderbird to not mangle patches. The second approach is to use +an external editor to keep Thunderbird from mangling the patches. + +Approach #1 (configuration): + +This recipe is current as of Thunderbird 2.0.0.19. Three steps: + 1. Configure your mail server composition as plain text + Edit...Account Settings...Composition & Addressing, + uncheck 'Compose Messages in HTML'. + 2. Configure your general composition window to not wrap + Edit..Preferences..Composition, wrap plain text messages at 0 + 3. Disable the use of format=flowed + Edit..Preferences..Advanced..Config Editor. Search for: + mailnews.send_plaintext_flowed + toggle it to make sure it is set to 'false'. + +After that is done, you should be able to compose email as you +otherwise would (cut + paste, git-format-patch | git-imap-send, etc), +and the patches should not be mangled. + +Approach #2 (external editor): + +This recipe appears to work with the current [*1*] Thunderbird from Suse. + +The following Thunderbird extensions are needed: + AboutConfig 0.5 + http://aboutconfig.mozdev.org/ + External Editor 0.7.2 + http://globs.org/articles.php?lng=en&pg=8 + +1) Prepare the patch as a text file using your method of choice. + +2) Before opening a compose window, use Edit->Account Settings to +uncheck the "Compose messages in HTML format" setting in the +"Composition & Addressing" panel of the account to be used to send the +patch. [*2*] + +3) In the main Thunderbird window, _before_ you open the compose window +for the patch, use Tools->about:config to set the following to the +indicated values: + mailnews.send_plaintext_flowed => false + mailnews.wraplength => 0 + +4) Open a compose window and click the external editor icon. + +5) In the external editor window, read in the patch file and exit the +editor normally. + +6) Back in the compose window: Add whatever other text you wish to the +message, complete the addressing and subject fields, and press send. + +7) Optionally, undo the about:config/account settings changes made in +steps 2 & 3. + + +[Footnotes] +*1* Version 1.0 (20041207) from the MozillaThunderbird-1.0-5 rpm of Suse +9.3 professional updates. + +*2* It may be possible to do this with about:config and the following +settings but I haven't tried, yet. + mail.html_compose => false + mail.identity.default.compose_html => false + mail.identity.id?.compose_html => false + +(Lukas Sandström) + +There is a script in contrib/thunderbird-patch-inline which can help +you include patches with Thunderbird in an easy way. To use it, do the +steps above and then use the script as the external editor. + +Gnus +---- + +'|' in the *Summary* buffer can be used to pipe the current +message to an external program, and this is a handy way to drive +"git am". However, if the message is MIME encoded, what is +piped into the program is the representation you see in your +*Article* buffer after unwrapping MIME. This is often not what +you would want for two reasons. It tends to screw up non ASCII +characters (most notably in people's names), and also +whitespaces (fatal in patches). Running 'C-u g' to display the +message in raw form before using '|' to run the pipe can work +this problem around. + + +KMail +----- + +This should help you to submit patches inline using KMail. + +1) Prepare the patch as a text file. + +2) Click on New Mail. + +3) Go under "Options" in the Composer window and be sure that +"Word wrap" is not set. + +4) Use Message -> Insert file... and insert the patch. + +5) Back in the compose window: add whatever other text you wish to the +message, complete the addressing and subject fields, and press send. + + +Gmail +----- + +GMail does not appear to have any way to turn off line wrapping in the web +interface, so this will mangle any emails that you send. You can however +use any IMAP email client to connect to the google imap server, and forward +the emails through that. Just make sure to disable line wrapping in that +email client. Alternatively, use "git send-email" instead. + +Submitting properly formatted patches via Gmail is simple now that +IMAP support is available. First, edit your ~/.gitconfig to specify your +account settings: + +[imap] + folder = "[Gmail]/Drafts" + host = imaps://imap.gmail.com + user = user@gmail.com + pass = p4ssw0rd + port = 993 + sslverify = false + +You might need to instead use: folder = "[Google Mail]/Drafts" if you get an error +that the "Folder doesn't exist". + +Next, ensure that your Gmail settings are correct. In "Settings" the +"Use Unicode (UTF-8) encoding for outgoing messages" should be checked. + +Once your commits are ready to send to the mailing list, run the following +command to send the patch emails to your Gmail Drafts folder. + + $ git format-patch -M --stdout origin/master | git imap-send + +Go to your Gmail account, open the Drafts folder, find the patch email, fill +in the To: and CC: fields and send away! + diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf new file mode 100644 index 0000000000..87a90f2c3f --- /dev/null +++ b/Documentation/asciidoc.conf @@ -0,0 +1,92 @@ +## linkgit: macro +# +# Usage: linkgit:command[manpage-section] +# +# Note, {0} is the manpage section, while {target} is the command. +# +# Show GIT link as: <command>(<section>); if section is defined, else just show +# the command. + +[macros] +(?su)[\\]?(?P<name>linkgit):(?P<target>\S*?)\[(?P<attrlist>.*?)\]= + +[attributes] +asterisk=* +plus=+ +caret=^ +startsb=[ +endsb=] +tilde=~ +backtick=` + +ifdef::backend-docbook[] +[linkgit-inlinemacro] +{0%{target}} +{0#<citerefentry>} +{0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>} +{0#</citerefentry>} +endif::backend-docbook[] + +ifdef::backend-docbook[] +ifndef::git-asciidoc-no-roff[] +# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this. +# v1.72 breaks with this because it replaces dots not in roff requests. +[listingblock] +<example><title>{title}</title> +<literallayout> +ifdef::doctype-manpage[] + .ft C +endif::doctype-manpage[] +| +ifdef::doctype-manpage[] + .ft +endif::doctype-manpage[] +</literallayout> +{title#}</example> +endif::git-asciidoc-no-roff[] + +ifdef::git-asciidoc-no-roff[] +ifdef::doctype-manpage[] +# The following two small workarounds insert a simple paragraph after screen +[listingblock] +<example><title>{title}</title> +<literallayout> +| +</literallayout><simpara></simpara> +{title#}</example> + +[verseblock] +<formalpara{id? id="{id}"}><title>{title}</title><para> +{title%}<literallayout{id? id="{id}"}> +{title#}<literallayout> +| +</literallayout> +{title#}</para></formalpara> +{title%}<simpara></simpara> +endif::doctype-manpage[] +endif::git-asciidoc-no-roff[] +endif::backend-docbook[] + +ifdef::doctype-manpage[] +ifdef::backend-docbook[] +[header] +template::[header-declarations] +<refentry> +<refmeta> +<refentrytitle>{mantitle}</refentrytitle> +<manvolnum>{manvolnum}</manvolnum> +<refmiscinfo class="source">Git</refmiscinfo> +<refmiscinfo class="version">{git_version}</refmiscinfo> +<refmiscinfo class="manual">Git Manual</refmiscinfo> +</refmeta> +<refnamediv> + <refname>{manname}</refname> + <refpurpose>{manpurpose}</refpurpose> +</refnamediv> +endif::backend-docbook[] +endif::doctype-manpage[] + +ifdef::backend-xhtml11[] +[linkgit-inlinemacro] +<a href="{target}.html">{target}{0?({0})}</a> +endif::backend-xhtml11[] diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt new file mode 100644 index 0000000000..1625ffce6a --- /dev/null +++ b/Documentation/blame-options.txt @@ -0,0 +1,111 @@ +-b:: + Show blank SHA-1 for boundary commits. This can also + be controlled via the `blame.blankboundary` config option. + +--root:: + Do not treat root commits as boundaries. This can also be + 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 ++ +This is only valid for <end> and will specify a number +of lines before or after the line given by <start>. ++ + +-l:: + Show long rev (Default: off). + +-t:: + Show raw timestamp (Default: off). + +-S <revs-file>:: + Use revisions from revs-file instead of calling linkgit:git-rev-list[1]. + +--reverse:: + Walk history forward instead of backward. Instead of showing + the revision in which a line appeared, this shows the last + revision in which a line has existed. This requires a range of + revision like START..END where the path to blame exists in + START. + +-p:: +--porcelain:: + Show in a format designed for machine consumption. + +--incremental:: + Show the result incrementally in a format designed for + machine consumption. + +--encoding=<encoding>:: + Specifies the encoding used to output author names + and commit summaries. Setting it to `none` makes blame + output unconverted data. For more information see the + discussion about encoding in the linkgit:git-log[1] + manual page. + +--contents <file>:: + When <rev> is not specified, the command annotates the + changes starting backwards from the working tree copy. + This flag makes the command pretend as if the working + tree copy has the contents of the named file (specify + `-` to make the command read from the standard input). + +--date <format>:: + The value is one of the following alternatives: + {relative,local,default,iso,rfc,short}. If --date is not + provided, the value of the blame.date config variable is + used. If the blame.date config variable is also not set, the + iso format is used. For more information, See the discussion + of the --date option at linkgit:git-log[1]. + +-M|<num>|:: + Detect moving lines in the file as well. When a commit + moves a block of lines in a file (e.g. the original file + has A and then B, and the commit changes it to B and + then A), the traditional 'blame' algorithm typically blames + the lines that were moved up (i.e. B) to the parent and + assigns blame to the lines that were moved down (i.e. A) + to the child commit. With this option, both groups of lines + are blamed on the parent. ++ +<num> is optional but it is the lower bound on the number of +alphanumeric characters that git must detect as moving +within a file for it to associate those lines with the parent +commit. + +-C|<num>|:: + In addition to `-M`, detect lines copied from other + files that were modified in the same commit. This is + useful when you reorganize your program and move code + around across files. When this option is given twice, + the command additionally looks for copies from all other + files in the parent for the commit that creates the file. ++ +<num> is optional but it is the lower bound on the number of +alphanumeric characters that git must detect as moving +between files for it to associate those lines with the parent +commit. + +-h:: +--help:: + Show help message. diff --git a/Documentation/build-docdep.perl b/Documentation/build-docdep.perl new file mode 100755 index 0000000000..ba4205e030 --- /dev/null +++ b/Documentation/build-docdep.perl @@ -0,0 +1,46 @@ +#!/usr/bin/perl + +my %include = (); +my %included = (); + +for my $text (<*.txt>) { + open I, '<', $text || die "cannot read: $text"; + while (<I>) { + if (/^include::/) { + chomp; + s/^include::\s*//; + s/\[\]//; + $include{$text}{$_} = 1; + $included{$_} = 1; + } + } + close I; +} + +# Do we care about chained includes??? +my $changed = 1; +while ($changed) { + $changed = 0; + while (my ($text, $included) = each %include) { + for my $i (keys %$included) { + # $text has include::$i; if $i includes $j + # $text indirectly includes $j. + if (exists $include{$i}) { + for my $j (keys %{$include{$i}}) { + if (!exists $include{$text}{$j}) { + $include{$text}{$j} = 1; + $included{$j} = 1; + $changed = 1; + } + } + } + } + } +} + +while (my ($text, $included) = each %include) { + if (! exists $included{$text} && + (my $base = $text) =~ s/\.txt$//) { + print "$base.html $base.xml : ", join(" ", keys %$included), "\n"; + } +} diff --git a/Documentation/cat-texi.perl b/Documentation/cat-texi.perl new file mode 100755 index 0000000000..828ec62554 --- /dev/null +++ b/Documentation/cat-texi.perl @@ -0,0 +1,42 @@ +#!/usr/bin/perl -w + +my @menu = (); +my $output = $ARGV[0]; + +open TMP, '>', "$output.tmp"; + +while (<STDIN>) { + next if (/^\\input texinfo/../\@node Top/); + next if (/^\@bye/ || /^\.ft/); + if (s/^\@top (.*)/\@node $1,,,Top/) { + push @menu, $1; + } + s/\(\@pxref{\[(URLS|REMOTES)\]}\)//; + print TMP; +} +close TMP; + +printf '\input texinfo +@setfilename gitman.info +@documentencoding UTF-8 +@dircategory Development +@direntry +* Git Man Pages: (gitman). Manual pages for Git revision control system +@end direntry +@node Top,,, (dir) +@top Git Manual Pages +@documentlanguage en +@menu +', $menu[0]; + +for (@menu) { + print "* ${_}::\n"; +} +print "\@end menu\n"; +open TMP, '<', "$output.tmp"; +while (<TMP>) { + print; +} +close TMP; +print "\@bye\n"; +unlink "$output.tmp"; diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl new file mode 100755 index 0000000000..04f99778d8 --- /dev/null +++ b/Documentation/cmd-list.perl @@ -0,0 +1,74 @@ +#!/usr/bin/perl -w + +use File::Compare qw(compare); + +sub format_one { + my ($out, $nameattr) = @_; + my ($name, $attr) = @$nameattr; + my ($state, $description); + $state = 0; + open I, '<', "$name.txt" or die "No such file $name.txt"; + while (<I>) { + if (/^NAME$/) { + $state = 1; + next; + } + if ($state == 1 && /^----$/) { + $state = 2; + next; + } + next if ($state != 2); + chomp; + $description = $_; + last; + } + close I; + if (!defined $description) { + die "No description found in $name.txt"; + } + if (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) { + print $out "linkgit:$name\[1\]::\n\t"; + if ($attr =~ / deprecated /) { + print $out "(deprecated) "; + } + print $out "$text.\n\n"; + } + else { + die "Description does not match $name: $description"; + } +} + +my %cmds = (); +for (sort <>) { + next if /^#/; + + chomp; + my ($name, $cat, $attr) = /^(\S+)\s+(.*?)(?:\s+(.*))?$/; + $attr = '' unless defined $attr; + push @{$cmds{$cat}}, [$name, " $attr "]; +} + +for my $cat (qw(ancillaryinterrogators + ancillarymanipulators + mainporcelain + plumbinginterrogators + plumbingmanipulators + synchingrepositories + foreignscminterface + purehelpers + synchelpers)) { + my $out = "cmds-$cat.txt"; + open O, '>', "$out+" or die "Cannot open output file $out+"; + for (@{$cmds{$cat}}) { + format_one(\*O, $_); + } + close O; + + if (-f "$out" && compare("$out", "$out+") == 0) { + unlink "$out+"; + } + else { + print STDERR "$out\n"; + rename "$out+", "$out"; + } +} diff --git a/Documentation/config.txt b/Documentation/config.txt new file mode 100644 index 0000000000..a1e36d7e42 --- /dev/null +++ b/Documentation/config.txt @@ -0,0 +1,1617 @@ +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 +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 +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. + +Syntax +~~~~~~ + +The syntax is fairly flexible and permissive; whitespaces are mostly +ignored. The '#' and ';' characters begin comments to the end of line, +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 +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. + +Sections can be further divided into subsections. To begin a subsection +put its name in double quotes, separated by space from the section name, +in the section header, like in the example below: + +-------- + [section "subsection"] + +-------- + +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 +lines. Variables may belong directly to a section or to a given subsection. +You can have `[section]` if you have `[section "subsection"]`, but you +don't need to. + +There is also a case insensitive alternative `[section.subsection]` syntax. +In this syntax, subsection names follow the same restrictions as for section +names. + +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, +0/1, 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 `\`. + +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. + +Variable values ending in a `\` are continued on the next line in the +customary UNIX fashion. + +Some variables may require a special value format. + +Example +~~~~~~~ + + # Core variables + [core] + ; Don't trust file modes + filemode = false + + # Our diff algorithm + [diff] + external = /usr/local/bin/diff-wrapper + renames = true + + [branch "devel"] + remote = origin + merge = refs/heads/devel + + # Proxy settings + [core] + gitProxy="ssh" for "kernel.org" + gitProxy=default-proxy ; for the rest + +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. + +advice.*:: + When set to 'true', display the given optional help message. + When set to 'false', do not display. The configuration variables + are: ++ +-- + pushNonFastForward:: + Advice shown when linkgit:git-push[1] refuses + non-fast-forward refs. Default: true. + statusHints:: + Directions on how to stage/unstage/add shown in the + output of linkgit:git-status[1] and the template shown + when writing commit messages. Default: true. + commitBeforeMerge:: + Advice shown when linkgit:git-merge[1] refuses to + merge to avoid overwritting local changes. + Default: true. +-- + +core.fileMode:: + If false, the executable bit differences between the index and + the working copy are ignored; useful on broken filesystems like FAT. + See linkgit:git-update-index[1]. ++ +The default is true, except linkgit:git-clone[1] or linkgit:git-init[1] +will probe and set core.fileMode false if appropriate when the +repository is created. + +core.ignoreCygwinFSTricks:: + This option is only used by Cygwin implementation of Git. If false, + the Cygwin stat() and lstat() functions are used. This may be useful + if your repository consists of a few separate directories joined in + one hierarchy using Cygwin mount. If true, Git uses native Win32 API + whenever it is possible and falls back to Cygwin functions only to + handle symbol links. The native mode is more than twice faster than + normal Cygwin l/stat() functions. True by default, unless core.filemode + is true, in which case ignoreCygwinFSTricks is ignored as Cygwin's + POSIX emulation is required to support core.filemode. + +core.ignorecase:: + If true, this option enables various workarounds to enable + git to work better on filesystems that are not case sensitive, + like FAT. For example, if a directory listing finds + "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 +is created. + +core.trustctime:: + If false, the ctime differences between the index and the + working copy are ignored; useful when the inode change time + is regularly modified by something outside Git (file system + crawlers and some backup systems). + See linkgit:git-update-index[1]. True by default. + +core.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 + pathname in a double-quote pair and with backslashes the + same way strings in C source code are quoted. If this + variable is set to false, the bytes higher than 0x80 are + not quoted but output as verbatim. Note that double + quote, backslash and control characters are always + quoted without `-z` regardless of the setting of this + variable. + +core.autocrlf:: + If true, makes git convert `CRLF` at the end of lines in text files to + `LF` when reading from the filesystem, and convert in reverse when + writing to the filesystem. The variable can be set to + 'input', in which case the conversion happens only while + reading from the filesystem but files are written out with + `LF` at the end of lines. A file is considered + "text" (i.e. be subjected to the autocrlf mechanism) based on + the file's `crlf` attribute, or if `crlf` is unspecified, + based on the file's contents. See linkgit:gitattributes[5]. + +core.safecrlf:: + If true, makes git check if converting `CRLF` as controlled by + `core.autocrlf` is reversible. Git will verify if a command + modifies a file in the work tree either directly or indirectly. + For example, committing a file followed by checking out the + same file should yield the original file in the work tree. If + this is not the case for the current setting of + `core.autocrlf`, git will reject the file. The variable can + be set to "warn", in which case git will only warn about an + irreversible conversion but continue the operation. ++ +CRLF conversion bears a slight chance of corrupting data. +autocrlf=true will convert CRLF to LF during commit and LF to +CRLF during checkout. A file that contains a mixture of LF and +CRLF before the commit cannot be recreated by git. For text +files this is the right thing to do: it corrects line endings +such that we have only LF line endings in the repository. +But for binary files that are accidentally classified as text the +conversion can corrupt data. ++ +If you recognize such corruption early you can easily fix it by +setting the conversion type explicitly in .gitattributes. Right +after committing you still have the original file in your work +tree and this file is not yet corrupted. You can explicitly tell +git that this file is binary and git will handle the file +appropriately. ++ +Unfortunately, the desired effect of cleaning up text files with +mixed line endings and the undesired effect of corrupting binary +files cannot be distinguished. In both cases CRLFs are removed +in an irreversible way. For text files this is the right thing +to do because CRLFs are line endings, while for binary files +converting CRLFs corrupts data. ++ +Note, this safety check does not mean that a checkout will generate a +file identical to the original file for a different setting of +`core.autocrlf`, but only for the current one. For example, a text +file with `LF` would be accepted with `core.autocrlf=input` and could +later be checked out with `core.autocrlf=true`, in which case the +resulting file would contain `CRLF`, although the original file +contained `LF`. However, in both work trees the line endings would be +consistent, that is either all `LF` or all `CRLF`, but never mixed. A +file with mixed line endings would be reported by the `core.safecrlf` +mechanism. + +core.symlinks:: + If false, symbolic links are checked out as small plain files that + contain the link text. linkgit:git-update-index[1] and + linkgit:git-add[1] will not change the recorded type to regular + file. Useful on filesystems like FAT that do not support + symbolic links. ++ +The default is true, except linkgit:git-clone[1] or linkgit:git-init[1] +will probe and set core.symlinks false if appropriate when the repository +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 + 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; + the first match wins. ++ +Can be overridden by the 'GIT_PROXY_COMMAND' environment variable +(which always applies universally, without the special "for" +handling). ++ +The special string `none` can be used as the proxy command to +specify that no proxy be used for a given domain pattern. +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 copy, 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. + +core.preferSymlinkRefs:: + Instead of the default "symref" format for HEAD + and other symbolic reference files, use symbolic links. + This is sometimes needed to work with old scripts that + expect HEAD to be a symbolic link. + +core.bare:: + If true this repository is assumed to be 'bare' and has no + working directory associated with it. If this is the case a + number of commands that require a working directory will be + disabled, such as linkgit:git-add[1] or linkgit:git-merge[1]. ++ +This setting is automatically guessed by linkgit:git-clone[1] or +linkgit:git-init[1] when the repository was created. By default a +repository that ends in "/.git" is assumed to be not bare (bare = +false), while all other repositories are assumed to be bare (bare += true). + +core.worktree:: + 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 be overridden by the GIT_WORK_TREE environment + variable and the '--work-tree' command line option. It can be + a absolute path or relative path to the directory specified by + --git-dir or GIT_DIR. + Note: If --git-dir or GIT_DIR are specified but none of + --work-tree, GIT_WORK_TREE and core.worktree is specified, + the current working directory is regarded as the top directory + of your 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 + 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. ++ +This information can be used to determine what commit +was the tip of a branch "2 days ago". ++ +This value is true by default in a repository that has +a working directory associated with it, and false by +default in a bare repository. + +core.repositoryFormatVersion:: + Internal variable identifying the repository format and layout + version. + +core.sharedRepository:: + When 'group' (or 'true'), the repository is made shareable between + 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 + 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 + requested parts of the user's umask value). Examples: '0660' will make + the repo read/write-able for the owner and group, but inaccessible to + others (equivalent to 'group' unless umask is e.g. '0022'). '0640' is a + repository that is group-readable but not group-writable. + 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. + +core.compression:: + An integer -1..9, indicating a default compression level. + -1 is the zlib default. 0 means no compression, + and 1..9 are various speed/size tradeoffs, 9 being slowest. + If set, this provides a default to other compression variables, + such as 'core.loosecompression' and 'pack.compression'. + +core.loosecompression:: + An integer -1..9, indicating the compression level for objects that + are not in a pack file. -1 is the zlib default. 0 means no + compression, and 1..9 are various speed/size tradeoffs, 9 being + slowest. If not set, defaults to core.compression. If that is + not set, defaults to 1 (best speed). + +core.packedGitWindowSize:: + Number of bytes of a pack file to map into memory in a + single mapping operation. Larger window sizes may allow + your system to process a smaller number of large pack files + more quickly. Smaller window sizes will negatively affect + performance due to increased calls to the operating system's + memory manager, but may improve performance when accessing + a large number of large pack files. ++ +Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32 +MiB on 32 bit platforms and 1 GiB on 64 bit platforms. This should +be reasonable for all users/operating systems. You probably do +not need to adjust this value. ++ +Common unit suffixes of 'k', 'm', or 'g' are supported. + +core.packedGitLimit:: + Maximum number of bytes to map simultaneously into memory + from pack files. If Git needs to access more than this many + bytes at once to complete an operation it will unmap existing + regions to reclaim virtual address space within the process. ++ +Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms. +This should be reasonable for all users/operating systems, except on +the largest projects. You probably do not need to adjust this value. ++ +Common unit suffixes of 'k', 'm', or 'g' are supported. + +core.deltaBaseCacheLimit:: + Maximum number of bytes to reserve for caching base objects + that multiple deltafied objects reference. By storing the + entire decompressed base objects in a cache Git is able + to avoid unpacking and decompressing frequently used base + objects multiple times. ++ +Default is 16 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. ++ +Common unit suffixes of 'k', 'm', or 'g' are supported. + +core.excludesfile:: + In addition to '.gitignore' (per-directory) and + '.git/info/exclude', git looks into this file for patterns + of files which are not meant to be tracked. "{tilde}/" is expanded + to the value of `$HOME` and "{tilde}user/" to the specified user's + home directory. See linkgit:gitignore[5]. + +core.editor:: + Commands such as `commit` and `tag` that lets you edit + messages by launching an editor uses the value of this + variable when it is set, and the environment variable + `GIT_EDITOR` is not set. See linkgit:git-var[1]. + +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`. + +core.whitespace:: + A comma separated list of common whitespace problems to + notice. 'git-diff' will use `color.diff.whitespace` to + highlight them, and 'git-apply --whitespace=error' will + consider them as errors. You can prefix `-` to disable + any of them (e.g. `-trailing-space`): ++ +* `blank-at-eol` treats trailing whitespaces at the end of the line + as an error (enabled by default). +* `space-before-tab` treats a space character that appears immediately + before a tab character in the initial indent part of the line as an + error (enabled by default). +* `indent-with-non-tab` treats a line that is indented with 8 or more + space characters as an error (not enabled by default). +* `blank-at-eof` treats blank lines added at the end of file as an error + (enabled by default). +* `trailing-space` is a short-hand to cover both `blank-at-eol` and + `blank-at-eof`. +* `cr-at-eol` treats a carriage-return at the end of line as + part of the line terminator, i.e. with it, `trailing-space` + does not trigger if the character before such a carriage-return + is not a whitespace (not enabled by default). + +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 +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:: + 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 +index comparison to the filesystem data in parallel, allowing +overlapping IO's. + +core.createObject:: + You can set this to 'link', in which case a hardlink followed by + a delete of the source are used to make sure that object creation + will not overwrite existing objects. ++ +On some file system/operating system combinations, this is unreliable. +Set this config setting to 'rename' there; However, This will remove the +check that makes sure that existing object files will not get overwritten. + +core.notesRef:: + When showing commit messages, also show notes which are stored in + the given ref. This ref is expected to contain files named + after the full SHA-1 of the commit they annotate. ++ +If such a file exists in the given ref, the referenced blob is read, and +appended to the commit message, separated by a "Notes:" line. If the +given ref itself does not exist, it is not an error, but means that no +notes should be printed. ++ +This setting defaults to "refs/notes/commits", and can be overridden by +the `GIT_NOTES_REF` environment variable. + +add.ignore-errors:: + 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]. + +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 + spaces, the usual shell quoting and escaping is supported. + quote pair and 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 +"alias.new = !gitk --all --not ORIG_HEAD", the invocation +"git new" is equivalent to running the shell command +"gitk --all --not ORIG_HEAD". Note that shell commands will be +executed from the top-level directory of a repository, which may +not necessarily be the current directory. + +apply.ignorewhitespace:: + When set to 'change', tells 'git-apply' to ignore changes in + whitespace, in the same way as the '--ignore-space-change' + option. + When set to one of: no, none, never, false tells 'git-apply' to + respect all whitespace differences. + See linkgit:git-apply[1]. + +apply.whitespace:: + Tells 'git-apply' how to handle whitespaces, in the same way + as the '--whitespace' option. See linkgit:git-apply[1]. + +branch.autosetupmerge:: + Tells 'git-branch' and 'git-checkout' to setup 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, + this behavior can be chosen per-branch using the `--track` + and `--no-track` options. The valid settings are: `false` -- no + automatic setup is done; `true` -- automatic setup is done when the + starting point is a remote branch; `always` -- automatic setup is + done when the starting point is either a local branch or remote + branch. This option defaults to true. + +branch.autosetuprebase:: + When a new branch is created with 'git-branch' or 'git-checkout' + 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 + other local branches. + When `remote`, rebase is set to true for tracked branches of + remote branches. + When `always`, rebase will be set to true for all tracking + branches. + 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. + +branch.<name>.merge:: + Defines, together with branch.<name>.remote, the upstream branch + for the given branch. It tells 'git-fetch'/'git-pull' which + branch to merge and can also affect 'git-push' (see push.default). + When in branch <name>, it tells 'git-fetch' the default + refspec to be marked for merging in FETCH_HEAD. The value is + handled like the remote part of a refspec, and must match a + ref which is fetched from the remote given by + "branch.<name>.remote". + The merge information is used by 'git-pull' (which at first calls + 'git-fetch') to lookup the default branch for merging. Without + this option, 'git-pull' defaults to merge the first refspec fetched. + 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>.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 + supported. + +branch.<name>.rebase:: + When true, rebase the branch <name> on top of the fetched branch, + instead of merging the default branch from the default remote when + "git pull" is run. + *NOTE*: this is a possibly dangerous operation; do *not* use + it unless you understand the implications (see linkgit:git-rebase[1] + for details). + +browser.<tool>.cmd:: + Specify the command to invoke the specified browser. The + specified command is evaluated in shell with the URLs passed + as arguments. (See linkgit:git-web--browse[1].) + +browser.<tool>.path:: + Override the path for the given tool that may be used to + browse HTML help (see '-w' option in linkgit:git-help[1]) or a + working repository in gitweb (see linkgit:git-instaweb[1]). + +clean.requireForce:: + A boolean to make git-clean do nothing unless given -f + or -n. Defaults to true. + +color.branch:: + A boolean to enable/disable color in the output of + linkgit:git-branch[1]. May be set to `always`, + `false` (or `never`) or `auto` (or `true`), in which case colors are used + only when the output is to a terminal. Defaults to false. + +color.branch.<slot>:: + Use customized color for branch coloration. `<slot>` is one of + `current` (the current branch), `local` (a local branch), + `remote` (a tracking branch in refs/remotes/), `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:: + When set to `always`, always use colors in patch. + When false (or `never`), never. When set to `true` or `auto`, use + colors only when the output is to the terminal. Defaults to false. + +color.diff.<slot>:: + Use customized color for diff colorization. `<slot>` specifies + which part of the patch to use the specified color, and is one + of `plain` (context text), `meta` (metainformation), `frag` + (hunk header), '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>. + +color.grep:: + When set to `always`, always highlight matches. When `false` (or + `never`), never. When set to `true` or `auto`, use color only + when the output is written to the terminal. Defaults to `false`. + +color.grep.external:: + The string value of this variable is passed to an external 'grep' + command as a command line option if match highlighting is turned + on. If set to an empty string, no option is passed at all, + turning off coloring for external 'grep' calls; this is the default. + For GNU grep, set it to `--color=always` to highlight matches even + when a pager is used. + +color.grep.match:: + Use customized color for matches. The value of this variable + may be specified as in color.branch.<slot>. It is passed using + the environment variables 'GREP_COLOR' and 'GREP_COLORS' when + calling an external 'grep'. + +color.interactive:: + When set to `always`, always use colors for interactive prompts + and displays (such as those used by "git-add --interactive"). + When false (or `never`), never. When set to `true` or `auto`, use + colors only when the output is to the terminal. Defaults to false. + +color.interactive.<slot>:: + Use customized color for 'git-add --interactive' + output. `<slot>` may be `prompt`, `header`, `help` or `error`, for + four distinct types of normal output from interactive + commands. The values of these variables may be specified as + in color.branch.<slot>. + +color.pager:: + A boolean to enable/disable colored output when the pager is in + use (default is true). + +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 + only when the output is to a terminal. Defaults to false. + +color.status:: + A boolean to enable/disable color in the output of + linkgit:git-status[1]. May be set to `always`, + `false` (or `never`) or `auto` (or `true`), in which case colors are used + only when the output is to a terminal. Defaults to false. + +color.status.<slot>:: + Use customized color for status colorization. `<slot>` is + 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), or + `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>. + +color.ui:: + When set to `always`, always use colors in all git commands which + are capable of colored output. When false (or `never`), never. When + set to `true` or `auto`, use colors only when the output is to the + terminal. When more specific variables of color.* are set, they always + take precedence over this setting. Defaults to false. + +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 + specified user's home directory. + +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 + update the cached stat information for paths whose + contents in the work tree match the contents in the + index. This option defaults to true. Note that this + affects only 'git-diff' Porcelain, and not lower level + 'diff' commands, such as 'git-diff-files'. + +diff.external:: + If this config variable is set, diff generation is not + performed using the internal diff machinery, but using the + given command. Can be overridden with the `GIT_EXTERNAL_DIFF' + environment variable. The command is called with parameters + as described under "git Diffs" in linkgit:git[1]. Note: if + you want to use an external diff program only on a subset of + your files, you might want to use linkgit:gitattributes[5] instead. + +diff.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 + the order of the prefixes: +'git-diff';; + compares the (i)ndex and the (w)ork tree; +'git-diff HEAD';; + compares a (c)ommit and the (w)ork tree; +'git diff --cached';; + compares a (c)ommit and the (i)ndex; +'git-diff HEAD:file1 file2';; + compares an (o)bject and a (w)ork tree entity; +'git diff --no-index a b';; + compares two non-git things (1) and (2). + +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 + will enable basic rename detection. If set to "copies" or + "copy", it will detect copies, as well. + +diff.suppressBlankEmpty:: + A boolean to inhibit the standard behavior of printing a space + before each empty output line. Defaults to false. + +diff.tool:: + Controls which diff tool is used. `diff.tool` overrides + `merge.tool` when used by linkgit:git-difftool[1] and has + the same valid values as `merge.tool` minus "tortoisemerge" + and plus "kompare". + +difftool.<tool>.path:: + Override the path for the given tool. This is useful in case + your tool is not in the PATH. + +difftool.<tool>.cmd:: + Specify the command to invoke the specified diff tool. + The specified command is evaluated in shell with the following + variables available: 'LOCAL' is set to the name of the temporary + file containing the contents of the diff pre-image and 'REMOTE' + is set to the name of the temporary file containing the contents + of the diff post-image. + +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.unpackLimit:: + 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 + exceeds this limit then the received pack will be stored as + a pack, after adding any missing delta bases. Storing the + pack from a push can make the push operation complete faster, + especially on slow filesystems. If not set, the value of + `transfer.unpackLimit` is used instead. + +format.attach:: + Enable multipart/mixed attachments as the default for + 'format-patch'. The value can also be a double quoted string + which will enable attachments as the default and set the + value as the boundary. See the --attach option in + linkgit:git-format-patch[1]. + +format.numbered:: + A boolean which can enable or disable sequence numbers in patch + subjects. It defaults to "auto" which enables it only if there + is more than one patch. It can be enabled or disabled for all + messages by setting it to "true" or "false". See --numbered + option in linkgit:git-format-patch[1]. + +format.headers:: + Additional email headers to include in a patch to be submitted + by mail. See linkgit:git-format-patch[1]. + +format.cc:: + Additional "Cc:" headers to include in a patch to be submitted + by mail. See the --cc option in linkgit:git-format-patch[1]. + +format.subjectprefix:: + The default for format-patch is to output files with the '[PATCH]' + subject prefix. Use this variable to change that prefix. + +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 + include the dot if you want it). + +format.pretty:: + The default pretty format for log/show/whatchanged command, + See linkgit:git-log[1], linkgit:git-show[1], + linkgit:git-whatchanged[1]. + +format.thread:: + The default threading style for 'git-format-patch'. Can be + either a boolean value, `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` 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. + +gc.aggressiveWindow:: + The window size parameter used in the delta compression + algorithm used by 'git-gc --aggressive'. This defaults + to 10. + +gc.auto:: + When there are approximately more than this many loose + objects in the repository, `git gc --auto` will pack them. + Some Porcelain commands use this command to perform a + light-weight garbage collection from time to time. The + default value is 6700. Setting this to 0 disables it. + +gc.autopacklimit:: + When there are more than this many packs that are not + marked with `*.keep` file in the repository, `git gc + --auto` consolidates them into one larger pack. The + default value is 50. Setting this to 0 disables it. + +gc.packrefs:: + 'git-gc' does not run `git pack-refs` in a bare repository by + default so that older dumb-transport clients can still fetch + from the repository. Setting this to `true` lets 'git-gc' + to run `git pack-refs`. Setting this to `false` tells + 'git-gc' never to run `git pack-refs`. The default setting is + `notbare`. Enable it only when you know you do not have to + support such clients. The default setting will change to `true` + at some stage, and setting this to `false` will continue to + prevent `git pack-refs` from being run from 'git-gc'. + +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:: + 'git-reflog expire' removes reflog entries older than + this time; defaults to 90 days. + +gc.reflogexpireunreachable:: + 'git-reflog expire' removes reflog entries older than + this time and are not reachable from the current tip; + defaults to 30 days. + +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:: + 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:: + Append this string to each commit message. Set to empty string + to disable this feature. Defaults to "via git-CVS emulator". + +gitcvs.enabled:: + Whether the CVS server interface is enabled for this repository. + See linkgit:git-cvsserver[1]. + +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 `crlf` attribute for + files to determine the '-k' modes to use. If `crlf` is set, + the '-k' mode will be left blank, so cvs clients will + treat it as text. If `crlf` is explicitly unset, the file + will be set with '-kb' mode, which suppresses any newline munging + the client might otherwise do. If `crlf` is not specified, + then 'gitcvs.allbinary' is used. See linkgit:gitattributes[5]. + +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 + mode '-kb'. This causes the client to treat them + as binary files, which suppresses any newline munging it + otherwise might do. Alternatively, if it is set to "guess", + then the contents of the file are examined to decide if + it is binary, similar to 'core.autocrlf'. + +gitcvs.dbname:: + Database used by git-cvsserver to cache revision information + 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:: + Used Perl DBI driver. You can specify any available driver + 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', + since SQLite has no concept of database users and/or passwords. + 'gitcvs.dbuser' supports variable substitution (see + linkgit:git-cvsserver[1] for details). + +gitcvs.dbTableNamePrefix:: + Database table name prefix. Prepended to the names of any + database tables used, allowing a single database to be used + for several repositories. Supports variable substitution (see + linkgit:git-cvsserver[1] for details). Any non-alphabetic + characters will be replaced with underscores. + +All gitcvs variables except for 'gitcvs.usecrlfattr' and +'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. + +gui.commitmsgwidth:: + Defines how wide the commit message window is in the + linkgit:git-gui[1]. "75" is the default. + +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.encoding:: + Specifies the default encoding to use for displaying of + file contents in linkgit:git-gui[1] and linkgit:gitk[1]. + It can be overridden by setting the 'encoding' attribute + for relevant files (see linkgit:gitattributes[5]). + If this option is not set, the tools default to the + locale encoding. + +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:: + Is used as suggested name when creating new branches using the + linkgit:git-gui[1]. + +gui.pruneduringfetch:: + "true" if linkgit:git-gui[1] should prune tracking branches when + performing a fetch. The default value is "false". + +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:: + 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:: + 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:: + 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. + +gui.blamehistoryctx:: + Specifies the radius of history context in days to show in + linkgit:gitk[1] for the selected commit, when the `Show History + Context` menu item is invoked from 'git gui blame'. If this + variable is set to zero, the whole history is shown. + +guitool.<name>.cmd:: + Specifies the shell command line to execute when the corresponding item + of the linkgit:git-gui[1] `Tools` menu is invoked. This option is + mandatory for every tool. The command is executed from the root of + the working directory, and in the environment it receives the name of + the tool as 'GIT_GUITOOL', the name of the currently selected file as + 'FILENAME', and the name of the current branch as 'CUR_BRANCH' (if + the head is detached, 'CUR_BRANCH' is empty). + +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:: + Run the command silently, without creating a window to display its + output. + +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:: + 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 + if this is enabled. If the option is set to 'true', 'yes', or '1', + the dialog uses a built-in generic prompt; otherwise the exact + value of the variable is used. + +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. + +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. + +guitool.<name>.title:: + Specifies the title to use for the prompt dialog. The default + is the tool name. + +guitool.<name>.prompt:: + Specifies the general prompt string to display at the top of + the dialog, before subsections for 'argprompt' and 'revprompt'. + The default value includes the actual command. + +help.browser:: + Specify the browser that will be used to display help in the + 'web' format. See linkgit:git-help[1]. + +help.format:: + Override the default help format used by linkgit:git-help[1]. + Values 'man', 'info', 'web' and 'html' are supported. 'man' is + the default. 'web' and 'html' are the same. + +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 + will be executed. If the value of this option is negative, + the corrected command will be executed immediately. If the + value is 0 - the command will be just shown but not executed. + This is the default. + +http.proxy:: + Override the HTTP proxy, normally configured using the 'http_proxy' + environment variable (see linkgit:curl[1]). This can be overridden + on a per-remote basis; see remote.<name>.proxy + +http.sslVerify:: + Whether to verify the SSL certificate when fetching or pushing + over HTTPS. Can be overridden by the 'GIT_SSL_NO_VERIFY' environment + variable. + +http.sslCert:: + File containing the SSL certificate when fetching or pushing + over HTTPS. Can be overridden by the 'GIT_SSL_CERT' environment + variable. + +http.sslKey:: + File containing the SSL private key when fetching or pushing + over HTTPS. Can be overridden by the 'GIT_SSL_KEY' environment + variable. + +http.sslCertPasswordProtected:: + 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. + +http.sslCAInfo:: + File containing the certificates to verify the peer with when + fetching or pushing over HTTPS. Can be overridden by the + 'GIT_SSL_CAINFO' environment variable. + +http.sslCAPath:: + Path containing files with the CA certificates to verify the peer + with when fetching or pushing over HTTPS. Can be overridden + by the 'GIT_SSL_CAPATH' environment variable. + +http.maxRequests:: + How many HTTP requests to launch in parallel. Can be overridden + by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5. + +http.postBuffer:: + Maximum size in bytes of the buffer used by smart HTTP + transports when POSTing data to the remote system. + For requests larger than this buffer size, HTTP/1.1 and + Transfer-Encoding: chunked is used to avoid creating a + massive pack file locally. Default is 1 MiB, which is + sufficient for most requests. + +http.lowSpeedLimit, http.lowSpeedTime:: + If the HTTP transfer speed is less than 'http.lowSpeedLimit' + for longer than 'http.lowSpeedTime' seconds, the transfer is aborted. + Can be overridden by the 'GIT_HTTP_LOW_SPEED_LIMIT' and + 'GIT_HTTP_LOW_SPEED_TIME' environment variables. + +http.noEPSV:: + A boolean which disables using of EPSV ftp command by curl. + This can helpful with some "poor" ftp servers which don't + support EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV' + environment variable. Default is false (curl will use EPSV). + +i18n.commitEncoding:: + 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 + porcelains). See e.g. linkgit:git-mailinfo[1]. Defaults to 'utf-8'. + +i18n.logOutputEncoding:: + Character encoding the commit messages are converted to when + running 'git-log' and friends. + +imap:: + The configuration variables in the 'imap' section are described + in linkgit:git-imap-send[1]. + +instaweb.browser:: + Specify the program that will be used to browse your working + repository in gitweb. See linkgit:git-instaweb[1]. + +instaweb.httpd:: + The HTTP daemon command-line to start gitweb on your working + repository. See linkgit:git-instaweb[1]. + +instaweb.local:: + If true the web server started by linkgit:git-instaweb[1] will + be bound to the local IP (127.0.0.1). + +instaweb.modulepath:: + The module path for an apache httpd used by linkgit:git-instaweb[1]. + +instaweb.port:: + The port number to bind the gitweb httpd to. See + linkgit:git-instaweb[1]. + +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 only by the `\--patch` mode of + linkgit:git-add[1]. Note that this setting is silently + ignored if portable keystroke input is not available. + +log.date:: + Set default date-time mode for the log command. Setting log.date + value is similar to using 'git-log'\'s --date option. The value is one of the + following alternatives: {relative,local,default,iso,rfc,short}. + See linkgit:git-log[1]. + +log.showroot:: + If true, the initial commit will be shown as a big creation event. + This is equivalent to a diff against an empty tree. + Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which + normally hide the root commit will now show it. True by default. + +mailmap.file:: + The location of an augmenting mailmap file. The default + mailmap, located in the root of the repository, is loaded + first, then the mailmap file pointed to by this variable. + The location of the mailmap file may be in a repository + subdirectory, or somewhere outside of the repository itself. + See linkgit:git-shortlog[1] and linkgit:git-blame[1]. + +man.viewer:: + Specify the programs that may be used to display help in the + 'man' format. See linkgit:git-help[1]. + +man.<tool>.cmd:: + Specify the command to invoke the specified man viewer. The + specified command is evaluated in shell with the man page + passed as argument. (See linkgit:git-help[1].) + +man.<tool>.path:: + Override the path for the given tool that may be used to + display help in the 'man' format. See linkgit:git-help[1]. + +include::merge-config.txt[] + +mergetool.<tool>.path:: + Override the path for the given tool. This is useful in case + your tool is not in the PATH. + +mergetool.<tool>.cmd:: + Specify the command to invoke the specified merge tool. The + specified command is evaluated in shell with the following + variables available: 'BASE' is the name of a temporary file + containing the common base of the files to be merged, if available; + 'LOCAL' is the name of a temporary file containing the contents of + the file on the current branch; 'REMOTE' is the name of a temporary + file containing the contents of the file from the branch being + merged; 'MERGED' contains the name of the file to which the merge + tool should write the results of a successful merge. + +mergetool.<tool>.trustExitCode:: + For a custom merge command, specify whether the exit code of + the merge command can be used to determine whether the merge was + successful. If this is not set to true then the merge target file + timestamp is checked and the merge assumed to have been successful + if the file has been updated, otherwise the user is prompted to + indicate the success of the merge. + +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 + is set to `false` then this file is not preserved. Defaults to + `true` (i.e. keep the backup files). + +mergetool.keepTemporaries:: + 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.prompt:: + Prompt before each invocation of the merge resolution program. + +pack.window:: + The size of the window used by linkgit:git-pack-objects[1] when no + window size is given on the command line. Defaults to 10. + +pack.depth:: + The maximum delta depth used by linkgit:git-pack-objects[1] when no + maximum depth is given on the command line. Defaults to 50. + +pack.windowMemory:: + The window memory size limit used by 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. + +pack.compression:: + An integer -1..9, indicating the compression level for objects + in a pack file. -1 is the zlib default. 0 means no + compression, and 1..9 are various speed/size tradeoffs, 9 being + slowest. If not set, defaults to core.compression. If that is + not set, defaults to -1, the zlib default, which is "a default + compromise between speed and compression (currently equivalent + to level 6)." + +pack.deltaCacheSize:: + The maximum memory in bytes used for caching deltas in + linkgit:git-pack-objects[1] before writing them out to a pack. + This cache is used to speed up the writing object phase by not + having to recompute the final delta result once the best match + for all objects is found. Repacking large repositories on machines + which are tight with memory might be badly impacted by this though, + especially if this cache pushes the system into swapping. + A value of 0 means no limit. The smallest size of 1 byte may be + used to virtually disable this cache. Defaults to 256 MiB. + +pack.deltaCacheLimit:: + The maximum size of a delta, that is cached in + linkgit:git-pack-objects[1]. This cache is used to speed up the + writing object phase by not having to recompute the final delta + result once the best match for all objects is found. Defaults to 1000. + +pack.threads:: + Specifies the number of threads to spawn when searching for best + delta matches. This requires that linkgit:git-pack-objects[1] + be compiled with pthreads otherwise this option is ignored with a + warning. This is meant to reduce packing time on multiprocessor + machines. The required amount of memory for the delta search window + is however multiplied by the number of threads. + Specifying 0 will cause git to auto-detect the number of CPU's + and set the number of threads accordingly. + +pack.indexVersion:: + Specify the default pack index version. Valid values are 1 for + legacy pack index used by Git versions prior to 1.5.2, and 2 for + the new pack index with capabilities for packs larger than 4 GB + as well as proper protection against the repacking of corrupted + packs. Version 2 is the default. Note that version 2 is enforced + 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, +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 +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, +you can use linkgit:git-index-pack[1] on the *.pack file to regenerate +the `{asterisk}.idx` file. + +pack.packSizeLimit:: + The default maximum size of a pack. This setting only affects + packing to a file, i.e. the git:// protocol is unaffected. It + can be overridden by the `\--max-pack-size` option of + linkgit:git-repack[1]. + +pager.<cmd>:: + Allows turning on or off pagination of the output of a + particular git subcommand when writing to a tty. 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`. + +pull.octopus:: + The default merge strategy to use when pulling multiple branches + at once. + +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. +* `tracking` push the current branch to its upstream branch. +* `current` push the current branch to a branch of the same name. + +rebase.stat:: + Whether to show a diffstat of what changed upstream since the last + rebase. False by default. + +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.fsckObjects:: + If it is set to true, git-receive-pack will check all received + objects. It will abort in the case of a malformed object or a + broken link. The result of an abort are only dangling objects. + Defaults to false. + +receive.unpackLimit:: + If the number of objects received in a push is below this + limit then the objects will be unpacked into loose object + files. However if the number of received objects equals or + exceeds this limit then the received pack will be stored as + a pack, after adding any missing delta bases. Storing the + pack from a push can make the push operation complete faster, + especially on slow filesystems. If not set, the value of + `transfer.unpackLimit` is used instead. + +receive.denyDeletes:: + If set to true, git-receive-pack will deny a ref update that deletes + the ref. Use this to prevent such a ref deletion via a push. + +receive.denyCurrentBranch:: + If set to true or "refuse", receive-pack will deny a ref update + to the currently checked out branch of a non-bare repository. + Such a push is potentially dangerous because it brings the HEAD + out of sync with the index and working tree. If set to "warn", + 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 "warn". + +receive.denyNonFastForwards:: + If set to true, git-receive-pack will deny a ref update which is + not a fast-forward. Use this to prevent such an update via a push, + even if that push is forced. This configuration variable is + set when initializing a shared repository. + +receive.updateserverinfo:: + If set to true, git-receive-pack will run git-update-server-info + after receiving data from git-push and updating refs. + +remote.<name>.url:: + The URL of a remote repository. See linkgit:git-fetch[1] or + linkgit:git-push[1]. + +remote.<name>.pushurl:: + The push URL of a remote repository. See linkgit:git-push[1]. + +remote.<name>.proxy:: + For remotes that require curl (http, https and ftp), the URL to + the proxy to use for that remote. Set to the empty string to + disable proxying for that remote. + +remote.<name>.fetch:: + The default set of "refspec" for linkgit:git-fetch[1]. See + linkgit:git-fetch[1]. + +remote.<name>.push:: + The default set of "refspec" for linkgit:git-push[1]. See + linkgit:git-push[1]. + +remote.<name>.mirror:: + If true, pushing to this remote will automatically behave + 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 + using linkgit:git-fetch[1] or the `update` subcommand of + linkgit:git-remote[1]. + +remote.<name>.skipFetchAll:: + If true, this remote will be skipped by default when updating + using linkgit:git-fetch[1] or the `update` subcommand of + linkgit:git-remote[1]. + +remote.<name>.receivepack:: + The default program to execute on the remote side when pushing. See + option \--receive-pack of linkgit:git-push[1]. + +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:: + Setting this value to \--no-tags disables automatic tag following when + fetching from remote <name> + +remotes.<group>:: + The list of remotes which are fetched by "git remote update + <group>". See linkgit:git-remote[1]. + +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 + protocol such as http, then you need to set this option to + "false" and repack. Access from old git versions over the + native protocol are unaffected by this option. + +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. + +rerere.enabled:: + Activate recording of resolved conflicts, so that identical + conflict hunks can be resolved automatically, should they + be encountered again. linkgit:git-rerere[1] command is by + default enabled if you create `rr-cache` directory under + `$GIT_DIR`, but can be disabled by setting this option to false. + +sendemail.identity:: + A configuration identity. When given, causes values in the + 'sendemail.<identity>' subsection to take precedence over + values in the 'sendemail' section. The default identity is + the value of 'sendemail.identity'. + +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.<identity>.*:: + Identity-specific versions of the 'sendemail.*' parameters + found below, taking precedence over those when the this + identity is selected, through command-line or + 'sendemail.identity'. + +sendemail.aliasesfile:: +sendemail.aliasfiletype:: +sendemail.bcc:: +sendemail.cc:: +sendemail.cccmd:: +sendemail.chainreplyto:: +sendemail.confirm:: +sendemail.envelopesender:: +sendemail.from:: +sendemail.multiedit:: +sendemail.signedoffbycc:: +sendemail.smtppass:: +sendemail.suppresscc:: +sendemail.suppressfrom:: +sendemail.to:: +sendemail.smtpserver:: +sendemail.smtpserverport:: +sendemail.smtpuser:: +sendemail.thread:: +sendemail.validate:: + See linkgit:git-send-email[1] for description. + +sendemail.signedoffcc:: + Deprecated alias for 'sendemail.signedoffbycc'. + +showbranch.default:: + The default set of branches for linkgit:git-show-branch[1]. + See linkgit:git-show-branch[1]. + +status.relativePaths:: + By default, linkgit:git-status[1] shows paths relative to the + current directory. Setting this variable to `false` shows paths + relative to the repository root (this was the default for git + prior to v1.5.4). + +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 + systems. So, this variable controls how the commands displays + the untracked files. Possible values are: ++ +-- + - 'no' - Show no untracked files + - 'normal' - Shows untracked files and directories + - 'all' - Shows also individual files in untracked directories. +-- ++ +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]. + +tar.umask:: + This variable can be used to restrict the permission bits of + tar archive entries. The default is 0002, which turns off the + world write bit. The special value "user" indicates that the + archiving user's umask will be used instead. See umask(2) and + linkgit:git-archive[1]. + +transfer.unpackLimit:: + When `fetch.unpackLimit` or `receive.unpackLimit` are + not set, the value of this variable is used instead. + The default value is 100. + +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 + 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. + +url.<base>.pushInsteadOf:: + Any URL that starts with this value will not be pushed to; + instead, it will be rewritten to start with <base>, and the + 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 + 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 + setting for that remote. + +user.email:: + Your email address to be recorded in any newly created commits. + Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and + 'EMAIL' environment variables. See linkgit:git-commit-tree[1]. + +user.name:: + Your full name to be recorded in any newly created commits. + Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME' + environment variables. See 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. + +web.browser:: + Specify a web browser that may be used by some commands. + Currently only linkgit:git-instaweb[1] and linkgit:git-help[1] + may use it. diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt new file mode 100644 index 0000000000..b71712473e --- /dev/null +++ b/Documentation/diff-format.txt @@ -0,0 +1,169 @@ +Raw output format +----------------- + +The raw output format from "git-diff-index", "git-diff-tree", +"git-diff-files" and "git diff --raw" are very similar. + +These commands all compare two sets of things; what is +compared differs: + +git-diff-index <tree-ish>:: + compares the <tree-ish> and the files on the filesystem. + +git-diff-index --cached <tree-ish>:: + compares the <tree-ish> and the index. + +git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]:: + compares the trees named by the two arguments. + +git-diff-files [<pattern>...]:: + compares the index and the files on the filesystem. + +The "git-diff-tree" command begins its ouput by printing the hash of +what is being compared. After that, all the commands print one output +line per changed file. + +An output line is formatted this way: + +------------------------------------------------ +in-place edit :100644 100644 bcd1234... 0123456... M file0 +copy-edit :100644 100644 abcd123... 1234567... C68 file1 file2 +rename-edit :100644 100644 abcd123... 1234567... R86 file1 file3 +create :000000 100644 0000000... 1234567... A file4 +delete :100644 000000 1234567... 0000000... D file5 +unmerged :000000 000000 0000000... 0000000... U file6 +------------------------------------------------ + +That is, from the left to the right: + +. a colon. +. mode for "src"; 000000 if creation or unmerged. +. a space. +. mode for "dst"; 000000 if deletion or unmerged. +. a space. +. sha1 for "src"; 0\{40\} if creation or unmerged. +. a space. +. sha1 for "dst"; 0\{40\} if creation, unmerged or "look at work tree". +. a space. +. status, followed by optional "score" number. +. a tab or a NUL when '-z' option is used. +. path for "src" +. a tab or a NUL when '-z' option is used; only exists for C or R. +. path for "dst"; only exists for C or R. +. an LF or a NUL when '-z' option is used, to terminate the record. + +Possible status letters are: + +- A: addition of a file +- C: copy of a file into a new one +- D: deletion of a file +- M: modification of the contents or mode of a file +- R: renaming of a file +- T: change in the type of the file +- U: file is unmerged (you must complete the merge before it can +be committed) +- X: "unknown" change type (most probably a bug, please report it) + +Status letters C and R are always followed by a score (denoting the +percentage of similarity between the source and target of the move or +copy), and are the only ones to be so. + +<sha1> is shown as all 0's if a file is new on the filesystem +and it is out of sync with the index. + +Example: + +------------------------------------------------ +:100644 100644 5be4a4...... 000000...... M file.c +------------------------------------------------ + +When `-z` option is not used, TAB, LF, and backslash characters +in pathnames are represented as `\t`, `\n`, and `\\`, +respectively. + +diff format for merges +---------------------- + +"git-diff-tree", "git-diff-files" and "git-diff --raw" +can take '-c' or '--cc' option +to generate diff output also for merge commits. The output differs +from the format described above in the following way: + +. there is a colon for each parent +. there are more "src" modes and "src" sha1 +. status is concatenated status characters for each parent +. no optional "score" number +. single path, only for "dst" + +Example: + +------------------------------------------------ +::100644 100644 100644 fabadb8... cc95eb0... 4866510... MM describe.c +------------------------------------------------ + +Note that 'combined diff' lists only files which were modified from +all parents. + + +include::diff-generate-patch.txt[] + + +other diff formats +------------------ + +The `--summary` option describes newly added, deleted, renamed and +copied files. The `--stat` option adds diffstat(1) graph to the +output. These options can be combined with other options, such as +`-p`, and are meant for human consumption. + +When showing a change that involves a rename or a copy, `--stat` output +formats the pathnames compactly by combining common prefix and suffix of +the pathnames. For example, a change that moves `arch/i386/Makefile` to +`arch/x86/Makefile` while modifying 4 lines will be shown like this: + +------------------------------------ +arch/{i386 => x86}/Makefile | 4 +-- +------------------------------------ + +The `--numstat` option gives the diffstat(1) information but is designed +for easier machine consumption. An entry in `--numstat` output looks +like this: + +---------------------------------------- +1 2 README +3 1 arch/{i386 => x86}/Makefile +---------------------------------------- + +That is, from left to right: + +. the number of added lines; +. a tab; +. the number of deleted lines; +. a tab; +. pathname (possibly with rename/copy information); +. a newline. + +When `-z` output option is in effect, the output is formatted this way: + +---------------------------------------- +1 2 README NUL +3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL +---------------------------------------- + +That is: + +. the number of added lines; +. a tab; +. the number of deleted lines; +. a tab; +. a NUL (only exists if renamed/copied); +. pathname in preimage; +. a NUL (only exists if renamed/copied); +. pathname in postimage (only exists if renamed/copied); +. a NUL. + +The extra `NUL` before the preimage path in renamed case is to allow +scripts that read the output to tell if the current record being read is +a single-path record or a rename/copy record without reading ahead. +After reading added and deleted lines, reading up to `NUL` would yield +the pathname, but if that is `NUL`, the record will show two paths. diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt new file mode 100644 index 0000000000..0f25ba7e38 --- /dev/null +++ b/Documentation/diff-generate-patch.txt @@ -0,0 +1,161 @@ +Generating patches with -p +-------------------------- + +When "git-diff-index", "git-diff-tree", or "git-diff-files" are run +with a '-p' option, "git diff" without the '--raw' option, or +"git log" with the "-p" option, they +do not produce the output described above; instead they produce a +patch file. You can customize the creation of such patches via the +GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables. + +What the -p option produces is slightly different from the traditional +diff format. + +1. It is preceded with a "git diff" header, that looks like + this: + + diff --git a/file1 b/file2 ++ +The `a/` and `b/` filenames are the same unless rename/copy is +involved. Especially, even for a creation or a deletion, +`/dev/null` is _not_ used in place of `a/` or `b/` filenames. ++ +When rename/copy is involved, `file1` and `file2` show the +name of the source file of the rename/copy and the name of +the file that rename/copy produces, respectively. + +2. It is followed by one or more extended header lines: + + old mode <mode> + new mode <mode> + deleted file mode <mode> + new file mode <mode> + copy from <path> + copy to <path> + rename from <path> + rename to <path> + similarity index <number> + dissimilarity index <number> + index <hash>..<hash> <mode> + +3. TAB, LF, double quote and backslash characters in pathnames + are represented as `\t`, `\n`, `\"` and `\\`, respectively. + If there is need for such substitution then the whole + pathname is put in double quotes. + +The similarity index is the percentage of unchanged lines, and +the dissimilarity index is the percentage of changed lines. It +is a rounded down integer, followed by a percent sign. The +similarity index value of 100% is thus reserved for two equal +files, while 100% dissimilarity means that no line from the old +file made it into the new one. + + +combined diff format +-------------------- + +"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or +'--cc' option to produce 'combined diff'. For showing a merge commit +with "git log -p", this is the default format. +A 'combined diff' format looks like this: + +------------ +diff --combined describe.c +index fabadb8,cc95eb0..4866510 +--- a/describe.c ++++ b/describe.c +@@@ -98,20 -98,12 +98,20 @@@ + return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1; + } + +- static void describe(char *arg) + -static void describe(struct commit *cmit, int last_one) +++static void describe(char *arg, int last_one) + { + + unsigned char sha1[20]; + + struct commit *cmit; + struct commit_list *list; + static int initialized = 0; + struct commit_name *n; + + + if (get_sha1(arg, sha1) < 0) + + usage(describe_usage); + + cmit = lookup_commit_reference(sha1); + + if (!cmit) + + usage(describe_usage); + + + if (!initialized) { + initialized = 1; + for_each_ref(get_name); +------------ + +1. It is preceded with a "git diff" header, that looks like + this (when '-c' option is used): + + diff --combined file ++ +or like this (when '--cc' option is used): + + diff --cc file + +2. It is followed by one or more extended header lines + (this example shows a merge with two parents): + + index <hash>,<hash>..<hash> + mode <mode>,<mode>..<mode> + new file mode <mode> + deleted file mode <mode>,<mode> ++ +The `mode <mode>,<mode>..<mode>` line appears only if at least one of +the <mode> is different from the rest. Extended headers with +information about detected contents movement (renames and +copying detection) are designed to work with diff of two +<tree-ish> and are not used by combined diff format. + +3. It is followed by two-line from-file/to-file header + + --- a/file + +++ b/file ++ +Similar to two-line header for traditional 'unified' diff +format, `/dev/null` is used to signal created or deleted +files. + +4. Chunk header format is modified to prevent people from + accidentally feeding it to `patch -p1`. Combined diff format + was created for review of merge commit changes, and was not + meant for apply. The change is similar to the change in the + extended 'index' header: + + @@@ <from-file-range> <from-file-range> <to-file-range> @@@ ++ +There are (number of parents + 1) `@` characters in the chunk +header for combined diff format. + +Unlike the traditional 'unified' diff format, which shows two +files A and B with a single column that has `-` (minus -- +appears in A but removed in B), `+` (plus -- missing in A but +added to B), or `" "` (space -- unchanged) prefix, this format +compares two or more files file1, file2,... with one file X, and +shows how X differs from each of fileN. One column for each of +fileN is prepended to the output line to note how X's line is +different from it. + +A `-` character in the column N means that the line appears in +fileN but it does not appear in the result. A `+` character +in the column N means that the line appears in the result, +and fileN does not have that line (in other words, the line was +added, from the point of view of that parent). + +In the above example output, the function signature was changed +from both files (hence two `-` removals from both file1 and +file2, plus `++` to mean one line that was added does not appear +in either file1 nor file2). Also eight other lines are the same +from file1 but do not appear in file2 (hence prefixed with `{plus}`). + +When shown by `git diff-tree -c`, it compares the parents of a +merge commit with the merge result (i.e. file1..fileN are the +parents). When shown by `git diff-files -c`, it compares the +two unresolved merge parents with the working tree file +(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka +"their version"). diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt new file mode 100644 index 0000000000..8707d0e740 --- /dev/null +++ b/Documentation/diff-options.txt @@ -0,0 +1,302 @@ +// Please don't remove this comment as asciidoc behaves badly when +// the first non-empty line is ifdef/ifndef. The symptom is that +// without this comment the <git-diff-core> attribute conditionally +// defined below ends up being defined unconditionally. +// Last checked with asciidoc 7.0.2. + +ifndef::git-format-patch[] +ifndef::git-diff[] +ifndef::git-log[] +:git-diff-core: 1 +endif::git-log[] +endif::git-diff[] +endif::git-format-patch[] + +ifdef::git-format-patch[] +-p:: +--no-stat:: + Generate plain patches without any diffstats. +endif::git-format-patch[] + +ifndef::git-format-patch[] +-p:: +-u:: + Generate patch (see section on generating patches). + {git-diff? This is the default.} +endif::git-format-patch[] + +-U<n>:: +--unified=<n>:: + Generate diffs with <n> lines of context instead of + the usual three. +ifndef::git-format-patch[] + Implies `-p`. +endif::git-format-patch[] + +ifndef::git-format-patch[] +--raw:: + Generate the raw format. + {git-diff-core? This is the default.} +endif::git-format-patch[] + +ifndef::git-format-patch[] +--patch-with-raw:: + Synonym for `-p --raw`. +endif::git-format-patch[] + +--patience:: + Generate a diff using the "patience diff" algorithm. + +--stat[=width[,name-width]]:: + Generate a diffstat. You can override the default + output width for 80-column terminal by `--stat=width`. + The width of the filename part can be controlled by + giving another width to it separated by a comma. + +--numstat:: + Similar to `\--stat`, but shows number of added and + deleted lines in decimal notation and pathname without + abbreviation, to make it more machine friendly. For + binary files, outputs two `-` instead of saying + `0 0`. + +--shortstat:: + Output only the last line of the `--stat` format containing total + number of modified files, as well as number of added and deleted + lines. + +--dirstat[=limit]:: + Output the distribution of relative amount of changes (number of lines added or + removed) for each sub-directory. Directories with changes below + a cut-off percent (3% by default) are not shown. The cut-off percent + can be set with `--dirstat=limit`. Changes in a child directory is not + counted for the parent directory, unless `--cumulative` is used. + +--dirstat-by-file[=limit]:: + Same as `--dirstat`, but counts changed files instead of lines. + +--summary:: + Output a condensed summary of extended header information + such as creations, renames and mode changes. + +ifndef::git-format-patch[] +--patch-with-stat:: + Synonym for `-p --stat`. +endif::git-format-patch[] + +ifndef::git-format-patch[] + +-z:: +ifdef::git-log[] + Separate the commits with NULs instead of with new newlines. ++ +Also, when `--raw` or `--numstat` has been given, do not munge +pathnames and use NULs as output field terminators. +endif::git-log[] +ifndef::git-log[] + When `--raw` or `--numstat` has been given, do not munge + pathnames and use NULs as output field terminators. +endif::git-log[] ++ +Without this option, each pathname output will have TAB, LF, double quotes, +and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`, +respectively, and the pathname will be enclosed in double quotes if +any of those replacements occurred. + +--name-only:: + Show only names of changed files. + +--name-status:: + Show only names and status of changed files. See the description + of the `--diff-filter` option on what the status letters mean. + +--submodule[=<format>]:: + Chose the output format for submodule differences. <format> can be one of + 'short' and 'log'. 'short' just shows pairs of commit names, this format + is used when this option is not given. 'log' is the default value for this + option and lists the commits in that commit range like the 'summary' + option of linkgit:git-submodule[1] does. + +--color:: + Show colored diff. + +--no-color:: + Turn off colored diff, even when the configuration file + gives the default to color output. + +--color-words[=<regex>]:: + Show colored word diff, i.e., color words which have changed. + By default, words are separated by whitespace. ++ +When a <regex> is specified, every non-overlapping match of the +<regex> is considered a word. Anything between these matches is +considered whitespace and ignored(!) for the purposes of finding +differences. You may want to append `|[^[:space:]]` to your regular +expression to make sure that it matches all non-whitespace characters. +A match that contains a newline is silently truncated(!) at the +newline. ++ +The regex can also be set via a diff driver or configuration option, see +linkgit:gitattributes[1] or linkgit:git-config[1]. Giving it explicitly +overrides any diff driver or configuration setting. Diff drivers +override configuration settings. +endif::git-format-patch[] + +--no-renames:: + Turn off rename detection, even when the configuration + file gives the default to do so. + +ifndef::git-format-patch[] +--check:: + Warn if changes introduce trailing whitespace + or an indent that uses a space before a tab. Exits with + non-zero status if problems are found. Not compatible with + --exit-code. +endif::git-format-patch[] + +--full-index:: + Instead of the first handful of characters, show the full + pre- and post-image blob object names on the "index" + line when generating patch format output. + +--binary:: + In addition to `--full-index`, output a binary diff that + can be applied with `git-apply`. + +--abbrev[=<n>]:: + Instead of showing the full 40-byte hexadecimal object + name in diff-raw format output and diff-tree header + lines, show only a partial prefix. This is + independent of the `--full-index` option above, which controls + the diff-patch output format. Non default number of + digits can be specified with `--abbrev=<n>`. + +-B:: + Break complete rewrite changes into pairs of delete and create. + +-M:: + Detect renames. + +-C:: + Detect copies as well as renames. See also `--find-copies-harder`. + +ifndef::git-format-patch[] +--diff-filter=[ACDMRTUXB*]:: + Select only files that are Added (`A`), Copied (`C`), + Deleted (`D`), Modified (`M`), Renamed (`R`), have their + type (i.e. regular file, symlink, submodule, ...) changed (`T`), + are Unmerged (`U`), are + Unknown (`X`), or have had their pairing Broken (`B`). + Any combination of the filter characters may be used. + When `*` (All-or-none) is added to the combination, all + paths are selected if there is any file that matches + other criteria in the comparison; if there is no file + that matches other criteria, nothing is selected. +endif::git-format-patch[] + +--find-copies-harder:: + For performance reasons, by default, `-C` option finds copies only + if the original file of the copy was modified in the same + changeset. This flag makes the command + inspect unmodified files as candidates for the source of + copy. This is a very expensive operation for large + projects, so use it with caution. Giving more than one + `-C` option has the same effect. + +-l<num>:: + The `-M` and `-C` options require O(n^2) processing time where n + is the number of potential rename/copy targets. This + option prevents rename/copy detection from running if + the number of rename/copy targets exceeds the specified + number. + +ifndef::git-format-patch[] +-S<string>:: + Look for differences that introduce or remove an instance of + <string>. Note that this is different than the string simply + appearing in diff output; see the 'pickaxe' entry in + linkgit:gitdiffcore[7] for more details. + +--pickaxe-all:: + When `-S` finds a change, show all the changes in that + changeset, not just the files that contain the change + in <string>. + +--pickaxe-regex:: + Make the <string> not a plain string but an extended POSIX + regex to match. +endif::git-format-patch[] + +-O<orderfile>:: + Output the patch in the order specified in the + <orderfile>, which has one shell glob pattern per line. + +ifndef::git-format-patch[] +-R:: + Swap two inputs; that is, show differences from index or + on-disk file to tree contents. + +--relative[=<path>]:: + When run from a subdirectory of the project, it can be + told to exclude changes outside the directory and show + pathnames relative to it with this option. When you are + not in a subdirectory (e.g. in a bare repository), you + can name which subdirectory to make the output relative + to by giving a <path> as an argument. +endif::git-format-patch[] + +-a:: +--text:: + Treat all files as text. + +--ignore-space-at-eol:: + Ignore changes in whitespace at EOL. + +-b:: +--ignore-space-change:: + Ignore changes in amount of whitespace. This ignores whitespace + at line end, and considers all other sequences of one or + more whitespace characters to be equivalent. + +-w:: +--ignore-all-space:: + Ignore whitespace when comparing lines. This ignores + differences even if one line has whitespace where the other + line has none. + +--inter-hunk-context=<lines>:: + Show the context between diff hunks, up to the specified number + of lines, thereby fusing hunks that are close to each other. + +ifndef::git-format-patch[] +--exit-code:: + Make the program exit with codes similar to diff(1). + That is, it exits with 1 if there were differences and + 0 means no differences. + +--quiet:: + Disable all output of the program. Implies `--exit-code`. +endif::git-format-patch[] + +--ext-diff:: + Allow an external diff helper to be executed. If you set an + external diff driver with linkgit:gitattributes[5], you need + to use this option with linkgit:git-log[1] and friends. + +--no-ext-diff:: + Disallow external diff drivers. + +--ignore-submodules:: + Ignore changes to submodules in the diff generation. + +--src-prefix=<prefix>:: + Show the given source prefix instead of "a/". + +--dst-prefix=<prefix>:: + Show the given destination prefix instead of "b/". + +--no-prefix:: + Do not show any source or destination prefix. + +For more detailed explanation on these common options, see also +linkgit:gitdiffcore[7]. diff --git a/Documentation/docbook-xsl.css b/Documentation/docbook-xsl.css new file mode 100644 index 0000000000..e11c8f053a --- /dev/null +++ b/Documentation/docbook-xsl.css @@ -0,0 +1,296 @@ +/* + CSS stylesheet for XHTML produced by DocBook XSL stylesheets. + Tested with XSL stylesheets 1.61.2, 1.67.2 +*/ + +span.strong { + font-weight: bold; +} + +body blockquote { + margin-top: .75em; + line-height: 1.5; + margin-bottom: .75em; +} + +html body { + margin: 1em 5% 1em 5%; + line-height: 1.2; + font-family: sans-serif; +} + +body div { + margin: 0; +} + +h1, h2, h3, h4, h5, h6, +div.toc p b, +div.list-of-figures p b, +div.list-of-tables p b, +div.abstract p.title +{ + color: #527bbd; + font-family: tahoma, verdana, sans-serif; +} + +div.toc p:first-child, +div.list-of-figures p:first-child, +div.list-of-tables p:first-child, +div.example p.title +{ + margin-bottom: 0.2em; +} + +body h1 { + margin: .0em 0 0 -4%; + line-height: 1.3; + border-bottom: 2px solid silver; +} + +body h2 { + margin: 0.5em 0 0 -4%; + line-height: 1.3; + border-bottom: 2px solid silver; +} + +body h3 { + margin: .8em 0 0 -3%; + line-height: 1.3; +} + +body h4 { + margin: .8em 0 0 -3%; + line-height: 1.3; +} + +body h5 { + margin: .8em 0 0 -2%; + line-height: 1.3; +} + +body h6 { + margin: .8em 0 0 -1%; + line-height: 1.3; +} + +body hr { + border: none; /* Broken on IE6 */ +} +div.footnotes hr { + border: 1px solid silver; +} + +div.navheader th, div.navheader td, div.navfooter td { + font-family: sans-serif; + font-size: 0.9em; + font-weight: bold; + color: #527bbd; +} +div.navheader img, div.navfooter img { + border-style: none; +} +div.navheader a, div.navfooter a { + font-weight: normal; +} +div.navfooter hr { + border: 1px solid silver; +} + +body td { + line-height: 1.2 +} + +body th { + line-height: 1.2; +} + +ol { + line-height: 1.2; +} + +ul, body dir, body menu { + line-height: 1.2; +} + +html { + margin: 0; + padding: 0; +} + +body h1, body h2, body h3, body h4, body h5, body h6 { + margin-left: 0 +} + +body pre { + margin: 0.5em 10% 0.5em 1em; + line-height: 1.0; + color: navy; +} + +tt.literal, code.literal { + color: navy; + font-family: sans-serif; +} + +code.literal:before { content: "'"; } +code.literal:after { content: "'"; } + +em { + font-style: italic; + color: #064; +} + +div.literallayout p { + padding: 0em; + margin: 0em; +} + +div.literallayout { + font-family: monospace; + margin: 0em; + color: navy; + border: 1px solid silver; + background: #f4f4f4; + padding: 0.5em; +} + +.programlisting, .screen { + border: 1px solid silver; + background: #f4f4f4; + margin: 0.5em 10% 0.5em 0; + padding: 0.5em 1em; +} + +div.sidebar { + background: #ffffee; + margin: 1.0em 10% 0.5em 0; + padding: 0.5em 1em; + border: 1px solid silver; +} +div.sidebar * { padding: 0; } +div.sidebar div { margin: 0; } +div.sidebar p.title { + font-family: sans-serif; + margin-top: 0.5em; + margin-bottom: 0.2em; +} + +div.bibliomixed { + margin: 0.5em 5% 0.5em 1em; +} + +div.glossary dt { + font-weight: bold; +} +div.glossary dd p { + margin-top: 0.2em; +} + +dl { + margin: .8em 0; + line-height: 1.2; +} + +dt { + margin-top: 0.5em; +} + +dt span.term { + font-style: normal; + color: navy; +} + +div.variablelist dd p { + margin-top: 0; +} + +div.itemizedlist li, div.orderedlist li { + margin-left: -0.8em; + margin-top: 0.5em; +} + +ul, ol { + list-style-position: outside; +} + +div.sidebar ul, div.sidebar ol { + margin-left: 2.8em; +} + +div.itemizedlist p.title, +div.orderedlist p.title, +div.variablelist p.title +{ + margin-bottom: -0.8em; +} + +div.revhistory table { + border-collapse: collapse; + border: none; +} +div.revhistory th { + border: none; + color: #527bbd; + font-family: tahoma, verdana, sans-serif; +} +div.revhistory td { + border: 1px solid silver; +} + +/* Keep TOC and index lines close together. */ +div.toc dl, div.toc dt, +div.list-of-figures dl, div.list-of-figures dt, +div.list-of-tables dl, div.list-of-tables dt, +div.indexdiv dl, div.indexdiv dt +{ + line-height: normal; + margin-top: 0; + margin-bottom: 0; +} + +/* + Table styling does not work because of overriding attributes in + generated HTML. +*/ +div.table table, +div.informaltable table +{ + margin-left: 0; + margin-right: 5%; + margin-bottom: 0.8em; +} +div.informaltable table +{ + margin-top: 0.4em +} +div.table thead, +div.table tfoot, +div.table tbody, +div.informaltable thead, +div.informaltable tfoot, +div.informaltable tbody +{ + /* No effect in IE6. */ + border-top: 2px solid #527bbd; + border-bottom: 2px solid #527bbd; +} +div.table thead, div.table tfoot, +div.informaltable thead, div.informaltable tfoot +{ + font-weight: bold; +} + +div.mediaobject img { + border: 1px solid silver; + margin-bottom: 0.8em; +} +div.figure p.title, +div.table p.title +{ + margin-top: 1em; + margin-bottom: 0.4em; +} + +@media print { + div.navheader, div.navfooter { display: none; } +} diff --git a/Documentation/docbook.xsl b/Documentation/docbook.xsl new file mode 100644 index 0000000000..9a6912c641 --- /dev/null +++ b/Documentation/docbook.xsl @@ -0,0 +1,5 @@ +<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" + version='1.0'> + <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl"/> + <xsl:output method="html" encoding="UTF-8" indent="no" /> +</xsl:stylesheet> diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt new file mode 100644 index 0000000000..9310b650d3 --- /dev/null +++ b/Documentation/everyday.txt @@ -0,0 +1,456 @@ +Everyday GIT With 20 Commands Or So +=================================== + +<<Basic Repository>> commands are needed by people who have a +repository --- that is everybody, because every working tree of +git is a repository. + +In addition, <<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 <<Individual Developer (Participant)>> section as well. + +People who play the <<Integrator>> role need to learn some more +commands in addition to the above. + +<<Repository Administration>> commands are for system +administrators who are responsible for the care and feeding +of git repositories. + + +Basic Repository[[Basic Repository]] +------------------------------------ + +Everybody uses these commands to maintain git repositories. + + * linkgit:git-init[1] or linkgit:git-clone[1] to create a + new repository. + + * linkgit:git-fsck[1] to check the repository for errors. + + * linkgit:git-gc[1] to do common housekeeping tasks such as + repack and prune. + +Examples +~~~~~~~~ + +Check health and remove cruft.:: ++ +------------ +$ git fsck <1> +$ git count-objects <2> +$ git gc <3> +------------ ++ +<1> running without `\--full` is usually cheap and assures the +repository health reasonably well. +<2> check how many loose objects there are and how much +disk space is wasted by not repacking. +<3> repacks the local repository and performs other housekeeping tasks. + +Repack a small project into single pack.:: ++ +------------ +$ git gc <1> +------------ ++ +<1> pack all the objects reachable from the refs into one pack, +then remove the other packs. + + +Individual Developer (Standalone)[[Individual Developer (Standalone)]] +---------------------------------------------------------------------- + +A standalone individual developer does not exchange patches with +other people, and works alone in a single repository, using the +following commands. + + * 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 + branches. + + * linkgit:git-add[1] to manage the index file. + + * linkgit:git-diff[1] and linkgit:git-status[1] to see what + you are in the middle of doing. + + * linkgit:git-commit[1] to advance the current branch. + + * linkgit:git-reset[1] and linkgit:git-checkout[1] (with + pathname parameters) to undo changes. + + * linkgit:git-merge[1] to merge between local branches. + + * linkgit:git-rebase[1] to maintain topic branches. + + * linkgit:git-tag[1] to mark known point. + +Examples +~~~~~~~~ + +Use a tarball as a starting point for a new repository.:: ++ +------------ +$ tar zxf frotz.tar.gz +$ cd frotz +$ git init +$ git add . <1> +$ git commit -m "import of frotz source tree." +$ git tag v2.43 <2> +------------ ++ +<1> add everything under the current directory. +<2> make a lightweight, unannotated tag. + +Create a topic branch and develop.:: ++ +------------ +$ git checkout -b alsa-audio <1> +$ edit/compile/test +$ git checkout -- curses/ux_audio_oss.c <2> +$ git add curses/ux_audio_alsa.c <3> +$ 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> +------------ ++ +<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 +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/` +directory, since `v2.43` tag. + + +Individual Developer (Participant)[[Individual Developer (Participant)]] +------------------------------------------------------------------------ + +A developer working as a participant in a group project needs to +learn how to communicate with others, and uses these commands in +addition to the ones needed by a standalone developer. + + * linkgit:git-clone[1] from the upstream to prime your local + repository. + + * linkgit:git-pull[1] and linkgit:git-fetch[1] from "origin" + to keep up-to-date with the upstream. + + * linkgit:git-push[1] to shared repository, if you adopt CVS + style shared repository workflow. + + * linkgit:git-format-patch[1] to prepare e-mail submission, if + you adopt Linux kernel-style public forum workflow. + +Examples +~~~~~~~~ + +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> +------------ ++ +<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 +current branch. +<4> 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/`. + + +Push into another repository.:: ++ +------------ +satellite$ git clone mothership:frotz frotz <1> +satellite$ cd frotz +satellite$ git config --get-regexp '^(remote|branch)\.' <2> +remote.origin.url mothership:frotz +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> +satellite$ edit/compile/test/commit +satellite$ git push origin <4> + +mothership$ cd frotz +mothership$ git checkout master +mothership$ git merge satellite/master <5> +------------ ++ +<1> mothership machine has a frotz repository under your home +directory; clone from it to start a repository on the satellite +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/*` 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` +tracking branch on the mothership machine. You could use this as +a back-up method. +<5> on mothership machine, merge the work done on the satellite +machine into the master branch. + +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> +------------ ++ +<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". + + +Integrator[[Integrator]] +------------------------ + +A fairly central person acting as the integrator in a group +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. + + * linkgit:git-am[1] to apply patches e-mailed in from your + contributors. + + * linkgit:git-pull[1] to merge from your trusted lieutenants. + + * linkgit:git-format-patch[1] to prepare and send suggested + alternative to contributors. + + * linkgit:git-revert[1] to undo botched commits. + + * linkgit:git-push[1] to publish the bleeding edge. + + +Examples +~~~~~~~~ + +My typical GIT day.:: ++ +------------ +$ git status <1> +$ git show-branch <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> +$ compile/test +$ git checkout -b hold/linus && git am -3 -i -s -u ./+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> +$ 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> +------------ ++ +<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. +<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. +<6> rebase internal topic branch that has not been merged to the +master, nor 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: ++ +------------ +$ 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 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. + + +Repository Administration[[Repository Administration]] +------------------------------------------------------ + +A repository administrator uses the following tools to set up +and maintain access to the repository by developers. + + * linkgit:git-daemon[1] to allow anonymous download from + repository. + + * 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 +example of managing a shared central repository. + + +Examples +~~~~~~~~ +We assume the following in /etc/services:: ++ +------------ +$ grep 9418 /etc/services +git 9418/tcp # Git Version Control System +------------ + +Run git-daemon to serve /pub/scm from inetd.:: ++ +------------ +$ grep git /etc/inetd.conf +git stream tcp nowait nobody \ + /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm +------------ ++ +The actual configuration line should be on one line. + +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 +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 +} +------------ ++ +Check your xinetd(8) documentation and setup, this is from a Fedora system. +Others might be different. + +Give push/pull only access to developers.:: ++ +------------ +$ grep git /etc/passwd <1> +alice:x:1000:1000::/home/alice:/usr/bin/git-shell +bob:x:1001:1001::/home/bob:/usr/bin/git-shell +cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell +david:x:1003:1003::/home/david:/usr/bin/git-shell +$ grep git /etc/shells <2> +/usr/bin/git-shell +------------ ++ +<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. +<2> in many distributions /etc/shells needs to list what is used +as the login shell. + +CVS-style shared repository.:: ++ +------------ +$ grep git /etc/group <1> +git:x:9418:alice,bob,cindy,david +$ cd /home/devo.git +$ ls -l <2> + lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master + drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches + -rw-rw-r-- 1 david git 84 Dec 4 22:40 config + -rw-rw-r-- 1 david git 58 Dec 4 22:40 description + drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks + -rw-rw-r-- 1 david git 37504 Dec 4 22:40 index + drwxrwsr-x 2 david git 4096 Dec 4 22:40 info + drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects + drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs + drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes +$ ls -l hooks/update <3> + -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update +$ cat info/allowed-users <4> +refs/heads/master alice\|cindy +refs/heads/doc-update bob +refs/tags/v[0-9]* david +------------ ++ +<1> place the developers into the same git group. +<2> and make the shared repository writable by the group. +<3> use update-hook example by Carl from Documentation/howto/ +for branch policy control. +<4> alice and cindy can push into master, only bob can push into doc-update. +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. diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt new file mode 100644 index 0000000000..ab6419fe6e --- /dev/null +++ b/Documentation/fetch-options.txt @@ -0,0 +1,86 @@ +--all:: + Fetch all remotes. + +-a:: +--append:: + Append ref names and object names of fetched refs to the + existing contents of `.git/FETCH_HEAD`. Without this + option old data in `.git/FETCH_HEAD` will be overwritten. + +--depth=<depth>:: + Deepen the history of a 'shallow' repository created by + `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1]) + by the specified number of commits. + +ifndef::git-pull[] +--dry-run:: + Show what would be done, without making any changes. +endif::git-pull[] + +-f:: +--force:: + When 'git-fetch' is used with `<rbranch>:<lbranch>` + refspec, it refuses to update the local branch + `<lbranch>` unless the remote branch `<rbranch>` it + fetches is a descendant of `<lbranch>`. This option + overrides that check. + +-k:: +--keep:: + Keep downloaded pack. + +ifndef::git-pull[] +--multiple:: + Allow several <repository> and <group> arguments to be + specified. No <refspec>s may be specified. + +--prune:: + After fetching, remove any remote tracking branches which + no longer exist on the remote. +endif::git-pull[] + +ifdef::git-pull[] +--no-tags:: +endif::git-pull[] +ifndef::git-pull[] +-n:: +--no-tags:: +endif::git-pull[] + By default, tags that point at objects that are downloaded + from the remote repository are fetched and stored locally. + This option disables this automatic tag following. + +-t:: +--tags:: + 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. + +-u:: +--update-head-ok:: + By default 'git-fetch' refuses to update the head which + corresponds to the current branch. This flag disables the + check. This is purely for the internal use for 'git-pull' + to communicate with 'git-fetch', and unless you are + implementing your own Porcelain you are not supposed to + use it. + +--upload-pack <upload-pack>:: + When given, and the repository to fetch from is handled + by 'git-fetch-pack', '--exec=<upload-pack>' is passed to + the command to specify non-default path for the command + run on the other end. + +ifndef::git-pull[] +-q:: +--quiet:: + Pass --quiet to git-fetch-pack and silence any other internally + used git commands. + +-v:: +--verbose:: + Be verbose. +endif::git-pull[] diff --git a/Documentation/fix-texi.perl b/Documentation/fix-texi.perl new file mode 100755 index 0000000000..ff7d78f620 --- /dev/null +++ b/Documentation/fix-texi.perl @@ -0,0 +1,15 @@ +#!/usr/bin/perl -w + +while (<>) { + if (/^\@setfilename/) { + $_ = "\@setfilename git.info\n"; + } elsif (/^\@direntry/) { + print '@dircategory Development +@direntry +* Git: (git). A fast distributed revision control system +@end direntry +'; } + unless (/^\@direntry/../^\@end direntry/) { + print; + } +} diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt new file mode 100644 index 0000000000..e93e606f45 --- /dev/null +++ b/Documentation/git-add.txt @@ -0,0 +1,302 @@ +git-add(1) +========== + +NAME +---- +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] [--] [<filepattern>...] + +DESCRIPTION +----------- +This command adds the current content of new or modified files to the +index, thus staging that content for inclusion in the next commit. + +The "index" holds a snapshot of the content of the working tree, and it +is this snapshot that is taken as the contents of the next commit. Thus +after making any changes to the working directory, and before running +the commit command, you must use the 'add' command to add any new or +modified files to the index. + +This command can be performed multiple times before a commit. It only +adds the content of the specified file(s) at the time the add command is +run; if you want subsequent changes included in the next commit, then +you must run 'git add' again to add the new content to the index. + +The 'git status' command can be used to obtain a summary of which +files have changes that are staged for the next commit. + +The 'git add' command will not add ignored files by default. If any +ignored files were explicitly specified on the command line, 'git add' +will fail with a list of ignored files. Ignored files reached by +directory recursion or filename globbing performed by Git (quote your +globs before the shell) will be silently ignored. The 'add' command can +be used to add ignored files with the `-f` (force) option. + +Please see linkgit:git-commit[1] for alternative ways to add content to a +commit. + + +OPTIONS +------- +<filepattern>...:: + 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. + +-n:: +--dry-run:: + Don't actually add the file(s), just show if they exist. + +-v:: +--verbose:: + Be verbose. + +-f:: +--force:: + Allow adding otherwise ignored files. + +-i:: +--interactive:: + Add modified contents in the working tree interactively to + the index. Optional path arguments may be supplied to limit + operation to a subset of the working tree. See ``Interactive + mode'' for details. + +-p:: +--patch:: + Interactively choose hunks of patch between the index and the + work tree and add them to the index. This gives the user a chance + to review the difference before adding modified contents to the + index. ++ +This effectively runs `add --interactive`, but bypasses the +initial command menu and directly jumps to the `patch` subcommand. +See ``Interactive mode'' for details. + +-e, \--edit:: + Open the diff vs. the index in an editor and let the user + edit it. After the editor was closed, adjust the hunk headers + and apply the patch to the index. ++ +*NOTE*: Obviously, if you change anything else than the first character +on lines beginning with a space or a minus, the patch will no longer +apply. + +-u:: +--update:: + Update only files that git already knows about, staging modified + content for commit and marking deleted files for removal. This + is similar + to what "git commit -a" does in preparation for making a commit, + except that the update is limited to paths specified on the + command line. If no paths are specified, all tracked files in the + current directory and its subdirectories are updated. + +-A:: +--all:: + Update files that git already knows about (same as '\--update') + and add all untracked files that are not ignored by '.gitignore' + mechanism. + + +-N:: +--intent-to-add:: + Record only the fact that the path will be added later. An entry + for the path is placed in the index with no content. This is + useful for, among other things, showing the unstaged content of + such files with 'git diff' and committing them with 'git commit + -a'. + +--refresh:: + Don't add the file(s), but only refresh their stat() + information in the index. + +--ignore-errors:: + If some files could not be added because of errors indexing + them, do not abort the operation, but continue adding the + others. The command shall still exit with non-zero status. + +\--:: + This option can be used to separate command-line options from + the list of files, (useful when filenames might be mistaken + for command-line options). + + +Configuration +------------- + +The optional configuration variable 'core.excludesfile' indicates a path to a +file containing patterns of file names to exclude from git-add, similar to +$GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to +those in info/exclude. See linkgit:gitrepository-layout[5]. + + +EXAMPLES +-------- + +* Adds content from all `\*.txt` files under `Documentation` directory +and its subdirectories: ++ +------------ +$ git add Documentation/\\*.txt +------------ ++ +Note that the asterisk `\*` is quoted from the shell in this +example; this lets the command include the files from +subdirectories of `Documentation/` directory. + +* Considers adding content from all git-*.sh scripts: ++ +------------ +$ git add git-*.sh +------------ ++ +Because this example lets the shell expand the asterisk (i.e. you are +listing the files explicitly), it does not consider +`subdir/git-foo.sh`. + +Interactive mode +---------------- +When the command enters the interactive mode, it shows the +output of the 'status' subcommand, and then 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: status 2: update 3: revert 4: add untracked + 5: patch 6: diff 7: quit 8: help + What now> 1 +------------ + +You also could say "s" or "sta" or "status" above as long as the +choice is unique. + +The main command loop has 6 subcommands (plus help and quit). + +status:: + + This shows the change between HEAD and index (i.e. what will be + committed if you say "git commit"), and between index and + working tree files (i.e. what you could stage further before + "git commit" using "git-add") for each path. A sample output + looks like this: ++ +------------ + staged unstaged path + 1: binary nothing foo.png + 2: +403/-35 +1/-1 git-add--interactive.perl +------------ ++ +It shows that foo.png has differences from HEAD (but that is +binary so line count cannot be shown) and there is no +difference between indexed copy and the working tree +version (if the working tree version were also different, +'binary' would have been shown in place of 'nothing'). The +other file, git-add--interactive.perl, has 403 lines added +and 35 lines deleted if you commit what is in the index, but +working tree file has further modifications (one addition and +one deletion). + +update:: + + This shows the status information and issues an "Update>>" + prompt. When the prompt ends with double '>>', you can + make more than one selection, concatenated with whitespace or + comma. Also you can say ranges. E.g. "2-5 7,9" to choose + 2,3,4,5,7,9 from the list. If the second number in a range is + omitted, all remaining patches are taken. E.g. "7-" to choose + 7,8,9 from the list. You can say '*' to choose everything. ++ +What you chose are then highlighted with '*', +like this: ++ +------------ + staged unstaged path + 1: binary nothing foo.png +* 2: +403/-35 +1/-1 git-add--interactive.perl +------------ ++ +To remove selection, prefix the input with `-` +like this: ++ +------------ +Update>> -2 +------------ ++ +After making the selection, answer with an empty line to stage the +contents of working tree files for selected paths in the index. + +revert:: + + This has a very similar UI to 'update', and the staged + information for selected paths are reverted to that of the + HEAD version. Reverting new paths makes them untracked. + +add untracked:: + + This has a very similar UI to 'update' and + 'revert', and lets you add untracked paths to the index. + +patch:: + + This lets you choose one path out of a 'status' like selection. + After choosing the path, it presents the diff between the index + and the working tree file and asks you if you want to stage + the change of each hunk. You can say: + + y - stage this hunk + n - do not stage this hunk + q - quit, do not stage this hunk nor any of the remaining ones + a - stage this and all the remaining hunks in the file + d - do not stage this hunk nor any of the remaining hunks in the file + g - select a hunk to go to + / - search for a hunk matching the given regex + j - leave this hunk undecided, see next undecided hunk + J - leave this hunk undecided, see next hunk + k - leave this hunk undecided, see previous undecided hunk + K - leave this hunk undecided, see previous hunk + s - split the current hunk into smaller hunks + e - manually edit the current hunk + ? - print help ++ +After deciding the fate for all hunks, if there is any hunk +that was chosen, the index is updated with the selected hunks. + +diff:: + + This lets you review what will be committed (i.e. between + HEAD and index). + +SEE ALSO +-------- +linkgit:git-status[1] +linkgit:git-rm[1] +linkgit:git-reset[1] +linkgit:git-mv[1] +linkgit:git-commit[1] +linkgit:git-update-index[1] + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt new file mode 100644 index 0000000000..67ad5da9cc --- /dev/null +++ b/Documentation/git-am.txt @@ -0,0 +1,195 @@ +git-am(1) +========= + +NAME +---- +git-am - Apply a series of patches from a mailbox + + +SYNOPSIS +-------- +[verse] +'git am' [--signoff] [--keep] [--utf8 | --no-utf8] + [--3way] [--interactive] [--committer-date-is-author-date] + [--ignore-date] [--ignore-space-change | --ignore-whitespace] + [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>] + [--reject] [-q | --quiet] [--scissors | --no-scissors] + [<mbox> | <Maildir>...] +'git am' (--skip | --resolved | --abort) + +DESCRIPTION +----------- +Splits mail messages in a mailbox into commit log message, +authorship information and patches, and applies them to the +current branch. + +OPTIONS +------- +<mbox>|<Maildir>...:: + The list of mailbox files to read patches from. If you do not + supply this argument, the command reads from the standard input. + If you supply directories, they will be treated as Maildirs. + +-s:: +--signoff:: + Add a `Signed-off-by:` line to the commit message, using + the committer identity of yourself. + +-k:: +--keep:: + Pass `-k` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]). + +-c:: +--scissors:: + Remove everything in body before a scissors line (see + linkgit:git-mailinfo[1]). + +---no-scissors:: + Ignore scissors lines (see linkgit:git-mailinfo[1]). + +-q:: +--quiet:: + Be quiet. Only print error messages. + +-u:: +--utf8:: + Pass `-u` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]). + The proposed commit log message taken from the e-mail + is re-coded into UTF-8 encoding (configuration variable + `i18n.commitencoding` can be used to specify project's + preferred encoding if it is not UTF-8). ++ +This was optional in prior versions of git, but now it is the +default. You can use `--no-utf8` to override this. + +--no-utf8:: + Pass `-n` flag to 'git-mailinfo' (see + linkgit:git-mailinfo[1]). + +-3:: +--3way:: + When the patch does not apply cleanly, fall back on + 3-way merge if the patch records the identity of blobs + it is supposed to apply to and we have those blobs + available locally. + +--ignore-date:: +--ignore-space-change:: +--ignore-whitespace:: +--whitespace=<option>:: +-C<n>:: +-p<n>:: +--directory=<dir>:: +--reject:: + These flags are passed to the 'git-apply' (see linkgit:git-apply[1]) + program that applies + the patch. + +-i:: +--interactive:: + Run interactively. + +--committer-date-is-author-date:: + By default the command records the date from the e-mail + message as the commit author date, and uses the time of + commit creation as the committer date. This allows the + user to lie about the committer date by using the same + value as the author date. + +--ignore-date:: + By default the command records the date from the e-mail + message as the commit author date, and uses the time of + commit creation as the committer date. This allows the + user to lie about the author date by using the same + value as the committer date. + +--skip:: + Skip the current patch. This is only meaningful when + restarting an aborted patch. + +-r:: +--resolved:: + After a patch failure (e.g. attempting to apply + conflicting patch), the user has applied it by hand and + the index file stores the result of the application. + Make a commit using the authorship and commit log + extracted from the e-mail message and the current index + file, and continue. + +--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` + or `--skip` to handle the failure. This is solely + for internal use between 'git-rebase' and 'git-am'. + +--abort:: + Restore the original branch and abort the patching operation. + +DISCUSSION +---------- + +The commit author name is taken from the "From: " line of the +message, and commit author date is taken from the "Date: " line +of the message. The "Subject: " line is used as the title of +the commit, after stripping common prefix "[PATCH <anything>]". +The "Subject: " line is supposed to concisely describe what the +commit is about in one line of text. + +"From: " and "Subject: " lines starting the body override the respective +commit author name and title values taken from the headers. + +The commit message is formed by the title taken from the +"Subject: ", a blank line and the body of the message up to +where the patch begins. Excess whitespace at the end of each +line is automatically stripped. + +The patch is expected to be inline, directly following the +message. Any line that is of the form: + +* three-dashes and end-of-line, or +* a line that begins with "diff -", or +* a line that begins with "Index: " + +is taken as the beginning of a patch, and the commit log message +is terminated before the first occurrence of such a line. + +When initially invoking `git am`, you give it the names of the mailboxes +to process. Upon seeing the first patch that does not apply, it +aborts in the middle. You can recover from this in one of two ways: + +. skip the current patch by re-running the command with the '--skip' + option. + +. 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. + +The command refuses to process new mailboxes while the `.git/rebase-apply` +directory exists, so if you decide to start over from scratch, +run `rm -f -r .git/rebase-apply` before running the command with mailbox +names. + +Before any patches are applied, ORIG_HEAD is set to the tip of the +current branch. This is useful if you have problems with multiple +commits, like running 'git am' on the wrong branch or an error in the +commits that is more easily fixed by changing the mailbox (e.g. +errors in the "From:" lines). + + +SEE ALSO +-------- +linkgit:git-apply[1]. + + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-annotate.txt b/Documentation/git-annotate.txt new file mode 100644 index 0000000000..0590eec056 --- /dev/null +++ b/Documentation/git-annotate.txt @@ -0,0 +1,36 @@ +git-annotate(1) +=============== + +NAME +---- +git-annotate - Annotate file lines with commit information + +SYNOPSIS +-------- +'git annotate' [options] file [revision] + +DESCRIPTION +----------- +Annotates each line in the given file with information from the commit +which introduced the line. Optionally annotates from a given revision. + +The only difference between this command and linkgit:git-blame[1] is that +they use slightly different output formats, and this command exists only +for backward compatibility to support existing scripts, and provide a more +familiar command name for people coming from other SCM systems. + +OPTIONS +------- +include::blame-options.txt[] + +SEE ALSO +-------- +linkgit:git-blame[1] + +AUTHOR +------ +Written by Ryan Anderson <ryan@michonline.com>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt new file mode 100644 index 0000000000..c2528a7654 --- /dev/null +++ b/Documentation/git-apply.txt @@ -0,0 +1,255 @@ +git-apply(1) +============ + +NAME +---- +git-apply - Apply a patch to files and/or to the index + + +SYNOPSIS +-------- +[verse] +'git apply' [--stat] [--numstat] [--summary] [--check] [--index] + [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse] + [--allow-binary-replacement | --binary] [--reject] [-z] + [-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached] + [--ignore-space-change | --ignore-whitespace ] + [--whitespace=<nowarn|warn|fix|error|error-all>] + [--exclude=PATH] [--include=PATH] [--directory=<root>] + [--verbose] [<patch>...] + +DESCRIPTION +----------- +Reads the supplied diff output (i.e. "a patch") and applies it to files. +With the `--index` option the patch is also applied to the index, and +with the `--cache` option the patch is only applied to the index. +Without these options, the command applies the patch only to files, +and does not require them to be in a git repository. + +OPTIONS +------- +<patch>...:: + The files to read the patch from. '-' can be used to read + from the standard input. + +--stat:: + Instead of applying the patch, output diffstat for the + input. Turns off "apply". + +--numstat:: + Similar to `--stat`, but shows the number of added and + deleted lines in decimal notation and the pathname without + abbreviation, to make it more machine friendly. For + binary files, outputs two `-` instead of saying + `0 0`. Turns off "apply". + +--summary:: + Instead of applying the patch, output a condensed + summary of information obtained from git diff extended + headers, such as creations, renames and mode changes. + Turns off "apply". + +--check:: + Instead of applying the patch, see if the patch is + applicable to the current working tree and/or the index + file and detects errors. Turns off "apply". + +--index:: + When `--check` is in effect, or when applying the patch + (which is the default when none of the options that + disables it is in effect), make sure the patch is + applicable to what the current index file records. If + the file to be patched in the working tree is not + up-to-date, it is flagged as an error. This flag also + causes the index file to be updated. + +--cached:: + Apply a patch without touching the working tree. Instead take the + cached data, apply the patch, and store the result in the index + without using the working tree. This implies `--index`. + +--build-fake-ancestor=<file>:: + Newer 'git-diff' output has embedded 'index information' + for each blob to help identify the original version that + the patch applies to. When this flag is given, and if + the original versions of the blobs are available locally, + builds a temporary index containing those blobs. ++ +When a pure mode change is encountered (which has no index information), +the information is read from the current index instead. + +-R:: +--reverse:: + Apply the patch in reverse. + +--reject:: + For atomicity, 'git-apply' by default fails the whole patch and + does not touch the working tree when some of the hunks + do not apply. This option makes it apply + the parts of the patch that are applicable, and leave the + rejected hunks in corresponding *.rej files. + +-z:: + When `--numstat` has been given, do not munge pathnames, + but use a NUL-terminated machine-readable format. ++ +Without this option, each pathname output will have TAB, LF, double quotes, +and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`, +respectively, and the pathname will be enclosed in double quotes if +any of those replacements occurred. + +-p<n>:: + Remove <n> leading slashes from traditional diff paths. The + default is 1. + +-C<n>:: + Ensure at least <n> lines of surrounding context match before + and after each change. When fewer lines of surrounding + context exist they all must match. By default no context is + ever ignored. + +--unidiff-zero:: + By default, 'git-apply' expects that the patch being + applied is a unified diff with at least one line of context. + This provides good safety measures, but breaks down when + applying a diff generated with `--unified=0`. To bypass these + checks use `--unidiff-zero`. ++ +Note, for the reasons stated above usage of context-free patches is +discouraged. + +--apply:: + If you use any of the options marked "Turns off + 'apply'" above, 'git-apply' reads and outputs the + requested information without actually applying the + patch. Give this flag after those flags to also apply + the patch. + +--no-add:: + When applying a patch, ignore additions made by the + patch. This can be used to extract the common part between + two files by first running 'diff' on them and applying + the result with this option, which would apply the + deletion part but not the addition part. + +--allow-binary-replacement:: +--binary:: + Historically we did not allow binary patch applied + without an explicit permission from the user, and this + flag was the way to do so. Currently we always allow binary + patch application, so this is a no-op. + +--exclude=<path-pattern>:: + Don't apply changes to files matching the given path pattern. This can + be useful when importing patchsets, where you want to exclude certain + files or directories. + +--include=<path-pattern>:: + Apply changes to files matching the given path pattern. This can + be useful when importing patchsets, where you want to include certain + files or directories. ++ +When `--exclude` and `--include` patterns are used, they are examined in the +order they appear on the command line, and the first match determines if a +patch to each path is used. A patch to a path that does not match any +include/exclude pattern is used by default if there is no include pattern +on the command line, and ignored if there is any include pattern. + +--ignore-space-change:: +--ignore-whitespace:: + When applying a patch, ignore changes in whitespace in context + lines if necessary. + Context lines will preserve their whitespace, and they will not + undergo whitespace fixing regardless of the value of the + `--whitespace` option. New lines will still be fixed, though. + +--whitespace=<action>:: + When applying a patch, detect a new or modified line that has + whitespace errors. What are considered whitespace errors is + controlled by `core.whitespace` configuration. By default, + trailing whitespaces (including lines that solely consist of + whitespaces) and a space character that is immediately followed + by a tab character inside the initial indent of the line are + considered whitespace errors. ++ +By default, the command outputs warning messages but applies the patch. +When `git-apply` is used for statistics and not applying a +patch, it defaults to `nowarn`. ++ +You can use different `<action>` values to control this +behavior: ++ +* `nowarn` turns off the trailing whitespace warning. +* `warn` outputs warnings for a few such errors, but applies the + patch as-is (default). +* `fix` outputs warnings for a few such errors, and applies the + patch after fixing them (`strip` is a synonym --- the tool + used to consider only trailing whitespace characters as errors, and the + fix involved 'stripping' them, but modern gits do more). +* `error` outputs warnings for a few such errors, and refuses + to apply the patch. +* `error-all` is similar to `error` but shows all errors. + +--inaccurate-eof:: + Under certain circumstances, some versions of 'diff' do not correctly + detect a missing new-line at the end of the file. As a result, patches + created by such 'diff' programs do not record incomplete lines + correctly. This option adds support for applying such patches by + working around this bug. + +-v:: +--verbose:: + Report progress to stderr. By default, only a message about the + current patch being applied will be printed. This option will cause + additional information to be reported. + +--recount:: + Do not trust the line counts in the hunk headers, but infer them + by inspecting the patch (e.g. after editing the patch without + adjusting the hunk headers appropriately). + +--directory=<root>:: + Prepend <root> to all filenames. If a "-p" argument was also passed, + it is applied before prepending the new root. ++ +For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh` +can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by +running `git apply --directory=modules/git-gui`. + +Configuration +------------- + +apply.ignorewhitespace:: + Set to 'change' if you want changes in whitespace to be ignored by default. + Set to one of: no, none, never, false if you want changes in + whitespace to be significant. +apply.whitespace:: + When no `--whitespace` flag is given from the command + line, this configuration item is used as the default. + +Submodules +---------- +If the patch contains any changes to submodules then 'git-apply' +treats these changes as follows. + +If `--index` is specified (explicitly or implicitly), then the submodule +commits must match the index exactly for the patch to apply. If any +of the submodules are checked-out, then these check-outs are completely +ignored, i.e., they are not required to be up-to-date or clean and they +are not updated. + +If `--index` is not specified, then the submodule commits in the patch +are ignored and only the absence or presence of the corresponding +subdirectory is checked and (if possible) updated. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt new file mode 100644 index 0000000000..c7a6e3ec05 --- /dev/null +++ b/Documentation/git-archimport.txt @@ -0,0 +1,120 @@ +git-archimport(1) +================= + +NAME +---- +git-archimport - Import an Arch repository into git + + +SYNOPSIS +-------- +[verse] +'git archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir] + <archive/branch>[:<git-branch>] ... + +DESCRIPTION +----------- +Imports a project from one or more Arch repositories. It will follow branches +and repositories within the namespaces defined by the <archive/branch> +parameters supplied. If it cannot find the remote branch a merge comes from +it will just import it as a regular commit. If it can find it, it will mark it +as a merge whenever possible (see discussion below). + +The script expects you to provide the key roots where it can start the import +from an 'initial import' or 'tag' type of Arch commit. It will follow and +import new branches within the provided roots. + +It expects to be dealing with one project only. If it sees +branches that have different roots, it will refuse to run. In that case, +edit your <archive/branch> parameters to define clearly the scope of the +import. + +'git-archimport' uses `tla` extensively in the background to access the +Arch repository. +Make sure you have a recent version of `tla` available in the path. `tla` must +know about the repositories you pass to 'git-archimport'. + +For the initial import, 'git-archimport' expects to find itself in an empty +directory. To follow the development of a project that uses Arch, rerun +'git-archimport' with the same parameters as the initial import to perform +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> +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 +"PROJECT--devo--VERSION" branch to "master". + +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. + + +MERGES +------ +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 +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 +patches that have been traded out-of-sequence between the branches. + +OPTIONS +------- + +-h:: + Display usage. + +-v:: + Verbose output. + +-T:: + Many tags. Will create a tag for every commit, reflecting the commit + name in the Arch repository. + +-f:: + Use the fast patchset import strategy. This can be significantly + faster for large trees, but cannot handle directory renames or + permissions changes. The default strategy is slow and safe. + +-o:: + Use this for compatibility with old-style branch names used by + earlier versions of 'git-archimport'. Old-style branch names + were category--branch, whereas new-style branch names are + archive,category--branch--version. In both cases, names given + on the command-line will override the automatically-generated + ones. + +-D <depth>:: + Follow merge ancestry and attempt to import trees that have been + merged from. Specify a depth greater than 1 if patch logs have been + pruned. + +-a:: + Attempt to auto-register archives at http://mirrors.sourcecontrol.net + This is particularly useful with the -D option. + +-t <tmpdir>:: + Override the default tempdir. + + +<archive/branch>:: + Archive/branch identifier in a format that `tla log` understands. + + +Author +------ +Written by Martin Langhoff <martin@catalyst.net.nz>. + +Documentation +-------------- +Documentation by Junio C Hamano, Martin Langhoff and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt new file mode 100644 index 0000000000..e57979198b --- /dev/null +++ b/Documentation/git-archive.txt @@ -0,0 +1,158 @@ +git-archive(1) +============== + +NAME +---- +git-archive - Create an archive of files from a named tree + + +SYNOPSIS +-------- +[verse] +'git archive' [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>] + [-o | --output=<file>] [--worktree-attributes] + [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish> + [path...] + +DESCRIPTION +----------- +Creates an archive of the specified format containing the tree +structure for the named tree, and writes it out to the standard +output. If <prefix> is specified it is +prepended to the filenames in the archive. + +'git-archive' behaves differently when given a tree ID versus when +given a commit ID or tag ID. In the first case the current time is +used as the modification time of each file in the archive. In the latter +case the commit time as recorded in the referenced commit object is +used instead. Additionally the commit ID is stored in a global +extended pax header if the tar format is used; it can be extracted +using 'git-get-tar-commit-id'. In ZIP files it is stored as a file +comment. + +OPTIONS +------- + +--format=<fmt>:: + Format of the resulting archive: 'tar' or 'zip'. If this option + is not given, and the output file is specified, the format is + inferred from the filename if possible (e.g. writing to "foo.zip" + makes the output to be in the zip format). Otherwise the output + format is `tar`. + +-l:: +--list:: + Show all available formats. + +-v:: +--verbose:: + Report progress to stderr. + +--prefix=<prefix>/:: + Prepend <prefix>/ to each filename in the archive. + +-o <file>:: +--output=<file>:: + Write the archive to <file> instead of stdout. + +--worktree-attributes:: + Look for attributes in .gitattributes in working directory too. + +<extra>:: + This can be any options that the archiver backend understands. + See next section. + +--remote=<repo>:: + Instead of making a tar archive from the local repository, + retrieve a tar archive from a remote repository. + +--exec=<git-upload-archive>:: + Used with --remote to specify the path to the + 'git-upload-archive' on the remote side. + +<tree-ish>:: + The tree or commit to produce an archive for. + +path:: + Without an optional path parameter, all files and subdirectories + of the current working directory are included in the archive. + If one or more paths are specified, only these are included. + +BACKEND EXTRA OPTIONS +--------------------- + +zip +~~~ +-0:: + Store the files instead of deflating them. +-9:: + Highest and slowest compression level. You can specify any + number from 1 to 9 to adjust compression speed and ratio. + + +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. + +ATTRIBUTES +---------- + +export-ignore:: + Files and directories with the attribute export-ignore won't be + added to archive files. See linkgit:gitattributes[5] for details. + +export-subst:: + If the attribute export-subst is set for a file then git will + expand several placeholders when adding this file to an archive. + See linkgit:gitattributes[5] for details. + +EXAMPLES +-------- +git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -):: + + Create a tar archive that contains the contents of the + latest commit on the current branch, and extract it in the + `/var/tmp/junk` directory. + +git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz:: + + Create a compressed tarball for v1.4.0 release. + +git archive --format=tar --prefix=git-1.4.0/ v1.4.0{caret}\{tree\} | gzip >git-1.4.0.tar.gz:: + + Create a compressed tarball for v1.4.0 release, but without a + global extended pax header. + +git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip:: + + Put everything in the current head's Documentation/ directory + into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'. + +git archive -o latest.zip HEAD:: + + Create a Zip archive that contains the contents of the latest + commit on the current branch. Note that the output format is + inferred by the extension of the output file. + + +SEE ALSO +-------- +linkgit:gitattributes[5] + +Author +------ +Written by Franck Bui-Huu and Rene Scharfe. + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt new file mode 100644 index 0000000000..6b7b2e5497 --- /dev/null +++ b/Documentation/git-bisect-lk2009.txt @@ -0,0 +1,1358 @@ +Fighting regressions with git bisect +==================================== +:Author: Christian Couder +:Email: chriscool@tuxfamily.org +:Date: 2009/11/08 + +Abstract +-------- + +"git bisect" enables software users and developers to easily find the +commit that introduced a regression. We show why it is important to +have good tools to fight regressions. We describe how "git bisect" +works from the outside and the algorithms it uses inside. Then we +explain how to take advantage of "git bisect" to improve current +practices. And we discuss how "git bisect" could improve in the +future. + + +Introduction to "git bisect" +---------------------------- + +Git is a Distributed Version Control system (DVCS) created by Linus +Torvalds and maintained by Junio Hamano. + +In Git like in many other Version Control Systems (VCS), the different +states of the data that is managed by the system are called +commits. And, as VCS are mostly used to manage software source code, +sometimes "interesting" changes of behavior in the software are +introduced in some commits. + +In fact people are specially interested in commits that introduce a +"bad" behavior, called a bug or a regression. They are interested in +these commits because a commit (hopefully) contains a very small set +of source code changes. And it's much easier to understand and +properly fix a problem when you only need to check a very small set of +changes, than when you don't know where look in the first place. + +So to help people find commits that introduce a "bad" behavior, the +"git bisect" set of commands was invented. And it follows of course +that in "git bisect" parlance, commits where the "interesting +behavior" is present are called "bad" commits, while other commits are +called "good" commits. And a commit that introduce the behavior we are +interested in is called a "first bad commit". Note that there could be +more than one "first bad commit" in the commit space we are searching. + +So "git bisect" is designed to help find a "first bad commit". And to +be as efficient as possible, it tries to perform a binary search. + + +Fighting regressions overview +----------------------------- + +Regressions: a big problem +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Regressions are a big problem in the software industry. But it's +difficult to put some real numbers behind that claim. + +There are some numbers about bugs in general, like a NIST study in +2002 <<1>> that said: + +_____________ +Software bugs, or errors, are so prevalent and so detrimental that +they cost the U.S. economy an estimated $59.5 billion annually, or +about 0.6 percent of the gross domestic product, according to a newly +released study commissioned by the Department of Commerce's National +Institute of Standards and Technology (NIST). At the national level, +over half of the costs are borne by software users and the remainder +by software developers/vendors. The study also found that, although +all errors cannot be removed, more than a third of these costs, or an +estimated $22.2 billion, could be eliminated by an improved testing +infrastructure that enables earlier and more effective identification +and removal of software defects. These are the savings associated with +finding an increased percentage (but not 100 percent) of errors closer +to the development stages in which they are introduced. Currently, +over half of all errors are not found until "downstream" in the +development process or during post-sale software use. +_____________ + +And then: + +_____________ +Software developers already spend approximately 80 percent of +development costs on identifying and correcting defects, and yet few +products of any type other than software are shipped with such high +levels of errors. +_____________ + +Eventually the conclusion started with: + +_____________ +The path to higher software quality is significantly improved software +testing. +_____________ + +There are other estimates saying that 80% of the cost related to +software is about maintenance <<2>>. + +Though, according to Wikipedia <<3>>: + +_____________ +A common perception of maintenance is that it is merely fixing +bugs. However, studies and surveys over the years have indicated that +the majority, over 80%, of the maintenance effort is used for +non-corrective actions (Pigosky 1997). This perception is perpetuated +by users submitting problem reports that in reality are functionality +enhancements to the system. +_____________ + +But we can guess that improving on existing software is very costly +because you have to watch out for regressions. At least this would +make the above studies consistent among themselves. + +Of course some kind of software is developed, then used during some +time without being improved on much, and then finally thrown away. In +this case, of course, regressions may not be a big problem. But on the +other hand, there is a lot of big software that is continually +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 +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 +after that about 7 or 8 more rc versions will appear with around one +week between each of them, before the final release. + +The time between the first rc release and the final release is +supposed to be used to test rc versions and fight bugs and especially +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 +developer) says about his use of git bisect: + +_____________ +I most actively use it during the merge window (when a lot of trees +get merged upstream and when the influx of bugs is the highest) - and +yes, there have been cases that i used it multiple times a day. My +average is roughly once a day. +_____________ + +So regressions are fought all the time by developers, and indeed it is +well known that bugs should be fixed as soon as possible, so as soon +as they are found. That's why it is interesting to have good tools for +this purpose. + +Other tools to fight regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +So what are the tools used to fight regressions? They are nearly the +same as those used to fight regular bugs. The only specific tools are +test suites and tools similar as "git bisect". + +Test suites are very nice. But when they are used alone, they are +supposed to be used so that all the tests are checked after each +commit. This means that they are not very efficient, because many +tests are run for no interesting result, and they suffer from +combinational explosion. + +In fact the problem is that big software often has many different +configuration options and that each test case should pass for each +configuration after each commit. So if you have for each release: N +configurations, M commits and T test cases, you should perform: + +------------- +N * M * T tests +------------- + +where N, M and T are all growing with the size your software. + +So very soon it will not be possible to completely test everything. + +And if some bugs slip through your test suite, then you can add a test +to your test suite. But if you want to use your new improved test +suite to find where the bug slipped in, then you will either have to +emulate a bisection process or you will perhaps bluntly test each +commit backward starting from the "bad" commit you have which may be +very wasteful. + +"git bisect" overview +--------------------- + +Starting a bisection +~~~~~~~~~~~~~~~~~~~~ + +The first "git bisect" subcommand to use is "git bisect start" to +start the search. Then bounds must be set to limit the commit +space. This is done usually by giving one "bad" and at least one +"good" commit. They can be passed in the initial call to "git bisect +start" like this: + +------------- +$ git bisect start [BAD [GOOD...]] +------------- + +or they can be set using: + +------------- +$ git bisect bad [COMMIT] +------------- + +and: + +------------- +$ git bisect good [COMMIT...] +------------- + +where BAD, GOOD and COMMIT are all names that can be resolved to a +commit. + +Then "git bisect" will checkout a commit of its choosing and ask the +user to test it, like this: + +------------- +$ git bisect start v2.6.27 v2.6.25 +Bisecting: 10928 revisions left to test after this (roughly 14 steps) +[2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit +------------- + +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 +example "git blame" or "git log -S<string>"). + +Driving a bisection manually +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +At this point there are basically 2 ways to drive the search. It can +be driven manually by the user or it can be driven automatically by a +script or a command. + +If the user is driving it, then at each step of the search, the user +will have to test the current commit and say if it is "good" or "bad" +using the "git bisect good" or "git bisect bad" commands respectively +that have been described above. For example: + +------------- +$ git bisect bad +Bisecting: 5480 revisions left to test after this (roughly 13 steps) +[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm +------------- + +And after a few more steps like that, "git bisect" will eventually +find a first bad commit: + +------------- +$ git bisect bad +2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit +commit 2ddcca36c8bcfa251724fe342c8327451988be0d +Author: Linus Torvalds <torvalds@linux-foundation.org> +Date: Sat May 3 11:59:44 2008 -0700 + + Linux 2.6.26-rc1 + +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +------------- + +At this point we can see what the commit does, check it out (if it's +not already checked out) or tinker with it, for example: + +------------- +$ git show HEAD +commit 2ddcca36c8bcfa251724fe342c8327451988be0d +Author: Linus Torvalds <torvalds@linux-foundation.org> +Date: Sat May 3 11:59:44 2008 -0700 + + Linux 2.6.26-rc1 + +diff --git a/Makefile b/Makefile +index 5cf8258..4492984 100644 +--- a/Makefile ++++ b/Makefile +@@ -1,7 +1,7 @@ + VERSION = 2 + PATCHLEVEL = 6 +-SUBLEVEL = 25 +-EXTRAVERSION = ++SUBLEVEL = 26 ++EXTRAVERSION = -rc1 + NAME = Funky Weasel is Jiggy wit it + + # *DOCUMENTATION* +------------- + +And when we are finished we can use "git bisect reset" to go back to +the branch we were in before we started bisecting: + +------------- +$ git bisect reset +Checking out files: 100% (21549/21549), done. +Previous HEAD position was 2ddcca3... Linux 2.6.26-rc1 +Switched to branch 'master' +------------- + +Driving a bisection automatically +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The other way to drive the bisection process is to tell "git bisect" +to launch a script or command at each bisection step to know if the +current commit is "good" or "bad". To do that, we use the "git bisect +run" command. For example: + +------------- +$ git bisect start v2.6.27 v2.6.25 +Bisecting: 10928 revisions left to test after this (roughly 14 steps) +[2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit +$ +$ git bisect run grep '^SUBLEVEL = 25' Makefile +running grep ^SUBLEVEL = 25 Makefile +Bisecting: 5480 revisions left to test after this (roughly 13 steps) +[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm +running grep ^SUBLEVEL = 25 Makefile +SUBLEVEL = 25 +Bisecting: 2740 revisions left to test after this (roughly 12 steps) +[671294719628f1671faefd4882764886f8ad08cb] V4L/DVB(7879): Adding cx18 Support for mxl5005s +... +... +running grep ^SUBLEVEL = 25 Makefile +Bisecting: 0 revisions left to test after this (roughly 0 steps) +[2ddcca36c8bcfa251724fe342c8327451988be0d] Linux 2.6.26-rc1 +running grep ^SUBLEVEL = 25 Makefile +2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit +commit 2ddcca36c8bcfa251724fe342c8327451988be0d +Author: Linus Torvalds <torvalds@linux-foundation.org> +Date: Sat May 3 11:59:44 2008 -0700 + + Linux 2.6.26-rc1 + +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +bisect run success +------------- + +In this example, we passed "grep '^SUBLEVEL = 25' Makefile" as +parameter to "git bisect run". This means that at each step, the grep +command we passed will be launched. And if it exits with code 0 (that +means success) then git bisect will mark the current state as +"good". If it exits with code 1 (or any code between 1 and 127 +included, except the special code 125), then the current state will be +marked as "bad". + +Exit code between 128 and 255 are special to "git bisect run". They +make it stop immediately the bisection process. This is useful for +example if the command passed takes too long to complete, because you +can kill it with a signal and it will stop the bisection process. + +It can also be useful in scripts passed to "git bisect run" to "exit +255" if some very abnormal situation is detected. + +Avoiding untestable commits +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Sometimes it happens that the current state cannot be tested, for +example if it does not compile because there was a bug preventing it +at that time. This is what the special exit code 125 is for. It tells +"git bisect run" that the current commit should be marked as +untestable and that another one should be chosen and checked out. + +If the bisection process is driven manually, you can use "git bisect +skip" to do the same thing. (In fact the special exit code 125 makes +"git bisect run" use "git bisect skip" in the background.) + +Or if you want more control, you can inspect the current state using +for example "git bisect visualize". It will launch gitk (or "git log" +if the DISPLAY environment variable is not set) to help you find a +better bisection point. + +Either way, if you have a string of untestable commits, it might +happen that the regression you are looking for has been introduced by +one of these untestable commits. In this case it's not possible to +tell for sure which commit introduced the regression. + +So if you used "git bisect skip" (or the run script exited with +special code 125) you could get a result like this: + +------------- +There are only 'skip'ped commits left to test. +The first bad commit could be any of: +15722f2fa328eaba97022898a305ffc8172db6b1 +78e86cf3e850bd755bb71831f42e200626fbd1e0 +e15b73ad3db9b48d7d1ade32f8cd23a751fe0ace +070eab2303024706f2924822bfec8b9847e4ac1b +We cannot bisect more! +------------- + +Saving a log and replaying it +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you want to show other people your bisection process, you can get a +log using for example: + +------------- +$ git bisect log > bisect_log.txt +------------- + +And it is possible to replay it using: + +------------- +$ git bisect replay bisect_log.txt +------------- + + +"git bisect" details +-------------------- + +Bisection algorithm +~~~~~~~~~~~~~~~~~~~ + +As the Git commits form a directed acyclic graph (DAG), finding the +best bisection commit to test at each step is not so simple. Anyway +Linus found and implemented a "truly stupid" algorithm, later improved +by Junio Hamano, that works quite well. + +So the algorithm used by "git bisect" to find the best bisection +commit when there are no skipped commits is the following: + +1) keep only the commits that: + +a) are ancestor of the "bad" commit (including the "bad" commit itself), +b) are not ancestor of a "good" commit (excluding the "good" commits). + +This means that we get rid of the uninteresting commits in the DAG. + +For example if we start with a graph like this: + +------------- +G-Y-G-W-W-W-X-X-X-X + \ / + W-W-B + / +Y---G-W---W + \ / \ +Y-Y X-X-X-X + +-> time goes this way -> +------------- + +where B is the "bad" commit, "G" are "good" commits and W, X, and Y +are other commits, we will get the following graph after this first +step: + +------------- +W-W-W + \ + W-W-B + / +W---W +------------- + +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 +given by: + +------------- +git rev-list BAD --not GOOD1 GOOD2... +------------- + +Also note that we don't require the commits that are kept to be +descendants of a "good" commit. So in the following example, commits W +and Z will be kept: + +------------- +G-W-W-W-B + / +Z-Z +------------- + +2) starting from the "good" ends of the graph, associate to each +commit the number of ancestors it has plus one + +For example with the following graph where H is the "bad" commit and A +and D are some parents of some "good" commits: + +------------- +A-B-C + \ + F-G-H + / +D---E +------------- + +this will give: + +------------- +1 2 3 +A-B-C + \6 7 8 + F-G-H +1 2/ +D---E +------------- + +3) associate to each commit: min(X, N - X) + +where X is the value associated to the commit in step 2) and N is the +total number of commits in the graph. + +In the above example we have N = 8, so this will give: + +------------- +1 2 3 +A-B-C + \2 1 0 + F-G-H +1 2/ +D---E +------------- + +4) the best bisection point is the commit with the highest associated +number + +So in the above example the best bisection point is commit C. + +5) note that some shortcuts are implemented to speed up the algorithm + +As we know N from the beginning, we know that min(X, N - X) can't be +greater than N/2. So during steps 2) and 3), if we would associate N/2 +to a commit, then we know this is the best bisection point. So in this +case we can just stop processing any other commit and return the +current commit. + +Bisection algorithm debugging +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For any commit graph, you can see the number associated with each +commit using "git rev-list --bisect-all". + +For example, for the above graph, a command like: + +------------- +$ git rev-list --bisect-all BAD --not GOOD1 GOOD2 +------------- + +would output something like: + +------------- +e15b73ad3db9b48d7d1ade32f8cd23a751fe0ace (dist=3) +15722f2fa328eaba97022898a305ffc8172db6b1 (dist=2) +78e86cf3e850bd755bb71831f42e200626fbd1e0 (dist=2) +a1939d9a142de972094af4dde9a544e577ddef0e (dist=2) +070eab2303024706f2924822bfec8b9847e4ac1b (dist=1) +a3864d4f32a3bf5ed177ddef598490a08760b70d (dist=1) +a41baa717dd74f1180abf55e9341bc7a0bb9d556 (dist=1) +9e622a6dad403b71c40979743bb9d5be17b16bd6 (dist=0) +------------- + +Bisection algorithm discussed +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First let's define "best bisection point". We will say that a commit X +is a best bisection point or a best bisection commit if knowing its +state ("good" or "bad") gives as much information as possible whether +the state of the commit happens to be "good" or "bad". + +This means that the best bisection commits are the commits where the +following function is maximum: + +------------- +f(X) = min(information_if_good(X), information_if_bad(X)) +------------- + +where information_if_good(X) is the information we get if X is good +and information_if_bad(X) is the information we get if X is bad. + +Now we will suppose that there is only one "first bad commit". This +means that all its descendants are "bad" and all the other commits are +"good". And we will suppose that all commits have an equal probability +of being good or bad, or of being the first bad commit, so knowing the +state of c commits gives always the same amount of information +wherever these c commits are on the graph and whatever c is. (So we +suppose that these commits being for example on a branch or near a +good or a bad commit does not give more or less information). + +Let's also suppose that we have a cleaned up graph like one after step +1) in the bisection algorithm above. This means that we can measure +the information we get in terms of number of commit we can remove from +the graph.. + +And let's take a commit X in the graph. + +If X is found to be "good", then we know that its ancestors are all +"good", so we want to say that: + +------------- +information_if_good(X) = number_of_ancestors(X) (TRUE) +------------- + +And this is true because at step 1) b) we remove the ancestors of the +"good" commits. + +If X is found to be "bad", then we know that its descendants are all +"bad", so we want to say that: + +------------- +information_if_bad(X) = number_of_descendants(X) (WRONG) +------------- + +But this is wrong because at step 1) a) we keep only the ancestors of +the bad commit. So we get more information when a commit is marked as +"bad", because we also know that the ancestors of the previous "bad" +commit that are not ancestors of the new "bad" commit are not the +first bad commit. We don't know if they are good or bad, but we know +that they are not the first bad commit because they are not ancestor +of the new "bad" commit. + +So when a commit is marked as "bad" we know we can remove all the +commits in the graph except those that are ancestors of the new "bad" +commit. This means that: + +------------- +information_if_bad(X) = N - number_of_ancestors(X) (TRUE) +------------- + +where N is the number of commits in the (cleaned up) graph. + +So in the end this means that to find the best bisection commits we +should maximize the function: + +------------- +f(X) = min(number_of_ancestors(X), N - number_of_ancestors(X)) +------------- + +And this is nice because at step 2) we compute number_of_ancestors(X) +and so at step 3) we compute f(X). + +Let's take the following graph as an example: + +------------- + G-H-I-J + / \ +A-B-C-D-E-F O + \ / + K-L-M-N +------------- + +If we compute the following non optimal function on it: + +------------- +g(X) = min(number_of_ancestors(X), number_of_descendants(X)) +------------- + +we get: + +------------- + 4 3 2 1 + G-H-I-J +1 2 3 4 5 6/ \0 +A-B-C-D-E-F O + \ / + K-L-M-N + 4 3 2 1 +------------- + +but with the algorithm used by git bisect we get: + +------------- + 7 7 6 5 + G-H-I-J +1 2 3 4 5 6/ \0 +A-B-C-D-E-F O + \ / + K-L-M-N + 7 7 6 5 +------------- + +So we chose G, H, K or L as the best bisection point, which is better +than F. Because if for example L is bad, then we will know not only +that L, M and N are bad but also that G, H, I and J are not the first +bad commit (since we suppose that there is only one first bad commit +and it must be an ancestor of L). + +So the current algorithm seems to be the best possible given what we +initially supposed. + +Skip algorithm +~~~~~~~~~~~~~~ + +When some commits have been skipped (using "git bisect skip"), then +the bisection algorithm is the same for step 1) to 3). But then we use +roughly the following steps: + +6) sort the commit by decreasing associated value + +7) if the first commit has not been skipped, we can return it and stop +here + +8) otherwise filter out all the skipped commits in the sorted list + +9) use a pseudo random number generator (PRNG) to generate a random +number between 0 and 1 + +10) multiply this random number with its square root to bias it toward +0 + +11) multiply the result by the number of commits in the filtered list +to get an index into this list + +12) return the commit at the computed index + +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). + +But Ingo Molnar and H. Peter Anvin (another well known linux kernel +developer) both complained that sometimes the best bisection points +all happened to be in an area where all the commits are +untestable. And in this case the user was asked to test many +untestable commits, which could be very inefficient. + +Indeed untestable commits are often untestable because a breakage was +introduced at one time, and that breakage was fixed only after many +other commits were introduced. + +This breakage is of course most of the time unrelated to the breakage +we are trying to locate in the commit graph. But it prevents us to +know if the interesting "bad behavior" is present or not. + +So it is a fact that commits near an untestable commit have a high +probability of being untestable themselves. And the best bisection +commits are often found together too (due to the bisection algorithm). + +This is why it is a bad idea to just chose the next best unskipped +bisection commit when the first one has been skipped. + +We found that most commits on the graph may give quite a lot of +information when they are tested. And the commits that will not on +average give a lot of information are the one near the good and bad +commits. + +So using a PRNG with a bias to favor commits away from the good and +bad commits looked like a good choice. + +One obvious improvement to this algorithm would be to look for a +commit that has an associated value near the one of the best bisection +commit, and that is on another branch, before using the PRNG. Because +if such a commit exists, then it is not very likely to be untestable +too, so it will probably give more information than a nearly randomly +chosen one. + +Checking merge bases +~~~~~~~~~~~~~~~~~~~~ + +There is another tweak in the bisection algorithm that has not been +described in the "bisection algorithm" above. + +We supposed in the previous examples that the "good" commits were +ancestors of the "bad" commit. But this is not a requirement of "git +bisect". + +Of course the "bad" commit cannot be an ancestor of a "good" commit, +because the ancestors of the good commits are supposed to be +"good". And all the "good" commits must be related to the bad commit. +They cannot be on a branch that has no link with the branch of the +"bad" commit. But it is possible for a good commit to be related to a +bad commit and yet not be neither one of its ancestor nor one of its +descendants. + +For example, there can be a "main" branch, and a "dev" branch that was +forked of the main branch at a commit named "D" like this: + +------------- +A-B-C-D-E-F-G <--main + \ + H-I-J <--dev +------------- + +The commit "D" is called a "merge base" for branch "main" and "dev" +because it's the best common ancestor for these branches for a merge. + +Now let's suppose that commit J is bad and commit G is good and that +we apply the bisection algorithm like it has been previously +described. + +As described in step 1) b) of the bisection algorithm, we remove all +the ancestors of the good commits because they are supposed to be good +too. + +So we would be left with only: + +------------- +H-I-J +------------- + +But what happens if the first bad commit is "B" and if it has been +fixed in the "main" branch by commit "F"? + +The result of such a bisection would be that we would find that H is +the first bad commit, when in fact it's B. So that would be wrong! + +And yes it's can happen in practice that people working on one branch +are not aware that people working on another branch fixed a bug! It +could also happen that F fixed more than one bug or that it is a +revert of some big development effort that was not ready to be +released. + +In fact development teams often maintain both a development branch and +a maintenance branch, and it would be quite easy for them if "git +bisect" just worked when they want to bisect a regression on the +development branch that is not on the maintenance branch. They should +be able to start bisecting using: + +------------- +$ git bisect start dev main +------------- + +To enable that additional nice feature, when a bisection is started +and when some good commits are not ancestors of the bad commit, we +first compute the merge bases between the bad and the good commits and +we chose these merge bases as the first commits that will be checked +out and tested. + +If it happens that one merge base is bad, then the bisection process +is stopped with a message like: + +------------- +The merge base BBBBBB is bad. +This means the bug has been fixed between BBBBBB and [GGGGGG,...]. +------------- + +where BBBBBB is the sha1 hash of the bad merge base and [GGGGGG,...] +is a comma separated list of the sha1 of the good commits. + +If some of the merge bases are skipped, then the bisection process +continues, but the following message is printed for each skipped merge +base: + +------------- +Warning: the merge base between BBBBBB and [GGGGGG,...] must be skipped. +So we cannot be sure the first bad commit is between MMMMMM and BBBBBB. +We continue anyway. +------------- + +where BBBBBB is the sha1 hash of the bad commit, MMMMMM is the sha1 +hash of the merge base that is skipped and [GGGGGG,...] is a comma +separated list of the sha1 of the good commits. + +So if there is no bad merge base, the bisection process continues as +usual after this step. + +Best bisecting practices +------------------------ + +Using test suites and git bisect together +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you both have a test suite and use git bisect, then it becomes less +important to check that all tests pass after each commit. Though of +course it is probably a good idea to have some checks to avoid +breaking too many things because it could make bisecting other bugs +more difficult. + +You can focus your efforts to check at a few points (for example rc +and beta releases) that all the T test cases pass for all the N +configurations. And when some tests don't pass you can use "git +bisect" (or better "git bisect run"). So you should perform roughly: + +------------- +c * N * T + b * M * log2(M) tests +------------- + +where c is the number of rounds of test (so a small constant) and b is +the ratio of bug per commit (hopefully a small constant too). + +So of course it's much better as it's O(N \* T) vs O(N \* T \* M) if +you would test everything after each commit. + +This means that test suites are good to prevent some bugs from being +committed and they are also quite good to tell you that you have some +bugs. But they are not so good to tell you where some bugs have been +introduced. To tell you that efficiently, git bisect is needed. + +The other nice thing with test suites, is that when you have one, you +already know how to test for bad behavior. So you can use this +knowledge to create a new test case for "git bisect" when it appears +that there is a regression. So it will be easier to bisect the bug and +fix it. And then you can add the test case you just created to your +test suite. + +So if you know how to create test cases and how to bisect, you will be +subject to a virtuous circle: + +more tests => easier to create tests => easier to bisect => more tests + +So test suites and "git bisect" are complementary tools that are very +powerful and efficient when used together. + +Bisecting build failures +~~~~~~~~~~~~~~~~~~~~~~~~ + +You can very easily automatically bisect broken builds using something +like: + +------------- +$ git bisect start BAD GOOD +$ git bisect run make +------------- + +Passing sh -c "some commands" to "git bisect run" +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For example: + +------------- +$ git bisect run sh -c "make || exit 125; ./my_app | grep 'good output'" +------------- + +On the other hand if you do this often, then it can be worth having +scripts to avoid too much typing. + +Finding performance regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Here is an example script that comes slightly modified from a real +world script used by Junio Hamano <<4>>. + +This script can be passed to "git bisect run" to find the commit that +introduced a performance regression: + +------------- +#!/bin/sh + +# Build errors are not what I am interested in. +make my_app || exit 255 + +# We are checking if it stops in a reasonable amount of time, so +# let it run in the background... + +./my_app >log 2>&1 & + +# ... and grab its process ID. +pid=$! + +# ... and then wait for sufficiently long. +sleep $NORMAL_TIME + +# ... and then see if the process is still there. +if kill -0 $pid +then + # It is still running -- that is bad. + kill $pid; sleep 1; kill $pid; + exit 1 +else + # It has already finished (the $pid process was no more), + # and we are happy. + exit 0 +fi +------------- + +Following general best practices +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is obviously a good idea not to have commits with changes that +knowingly break things, even if some other commits later fix the +breakage. + +It is also a good idea when using any VCS to have only one small +logical change in each commit. + +The smaller the changes in your commit, the most effective "git +bisect" will be. And you will probably need "git bisect" less in the +first place, as small changes are easier to review even if they are +only reviewed by the commiter. + +Another good idea is to have good commit messages. They can be very +helpful to understand why some changes were made. + +These general best practices are very helpful if you bisect often. + +Avoiding bug prone merges +~~~~~~~~~~~~~~~~~~~~~~~~~ + +First merges by themselves can introduce some regressions even when +the merge needs no source code conflict resolution. This is because a +semantic change can happen in one branch while the other branch is not +aware of it. + +For example one branch can change the semantic of a function while the +other branch add more calls to the same function. + +This is made much worse if many files have to be fixed to resolve +conflicts. That's why such merges are called "evil merges". They can +make regressions very difficult to track down. It can even be +misleading to know the first bad commit if it happens to be such a +merge, because people might think that the bug comes from bad conflict +resolution when it comes from a semantic change in one branch. + +Anyway "git rebase" can be used to linearize history. This can be used +either to avoid merging in the first place. Or it can be used to +bisect on a linear history instead of the non linear one, as this +should give more information in case of a semantic change in one +branch. + +Merges can be also made simpler by using smaller branches or by using +many topic branches instead of only long version related branches. + +And testing can be done more often in special integration branches +like linux-next for the linux kernel. + +Adapting your work-flow +~~~~~~~~~~~~~~~~~~~~~~~ + +A special work-flow to process regressions can give great results. + +Here is an example of a work-flow used by Andreas Ericsson: + +* write, in the test suite, a test script that exposes the regression +* use "git bisect run" to find the commit that introduced it +* fix the bug that is often made obvious by the previous step +* commit both the fix and the test script (and if needed more tests) + +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 +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 +for us). Each new release results in ~40% fewer bugs (almost certainly +due to how we now feel about writing tests). +_____________ + +Clearly this work-flow uses the virtuous circle between test suites +and "git bisect". In fact it makes it the standard procedure to deal +with regression. + +In other messages Andreas says that they also use the "best practices" +described above: small logical commits, topic branches, no evil +merge,... These practices all improve the bisectability of the commit +graph, by making it easier and more useful to bisect. + +So a good work-flow should be designed around the above points. That +is making bisecting easier, more useful and standard. + +Involving QA people and if possible end users +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +One nice about "git bisect" is that it is not only a developer +tool. It can effectively be used by QA people or even end users (if +they have access to the source code or if they can get access to all +the builds). + +There was a discussion at one point on the linux kernel mailing list +of whether it was ok to always ask end user to bisect, and very good +points were made to support the point of view that it is ok. + +For example David Miller wrote <<6>>: + +_____________ +What people don't get is that this is a situation where the "end node +principle" applies. When you have limited resources (here: developers) +you don't push the bulk of the burden upon them. Instead you push +things out to the resource you have a lot of, the end nodes (here: +users), so that the situation actually scales. +_____________ + +This means that it is often "cheaper" if QA people or end users can do +it. + +What is interesting too is that end users that are reporting bugs (or +QA people that reproduced a bug) have access to the environment where +the bug happens. So they can often more easily reproduce a +regression. And if they can bisect, then more information will be +extracted from the environment where the bug happens, which means that +it will be easier to understand and then fix the bug. + +For open source projects it can be a good way to get more useful +contributions from end users, and to introduce them to QA and +development activities. + +Using complex scripts +~~~~~~~~~~~~~~~~~~~~~ + +In some cases like for kernel development it can be worth developing +complex scripts to be able to fully automate bisecting. + +Here is what Ingo Molnar says about that <<7>>: + +_____________ +i have a fully automated bootup-hang bisection script. It is based on +"git-bisect run". I run the script, it builds and boots kernels fully +automatically, and when the bootup fails (the script notices that via +the serial log, which it continuously watches - or via a timeout, if +the system does not come up within 10 minutes it's a "bad" kernel), +the script raises my attention via a beep and i power cycle the test +box. (yeah, i should make use of a managed power outlet to 100% +automate it) +_____________ + +Combining test suites, git bisect and other systems together +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +We have seen that test suites an git bisect are very powerful when +used together. It can be even more powerful if you can combine them +with other systems. + +For example some test suites could be run automatically at night with +some unusual (or even random) configurations. And if a regression is +found by a test suite, then "git bisect" can be automatically +launched, and its result can be emailed to the author of the first bad +commit found by "git bisect", and perhaps other people too. And a new +entry in the bug tracking system could be automatically created too. + + +The future of bisecting +----------------------- + +"git replace" +~~~~~~~~~~~~~ + +We saw earlier that "git bisect skip" is now using a PRNG to try to +avoid areas in the commit graph where commits are untestable. The +problem is that sometimes the first bad commit will be in an +untestable area. + +To simplify the discussion we will suppose that the untestable area is +a simple string of commits and that it was created by a breakage +introduced by one commit (let's call it BBC for bisect breaking +commit) and later fixed by another one (let's call it BFC for bisect +fixing commit). + +For example: + +------------- +...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z-... +------------- + +where we know that Y is good and BFC is bad, and where BBC and X1 to +X6 are untestable. + +In this case if you are bisecting manually, what you can do is create +a special branch that starts just before the BBC. The first commit in +this branch should be the BBC with the BFC squashed into it. And the +other commits in the branch should be the commits between BBC and BFC +rebased on the first commit of the branch and then the commit after +BFC also rebased on. + +For example: + +------------- + (BBC+BFC)-X1'-X2'-X3'-X4'-X5'-X6'-Z' + / +...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z-... +------------- + +where commits quoted with ' have been rebased. + +You can easily create such a branch with Git using interactive rebase. + +For example using: + +------------- +$ git rebase -i Y Z +------------- + +and then moving BFC after BBC and squashing it. + +After that you can start bisecting as usual in the new branch and you +should eventually find the first bad commit. + +For example: + +------------- +$ git bisect start Z' Y +------------- + +If you are using "git bisect run", you can use the same manual fix up +as above, and then start another "git bisect run" in the special +branch. Or as the "git bisect" man page says, the script passed to +"git bisect run" can apply a patch before it compiles and test the +software <<8>>. The patch should turn a current untestable commits +into a testable one. So the testing will result in "good" or "bad" and +"git bisect" will be able to find the first bad commit. And the script +should not forget to remove the patch once the testing is done before +exiting from the script. + +(Note that instead of a patch you can use "git cherry-pick BFC" to +apply the fix, and in this case you should use "git reset --hard +HEAD^" to revert the cherry-pick after testing and before returning +from the script.) + +But the above ways to work around untestable areas are a little bit +clunky. Using special branches is nice because these branches can be +shared by developers like usual branches, but the risk is that people +will get many such branches. And it disrupts the normal "git bisect" +work-flow. So, if you want to use "git bisect run" completely +automatically, you have to add special code in your script to restart +bisection in the special branches. + +Anyway one can notice in the above special branch example that the Z' +and Z commits should point to the same source code state (the same +"tree" in git parlance). That's because Z' result from applying the +same changes as Z just in a slightly different order. + +So if we could just "replace" Z by Z' when we bisect, then we would +not need to add anything to a script. It would just work for anyone in +the project sharing the special branches and the replacements. + +With the example above that would give: + +------------- + (BBC+BFC)-X1'-X2'-X3'-X4'-X5'-X6'-Z'-... + / +...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z +------------- + +That's why the "git replace" command was created. Technically it +stores replacements "refs" in the "refs/replace/" hierarchy. These +"refs" are like branches (that are stored in "refs/heads/") or tags +(that are stored in "refs/tags"), and that means that they can +automatically be shared like branches or tags among developers. + +"git replace" is a very powerful mechanism. It can be used to fix +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. + +One problem with "git replace" is that currently it stores all the +replacements refs in "refs/replace/", but it would be perhaps better +if the replacement refs that are useful only for bisecting would be in +"refs/replace/bisect/". This way the replacement refs could be used +only for bisecting, while other refs directly in "refs/replace/" would +be used nearly all the time. + +Bisecting sporadic bugs +~~~~~~~~~~~~~~~~~~~~~~~ + +Another possible improvement to "git bisect" would be to optionally +add some redundancy to the tests performed so that it would be more +reliable when tracking sporadic bugs. + +This has been requested by some kernel developers because some bugs +called sporadic bugs do not appear in all the kernel builds because +they are very dependent on the compiler output. + +The idea is that every 3 test for example, "git bisect" could ask the +user to test a commit that has already been found to be "good" or +"bad" (because one of its descendants or one of its ancestors has been +found to be "good" or "bad" respectively). If it happens that a commit +has been previously incorrectly classified then the bisection can be +aborted early, hopefully before too many mistakes have been made. Then +the user will have to look at what happened and then restart the +bisection using a fixed bisect log. + +There is already a project called BBChop created by Ealdwulf Wuffinga +on Github that does something like that using Bayesian Search Theory +<<9>>: + +_____________ +BBChop is like 'git bisect' (or equivalent), but works when your bug +is intermittent. That is, it works in the presence of false negatives +(when a version happens to work this time even though it contains the +bug). It assumes that there are no false positives (in principle, the +same approach would work, but adding it may be non-trivial). +_____________ + +But BBChop is independent of any VCS and it would be easier for Git +users to have something integrated in Git. + +Conclusion +---------- + +We have seen that regressions are an important problem, and that "git +bisect" has nice features that complement very well practices and +other tools, especially test suites, that are generally used to fight +regressions. But it might be needed to change some work-flows and +(bad) habits to get the most out of it. + +Some improvements to the algorithms inside "git bisect" are possible +and some new features could help in some cases, but overall "git +bisect" works already very well, is used a lot, and is already very +useful. To back up that last claim, let's give the final word to Ingo +Molnar when he was asked by the author how much time does he think +"git bisect" saves him when he uses it: + +_____________ +a _lot_. + +About ten years ago did i do my first 'bisection' of a Linux patch +queue. That was prior the Git (and even prior the BitKeeper) days. I +literally days spent sorting out patches, creating what in essence +were standalone commits that i guessed to be related to that bug. + +It was a tool of absolute last resort. I'd rather spend days looking +at printk output than do a manual 'patch bisection'. + +With Git bisect it's a breeze: in the best case i can get a ~15 step +kernel bisection done in 20-30 minutes, in an automated way. Even with +manual help or when bisecting multiple, overlapping bugs, it's rarely +more than an hour. + +In fact it's invaluable because there are bugs i would never even +_try_ to debug if it wasn't for git bisect. In the past there were bug +patterns that were immediately hopeless for me to debug - at best i +could send the crash/bug signature to lkml and hope that someone else +can think of something. + +And even if a bisection fails today it tells us something valuable +about the bug: that it's non-deterministic - timing or kernel image +layout dependent. + +So git bisect is unconditional goodness - and feel free to quote that +;-) +_____________ + +Acknowledgements +---------------- + +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 +some ideas and helping me improve them, for improving "git bisect" a +lot and for his awesome work in maintaining and developing Git. + +Many thanks to Ingo Molnar for giving me very useful information that +appears in this paper, for commenting on this paper, for his +suggestions to improve "git bisect" and for evangelizing "git bisect" +on the linux kernel mailing lists. + +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 +Schindelin, H. Peter Anvin, Daniel Barkalow, Bill Lear, John Hawley, +Shawn O. Pierce, Jeff King, Sam Vilain, Jon Seymour. + +Many thanks to the Linux-Kongress program committee for choosing the +author to given a talk and for publishing this paper. + +References +---------- + +- [[[1]]] http://www.nist.gov/public_affairs/releases/n02-10.htm['Software Errors Cost U.S. Economy $59.5 Billion Annually'. Nist News Release.] +- [[[2]]] http://java.sun.com/docs/codeconv/html/CodeConventions.doc.html#16712['Code Conventions for the Java Programming Language'. Sun Microsystems.] +- [[[3]]] http://en.wikipedia.org/wiki/Software_maintenance['Software maintenance'. Wikipedia.] +- [[[4]]] http://article.gmane.org/gmane.comp.version-control.git/45195/[Junio C Hamano. 'Automated bisect success story'. Gmane.] +- [[[5]]] http://lwn.net/Articles/317154/[Christian Couder. 'Fully automated bisecting with "git bisect run"'. LWN.net.] +- [[[6]]] http://lwn.net/Articles/277872/[Jonathan Corbet. 'Bisection divides users and developers'. LWN.net.] +- [[[7]]] http://article.gmane.org/gmane.linux.scsi/36652/[Ingo Molnar. 'Re: BUG 2.6.23-rc3 can't see sd partitions on Alpha'. Gmane.] +- [[[8]]] http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html[Junio C Hamano and the git-list. 'git-bisect(1) Manual Page'. Linux Kernel Archives.] +- [[[9]]] http://github.com/Ealdwulf/bbchop[Ealdwulf. 'bbchop'. GitHub.] diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt new file mode 100644 index 0000000000..c39d957c3a --- /dev/null +++ b/Documentation/git-bisect.txt @@ -0,0 +1,340 @@ +git-bisect(1) +============= + +NAME +---- +git-bisect - Find by binary search the change that introduced a bug + + +SYNOPSIS +-------- +'git bisect' <subcommand> <options> + +DESCRIPTION +----------- +The command takes various subcommands, and different options depending +on the subcommand: + + git bisect help + git bisect start [<bad> [<good>...]] [--] [<paths>...] + git bisect bad [<rev>] + git bisect good [<rev>...] + git bisect skip [(<rev>|<range>)...] + git bisect reset [<commit>] + git bisect visualize + git bisect replay <logfile> + git bisect log + git bisect run <cmd>... + +This command uses 'git rev-list --bisect' to help drive the +binary search process to find which change introduced a bug, given an +old "good" commit object name and a later "bad" commit object name. + +Getting help +~~~~~~~~~~~~ + +Use "git bisect" to get a short usage description, and "git bisect +help" or "git bisect -h" to get a long usage description. + +Basic bisect commands: start, bad, good +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Using the Linux kernel tree as an example, basic use of the bisect +command is as follows: + +------------------------------------------------ +$ git bisect start +$ git bisect bad # Current version is bad +$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version + # tested that was good +------------------------------------------------ + +When you have specified at least one bad and one good version, the +command bisects the revision tree and outputs something similar to +the following: + +------------------------------------------------ +Bisecting: 675 revisions left to test after this +------------------------------------------------ + +The state in the middle of the set of revisions is then checked out. +You would now compile that kernel and boot it. If the booted kernel +works correctly, you would then issue the following command: + +------------------------------------------------ +$ git bisect good # this one is good +------------------------------------------------ + +The output of this command would be something similar to the following: + +------------------------------------------------ +Bisecting: 337 revisions left to test after this +------------------------------------------------ + +You keep repeating this process, compiling the tree, testing it, and +depending on whether it is good or bad issuing the command "git bisect good" +or "git bisect bad" to ask for the next bisection. + +Eventually there will be no more revisions left to bisect, and you +will have been left with the first bad kernel revision in "refs/bisect/bad". + +Bisect reset +~~~~~~~~~~~~ + +After a bisect session, to clean up the bisection state and return to +the original HEAD, issue the following command: + +------------------------------------------------ +$ git bisect reset +------------------------------------------------ + +By default, this will return your tree to the commit that was checked +out before `git bisect start`. (A new `git bisect start` will also do +that, as it cleans up the old bisection state.) + +With an optional argument, you can return to a different commit +instead: + +------------------------------------------------ +$ git bisect reset <commit> +------------------------------------------------ + +For example, `git bisect reset HEAD` will leave you on the current +bisection commit and avoid switching commits at all, while `git bisect +reset bisect/bad` will check out the first bad revision. + +Bisect visualize +~~~~~~~~~~~~~~~~ + +To see the currently remaining suspects in 'gitk', issue the following +command during the bisection process: + +------------ +$ 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 +`--stat`. + +------------ +$ git bisect view --stat +------------ + +Bisect log and bisect replay +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +After having marked revisions as good or bad, issue the following +command to show what has been done so far: + +------------ +$ git bisect log +------------ + +If you discover that you made a mistake in specifying the status of a +revision, you can save the output of this command to a file, edit it to +remove the incorrect entries, and then issue the following commands to +return to a corrected state: + +------------ +$ git bisect reset +$ git bisect replay that-file +------------ + +Avoiding testing a commit +~~~~~~~~~~~~~~~~~~~~~~~~~ + +If, in the middle of a bisect session, you know that the next suggested +revision is not a good one to test (e.g. the change the commit +introduces is known not to work in your environment and you know it +does not have anything to do with the bug you are chasing), you may +want to find a nearby commit and try that instead. + +For example: + +------------ +$ git bisect good/bad # previous round was good or bad. +Bisecting: 337 revisions left to test after this +$ git bisect visualize # oops, that is uninteresting. +$ git reset --hard HEAD~3 # try 3 revisions before what + # was suggested +------------ + +Then compile and test the chosen revision, and afterwards mark +the revision as good or bad in the usual manner. + +Bisect skip +~~~~~~~~~~~~ + +Instead of choosing by yourself a nearby commit, you can ask git +to do it for you by issuing the command: + +------------ +$ git bisect skip # Current version cannot be tested +------------ + +But git may eventually be unable to tell the first bad commit among +a bad commit and one or more skipped commits. + +You can even skip a range of commits, instead of just one commit, +using the "'<commit1>'..'<commit2>'" notation. For example: + +------------ +$ git bisect skip v2.5..v2.6 +------------ + +This tells the bisect process that no commit after `v2.5`, up to and +including `v2.6`, should be tested. + +Note that if you also want to skip the first commit of the range you +would issue the command: + +------------ +$ git bisect skip v2.5 v2.5..v2.6 +------------ + +This tells the bisect process that the commits between `v2.5` included +and `v2.6` included should be skipped. + + +Cutting down bisection by giving more parameters to bisect start +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can further cut down the number of trials, if you know what part of +the tree is involved in the problem you are tracking down, by specifying +path parameters when issuing the `bisect start` command: + +------------ +$ git bisect start -- arch/i386 include/asm-i386 +------------ + +If you know beforehand more than one good commit, you can narrow the +bisect space down by specifying all of the good commits immediately after +the bad commit when issuing the `bisect start` command: + +------------ +$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 -- + # v2.6.20-rc6 is bad + # v2.6.20-rc4 and v2.6.20-rc1 are good +------------ + +Bisect run +~~~~~~~~~~ + +If you have a script that can tell if the current source code is good +or bad, you can bisect by issuing the command: + +------------ +$ git bisect run my_script arguments +------------ + +Note that the script (`my_script` in the above example) should +exit with code 0 if the current source code is good, and exit with a +code between 1 and 127 (inclusive), except 125, if the current +source code is bad. + +Any other exit code will abort the bisect process. It should be noted +that a program that terminates via "exit(-1)" leaves $? = 255, (see the +exit(3) manual page), as the value is chopped with "& 0377". + +The special exit code 125 should be used when the current source code +cannot be tested. If the script exits with this code, the current +revision will be skipped (see `git bisect skip` above). + +You may often find that during a bisect session you want to have +temporary modifications (e.g. s/#define DEBUG 0/#define DEBUG 1/ in a +header file, or "revision that does not have this commit needs this +patch applied to work around another problem this bisection is not +interested in") applied to the revision being tested. + +To cope with such a situation, after the inner 'git bisect' finds the +next revision to test, the script can apply the patch +before compiling, run the real test, and afterwards decide if the +revision (possibly with the needed patch) passed the test and then +rewind the tree to the pristine state. Finally the script should exit +with the status of the real test to let the "git bisect run" command loop +determine the eventual outcome of the bisect session. + +EXAMPLES +-------- + +* Automatically bisect a broken build between v1.2 and HEAD: ++ +------------ +$ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good +$ git bisect run make # "make" builds the app +------------ + +* Automatically bisect a test failure between origin and HEAD: ++ +------------ +$ git bisect start HEAD origin -- # HEAD is bad, origin is good +$ git bisect run make test # "make test" builds and tests +------------ + +* Automatically bisect a broken test suite: ++ +------------ +$ cat ~/test.sh +#!/bin/sh +make || exit 125 # this skips broken builds +make test # "make test" runs the test suite +$ git bisect start v1.3 v1.1 -- # v1.3 is bad, v1.1 is good +$ git bisect run ~/test.sh +------------ ++ +Here we use a "test.sh" custom script. In this script, if "make" +fails, we skip the current commit. ++ +It is safer to use a custom script outside the repository to prevent +interactions between the bisect, make and test processes and the +script. ++ +"make test" should "exit 0", if the test suite passes, and +"exit 1" otherwise. + +* Automatically bisect a broken test case: ++ +------------ +$ cat ~/test.sh +#!/bin/sh +make || exit 125 # this skips broken builds +~/check_test_case.sh # does the test case passes ? +$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10 +$ git bisect run ~/test.sh +------------ ++ +Here "check_test_case.sh" should "exit 0" if the test case passes, +and "exit 1" otherwise. ++ +It is safer if both "test.sh" and "check_test_case.sh" scripts are +outside the repository to prevent interactions between the bisect, +make and test processes and the scripts. + +* Automatically bisect a broken test suite: ++ +------------ +$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10 +$ git bisect run sh -c "make || exit 125; ~/check_test_case.sh" +------------ ++ +Does the same as the previous example, but on a single line. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +SEE ALSO +-------- +link:git-bisect-lk2009.html[Fighting regressions with git bisect], +linkgit:git-blame[1]. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt new file mode 100644 index 0000000000..8c7b7b0838 --- /dev/null +++ b/Documentation/git-blame.txt @@ -0,0 +1,203 @@ +git-blame(1) +============ + +NAME +---- +git-blame - Show what revision and author last modified each line of a file + +SYNOPSIS +-------- +[verse] +'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m] + [-S <revs-file>] [-M] [-C] [-C] [--since=<date>] + [<rev> | --contents <file> | --reverse <rev>] [--] <file> + +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. + +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 +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: + +----------------------------------------------------------------------------- +$ git log --pretty=oneline -S'blame_usage' +5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file> +ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output +----------------------------------------------------------------------------- + +OPTIONS +------- +include::blame-options.txt[] + +-c:: + Use the same output mode as linkgit:git-annotate[1] (Default: off). + +--score-debug:: + Include debugging information related to the movement of + lines between files (see `-C`) and lines moved within a + file (see `-M`). The first number listed is the score. + This is the number of alphanumeric characters detected + as having been moved between or within files. This must be above + a certain threshold for 'git-blame' to consider those lines + of code to have been moved. + +-f:: +--show-name:: + Show the filename in the original commit. By default + the filename is shown if there is any line that came from a + file with a different name, due to rename detection. + +-n:: +--show-number:: + Show the line number in the original commit (Default: off). + +-s:: + Suppress the author name and timestamp from the output. + +-w:: + Ignore whitespace when comparing the parent's version and + the child's to find where the lines came from. + + +THE PORCELAIN FORMAT +-------------------- + +In this format, each line is output after a header; the +header at the minimum has the first line which has: + +- 40-byte SHA-1 of the commit the line is attributed to; +- the line number of the line in the original file; +- the line number of the line in the final file; +- on a line that starts a group of lines from a different + commit than the previous one, the number of lines in this + group. On subsequent lines this field is absent. + +This header line is followed by the following information +at least once for each commit: + +- the author name ("author"), email ("author-mail"), time + ("author-time"), and timezone ("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"). + +The contents of the actual line is output after the above +header, prefixed by a TAB. This is to allow adding more +header elements later. + + +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 +lines 40-60 for file `foo`, you can use the `-L` option like so +(they mean the same thing -- both ask for 21 lines starting at +line 40): + + git blame -L 40,60 foo + git blame -L 40,+21 foo + +Also you can use a regular expression to specify the line range: + + git blame -L '/^sub hello {/,/^}$/' foo + +which limits the annotation to the body of the `hello` subroutine. + +When you are not interested in changes older than version +v2.6.18, or changes older than 3 weeks, you can use revision +range specifiers similar to 'git-rev-list': + + git blame v2.6.18.. -- foo + git blame --since=3.weeks -- foo + +When revision range specifiers are used to limit the annotation, +lines that have not changed since the range boundary (either the +commit v2.6.18 or the most recent commit that is more than 3 +weeks old in the above example) are blamed for that range +boundary commit. + +A particularly useful way is to see if an added file has lines +created by copy-and-paste from existing files. Sometimes this +indicates that the developer was being sloppy and did not +refactor the code properly. You can first find the commit that +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: + + git blame -C -C -f $commit^! -- foo + + +INCREMENTAL OUTPUT +------------------ + +When called with `--incremental` option, the command outputs the +result as it is built. The output generally will talk about +lines touched by more recent commits first (i.e. the lines will +be annotated out of order) and is meant to be used by +interactive viewers. + +The output format is similar to the Porcelain format, but it +does not contain the actual lines from the file that is being +annotated. + +. Each blame entry always starts with a line of: + + <40-byte hex sha1> <sourceline> <resultline> <num_lines> ++ +Line numbers count from 1. + +. The first time that a commit shows up in the stream, it has various + other information about it printed out with a one-word tag at the + beginning of each line describing the extra commit information (author, + email, committer, dates, summary, etc.). + +. Unlike the Porcelain format, the filename information is always + given and terminates the entry: + + "filename" <whitespace-quoted-filename-goes-here> ++ +and thus it is really quite easy to parse for some line- and word-oriented +parser (which should be quite natural for most scripting languages). ++ +[NOTE] +For people who do parsing: to make it more robust, just ignore any +lines between the first and last one ("<sha1>" and "filename" lines) +where you do not recognize the tag words (or care about that particular +one) at the beginning of the "extended information" lines. That way, if +there is ever added information (like the commit encoding or extended +commit commentary), a blame viewer will not care. + + +MAPPING AUTHORS +--------------- + +include::mailmap.txt[] + + +SEE ALSO +-------- +linkgit:git-annotate[1] + +AUTHOR +------ +Written by Junio C Hamano <gitster@pobox.com> + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt new file mode 100644 index 0000000000..0e836809c2 --- /dev/null +++ b/Documentation/git-branch.txt @@ -0,0 +1,231 @@ +git-branch(1) +============= + +NAME +---- +git-branch - List, create, or delete branches + +SYNOPSIS +-------- +[verse] +'git branch' [--color | --no-color] [-r | -a] + [-v [--abbrev=<length> | --no-abbrev]] + [(--merged | --no-merged | --contains) [<commit>]] +'git branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>] +'git branch' (-m | -M) [<oldbranch>] <newbranch> +'git branch' (-d | -D) [-r] <branchname>... + +DESCRIPTION +----------- + +With no arguments, existing branches are listed and the current branch will +be highlighted with an asterisk. Option `-r` causes the remote-tracking +branches to be listed, and option `-a` shows both. + +With `--contains`, shows only the branches that contain the named commit +(in other words, the branches whose tip commits are descendants of the +named commit). With `--merged`, only branches merged into the named +commit (i.e. the branches whose tip commits are reachable from the named +commit) will be listed. With `--no-merged` only branches not merged into +the named commit will be listed. If the <commit> argument is missing it +defaults to 'HEAD' (i.e. the tip of the current branch). + +The command's second form creates a new branch head named <branchname> +which points to the current 'HEAD', or <start-point> if given. + +Note that this will create the new branch, but it will not switch the +working tree to it; use "git checkout <newbranch>" to switch to the +new branch. + +When a local branch is started off a remote branch, git sets up the +branch so that 'git-pull' will appropriately merge from +the remote branch. This behavior may be changed via the global +`branch.autosetupmerge` configuration flag. That setting can be +overridden by using the `--track` and `--no-track` options. + +With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>. +If <oldbranch> had a corresponding reflog, it is renamed to match +<newbranch>, and a reflog entry is created to remember the branch +renaming. If <newbranch> exists, -M must be used to force the rename +to happen. + +With a `-d` or `-D` option, `<branchname>` will be deleted. You may +specify more than one branch for deletion. If the branch currently +has a reflog then the reflog will also be deleted. + +Use -r together with -d to delete remote-tracking branches. Note, that it +only makes sense to delete remote-tracking branches if they no longer exist +in the remote repository or if 'git-fetch' was configured not to fetch +them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a +way to clean up all obsolete remote-tracking branches. + + +OPTIONS +------- +-d:: + Delete a branch. The branch must be fully merged in HEAD. + +-D:: + Delete a branch irrespective of its merged status. + +-l:: + Create the branch's reflog. This activates recording of + all changes made to the branch ref, enabling use of date + based sha1 expressions such as "<branchname>@\{yesterday}". + +-f:: +--force:: + Reset <branchname> to <startpoint> if <branchname> exists + already. Without `-f` 'git-branch' refuses to change an existing branch. + +-m:: + Move/rename a branch and the corresponding reflog. + +-M:: + Move/rename a branch even if the new branch name already exists. + +--color:: + Color branches to highlight current, local, and remote branches. + +--no-color:: + Turn off branch colors, even when the configuration file gives the + default to color output. + +-r:: + List or delete (if used with -d) the remote-tracking branches. + +-a:: + List both remote-tracking branches and local branches. + +-v:: +--verbose:: + Show sha1 and commit subject line for each head, along with + relationship to upstream branch (if any). If given twice, print + the name of the upstream branch, as well. + +--abbrev=<length>:: + Alter the sha1's minimum display length in the output listing. + The default value is 7. + +--no-abbrev:: + Display the full sha1s in the output listing rather than abbreviating them. + +-t:: +--track:: + When creating a new branch, set up configuration to mark the + start-point branch as "upstream" from the new branch. This + configuration will tell git to show the relationship between the + two branches in `git status` and `git branch -v`. Furthermore, + it directs `git pull` without arguments to pull from the + upstream when the new branch is checked out. ++ +This behavior is the default when the start point is a remote branch. +Set the branch.autosetupmerge configuration variable to `false` if you +want `git checkout` and `git branch` to always behave as if '--no-track' +were given. Set it to `always` if you want this behavior when the +start-point is either a local or remote branch. + +--no-track:: + Do not set up "upstream" configuration, even if the + branch.autosetupmerge configuration variable is true. + +--contains <commit>:: + Only list branches which contain the specified commit. + +--merged [<commit>]:: + Only list branches whose tips are reachable from the + specified commit (HEAD if not specified). + +--no-merged [<commit>]:: + Only list branches whose tips are not reachable from the + specified commit (HEAD if not specified). + +<branchname>:: + The name of the branch to create or delete. + The new branch name must pass all checks defined by + linkgit:git-check-ref-format[1]. Some of these checks + may restrict the characters allowed in a branch name. + +<start-point>:: + The new branch head will point to this commit. It may be + given as a branch name, a commit-id, or a tag. If this + option is omitted, the current HEAD will be used instead. + +<oldbranch>:: + The name of an existing branch to rename. + +<newbranch>:: + The new name for an existing branch. The same restrictions as for + <branchname> apply. + + +Examples +-------- + +Start development from a known tag:: ++ +------------ +$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 +$ cd my2.6 +$ git branch my2.6.14 v2.6.14 <1> +$ git checkout my2.6.14 +------------ ++ +<1> This step and the next one could be combined into a single step with +"checkout -b my2.6.14 v2.6.14". + +Delete an unneeded branch:: ++ +------------ +$ git clone git://git.kernel.org/.../git.git my.git +$ cd my.git +$ git branch -d -r origin/todo origin/html origin/man <1> +$ git branch -D test <2> +------------ ++ +<1> Delete the remote-tracking branches "todo", "html" and "man". The next +'fetch' or 'pull' will create them again unless you configure them not to. +See linkgit:git-fetch[1]. +<2> Delete the "test" branch even if the "master" branch (or whichever branch +is currently checked out) does not have all commits from the test branch. + + +Notes +----- + +If you are creating a branch that you want to checkout immediately, it is +easier to use the git checkout command with its `-b` option to create +a branch and check it out with a single command. + +The options `--contains`, `--merged` and `--no-merged` serve three related +but different purposes: + +- `--contains <commit>` is used to find all branches which will need + special attention if <commit> were to be rebased or amended, since those + branches contain the specified <commit>. + +- `--merged` is used to find all branches which can be safely deleted, + since those branches are fully contained by HEAD. + +- `--no-merged` is used to find branches which are candidates for merging + into HEAD, since those branches are not fully contained by HEAD. + +SEE ALSO +-------- +linkgit:git-check-ref-format[1], +linkgit:git-fetch[1], +linkgit:git-remote[1], +link:user-manual.html#what-is-a-branch[``Understanding history: What is +a branch?''] in the Git User's Manual. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt new file mode 100644 index 0000000000..c3a066e60c --- /dev/null +++ b/Documentation/git-bundle.txt @@ -0,0 +1,209 @@ +git-bundle(1) +============= + +NAME +---- +git-bundle - Move objects and refs by archive + + +SYNOPSIS +-------- +[verse] +'git bundle' create <file> <git-rev-list args> +'git bundle' verify <file> +'git bundle' list-heads <file> [refname...] +'git bundle' unbundle <file> [refname...] + +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, +ssh, rsync, http) cannot be used. This command provides support for +'git-fetch' and 'git-pull' to operate by packaging objects and references +in an archive at the originating machine, then importing those into +another repository using 'git-fetch' and 'git-pull' +after moving the archive by some means (e.g., by sneakernet). As no +direct connection between the repositories exists, the user must specify a +basis for the bundle that is held by the destination repository: the +bundle assumes that all objects in the basis are already in the +destination repository. + +OPTIONS +------- + +create <file>:: + Used to create a bundle named 'file'. This requires the + 'git-rev-list' arguments to define the bundle contents. + +verify <file>:: + Used to check that a bundle file is valid and will apply + cleanly to the current repository. This includes checks on the + bundle format itself as well as checking that the prerequisite + commits exist and are fully linked in the current repository. + 'git-bundle' prints a list of missing commits, if any, and exits + with a non-zero status. + +list-heads <file>:: + Lists the references defined in the bundle. If followed by a + list of references, only references matching those given are + printed out. + +unbundle <file>:: + Passes the objects in the bundle to 'git-index-pack' + for storage in the repository, then prints the names of all + defined references. If a list of references is given, only + references matching those in the list are printed. This command is + really plumbing, intended to be called only by 'git-fetch'. + +[git-rev-list-args...]:: + A list of arguments, acceptable to 'git-rev-parse' and + 'git-rev-list', that specifies the specific objects and references + to transport. For example, `master\~10..master` causes the + current master reference to be packaged along with all objects + added since its 10th ancestor commit. There is no explicit + limit to the number of references and objects that may be + packaged. + + +[refname...]:: + A list of references used to limit the references reported as + available. This is principally of use to 'git-fetch', which + expects to receive only those references asked for and not + necessarily everything in the pack (in this case, 'git-bundle' acts + like 'git-fetch-pack'). + +SPECIFYING REFERENCES +--------------------- + +'git-bundle' will only package references that are shown by +'git-show-ref': this includes heads, tags, and remote heads. References +such as `master\~1` cannot be packaged, but are perfectly suitable for +defining the basis. More than one reference may be packaged, and more +than one basis can be specified. The objects packaged are those not +contained in the union of the given bases. Each basis can be +specified explicitly (e.g. `^master\~10`), or implicitly (e.g. +`master\~10..master`, `--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 +to contain objects already in the destination, as these are ignored +when unpacking at the destination. + +EXAMPLE +------- + +Assume you want to transfer the history from a repository R1 on machine A +to another repository R2 on machine B. +For whatever reason, direct connection between A and B is not allowed, +but we can move data from A to B via some mechanism (CD, email, etc.). +We want to update R2 with development made on the branch master in R1. + +To bootstrap the process, you can first create a bundle that does not have +any basis. You can use a tag to remember up to what commit you last +processed, in order to make it easy to later update the other repository +with an incremental bundle: + +---------------- +machineA$ cd R1 +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: + +---------------- +machineB$ git clone /home/me/tmp/file.bundle R2 +---------------- + +This will define a remote called "origin" in the resulting repository that +lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will +have an entry like this: + +------------------------ +[remote "origin"] + url = /home/me/tmp/file.bundle + fetch = refs/heads/*:refs/remotes/origin/* +------------------------ + +To update the resulting mine.git repository, you can fetch or pull after +replacing the bundle stored at /home/me/tmp/file.bundle with incremental +updates. + +After working some more in the original repository, you can create an +incremental bundle to update the other repository: + +---------------- +machineA$ cd R1 +machineA$ git bundle create file.bundle lastR2bundle..master +machineA$ git tag -f lastR2bundle master +---------------- + +You then transfer the bundle to the other machine to replace +/home/me/tmp/file.bundle, and pull from it. + +---------------- +machineB$ cd R2 +machineB$ git pull +---------------- + +If you know up to what commit the intended recipient repository should +have the necessary objects, you can use that knowledge to specify the +basis, giving a cut-off point to limit the revisions and objects that go +in the resulting bundle. The previous example used lastR2bundle tag +for this purpose, but you can use any other options that you would give to +the linkgit:git-log[1] command. Here are more examples: + +You can use a tag that is present in both: + +---------------- +$ git bundle create mybundle v1.0.0..master +---------------- + +You can use a basis based on time: + +---------------- +$ git bundle create mybundle --since=10.days master +---------------- + +You can use the number of commits: + +---------------- +$ git bundle create mybundle -10 master +---------------- + +You can run `git-bundle verify` to see if you can extract from a bundle +that was created with a basis: + +---------------- +$ git bundle verify mybundle +---------------- + +This will list what commits you must have in order to extract from the +bundle and will error out if you do not have them. + +A bundle from a recipient repository's point of view is just like a +regular repository which it fetches or pulls from. You can, for example, map +references when fetching: + +---------------- +$ git fetch mybundle master:localRef +---------------- + +You can also see what references it offers. + +---------------- +$ git ls-remote mybundle +---------------- + +Author +------ +Written by Mark Levedahl <mdl123@verizon.net> + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt new file mode 100644 index 0000000000..58c8d65772 --- /dev/null +++ b/Documentation/git-cat-file.txt @@ -0,0 +1,107 @@ +git-cat-file(1) +=============== + +NAME +---- +git-cat-file - Provide content or type and size information for repository objects + + +SYNOPSIS +-------- +[verse] +'git cat-file' (-t | -s | -e | -p | <type>) <object> +'git cat-file' (--batch | --batch-check) < <list-of-objects> + +DESCRIPTION +----------- +In its first form, the command provides the content or the type of an object in +the repository. The type is required unless '-t' or '-p' is used to find the +object type, or '-s' is used to find the object size. + +In the second form, a list of objects (separated by linefeeds) is provided on +stdin, and the SHA1, type, and size of each object is printed on stdout. + +OPTIONS +------- +<object>:: + The name of the object to show. + For a more complete list of ways to spell object names, see + the "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. + +-t:: + Instead of the content, show the object type identified by + <object>. + +-s:: + Instead of the content, show the object size identified by + <object>. + +-e:: + Suppress all output; instead exit with zero status if <object> + exists and is a valid object. + +-p:: + Pretty-print the contents of <object> based on its type. + +<type>:: + Typically this matches the real type of <object> but asking + for a type that can trivially be dereferenced from the given + <object> is also permitted. An example is to ask for a + "tree" with <object> being a commit object that contains it, + or to ask for a "blob" with <object> being a tag object that + points at it. + +--batch:: + Print the SHA1, type, size, and contents of each object provided on + stdin. May not be combined with any other options or arguments. + +--batch-check:: + Print the SHA1, type, and size of each object provided on stdin. May not + be combined with any other options or arguments. + +OUTPUT +------ +If '-t' is specified, one of the <type>. + +If '-s' is specified, the size of the <object> in bytes. + +If '-e' is specified, no output. + +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: + +------------ +<sha1> SP <type> SP <size> LF +<contents> LF +------------ + +If '--batch-check' is specified, output of the following form is printed for +each object specified on stdin: + +------------ +<sha1> SP <type> SP <size> LF +------------ + +For both '--batch' and '--batch-check', output of the following form is printed +for each object specified on stdin that does not exist in the repository: + +------------ +<object> SP missing LF +------------ + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt new file mode 100644 index 0000000000..50824e3a2d --- /dev/null +++ b/Documentation/git-check-attr.txt @@ -0,0 +1,100 @@ +git-check-attr(1) +================= + +NAME +---- +git-check-attr - Display gitattributes information + + +SYNOPSIS +-------- +[verse] +'git check-attr' attr... [--] pathname... +'git check-attr' --stdin [-z] attr... < <list-of-paths> + +DESCRIPTION +----------- +For every pathname, this command will list if each attribute is 'unspecified', +'set', or 'unset' as a gitattribute on that pathname. + +OPTIONS +------- +--stdin:: + Read file names from stdin instead of from the command-line. + +-z:: + Only meaningful with `--stdin`; paths are separated with a + NUL character instead of a linefeed character. + +\--:: + Interpret all preceding arguments as attributes and all following + arguments as path names. If not supplied, only the first argument will + be treated as an attribute. + +OUTPUT +------ + +The output is of the form: +<path> COLON SP <attribute> COLON SP <info> LF + +<path> is the path of a file being queried, <attribute> is an attribute +being queried and <info> can be either: + +'unspecified';; when the attribute is not defined for the path. +'unset';; when the attribute is defined as false. +'set';; when the attribute is defined as true. +<value>;; when a value has been assigned to the attribute. + +EXAMPLES +-------- + +In the examples, the following '.gitattributes' file is used: +--------------- +*.java diff=java -crlf myAttr +NoMyAttr.java !myAttr +README caveat=unspecified +--------------- + +* Listing a single attribute: +--------------- +$ git check-attr diff org/example/MyClass.java +org/example/MyClass.java: diff: java +--------------- + +* Listing multiple attributes for a file: +--------------- +$ git check-attr crlf diff myAttr -- org/example/MyClass.java +org/example/MyClass.java: crlf: unset +org/example/MyClass.java: diff: java +org/example/MyClass.java: myAttr: set +--------------- + +* Listing an attribute for multiple files: +--------------- +$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java +org/example/MyClass.java: myAttr: set +org/example/NoMyAttr.java: myAttr: unspecified +--------------- + +* Not all values are equally unambiguous: +--------------- +$ git check-attr caveat README +README: caveat: unspecified +--------------- + +SEE ALSO +-------- +linkgit:gitattributes[5]. + + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by James Bowes. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt new file mode 100644 index 0000000000..0aeef24780 --- /dev/null +++ b/Documentation/git-check-ref-format.txt @@ -0,0 +1,95 @@ +git-check-ref-format(1) +======================= + +NAME +---- +git-check-ref-format - Ensures that a reference name is well formed + +SYNOPSIS +-------- +[verse] +'git check-ref-format' <refname> +'git check-ref-format' --print <refname> +'git check-ref-format' --branch <branchname-shorthand> + +DESCRIPTION +----------- +Checks if a given 'refname' is acceptable, and exits with a non-zero +status if it is not. + +A reference is used in git to specify branches and tags. A +branch head is stored under the `$GIT_DIR/refs/heads` directory, and +a tag is stored under the `$GIT_DIR/refs/tags` directory. git +imposes the following rules on how references are named: + +. They can include slash `/` for hierarchical (directory) + grouping, but no slash-separated component can begin with a + dot `.`. + +. They must contain at least one `/`. This enforces the presence of a + category like `heads/`, `tags/` etc. but the actual names are not + restricted. + +. They cannot have two consecutive dots `..` anywhere. + +. They cannot have ASCII control characters (i.e. bytes whose + values are lower than \040, or \177 `DEL`), space, tilde `~`, + caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`, + or open bracket `[` anywhere. + +. They cannot end with a slash `/` nor a dot `.`. + +. They cannot end with the sequence `.lock`. + +. They cannot contain a sequence `@{`. + +- They cannot contain a `\\`. + +These rules make it easy for shell script based tools to parse +reference names, pathname expansion by the shell when a reference name is used +unquoted (by mistake), and also avoids ambiguities in certain +reference name expressions (see linkgit:git-rev-parse[1]): + +. A double-dot `..` is often used as in `ref1..ref2`, and in some + contexts this notation means `{caret}ref1 ref2` (i.e. not in + `ref1` and in `ref2`). + +. A tilde `~` and caret `{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 + value and store it in dstref" in fetch and push operations. + It may also be used to select a specific object such as with + 'git-cat-file': "git cat-file blob v1.3.3:refs.c". + +. at-open-brace `@{` is used as a notation to access a reflog entry. + +With the `--print` option, if 'refname' is acceptable, it prints the +canonicalized name of a hypothetical reference with that name. That is, +it prints 'refname' with any extra `/` characters removed. + +With the `--branch` option, it expands the ``previous branch syntax'' +`@{-n}`. For example, `@{-1}` is a way to refer the last branch you +were on. This option should be used by porcelains to accept this +syntax anywhere a branch name is expected, so they can act as if you +typed the branch name. + +EXAMPLES +-------- + +* Print the name of the previous branch: ++ +------------ +$ git check-ref-format --branch @{-1} +------------ + +* Determine the reference name to use for a new branch: ++ +------------ +$ ref=$(git check-ref-format --print "refs/heads/$newbranch") || +die "we do not like '$newbranch' as a branch name." +------------ + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt new file mode 100644 index 0000000000..62d84836b8 --- /dev/null +++ b/Documentation/git-checkout-index.txt @@ -0,0 +1,189 @@ +git-checkout-index(1) +===================== + +NAME +---- +git-checkout-index - Copy files from the index to the working tree + + +SYNOPSIS +-------- +[verse] +'git checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>] + [--stage=<number>|all] + [--temp] + [-z] [--stdin] + [--] [<file>]\* + +DESCRIPTION +----------- +Will copy all files listed from the index to the working directory +(not overwriting existing files). + +OPTIONS +------- +-u:: +--index:: + update stat information for the checked out entries in + the index file. + +-q:: +--quiet:: + be quiet if files exist or are not in the index + +-f:: +--force:: + forces overwrite of existing files + +-a:: +--all:: + checks out all files in the index. Cannot be used + together with explicit filenames. + +-n:: +--no-create:: + Don't checkout new files, only refresh files already checked + out. + +--prefix=<string>:: + When creating files, prepend <string> (usually a directory + including a trailing /) + +--stage=<number>|all:: + Instead of checking out unmerged entries, copy out the + files from named stage. <number> must be between 1 and 3. + Note: --stage=all automatically implies --temp. + +--temp:: + Instead of copying the files to the working directory + write the content to temporary files. The temporary name + associations will be written to stdout. + +--stdin:: + Instead of taking list of paths from the command line, + read list of paths from the standard input. Paths are + separated by LF (i.e. one path per line) by default. + +-z:: + Only meaningful with `--stdin`; paths are separated with + NUL character instead of LF. + +\--:: + Do not interpret any more arguments as options. + +The order of the flags used to matter, but not anymore. + +Just doing `git checkout-index` does nothing. You probably meant +`git checkout-index -a`. And if you want to force it, you want +`git checkout-index -f -a`. + +Intuitiveness is not the goal here. Repeatability is. The reason for +the "no arguments means no work" behavior is that from scripts you are +supposed to be able to do: + +---------------- +$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f -- +---------------- + +which will force all existing `*.h` files to be replaced with their +cached copies. If an empty command line implied "all", then this would +force-refresh everything in the index, which was not the point. But +since 'git-checkout-index' accepts --stdin it would be faster to use: + +---------------- +$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin +---------------- + +The `--` is just a good idea when you know the rest will be filenames; +it will prevent problems with a filename of, for example, `-a`. +Using `--` is probably a good policy in scripts. + + +Using --temp or --stage=all +--------------------------- +When `--temp` is used (or implied by `--stage=all`) +'git-checkout-index' will create a temporary file for each index +entry being checked out. The index will not be updated with stat +information. These options can be useful if the caller needs all +stages of all unmerged entries so that the unmerged files can be +processed by an external merge tool. + +A listing will be written to stdout providing the association of +temporary file names to tracked path names. The listing format +has two variations: + + . tempname TAB path RS ++ +The first format is what gets used when `--stage` is omitted or +is not `--stage=all`. The field tempname is the temporary file +name holding the file content and path is the tracked path name in +the index. Only the requested entries are output. + + . stage1temp SP stage2temp SP stage3tmp TAB path RS ++ +The second format is what gets used when `--stage=all`. The three +stage temporary fields (stage1temp, stage2temp, stage3temp) list the +name of the temporary file if there is a stage entry in the index +or `.` if there is no stage entry. Paths which only have a stage 0 +entry will always be omitted from the output. + +In both formats RS (the record separator) is newline by default +but will be the null byte if -z was passed on the command line. +The temporary file names are always safe strings; they will never +contain directory separators or whitespace characters. The path +field is always relative to the current directory and the temporary +file names are always relative to the top level directory. + +If the object being copied out to a temporary file is a symbolic +link the content of the link will be written to a normal file. It is +up to the end-user or the Porcelain to make use of this information. + + +EXAMPLES +-------- +To update and refresh only the files already checked out:: ++ +---------------- +$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh +---------------- + +Using 'git-checkout-index' to "export an entire tree":: + The prefix ability basically makes it trivial to use + 'git-checkout-index' as an "export as tree" function. + Just read the desired tree into the index, and do: ++ +---------------- +$ git checkout-index --prefix=git-export-dir/ -a +---------------- ++ +`git checkout-index` will "export" the index into the specified +directory. ++ +The final "/" is important. The exported name is literally just +prefixed with the specified string. Contrast this with the +following example. + +Export files with a prefix:: ++ +---------------- +$ git checkout-index --prefix=.merged- Makefile +---------------- ++ +This will check out the currently cached copy of `Makefile` +into the file `.merged-Makefile`. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + + +Documentation +-------------- +Documentation by David Greaves, +Junio C Hamano and the git-list <git@vger.kernel.org>. + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt new file mode 100644 index 0000000000..37c1810e3f --- /dev/null +++ b/Documentation/git-checkout.txt @@ -0,0 +1,275 @@ +git-checkout(1) +=============== + +NAME +---- +git-checkout - Checkout a branch or paths to the working tree + +SYNOPSIS +-------- +[verse] +'git checkout' [-q] [-f] [-m] [<branch>] +'git checkout' [-q] [-f] [-m] [-b <new_branch>] [<start_point>] +'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>... +'git checkout' --patch [<tree-ish>] [--] [<paths>...] + +DESCRIPTION +----------- + +When <paths> are not given, this command switches branches by +updating the index, working tree, and HEAD to reflect the specified +branch. + +If `-b` is given, a new branch is created and checked out, as if +linkgit:git-branch[1] were called; in this case you can +use the --track or --no-track options, which will be passed to `git +branch`. As a convenience, --track without `-b` implies branch +creation; see the description of --track below. + +When <paths> or --patch are given, this command does *not* switch +branches. It updates the named paths in the working tree from +the index file, or from a named <tree-ish> (most often a commit). In +this case, the `-b` and `--track` options are meaningless and giving +either of them results in an error. The <tree-ish> argument can be +used to specify a specific tree-ish (i.e. commit, tag or tree) +to update the index for the given paths before updating the +working tree. + +The index may contain unmerged entries after a failed merge. By +default, if you try to check out such an entry from the index, the +checkout operation will fail and nothing will be checked out. +Using -f will ignore these unmerged entries. The contents from a +specific side of the merge can be checked out of the index by +using --ours or --theirs. With -m, changes made to the working tree +file can be discarded to recreate the original conflicted merge result. + +OPTIONS +------- +-q:: +--quiet:: + Quiet, suppress feedback messages. + +-f:: +--force:: + When switching branches, proceed even if the index or the + working tree differs from HEAD. This is used to throw away + local changes. ++ +When checking out paths from the index, do not fail upon unmerged +entries; instead, unmerged entries are ignored. + +--ours:: +--theirs:: + When checking out paths from the index, check out stage #2 + ('ours') or #3 ('theirs') for unmerged paths. + +-b:: + Create a new branch named <new_branch> and start it at + <start_point>; see linkgit:git-branch[1] for details. + +-t:: +--track:: + When creating a new branch, set up "upstream" configuration. See + "--track" in linkgit:git-branch[1] for details. ++ +If no '-b' option is given, the name of the new branch will be +derived from the remote branch. If "remotes/" or "refs/remotes/" +is prefixed it is stripped away, and then the part up to the +next slash (which would be the nickname of the remote) is removed. +This would tell us to use "hack" as the local branch when branching +off of "origin/hack" (or "remotes/origin/hack", or even +"refs/remotes/origin/hack"). If the given name has no slash, or the above +guessing results in an empty name, the guessing is aborted. You can +explicitly give a name with '-b' in such a case. + +--no-track:: + Do not set up "upstream" configuration, even if the + branch.autosetupmerge configuration variable is true. + +-l:: + Create the new branch's reflog; see linkgit:git-branch[1] for + details. + +-m:: +--merge:: + When switching branches, + if you have local modifications to one or more files that + are different between the current branch and the branch to + which you are switching, the command refuses to switch + branches in order to preserve your modifications in context. + However, with this option, a three-way merge between the current + branch, your working tree contents, and the new branch + is done, and you will be on the new branch. ++ +When a merge conflict happens, the index entries for conflicting +paths are left unmerged, and you need to resolve the conflicts +and mark the resolved paths with `git add` (or `git rm` if the merge +should result in deletion of the path). ++ +When checking out paths from the index, this option lets you recreate +the conflicted merge in the specified paths. + +--conflict=<style>:: + The same as --merge option above, but changes the way the + conflicting hunks are presented, overriding the + merge.conflictstyle configuration variable. Possible values are + "merge" (default) and "diff3" (in addition to what is shown by + "merge" style, shows the original contents). + +-p:: +--patch:: + Interactively select hunks in the difference between the + <tree-ish> (or the index, if unspecified) and the working + tree. The chosen hunks are then applied in reverse to the + working tree (and if a <tree-ish> was specified, the index). ++ +This means that you can use `git checkout -p` to selectively discard +edits from your current working tree. + +<branch>:: + Branch to checkout; if it refers to a branch (i.e., a name that, + when prepended with "refs/heads/", is a valid ref), then that + branch is checked out. Otherwise, if it refers to a valid + commit, your HEAD becomes "detached" and you are no longer on + any branch (see below for details). ++ +As a special case, the `"@\{-N\}"` syntax for the N-th last branch +checks out the branch (instead of detaching). You may also specify +`-` which is synonymous with `"@\{-1\}"`. + +<new_branch>:: + Name for the new branch. + +<start_point>:: + The name of a commit at which to start the new branch; see + linkgit:git-branch[1] for details. Defaults to HEAD. + +<tree-ish>:: + Tree to checkout from (when paths are given). If not specified, + the index will be used. + + + +Detached HEAD +------------- + +It is sometimes useful to be able to 'checkout' a commit that is +not at the tip of one of your branches. The most obvious +example is to check out the commit at a tagged official release +point, like this: + +------------ +$ git checkout v2.6.18 +------------ + +Earlier versions of git did not allow this and asked you to +create a temporary branch using the `-b` option, but starting from +version 1.5.0, the above command 'detaches' your HEAD from the +current branch and directly points at the commit named by the tag +(`v2.6.18` in the example above). + +You can use all git commands while in this state. You can use +`git reset --hard $othercommit` to further move around, for +example. You can make changes and create a new commit on top of +a detached HEAD. You can even create a merge by using `git +merge $othercommit`. + +The state you are in while your HEAD is detached is not recorded +by any branch (which is natural --- you are not on any branch). +What this means is that you can discard your temporary commits +and merges by switching back to an existing branch (e.g. `git +checkout master`), and a later `git prune` or `git gc` would +garbage-collect them. If you did this by mistake, you can ask +the reflog for HEAD where you were, e.g. + +------------ +$ git log -g -2 HEAD +------------ + + +EXAMPLES +-------- + +. The following sequence checks out the `master` branch, reverts +the `Makefile` to two revisions back, deletes hello.c by +mistake, and gets it back from the index. ++ +------------ +$ git checkout master <1> +$ git checkout master~2 Makefile <2> +$ rm -f hello.c +$ git checkout hello.c <3> +------------ ++ +<1> switch branch +<2> take a file out of another commit +<3> restore hello.c from the index ++ +If you have an unfortunate branch that is named `hello.c`, this +step would be confused as an instruction to switch to that branch. +You should instead write: ++ +------------ +$ git checkout -- hello.c +------------ + +. After working in the wrong branch, switching to the correct +branch would be done using: ++ +------------ +$ git checkout mytopic +------------ ++ +However, your "wrong" branch and correct "mytopic" branch may +differ in files that you have modified locally, in which case +the above checkout would fail like this: ++ +------------ +$ git checkout mytopic +fatal: Entry 'frotz' not uptodate. Cannot merge. +------------ ++ +You can give the `-m` flag to the command, which would try a +three-way merge: ++ +------------ +$ git checkout -m mytopic +Auto-merging frotz +------------ ++ +After this three-way merge, the local modifications are _not_ +registered in your index file, so `git diff` would show you what +changes you made since the tip of the new branch. + +. When a merge conflict happens during switching branches with +the `-m` option, you would see something like this: ++ +------------ +$ git checkout -m mytopic +Auto-merging frotz +ERROR: Merge conflict in frotz +fatal: merge program failed +------------ ++ +At this point, `git diff` shows the changes cleanly merged as in +the previous example, as well as the changes in the conflicted +files. Edit and resolve the conflict and mark it resolved with +`git add` as usual: ++ +------------ +$ edit frotz +$ git add frotz +------------ + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt new file mode 100644 index 0000000000..b764130d26 --- /dev/null +++ b/Documentation/git-cherry-pick.txt @@ -0,0 +1,84 @@ +git-cherry-pick(1) +================== + +NAME +---- +git-cherry-pick - Apply the change introduced by an existing commit + +SYNOPSIS +-------- +'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] <commit> + +DESCRIPTION +----------- +Given one existing commit, apply the change the patch introduces, and record a +new commit that records it. This requires your working tree to be clean (no +modifications from the HEAD commit). + +OPTIONS +------- +<commit>:: + Commit to cherry-pick. + For a more complete list of ways to spell commits, see the + "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. + +-e:: +--edit:: + With this option, 'git-cherry-pick' will let you edit the commit + message prior to committing. + +-x:: + When recording the commit, append to the original commit + message a note that indicates which commit this change + was cherry-picked from. Append the note only for cherry + picks without conflicts. Do not use this option if + you are cherry-picking from your private branch because + the information is useless to the recipient. If on the + other hand you are cherry-picking between two publicly + visible branches (e.g. backporting a fix to a + maintenance branch for an older release from a + development branch), adding this information can be + useful. + +-r:: + It used to be that the command defaulted to do `-x` + described above, and `-r` was to disable it. Now the + default is not to do `-x` so this option is a no-op. + +-m parent-number:: +--mainline parent-number:: + Usually you cannot cherry-pick a merge because you do not know which + side of the merge should be considered the mainline. This + option specifies the parent number (starting from 1) of + the mainline and allows cherry-pick to replay the change + relative to the specified parent. + +-n:: +--no-commit:: + Usually the command automatically creates a commit. + This flag applies the change necessary to cherry-pick + the named commit to your working tree and the index, + but does not make the commit. In addition, when this + option is used, your index does not have to match the + HEAD commit. The cherry-pick is done against the + beginning state of your index. ++ +This is useful when cherry-picking more than one commits' +effect to your index in a row. + +-s:: +--signoff:: + Add Signed-off-by line at the end of the commit message. + + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt new file mode 100644 index 0000000000..7deefdae8f --- /dev/null +++ b/Documentation/git-cherry.txt @@ -0,0 +1,76 @@ +git-cherry(1) +============= + +NAME +---- +git-cherry - Find commits not merged upstream + +SYNOPSIS +-------- +'git cherry' [-v] [<upstream> [<head> [<limit>]]] + +DESCRIPTION +----------- +The changeset (or "diff") of each commit between the fork-point and <head> +is compared against each commit between the fork-point and <upstream>. +The commits are compared with their 'patch id', obtained from +the 'git-patch-id' program. + +Every commit that doesn't exist in the <upstream> branch +has its id (sha1) reported, prefixed by a symbol. The ones that have +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. + + +OPTIONS +------- +-v:: + Verbose. + +<upstream>:: + Upstream branch to compare against. + Defaults to the first tracked remote branch, if available. + +<head>:: + Working branch; defaults to HEAD. + +<limit>:: + Do not report commits up to (and including) limit. + +SEE ALSO +-------- +linkgit:git-patch-id[1] + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-citool.txt b/Documentation/git-citool.txt new file mode 100644 index 0000000000..670cb02b6c --- /dev/null +++ b/Documentation/git-citool.txt @@ -0,0 +1,32 @@ +git-citool(1) +============= + +NAME +---- +git-citool - Graphical alternative to git-commit + +SYNOPSIS +-------- +'git citool' + +DESCRIPTION +----------- +A Tcl/Tk based graphical interface to review modified files, stage +them into the index, enter a commit message and record the new +commit onto the current branch. This interface is an alternative +to the less interactive 'git-commit' program. + +'git-citool' is actually a standard alias for `git gui citool`. +See linkgit:git-gui[1] for more details. + +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-clean.txt b/Documentation/git-clean.txt new file mode 100644 index 0000000000..9d291bdd26 --- /dev/null +++ b/Documentation/git-clean.txt @@ -0,0 +1,66 @@ +git-clean(1) +============ + +NAME +---- +git-clean - Remove untracked files from the working tree + +SYNOPSIS +-------- +[verse] +'git clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <path>... + +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' +option is specified, ignored files are also removed. This can, for +example, be useful to remove all build products. + +If any optional `<path>...` arguments are given, only those paths +are affected. + +OPTIONS +------- +-d:: + Remove untracked directories in addition to untracked files. + If an untracked directory is managed by a different git + repository, it is not removed by default. Use -f option twice + if you really want to remove such a directory. + +-f:: +--force:: + If the git configuration specifies clean.requireForce as true, + 'git-clean' will refuse to run unless given -f or -n. + +-n:: +--dry-run:: + Don't actually remove anything, just show what would be done. + +-q:: +--quiet:: + Be quiet, only report errors, but not the files that are + successfully removed. + +-x:: + Don't use the ignore rules. This allows removing all untracked + files, including build products. This can be used (possibly in + conjunction with 'git-reset') to create a pristine + working directory to test a clean build. + +-X:: + Remove only files ignored by git. This may be useful to rebuild + everything from scratch, but keep manually created files. + + +Author +------ +Written by Pavel Roskin <proski@gnu.org> + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt new file mode 100644 index 0000000000..7ccd742a87 --- /dev/null +++ b/Documentation/git-clone.txt @@ -0,0 +1,239 @@ +git-clone(1) +============ + +NAME +---- +git-clone - Clone a repository into a new directory + + +SYNOPSIS +-------- +[verse] +'git clone' [--template=<template_directory>] + [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] + [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] + [--depth <depth>] [--recursive] [--] <repository> [<directory>] + +DESCRIPTION +----------- + +Clones a repository into a newly created directory, creates +remote-tracking branches for each branch in the cloned repository +(visible using `git branch -r`), and creates and checks out an +initial branch that is forked from the cloned repository's +currently active branch. + +After the clone, a plain `git fetch` without arguments will update +all the remote-tracking branches, and a `git pull` without +arguments will in addition merge the remote master branch into the +current master branch, if any. + +This default configuration is achieved by creating references to +the remote branch heads under `$GIT_DIR/refs/remotes/origin` and +by initializing `remote.origin.url` and `remote.origin.fetch` +configuration variables. + + +OPTIONS +------- +--local:: +-l:: + When the repository to clone from is on a local machine, + 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. + +--no-hardlinks:: + Optimize the cloning process from a repository on a + local filesystem by copying files under `.git/objects` + directory. + +--shared:: +-s:: + When the repository to clone is on the local machine, + instead of using hard links, automatically setup + `.git/objects/info/alternates` to share the objects + with the source repository. The resulting repository + starts out without any object of its own. ++ +*NOTE*: this is a possibly dangerous operation; do *not* use +it unless you understand what it does. If you clone your +repository using this option and then delete branches (or use any +other git command that makes any existing commit unreferenced) in the +source repository, some objects may become unreferenced (or dangling). +These objects may be removed by normal git operations (such as `git commit`) +which automatically call `git gc --auto`. (See linkgit:git-gc[1].) +If these objects are removed and were referenced by the cloned repository, +then the cloned repository will become corrupt. ++ +Note that running `git repack` without the `-l` option in a repository +cloned with `-s` will copy objects from the source repository into a pack +in the cloned repository, removing the disk space savings of `clone -s`. +It is safe, however, to run `git gc`, which uses the `-l` option by +default. ++ +If you want to break the dependency of a repository cloned with `-s` on +its source repository, you can simply run `git repack -a` to copy all +objects from the source repository into a pack in the cloned repository. + +--reference <repository>:: + If the reference repository is on the local machine, + automatically setup `.git/objects/info/alternates` to + obtain objects from the reference repository. Using + an already existing repository as an alternate will + require fewer objects to be copied from the repository + being cloned, reducing network and local storage costs. ++ +*NOTE*: see the NOTE for the `--shared` option. + +--quiet:: +-q:: + Operate quietly. This flag is also passed to the `rsync' + command when given. + +--verbose:: +-v:: + Display the progress bar, even in case the standard output is not + a terminal. + +--no-checkout:: +-n:: + No checkout of HEAD is performed after the clone is complete. + +--bare:: + 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` + because there is nowhere to check out the working tree. + Also the branch heads at the remote are copied directly + to corresponding local branch heads, without mapping + them to `refs/remotes/origin/`. When this option is + used, neither remote-tracking branches nor the related + configuration variables are created. + +--mirror:: + Set up a mirror of the remote repository. This implies `--bare`. + +--origin <name>:: +-o <name>:: + Instead of using the remote name `origin` to keep track + of the upstream repository, use `<name>`. + +--branch <name>:: +-b <name>:: + Instead of pointing the newly created HEAD to the branch pointed + to by the cloned repository's HEAD, point to `<name>` branch + instead. In a non-bare repository, this is the branch that will + be checked out. + +--upload-pack <upload-pack>:: +-u <upload-pack>:: + When given, and the repository to clone from is accessed + via ssh, this specifies a non-default path for the command + run on the other end. + +--template=<template_directory>:: + Specify the directory from which templates will be used; + if unset the templates are taken from the installation + defined default, typically `/usr/share/git-core/templates`. + +--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. + +--recursive:: + After the clone is created, initialize all submodules within, + using their default settings. This is equivalent to running + `git submodule update --init --recursive` immediately after + the clone is finished. This option is ignored if the cloned + repository does not have a worktree/checkout (i.e. if any of + `--no-checkout`/`-n`, `--bare`, or `--mirror` is given) + +<repository>:: + The (possibly remote) repository to clone from. See the + <<URLS,URLS>> section below for more information on specifying + repositories. + +<directory>:: + The name of a new directory to clone into. The "humanish" + part of the source repository is used if no directory is + explicitly given (`repo` for `/path/to/repo.git` and `foo` + for `host.xz:foo/.git`). Cloning into an existing directory + is only allowed if the directory is empty. + +:git-clone: 1 +include::urls.txt[] + +Examples +-------- + +Clone from upstream:: ++ +------------ +$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 +$ cd my2.6 +$ make +------------ + + +Make a local clone that borrows from the current directory, without checking things out:: ++ +------------ +$ git clone -l -s -n . ../copy +$ cd ../copy +$ 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 +------------ + + +Create a bare repository to publish your changes to the public:: ++ +------------ +$ 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 +------------ + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt new file mode 100644 index 0000000000..b8834baced --- /dev/null +++ b/Documentation/git-commit-tree.txt @@ -0,0 +1,106 @@ +git-commit-tree(1) +================== + +NAME +---- +git-commit-tree - Create a new commit object + + +SYNOPSIS +-------- +'git commit-tree' <tree> [-p <parent commit>]\* < changelog + +DESCRIPTION +----------- +This is usually not what an end user wants to run directly. See +linkgit:git-commit[1] instead. + +Creates a new commit object based on the provided tree object and +emits the new commit object id on stdout. + +A commit object may have any number of parents. With exactly one +parent, it is an ordinary commit. Having more than one parent makes +the commit a merge between several lines of history. Initial (root) +commits have no parents. + +While a tree represents a particular directory state of a working +directory, a commit represents that state in "time", and explains how +to get there. + +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 +state was. + +OPTIONS +------- +<tree>:: + An existing tree object + +-p <parent commit>:: + Each '-p' indicates the id of a parent commit object. + + +Commit Information +------------------ + +A commit encapsulates: + +- all parent object ids +- author name, email and date +- committer name and email and the commit time. + +While parent object ids are provided on the command line, author and +committer information is taken from the following environment variables, +if set: + + GIT_AUTHOR_NAME + GIT_AUTHOR_EMAIL + GIT_AUTHOR_DATE + GIT_COMMITTER_NAME + GIT_COMMITTER_EMAIL + GIT_COMMITTER_DATE + EMAIL + +(nb "<", ">" and "\n"s are stripped) + +In case (some of) these environment variables are not set, the information +is taken from the configuration items user.name and user.email, or, if not +present, system user name and fully qualified hostname. + +A commit comment is read from stdin. If a changelog +entry is not provided via "<" redirection, 'git-commit-tree' will just wait +for one to be entered and terminated with ^D. + + +Diagnostics +----------- +You don't exist. Go away!:: + The passwd(5) gecos field couldn't be read +Your parents must have hated you!:: + The passwd(5) gecos field is longer than a giant static buffer. +Your sysadmin must hate you!:: + The passwd(5) name field is longer than a giant static buffer. + +Discussion +---------- + +include::i18n.txt[] + +SEE ALSO +-------- +linkgit:git-write-tree[1] + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt new file mode 100644 index 0000000000..d227cec9ba --- /dev/null +++ b/Documentation/git-commit.txt @@ -0,0 +1,356 @@ +git-commit(1) +============= + +NAME +---- +git-commit - Record changes to the repository + +SYNOPSIS +-------- +[verse] +'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run] + [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author] + [--allow-empty] [--no-verify] [-e] [--author=<author>] + [--cleanup=<mode>] [--] [[-i | -o ]<file>...] + +DESCRIPTION +----------- +Stores the current contents of the index in a new commit along +with a log message from the user describing the changes. + +The content to be added can be specified in several ways: + +1. by using 'git-add' to incrementally "add" changes to the + index before using the 'commit' command (Note: even modified + files must be "added"); + +2. by using 'git-rm' to remove files from the working tree + and the index, again before using the 'commit' command; + +3. by listing files as arguments to the 'commit' command, in which + case the commit will ignore changes staged in the index, and instead + record the current content of the listed files (which must already + be known to git); + +4. by using the -a switch with the 'commit' command to automatically + "add" changes from all known files (i.e. all files that are already + listed in the index) and to automatically "rm" files in the index + that have been removed from the working tree, and then perform the + actual commit; + +5. by using the --interactive switch with the 'commit' command to decide one + by one which files should be part of the commit, before finalizing the + operation. Currently, this is done by invoking 'git-add --interactive'. + +The `--dry-run` option can be used to obtain a +summary of what is included by any of the above for the next +commit by giving the same set of parameters (options and paths). + +If you make a commit and then find a mistake immediately after +that, you can recover from it with 'git-reset'. + + +OPTIONS +------- +-a:: +--all:: + Tell the command to automatically stage files that have + been modified and deleted, but new files you have not + told git about are not affected. + +-C <commit>:: +--reuse-message=<commit>:: + Take an existing commit object, and reuse the log message + and the authorship information (including the timestamp) + when creating the commit. + +-c <commit>:: +--reedit-message=<commit>:: + Like '-C', but with '-c' the editor is invoked, so that + the user can further edit the commit message. + +--reset-author:: + When used with -C/-c/--amend options, declare that the + authorship of the resulting commit now belongs of the committer. + This also renews the author timestamp. + +-F <file>:: +--file=<file>:: + Take the commit message from the given file. Use '-' to + read the message from the standard input. + +--author=<author>:: + Override the author name used in the commit. You can use the + standard `A U Thor <author@example.com>` format. Otherwise, + an existing commit that matches the given string and its author + name is used. + +-m <msg>:: +--message=<msg>:: + Use the given <msg> as the commit message. + +-t <file>:: +--template=<file>:: + Use the contents of the given file as the initial version + of the commit message. The editor is invoked and you can + make subsequent changes. If a message is specified using + the `-m` or `-F` options, this option has no effect. This + overrides the `commit.template` configuration variable. + +-s:: +--signoff:: + Add Signed-off-by line by the committer at the end of the commit + log message. + +-n:: +--no-verify:: + This option bypasses the pre-commit and commit-msg hooks. + See also linkgit:githooks[5]. + +--allow-empty:: + Usually recording a commit that has the exact same tree as its + sole parent commit is a mistake, and the command prevents you + from making such a commit. This option bypasses the safety, and + is primarily for use by foreign scm interface scripts. + +--cleanup=<mode>:: + This option sets how the commit message is cleaned up. + The '<mode>' can be one of 'verbatim', 'whitespace', 'strip', + and 'default'. The 'default' mode will strip leading and + trailing empty lines and #commentary from the commit message + only if the message is to be edited. Otherwise only whitespace + removed. The 'verbatim' mode does not change message at all, + 'whitespace' removes just leading/trailing whitespace lines + and 'strip' removes both whitespace and commentary. + +-e:: +--edit:: + The message taken from file with `-F`, command line with + `-m`, and from file with `-C` are usually used as the + commit log message unmodified. This option lets you + further edit the message taken from these sources. + +--amend:: + Used to amend the tip of the current branch. Prepare the tree + object you would want to replace the latest commit as usual + (this includes the usual -i/-o and explicit paths), and the + 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. ++ +-- +It is a rough equivalent for: +------ + $ git reset --soft HEAD^ + $ ... do something else to come up with the right tree ... + $ git commit -c ORIG_HEAD + +------ +but can be used to amend a merge commit. +-- ++ +You should understand the implications of rewriting history if you +amend a commit that has already been published. (See the "RECOVERING +FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].) + +-i:: +--include:: + Before making a commit out of staged contents so far, + stage the contents of paths given on the command line + as well. This is usually not what you want unless you + are concluding a conflicted merge. + +-o:: +--only:: + Make a commit only from the paths specified on the + command line, disregarding any contents that have been + staged so far. This is the default mode of operation of + 'git-commit' if any paths are given on the command line, + in which case this option can be omitted. + If this option is specified together with '--amend', then + no paths need to be specified, which can be used to amend + the last commit without committing changes that have + already been staged. + +-u[<mode>]:: +--untracked-files[=<mode>]:: + Show untracked files (Default: 'all'). ++ +The mode parameter is optional, and is used to specify +the handling of untracked files. The possible options are: ++ +-- + - 'no' - Show no untracked files + - 'normal' - Shows untracked files and directories + - 'all' - Also shows individual files in untracked directories. +-- ++ +See linkgit:git-config[1] for configuration variable +used to change the default for when the option is not +specified. + +-v:: +--verbose:: + Show unified diff between the HEAD commit and what + would be committed at the bottom of the commit message + template. Note that this diff output doesn't have its + lines prefixed with '#'. + +-q:: +--quiet:: + Suppress commit summary message. + +--dry-run:: + Do not create a commit, but show a list of paths that are + to be committed, paths with local changes that will be left + uncommitted and paths that are untracked. + +\--:: + Do not interpret any more arguments as options. + +<file>...:: + When files are given on the command line, the command + commits the contents of the named files, without + recording the changes already staged. The contents of + these files are also staged for the next commit on top + of what have been staged before. + + +EXAMPLES +-------- +When recording your own work, the contents of modified files in +your working tree are temporarily stored to a staging area +called the "index" with 'git-add'. A file can be +reverted back, only in the index but not in the working tree, +to that of the last commit with `git reset HEAD -- <file>`, +which effectively reverts 'git-add' and prevents the changes to +this file from participating in the next commit. After building +the state to be committed incrementally with these commands, +`git commit` (without any pathname parameter) is used to record what +has been staged so far. This is the most basic form of the +command. An example: + +------------ +$ edit hello.c +$ git rm goodbye.c +$ git add hello.c +$ git commit +------------ + +Instead of staging files after each individual change, you can +tell `git commit` to notice the changes to the files whose +contents are tracked in +your working tree and do corresponding `git add` and `git rm` +for you. That is, this example does the same as the earlier +example if there is no other change in your working tree: + +------------ +$ edit hello.c +$ rm goodbye.c +$ git commit -a +------------ + +The command `git commit -a` first looks at your working tree, +notices that you have modified hello.c and removed goodbye.c, +and performs necessary `git add` and `git rm` for you. + +After staging changes to many files, you can alter the order the +changes are recorded in, by giving pathnames to `git commit`. +When pathnames are given, the command makes a commit that +only records the changes made to the named paths: + +------------ +$ edit hello.c hello.h +$ git add hello.c hello.h +$ edit Makefile +$ git commit Makefile +------------ + +This makes a commit that records the modification to `Makefile`. +The changes staged for `hello.c` and `hello.h` are not included +in the resulting commit. However, their changes are not lost -- +they are still staged and merely held back. After the above +sequence, if you do: + +------------ +$ git commit +------------ + +this second commit would record the changes to `hello.c` and +`hello.h` as expected. + +After a merge (initiated by 'git-merge' or 'git-pull') stops +because of conflicts, cleanly merged +paths are already staged to be committed for you, and paths that +conflicted are left in unmerged state. You would have to first +check which paths are conflicting with 'git-status' +and after fixing them manually in your working tree, you would +stage the result as usual with 'git-add': + +------------ +$ git status | grep unmerged +unmerged: hello.c +$ edit hello.c +$ git add hello.c +------------ + +After resolving conflicts and staging the result, `git ls-files -u` +would stop mentioning the conflicted path. When you are done, +run `git commit` to finally record the merge: + +------------ +$ git commit +------------ + +As with the case to record your own changes, you can use `-a` +option to save typing. One difference is that during a merge +resolution, you cannot use `git commit` with pathnames to +alter the order the changes are committed, because the merge +should be recorded as a single commit. In fact, the command +refuses to run when given pathnames (but see `-i` option). + + +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. + +include::i18n.txt[] + +ENVIRONMENT AND CONFIGURATION VARIABLES +--------------------------------------- +The editor used to edit the commit log message will be chosen from the +GIT_EDITOR environment variable, the core.editor configuration variable, the +VISUAL environment variable, or the EDITOR environment variable (in that +order). See linkgit:git-var[1] for details. + +HOOKS +----- +This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`, +and `post-commit` hooks. See linkgit:githooks[5] for more +information. + + +SEE ALSO +-------- +linkgit:git-add[1], +linkgit:git-rm[1], +linkgit:git-mv[1], +linkgit:git-merge[1], +linkgit:git-commit-tree[1] + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> and +Junio C Hamano <gitster@pobox.com> + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt new file mode 100644 index 0000000000..f68b198205 --- /dev/null +++ b/Documentation/git-config.txt @@ -0,0 +1,342 @@ +git-config(1) +============= + +NAME +---- +git-config - Get and set repository or global options + + +SYNOPSIS +-------- +[verse] +'git config' [<file-option>] [type] [-z|--null] name [value [value_regex]] +'git config' [<file-option>] [type] --add name value +'git config' [<file-option>] [type] --replace-all name value [value_regex] +'git config' [<file-option>] [type] [-z|--null] --get name [value_regex] +'git config' [<file-option>] [type] [-z|--null] --get-all name [value_regex] +'git config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex] +'git config' [<file-option>] --unset name [value_regex] +'git config' [<file-option>] --unset-all name [value_regex] +'git config' [<file-option>] --rename-section old_name new_name +'git config' [<file-option>] --remove-section name +'git config' [<file-option>] [-z|--null] -l | --list +'git config' [<file-option>] --get-color name [default] +'git config' [<file-option>] --get-colorbool name [stdout-is-tty] +'git config' [<file-option>] -e | --edit + +DESCRIPTION +----------- +You can query/set/replace/unset options with this command. The name is +actually the section and the key separated by a dot, and the value will be +escaped. + +Multiple lines can be added to an option by using the '--add' option. +If you want to update or unset an option which can occur on multiple +lines, a POSIX regexp `value_regex` needs to be given. Only the +existing values that match the regexp are updated or unset. If +you want to handle the lines that do *not* match the regex, just +prepend a single exclamation mark in front (see also <<EXAMPLES>>). + +The type specifier can be either '--int' or '--bool', which will make +'git-config' ensure that the variable(s) are of the given type and +convert the value to the canonical form (simple decimal number for int, +a "true" or "false" string for bool). If no type specifier is passed, +no checks or transformations are performed on the value. + +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>>). + +This command will fail if: + +. The config file is invalid, +. Can not write to the config file, +. no section was provided, +. the section or key is invalid, +. you try to unset an option which does not exist, +. you try to unset/set an option for which multiple lines match, or +. you use '--global' option without $HOME being properly set. + + +OPTIONS +------- + +--replace-all:: + Default behavior is to replace at most one line. This replaces + all lines matching the key (and optionally the value_regex). + +--add:: + Adds a new line to the option without altering any existing + values. This is the same as providing '^$' as the value_regex + in `--replace-all`. + +--get:: + Get the value for a given key (optionally filtered by a regex + matching the value). Returns error code 1 if the key was not + found and error code 2 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. + +--global:: + For writing options: write to global ~/.gitconfig file rather than + the repository .git/config. ++ +For reading options: read only from global ~/.gitconfig 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 reading options: read only from system-wide $(prefix)/etc/gitconfig +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. + +--remove-section:: + Remove the given section from the configuration file. + +--rename-section:: + Rename the given section to a new name. + +--unset:: + Remove the line matching the key from config file. + +--unset-all:: + Remove all lines matching the key from config file. + +-l:: +--list:: + List all variables set in config file. + +--bool:: + 'git-config' will ensure that the output is "true" or "false" + +--int:: + 'git-config' will ensure that the output is a simple + decimal number. An optional value suffix of 'k', 'm', or 'g' + in the config file will cause the value to be multiplied + by 1024, 1048576, or 1073741824 prior to output. + +--bool-or-int:: + 'git-config' will ensure that the output matches the format of + either --bool or --int, as described above. + +-z:: +--null:: + For all options that output values and/or keys, always + end values with the null character (instead of a + newline). Use newline instead as a delimiter between + key and value. This allows for secure parsing of the + output without getting confused e.g. by values that + contain line breaks. + +--get-colorbool name [stdout-is-tty]:: + + Find the color setting for `name` (e.g. `color.diff`) and output + "true" or "false". `stdout-is-tty` should be either "true" or + "false", and is taken into account when configuration says + "auto". If `stdout-is-tty` is missing, then checks the standard + output of the command itself, and exits with status 0 if color + is to be used, or exits with status 1 otherwise. + When the color setting for `name` is undefined, the command uses + `color.ui` as fallback. + +--get-color name [default]:: + + Find the color configured for `name` (e.g. `color.diff.new`) and + output it as the ANSI color escape sequence to the standard + output. The optional `default` parameter is used instead, if + there is no color configured for `name`. + +-e:: +--edit:: + Opens an editor to modify the specified config file; either + '--system', '--global', or repository (default). + +[[FILES]] +FILES +----- + +If not set explicitly with '--file', there are three files where +'git-config' will search for configuration options: + +$GIT_DIR/config:: + Repository specific configuration file. (The filename is + of course relative to the repository root, not the working + directory.) + +~/.gitconfig:: + User-specific configuration file. Also called "global" + configuration file. + +$(prefix)/etc/gitconfig:: + System-wide 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 +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. + +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 +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. + + +ENVIRONMENT +----------- + +GIT_CONFIG:: + Take the configuration from the given file instead of .git/config. + Using the "--global" option forces this to ~/.gitconfig. Using the + "--system" option forces this to $(prefix)/etc/gitconfig. + +See also <<FILES>>. + + +[[EXAMPLES]] +EXAMPLES +-------- + +Given a .git/config like this: + + # + # This is the config file, and + # a '#' or ';' character indicates + # a comment + # + + ; core variables + [core] + ; Don't trust file modes + filemode = false + + ; Our diff algorithm + [diff] + external = /usr/local/bin/diff-wrapper + renames = true + + ; Proxy settings + [core] + gitproxy="proxy-command" for kernel.org + gitproxy=default-proxy ; for all the rest + +you can set the filemode to true with + +------------ +% git config core.filemode true +------------ + +The hypothetical proxy command entries actually have a postfix to discern +what URL they apply to. Here is how to change the entry for kernel.org +to "ssh". + +------------ +% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$' +------------ + +This makes sure that only the key/value pair for kernel.org is replaced. + +To delete the entry for renames, do + +------------ +% git config --unset diff.renames +------------ + +If you want to delete an entry for a multivar (like core.gitproxy above), +you have to provide a regex matching the value of exactly one line. + +To query the value for a given key, do + +------------ +% git config --get core.filemode +------------ + +or + +------------ +% git config core.filemode +------------ + +or, to query a multivar: + +------------ +% git config --get core.gitproxy "for kernel.org$" +------------ + +If you want to know all the values for a multivar, do: + +------------ +% git config --get-all core.gitproxy +------------ + +If you like to live dangerously, you can replace *all* core.gitproxy by a +new one with + +------------ +% git config --replace-all core.gitproxy ssh +------------ + +However, if you really only want to replace the line for the default proxy, +i.e. the one without a "for ..." postfix, do something like this: + +------------ +% git config core.gitproxy ssh '! for ' +------------ + +To actually match only values with an exclamation mark, you have to + +------------ +% git config section.key value '[!]' +------------ + +To add a new proxy, without altering any of the existing ones, use + +------------ +% git config core.gitproxy '"proxy-command" for example.com' +------------ + +An example to use customized color from the configuration in your +script: + +------------ +#!/bin/sh +WS=$(git config --get-color color.diff.whitespace "blue reverse") +RESET=$(git config --get-color "" "reset") +echo "${WS}your whitespace color or blue reverse${RESET}" +------------ + +include::config.txt[] + + +Author +------ +Written by Johannes Schindelin <Johannes.Schindelin@gmx.de> + +Documentation +-------------- +Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt new file mode 100644 index 0000000000..6bc1c21e62 --- /dev/null +++ b/Documentation/git-count-objects.txt @@ -0,0 +1,39 @@ +git-count-objects(1) +==================== + +NAME +---- +git-count-objects - Count unpacked number of objects and their disk consumption + +SYNOPSIS +-------- +'git count-objects' [-v] + +DESCRIPTION +----------- +This counts the number of unpacked object files and disk space consumed by +them, to help you decide when it is a good time to repack. + + +OPTIONS +------- +-v:: +--verbose:: + In addition to the number of loose objects and disk + space consumed, it reports the number of in-pack + objects, number of packs, disk space consumed by those packs, + and number of objects that can be removed by running + `git prune-packed`. + + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt new file mode 100644 index 0000000000..abaaf273bb --- /dev/null +++ b/Documentation/git-cvsexportcommit.txt @@ -0,0 +1,125 @@ +git-cvsexportcommit(1) +====================== + +NAME +---- +git-cvsexportcommit - Export a single commit to a CVS checkout + + +SYNOPSIS +-------- +'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] + [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID + + +DESCRIPTION +----------- +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 +be defined. See examples below. + +It does its best to do the safe thing, it will check that the files are +unchanged and up to date in the CVS checkout, and it will not autocommit +by default. + +Supports file additions, removals, and commits that affect binary files. + +If the commit is a merge commit, you must tell 'git-cvsexportcommit' what +parent the changeset should be done against. + +OPTIONS +------- + +-c:: + Commit automatically if the patch applied cleanly. It will not + commit if any hunks fail to apply or there were other problems. + +-p:: + Be pedantic (paranoid) when applying patches. Invokes patch with + --fuzz=0 + +-a:: + Add authorship information. Adds Author line, and Committer (if + different from Author) to the message. + +-d:: + Set an alternative CVSROOT to use. This corresponds to the CVS + -d parameter. Usually users will not want to set this, except + if using CVS in an asymmetric fashion. + +-f:: + Force the merge even if the files are not up to date. + +-P:: + Force the parent commit, even if it is not a direct parent. + +-m:: + Prepend the commit message with the provided prefix. + Useful for patch series and the like. + +-u:: + Update affected files from CVS repository before attempting export. + +-k:: + Reverse CVS keyword expansion (e.g. $Revision: 1.2.3.4$ + becomes $Revision$) in working CVS checkout before applying patch. + +-w:: + Specify the location of the CVS checkout to use for the export. This + option does not require GIT_DIR to be set before execution if the + current directory is within a git repository. The default is the + value of 'cvsexportcommit.cvsdir'. + +-W:: + Tell cvsexportcommit that the current working directory is not only + a Git checkout, but also the CVS checkout. Therefore, Git will + reset the working directory to the parent commit before proceeding. + +-v:: + Verbose. + +CONFIGURATION +------------- +cvsexportcommit.cvsdir:: + The default location of the CVS checkout to use for the export. + +EXAMPLES +-------- + +Merge one patch into CVS:: ++ +------------ +$ export GIT_DIR=~/project/.git +$ cd ~/project_cvs_checkout +$ git cvsexportcommit -v <commit-sha1> +$ cvs commit -F .msg <files> +------------ + +Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo:: ++ +------------ + $ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1> +------------ + +Merge pending patches into CVS automatically -- only if you really know what you are doing:: ++ +------------ +$ export GIT_DIR=~/project/.git +$ cd ~/project_cvs_checkout +$ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit -c -p -v +------------ + +Author +------ +Written by Martin Langhoff <martin@catalyst.net.nz> and others. + +Documentation +-------------- +Documentation by Martin Langhoff <martin@catalyst.net.nz> and others. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt new file mode 100644 index 0000000000..614e769f4e --- /dev/null +++ b/Documentation/git-cvsimport.txt @@ -0,0 +1,215 @@ +git-cvsimport(1) +================ + +NAME +---- +git-cvsimport - Salvage your data out of another SCM people love to hate + + +SYNOPSIS +-------- +[verse] +'git cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>] + [-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>] + [-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>] + [-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>] + [-r <remote>] [<CVS_module>] + + +DESCRIPTION +----------- +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'. +At least version 2.1 is required. + +*WARNING:* for certain situations the import leads to incorrect results. +Please see the section <<issues,ISSUES>> for further reference. + +You should *never* do any work of your own on the branches that are +created by 'git-cvsimport'. By default initial import will create and populate a +"master" branch from the CVS repository's main branch which you're free +to work with; after that, you need to 'git-merge' incremental imports, or +any CVS branches, yourself. It is advisable to specify a named remote via +-r to separate and protect the incoming branches. + +If you intend to set up a shared public repository that all developers can +read/write, or if you want to use linkgit:git-cvsserver[1], then you +probably want to make a bare clone of the imported repository, +and use the clone as the shared repository. +See linkgit:gitcvs-migration[7]. + + +OPTIONS +------- +-v:: + Verbosity: let 'cvsimport' report what it is doing. + +-d <CVSROOT>:: + The root of the CVS archive. May be local (a simple path) or remote; + currently, only the :local:, :ext: and :pserver: access methods + are supported. If not given, 'git-cvsimport' will try to read it + from `CVS/Root`. If no such file exists, it checks for the + `CVSROOT` environment variable. + +<CVS_module>:: + The CVS module you want to import. Relative to <CVSROOT>. + If not given, 'git-cvsimport' tries to read it from + `CVS/Repository`. + +-C <target-dir>:: + 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. + 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. + 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 + branch. ++ +Use '-o master' for continuing an import that was initially done by +the old cvs2git tool. + +-i:: + Import-only: don't perform a checkout after importing. This option + ensures the working directory and index remain untouched and will + not create them if they do not exist. + +-k:: + Kill keywords: will extract files with '-kk' from the CVS archive + to avoid noisy changesets. Highly recommended, but off by default + to preserve compatibility with early imported trees. + +-u:: + Convert underscores in tag and branch names to dots. + +-s <subst>:: + Substitute the character "/" in branch names with <subst> + +-p <options-for-cvsps>:: + Additional options for cvsps. + The options '-u' and '-A' are implicit and should not be used here. ++ +If you need to pass multiple options, separate them with a comma. + +-z <fuzz>:: + Pass the timestamp fuzz factor to cvsps, in seconds. If unset, + cvsps defaults to 300s. + +-P <cvsps-output-file>:: + Instead of calling cvsps, read the provided cvsps output file. Useful + for debugging or when cvsps is being handled outside cvsimport. + +-m:: + Attempt to detect merges based on the commit message. This option + will enable default regexes that try to capture the source + branch name from the commit message. + +-M <regex>:: + Attempt to detect merges based on the commit message with a custom + regex. It can be used with '-m' to enable the default regexes + as well. You must escape forward slashes. ++ +The regex must capture the source branch name in $1. ++ +This option can be used several times to provide several detection regexes. + +-S <regex>:: + Skip paths matching the regex. + +-a:: + Import all commits, including recent ones. cvsimport by default + skips commits that have a timestamp less than 10 minutes ago. + +-L <limit>:: + Limit the number of commits imported. Workaround for cases where + cvsimport leaks memory. + +-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 ++ +--------- + exon=Andreas Ericsson <ae@op5.se> + spawn=Simon Pawn <spawn@frog-pond.org> + +--------- ++ +'git-cvsimport' will make it appear as those authors had +their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly +all along. ++ +For convenience, this data is saved to `$GIT_DIR/cvs-authors` +each time the '-A' option is provided and read from that same +file each time 'git-cvsimport' is run. ++ +It is not recommended to use this feature if you intend to +export changes back to CVS again later with +'git-cvsexportcommit'. + +-h:: + Print a short usage message and exit. + +OUTPUT +------ +If '-v' is specified, the script reports what it is doing. + +Otherwise, success is indicated the Unix way, i.e. by simply exiting with +a zero exit status. + +[[issues]] +ISSUES +------ +Problems related to timestamps: + + * If timestamps of commits in the cvs repository are not stable enough + to be used for ordering commits changes may show up in the wrong + order. + * If any files were ever "cvs import"ed more than once (e.g., import of + more than one vendor release) the HEAD contains the wrong content. + * If the timestamp order of different files cross the revision order + within the commit matching time window the order of commits may be + wrong. + +Problems related to branches: + + * Branches on which no commits have been made are not imported. + * All files from the branching point are added to a branch even if + never added in cvs. + * This applies to files added to the source branch *after* a daughter + branch was created: if previously no commit was made on the daughter + branch they will erroneously be added to the daughter branch in git. + +Problems related to tags: + +* Multiple tags on the same revision are not imported. + +If you suspect that any of these issues may apply to the repository you +want to import consider using these alternative tools which proved to be +more stable in practice: + +* cvs2git (part of cvs2svn), `http://cvs2svn.tigris.org` +* parsecvs, `http://cgit.freedesktop.org/~keithp/parsecvs` + +Author +------ +Written by Matthias Urlichs <smurf@smurf.noris.de>, with help from +various participants of the git-list <git@vger.kernel.org>. + +Documentation +-------------- +Documentation by Matthias Urlichs <smurf@smurf.noris.de>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt new file mode 100644 index 0000000000..99a7c14700 --- /dev/null +++ b/Documentation/git-cvsserver.txt @@ -0,0 +1,371 @@ +git-cvsserver(1) +================ + +NAME +---- +git-cvsserver - A CVS server emulator for git + +SYNOPSIS +-------- + +SSH: + +[verse] +export CVS_SERVER="git cvsserver" +'cvs' -d :ext:user@server/path/repo.git co <HEAD_name> + +pserver (/etc/inetd.conf): + +[verse] +cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver + +Usage: + +[verse] +'git cvsserver' [options] [pserver|server] [<directory> ...] + +OPTIONS +------- + +All these options obviously only make sense if enforced by the server side. +They have been implemented to resemble the linkgit:git-daemon[1] options as +closely as possible. + +--base-path <path>:: +Prepend 'path' to requested CVSROOT + +--strict-paths:: +Don't allow recursing into subdirectories + +--export-all:: +Don't check for `gitcvs.enabled` in config. You also have to specify a list +of allowed directories (see below) if you want to use this option. + +-V:: +--version:: +Print version information and exit + +-h:: +-H:: +--help:: +Print usage information and exit + +<directory>:: +You can specify a list of allowed directories. If no directories +are given, all are allowed. This is an additional restriction, gitcvs +access still needs to be enabled by the `gitcvs.enabled` config option +unless '--export-all' was given, too. + + +DESCRIPTION +----------- + +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, +not all switches are implemented. + +Testing has been done using both the CLI CVS client, and the Eclipse CVS +plugin. Most functionality works fine with both of these clients. + +LIMITATIONS +----------- + +Currently cvsserver works over SSH connections for read/write clients, and +over pserver for anonymous CVS access. + +CVS clients cannot tag, branch or perform GIT merges. + +'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. + +INSTALLATION +------------ + +1. If you are going to offer anonymous CVS access via pserver, add a line in + /etc/inetd.conf like ++ +-- +------ + cvspserver stream tcp nowait nobody git-cvsserver pserver + +------ +Note: Some inetd servers let you specify the name of the executable +independently of the value of argv[0] (i.e. the name the program assumes +it was executed with). In this case the correct line in /etc/inetd.conf +looks like + +------ + cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver + +------ +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`. + +Note: Newer CVS versions (>= 1.12.11) also support specifying +CVS_SERVER directly in CVSROOT like + +------ +cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name> +------ +This has the advantage that it will be saved in your 'CVS/Root' files and +you don't need to worry about always setting the correct environment +variable. SSH users restricted to 'git-shell' don't need to override the default +with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean +'git-cvsserver' and pretends that the other end runs the real 'cvs' better. +-- +2. For each repo that you want accessible from CVS you need to edit config in + the repo and add the following section. ++ +-- +------ + [gitcvs] + enabled=1 + # optional for debugging + 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. + +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]] +All configuration variables can also be overridden for a specific method of +access. Valid method names are "ext" (for SSH access) and "pserver". The +following example configuration would disable pserver access while still +allowing access over SSH. +------ + [gitcvs] + enabled=0 + + [gitcvs "ext"] + enabled=1 +------ +-- +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 + _not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'. ++ +-- +------ + export CVSROOT=:ext:user@server:/var/git/project.git + export CVS_SERVER="git cvsserver" +------ +-- +4. For SSH clients that will make commits, make sure their server-side + .ssh/environment files (or .bashrc, etc., according to their specific shell) + export appropriate values for GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, + GIT_COMMITTER_NAME, and GIT_COMMITTER_EMAIL. For SSH clients whose login + 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 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: ++ +------ + cvs co -d project-master master +------ + +[[dbbackend]] +Database Backend +---------------- + +'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. + +If the commit is done directly by using `git` (as opposed to +using 'git-cvsserver') the update will need to happen on the +next repository access by 'git-cvsserver', independent of +access method and requested operation. + +That means that even if you offer only read access (e.g. by using +the pserver method), 'git-cvsserver' should have write access to +the database to work reliably (otherwise you need to make sure +that the database is up-to-date any time 'git-cvsserver' is executed). + +By default it uses SQLite databases in the git directory, named +`gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates +temporary files in the same directory as the database file on +write so it might not be enough to grant the users using +'git-cvsserver' write access to the database file without granting +them write access to the directory, too. + +The database can not be reliably regenerated in a +consistent form after the branch it is tracking has changed. +Example: For merged branches, 'git-cvsserver' only tracks +one branch of development, and after a 'git-merge' an +incrementally updated database may track a different branch +than a database regenerated from scratch, causing inconsistent +CVS revision numbers. `git-cvsserver` has no way of knowing which +branch it would have picked if it had been run incrementally +pre-merge. So if you have to fully or partially (from old +backup) regenerate the database, you should be suspicious +of pre-existing CVS sandboxes. + +You can configure the database backend with the following +configuration variables: + +Configuring database backend +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +'git-cvsserver' uses the Perl DBI module. Please also read +its documentation if changing these variables, especially +about `DBI->connect()`. + +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:: + 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 + 'DBD::Pg', and reported *not* to work with 'DBD::mysql'. + Please regard this as an experimental feature. May not + contain colons (`:`). + Default: 'SQLite' + +gitcvs.dbuser:: + 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 + SQLite has no concept of database passwords. + +gitcvs.dbTableNamePrefix:: + Database table name prefix. Supports variable substitution + (see below). Any non-alphabetic characters will be replaced + with underscores. + +All variables can also be set per access method, see <<configaccessmethod,above>>. + +Variable substitution +^^^^^^^^^^^^^^^^^^^^^ +In `dbdriver` and `dbuser` you can use the following variables: + +%G:: + git directory name +%g:: + 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 +%a:: + access method (one of "ext" or "pserver") +%u:: + Name of the user running 'git-cvsserver'. + If no name can be determined, the + numeric uid is used. + +Eclipse CVS Client Notes +------------------------ + +To get a checkout with the Eclipse CVS client: + +1. Select "Create a new project -> From CVS checkout" +2. Create a new location. See the notes below for details on how to choose the + right protocol. +3. Browse the 'modules' available. It will give you a list of the heads in + the repository. You will not be able to browse the tree from there. Only + the heads. +4. Pick 'HEAD' when it asks what branch/tag to check out. Untick the + "launch commit wizard" to avoid committing the .project file. + +Protocol notes: If you are using anonymous access via pserver, just select that. +Those using SSH access should choose the 'ext' protocol, and configure 'ext' +access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to +"'git cvsserver'". Note that password support is not good when using 'ext', +you will definitely want to have SSH keys setup. + +Alternatively, you can just use the non-standard extssh protocol that Eclipse +offer. In that case CVS_SERVER is ignored, and you will have to replace +the cvs utility on the server with 'git-cvsserver' or manipulate your `.bashrc` +so that calling 'cvs' effectively calls 'git-cvsserver'. + +Clients known to work +--------------------- + +- CVS 1.12.9 on Debian +- CVS 1.11.17 on MacOSX (from Fink package) +- Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes) +- TortoiseCVS + +Operations supported +-------------------- + +All the operations required for normal use are supported, including +checkout, diff, status, update, log, add, remove, commit. +Legacy monitoring operations are not supported (edit, watch and related). +Exports and tagging (tags and branches) are not supported at this stage. + +CRLF Line Ending Conversions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +By default the server leaves the '-k' mode blank for all files, +which causes the cvs client to treat them as a text files, subject +to crlf conversion on some platforms. + +You can make the server use `crlf` attributes to set the '-k' modes +for files by setting the `gitcvs.usecrlfattr` config variable. +In this case, if `crlf` is explicitly unset ('-crlf'), then the +server will set '-kb' mode for binary files. If `crlf` is set, +then the '-k' mode will explicitly be left blank. See +also linkgit:gitattributes[5] for more information about the `crlf` +attribute. + +Alternatively, if `gitcvs.usecrlfattr` config is not enabled +or if the `crlf` attribute is unspecified for a filename, then +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 +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". + +Dependencies +------------ +'git-cvsserver' depends on DBD::SQLite. + +Copyright and Authors +--------------------- + +This program is copyright The Open University UK - 2006. + +Authors: + +- Martyn Smith <martyn@catalyst.net.nz> +- Martin Langhoff <martin@catalyst.net.nz> + +with ideas and patches from participants of the git-list <git@vger.kernel.org>. + +Documentation +-------------- +Documentation by Martyn Smith <martyn@catalyst.net.nz>, Martin Langhoff <martin@catalyst.net.nz>, and Matthias Urlichs <smurf@smurf.noris.de>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt new file mode 100644 index 0000000000..a85121c689 --- /dev/null +++ b/Documentation/git-daemon.txt @@ -0,0 +1,293 @@ +git-daemon(1) +============= + +NAME +---- +git-daemon - A really simple server for git repositories + +SYNOPSIS +-------- +[verse] +'git daemon' [--verbose] [--syslog] [--export-all] + [--timeout=n] [--init-timeout=n] [--max-connections=n] + [--strict-paths] [--base-path=path] [--base-path-relaxed] + [--user-path | --user-path=path] + [--interpolated-path=pathtemplate] + [--reuseaddr] [--detach] [--pid-file=file] + [--enable=service] [--disable=service] + [--allow-override=service] [--forbid-override=service] + [--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" +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 +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. + +By default, only `upload-pack` service is enabled, which serves +'git-fetch-pack' and 'git-ls-remote' clients, which are invoked +from 'git-fetch', 'git-pull', and 'git-clone'. + +This is ideally suited for read-only updates, i.e., pulling from +git repositories. + +An `upload-archive` also exists to serve 'git-archive'. + +OPTIONS +------- +--strict-paths:: + Match paths exactly (i.e. don't allow "/foo/repo" when the real path is + "/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths. + 'git-daemon' will refuse to start when this option is enabled and no + whitelist is specified. + +--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 + '--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'. + +--base-path-relaxed:: + If --base-path is enabled and repo lookup fails, with this option + 'git-daemon' will attempt to lookup without prefixing the base path. + This is useful for switching to --base-path usage, while still + allowing the old paths. + +--interpolated-path=pathtemplate:: + To support virtual hosting, an interpolated path template can be + used to dynamically construct alternate paths. The template + supports %H for the target hostname as supplied by the client but + converted to all lowercase, %CH for the canonical hostname, + %IP for the server's IP address, %P for the port number, + and %D for the absolute path of the named repository. + After interpolation, the path is validated against the directory + whitelist. + +--export-all:: + 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. + +--inetd:: + Have the server run as an inetd service. Implies --syslog. + Incompatible with --port, --listen, --user and --group options. + +--listen=host_or_ipaddr:: + Listen on a specific IP address or hostname. IP addresses can + be either an IPv4 address or an IPv6 address if supported. If IPv6 + is not supported, then --listen=hostname is also not supported and + --listen must be given an IPv4 address. + Incompatible with '--inetd' option. + +--port=n:: + Listen on an alternative port. Incompatible with '--inetd' option. + +--init-timeout=n:: + Timeout between the moment the connection is established and the + client request is received (typically a rather low value, since + that should be basically immediate). + +--timeout=n:: + Timeout for specific client sub-requests. This includes the time + it takes for the server to process the sub-request and the time spent + waiting for the next client's request. + +--max-connections=n:: + Maximum number of concurrent clients, defaults to 32. Set it to + zero for no limit. + +--syslog:: + Log to syslog instead of stderr. Note that this option does not imply + --verbose, thus by default only error conditions will be logged. + +--user-path:: +--user-path=path:: + Allow {tilde}user notation to be used in requests. When + specified with no parameter, requests to + git://host/{tilde}alice/foo is taken as a request to access + 'foo' repository in the home directory of user `alice`. + If `--user-path=path` is specified, the same request is + taken as a request to access `path/foo` repository in + the home directory of user `alice`. + +--verbose:: + Log details about the incoming connections and requested files. + +--reuseaddr:: + Use SO_REUSEADDR when binding the listening socket. + This allows the server to restart without waiting for + old connections to time out. + +--detach:: + Detach from the shell. Implies --syslog. + +--pid-file=file:: + Save the process id in 'file'. Ignored when the daemon + is run under `--inetd`. + +--user=user:: +--group=group:: + Change daemon's uid and gid before entering the service loop. + When only `--user` is given without `--group`, the + primary group ID for the user is used. The values of + the option are given to `getpwnam(3)` and `getgrnam(3)` + and numeric IDs are not supported. ++ +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. + +--enable=service:: +--disable=service:: + Enable/disable the service site-wide per default. Note + that a service disabled site-wide can still be enabled + per repository if it is marked overridable and the + repository enables the service with a configuration + item. + +--allow-override=service:: +--forbid-override=service:: + Allow/forbid overriding the site-wide default with per + repository configuration. By default, all the services + are overridable. + +<directory>:: + A directory to add to the whitelist of allowed directories. Unless + --strict-paths is specified this will also include subdirectories + of each named directory. + +SERVICES +-------- + +These services can be globally enabled/disabled using the +command line options of this command. If a finer-grained +control is desired (e.g. to allow 'git-archive' to be run +against only in a few selected repositories the daemon serves), +the per-repository configuration file can be used to enable or +disable them. + +upload-pack:: + This serves 'git-fetch-pack' and 'git-ls-remote' + clients. It is enabled by default, but a repository can + disable it by setting `daemon.uploadpack` configuration + item to `false`. + +upload-archive:: + This serves 'git-archive --remote'. It is disabled by + default, but a repository can enable it by setting + `daemon.uploadarch` configuration item to `true`. + +receive-pack:: + This serves 'git-send-pack' clients, allowing anonymous + push. It is disabled by default, as there is _no_ + authentication in the protocol (in other words, anybody + can push anything into the repository, including removal + 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 + `true`. + +EXAMPLES +-------- +We assume the following in /etc/services:: ++ +------------ +$ grep 9418 /etc/services +git 9418/tcp # Git Version Control System +------------ + +'git-daemon' as inetd server:: + To set up 'git-daemon' as an inetd service that handles any + repository under the whitelisted set of directories, /pub/foo + and /pub/bar, place an entry like the following into + /etc/inetd all on one line: ++ +------------------------------------------------ + git stream tcp nowait nobody /usr/bin/git + git daemon --inetd --verbose --export-all + /pub/foo /pub/bar +------------------------------------------------ + + +'git-daemon' as inetd server for virtual hosts:: + To set up 'git-daemon' as an inetd service that handles + repositories for different virtual hosts, `www.example.com` + and `www.example.org`, place an entry like the following into + `/etc/inetd` all on one line: ++ +------------------------------------------------ + git stream tcp nowait nobody /usr/bin/git + git daemon --inetd --verbose --export-all + --interpolated-path=/pub/%H%D + /pub/www.example.org/software + /pub/www.example.com/software + /software +------------------------------------------------ ++ +In this example, the root-level directory `/pub` will contain +a subdirectory for each virtual host name supported. +Further, both hosts advertise repositories simply as +`git://www.example.com/software/repo.git`. For pre-1.4.0 +clients, a symlink from `/software` into the appropriate +default repository could be made as well. + + +'git-daemon' as regular daemon for virtual hosts:: + To set up 'git-daemon' as a regular, non-inetd service that + handles repositories for multiple virtual hosts based on + their IP addresses, start the daemon like this: ++ +------------------------------------------------ + git daemon --verbose --export-all + --interpolated-path=/pub/%IP/%D + /pub/192.168.1.200/software + /pub/10.10.220.23/software +------------------------------------------------ ++ +In this example, the root-level directory `/pub` will contain +a subdirectory for each virtual host IP address supported. +Repositories can still be accessed by hostname though, assuming +they correspond to these IP addresses. + +selectively enable/disable services per repository:: + To enable 'git-archive --remote' and disable 'git-fetch' against + a repository, have the following in the configuration file in the + repository (that is the file 'config' next to 'HEAD', 'refs' and + 'objects'). ++ +---------------------------------------------------------------- + [daemon] + uploadpack = false + uploadarch = true +---------------------------------------------------------------- + + +ENVIRONMENT +----------- +'git-daemon' will set REMOTE_ADDR to the IP address of the client +that connected to it, if the IP address is available. REMOTE_ADDR will +be available in the environment of hooks called when +services are performed. + + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki +<yoshfuji@linux-ipv6.org> and the git-list <git@vger.kernel.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt new file mode 100644 index 0000000000..78b9808aa3 --- /dev/null +++ b/Documentation/git-describe.txt @@ -0,0 +1,169 @@ +git-describe(1) +=============== + +NAME +---- +git-describe - Show the most recent tag that is reachable from a commit + + +SYNOPSIS +-------- +[verse] +'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>... +'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>] + +DESCRIPTION +----------- +The command finds the most recent tag that is reachable from a +commit. If the tag points to the commit, then only the tag is +shown. Otherwise, it suffixes the tag name with the number of +additional commits on top of the tagged object and the +abbreviated object name of the most recent commit. + +By default (without --all or --tags) `git describe` only shows +annotated tags. For more information about creating annotated tags +see the -a and -s options to linkgit:git-tag[1]. + +OPTIONS +------- +<committish>...:: + Committish object names to describe. + +--dirty[=<mark>]:: + Describe the working tree. + It means describe HEAD and appends <mark> (`-dirty` by + default) if the working tree is dirty. + +--all:: + Instead of using only the annotated tags, use any ref + found in `.git/refs/`. This option enables matching + any known branch, remote branch, or lightweight tag. + +--tags:: + Instead of using only the annotated tags, use any tag + found in `.git/refs/tags`. This option enables matching + a lightweight (non-annotated) tag. + +--contains:: + Instead of finding the tag that predates the commit, find + the tag that comes after the commit, and thus contains it. + Automatically implies --tags. + +--abbrev=<n>:: + Instead of using the default 7 hexadecimal digits as the + abbreviated object name, use <n> digits, or as many digits + as needed to form a unique object name. An <n> of 0 + will suppress long format, only showing the closest tag. + +--candidates=<n>:: + Instead of considering only the 10 most recent tags as + candidates to describe the input committish 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. + +--exact-match:: + Only output exact matches (a tag directly references the + supplied commit). This is a synonym for --candidates=0. + +--debug:: + Verbosely display information about the searching strategy + being employed to standard error. The tag name will still + be printed to standard out. + +--long:: + Always output the long format (the tag, the number of commits + and the abbreviated commit name) even when it matches a tag. + This is useful when you want to see parts of the commit object name + in "describe" output, even when the commit in question happens to be + a tagged version. Instead of just emitting the tag name, it will + describe such a commit as v1.2-0-gdeadbee (0th commit since tag v1.2 + that points at object deadbee....). + +--match <pattern>:: + Only consider tags matching the given pattern (can be used to avoid + leaking private tags made from the repository). + +--always:: + Show uniquely abbreviated commit object as fallback. + +EXAMPLES +-------- + +With something like git.git current tree, I get: + + [torvalds@g5 git]$ git describe parent + v1.0.4-14-g2414721 + +i.e. the current head of my "parent" branch is based on v1.0.4, +but since it has a few commits on top of that, +describe has added the number of additional commits ("14") and +an abbreviated object name for the commit itself ("2414721") +at the end. + +The number of additional commits is the number +of commits which would be displayed by "git log v1.0.4..parent". +The hash suffix is "-g" + 7-char abbreviation for the tip commit +of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). + +Doing a 'git-describe' on a tag-name will just show the tag name: + + [torvalds@g5 git]$ git describe v1.0.4 + v1.0.4 + +With --all, the command can use branch heads as references, so +the output shows the reference path as well: + + [torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2 + tags/v1.0.0-21-g975b + + [torvalds@g5 git]$ git describe --all --abbrev=4 HEAD^ + heads/lt/describe-7-g975b + +With --abbrev set to 0, the command can be used to find the +closest tagname without any suffix: + + [torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2 + tags/v1.0.0 + +Note that the suffix you get if you type these commands today may be +longer than what Linus saw above when he ran these commands, as your +git repository may have new commits whose object names begin with +975b that did not exist back then, and "-g975b" suffix alone may not +be sufficient to disambiguate these commits. + + +SEARCH STRATEGY +--------------- + +For each committish supplied, 'git-describe' will first look for +a tag which tags exactly that commit. Annotated tags will always +be preferred over lightweight tags, and tags with newer dates will +always be preferred over tags with older dates. If an exact match +is found, its name will be output and searching will stop. + +If an exact match was not found, 'git-describe' will walk back +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. + +If multiple tags were found during the walk then the tag which +has the fewest commits different from the input committish 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. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org>, but somewhat +butchered by Junio C Hamano <gitster@pobox.com>. Later significantly +updated by Shawn Pearce <spearce@spearce.org>. + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-diff-files.txt b/Documentation/git-diff-files.txt new file mode 100644 index 0000000000..4ef03578eb --- /dev/null +++ b/Documentation/git-diff-files.txt @@ -0,0 +1,60 @@ +git-diff-files(1) +================= + +NAME +---- +git-diff-files - Compares files in the working tree and the index + + +SYNOPSIS +-------- +'git diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...] + +DESCRIPTION +----------- +Compares the files in the working tree and the index. When paths +are specified, compares only those named paths. Otherwise all +entries in the index are compared. The output format is the +same as for 'git-diff-index' and 'git-diff-tree'. + +OPTIONS +------- +include::diff-options.txt[] + +-1 --base:: +-2 --ours:: +-3 --theirs:: +-0:: + Diff against the "base" version, "our branch" or "their + branch" respectively. With these options, diffs for + merged entries are not shown. ++ +The default is to diff against our branch (-2) and the +cleanly resolved paths. The option -0 can be given to +omit diff output for unmerged entries and just show "Unmerged". + +-c:: +--cc:: + This compares stage 2 (our branch), stage 3 (their + branch) and the working tree file and outputs a combined + diff, similar to the way 'diff-tree' shows a merge + commit with these flags. + +-q:: + Remain silent even on nonexistent files + + +include::diff-format.txt[] + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt new file mode 100644 index 0000000000..8b9ed29299 --- /dev/null +++ b/Documentation/git-diff-index.txt @@ -0,0 +1,130 @@ +git-diff-index(1) +================= + +NAME +---- +git-diff-index - Compares content and mode of blobs between the index and repository + + +SYNOPSIS +-------- +'git diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...] + +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. + +OPTIONS +------- +include::diff-options.txt[] + +<tree-ish>:: + The id of a tree object to diff against. + +--cached:: + do not consider the on-disk file at all + +-m:: + By default, files recorded in the index but not checked + out are reported as deleted. This flag makes + 'git-diff-index' say that all non-checked-out files are up + to date. + +include::diff-format.txt[] + +Operating Modes +--------------- +You can choose whether you want to trust the index file entirely +(using the '--cached' flag) or ask the diff logic to show any files +that don't match the stat state as being "tentatively changed". Both +of these operations are very useful indeed. + +Cached Mode +----------- +If '--cached' is specified, it allows you to ask: + + show me the differences between HEAD and the current index + contents (the ones I'd write using 'git-write-tree') + +For example, let's say that you have worked on your working directory, updated +some files in the index and are ready to commit. You want to see exactly +*what* you are going to commit, without having to write a new tree +object and compare it that way, and to do that, you just do + + git diff-index --cached HEAD + +Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had +done an `update-index` to make that effective in the index file. +`git diff-files` wouldn't show anything at all, since the index file +matches my working directory. But doing a 'git-diff-index' does: + + torvalds@ppc970:~/git> git diff-index --cached HEAD + -100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c + +100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c + +You can see easily that the above is a rename. + +In fact, `git diff-index --cached` *should* always be entirely equivalent to +actually doing a 'git-write-tree' and comparing that. Except this one is much +nicer for the case where you just want to check where you are. + +So doing a 'git-diff-index --cached' is basically very useful when you are +asking yourself "what have I already marked for being committed, and +what's the difference to a previous tree". + +Non-cached Mode +--------------- +The "non-cached" mode takes a different approach, and is potentially +the more useful of the two in that what it does can't be emulated with +a 'git-write-tree' + 'git-diff-tree'. Thus that's the default mode. +The non-cached version asks the question: + + show me the differences between HEAD and the currently checked out + tree - index contents _and_ files that aren't up-to-date + +which is obviously a very useful question too, since that tells you what +you *could* commit. Again, the output matches the 'git-diff-tree -r' +output to a tee, but with a twist. + +The twist is that if some file doesn't match the index, we don't have +a backing store thing for it, and we use the magic "all-zero" sha1 to +show that. So let's say that you have edited `kernel/sched.c`, but +have not actually done a 'git-update-index' on it yet - there is no +"object" associated with the new state, and you get: + + torvalds@ppc970:~/v2.6/linux> git diff-index HEAD + *100644->100664 blob 7476bb......->000000...... kernel/sched.c + +i.e., it shows that the tree has changed, and that `kernel/sched.c` has is +not up-to-date and may contain new stuff. The all-zero sha1 means that to +get the real diff, you need to look at the object in the working directory +directly rather than do an object-to-object diff. + +NOTE: As with other commands of this type, 'git-diff-index' does not +actually look at the contents of the file at all. So maybe +`kernel/sched.c` hasn't actually changed, and it's just that you +touched it. In either case, it's a note that you need to +'git-update-index' it to make the index be in sync. + +NOTE: You can have a mixture of files show up as "has been updated" +and "is still dirty in the working directory" together. You can always +tell which file is in which state, since the "has been updated" ones +show a valid sha1, and the "not in sync with the index" ones will +always have the special all-zero sha1. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt new file mode 100644 index 0000000000..f2cef1260b --- /dev/null +++ b/Documentation/git-diff-tree.txt @@ -0,0 +1,176 @@ +git-diff-tree(1) +================ + +NAME +---- +git-diff-tree - Compares the content and mode of blobs found via two tree objects + + +SYNOPSIS +-------- +[verse] +'git diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty] + [-t] [-r] [-c | --cc] [--root] [<common diff options>] + <tree-ish> [<tree-ish>] [<path>...] + +DESCRIPTION +----------- +Compares the content and mode of the blobs found via two tree objects. + +If there is only one <tree-ish> given, the commit is compared with its parents +(see --stdin below). + +Note that 'git-diff-tree' can use the tree encapsulated in a commit object. + +OPTIONS +------- +include::diff-options.txt[] + +<tree-ish>:: + The id of a tree object. + +<path>...:: + If provided, the results are limited to a subset of files + matching one of these prefix strings. + i.e., file matches `/^<pattern1>|<pattern2>|.../` + Note that this parameter does not provide any wildcard or regexp + features. + +-r:: + recurse into sub-trees + +-t:: + show tree entry itself as well as subtrees. Implies -r. + +--root:: + When '--root' is specified the initial commit will be shown as a big + creation event. This is equivalent to a diff against the NULL tree. + +--stdin:: + When '--stdin' is specified, the command does not take + <tree-ish> arguments from the command line. Instead, it + reads lines containing either two <tree>, one <commit>, or a + list of <commit> from its standard input. (Use a single space + as separator.) ++ +When two trees are given, it compares the first tree with the second. +When a single commit is given, it compares the commit with its +parents. The remaining commits, when given, are used as if they are +parents of the first commit. ++ +When comparing two trees, the ID of both trees (separated by a space +and terminated by a newline) is printed before the difference. When +comparing commits, the ID of the first (or only) commit, followed by a +newline, is printed. ++ +The following flags further affect the behavior when comparing +commits (but not trees). + +-m:: + By default, 'git-diff-tree --stdin' does not show + differences for merge commits. With this flag, it shows + differences to that commit from all of its parents. See + also '-c'. + +-s:: + By default, 'git-diff-tree --stdin' shows differences, + either in machine-readable form (without '-p') or in patch + form (with '-p'). This output can be suppressed. It is + only useful with '-v' flag. + +-v:: + This flag causes 'git-diff-tree --stdin' to also show + the commit message before the differences. + +include::pretty-options.txt[] + +--no-commit-id:: + 'git-diff-tree' outputs a line with the commit ID when + applicable. This flag suppressed the commit ID output. + +-c:: + This flag changes the way a merge commit is displayed + (which means it is useful only when the command is given + one <tree-ish>, or '--stdin'). It shows the differences + from each of the parents to the merge result simultaneously + instead of showing pairwise diff between a parent and the + result one at a time (which is what the '-m' option does). + Furthermore, it lists only files which were modified + from all parents. + +--cc:: + This flag changes the way a merge commit patch is displayed, + in a similar way to the '-c' option. It implies the '-c' + and '-p' options and further compresses the patch output + by omitting uninteresting hunks whose the contents in the parents + have only two variants and the merge result picks one of them + without modification. When all hunks are uninteresting, the commit + itself and the commit log message is not shown, just like in any other + "empty diff" case. + +--always:: + Show the commit itself and the commit log message even + if the diff itself is empty. + + +include::pretty-formats.txt[] + + +Limiting Output +--------------- +If you're only interested in differences in a subset of files, for +example some architecture-specific files, you might do: + + git diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64 + +and it will only show you what changed in those two directories. + +Or if you are searching for what changed in just `kernel/sched.c`, just do + + git diff-tree -r <tree-ish> <tree-ish> kernel/sched.c + +and it will ignore all differences to other files. + +The pattern is always the prefix, and is matched exactly. There are no +wildcards. Even stricter, it has to match a complete path component. +I.e. "foo" does not pick up `foobar.h`. "foo" does match `foo/bar.h` +so it can be used to name subdirectories. + +An example of normal usage is: + + torvalds@ppc970:~/git> git diff-tree 5319e4...... + *100664->100664 blob ac348b.......->a01513....... git-fsck-objects.c + +which tells you that the last commit changed just one file (it's from +this one: + +----------------------------------------------------------------------------- +commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8 +tree 5319e4d609cdd282069cc4dce33c1db559539b03 +parent b4e628ea30d5ab3606119d2ea5caeab141d38df7 +author Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005 +committer Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005 + +Make "git-fsck-objects" print out all the root commits it finds. + +Once I do the reference tracking, I'll also make it print out all the +HEAD commits it finds, which is even more interesting. +----------------------------------------------------------------------------- + +in case you care). + + +include::diff-format.txt[] + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt new file mode 100644 index 0000000000..0ac711230e --- /dev/null +++ b/Documentation/git-diff.txt @@ -0,0 +1,171 @@ +git-diff(1) +=========== + +NAME +---- +git-diff - Show changes between commits, commit and working tree, etc + + +SYNOPSIS +-------- +'git diff' [<common diff options>] <commit>{0,2} [--] [<path>...] + +DESCRIPTION +----------- +Show changes between two trees, a tree and the working tree, a +tree and the index file, or the index file and the working tree. + +'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 + 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 is untracked, +compare the two files / directories. This behavior can be +forced by --no-index. + +'git diff' [--options] --cached [<commit>] [--] [<path>...]:: + + This form is to view the changes you staged for the next + commit relative to the named <commit>. Typically you + would want comparison with the latest commit, so if you + do not give <commit>, it defaults to HEAD. + --staged is a synonym of --cached. + +'git diff' [--options] <commit> [--] [<path>...]:: + + This form is to view the changes you have in your + working tree relative to the named <commit>. You can + use HEAD to compare it with the latest commit, or a + branch name to compare with the tip of a different + branch. + +'git diff' [--options] <commit> <commit> [--] [<path>...]:: + + This is to view the changes between two arbitrary + <commit>. + +'git diff' [--options] <commit>..<commit> [--] [<path>...]:: + + This is synonymous to the previous form. If <commit> on + one side is omitted, it will have the same effect as + using HEAD instead. + +'git diff' [--options] <commit>\...<commit> [--] [<path>...]:: + + This form is to view the changes on the branch containing + and up to the second <commit>, starting at a common ancestor + of both <commit>. "git diff A\...B" is equivalent to + "git diff $(git-merge-base A B) B". You can omit any one + of <commit>, which has the same effect as using HEAD instead. + +Just in case if you are doing something exotic, it should be +noted that all of the <commit> in the above description, except +for the last two forms that use ".." notations, can be any +<tree-ish>. + +For a more complete list of ways to spell <commit>, see +"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. +However, "diff" is about comparing two _endpoints_, not ranges, +and the range notations ("<commit>..<commit>" and +"<commit>\...<commit>") do not mean a range as defined in the +"SPECIFYING RANGES" section in linkgit:git-rev-parse[1]. + +OPTIONS +------- +:git-diff: 1 +include::diff-options.txt[] + +<path>...:: + The <paths> parameters, when given, are used to limit + the diff to the named paths (you can give directory + names and get diff for all files under them). + + +include::diff-format.txt[] + +EXAMPLES +-------- + +Various ways to check your working tree:: ++ +------------ +$ git diff <1> +$ git diff --cached <2> +$ git diff HEAD <3> +------------ ++ +<1> Changes in the working tree not yet staged for the next commit. +<2> Changes between the index and your last commit; what you +would be committing if you run "git commit" without "-a" option. +<3> Changes in the working tree since your last commit; what you +would be committing if you run "git commit -a" + +Comparing with arbitrary commits:: ++ +------------ +$ git diff test <1> +$ git diff HEAD -- ./test <2> +$ git diff HEAD^ HEAD <3> +------------ ++ +<1> Instead of using the tip of the current branch, compare with the +tip of "test" branch. +<2> Instead of comparing with the tip of "test" branch, compare with +the tip of the current branch, but limit the comparison to the +file "test". +<3> Compare the version before the last commit and the last commit. + +Comparing branches:: ++ +------------ +$ git diff topic master <1> +$ git diff topic..master <2> +$ git diff topic...master <3> +------------ ++ +<1> Changes between the tips of the topic and the master branches. +<2> Same as above. +<3> Changes that occurred on the master branch since when the topic +branch was started off it. + +Limiting the diff output:: ++ +------------ +$ git diff --diff-filter=MRC <1> +$ 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. +<2> Show only names and the nature of change, but not actual +diff output. +<3> Limit diff output to named subtrees. + +Munging the diff output:: ++ +------------ +$ git diff --find-copies-harder -B -C <1> +$ git diff -R <2> +------------ ++ +<1> Spend extra cycles to find renames, copies and complete +rewrites (very expensive). +<2> Output diff in reverse. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt new file mode 100644 index 0000000000..8e9aed67d7 --- /dev/null +++ b/Documentation/git-difftool.txt @@ -0,0 +1,105 @@ +git-difftool(1) +=============== + +NAME +---- +git-difftool - Show changes using common diff tools + +SYNOPSIS +-------- +'git difftool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<'git diff' options>] + +DESCRIPTION +----------- +'git-difftool' is a git command that allows you to compare and edit files +between revisions using common diff tools. 'git difftool' is a frontend +to 'git-diff' and accepts the same options and arguments. + +OPTIONS +------- +-y:: +--no-prompt:: + Do not prompt before launching a diff tool. + +--prompt:: + Prompt before each invocation of the diff tool. + This is the default behaviour; the option is provided to + override any configuration settings. + +-t <tool>:: +--tool=<tool>:: + Use the diff tool specified by <tool>. + Valid merge tools are: + kdiff3, kompare, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, + ecmerge, diffuse, opendiff, p4merge and araxis. ++ +If a diff tool is not specified, 'git-difftool' +will use the configuration variable `diff.tool`. If the +configuration variable `diff.tool` is not set, 'git-difftool' +will pick a suitable default. ++ +You can explicitly provide a full path to the tool by setting the +configuration variable `difftool.<tool>.path`. For example, you +can configure the absolute path to kdiff3 by setting +`difftool.kdiff3.path`. Otherwise, 'git-difftool' assumes the +tool is available in PATH. ++ +Instead of running one of the known diff tools, +'git-difftool' can be customized to run an alternative program +by specifying the command line to invoke in a configuration +variable `difftool.<tool>.cmd`. ++ +When 'git-difftool' is invoked with this tool (either through the +`-t` or `--tool` option or the `diff.tool` configuration variable) +the configured command line will be invoked with the following +variables available: `$LOCAL` is set to the name of the temporary +file containing the contents of the diff pre-image and `$REMOTE` +is set to the name of the temporary file containing the contents +of the diff post-image. `$BASE` is provided for compatibility +with custom merge tool commands and has the same value as `$LOCAL`. + +See linkgit:git-diff[1] for the full list of supported options. + +CONFIG VARIABLES +---------------- +'git-difftool' falls back to 'git-mergetool' config variables when the +difftool equivalents have not been defined. + +diff.tool:: + The default diff tool to use. + +difftool.<tool>.path:: + Override the path for the given tool. This is useful in case + your tool is not in the PATH. + +difftool.<tool>.cmd:: + Specify the command to invoke the specified diff tool. ++ +See the `--tool=<tool>` option above for more details. + +difftool.prompt:: + Prompt before each invocation of the diff tool. + +SEE ALSO +-------- +linkgit:git-diff[1]:: + Show changes between commits, commit and working tree, etc + +linkgit:git-mergetool[1]:: + Run merge conflict resolution tools to resolve merge conflicts + +linkgit:git-config[1]:: + Get and set repository or global options + + +AUTHOR +------ +Written by David Aguilar <davvid@gmail.com>. + +Documentation +-------------- +Documentation by David Aguilar and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt new file mode 100644 index 0000000000..75b06f33e7 --- /dev/null +++ b/Documentation/git-fast-export.txt @@ -0,0 +1,143 @@ +git-fast-export(1) +================== + +NAME +---- +git-fast-export - Git data exporter + + +SYNOPSIS +-------- +'git fast-export [options]' | 'git fast-import' + +DESCRIPTION +----------- +This program dumps the given revisions in a form suitable to be piped +into 'git-fast-import'. + +You can use it as a human-readable bundle replacement (see +linkgit:git-bundle[1]), or as a kind of an interactive +'git-filter-branch'. + + +OPTIONS +------- +--progress=<n>:: + Insert 'progress' statements every <n> objects, to be shown by + 'git-fast-import' during import. + +--signed-tags=(verbatim|warn|strip|abort):: + Specify how to handle signed tags. Since any transformation + after the export can change the tag names (which can also happen + when excluding revisions) the signatures will not match. ++ +When asking to 'abort' (which is the default), this program will die +when encountering a signed tag. With 'strip', the tags will be made +unsigned, with 'verbatim', they will be silently exported +and with 'warn', they will be exported, but you will see a warning. + +--tag-of-filtered-object=(abort|drop|rewrite):: + Specify how to handle tags whose tagged objectis filtered out. + Since revisions and files to export can be limited by path, + tagged objects may be filtered completely. ++ +When asking to 'abort' (which is the default), this program will die +when encountering such a tag. With 'drop' it will omit such tags from +the output. With 'rewrite', if the tagged object is a commit, it will +rewrite the tag to tag an ancestor commit (via parent rewriting; see +linkgit:git-rev-list[1]) + +-M:: +-C:: + Perform move and/or copy detection, as described in the + linkgit:git-diff[1] manual page, and use it to generate + rename and copy commands in the output dump. ++ +Note that earlier versions of this command did not complain and +produced incorrect results if you gave these options. + +--export-marks=<file>:: + Dumps the internal marks table to <file> when complete. + Marks are written one per line as `:markid SHA-1`. Only marks + for revisions are dumped; marks for blobs are ignored. + Backends can use this file to validate imports after they + have been completed, or to save the marks table across + incremental runs. As <file> is only opened and truncated + at completion, the same path can also be safely given to + \--import-marks. + +--import-marks=<file>:: + Before processing any input, load the marks specified in + <file>. The input file must exist, must be readable, and + must use the same format as produced by \--export-marks. ++ +Any commits that have already been marked will not be exported again. +If the backend uses a similar \--import-marks file, this allows for +incremental bidirectional exporting of the repository by keeping the +marks the same across runs. + +--fake-missing-tagger:: + Some old repositories have tags without a tagger. The + fast-import protocol was pretty strict about that, and did not + allow that. So fake a tagger to be able to fast-import the + output. + +--no-data:: + Skip output of blob objects and instead refer to blobs via + their original SHA-1 hash. This is useful when rewriting the + directory structure or history of a repository without + touching the contents of individual files. Note that the + resulting stream can only be used by a repository which + already contains the necessary objects. + +[git-rev-list-args...]:: + A list of arguments, acceptable to 'git-rev-parse' and + 'git-rev-list', that specifies the specific objects and references + to export. For example, `master\~10..master` causes the + current master reference to be exported along with all objects + added since its 10th ancestor commit. + +EXAMPLES +-------- + +------------------------------------------------------------------- +$ git fast-export --all | (cd /empty/repository && git fast-import) +------------------------------------------------------------------- + +This will export the whole repository and import it into the existing +empty repository. Except for reencoding commits that are not in +UTF-8, it would be a one-to-one mirror. + +----------------------------------------------------- +$ git fast-export master~5..master | + sed "s|refs/heads/master|refs/heads/other|" | + git fast-import +----------------------------------------------------- + +This makes a new branch called 'other' from 'master~5..master' +(i.e. if 'master' has linear history, it will take the last 5 commits). + +Note that this assumes that none of the blobs and commit messages +referenced by that revision range contains the string +'refs/heads/master'. + + +Limitations +----------- + +Since 'git-fast-import' cannot tag trees, you will not be +able to export the linux-2.6.git repository completely, as it contains +a tag referencing a tree instead of a commit. + + +Author +------ +Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>. + +Documentation +-------------- +Documentation by Johannes E. Schindelin <johannes.schindelin@gmx.de>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt new file mode 100644 index 0000000000..288032c7b8 --- /dev/null +++ b/Documentation/git-fast-import.txt @@ -0,0 +1,1158 @@ +git-fast-import(1) +================== + +NAME +---- +git-fast-import - Backend for fast Git data importers + + +SYNOPSIS +-------- +frontend | 'git fast-import' [options] + +DESCRIPTION +----------- +This program is usually not what the end user wants to run directly. +Most end users want to use one of the existing frontend programs, +which parses a specific type of foreign source and feeds the contents +stored there to 'git-fast-import'. + +fast-import reads a mixed command/data stream from standard input and +writes one or more packfiles directly into the current repository. +When EOF is received on standard input, fast import writes out +updated branch and tag refs, fully updating the current repository +with the newly imported data. + +The fast-import backend itself can import into an empty repository (one that +has already been initialized by 'git-init') or incrementally +update an existing populated repository. Whether or not incremental +imports are supported from a particular foreign source depends on +the frontend program in use. + + +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, expressed in MiB. + The default is 4096 (4 GiB) as that is the maximum allowed + packfile size (due to file format limitations). Some + importers may wish to lower this, such as to ensure the + resulting packfiles fit on CDs. + +--depth=<n>:: + Maximum delta depth, for blob and tree deltification. + Default is 10. + +--active-branches=<n>:: + Maximum number of branches to maintain active at once. + See ``Memory Utilization'' below for details. Default is 5. + +--export-marks=<file>:: + Dumps the internal marks table to <file> when complete. + Marks are written one per line as `:markid SHA-1`. + Frontends can use this file to validate imports after they + have been completed, or to save the marks table across + incremental runs. As <file> is only opened and truncated + at checkpoint (or completion) the same path can also be + safely given to \--import-marks. + +--import-marks=<file>:: + Before processing any input, load the marks specified in + <file>. The input file must exist, must be readable, and + must use the same format as produced by \--export-marks. + Multiple options may be supplied to import more than one + set of marks. If a mark is defined to different values, + the last file wins. + +--export-pack-edges=<file>:: + After creating a packfile, print a line of data to + <file> listing the filename of the packfile and the last + commit on each branch that was written to that packfile. + This information may be useful after importing projects + whose total object set exceeds the 4 GiB packfile limit, + as these commits can be used as edge points during calls + to '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. + + +Performance +----------- +The design of fast-import allows it to import large projects in a minimum +amount of memory usage and processing time. Assuming the frontend +is able to keep up with fast-import and feed it a constant stream of data, +import times for projects holding 10+ years of history and containing +100,000+ individual commits are generally completed in just 1-2 +hours on quite modest (~$2,000 USD) hardware. + +Most bottlenecks appear to be in foreign source data access (the +source just cannot extract revisions fast enough) or disk IO (fast-import +writes as fast as the disk will take the data). Imports will run +faster if the source data is stored on a different drive than the +destination Git repository (due to less IO contention). + + +Development Cost +---------------- +A typical frontend for fast-import tends to weigh in at approximately 200 +lines of Perl/Python/Ruby code. Most developers have been able to +create working importers in just a couple of hours, even though it +is their first exposure to fast-import, and sometimes even to Git. This is +an ideal situation, given that most conversion tools are throw-away +(use once, and never look back). + + +Parallel Operation +------------------ +Like 'git-push' or 'git-fetch', imports handled by fast-import are safe to +run alongside parallel `git repack -a -d` or `git gc` invocations, +or any other Git operation (including 'git-prune', as loose objects +are never used by fast-import). + +fast-import does not lock the branch or tag refs it is actively importing. +After the import, during its ref update phase, fast-import tests each +existing branch ref to verify the update will be a fast-forward +update (the commit stored in the ref is contained in the new +history of the commit to be written). If the update is not a +fast-forward update, fast-import will skip updating that ref and instead +prints a warning message. fast-import will always attempt to update all +branch refs, and does not stop on the first failure. + +Branch updates can be forced with \--force, but its recommended that +this only be used on an otherwise quiet repository. Using \--force +is not necessary for an initial import into an empty repository. + + +Technical Discussion +-------------------- +fast-import tracks a set of branches in memory. Any branch can be created +or modified at any point during the import process by sending a +`commit` command on the input stream. This design allows a frontend +program to process an unlimited number of branches simultaneously, +generating commits in the order they are available from the source +data. It also simplifies the frontend programs considerably. + +fast-import does not use or alter the current working directory, or any +file within it. (It does however update the current Git repository, +as referenced by `GIT_DIR`.) Therefore an import frontend may use +the working directory for its own purposes, such as extracting file +revisions from the foreign source. This ignorance of the working +directory also allows fast-import to run very quickly, as it does not +need to perform any costly file update operations when switching +between branches. + +Input Format +------------ +With the exception of raw file data (which Git does not interpret) +the fast-import input format is text (ASCII) based. This text based +format simplifies development and debugging of frontend programs, +especially when a higher level language such as Perl, Python or +Ruby is being used. + +fast-import is very strict about its input. Where we say SP below we mean +*exactly* one space. Likewise LF means one (and only one) linefeed. +Supplying additional whitespace characters will cause unexpected +results, such as branch names or file names with leading or trailing +spaces in their name, or early termination of fast-import when it encounters +unexpected input. + +Stream Comments +~~~~~~~~~~~~~~~ +To aid in debugging frontends fast-import ignores any line that +begins with `#` (ASCII pound/hash) up to and including the line +ending `LF`. A comment line may contain any sequence of bytes +that does not contain an LF and therefore may be used to include +any detailed debugging information that might be specific to the +frontend and useful when inspecting a fast-import data stream. + +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. + +`raw`:: + This is the Git native format and is `<time> SP <offutc>`. + It is also fast-import's default format, if \--date-format was + not specified. ++ +The time of the event is specified by `<time>` as the number of +seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is +written as an ASCII decimal integer. ++ +The local offset is specified by `<offutc>` as a positive or negative +offset from UTC. For example EST (which is 5 hours behind UTC) +would be expressed in `<tz>` by ``-0500'' while UTC is ``+0000''. +The local offset does not affect `<time>`; it is used only as an +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 +case a reasonable offset from UTC could be assumed. ++ +Unlike the `rfc2822` format, this format is very strict. Any +variation in formatting will cause fast-import to reject the value. + +`rfc2822`:: + This is the standard email format as described by RFC 2822. ++ +An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git +parser is accurate, but a little on the lenient side. It is the +same parser used by 'git-am' when applying patches +received from email. ++ +Some malformed strings may be accepted as valid dates. In some of +these cases Git will still be able to obtain the correct date from +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 +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. ++ +If the source material uses RFC 2822 style dates, +the frontend should let fast-import handle the parsing and conversion +(rather than attempting to do it itself) as the Git parser has +been well tested in the wild. ++ +Frontends should prefer the `raw` format if the source material +already uses UNIX-epoch format, can be coaxed to give dates in that +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 + `now` must always be supplied for `<when>`. ++ +This is a toy format. The current time and timezone 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. ++ +This particular format is supplied as its short to implement and +may be useful to a process that wants to create a new commit +right now, without needing to use a working directory or +'git-update-index'. ++ +If separate `author` and `committer` commands are used in a `commit` +the timestamps may not match, as the system clock will be polled +twice (once for each command). The only way to ensure that both +author and committer identity information has the same timestamp +is to omit `author` (thus copying from `committer`) or to use a +date format other than `now`. + +Commands +~~~~~~~~ +fast-import accepts several commands to update the current repository +and control the current import process. More detailed discussion +(with examples) of each command follows later. + +`commit`:: + Creates a new branch or updates an existing branch by + creating a new commit and updating the branch to point at + the newly created commit. + +`tag`:: + Creates an annotated tag object from an existing commit or + branch. Lightweight tags are not supported by this command, + as they are not recommended for recording meaningful points + in time. + +`reset`:: + Reset an existing branch (or a new branch) to a specific + revision. This command must be used to change a branch to + a specific revision without making a commit on it. + +`blob`:: + Convert raw file data into a blob, for future use in a + `commit` command. This command is optional and is not + needed to perform an import. + +`checkpoint`:: + Forces fast-import to close the current packfile, generate its + unique SHA-1 checksum and index, and start a new packfile. + This command is optional and is not needed to perform + an import. + +`progress`:: + Causes fast-import to echo the entire line to its own + standard output. This command is optional and is not needed + to perform an import. + +`commit` +~~~~~~~~ +Create or update a branch with a new commit, recording one logical +change to the project. + +.... + 'commit' SP <ref> LF + mark? + ('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)? + (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)* + LF? +.... + +where `<ref>` is the name of the branch to make the commit on. +Typically branch names are prefixed with `refs/heads/` in +Git, so importing the CVS branch symbol `RELENG-1_0` would use +`refs/heads/RELENG-1_0` for the value of `<ref>`. The value of +`<ref>` must be a valid refname in Git. As `LF` is not valid in +a Git refname, no quoting or escaping syntax is supported here. + +A `mark` command may optionally appear, requesting fast-import to save a +reference to the newly created commit for future use by the frontend +(see below for format). It is very common for frontends to mark +every commit they create, thereby allowing future branch creation +from any imported commit. + +The `data` command following `committer` must supply the commit +message (see below for `data` command syntax). To import an empty +commit message use a 0 length data. Commit messages are free-form +and are not interpreted by Git. Currently they must be encoded in +UTF-8, as fast-import does not permit other encodings to be specified. + +Zero or more `filemodify`, `filedelete`, `filecopy`, `filerename`, +`filedeleteall` and `notemodify` commands +may be included to update the contents of the branch prior to +creating the commit. These commands may be supplied in any order. +However it is recommended that a `filedeleteall` command precede +all `filemodify`, `filecopy`, `filerename` and `notemodify` commands in +the same commit, as `filedeleteall` wipes the branch clean (see below). + +The `LF` after the command is optional (it used to be required). + +`author` +^^^^^^^^ +An `author` command may optionally appear, if the author information +might differ from the committer information. If `author` is omitted +then fast-import will automatically use the committer's information for +the author portion of the commit. See below for a description of +the fields in `author`, as they are identical to `committer`. + +`committer` +^^^^^^^^^^^ +The `committer` command indicates who made this commit, and when +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) +and greater-than (\x3e) symbols. These are required to delimit +the email address from the other fields in the line. Note that +`<name>` is free-form and may contain any sequence of bytes, except +`LT` and `LF`. It is typically UTF-8 encoded. + +The time of the change is specified by `<when>` using the date format +that was selected by the \--date-format=<fmt> command line option. +See ``Date Formats'' above for the set of supported formats, and +their syntax. + +`from` +^^^^^^ +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. + +Omitting the `from` command in the first commit of a new branch +will cause fast-import to create that commit with no ancestor. This +tends to be desired only for the initial commit of a project. +If the frontend creates all files from scratch when making a new +branch, a `merge` command may be used instead of `from` to start +the commit with an empty tree. +Omitting the `from` command on existing branches is usually desired, +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>`. + +Here `<committish>` 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, its treated as a SHA-1 + expression. + +* A mark reference, `:<idnum>`, where `<idnum>` is the mark number. ++ +The reason fast-import uses `:` to denote a mark reference is this character +is not legal in a Git branch name. The leading `:` makes it easy +to distinguish between the mark 42 (`:42`) and the branch 42 (`42` +or `refs/heads/42`), or an abbreviated SHA-1 which happened to +consist only of base-10 digits. ++ +Marks must be declared (via `mark`) before they can be used. + +* A complete 40 byte or abbreviated commit SHA-1 in hex. + +* Any valid Git SHA-1 expression that resolves to a commit. See + ``SPECIFYING REVISIONS'' in linkgit:git-rev-parse[1] for details. + +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 +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 +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 +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 +also accepted by `from` (see above). + +`filemodify` +^^^^^^^^^^^^ +Included in a `commit` command to add a new file or change the +content of an existing file. This command has two different means +of specifying the content of the file. + +External data format:: + The data content for the file was already supplied by a prior + `blob` command. The frontend just needs to connect it. ++ +.... + 'M' SP <mode> SP <dataref> SP <path> LF +.... ++ +Here `<dataref>` can be either a mark reference (`:<idnum>`) +set by a prior `blob` command, or a full 40-byte SHA-1 of an +existing Git blob object. + +Inline data format:: + The data content for the file has not been supplied yet. + The frontend wants to supply it as part of this modify + command. ++ +.... + 'M' SP <mode> SP 'inline' SP <path> LF + data +.... ++ +See below for a detailed description of the `data` command. + +In both formats `<mode>` is the type of file entry, specified +in octal. Git only supports the following modes: + +* `100644` or `644`: A normal (not-executable) file. The majority + of files in most projects use this mode. If in doubt, this is + what you want. +* `100755` or `755`: A normal, but executable, file. +* `120000`: A symlink, the content of the file will be the link target. +* `160000`: A gitlink, SHA-1 of the object refers to a commit in + another repository. Git links can only be specified by SHA or through + a commit mark. They are used to implement submodules. + +In both formats `<path>` is the complete path of the file to be added +(if not already existing) or modified (if already existing). + +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"`. + +The value of `<path>` must be in canonical form. That is it must not: + +* contain an empty directory component (e.g. `foo//bar` is invalid), +* end with a directory separator (e.g. `foo/` is invalid), +* start with a directory separator (e.g. `/foo` is invalid), +* contain the special component `.` or `..` (e.g. `foo/./bar` and + `foo/../bar` are invalid). + +It is recommended that `<path>` always be encoded using UTF-8. + +`filedelete` +^^^^^^^^^^^^ +Included in a `commit` command to remove a file or recursively +delete an entire directory from the branch. If the file or directory +removal makes its parent directory empty, the parent directory will +be automatically removed too. This cascades up the tree until the +first non-empty directory or the root is reached. + +.... + 'D' SP <path> LF +.... + +here `<path>` is the complete path of the file or subdirectory to +be removed from the branch. +See `filemodify` above for a detailed description of `<path>`. + +`filecopy` +^^^^^^^^^^^^ +Recursively copies an existing file or subdirectory to a different +location within the branch. The existing file or directory must +exist. If the destination exists it will be completely replaced +by the content copied from the source. + +.... + 'C' SP <path> SP <path> LF +.... + +here the first `<path>` is the source location and the second +`<path>` is the destination. See `filemodify` above for a detailed +description of what `<path>` may look like. To use a source path +that contains SP the path must be quoted. + +A `filecopy` command takes effect immediately. Once the source +location has been copied to the destination any future commands +applied to the source location will not impact the destination of +the copy. + +`filerename` +^^^^^^^^^^^^ +Renames an existing file or subdirectory to a different location +within the branch. The existing file or directory must exist. If +the destination exists it will be replaced by the source directory. + +.... + 'R' SP <path> SP <path> LF +.... + +here the first `<path>` is the source location and the second +`<path>` is the destination. See `filemodify` above for a detailed +description of what `<path>` may look like. To use a source path +that contains SP the path must be quoted. + +A `filerename` command takes effect immediately. Once the source +location has been renamed to the destination any future commands +applied to the source location will create new files there and not +impact the destination of the rename. + +Note that a `filerename` is the same as a `filecopy` followed by a +`filedelete` of the source location. There is a slight performance +advantage to using `filerename`, but the advantage is so small +that it is never worth trying to convert a delete/add pair in +source material into a rename for fast-import. This `filerename` +command is provided just to simplify frontends that already have +rename information and don't want bother with decomposing it into a +`filecopy` followed by a `filedelete`. + +`filedeleteall` +^^^^^^^^^^^^^^^ +Included in a `commit` command to remove all files (and also all +directories) from the branch. This command resets the internal +branch structure to have no files in it, allowing the frontend +to subsequently add all interesting files from scratch. + +.... + 'deleteall' LF +.... + +This command is extremely useful if the frontend does not know +(or does not care to know) what files are currently on the branch, +and therefore cannot generate the proper `filedelete` commands to +update the content. + +Issuing a `filedeleteall` followed by the needed `filemodify` +commands to set the correct content will produce the same results +as sending only the needed `filemodify` and `filedelete` commands. +The `filedeleteall` approach may however require fast-import to use slightly +more memory per active branch (less than 1 MiB for even most large +projects); so frontends that can easily obtain only the affected +paths for a commit are encouraged to do so. + +`notemodify` +^^^^^^^^^^^^ +Included in a `commit` command to add a new note (annotating a given +commit) or change the content of an existing note. This command has +two different means of specifying the content of the note. + +External data format:: + The data content for the note was already supplied by a prior + `blob` command. The frontend just needs to connect it to the + commit that is to be annotated. ++ +.... + 'N' SP <dataref> SP <committish> LF +.... ++ +Here `<dataref>` can be either a mark reference (`:<idnum>`) +set by a prior `blob` command, or a full 40-byte SHA-1 of an +existing Git blob object. + +Inline data format:: + The data content for the note has not been supplied yet. + The frontend wants to supply it as part of this modify + command. ++ +.... + 'N' SP 'inline' SP <committish> LF + data +.... ++ +See below for a detailed description of the `data` command. + +In both formats `<committish>` is any of the commit specification +expressions also accepted by `from` (see above). + +`mark` +~~~~~~ +Arranges for fast-import to save a reference to the current object, allowing +the frontend to recall this object at a future point in time, without +knowing its SHA-1. Here the current object is the object creation +command the `mark` command appears within. This can be `commit`, +`tag`, and `blob`, but `commit` is the most common usage. + +.... + 'mark' SP ':' <idnum> LF +.... + +where `<idnum>` is the number assigned by the frontend to this mark. +The value of `<idnum>` is expressed as an ASCII decimal integer. +The value 0 is reserved and cannot be used as +a mark. Only values greater than or equal to 1 may be used as marks. + +New marks are created automatically. Existing marks can be moved +to another object simply by reusing the same `<idnum>` in another +`mark` command. + +`tag` +~~~~~ +Creates an annotated tag referring to a specific commit. To create +lightweight (non-annotated) tags see the `reset` command below. + +.... + 'tag' SP <name> LF + 'from' SP <committish> LF + 'tagger' SP <name> SP LT <email> GT SP <when> LF + data +.... + +where `<name>` is the name of the tag to create. + +Tag names are automatically prefixed with `refs/tags/` when stored +in Git, so importing the CVS branch symbol `RELENG-1_0-FINAL` would +use just `RELENG-1_0-FINAL` for `<name>`, and fast-import will write the +corresponding ref as `refs/tags/RELENG-1_0-FINAL`. + +The value of `<name>` must be a valid refname in Git and therefore +may contain forward slashes. As `LF` is not valid in a Git refname, +no quoting or escaping syntax is supported here. + +The `from` command is the same as in the `commit` command; see +above for details. + +The `tagger` command uses the same format as `committer` within +`commit`; again see above for details. + +The `data` command following `tagger` must supply the annotated tag +message (see below for `data` command syntax). To import an empty +tag message use a 0 length data. Tag messages are free-form and are +not interpreted by Git. Currently they must be encoded in UTF-8, +as fast-import does not permit other encodings to be specified. + +Signing annotated tags during import from within fast-import is not +supported. Trying to include your own PGP/GPG signature is not +recommended, as the frontend does not (easily) have access to the +complete set of bytes which normally goes into such a signature. +If signing is required, create lightweight tags from within fast-import with +`reset`, then create the annotated versions of those tags offline +with the standard 'git-tag' process. + +`reset` +~~~~~~~ +Creates (or recreates) the named branch, optionally starting from +a specific revision. The reset command allows a frontend to issue +a new `from` command for an existing branch, or to create a new +branch from an existing commit without creating a new commit. + +.... + 'reset' SP <ref> LF + ('from' SP <committish> LF)? + LF? +.... + +For a detailed description of `<ref>` and `<committish>` see above +under `commit` and `from`. + +The `LF` after the command is optional (it used to be required). + +The `reset` command can also be used to create lightweight +(non-annotated) tags. For example: + +==== + reset refs/tags/938 + from :938 +==== + +would create the lightweight tag `refs/tags/938` referring to +whatever commit mark `:938` references. + +`blob` +~~~~~~ +Requests writing one file revision to the packfile. The revision +is not connected to any commit; this connection must be formed in +a subsequent `commit` command by referencing the blob through an +assigned mark. + +.... + 'blob' LF + mark? + data +.... + +The mark command is optional here as some frontends have chosen +to generate the Git SHA-1 for the blob on their own, and feed that +directly to `commit`. This is typically more work than its worth +however, as marks are inexpensive to store and easy to use. + +`data` +~~~~~~ +Supplies raw data (for use as blob/file content, commit messages, or +annotated tag messages) to fast-import. Data can be supplied using an exact +byte count or delimited with a terminating line. Real frontends +intended for production-quality conversions should always use the +exact byte count format, as it is more robust and performs better. +The delimited format is intended primarily for testing fast-import. + +Comment lines appearing within the `<raw>` part of `data` commands +are always taken to be part of the body of the data and are therefore +never ignored by fast-import. This makes it safe to import any +file/message content whose lines might start with `#`. + +Exact byte count format:: + The frontend must specify the number of bytes of data. ++ +.... + 'data' SP <count> LF + <raw> LF? +.... ++ +where `<count>` is the exact number of bytes appearing within +`<raw>`. The value of `<count>` is expressed as an ASCII decimal +integer. The `LF` on either side of `<raw>` is not +included in `<count>` and will not be included in the imported data. ++ +The `LF` after `<raw>` is optional (it used to be required) but +recommended. Always including it makes debugging a fast-import +stream easier as the next command always starts in column 0 +of the next line, even if `<raw>` did not end with an `LF`. + +Delimited format:: + A delimiter string is used to mark the end of the data. + fast-import will compute the length by searching for the delimiter. + This format is primarily useful for testing and is not + recommended for real data. ++ +.... + 'data' SP '<<' <delim> LF + <raw> LF + <delim> LF + LF? +.... ++ +where `<delim>` is the chosen delimiter string. The string `<delim>` +must not appear on a line by itself within `<raw>`, as otherwise +fast-import will think the data ends earlier than it really does. The `LF` +immediately trailing `<raw>` is part of `<raw>`. This is one of +the limitations of the delimited format, it is impossible to supply +a data chunk which does not have an LF as its last byte. ++ +The `LF` after `<delim> LF` is optional (it used to be required). + +`checkpoint` +~~~~~~~~~~~~ +Forces fast-import to close the current packfile, start a new one, and to +save out all current branch refs, tags and marks. + +.... + 'checkpoint' LF + LF? +.... + +Note that fast-import automatically switches packfiles when the current +packfile reaches \--max-pack-size, or 4 GiB, whichever limit is +smaller. During an automatic packfile switch fast-import does not update +the branch refs, tags or marks. + +As a `checkpoint` can require a significant amount of CPU time and +disk IO (to compute the overall pack SHA-1 checksum, generate the +corresponding index file, and update the refs) it can easily take +several minutes for a single `checkpoint` command to complete. + +Frontends may choose to issue checkpoints during extremely large +and long running imports, or when they need to allow another Git +process access to a branch. However given that a 30 GiB Subversion +repository can be loaded into Git through fast-import in about 3 hours, +explicit checkpointing may not be necessary. + +The `LF` after the command is optional (it used to be required). + +`progress` +~~~~~~~~~~ +Causes fast-import to print the entire `progress` line unmodified to +its standard output channel (file descriptor 1) when the command is +processed from the input stream. The command otherwise has no impact +on the current import, or on any of fast-import's internal state. + +.... + 'progress' SP <any> LF + LF? +.... + +The `<any>` part of the command may contain any sequence of bytes +that does not contain `LF`. The `LF` after the command is optional. +Callers may wish to process the output through a tool such as sed to +remove the leading part of the line, for example: + +==== + frontend | git fast-import | sed 's/^progress //' +==== + +Placing a `progress` command immediately after a `checkpoint` will +inform the reader when the `checkpoint` has been completed and it +can safely access the refs that fast-import updated. + +Crash Reports +------------- +If fast-import is supplied invalid input it will terminate with a +non-zero exit status and create a crash report in the top level of +the Git repository it was importing into. Crash reports contain +a snapshot of the internal fast-import state as well as the most +recent commands that lead up to the crash. + +All recent commands (including stream comments, file changes and +progress commands) are shown in the command history within the crash +report, but raw file data and commit messages are excluded from the +crash report. This exclusion saves space within the report file +and reduces the amount of buffering that fast-import must perform +during execution. + +After writing a crash report fast-import will close the current +packfile and export the marks table. This allows the frontend +developer to inspect the repository state and resume the import from +the point where it crashed. The modified branches and tags are not +updated during a crash, as the import did not complete successfully. +Branch and tag information can be found in the crash report and +must be applied manually if the update is needed. + +An example crash: + +==== + $ cat >in <<END_OF_INPUT + # my very first test commit + commit refs/heads/master + committer Shawn O. Pearce <spearce> 19283 -0400 + # who is that guy anyway? + data <<EOF + this is my commit + EOF + M 644 inline .gitignore + data <<EOF + .gitignore + EOF + M 777 inline bob + END_OF_INPUT + + $ git fast-import <in + fatal: Corrupt mode: M 777 inline bob + fast-import: dumping crash report to .git/fast_import_crash_8434 + + $ cat .git/fast_import_crash_8434 + fast-import crash report: + fast-import process: 8434 + parent process : 1391 + at Sat Sep 1 00:58:12 2007 + + fatal: Corrupt mode: M 777 inline bob + + Most Recent Commands Before Crash + --------------------------------- + # my very first test commit + commit refs/heads/master + committer Shawn O. Pearce <spearce> 19283 -0400 + # who is that guy anyway? + data <<EOF + M 644 inline .gitignore + data <<EOF + * M 777 inline bob + + Active Branch LRU + ----------------- + active_branches = 1 cur, 5 max + + pos clock name + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 1) 0 refs/heads/master + + Inactive Branches + ----------------- + refs/heads/master: + status : active loaded dirty + tip commit : 0000000000000000000000000000000000000000 + old tree : 0000000000000000000000000000000000000000 + cur tree : 0000000000000000000000000000000000000000 + commit clock: 0 + last pack : + + + ------------------- + END OF CRASH REPORT +==== + +Tips and Tricks +--------------- +The following tips and tricks have been collected from various +users of fast-import, and are offered here as suggestions. + +Use One Mark Per Commit +~~~~~~~~~~~~~~~~~~~~~~~ +When doing a repository conversion, use a unique mark per commit +(`mark :<n>`) and supply the \--export-marks option on the command +line. fast-import will dump a file which lists every mark and the Git +object SHA-1 that corresponds to it. If the frontend can tie +the marks back to the source repository, it is easy to verify the +accuracy and completeness of the import by comparing each Git +commit to the corresponding source revision. + +Coming from a system such as Perforce or Subversion this should be +quite simple, as the fast-import mark can also be the Perforce changeset +number or the Subversion revision number. + +Freely Skip Around Branches +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Don't bother trying to optimize the frontend to stick to one branch +at a time during an import. Although doing so might be slightly +faster for fast-import, it tends to increase the complexity of the frontend +code considerably. + +The branch LRU builtin to fast-import tends to behave very well, and the +cost of activating an inactive branch is so low that bouncing around +between branches has virtually no impact on import performance. + +Handling Renames +~~~~~~~~~~~~~~~~ +When importing a renamed file or directory, simply delete the old +name(s) and modify the new name(s) during the corresponding commit. +Git performs rename detection after-the-fact, rather than explicitly +during a commit. + +Use Tag Fixup Branches +~~~~~~~~~~~~~~~~~~~~~~ +Some other SCM systems let the user create a tag from multiple +files which are not from the same commit/changeset. Or to create +tags which are a subset of the files available in the repository. + +Importing these tags as-is in Git is impossible without making at +least one commit which ``fixes up'' the files to match the content +of the tag. Use fast-import's `reset` command to reset a dummy branch +outside of your normal branch space to the base commit for the tag, +then commit one or more file fixup commits, and finally tag the +dummy branch. + +For example since all normal branches are stored under `refs/heads/` +name the tag fixup branch `TAG_FIXUP`. This way it is impossible for +the fixup branch used by the importer to have namespace conflicts +with real branches imported from the source (the name `TAG_FIXUP` +is not `refs/heads/TAG_FIXUP`). + +When committing fixups, consider using `merge` to connect the +commit(s) which are supplying file revisions to the fixup branch. +Doing so will allow tools such as 'git-blame' to track +through the real commit history and properly annotate the source +files. + +After fast-import terminates the frontend will need to do `rm .git/TAG_FIXUP` +to remove the dummy branch. + +Import Now, Repack Later +~~~~~~~~~~~~~~~~~~~~~~~~ +As soon as fast-import completes the Git repository is completely valid +and ready for use. Typically this takes only a very short time, +even for considerably large projects (100,000+ commits). + +However repacking the repository is necessary to improve data +locality and access performance. It can also take hours on extremely +large projects (especially if -f and a large \--window parameter is +used). Since repacking is safe to run alongside readers and writers, +run the repack in the background and let it finish when it finishes. +There is no reason to wait to explore your new Git project! + +If you choose to wait for the repack, don't try to run benchmarks +or performance tests until repacking is completed. fast-import outputs +suboptimal packfiles that are simply never seen in real use +situations. + +Repacking Historical Data +~~~~~~~~~~~~~~~~~~~~~~~~~ +If you are repacking very old imported data (e.g. older than the +last year), consider expending some extra CPU time and supplying +\--window=50 (or higher) when you run 'git-repack'. +This will take longer, but will also produce a smaller packfile. +You only need to expend the effort once, and everyone using your +project will benefit from the smaller repository. + +Include Some Progress Messages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Every once in a while have your frontend emit a `progress` message +to fast-import. The contents of the messages are entirely free-form, +so one suggestion would be to output the current month and year +each time the current commit date moves into the next month. +Your users will feel better knowing how much of the data stream +has been processed. + + +Packfile Optimization +--------------------- +When packing a blob fast-import always attempts to deltify against the last +blob written. Unless specifically arranged for by the frontend, +this will probably not be a prior version of the same file, so the +generated delta will not be the smallest possible. The resulting +packfile will be compressed, but will not be optimal. + +Frontends which have efficient access to all revisions of a +single file (for example reading an RCS/CVS ,v file) can choose +to supply all revisions of that file as a sequence of consecutive +`blob` commands. This allows fast-import to deltify the different file +revisions against each other, saving space in the final packfile. +Marks can be used to later identify individual file revisions during +a sequence of `commit` commands. + +The packfile(s) created by fast-import do not encourage good disk access +patterns. This is caused by fast-import writing the data in the order +it is received on standard input, while Git typically organizes +data within packfiles to make the most recent (current tip) data +appear before historical data. Git also clusters commits together, +speeding up revision traversal through better cache locality. + +For this reason it is strongly recommended that users repack the +repository with `git repack -a -d` after fast-import completes, allowing +Git to reorganize the packfiles for faster data access. If blob +deltas are suboptimal (see above) then also adding the `-f` option +to force recomputation of all deltas can significantly reduce the +final packfile size (30-50% smaller can be quite typical). + + +Memory Utilization +------------------ +There are a number of factors which affect how much memory fast-import +requires to perform an import. Like critical sections of core +Git, fast-import uses its own memory allocators to amortize any overheads +associated with malloc. In practice fast-import tends to amortize any +malloc overheads to 0, due to its use of large block allocations. + +per object +~~~~~~~~~~ +fast-import maintains an in-memory structure for every object written in +this execution. On a 32 bit system the structure is 32 bytes, +on a 64 bit system the structure is 40 bytes (due to the larger +pointer sizes). Objects in the table are not deallocated until +fast-import terminates. Importing 2 million objects on a 32 bit system +will require approximately 64 MiB of memory. + +The object table is actually a hashtable keyed on the object name +(the unique SHA-1). This storage configuration allows fast-import to reuse +an existing or already written object and avoid writing duplicates +to the output packfile. Duplicate blobs are surprisingly common +in an import, typically due to branch merges in the source. + +per mark +~~~~~~~~ +Marks are stored in a sparse array, using 1 pointer (4 bytes or 8 +bytes, depending on pointer size) per mark. Although the array +is sparse, frontends are still strongly encouraged to use marks +between 1 and n, where n is the total number of marks required for +this import. + +per branch +~~~~~~~~~~ +Branches are classified as active and inactive. The memory usage +of the two classes is significantly different. + +Inactive branches are stored in a structure which uses 96 or 120 +bytes (32 bit or 64 bit systems, respectively), plus the length of +the branch name (typically under 200 bytes), per branch. fast-import will +easily handle as many as 10,000 inactive branches in under 2 MiB +of memory. + +Active branches have the same overhead as inactive branches, but +also contain copies of every tree that has been recently modified on +that branch. If subtree `include` has not been modified since the +branch became active, its contents will not be loaded into memory, +but if subtree `src` has been modified by a commit since the branch +became active, then its contents will be loaded in memory. + +As active branches store metadata about the files contained on that +branch, their in-memory storage size can grow to a considerable size +(see below). + +fast-import automatically moves active branches to inactive status based on +a simple least-recently-used algorithm. The LRU chain is updated on +each `commit` command. The maximum number of active branches can be +increased or decreased on the command line with \--active-branches=. + +per active tree +~~~~~~~~~~~~~~~ +Trees (aka directories) use just 12 bytes of memory on top of the +memory required for their entries (see ``per active file'' below). +The cost of a tree is virtually 0, as its overhead amortizes out +over the individual file entries. + +per active file entry +~~~~~~~~~~~~~~~~~~~~~ +Files (and pointers to subtrees) within active trees require 52 or 64 +bytes (32/64 bit platforms) per entry. To conserve space, file and +tree names are pooled in a common string table, allowing the filename +``Makefile'' to use just 16 bytes (after including the string header +overhead) no matter how many times it occurs within the project. + +The active branch LRU, when coupled with the filename string pool +and lazy loading of subtrees, allows fast-import to efficiently import +projects with 2,000+ branches and 45,114+ files in a very limited +memory footprint (less than 2.7 MiB per active branch). + + +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-fetch-pack.txt b/Documentation/git-fetch-pack.txt new file mode 100644 index 0000000000..47448da22e --- /dev/null +++ b/Documentation/git-fetch-pack.txt @@ -0,0 +1,104 @@ +git-fetch-pack(1) +================= + +NAME +---- +git-fetch-pack - Receive missing objects from another repository + + +SYNOPSIS +-------- +'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...] + +DESCRIPTION +----------- +Usually you would want to use 'git-fetch', which is a +higher level wrapper of this command, instead. + +Invokes 'git-upload-pack' on a possibly remote repository +and asks it to send objects missing from this repository, to +update the named heads. The list of commits available locally +is found out by scanning local $GIT_DIR/refs/ and sent to +'git-upload-pack' running on the other end. + +This command degenerates to download everything to complete the +asked refs from the remote side when the local side does not +have a common ancestor commit. + + +OPTIONS +------- +--all:: + Fetch all remote refs. + +-q:: +--quiet:: + Pass '-q' flag to 'git-unpack-objects'; this makes the + cloning process less verbose. + +-k:: +--keep:: + Do not invoke 'git-unpack-objects' on received data, but + create a single packfile out of it instead, and store it + in the object database. If provided twice then the pack is + locked against repacking. + +--thin:: + Spend extra cycles to minimize the number of objects to be sent. + Use it on slower connection. + +--include-tag:: + If the remote side supports it, annotated tags objects will + be downloaded on the same connection as the other objects if + the object the tag references is downloaded. The caller must + otherwise determine the tags this option made available. + +--upload-pack=<git-upload-pack>:: + Use this to specify the path to 'git-upload-pack' on the + remote side, if is not found on your $PATH. + 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 by having a lean .bashrc file (they set most of + the things up in .bash_profile). + +--exec=<git-upload-pack>:: + Same as \--upload-pack=<git-upload-pack>. + +--depth=<n>:: + Limit fetching to ancestor-chains not longer than n. + +--no-progress:: + Do not show the progress. + +-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. + +<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. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt new file mode 100644 index 0000000000..9b9e5686e4 --- /dev/null +++ b/Documentation/git-fetch.txt @@ -0,0 +1,95 @@ +git-fetch(1) +============ + +NAME +---- +git-fetch - Download objects and refs from another repository + + +SYNOPSIS +-------- +'git fetch' <options> <repository> <refspec>... + +'git fetch' <options> <group> + +'git fetch' --multiple <options> [<repository> | <group>]... + +'git fetch' --all <options> + + +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 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, or +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]). + +OPTIONS +------- +include::fetch-options.txt[] + +include::pull-fetch-param.txt[] + +include::urls-remotes.txt[] + + +EXAMPLES +-------- + +* Update the remote-tracking branches: ++ +------------------------------------------------ +$ git fetch origin +------------------------------------------------ ++ +The above command copies all branches from the remote refs/heads/ +namespace and stores them to the local refs/remotes/origin/ namespace, +unless the branch.<name>.fetch option is used to specify a non-default +refspec. + +* Using refspecs explicitly: ++ +------------------------------------------------ +$ git fetch origin +pu:pu maint:tmp +------------------------------------------------ ++ +This updates (or creates, as necessary) branches `pu` and `tmp` in +the local repository by fetching from the branches (respectively) +`pu` and `maint` from the remote repository. ++ +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. + + +SEE ALSO +-------- +linkgit:git-pull[1] + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> and +Junio C Hamano <gitster@pobox.com> + +Documentation +------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt new file mode 100644 index 0000000000..394a77a35f --- /dev/null +++ b/Documentation/git-filter-branch.txt @@ -0,0 +1,420 @@ +git-filter-branch(1) +==================== + +NAME +---- +git-filter-branch - Rewrite branches + +SYNOPSIS +-------- +[verse] +'git filter-branch' [--env-filter <command>] [--tree-filter <command>] + [--index-filter <command>] [--parent-filter <command>] + [--msg-filter <command>] [--commit-filter <command>] + [--tag-name-filter <command>] [--subdirectory-filter <directory>] + [--prune-empty] + [--original <namespace>] [-d <directory>] [-f | --force] + [--] [<rev-list options>...] + +DESCRIPTION +----------- +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. +Otherwise, all information (including original commit times or merge +information) will be preserved. + +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, +therefore such a usage is permitted. + +*NOTE*: This command honors `.git/info/grafts`. If you have any grafts +defined, running this command will make them permanent. + +*WARNING*! The rewritten history will have different object names for all +the objects and will not converge with the original branch. You will not +be able to easily push and distribute the rewritten branch on top of the +original branch. Please do not use this command if you do not know the +full implications, and avoid using it anyway, if a simple single commit +would suffice to fix your problem. (See the "RECOVERING FROM UPSTREAM +REBASE" section in linkgit:git-rebase[1] for further information about +rewriting published history.) + +Always verify that the rewritten version is correct: The original refs, +if different from the rewritten ones, will be stored in the namespace +'refs/original/'. + +Note that since this operation is very I/O expensive, it might +be a good idea to redirect the temporary directory off-disk with the +'-d' option, e.g. on tmpfs. Reportedly the speedup is very noticeable. + + +Filters +~~~~~~~ + +The filters are applied in the order as listed below. The <command> +argument is always evaluated in the shell context using the 'eval' command +(with the notable exception of the commit filter, for technical reasons). +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. +If any evaluation of <command> returns a non-zero exit status, the whole +operation will be aborted. + +A 'map' function is available that takes an "original sha1 id" argument +and outputs a "rewritten sha1 id" if the commit has been already +rewritten, and "original sha1 id" otherwise; the 'map' function can +return several ids on separate lines if your commit filter emitted +multiple commits. + + +OPTIONS +------- + +--env-filter <command>:: + This filter may be used if you only need to modify the environment + in which the commit will be performed. Specifically, you might + want to rewrite the author/committer name/email/time environment + variables (see linkgit:git-commit[1] for details). Do not forget + to re-export the variables. + +--tree-filter <command>:: + This is the filter for rewriting the tree and its contents. + The argument is evaluated in shell with the working + directory set to the root of the checked out tree. The new tree + is then used as-is (new files are auto-added, disappeared files + are auto-removed - neither .gitignore files nor any other ignore + rules *HAVE ANY EFFECT*!). + +--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 + cases, see linkgit:git-update-index[1]. + +--parent-filter <command>:: + This is the filter for rewriting the commit's parent list. + It will receive the parent string on stdin and shall output + the new parent string on stdout. The parent string is in + the format described in linkgit:git-commit-tree[1]: empty for + the initial commit, "-p parent" for a normal commit and + "-p parent1 -p parent2 -p parent3 ..." for a merge commit. + +--msg-filter <command>:: + This is the filter for rewriting the commit messages. + The argument is evaluated in the shell with the original + commit message on standard input; its standard output is + used as the new commit message. + +--commit-filter <command>:: + This is the filter for performing the commit. + If this filter is specified, it will be called instead of the + 'git-commit-tree' command, with arguments of the form + "<TREE_ID> [-p <PARENT_COMMIT_ID>]..." and the log message on + stdin. The commit id is expected on stdout. ++ +As a special extension, the commit filter may emit multiple +commit ids; in that case, the rewritten children of the original commit will +have all of them as parents. ++ +You can use the 'map' convenience function in this filter, and other +convenience functions, too. For example, calling 'skip_commit "$@"' +will leave out the current commit (but not its changes! If you want +that, use 'git-rebase' instead). ++ +You can also use the 'git_commit_non_empty_tree "$@"' instead of +'git commit-tree "$@"' if you don't wish to keep commits with a single parent +and that makes no change to the tree. + +--tag-name-filter <command>:: + This is the filter for rewriting tag names. When passed, + it will be called for every tag ref that points to a rewritten + object (or to a tag object which points to a rewritten object). + The original tag name is passed via standard input, and the new + tag name is expected on standard output. ++ +The original tags are not deleted, but can be overwritten; +use "--tag-name-filter cat" to simply update the tags. In this +case, be very careful and make sure you have the old tags +backed up in case the conversion has run afoul. ++ +Nearly proper rewriting of tag objects is supported. If the tag has +a message attached, a new tag object will be created with the same message, +author, and timestamp. If the tag has a signature attached, the +signature will be stripped. It is by definition impossible to preserve +signatures. The reason this is "nearly" proper, is because ideally if +the tag did not change (points to the same object, has the same name, etc.) +it should retain any signature. That is not the case, signatures will always +be removed, buyer beware. There is also no support for changing the +author or timestamp (or the tag message for that matter). Tags which point +to other tags will be rewritten to point to the underlying commit. + +--subdirectory-filter <directory>:: + Only look at the history which touches the given subdirectory. + The result will contain that directory (and only that) as its + project root. Implies --remap-to-ancestor. + +--remap-to-ancestor:: + Rewrite refs to the nearest rewritten ancestor instead of + ignoring them. ++ +Normally, positive refs on the command line are only changed if the +commit they point to was rewritten. However, you can limit the extent +of this rewriting by using linkgit:rev-list[1] arguments, e.g., path +limiters. Refs pointing to such excluded commits would then normally +be ignored. With this option, they are instead rewritten to point at +the nearest ancestor that was not excluded. + +--prune-empty:: + Some kind of filters will generate empty commits, that left the tree + untouched. This switch allow git-filter-branch to ignore such + commits. Though, this switch only applies for commits that have one + and only one parent, it will hence keep merges points. Also, this + option is not compatible with the use of '--commit-filter'. Though you + just need to use the function 'git_commit_non_empty_tree "$@"' instead + of the 'git commit-tree "$@"' idiom in your commit filter to make that + happen. + +--original <namespace>:: + Use this option to set the namespace where the original commits + will be stored. The default value is 'refs/original'. + +-d <directory>:: + Use this option to set the path to the temporary directory used for + rewriting. When applying a tree filter, the command needs to + temporarily check out the tree to some directory, which may consume + considerable space in case of large projects. By default it + does this in the '.git-rewrite/' directory but you can override + that choice by this parameter. + +-f:: +--force:: + 'git-filter-branch' refuses to start with an existing temporary + directory or when there are already refs starting with + 'refs/original/', unless forced. + +<rev-list options>...:: + Arguments for 'git-rev-list'. All positive refs included by + these options are rewritten. You may also specify options + such as '--all', but you must use '--' to separate them from + the 'git-filter-branch' options. + + +Examples +-------- + +Suppose you want to remove a file (containing confidential information +or copyright violation) from all commits: + +------------------------------------------------------- +git filter-branch --tree-filter 'rm filename' HEAD +------------------------------------------------------- + +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 +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`: + +-------------------------------------------------------------------------- +git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD +-------------------------------------------------------------------------- + +Now, you will get the rewritten history saved in HEAD. + +To rewrite the repository to look as if `foodir/` had been its project +root, and discard all other history: + +------------------------------------------------------- +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. + +To set a commit (which typically is at the tip of another +history) to be the parent of the current initial commit, in +order to paste the other history behind the current history: + +------------------------------------------------------------------- +git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD +------------------------------------------------------------------- + +(if the parent string is empty - which happens when we are dealing with +the initial commit - add graftcommit as a parent). Note that this assumes +history with a single root (that is, no merge without common ancestors +happened). If this is not the case, use: + +-------------------------------------------------------------------------- +git filter-branch --parent-filter \ + 'test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>" || cat' HEAD +-------------------------------------------------------------------------- + +or even simpler: + +----------------------------------------------- +echo "$commit-id $graft-id" >> .git/info/grafts +git filter-branch $graft-id..HEAD +----------------------------------------------- + +To remove commits authored by "Darl McBribe" from the history: + +------------------------------------------------------------------------------ +git filter-branch --commit-filter ' + if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ]; + then + skip_commit "$@"; + else + git commit-tree "$@"; + fi' HEAD +------------------------------------------------------------------------------ + +The function 'skip_commit' is defined as follows: + +-------------------------- +skip_commit() +{ + shift; + while [ -n "$1" ]; + do + shift; + map "$1"; + shift; + done; +} +-------------------------- + +The shift magic first throws away the tree id and then the -p +parameters. Note that this handles merges properly! In case Darl +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. + +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: + +------------------------------------------------------- +git filter-branch --msg-filter ' + sed -e "/^git-svn-id:/d" +' +------------------------------------------------------- + +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: + +-------------------------------------------------------- +git filter-branch --msg-filter ' + cat && + echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>" +' 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'. + + +Consider this history: + +------------------ + D--E--F--G--H + / / +A--B-----C +------------------ + +To rewrite only commits D,E,F,G,H, but leave A, B and C alone, use: + +-------------------------------- +git filter-branch ... C..H +-------------------------------- + +To rewrite commits E,F,G,H, use one of these: + +---------------------------------------- +git filter-branch ... C..H --not D +git filter-branch ... D..H --not C +---------------------------------------- + +To move the whole tree into a subdirectory, or remove it from there: + +--------------------------------------------------------------- +git filter-branch --index-filter \ + 'git ls-files -s | sed "s-\t-&newsubdir/-" | + GIT_INDEX_FILE=$GIT_INDEX_FILE.new \ + git update-index --index-info && + mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD +--------------------------------------------------------------- + + + +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 +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 +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. + +* 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 + will not have the removed objects. See linkgit:git-clone[1]. (Note + that cloning with a plain path just hardlinks everything!) + +If you really don't want to clone it, for whatever reasons, check the +following points instead (in this order). This is a very destructive +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 + update-ref -d`. + +* Expire all reflogs with `git reflog expire \--expire=now \--all`. + +* 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). + + +Author +------ +Written by Petr "Pasky" Baudis <pasky@suse.cz>, +and the git list <git@vger.kernel.org> + +Documentation +-------------- +Documentation by Petr Baudis and the git list. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt new file mode 100644 index 0000000000..a586950b48 --- /dev/null +++ b/Documentation/git-fmt-merge-msg.txt @@ -0,0 +1,72 @@ +git-fmt-merge-msg(1) +==================== + +NAME +---- +git-fmt-merge-msg - Produce a merge commit message + + +SYNOPSIS +-------- +[verse] +'git fmt-merge-msg' [--log | --no-log] <$GIT_DIR/FETCH_HEAD +'git fmt-merge-msg' [--log | --no-log] -F <file> + +DESCRIPTION +----------- +Takes the list of merged objects on stdin and produces a suitable +commit message to be used for the merge commit, usually to be +passed as the '<merge-message>' argument of 'git-merge'. + +This command is intended mostly for internal use by scripts +automatically invoking 'git merge'. + +OPTIONS +------- + +--log:: + In addition to branch names, populate the log message with + one-line descriptions from the actual commits that are being + merged. + +--no-log:: + Do not list one-line descriptions from the actual commits being + merged. + +--summary:: +--no-summary:: + Synonyms to --log and --no-log; these are deprecated and will be + removed in the future. + +-F <file>:: +--file <file>:: + Take the list of merged objects from <file> instead of + stdin. + +CONFIGURATION +------------- + +merge.log:: + Whether to include summaries of merged commits in newly + merge commit messages. False by default. + +merge.summary:: + Synonym to `merge.log`; this is deprecated and will be removed in + the future. + +SEE ALSO +-------- +linkgit:git-merge[1] + + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt new file mode 100644 index 0000000000..8dc873fd44 --- /dev/null +++ b/Documentation/git-for-each-ref.txt @@ -0,0 +1,205 @@ +git-for-each-ref(1) +=================== + +NAME +---- +git-for-each-ref - Output information on each ref + +SYNOPSIS +-------- +[verse] +'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl] + [--sort=<key>]\* [--format=<format>] [<pattern>...] + +DESCRIPTION +----------- + +Iterate over all refs that match `<pattern>` and show them +according to the given `<format>`, after sorting them according +to the given set of `<key>`. If `<count>` is given, stop after +showing that many refs. The interpolated values in `<format>` +can optionally be quoted as string literals in the specified +host language allowing their direct evaluation in that language. + +OPTIONS +------- +<count>:: + By default the command shows all refs that match + `<pattern>`. This option makes it stop after showing + that many refs. + +<key>:: + A field name to sort on. Prefix `-` to sort in + descending order of the value. When unspecified, + `refname` is used. You may use the --sort=<key> option + multiple times, in which case the last key becomes the primary + key. + +<format>:: + A string that interpolates `%(fieldname)` from the + object pointed at by a ref being shown. If `fieldname` + is prefixed with an asterisk (`*`) and the ref points + at a tag object, the value for the field in the object + tag refers is used. When unspecified, defaults to + `%(objectname) SPC %(objecttype) TAB %(refname)`. + It also interpolates `%%` to `%`, and `%xx` where `xx` + are hex digits interpolates to character with hex code + `xx`; for example `%00` interpolates to `\0` (NUL), + `%09` to `\t` (TAB) and `%0a` to `\n` (LF). + +<pattern>...:: + If one or more patterns are given, only refs are shown that + match against at least one pattern, either using fnmatch(3) or + literally, in the latter case matching completely or from the + beginning up to a slash. + +--shell:: +--perl:: +--python:: +--tcl:: + If given, strings that substitute `%(fieldname)` + placeholders are quoted as string literals suitable for + the specified host language. This is meant to produce + a scriptlet that can directly be `eval`ed. + + +FIELD NAMES +----------- + +Various values from structured fields in referenced objects can +be used to interpolate into the resulting output, or as sort +keys. + +For all objects, the following names can be used: + +refname:: + The name of the ref (the part after $GIT_DIR/). + For a non-ambiguous short name of the ref append `:short`. + The option core.warnAmbiguousRefs is used to select the strict + abbreviation mode. + +objecttype:: + The type of the object (`blob`, `tree`, `commit`, `tag`). + +objectsize:: + The size of the object (the same as 'git-cat-file -s' reports). + +objectname:: + The object name (aka SHA-1). + +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. + +In addition to the above, for commit and tag objects, the header +field names (`tree`, `parent`, `object`, `type`, and `tag`) can +be used to specify the value in the header field. + +Fields that have name-email-date tuple as its value (`author`, +`committer`, and `tagger`) can be suffixed with `name`, `email`, +and `date` to extract the named component. + +The first line of the message in a commit and tag object is +`subject`, the remaining lines are `body`. The whole message +is `contents`. + +For sorting purposes, fields with numeric values sort in numeric +order (`objectsize`, `authordate`, `committerdate`, `taggerdate`). +All other fields are used to sort in their byte-value order. + +In any case, a field name that refers to a field inapplicable to +the object referred by the ref does not cause an error. It +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. +`%(taggerdate:relative)`. + + +EXAMPLES +-------- + +An example directly producing formatted text. Show the most recent +3 tagged commits:: + +------------ +#!/bin/sh + +git for-each-ref --count=3 --sort='-*authordate' \ +--format='From: %(*authorname) %(*authoremail) +Subject: %(*subject) +Date: %(*authordate) +Ref: %(*refname) + +%(*body) +' 'refs/tags' +------------ + + +A simple example showing the use of shell eval on the output, +demonstrating the use of --shell. List the prefixes of all heads:: +------------ +#!/bin/sh + +git for-each-ref --shell --format="ref=%(refname)" refs/heads | \ +while read entry +do + eval "$entry" + echo `dirname $ref` +done +------------ + + +A bit more elaborate report on tags, demonstrating that the format +may be an entire script:: +------------ +#!/bin/sh + +fmt=' + r=%(refname) + t=%(*objecttype) + T=${r#refs/tags/} + + o=%(*objectname) + n=%(*authorname) + e=%(*authoremail) + s=%(*subject) + d=%(*authordate) + b=%(*body) + + kind=Tag + if test "z$t" = z + then + # could be a lightweight tag + t=%(objecttype) + kind="Lightweight tag" + o=%(objectname) + n=%(authorname) + e=%(authoremail) + s=%(subject) + d=%(authordate) + b=%(body) + fi + echo "$kind $T points at a $t object $o" + if test "z$t" = zcommit + then + echo "The commit was authored by $n $e +at $d, and titled + + $s + +Its message reads as: +" + echo "$b" | sed -e "s/^/ /" + echo + fi +' + +eval=`git for-each-ref --shell --format="$fmt" \ + --sort='*objecttype' \ + --sort=-taggerdate \ + refs/tags` +eval "$eval" +------------ diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt new file mode 100644 index 0000000000..f1fd0df08a --- /dev/null +++ b/Documentation/git-format-patch.txt @@ -0,0 +1,280 @@ +git-format-patch(1) +=================== + +NAME +---- +git-format-patch - Prepare patches for e-mail submission + + +SYNOPSIS +-------- +[verse] +'git format-patch' [-k] [(-o|--output-directory) <dir> | --stdout] + [--no-thread | --thread[=<style>]] + [(--attach|--inline)[=<boundary>] | --no-attach] + [-s | --signoff] + [-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] + [--cc=<email>] + [--cover-letter] + [<common diff options>] + [ <since> | <revision range> ] + +DESCRIPTION +----------- + +Prepare each commit with its patch in +one file per commit, formatted to resemble UNIX mailbox format. +The output of this command is convenient for e-mail submission or +for use with 'git-am'. + +There are two ways to specify which commits to operate on. + +1. A single commit, <since>, specifies that the commits leading + to the tip of the current branch that are not in the history + that leads to the <since> to be output. + +2. Generic <revision range> expression (see "SPECIFYING + REVISIONS" section in linkgit:git-rev-parse[1]) means the + commits in the specified range. + +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 +can do this with `git format-patch -1 <commit>`. + +By default, each output file is numbered sequentially from 1, and uses the +first line of the commit message (massaged for pathname safety) as +the filename. With the `--numbered-files` option, the output file names +will only be numbers, without the first line of the commit appended. +The names of the output files are printed to standard +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`. + +If given `--thread`, `git-format-patch` will generate `In-Reply-To` and +`References` headers to make the second and subsequent patch mails appear +as replies to the first mail; this also generates a `Message-Id` header to +reference. + +OPTIONS +------- +:git-format-patch: 1 +include::diff-options.txt[] + +-<n>:: + Limits the number of patches to prepare. + +-o <dir>:: +--output-directory <dir>:: + Use <dir> to store the resulting files, instead of the + current working directory. + +-n:: +--numbered:: + Name output in '[PATCH n/m]' format, even with a single patch. + +-N:: +--no-numbered:: + Name output in '[PATCH]' format. + +--start-number <n>:: + Start numbering the patches at <n> instead of 1. + +--numbered-files:: + Output file names will be a simple number sequence + without the default first line of the commit appended. + +-k:: +--keep-subject:: + Do not strip/add '[PATCH]' from the first line of the + commit log message. + +-s:: +--signoff:: + Add `Signed-off-by:` line to the commit message, using + the committer identity of yourself. + +--stdout:: + Print all commits to the standard output in mbox format, + instead of creating a file for each one. + +--attach[=<boundary>]:: + Create multipart/mixed attachment, the first part of + which is the commit message and the patch itself in the + second part, with `Content-Disposition: attachment`. + +--no-attach:: + Disable the creation of an attachment, overriding the + configuration setting. + +--inline[=<boundary>]:: + Create multipart/mixed attachment, the first part of + which is the commit message and the patch itself in the + second part, with `Content-Disposition: inline`. + +--thread[=<style>]:: +--no-thread:: + Controls addition of `In-Reply-To` and `References` headers to + make the second and subsequent mails appear as replies to the + first. Also controls generation of the `Message-Id` header to + reference. ++ +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' +threading makes every mail a reply to the previous one. ++ +The default is `--no-thread`, unless the 'format.thread' configuration +is set. If `--thread` is specified without a style, it defaults to the +style specified by 'format.thread' if any, or else `shallow`. ++ +Beware that the default for 'git send-email' is to thread emails +itself. If you want `git format-patch` to take care of threading, you +will want to ensure that threading is disabled for `git send-email`. + +--in-reply-to=Message-Id:: + Make the first mail (or all the mails with `--no-thread`) appear as a + reply to the given Message-Id, which avoids breaking threads to + provide a new patch series. + +--ignore-if-in-upstream:: + Do not include a patch that matches a commit in + <until>..<since>. This will examine all patches reachable + from <since> but not from <until> and compare them with the + patches being generated, and any patch that matches is + ignored. + +--subject-prefix=<Subject-Prefix>:: + Instead of the standard '[PATCH]' prefix in the subject + line, instead use '[<Subject-Prefix>]'. This + allows for useful naming of a patch series, and can be + combined with the `--numbered` option. + +--cc=<email>:: + Add a `Cc:` header to the email headers. This is in addition + to any configured headers, and may be used multiple times. + +--add-header=<header>:: + Add an arbitrary header to the email headers. This is in addition + to any configured headers, and may be used multiple times. + For example, `--add-header="Organization: git-foo"` + +--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. + +--suffix=.<sfx>:: + Instead of using `.patch` as the suffix for generated + filenames, use specified suffix. A common alternative is + `--suffix=.txt`. Leaving this empty will remove the `.patch` + suffix. ++ +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`. + +--no-binary:: + Do not output contents of changes in binary files, instead + display a notice that those files changed. Patches generated + using this option cannot be applied properly, but they are + still useful for code review. + +--root:: + Treat the revision argument as a <revision range>, even if it + is just a single commit (that would normally be treated as a + <since>). Note that root commits included in the specified + range are always formatted as creation patches, independently + of this flag. + +CONFIGURATION +------------- +You can specify extra mail header lines to be added to each message, +defaults for the subject prefix and file suffix, number patches when +outputting more than one patch, add "Cc:" headers, configure attachments, +and sign off patches with configuration variables. + +------------ +[format] + headers = "Organization: git-foo\n" + subjectprefix = CHANGE + suffix = .txt + numbered = auto + cc = <email> + attach [ = mime-boundary-string ] + signoff = true +------------ + + +EXAMPLES +-------- + +* Extract commits between revisions R1 and R2, and apply them on top of +the current branch using 'git-am' to cherry-pick them: ++ +------------ +$ git format-patch -k --stdout R1..R2 | git am -3 -k +------------ + +* Extract all commits which are in the current branch but not in the +origin branch: ++ +------------ +$ git format-patch origin +------------ ++ +For each commit a separate file is created in the current directory. + +* Extract all commits that lead to 'origin' since the inception of the +project: ++ +------------ +$ git format-patch --root origin +------------ + +* The same as the previous one: ++ +------------ +$ 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. + +* Extract three topmost commits from the current branch and format them +as e-mailable patches: ++ +------------ +$ git format-patch -3 +------------ + +SEE ALSO +-------- +linkgit:git-am[1], linkgit:git-send-email[1] + + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-fsck-objects.txt b/Documentation/git-fsck-objects.txt new file mode 100644 index 0000000000..965a8279c1 --- /dev/null +++ b/Documentation/git-fsck-objects.txt @@ -0,0 +1,17 @@ +git-fsck-objects(1) +=================== + +NAME +---- +git-fsck-objects - Verifies the connectivity and validity of the objects in the database + + +SYNOPSIS +-------- +'git fsck-objects' ... + +DESCRIPTION +----------- + +This is a synonym for linkgit:git-fsck[1]. Please refer to the +documentation of that command. diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt new file mode 100644 index 0000000000..6fe9484da3 --- /dev/null +++ b/Documentation/git-fsck.txt @@ -0,0 +1,156 @@ +git-fsck(1) +=========== + +NAME +---- +git-fsck - Verifies the connectivity and validity of the objects in the database + + +SYNOPSIS +-------- +[verse] +'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] + [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*] + +DESCRIPTION +----------- +Verifies the connectivity and validity of the objects in the database. + +OPTIONS +------- +<object>:: + 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. + +--unreachable:: + Print out objects that exist but that aren't readable from any + of the reference nodes. + +--root:: + Report root nodes. + +--tags:: + Report tags. + +--cache:: + Consider any object recorded in the index also as a head node for + an unreachability trace. + +--no-reflogs:: + Do not consider commits that are referenced only by an + entry in a reflog to be reachable. This option is meant + only to search for commits that used to be in a ref, but + now aren't, but are still in that corresponding reflog. + +--full:: + Check not just objects in GIT_OBJECT_DIRECTORY + ($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 corresponding pack subdirectories in alternate + object pools. This is now default; you can turn it off + with --no-full. + +--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 + objects that triggers this check, but it is recommended + to check new projects with this flag. + +--verbose:: + Be chatty. + +--lost-found:: + Write dangling objects into .git/lost-found/commit/ or + .git/lost-found/other/, depending on type. If the object is + a blob, the contents are written into the file, rather than + its object name. + +It tests SHA1 and general object sanity, and it does full tracking of +the resulting reachability and everything else. It prints out any +corruption it finds (missing or bad objects), and if you use the +'--unreachable' flag it will also print out objects that exist but +that aren't readable from any of the specified head nodes. + +So for example + + git fsck --unreachable HEAD \ + $(git for-each-ref --format="%(objectname)" refs/heads) + +will do quite a _lot_ of verification on the tree. There are a few +extra validity tests to be added (make sure that tree objects are +sorted properly etc), but on the whole if 'git-fsck' is happy, you +do have a valid tree. + +Any corrupt objects you will have to find in backups or other archives +(i.e., you can just remove them and do an 'rsync' with some other site in +the hopes that somebody else has the object you have corrupted). + +Of course, "valid tree" doesn't mean that it wasn't generated by some +evil person, and the end result might be crap. git is a revision +tracking system, not a quality assurance system ;) + +Extracted Diagnostics +--------------------- + +expect dangling commits - potential heads - due to lack of head information:: + You haven't specified any nodes as heads so it won't be + possible to differentiate between un-parented commits and + root nodes. + +missing sha1 directory '<dir>':: + The directory holding the sha1 objects is missing. + +unreachable <type> <object>:: + The <type> object <object>, isn't actually referred to directly + or indirectly in any of the trees or commits seen. This can + mean that there's another root node that you're not specifying + or that the tree is corrupt. If you haven't missed a root node + then you might as well delete unreachable nodes since they + can't be used. + +missing <type> <object>:: + The <type> object <object>, is referred to but isn't present in + the database. + +dangling <type> <object>:: + The <type> object <object>, is present in the database but never + 'directly' used. A dangling commit could be a root node. + +warning: git-fsck: tree <tree> has full pathnames in it:: + And it shouldn't... + +sha1 mismatch <object>:: + The database has an object who's sha1 doesn't match the + database value. + This indicates a serious data integrity problem. + +Environment Variables +--------------------- + +GIT_OBJECT_DIRECTORY:: + used to specify the object database root (usually $GIT_DIR/objects) + +GIT_INDEX_FILE:: + used to specify the index file of the index + +GIT_ALTERNATE_OBJECT_DIRECTORIES:: + used to specify additional object database roots (usually unset) + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt new file mode 100644 index 0000000000..4cd9cdf905 --- /dev/null +++ b/Documentation/git-gc.txt @@ -0,0 +1,143 @@ +git-gc(1) +========= + +NAME +---- +git-gc - Cleanup unnecessary files and optimize the local repository + + +SYNOPSIS +-------- +'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] + +DESCRIPTION +----------- +Runs a number of housekeeping tasks within the current repository, +such as compressing file revisions (to reduce disk space and increase +performance) and removing unreachable objects which may have been +created from prior invocations of 'git-add'. + +Users are encouraged to run this task on a regular basis within +each repository to maintain good disk space utilization and good +operating performance. + +Some git commands may automatically run 'git-gc'; see the `--auto` flag +below for details. If you know what you're doing and all you want is to +disable this behavior permanently without further considerations, just do: + +---------------------- +$ git config --global gc.auto 0 +---------------------- + +OPTIONS +------- + +--aggressive:: + Usually 'git-gc' runs very quickly while providing good disk + space utilization and performance. This option will cause + 'git-gc' to more aggressively optimize the repository at the expense + of taking much more time. The effects of this optimization are + persistent, so this option only needs to be used occasionally; every + few hundred changesets or so. + +--auto:: + With this option, 'git-gc' checks whether any housekeeping is + required; if not, it exits without performing any work. + Some git commands run `git gc --auto` after performing + operations that could create many loose objects. ++ +Housekeeping is required if there are too many loose objects or +too many packs in the repository. If the number of loose objects +exceeds the value of the `gc.auto` configuration variable, then +all loose objects are combined into a single pack using +'git-repack -d -l'. Setting the value of `gc.auto` to 0 +disables automatic packing of loose objects. ++ +If the number of packs exceeds the value of `gc.autopacklimit`, +then existing packs (except those marked with a `.keep` file) +are consolidated into a single pack by using the `-A` option of +'git-repack'. Setting `gc.autopacklimit` to 0 disables +automatic consolidation of packs. + +--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. + +--no-prune:: + Do not prune any loose objects. + +--quiet:: + Suppress all progress reports. + +Configuration +------------- + +The optional configuration variable 'gc.reflogExpire' can be +set to indicate how long historical entries within each branch's +reflog should remain available in this repository. The setting is +expressed as a length of time, for example '90 days' or '3 months'. +It defaults to '90 days'. + +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 +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'. + +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 +how long records of conflicted merge you have not resolved are +kept. This defaults to 15 days. + +The optional configuration variable 'gc.packrefs' determines if +'git-gc' runs 'git-pack-refs'. This can be set to "nobare" to enable +it within all non-bare repos or it can be set to a boolean value. +This defaults to true. + +The optional configuration variable 'gc.aggressiveWindow' controls how +much time is spent optimizing the delta compression of the objects in +the repository when the --aggressive option is specified. The larger +the value, the more time is spent optimizing the delta compression. See +the documentation for the --window' option in linkgit:git-repack[1] for +more details. 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". + + +Notes +----- + +'git-gc' tries very hard to be safe about the garbage it collects. In +particular, it will keep not only objects referenced by your current set +of branches and tags, but also objects referenced by the index, remote +tracking branches, refs saved by 'git-filter-branch' in +refs/original/, or reflogs (which may reference commits in branches +that were later amended or rewound). + +If you are expecting some objects to be collected and they aren't, check +all of those locations and decide whether it makes sense in your case to +remove those references. + +SEE ALSO +-------- +linkgit:git-prune[1] +linkgit:git-reflog[1] +linkgit:git-repack[1] +linkgit:git-rerere[1] + +Author +------ +Written by Shawn O. Pearce <spearce@spearce.org> + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt new file mode 100644 index 0000000000..84f23ee525 --- /dev/null +++ b/Documentation/git-get-tar-commit-id.txt @@ -0,0 +1,36 @@ +git-get-tar-commit-id(1) +======================== + +NAME +---- +git-get-tar-commit-id - Extract commit ID from an archive created using git-archive + + +SYNOPSIS +-------- +'git get-tar-commit-id' < <tarfile> + + +DESCRIPTION +----------- +Acts as a filter, extracting the commit ID stored in archives created by +'git-archive'. It reads only the first 1024 bytes of input, thus its +runtime is not influenced by the size of <tarfile> very much. + +If no commit ID is found, 'git-get-tar-commit-id' quietly exists with a +return code of 1. This can happen if <tarfile> had not been created +using 'git-archive' or if the first parameter of 'git-archive' had been +a tree ID instead of a commit ID or tag. + + +Author +------ +Written by Rene Scharfe <rene.scharfe@lsrfire.ath.cx> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt new file mode 100644 index 0000000000..8c700200f5 --- /dev/null +++ b/Documentation/git-grep.txt @@ -0,0 +1,192 @@ +git-grep(1) +=========== + +NAME +---- +git-grep - Print lines matching a pattern + + +SYNOPSIS +-------- +[verse] +'git grep' [--cached] + [-a | --text] [-I] [-i | --ignore-case] [-w | --word-regexp] + [-v | --invert-match] [-h|-H] [--full-name] + [-E | --extended-regexp] [-G | --basic-regexp] + [-F | --fixed-strings] [-n] + [-l | --files-with-matches] [-L | --files-without-match] + [-z | --null] + [-c | --count] [--all-match] + [--max-depth <depth>] + [--color | --no-color] + [-A <post-context>] [-B <pre-context>] [-C <context>] + [-f <file>] [-e] <pattern> + [--and|--or|--not|(|)|-e <pattern>...] [<tree>...] + [--] [<path>...] + +DESCRIPTION +----------- +Look for specified patterns in the working tree files, blobs +registered in the index file, or given tree objects. + + +OPTIONS +------- +--cached:: + Instead of searching in the working tree files, check + the blobs registered in the index file. + +-a:: +--text:: + Process binary files as if they were text. + +-i:: +--ignore-case:: + Ignore case differences between the patterns and the + files. + +-I:: + Don't match the pattern in binary files. + +--max-depth <depth>:: + For each pathspec given on command line, descend at most <depth> + levels of directories. A negative value means no limit. + +-w:: +--word-regexp:: + Match the pattern only at word boundary (either begin at the + beginning of a line, or preceded by a non-word character; end at + the end of a line or followed by a non-word character). + +-v:: +--invert-match:: + Select non-matching lines. + +-h:: +-H:: + By default, the command shows the filename for each + match. `-h` option is used to suppress this output. + `-H` is there for completeness and does not do anything + except it overrides `-h` given earlier on the command + line. + +--full-name:: + When run from a subdirectory, the command usually + outputs paths relative to the current directory. This + option forces paths to be output relative to the project + top directory. + +-E:: +--extended-regexp:: +-G:: +--basic-regexp:: + Use POSIX extended/basic regexp for patterns. Default + is to use basic regexp. + +-F:: +--fixed-strings:: + Use fixed strings for patterns (don't interpret pattern + as a regex). + +-n:: + Prefix the line number to matching lines. + +-l:: +--files-with-matches:: +--name-only:: +-L:: +--files-without-match:: + Instead of showing every matched line, show only the + names of files that contain (or do not contain) matches. + For better compatibility with 'git-diff', --name-only is a + synonym for --files-with-matches. + +-z:: +--null:: + Output \0 instead of the character that normally follows a + file name. + +-c:: +--count:: + Instead of showing every matched line, show the number of + lines that match. + +--color:: + Show colored matches. + +--no-color:: + Turn off match highlighting, even when the configuration file + gives the default to color output. + +-[ABC] <context>:: + Show `context` trailing (`A` -- after), or leading (`B` + -- before), or both (`C` -- context) lines, and place a + line containing `--` between contiguous groups of + matches. + +-<num>:: + A shortcut for specifying -C<num>. + +-p:: +--show-function:: + Show the preceding line that contains the function name of + the match, unless the matching line is a function name itself. + The name is determined in the same way as 'git diff' works out + patch hunk headers (see 'Defining a custom hunk-header' in + linkgit:gitattributes[5]). + +-f <file>:: + Read patterns from <file>, one per line. + +-e:: + The next parameter is the pattern. This option has to be + used for patterns starting with - and should be used in + scripts passing user input to grep. Multiple patterns are + combined by 'or'. + +--and:: +--or:: +--not:: +( ... ):: + Specify how multiple patterns are combined using Boolean + expressions. `--or` is the default operator. `--and` has + higher precedence than `--or`. `-e` has to be used for all + patterns. + +--all-match:: + When giving multiple pattern expressions combined with `--or`, + this flag is specified to limit the match to files that + have lines to match all of them. + +`<tree>...`:: + Search blobs in the trees for specified patterns. + +\--:: + Signals the end of options; the rest of the parameters + are <path> limiters. + + +Example +------- + +git grep -e \'#define\' --and \( -e MAX_PATH -e PATH_MAX \):: + Looks for a line that has `#define` and either `MAX_PATH` or + `PATH_MAX`. + +git grep --all-match -e NODE -e Unexpected:: + Looks for a line that has `NODE` or `Unexpected` in + files that have lines that match both. + +Author +------ +Originally written by Linus Torvalds <torvalds@osdl.org>, later +revamped by Junio C Hamano. + + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt new file mode 100644 index 0000000000..d0bc98b852 --- /dev/null +++ b/Documentation/git-gui.txt @@ -0,0 +1,134 @@ +git-gui(1) +========== + +NAME +---- +git-gui - A portable graphical interface to Git + +SYNOPSIS +-------- +'git gui' [<command>] [arguments] + +DESCRIPTION +----------- +A Tcl/Tk based graphical user interface to Git. 'git-gui' focuses +on allowing users to make changes to their repository by making +new commits, amending existing ones, creating branches, performing +local merges, and fetching/pushing to remote repositories. + +Unlike 'gitk', 'git-gui' focuses on commit generation +and single file annotation and does not show project history. +It does however supply menu actions to start a 'gitk' session from +within 'git-gui'. + +'git-gui' is known to work on all popular UNIX systems, Mac OS X, +and Windows (under both Cygwin and MSYS). To the extent possible +OS specific user interface guidelines are followed, making 'git-gui' +a fairly native interface for users. + +COMMANDS +-------- +blame:: + Start a blame viewer on the specified file on the given + version (or working directory if not specified). + +browser:: + Start a tree browser showing all files in the specified + commit (or 'HEAD' by default). Files selected through the + browser are opened in the blame viewer. + +citool:: + Start 'git-gui' and arrange to make exactly one commit before + exiting and returning to the shell. The interface is limited + to only commit actions, slightly reducing the application's + startup time and simplifying the menubar. + +version:: + Display the currently running version of 'git-gui'. + + +Examples +-------- +git gui blame Makefile:: + + Show the contents of the file 'Makefile' in the current + working directory, and provide annotations for both the + original author of each line, and who moved the line to its + current location. The uncommitted file is annotated, and + uncommitted changes (if any) are explicitly attributed to + 'Not Yet Committed'. + +git gui blame v0.99.8 Makefile:: + + Show the contents of 'Makefile' in revision 'v0.99.8' + and provide annotations for each line. Unlike the above + example the file is read from the object database and not + the working directory. + +git gui blame --line=100 Makefile:: + + Loads annotations as described above and automatically + scrolls the view to center on line '100'. + +git gui citool:: + + Make one commit and return to the shell when it is complete. + This command returns a non-zero exit code if the window was + closed in any way other than by making a commit. + +git gui citool --amend:: + + Automatically enter the 'Amend Last Commit' mode of + the interface. + +git gui citool --nocommit:: + + Behave as normal citool, but instead of making a commit + simply terminate with a zero exit code. It still checks + that the index does not contain any unmerged entries, so + you can use it as a GUI version of linkgit:git-mergetool[1] + +git citool:: + + Same as `git gui citool` (above). + +git gui browser maint:: + + Show a browser for the tree of the 'maint' branch. Files + selected in the browser can be viewed with the internal + blame viewer. + +SEE ALSO +-------- +linkgit:gitk[1]:: + The git repository browser. Shows branches, commit history + and file differences. gitk is the utility started by + 'git-gui''s Repository Visualize actions. + +Other +----- +'git-gui' is actually maintained as an independent project, but stable +versions are distributed as part of the Git suite for the convenience +of end users. + +A 'git-gui' development repository can be obtained from: + + git clone git://repo.or.cz/git-gui.git + +or + + git clone http://repo.or.cz/r/git-gui.git + +or browsed online at http://repo.or.cz/w/git-gui.git/[]. + +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-hash-object.txt b/Documentation/git-hash-object.txt new file mode 100644 index 0000000000..0af40cfb85 --- /dev/null +++ b/Documentation/git-hash-object.txt @@ -0,0 +1,66 @@ +git-hash-object(1) +================== + +NAME +---- +git-hash-object - Compute object ID and optionally creates a blob from a file + + +SYNOPSIS +-------- +[verse] +'git hash-object' [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin] [--] <file>... +'git hash-object' [-t <type>] [-w] --stdin-paths < <list-of-paths> + +DESCRIPTION +----------- +Computes the object ID value for an object with specified type +with the contents of the named file (which can be outside of the +work tree), and optionally writes the resulting object into the +object database. Reports its object ID to its standard output. +This is used by 'git-cvsimport' to update the index +without modifying files in the work tree. When <type> is not +specified, it defaults to "blob". + +OPTIONS +------- + +-t <type>:: + Specify the type (default: "blob"). + +-w:: + Actually write the object into the object database. + +--stdin:: + Read the object from standard input instead of from a file. + +--stdin-paths:: + Read file names from stdin instead of from the command-line. + +--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 + 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 + temporary files located outside of the working directory or files + read from stdin. + +--no-filters:: + Hash the contents as is, ignoring any input filter that would + have been chosen by the attributes mechanism, including crlf + conversion. If the file is read from standard input then this + is always implied, unless the --path option is given. + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt new file mode 100644 index 0000000000..d9b9c34b3a --- /dev/null +++ b/Documentation/git-help.txt @@ -0,0 +1,187 @@ +git-help(1) +=========== + +NAME +---- +git-help - display help information about git + +SYNOPSIS +-------- +'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND] + +DESCRIPTION +----------- + +With no options and no COMMAND given, the synopsis of the 'git' +command and a list of the most commonly used git commands are printed +on the standard output. + +If the option '--all' or '-a' is given, then all available commands are +printed on the standard output. + +If a git command is named, a manual page for that command is brought +up. The 'man' program is used by default for this purpose, but this +can be overridden by other options or configuration variables. + +Note that `git --help ...` is identical to `git help ...` because the +former is internally converted into the latter. + +OPTIONS +------- +-a:: +--all:: + Prints all the available commands on the standard output. This + option supersedes any other option. + +-i:: +--info:: + Display manual page for the command in the 'info' format. The + 'info' program will be used for that purpose. + +-m:: +--man:: + Display manual page for the command in the 'man' format. This + option may be used to override a value set in the + 'help.format' configuration variable. ++ +By default the 'man' program will be used to display the manual page, +but the 'man.viewer' configuration variable may be used to choose +other display programs (see below). + +-w:: +--web:: + Display manual page for the command in the 'web' (HTML) + format. A web browser will be used for that purpose. ++ +The web browser can be specified using the configuration variable +'help.browser', or 'web.browser' if the former is not set. If none of +these config variables is set, the 'git-web--browse' helper script +(called by 'git-help') will pick a suitable default. See +linkgit:git-web--browse[1] for more information about this. + +CONFIGURATION VARIABLES +----------------------- + +help.format +~~~~~~~~~~~ + +If no command line option is passed, the 'help.format' configuration +variable will be checked. The following values are supported for this +variable; they make 'git-help' behave as their corresponding command +line option: + +* "man" corresponds to '-m|--man', +* "info" corresponds to '-i|--info', +* "web" or "html" correspond to '-w|--web'. + +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 +option or configuration variable). See '-w|--web' in the OPTIONS +section above and linkgit:git-web--browse[1]. + +man.viewer +~~~~~~~~~~ + +The 'man.viewer' config 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 +(this only works starting with emacsclient versions 22), +* "konqueror": use 'kfmclient' to open the man page in a new konqueror +tab (see 'Note about konqueror' below). + +Values for other tools can be used if there is a corresponding +'man.<tool>.cmd' configuration entry (see below). + +Multiple values may be given to the 'man.viewer' configuration +variable. Their corresponding programs will be tried in the order +listed in the configuration file. + +For example, this configuration: + +------------------------------------------------ + [man] + viewer = konqueror + viewer = woman +------------------------------------------------ + +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 +in the GIT_MAN_VIEWER environment variable will be tried. If that +fails too, the 'man' program will be tried anyway. + +man.<tool>.path +~~~~~~~~~~~~~~~ + +You can explicitly provide a full path to your preferred man viewer by +setting the configuration variable 'man.<tool>.path'. For example, you +can configure the absolute path to konqueror by setting +'man.konqueror.path'. Otherwise, 'git-help' assumes the tool is +available in PATH. + +man.<tool>.cmd +~~~~~~~~~~~~~~ + +When the man viewer, specified by the 'man.viewer' configuration +variables, is not among the supported ones, then the corresponding +'man.<tool>.cmd' configuration variable will be looked up. If this +variable exists then the specified tool will be treated as a custom +command and a shell eval will be used to run the command with the man +page passed as arguments. + +Note about konqueror +~~~~~~~~~~~~~~~~~~~~ + +When 'konqueror' is specified in the 'man.viewer' configuration +variable, we launch 'kfmclient' to try to open the man page on an +already opened konqueror in a new tab if possible. + +For consistency, we also try such a trick if 'man.konqueror.path' is +set to something like 'A_PATH_TO/konqueror'. That means we will try to +launch 'A_PATH_TO/kfmclient' instead. + +If you really want to use 'konqueror', then you can use something like +the following: + +------------------------------------------------ + [man] + viewer = konq + + [man "konq"] + cmd = A_PATH_TO/konqueror +------------------------------------------------ + +Note about git config --global +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Note that all these configuration variables should probably be set +using the '--global' flag, for example like this: + +------------------------------------------------ +$ git config --global help.format web +$ git config --global web.browser firefox +------------------------------------------------ + +as they are probably more user specific than repository specific. +See linkgit:git-config[1] for more information about this. + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> and the git-list +<git@vger.kernel.org>. + +Documentation +------------- +Initial documentation was part of the linkgit:git[1] man page. +Christian Couder <chriscool@tuxfamily.org> extracted and rewrote it a +little. Maintenance is done by the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt new file mode 100644 index 0000000000..67aec067c8 --- /dev/null +++ b/Documentation/git-http-backend.txt @@ -0,0 +1,178 @@ +git-http-backend(1) +=================== + +NAME +---- +git-http-backend - Server side implementation of Git over HTTP + +SYNOPSIS +-------- +[verse] +'git-http-backend' + +DESCRIPTION +----------- +A simple CGI program to serve the contents of a Git repository to Git +clients accessing the repository over http:// and https:// protocols. +The program supports clients fetching using both the smart HTTP protcol +and the backwards-compatible dumb HTTP protocol, as well as clients +pushing using the smart HTTP protocol. + +By default, only the `upload-pack` service is enabled, which serves +'git-fetch-pack' and 'git-ls-remote' clients, which are invoked from +'git-fetch', 'git-pull', and 'git-clone'. If the client is authenticated, +the `receive-pack` service is enabled, which serves 'git-send-pack' +clients, which is invoked from 'git-push'. + +SERVICES +-------- +These services can be enabled/disabled using the per-repository +configuration file: + +http.getanyfile:: + This serves older Git clients which are unable to use the + upload pack service. When enabled, clients are able to read + any file within the repository, including objects that are + no longer reachable from a branch but are still present. + It is enabled by default, but a repository can disable it + by setting this configuration item to `false`. + +http.uploadpack:: + This serves 'git-fetch-pack' and 'git-ls-remote' clients. + It is enabled by default, but a repository can disable it + by setting this configuration item to `false`. + +http.receivepack:: + This serves 'git-send-pack' clients, allowing push. It is + disabled by default for anonymous users, and enabled by + default for users authenticated by the web server. It can be + disabled by setting this item to `false`, or enabled for all + users, including anonymous users, by setting it to `true`. + +URL TRANSLATION +--------------- +To determine the location of the repository on disk, 'git-http-backend' +concatenates the environment variables PATH_INFO, which is set +automatically by the web server, and GIT_PROJECT_ROOT, which must be set +manually in the web server configuration. If GIT_PROJECT_ROOT is not +set, 'git-http-backend' reads PATH_TRANSLATED, which is also set +automatically by the web server. + +EXAMPLES +-------- +All of the following examples map 'http://$hostname/git/foo/bar.git' +to '/var/www/git/foo/bar.git'. + +Apache 2.x:: + Ensure mod_cgi, mod_alias, and mod_env are enabled, set + GIT_PROJECT_ROOT (or DocumentRoot) appropriately, and + create a ScriptAlias to the CGI: ++ +---------------------------------------------------------------- +SetEnv GIT_PROJECT_ROOT /var/www/git +ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/ +---------------------------------------------------------------- ++ +To enable anonymous read access but authenticated write access, +require authorization with a LocationMatch directive: ++ +---------------------------------------------------------------- +<LocationMatch "^/git/.*/git-receive-pack$"> + AuthType Basic + AuthName "Git Access" + Require group committers + ... +</LocationMatch> +---------------------------------------------------------------- ++ +To require authentication for both reads and writes, use a Location +directive around the repository, or one of its parent directories: ++ +---------------------------------------------------------------- +<Location /git/private> + AuthType Basic + AuthName "Private Git Access" + Require group committers + ... +</Location> +---------------------------------------------------------------- ++ +To serve gitweb at the same url, use a ScriptAliasMatch to only +those URLs that 'git-http-backend' can handle, and forward the +rest to gitweb: ++ +---------------------------------------------------------------- +ScriptAliasMatch \ + "(?x)^/git/(.*/(HEAD | \ + info/refs | \ + objects/(info/[^/]+ | \ + [0-9a-f]{2}/[0-9a-f]{38} | \ + pack/pack-[0-9a-f]{40}\.(pack|idx)) | \ + git-(upload|receive)-pack))$" \ + /usr/libexec/git-core/git-http-backend/$1 + +ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/ +---------------------------------------------------------------- + +Accelerated static Apache 2.x:: + Similar to the above, but Apache can be used to return static + files that are stored on disk. On many systems this may + be more efficient as Apache can ask the kernel to copy the + file contents from the file system directly to the network: ++ +---------------------------------------------------------------- +SetEnv GIT_PROJECT_ROOT /var/www/git + +AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1 +AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1 +ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/ +---------------------------------------------------------------- ++ +This can be combined with the gitweb configuration: ++ +---------------------------------------------------------------- +SetEnv GIT_PROJECT_ROOT /var/www/git + +AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/www/git/$1 +AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1 +ScriptAliasMatch \ + "(?x)^/git/(.*/(HEAD | \ + info/refs | \ + objects/info/[^/]+ | \ + git-(upload|receive)-pack))$" \ + /usr/libexec/git-core/git-http-backend/$1 +ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/ +---------------------------------------------------------------- + + +ENVIRONMENT +----------- +'git-http-backend' relies upon the CGI environment variables set +by the invoking web server, including: + +* PATH_INFO (if GIT_PROJECT_ROOT is set, otherwise PATH_TRANSLATED) +* REMOTE_USER +* REMOTE_ADDR +* CONTENT_TYPE +* QUERY_STRING +* REQUEST_METHOD + +The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and +GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}', +ensuring that any reflogs created by 'git-receive-pack' contain some +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 new file mode 100644 index 0000000000..e7c796155f --- /dev/null +++ b/Documentation/git-http-fetch.txt @@ -0,0 +1,56 @@ +git-http-fetch(1) +================= + +NAME +---- +git-http-fetch - Download from a remote git repository via HTTP + + +SYNOPSIS +-------- +'git http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url> + +DESCRIPTION +----------- +Downloads a remote git repository via HTTP. + +OPTIONS +------- +commit-id:: + Either the hash or the filename under [URL]/refs/ to + pull. + +-c:: + Get the commit objects. +-t:: + Get trees associated with the commit objects. +-a:: + Get all the objects. +-v:: + Report what is downloaded. + +-w <filename>:: + Writes the commit-id into the filename under $GIT_DIR/refs/<filename> on + the local end after the transfer is complete. + +--stdin:: + Instead of a commit id on the command line (which is not expected in this + case), 'git-http-fetch' expects lines on stdin in the format + + <commit-id>['\t'<filename-as-in--w>] + +--recover:: + Verify that everything reachable from target is fetched. Used after + an earlier fetch is interrupted. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt new file mode 100644 index 0000000000..ddf7a18dc4 --- /dev/null +++ b/Documentation/git-http-push.txt @@ -0,0 +1,105 @@ +git-http-push(1) +================ + +NAME +---- +git-http-push - Push objects over HTTP/DAV to another repository + + +SYNOPSIS +-------- +'git http-push' [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>...] + +DESCRIPTION +----------- +Sends missing objects to remote repository, and updates the +remote branch. + +*NOTE*: This command is temporarily disabled if your libcurl +is older than 7.16, as the combination has been reported +not to work and sometimes corrupts repository. + +OPTIONS +------- +--all:: + Do not assume that the remote repository is complete in its + current state, and verify all objects in the entire local + ref's history exist in the remote repository. + +--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. What this means is that + the remote repository can lose commits; use it with + care. + +--dry-run:: + Do everything except actually send the updates. + +--verbose:: + Report the list of objects being walked locally and the + list of objects successfully sent to the remote repository. + +-d:: +-D:: + Remove <ref> from remote repository. The specified branch + cannot be the remote HEAD. If -d is specified the following + other conditions must also be met: + + - Remote HEAD must resolve to an object that exists locally + - Specified branch resolves to an object that exists locally + - Specified branch is an ancestor of the remote HEAD + +<ref>...:: + The remote refs to update. + + +Specifying the Refs +------------------- + +A '<ref>' specification can be either a single pattern, or a pair +of such patterns 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>'. + +Each pattern pair consists of the source side (before the colon) +and the destination side (after the colon). The ref to be +pushed is determined by finding a match that matches the source +side, and where it is pushed is determined by using the +destination side. + + - It is an error if <src> does not match exactly one of the + local refs. + + - If <dst> does not match any remote ref, either + + * it has to start with "refs/"; <dst> is used as the + destination literally in this case. + + * <src> == <dst> and the ref that matched the <src> must not + exist in the set of remote refs; the ref matched <src> + locally is used as the name of the destination. + +Without '--force', the <src> ref is stored at the remote only if +<dst> does not exist, or <dst> is a proper subset (i.e. an +ancestor) of <src>. This check, known as "fast-forward check", +is performed in order to avoid accidentally overwriting the +remote ref and lose other peoples' commits from there. + +With '--force', the fast-forward check is disabled for all refs. + +Optionally, a <ref> parameter can be prefixed with a plus '+' sign +to disable the fast-forward check only on that ref. + + +Author +------ +Written by Nick Hengeveld <nickh@reactrix.com> + +Documentation +-------------- +Documentation by Nick Hengeveld + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt new file mode 100644 index 0000000000..d016dafd49 --- /dev/null +++ b/Documentation/git-imap-send.txt @@ -0,0 +1,137 @@ +git-imap-send(1) +================ + +NAME +---- +git-imap-send - Send a collection of patches from stdin to an IMAP folder + + +SYNOPSIS +-------- +'git imap-send' + + +DESCRIPTION +----------- +This command uploads a mailbox generated with 'git-format-patch' +into an IMAP drafts folder. This allows patches to be sent as +other email is when using mail clients that cannot read mailbox +files directly. + +Typical usage is something like: + +git format-patch --signoff --stdout --attach origin | git imap-send + + +CONFIGURATION +------------- + +To use the tool, imap.folder and either imap.tunnel or imap.host must be set +to appropriate values. + +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. + +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. + +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. + +imap.user:: + The username to use when logging in to the server. + +imap.pass:: + The password to use when logging in to the server. + +imap.port:: + An integer port number to connect to on the server. + Defaults to 143 for imap:// hosts and 993 for imaps:// hosts. + Ignored when imap.tunnel is set. + +imap.sslverify:: + A boolean to enable/disable verification of the server certificate + used by the SSL/TLS connection. Default is `true`. Ignored when + imap.tunnel is set. + +imap.preformattedHTML:: + A boolean to enable/disable the use of html encoding when sending + a patch. An html encoded patch will be bracketed with <pre> + and have a content type of text/html. Ironically, enabling this + option causes Thunderbird to send the patch as a plain/text, + format=fixed email. Default is `false`. + +Examples +~~~~~~~~ + +Using tunnel mode: + +.......................... +[imap] + folder = "INBOX.Drafts" + tunnel = "ssh -q -C user@example.com /usr/bin/imapd ./Maildir 2> /dev/null" +.......................... + +Using direct mode: + +......................... +[imap] + folder = "INBOX.Drafts" + host = imap://imap.example.com + user = bob + pass = p4ssw0rd +.......................... + +Using direct mode with SSL: + +......................... +[imap] + folder = "INBOX.Drafts" + host = imaps://imap.example.com + user = bob + pass = p4ssw0rd + port = 123 + sslverify = false +.......................... + + +CAUTION +------- +It is still your responsibility to make sure that the email message +sent by your email program meets the standards of your project. +Many projects do not like patches to be attached. Some mail +agents will transform patches (e.g. wrap lines, send them as +format=flowed) in ways that make them fail. You will get angry +flames ridiculing you if you don't check this. + +Thunderbird in particular is known to be problematic. Thunderbird +users may wish to visit this web page for more information: + http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email + + +BUGS +---- +Doesn't handle lines starting with "From " in the message body. + + +Author +------ +Derived from isync 1.0.1 by Mike McCormack. + +Documentation +-------------- +Documentation by Mike McCormack + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt new file mode 100644 index 0000000000..4b5c743c1e --- /dev/null +++ b/Documentation/git-index-pack.txt @@ -0,0 +1,103 @@ +git-index-pack(1) +================= + +NAME +---- +git-index-pack - Build pack index file for an existing packed archive + + +SYNOPSIS +-------- +[verse] +'git index-pack' [-v] [-o <index-file>] <pack-file> +'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>] + [<pack-file>] + + +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. + + +OPTIONS +------- +-v:: + Be verbose about what is going on, including progress status. + +-o <index-file>:: + Write the generated pack index into the specified + file. Without this option the name of pack index + file is constructed from the name of packed archive + file by replacing .pack with .idx (and the program + fails if the name of packed archive does not end + with .pack). + +--stdin:: + 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 + 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 + 'git-repack'. + +--fix-thin:: + It is possible for 'git-pack-objects' to build + "thin" pack, which records objects in deltified form based on + objects not included in the pack to reduce network traffic. + Those objects are expected to be present on the receiving end + and they must be included in the pack for that pack to be self + contained and indexable. Without this option any attempt to + index a thin pack will fail. This option only makes sense in + conjunction with --stdin. + +--keep:: + Before moving the index into its final destination + create an empty .keep file for the associated pack file. + This option is usually necessary with --stdin to prevent a + simultaneous 'git-repack' process from deleting + the newly constructed pack and index before refs can be + updated to use objects contained in the pack. + +--keep='why':: + Like --keep create a .keep file before moving the index into + its final destination, but rather than creating an empty file + place 'why' followed by an LF into the .keep file. The 'why' + message can later be searched for within all .keep files to + locate any which have outlived their usefulness. + +--index-version=<version>[,<offset>]:: + This is intended to be used by the test suite only. It allows + to force the version for the generated pack index, and to force + 64-bit index entries on objects located above the given offset. + +--strict:: + Die, if the pack contains broken objects or links. + + +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 +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' +mentioned above. + + +Author +------ +Written by Sergey Vlasov <vsu@altlinux.ru> + +Documentation +------------- +Documentation by Sergey Vlasov + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt new file mode 100644 index 0000000000..eba3cb4998 --- /dev/null +++ b/Documentation/git-init-db.txt @@ -0,0 +1,18 @@ +git-init-db(1) +============== + +NAME +---- +git-init-db - Creates an empty git repository + + +SYNOPSIS +-------- +'git init-db' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]] + + +DESCRIPTION +----------- + +This is a synonym for linkgit:git-init[1]. Please refer to the +documentation of that command. diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt new file mode 100644 index 0000000000..f081b24d9d --- /dev/null +++ b/Documentation/git-init.txt @@ -0,0 +1,135 @@ +git-init(1) +=========== + +NAME +---- +git-init - Create an empty git repository or reinitialize an existing one + + +SYNOPSIS +-------- +'git init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]] [directory] + + +OPTIONS +------- + +-- + +-q:: +--quiet:: + +Only print error and warning messages, all other output will be suppressed. + +--bare:: + +Create a bare repository. If GIT_DIR environment is not set, it is set to the +current working directory. + +--template=<template_directory>:: + +Provide the directory from which templates will be used. The default template +directory is `/usr/share/git-core/templates`. + +When specified, `<template_directory>` is used as the source of the template +files rather than the default. The template files include some directory +structure, some suggested "exclude patterns", and copies of non-executing +"hook" files. The suggested patterns and hook files are all modifiable and +extensible. + +--shared[={false|true|umask|group|all|world|everybody|0xxx}]:: + +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 +by umask(2). + +The option can have the following values, defaulting to 'group' if no value +is given: + + - 'umask' (or 'false'): 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. + + - 'all' (or 'world' or 'everybody'): 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). + +-- + + +DESCRIPTION +----------- +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. + +If the `$GIT_DIR` environment variable is set then it specifies a path +to use instead of `./.git` for the base of the repository. + +If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY` +environment variable then the sha1 directories are created underneath - +otherwise the default `$GIT_DIR/objects` directory is used. + +Running 'git-init' in an existing repository is safe. It will not overwrite +things that are already there. The primary reason for rerunning 'git-init' +is to pick up newly added templates. + +Note that 'git-init' is the same as 'git-init-db'. The command +was primarily meant to initialize the object database, but over +time it has become responsible for setting up the other aspects +of the repository, such as installing the default hooks and +setting the configuration variables. The old name is retained +for backward compatibility reasons. + + +EXAMPLES +-------- + +Start a new git repository for an existing code base:: ++ +---------------- +$ cd /path/to/my/codebase +$ git init <1> +$ git add . <2> +---------------- ++ +<1> prepare /path/to/my/codebase/.git directory +<2> add all existing file to the index + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt new file mode 100644 index 0000000000..0771f25443 --- /dev/null +++ b/Documentation/git-instaweb.txt @@ -0,0 +1,94 @@ +git-instaweb(1) +=============== + +NAME +---- +git-instaweb - Instantly browse your working repository in gitweb + +SYNOPSIS +-------- +[verse] +'git instaweb' [--local] [--httpd=<httpd>] [--port=<port>] + [--browser=<browser>] +'git instaweb' [--start] [--stop] [--restart] + +DESCRIPTION +----------- +A simple script to set up `gitweb` and a web server for browsing the local +repository. + +OPTIONS +------- + +-l:: +--local:: + Only bind the web server to the local IP (127.0.0.1). + +-d:: +--httpd:: + The HTTP daemon command-line that will be executed. + Command-line options may be specified here, and the + configuration file will be added at the end of the command-line. + Currently apache2, lighttpd, mongoose and webrick are supported. + (Default: lighttpd) + +-m:: +--module-path:: + The module path (only needed if httpd is Apache). + (Default: /usr/lib/apache2/modules) + +-p:: +--port:: + The port number to bind the httpd to. (Default: 1234) + +-b:: +--browser:: + The web browser that should be used to view the gitweb + page. This will be passed to the 'git-web--browse' helper + script along with the URL of the gitweb instance. See + linkgit:git-web--browse[1] for more information about this. If + the script fails, the URL will be printed to stdout. + +--start:: + Start the httpd instance and exit. This does not generate + any of the configuration files for spawning a new instance. + +--stop:: + Stop the httpd instance and exit. This does not generate + any of the configuration files for spawning a new instance, + nor does it close the browser. + +--restart:: + Restart the httpd instance and exit. This does not generate + any of the configuration files for spawning a new instance. + +CONFIGURATION +------------- + +You may specify configuration in your .git/config + +----------------------------------------------------------------------- +[instaweb] + local = true + httpd = apache2 -f + port = 4321 + browser = konqueror + modulepath = /usr/lib/apache2/modules + +----------------------------------------------------------------------- + +If the configuration variable 'instaweb.browser' is not set, +'web.browser' will be used instead if it is defined. See +linkgit:git-web--browse[1] for more information about this. + +Author +------ +Written by Eric Wong <normalperson@yhbt.net> + +Documentation +-------------- +Documentation by Eric Wong <normalperson@yhbt.net>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt new file mode 100644 index 0000000000..3d79de11ec --- /dev/null +++ b/Documentation/git-log.txt @@ -0,0 +1,126 @@ +git-log(1) +========== + +NAME +---- +git-log - Show commit logs + + +SYNOPSIS +-------- +'git log' [<options>] [<since>..<until>] [[\--] <path>...] + +DESCRIPTION +----------- +Shows the commit logs. + +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 +each commit introduces are shown. + + +OPTIONS +------- + +:git-log: 1 +include::diff-options.txt[] + +-<n>:: + Limits the number of commits to show. + +<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 "SPECIFYING REVISIONS" section in + linkgit:git-rev-parse[1]. + +--decorate[=short|full]:: + Print out the ref names of any commits that are shown. If 'short' is + specified, the ref name prefixes 'refs/heads/', 'refs/tags/' and + 'refs/remotes/' will not be printed. If 'full' is specified, the + full ref name (including prefix) will be printed. The default option + is 'short'. + +--source:: + Print out the ref name given on the command line by which each + commit was reached. + +--full-diff:: + 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. + +--follow:: + Continue listing the history of a file beyond renames. + +--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. + +[\--] <path>...:: + Show only commits that affect any of the specified paths. To + prevent confusion with options and branch names, paths may need + to be prefixed with "\-- " to separate them from options or + refnames. + + +include::rev-list-options.txt[] + +include::pretty-formats.txt[] + +include::diff-generate-patch.txt[] + +Examples +-------- +git log --no-merges:: + + Show the whole commit history, but skip any merges + +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 + +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 + 'gitk' + +git log --name-status release..test:: + + Show the commits that are in the "test" branch but not yet + in the "release" branch, along with the list of paths + each commit modifies. + +git log --follow builtin-rev-list.c:: + + Shows the commits that changed builtin-rev-list.c, including + those commits that occurred before the file was given its + present name. + +Discussion +---------- + +include::i18n.txt[] + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-lost-found.txt b/Documentation/git-lost-found.txt new file mode 100644 index 0000000000..602b8d5d4d --- /dev/null +++ b/Documentation/git-lost-found.txt @@ -0,0 +1,81 @@ +git-lost-found(1) +================= + +NAME +---- +git-lost-found - Recover lost refs that luckily have not yet been pruned + +SYNOPSIS +-------- +'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 +------------ + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt new file mode 100644 index 0000000000..625723e41f --- /dev/null +++ b/Documentation/git-ls-files.txt @@ -0,0 +1,207 @@ +git-ls-files(1) +=============== + +NAME +---- +git-ls-files - Show information about files in the index and the working tree + + +SYNOPSIS +-------- +[verse] +'git ls-files' [-z] [-t] [-v] + (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])\* + (-[c|d|o|i|s|u|k|m])\* + [-x <pattern>|--exclude=<pattern>] + [-X <file>|--exclude-from=<file>] + [--exclude-per-directory=<file>] + [--exclude-standard] + [--error-unmatch] [--with-tree=<tree-ish>] + [--full-name] [--abbrev] [--] [<file>]\* + +DESCRIPTION +----------- +This merges the file listing in the directory cache index with the +actual working directory list, and shows different combinations of the +two. + +One or more of the options below may be used to determine the files +shown: + +OPTIONS +------- +-c:: +--cached:: + Show cached files in the output (default) + +-d:: +--deleted:: + Show deleted files in the output + +-m:: +--modified:: + Show modified files in the output + +-o:: +--others:: + Show other (i.e. untracked) files in the output + +-i:: +--ignored:: + Show only ignored files in the output. When showing files in the + index, print only those matched by an exclude pattern. When + showing "other" files, show only those matched by an exclude + pattern. + +-s:: +--stage:: + Show staged contents' object name, mode bits and stage number in the output. + +--directory:: + If a whole directory is classified as "other", show just its + name (with a trailing slash) and not its whole contents. + +--no-empty-directory:: + Do not list empty directories. Has no effect without --directory. + +-u:: +--unmerged:: + Show unmerged files in the output (forces --stage) + +-k:: +--killed:: + Show files on the filesystem that need to be removed due + to file/directory conflicts for checkout-index to + succeed. + +-z:: + \0 line termination on output. + +-x <pattern>:: +--exclude=<pattern>:: + Skips files matching pattern. + Note that pattern is a shell wildcard pattern. + +-X <file>:: +--exclude-from=<file>:: + exclude patterns are read from <file>; 1 per line. + +--exclude-per-directory=<file>:: + read additional exclude patterns that apply only to the + directory and its subdirectories in <file>. + +--exclude-standard:: + Add the standard git exclusions: .git/info/exclude, .gitignore + in each directory, and the user's global exclusion file. + +--error-unmatch:: + If any <file> does not appear in the index, treat this as an + error (return 1). + +--with-tree=<tree-ish>:: + When using --error-unmatch to expand the user supplied + <file> (i.e. path pattern) arguments to paths, pretend + that paths which were removed in the index since the + named <tree-ish> are still present. Using this option + with `-s` or `-u` options does not make any sense. + +-t:: + Identify the file status with the following tags (followed by + a space) at the start of each line: + H:: cached + M:: unmerged + R:: removed/deleted + C:: modified/changed + K:: to be killed + ?:: other + +-v:: + Similar to `-t`, but use lowercase letters for files + that are marked as 'assume unchanged' (see + linkgit:git-update-index[1]). + +--full-name:: + When run from a subdirectory, the command usually + outputs paths relative to the current directory. This + option forces paths to be output relative to the project + top directory. + +--abbrev[=<n>]:: + Instead of showing the full 40-byte hexadecimal object + lines, show only a partial prefix. + Non default number of digits can be specified with --abbrev=<n>. + +\--:: + Do not interpret any more arguments as options. + +<file>:: + Files to show. If no files are given all files which match the other + specified criteria are shown. + +Output +------ +show files just outputs the filename unless '--stage' is specified in +which case it outputs: + + [<tag> ]<mode> <object> <stage> <file> + +'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, +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 +path. (see linkgit:git-read-tree[1] for more information on state) + +When `-z` option is not used, TAB, LF, and backslash characters +in pathnames are represented as `\t`, `\n`, and `\\`, +respectively. + + +Exclude Patterns +---------------- + +'git-ls-files' can use a list of "exclude patterns" when +traversing the directory tree and finding files to show when the +flags --others or --ignored are specified. linkgit:gitignore[5] +specifies the format of exclude patterns. + +These exclude patterns come from these places, in order: + + 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 + file containing a list of patterns. Patterns are ordered + in the same order they appear in the file. + + 3. 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 + same order they appear in the files. + +A pattern specified on the command line with --exclude or read +from the file specified with --exclude-from is relative to the +top of the directory tree. A pattern read from a file specified +by --exclude-per-directory is relative to the directory that the +pattern file appears in. + +SEE ALSO +-------- +linkgit:git-read-tree[1], linkgit:gitignore[5] + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano, Josh Triplett, and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt new file mode 100644 index 0000000000..abe7bf9ff9 --- /dev/null +++ b/Documentation/git-ls-remote.txt @@ -0,0 +1,76 @@ +git-ls-remote(1) +================ + +NAME +---- +git-ls-remote - List references in a remote repository + + +SYNOPSIS +-------- +[verse] +'git ls-remote' [--heads] [--tags] [-u <exec> | --upload-pack <exec>] + <repository> <refs>... + +DESCRIPTION +----------- +Displays references available in a remote repository along with the associated +commit IDs. + + +OPTIONS +------- +-h:: +--heads:: +-t:: +--tags:: + 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. + +-u <exec>:: +--upload-pack=<exec>:: + Specify the full path of 'git-upload-pack' on the remote + host. This allows listing references from repositories accessed via + SSH and where the SSH daemon does not use the PATH configured by the + user. + +<repository>:: + Location of the repository. The shorthand defined in + $GIT_DIR/branches/ can be used. Use "." (dot) to list references in + the local repository. + +<refs>...:: + When unspecified, all references, after filtering done + with --heads and --tags, are shown. When <refs>... are + specified, only references matching the given patterns + are displayed. + +EXAMPLES +-------- + + $ git ls-remote --tags ./. + d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99 + f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1 + 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3 + c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2 + 0918385dbd9656cab0d1d81ba7453d49bbc16250 refs/tags/junio-gpg-pub + $ 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\* + d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99 + f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1 + c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2 + 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3 + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt new file mode 100644 index 0000000000..c3fdccb4c2 --- /dev/null +++ b/Documentation/git-ls-tree.txt @@ -0,0 +1,112 @@ +git-ls-tree(1) +============== + +NAME +---- +git-ls-tree - List the contents of a tree object + + +SYNOPSIS +-------- +[verse] +'git ls-tree' [-d] [-r] [-t] [-l] [-z] + [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev=[<n>]] + <tree-ish> [paths...] + +DESCRIPTION +----------- +Lists the contents of a given tree object, like what "/bin/ls -a" does +in the current working directory. Note that: + + - the behaviour is slightly different from that of "/bin/ls" in that the + 'paths' denote just a list of patterns to match, e.g. so specifying + directory name (without '-r') will behave differently, and order of the + arguments does not matter. + + - the behaviour is similar to that of "/bin/ls" in that the 'paths' is + taken as relative to the current working directory. E.g. when you are + in a directory 'sub' that has a directory 'dir', you can run 'git + ls-tree -r HEAD dir' to list the contents of the tree (that is + 'sub/dir' in 'HEAD'). You don't want to give a tree that is not at the + root level (e.g. 'git ls-tree -r HEAD:sub dir') in this case, as that + would result in asking for 'sub/sub/dir' in the 'HEAD' commit. + However, the current working directory can be ignored by passing + --full-tree option. + +OPTIONS +------- +<tree-ish>:: + Id of a tree-ish. + +-d:: + Show only the named tree entry itself, not its children. + +-r:: + Recurse into sub-trees. + +-t:: + Show tree entries even when going to recurse them. Has no effect + if '-r' was not passed. '-d' implies '-t'. + +-l:: +--long:: + Show object size of blob (file) entries. + +-z:: + \0 line termination on output. + +--name-only:: +--name-status:: + List only filenames (instead of the "long" output), one per line. + +--abbrev[=<n>]:: + Instead of showing the full 40-byte hexadecimal object + lines, show only a partial prefix. + Non default number of digits can be specified with --abbrev=<n>. + +--full-name:: + Instead of showing the path names relative to the current working + directory, show the full path names. + +--full-tree:: + Do not limit the listing to the current working directory. + Implies --full-name. + +paths:: + When paths are given, show them (note that this isn't really raw + pathnames, but rather a list of patterns to match). Otherwise + implicitly uses the root level of the tree as the sole path argument. + + +Output Format +------------- + <mode> SP <type> SP <object> TAB <file> + +Unless the `-z` option is used, TAB, LF, and backslash characters +in pathnames are represented as `\t`, `\n`, and `\\`, respectively. +This output format is compatible with what '--index-info --stdin' of +'git update-index' expects. + +When the `-l` option is used, format changes to + + <mode> SP <type> SP <object> SP <object size> TAB <file> + +Object size identified by <object> is given in bytes, and right-justified +with minimum width of 7 characters. Object size is given only for blobs +(file) entries; for other entries `-` character is used in place of size. + + +Author +------ +Written by Petr Baudis <pasky@suse.cz> +Completely rewritten from scratch by Junio C Hamano <gitster@pobox.com>, +another major rewrite by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list +<git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt new file mode 100644 index 0000000000..b81ac98cf0 --- /dev/null +++ b/Documentation/git-mailinfo.txt @@ -0,0 +1,96 @@ +git-mailinfo(1) +=============== + +NAME +---- +git-mailinfo - Extracts patch and authorship from a single e-mail message + + +SYNOPSIS +-------- +'git mailinfo' [-k|-b] [-u | --encoding=<encoding> | -n] [--scissors] <msg> <patch> + + +DESCRIPTION +----------- +Reads a single e-mail message from the standard input, and +writes the commit log message in <msg> file, and the patches in +<patch> file. The author name, e-mail and e-mail subject are +written out to the standard output to be used by 'git-am' +to create a commit. It is usually not necessary to use this +command directly. See linkgit:git-am[1] instead. + + +OPTIONS +------- +-k:: + Usually the program 'cleans up' the Subject: header line + to extract the title line for the commit log message, + among which (1) remove 'Re:' or 're:', (2) leading + whitespaces, (3) '[' up to ']', typically '[PATCH]', and + then prepends "[PATCH] ". This flag forbids this + munging, and is most useful when used to read back + 'git-format-patch -k' output. + +-b:: + When -k is not in effect, all leading strings bracketed with '[' + and ']' pairs are stripped. This option limits the stripping to + only the pairs whose bracketed string contains the word "PATCH". + +-u:: + The commit log message, author name and author email are + taken from the e-mail, and after minimally decoding MIME + transfer encoding, re-coded in UTF-8 by transliterating + them. This used to be optional but now it is the default. ++ +Note that the patch is always used as-is without charset +conversion, even with this flag. + +--encoding=<encoding>:: + Similar to -u but if the local convention is different + from what is specified by i18n.commitencoding, this flag + can be used to override it. + +-n:: + Disable all charset re-coding of the metadata. + +--scissors:: + Remove everything in body before a scissors line. A line that + mainly consists of scissors (either ">8" or "8<") and perforation + (dash "-") marks is called a scissors line, and is used to request + the reader to cut the message at that line. If such a line + appears in the body of the message before the patch, everything + before it (including the scissors line itself) is ignored when + this option is used. ++ +This is useful if you want to begin your message in a discussion thread +with comments and suggestions on the message you are responding to, and to +conclude it with a patch submission, separating the discussion and the +beginning of the proposed commit log message with a scissors line. ++ +This can enabled by default with the configuration option mailinfo.scissors. + +--no-scissors:: + Ignore scissors lines. Useful for overriding mailinfo.scissors settings. + +<msg>:: + The commit log message extracted from e-mail, usually + except the title line which comes from e-mail Subject. + +<patch>:: + The patch extracted from e-mail. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> and +Junio C Hamano <gitster@pobox.com> + + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt new file mode 100644 index 0000000000..5cc94ec53d --- /dev/null +++ b/Documentation/git-mailsplit.txt @@ -0,0 +1,58 @@ +git-mailsplit(1) +================ + +NAME +---- +git-mailsplit - Simple UNIX mbox splitter program + +SYNOPSIS +-------- +'git mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>|<Maildir>...] + +DESCRIPTION +----------- +Splits a mbox file or a Maildir into a list of files: "0001" "0002" .. in the +specified directory so you can process them further from there. + +IMPORTANT: Maildir splitting relies upon filenames being sorted to output +patches in the correct order. + +OPTIONS +------- +<mbox>:: + Mbox file to split. If not given, the mbox is read from + the standard input. + +<Maildir>:: + Root of the Maildir to split. This directory should contain the cur, tmp + and new subdirectories. + +-o<directory>:: + Directory in which to place the individual messages. + +-b:: + If any file doesn't begin with a From line, assume it is a + single mail message instead of signaling error. + +-d<prec>:: + Instead of the default 4 digits with leading zeros, + different precision can be specified for the generated + filenames. + +-f<nn>:: + Skip the first <nn> numbers, for example if -f3 is specified, + start the numbering with 0004. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> +and Junio C Hamano <gitster@pobox.com> + + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt new file mode 100644 index 0000000000..ce5b369985 --- /dev/null +++ b/Documentation/git-merge-base.txt @@ -0,0 +1,101 @@ +git-merge-base(1) +================= + +NAME +---- +git-merge-base - Find as good common ancestors as possible for a merge + + +SYNOPSIS +-------- +'git merge-base' [-a|--all] <commit> <commit>... + +DESCRIPTION +----------- + +'git merge-base' finds best common ancestor(s) between two commits to use +in a three-way merge. One common ancestor is 'better' than another common +ancestor if the latter is an ancestor of the former. A common ancestor +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. + +Among the two commits to compute the merge base from, one is specified by +the first commit argument on the command line; the other commit is a +(possibly hypothetical) commit that is a merge across all the remaining +commits on the command line. As the most common special case, specifying only +two commits on the command line means computing the merge base between +the given two commits. + +As a consequence, the 'merge base' is not necessarily contained in each of the +commit arguments if more than two commits are specified. This is different +from linkgit:git-show-branch[1] when used with the `--merge-base` option. + +OPTIONS +------- +-a:: +--all:: + Output all merge bases for the commits, instead of just one. + +DISCUSSION +---------- + +Given two commits 'A' and 'B', `git merge-base A B` will output a commit +which is reachable from both 'A' and 'B' through the parent relationship. + +For example, with this topology: + + o---o---o---B + / + ---o---1---o---o---o---A + +the merge base between 'A' and 'B' is '1'. + +Given three commits 'A', 'B' and 'C', `git merge-base A B C` will compute the +merge base between 'A' and a hypothetical commit 'M', which is a merge +between 'B' and 'C'. For example, with this topology: + + o---o---o---o---C + / + / o---o---o---B + / / + ---2---1---o---o---o---A + +the result of `git merge-base A B C` is '1'. This is because the +equivalent topology with a merge commit 'M' between 'B' and 'C' is: + + + o---o---o---o---o + / \ + / o---o---o---o---M + / / + ---2---1---o---o---o---A + +and the result of `git merge-base A M` is '1'. Commit '2' is also a +common ancestor between 'A' and 'M', but '1' is a better common ancestor, +because '2' is an ancestor of '1'. Hence, '2' is not a merge base. + +When the history involves criss-cross merges, there can be more than one +'best' common ancestor for two commits. For example, with this topology: + + ---1---o---A + \ / + X + / \ + ---2---o---o---B + +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. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt new file mode 100644 index 0000000000..303537357b --- /dev/null +++ b/Documentation/git-merge-file.txt @@ -0,0 +1,92 @@ +git-merge-file(1) +================= + +NAME +---- +git-merge-file - Run a three-way file merge + + +SYNOPSIS +-------- +[verse] +'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]] + [-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file> + + +DESCRIPTION +----------- +'git-merge-file' incorporates all changes that lead from the `<base-file>` +to `<other-file>` into `<current-file>`. The result ordinarily goes into +`<current-file>`. 'git-merge-file' is useful for combining separate changes +to an original. Suppose `<base-file>` is the original, and both +`<current-file>` and `<other-file>` are modifications of `<base-file>`, +then 'git-merge-file' combines both changes. + +A conflict occurs if both `<current-file>` and `<other-file>` have changes +in a common segment of lines. If a conflict is found, 'git-merge-file' +normally outputs a warning and brackets the conflict with lines containing +<<<<<<< and >>>>>>> markers. A typical conflict will look like this: + + <<<<<<< A + lines in file A + ======= + lines in file B + >>>>>>> B + +If there are conflicts, the user should edit the result and delete one of +the alternatives. + +The exit value of this program is negative on error, and the number of +conflicts otherwise. If the merge was clean, the exit value is 0. + +'git-merge-file' is designed to be a minimal clone of RCS 'merge'; that is, it +implements all of RCS 'merge''s functionality which is needed by +linkgit:git[1]. + + +OPTIONS +------- + +-L <label>:: + This option may be given up to three times, and + specifies labels to be used in place of the + corresponding file names in conflict reports. That is, + `git merge-file -L x -L y -L z a b c` generates output that + looks like it came from files x, y and z instead of + from files a, b and c. + +-p:: + Send results to standard output instead of overwriting + `<current-file>`. + +-q:: + Quiet; do not warn about conflicts. + + +EXAMPLES +-------- + +git merge-file README.my README README.upstream:: + + combines the changes of README.my and README.upstream since README, + tries to merge them and writes the result into README.my. + +git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345:: + + merges tmp/a123 and tmp/c345 with the base tmp/b234, but uses labels + `a` and `c` instead of `tmp/a123` and `tmp/c345`. + + +Author +------ +Written by Johannes Schindelin <johannes.schindelin@gmx.de> + + +Documentation +-------------- +Documentation by Johannes Schindelin and the git-list <git@vger.kernel.org>, +with parts copied from the original documentation of RCS 'merge'. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt new file mode 100644 index 0000000000..123e6d024a --- /dev/null +++ b/Documentation/git-merge-index.txt @@ -0,0 +1,87 @@ +git-merge-index(1) +================== + +NAME +---- +git-merge-index - Run a merge for files needing merging + + +SYNOPSIS +-------- +'git merge-index' [-o] [-q] <merge-program> (-a | [--] <file>\*) + +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 +argument if no file), and <file> as argument 4. File modes for the three +files are passed as arguments 5, 6 and 7. + +OPTIONS +------- +\--:: + Do not interpret any more arguments as options. + +-a:: + Run merge against all files in the index that need merging. + +-o:: + Instead of stopping at the first failed merge, do all of them + in one shot - continue with merging even when previous merges + returned errors, and only return the error code after all the + merges. + +-q:: + Do not complain about a failed merge program (a merge program + failure usually indicates conflicts during the merge). This is for + porcelains which might want to emit custom messages. + +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 +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 +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. + +Examples: + + torvalds@ppc970:~/merge-test> git merge-index cat MM + This is MM from the original tree. # original + This is modified MM in the branch A. # merge1 + This is modified MM in the branch B. # merge2 + This is modified MM in the branch B. # current contents + +or + + torvalds@ppc970:~/merge-test> git merge-index cat AA MM + cat: : No such file or directory + This is added AA in the branch A. + This is added AA in the branch B. + This is added AA in the branch B. + fatal: merge program failed + +where the latter example shows how 'git-merge-index' will stop trying to +merge once anything has returned an error (i.e., `cat` returned an error +for the AA file, because it didn't exist in the original, and thus +'git-merge-index' didn't even try to merge the MM thing). + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> +One-shot merge by Petr Baudis <pasky@ucw.cz> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-merge-one-file.txt b/Documentation/git-merge-one-file.txt new file mode 100644 index 0000000000..dc8a96adb0 --- /dev/null +++ b/Documentation/git-merge-one-file.txt @@ -0,0 +1,29 @@ +git-merge-one-file(1) +===================== + +NAME +---- +git-merge-one-file - The standard helper program to use with git-merge-index + + +SYNOPSIS +-------- +'git-merge-one-file' + +DESCRIPTION +----------- +This is the standard helper program to use with 'git-merge-index' +to resolve a merge after the trivial merge done with 'git-read-tree -m'. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org>, +Junio C Hamano <gitster@pobox.com> and Petr Baudis <pasky@suse.cz>. + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt new file mode 100644 index 0000000000..f869a7f00f --- /dev/null +++ b/Documentation/git-merge-tree.txt @@ -0,0 +1,36 @@ +git-merge-tree(1) +================= + +NAME +---- +git-merge-tree - Show three-way merge without touching index + + +SYNOPSIS +-------- +'git merge-tree' <base-tree> <branch1> <branch2> + +DESCRIPTION +----------- +Reads three treeish, 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 +standard output. + +This is meant to be used by higher level scripts to compute +merge results outside of the index, and stuff the results back into the +index. For this reason, the output from the command omits +entries that match the <branch1> tree. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt new file mode 100644 index 0000000000..e886c2ef54 --- /dev/null +++ b/Documentation/git-merge.txt @@ -0,0 +1,268 @@ +git-merge(1) +============ + +NAME +---- +git-merge - Join two or more development histories together + + +SYNOPSIS +-------- +[verse] +'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]... + [-m <msg>] <remote>... +'git merge' <msg> HEAD <remote>... + +DESCRIPTION +----------- +This is the top-level interface to the merge machinery +which drives multiple merge strategy scripts. + +The second syntax (<msg> `HEAD` <remote>) is supported for +historical reasons. Do not use it from the command line or in +new scripts. It is the same as `git merge -m <msg> <remote>`. + + +OPTIONS +------- +include::merge-options.txt[] + +-m <msg>:: + Set the commit message to be used for the merge commit (in + case one is created). The 'git fmt-merge-msg' command can be + used to give a good default for automated 'git merge' + invocations. + +<remote>...:: + Other branch heads to merge into our branch. You need at + least one <remote>. Specifying more than one <remote> + obviously means you are trying an Octopus. + +include::merge-strategies.txt[] + + +If you tried a merge which resulted in complex conflicts and +want to start over, you can recover with 'git-reset'. + +CONFIGURATION +------------- +include::merge-config.txt[] + +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. + +HOW MERGE WORKS +--------------- + +A merge is always between the current `HEAD` and one or more +commits (usually, branch head or tag), and the index file must +match the tree of `HEAD` commit (i.e. the contents of the last commit) +when it starts out. In other words, `git diff --cached HEAD` must +report no changes. (One exception is when the changed index +entries are already in the same state that would result from +the merge anyway.) + +Three kinds of merge can happen: + +* The merged commit is already contained in `HEAD`. This is the + simplest case, called "Already up-to-date." + +* `HEAD` is already contained in the merged commit. This is the + most common case especially when invoked from 'git pull': + you are tracking an upstream repository, have committed no local + changes and now you want to update to a newer upstream revision. + Your `HEAD` (and the index) is updated to point at the merged + commit, without creating an extra merge commit. This is + called "Fast-forward". + +* Both the merged commit and `HEAD` are independent and must be + tied together by a merge commit that has both of them as its parents. + The rest of this section describes this "True merge" case. + +The chosen merge strategy merges the two commits into a single +new source tree. +When things merge cleanly, this is what happens: + +1. The results are updated both in the index file and in your + working tree; +2. Index file is written out as a tree; +3. The tree gets committed; and +4. The `HEAD` pointer gets advanced. + +Because of 2., we require that the original state of the index +file matches exactly the current `HEAD` commit; otherwise we +will write out your local changes already registered in your +index file along with the merge result, which is not good. +Because 1. involves only those paths differing between your +branch and the remote branch you are pulling from during the +merge (which is typically a fraction of the whole tree), you can +have local modifications in your working tree as long as they do +not overlap with what the merge updates. + +When there are conflicts, the following happens: + +1. `HEAD` stays the same. + +2. Cleanly merged paths are updated both in the index file and + in your working tree. + +3. For conflicting paths, the index file records up to three + versions; stage1 stores the version from the common ancestor, + stage2 from `HEAD`, and stage3 from the remote branch (you + can inspect the stages with `git ls-files -u`). The working + tree files contain the result of the "merge" program; i.e. 3-way + merge results with familiar conflict markers `<<< === >>>`. + +4. No other changes are done. In particular, the local + modifications you had before you started merge will stay the + same and the index entries for them stay as they were, + i.e. matching `HEAD`. + +HOW CONFLICTS ARE PRESENTED +--------------------------- + +During a merge, the working tree files are updated to reflect the result +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 +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 +from the RCS suite to present such a conflicted hunk, like this: + +------------ +Here are lines that are either unchanged from the common +ancestor, or cleanly resolved because only one side changed. +<<<<<<< yours:sample.txt +Conflict resolution is hard; +let's go shopping. +======= +Git makes conflict resolution easy. +>>>>>>> theirs:sample.txt +And here is another line that is cleanly resolved or unmodified. +------------ + +The area where a pair of conflicting changes happened is marked with markers +`<<<<<<<`, `=======`, and `>>>>>>>`. The part before the `=======` +is typically your side, and the part afterwards is typically their side. + +The default format does not show what the original said in the conflicting +area. You cannot tell how many lines are deleted and replaced with +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" +configuration variable to "diff3". In "diff3" style, the above conflict +may look like this: + +------------ +Here are lines that are either unchanged from the common +ancestor, or cleanly resolved because only one side changed. +<<<<<<< yours:sample.txt +Conflict resolution is hard; +let's go shopping. +||||||| +Conflict resolution is hard. +======= +Git makes conflict resolution easy. +>>>>>>> theirs:sample.txt +And here is another line that is cleanly resolved or unmodified. +------------ + +In addition to the `<<<<<<<`, `=======`, and `>>>>>>>` markers, it uses +another `|||||||` marker that is followed by the original text. You can +tell that the original just stated a fact, and your side simply gave in to +that statement and gave up, while the other side tried to have a more +positive attitude. You can sometimes come up with a better resolution by +viewing the original. + + +HOW TO RESOLVE CONFLICTS +------------------------ + +After seeing a conflict, you can do two things: + + * Decide not to merge. The only clean-ups you need are to reset + the index file to the `HEAD` commit to reverse 2. and to clean + up working tree changes made by 2. and 3.; 'git-reset --hard' can + be used for this. + + * Resolve the conflicts. Git will mark the conflicts in + the working tree. Edit the files into shape and + 'git-add' them to the index. Use 'git-commit' to seal the deal. + +You can work through the conflict with a number of tools: + + * Use a mergetool. 'git mergetool' to launch a graphical + mergetool which will work you through the merge. + + * Look at the diffs. 'git diff' will show a three-way diff, + highlighting changes from both the HEAD and remote versions. + + * Look at the diffs on their own. 'git log --merge -p <path>' + will show diffs first for the HEAD version and then the + remote version. + + * Look at the originals. 'git show :1:filename' shows the + common ancestor, 'git show :2:filename' shows the HEAD + version and 'git show :3:filename' shows the remote version. + + +EXAMPLES +-------- + +* Merge branches `fixes` and `enhancements` on top of + the current branch, making an octopus merge: ++ +------------------------------------------------ +$ git merge fixes enhancements +------------------------------------------------ + +* Merge branch `obsolete` into the current branch, using `ours` + merge strategy: ++ +------------------------------------------------ +$ git merge -s ours obsolete +------------------------------------------------ + +* Merge branch `maint` into the current branch, but do not make + a new commit automatically: ++ +------------------------------------------------ +$ git merge --no-commit maint +------------------------------------------------ ++ +This can be used when you want to include further changes to the +merge, or want to write your own merge commit message. ++ +You should refrain from abusing this option to sneak substantial +changes into a merge commit. Small fixups like bumping +release/version name would be acceptable. + + +SEE ALSO +-------- +linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1], +linkgit:gitattributes[5], +linkgit:git-reset[1], +linkgit:git-diff[1], linkgit:git-ls-files[1], +linkgit:git-add[1], linkgit:git-rm[1], +linkgit:git-mergetool[1] + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-mergetool--lib.txt b/Documentation/git-mergetool--lib.txt new file mode 100644 index 0000000000..78eb03f0ae --- /dev/null +++ b/Documentation/git-mergetool--lib.txt @@ -0,0 +1,54 @@ +git-mergetool--lib(1) +===================== + +NAME +---- +git-mergetool--lib - Common git merge tool shell scriptlets + +SYNOPSIS +-------- +'TOOL_MODE=(diff|merge) . "$(git --exec-path)/git-mergetool--lib"' + +DESCRIPTION +----------- + +This is not a command the end user would want to run. Ever. +This documentation is meant for people who are studying the +Porcelain-ish scripts and/or are writing new ones. + +The 'git-mergetool--lib' scriptlet is designed to be sourced (using +`.`) by other shell scripts to set up functions for working +with git merge tools. + +Before sourcing 'git-mergetool--lib', your script must set `TOOL_MODE` +to define the operation mode for the functions listed below. +'diff' and 'merge' are valid values. + +FUNCTIONS +--------- +get_merge_tool:: + returns a merge tool. + +get_merge_tool_cmd:: + returns the custom command for a merge tool. + +get_merge_tool_path:: + returns the custom path for a merge tool. + +run_merge_tool:: + launches a merge tool given the tool name and a true/false + flag to indicate whether a merge base is present. + '$MERGED', '$LOCAL', '$REMOTE', and '$BASE' must be defined + for use by the merge tool. + +Author +------ +Written by David Aguilar <davvid@gmail.com> + +Documentation +-------------- +Documentation by David Aguilar and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt new file mode 100644 index 0000000000..4a6f7f3a2d --- /dev/null +++ b/Documentation/git-mergetool.txt @@ -0,0 +1,85 @@ +git-mergetool(1) +================ + +NAME +---- +git-mergetool - Run merge conflict resolution tools to resolve merge conflicts + +SYNOPSIS +-------- +'git mergetool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<file>]... + +DESCRIPTION +----------- + +Use `git mergetool` to run one of several merge utilities to resolve +merge conflicts. It is typically run after 'git-merge'. + +If one or more <file> parameters are given, the merge tool program will +be run to resolve differences on each file. If no <file> names are +specified, 'git-mergetool' will run the merge tool program on every file +with merge conflicts. + +OPTIONS +------- +-t <tool>:: +--tool=<tool>:: + Use the merge resolution program specified by <tool>. + Valid merge tools are: + kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, + diffuse, tortoisemerge, opendiff, p4merge and araxis. ++ +If a merge resolution program is not specified, 'git-mergetool' +will use the configuration variable `merge.tool`. If the +configuration variable `merge.tool` is not set, 'git-mergetool' +will pick a suitable default. ++ +You can explicitly provide a full path to the tool by setting the +configuration variable `mergetool.<tool>.path`. For example, you +can configure the absolute path to kdiff3 by setting +`mergetool.kdiff3.path`. Otherwise, 'git-mergetool' assumes the +tool is available in PATH. ++ +Instead of running one of the known merge tool programs, +'git-mergetool' can be customized to run an alternative program +by specifying the command line to invoke in a configuration +variable `mergetool.<tool>.cmd`. ++ +When 'git-mergetool' is invoked with this tool (either through the +`-t` or `--tool` option or the `merge.tool` configuration +variable) the configured command line will be invoked with `$BASE` +set to the name of a temporary file containing the common base for +the merge, if available; `$LOCAL` set to the name of a temporary +file containing the contents of the file on the current branch; +`$REMOTE` set to the name of a temporary file containing the +contents of the file to be merged, and `$MERGED` set to the name +of the file to which the merge tool should write the result of the +merge resolution. ++ +If the custom merge tool correctly indicates the success of a +merge resolution with its exit code, then the configuration +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. + +-y:: +--no-prompt:: + Don't prompt before each invocation of the merge resolution + program. + +--prompt:: + Prompt before each invocation of the merge resolution program. + This is the default behaviour; the option is provided to + override any configuration settings. + +Author +------ +Written by Theodore Y Ts'o <tytso@mit.edu> + +Documentation +-------------- +Documentation by Theodore Y Ts'o. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-mktag.txt b/Documentation/git-mktag.txt new file mode 100644 index 0000000000..8bcc11443d --- /dev/null +++ b/Documentation/git-mktag.txt @@ -0,0 +1,46 @@ +git-mktag(1) +============ + +NAME +---- +git-mktag - Creates a tag object + + +SYNOPSIS +-------- +'git mktag' < signature_file + +DESCRIPTION +----------- +Reads a tag contents on standard input and creates a tag object +that can also be used to sign other objects. + +The output is the new tag's <object> identifier. + +Tag Format +---------- +A tag signature file has a very simple fixed format: four lines of + + object <sha1> + type <typename> + tag <tagname> + tagger <tagger> + +followed by some 'optional' free-form message (some tags created +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 +care about, but that can be verified with gpg. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-mktree.txt b/Documentation/git-mktree.txt new file mode 100644 index 0000000000..81e3326772 --- /dev/null +++ b/Documentation/git-mktree.txt @@ -0,0 +1,47 @@ +git-mktree(1) +============= + +NAME +---- +git-mktree - Build a tree-object from ls-tree formatted text + + +SYNOPSIS +-------- +'git mktree' [-z] [--missing] [--batch] + +DESCRIPTION +----------- +Reads standard input in non-recursive `ls-tree` output format, and creates +a tree object. The order of the tree entries is normalised by mktree so +pre-sorting the input is not required. The object name of the tree object +built is written to the standard output. + +OPTIONS +------- +-z:: + Read the NUL-terminated `ls-tree -z` output instead. + +--missing:: + Allow missing objects. The default behaviour (without this option) + is to verify that each tree entry's sha1 identifies an existing + object. This option has no effect on the treatment of gitlink entries + (aka "submodules") which are always allowed to be missing. + +--batch:: + Allow building of more than one tree object before exiting. Each + tree is separated by as single blank line. The final new-line is + optional. Note - if the '-z' option is used, lines are terminated + with NUL. + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt new file mode 100644 index 0000000000..bdcb58526e --- /dev/null +++ b/Documentation/git-mv.txt @@ -0,0 +1,55 @@ +git-mv(1) +========= + +NAME +---- +git-mv - Move or rename a file, a directory, or a symlink + + +SYNOPSIS +-------- +'git mv' <options>... <args>... + +DESCRIPTION +----------- +This script is used to move or rename a file, directory or symlink. + + git mv [-f] [-n] <source> <destination> + git mv [-f] [-n] [-k] <source> ... <destination directory> + +In the first form, it renames <source>, which must exist and be either +a file, symlink or directory, to <destination>. +In the second form, the last argument has to be an existing +directory; the given sources will be moved into this directory. + +The index is updated after successful completion, but the change must still be +committed. + +OPTIONS +------- +-f:: +--force:: + Force renaming or moving of a file even if the target exists +-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 + file unless '-f' is given. +-n:: +--dry-run:: + Do nothing; only show what would happen + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> +Rewritten by Ryan Anderson <ryan@michonline.com> +Move functionality added by Josef Weidendorfer <Josef.Weidendorfer@gmx.de> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt new file mode 100644 index 0000000000..7ca8a7b48c --- /dev/null +++ b/Documentation/git-name-rev.txt @@ -0,0 +1,84 @@ +git-name-rev(1) +=============== + +NAME +---- +git-name-rev - Find symbolic names for given revs + + +SYNOPSIS +-------- +[verse] +'git name-rev' [--tags] [--refs=<pattern>] + ( --all | --stdin | <committish>... ) + +DESCRIPTION +----------- +Finds symbolic names suitable for human digestion for revisions given in any +format parsable by 'git-rev-parse'. + + +OPTIONS +------- + +--tags:: + Do not use branch names, but only tags to name the commits + +--refs=<pattern>:: + Only use refs whose names match a given shell pattern. + +--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 + +--name-only:: + Instead of printing both the SHA-1 and the name, print only + the name. If given with --tags the usual tag prefix of + "tags/" is also omitted from the name, matching the output + of `git-describe` more closely. + +--no-undefined:: + Die with error code != 0 when a reference is undefined, + instead of printing `undefined`. + +--always:: + Show uniquely abbreviated commit object as fallback. + +EXAMPLE +------- + +Given a commit, find out where it is relative to the local refs. Say somebody +wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a. +Of course, you look into the commit, but that only tells you what happened, but +not the context. + +Enter 'git-name-rev': + +------------ +% git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a +33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99~940 +------------ + +Now you are wiser, because you know that it happened 940 revisions before v0.99. + +Another nice thing you can do is: + +------------ +% git log | git name-rev --stdin +------------ + + +Author +------ +Written by Johannes Schindelin <Johannes.Schindelin@gmx.de> + +Documentation +-------------- +Documentation by Johannes Schindelin. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt new file mode 100644 index 0000000000..94cceb1319 --- /dev/null +++ b/Documentation/git-notes.txt @@ -0,0 +1,60 @@ +git-notes(1) +============ + +NAME +---- +git-notes - Add/inspect commit notes + +SYNOPSIS +-------- +[verse] +'git-notes' (edit [-F <file> | -m <msg>] | show) [commit] + +DESCRIPTION +----------- +This command allows you to add notes to commit messages, without +changing the commit. To discern these notes from the message stored +in the commit object, the notes are indented like the message, after +an unindented line saying "Notes:". + +To disable commit notes, you have to set the config variable +core.notesRef to the empty string. Alternatively, you can set it +to a different ref, something like "refs/notes/bugzilla". This setting +can be overridden by the environment variable "GIT_NOTES_REF". + + +SUBCOMMANDS +----------- + +edit:: + Edit the notes for a given commit (defaults to HEAD). + +show:: + Show the notes for a given commit (defaults to HEAD). + + +OPTIONS +------- +-m <msg>:: + Use the given note message (instead of prompting). + If multiple `-m` (or `-F`) options are given, their + values are concatenated as separate paragraphs. + +-F <file>:: + Take the note message from the given file. Use '-' to + read the note message from the standard input. + If multiple `-F` (or `-m`) options are given, their + values are concatenated as separate paragraphs. + + +Author +------ +Written by Johannes Schindelin <johannes.schindelin@gmx.de> + +Documentation +------------- +Documentation by Johannes Schindelin + +GIT +--- +Part of the linkgit:git[7] suite diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt new file mode 100644 index 0000000000..f54d433d36 --- /dev/null +++ b/Documentation/git-pack-objects.txt @@ -0,0 +1,228 @@ +git-pack-objects(1) +=================== + +NAME +---- +git-pack-objects - Create a packed archive of objects + + +SYNOPSIS +-------- +[verse] +'git pack-objects' [-q | --progress | --all-progress] [--all-progress-implied] + [--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 + + +DESCRIPTION +----------- +Reads list of objects from the standard input, and writes a packed +archive with specified base-name, or to the standard output. + +A packed archive is an efficient way to transfer set of objects +between two repositories, and also is an archival format which +is efficient to access. The packed archive format (.pack) is +designed to be self contained so that it can be unpacked without +any further information, but for fast, random access to the objects +in the pack, a pack index file (.idx) will be generated. + +Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or +any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES) +enables git to read from such an archive. + +The 'git-unpack-objects' command can read the packed archive and +expand the objects contained in the pack into "one-file +one-object" format; this is typically done by the smart-pull +commands when a pack is created on-the-fly for efficient network +transport by their peers. + +In a packed archive, an object is either stored as a compressed +whole, or as a difference from some other object. The latter is +often called a delta. + + +OPTIONS +------- +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 + output of the command. + +--stdout:: + Write the pack contents (what would have been written to + .pack file) out to the standard output. + +--revs:: + Read the revision arguments from the standard input, instead of + individual object names. The revision arguments are processed + 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. + +--unpacked:: + This implies `--revs`. When processing the list of + revision arguments read from the standard input, limit + the objects packed to those that are not already packed. + +--all:: + This implies `--revs`. In addition to the list of + revision arguments read from the standard input, pretend + as if all refs under `$GIT_DIR/refs` are specified to be + included. + +--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. + +--window=[N]:: +--depth=[N]:: + These two options affect how the objects contained in + the pack are stored using delta compression. The + objects are first internally sorted by type, size and + optionally names and compared against the other objects + within --window to see if using delta compression saves + space. --depth limits the maximum delta depth; making + it too deep affects the performance on the unpacker + side, because delta data needs to be applied that many + times to get to the necessary object. + The default value for --window is 10 and --depth is 50. + +--window-memory=[N]:: + This option provides an additional limit on top of `--window`; + the window size will dynamically scale down so as to not take + up more than N bytes in memory. This is useful in + repositories with a mix of large and small objects to not run + out of memory with a large window, but still be able to take + advantage of the large window for the smaller objects. The + size can be suffixed with "k", "m", or "g". + `--window-memory=0` makes memory usage unlimited, which is the + default. + +--max-pack-size=<n>:: + Maximum size of each output packfile, expressed in MiB. + If specified, multiple packfiles may be created. + The default is unlimited, unless the config variable + `pack.packSizeLimit` is set. + +--honor-pack-keep:: + This flag causes an object already in a local pack that + has a .keep file to be ignored, even if it appears in the + standard input. + +--incremental:: + This flag causes an object already in a pack ignored + even if it appears in the standard input. + +--local:: + This flag is similar to `--incremental`; instead of + ignoring all packed objects, it only ignores objects + that are packed and/or not in the local object store + (i.e. borrowed from an alternate). + +--non-empty:: + Only create a packed archive if it would contain at + least one object. + +--progress:: + Progress status is reported on the standard error stream + by default when it is attached to a terminal, unless -q + is specified. This flag forces progress status even if + the standard error stream is not directed to a terminal. + +--all-progress:: + When --stdout is specified then progress report is + displayed during the object count and compression phases + but inhibited during the write-out phase. The reason is + that in some cases the output stream is directly linked + to another command which may wish to display progress + status of its own as it processes incoming pack data. + This flag is like --progress except that it forces progress + report for the write-out phase as well even if --stdout is + used. + +--all-progress-implied:: + This is used to imply --all-progress whenever progress display + is activated. Unlike --all-progress this flag doesn't actually + force any progress display by itself. + +-q:: + This flag makes the command not to report its progress + on the standard error stream. + +--no-reuse-delta:: + When creating a packed archive in a repository that + has existing packs, the command reuses existing deltas. + This sometimes results in a slightly suboptimal pack. + This flag tells the command not to reuse existing deltas + but compute them from scratch. + +--no-reuse-object:: + This flag tells the command not to reuse existing object data at all, + including non deltified object, forcing recompression of everything. + This implies --no-reuse-delta. Useful only in the obscure case where + wholesale enforcement of a different compression level on the + packed data is desired. + +--compression=[N]:: + Specifies compression level for newly-compressed data in the + generated pack. If not specified, pack compression level is + determined first by pack.compression, then by core.compression, + and defaults to -1, the zlib default, if neither is set. + Add --no-reuse-object if you want to force a uniform compression + level on all data no matter the source. + +--delta-base-offset:: + A packed archive can express base object of a delta as + either 20-byte object name or as an offset in the + stream, but older version of git does not 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 + compactness. Depending on the average delta chain + length, this option typically shrinks the resulting + packfile by 3-5 per-cent. + +--threads=<n>:: + Specifies the number of threads to spawn when searching for best + delta matches. This requires that pack-objects 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 set the number of threads accordingly. + +--index-version=<version>[,<offset>]:: + This is intended to be used by the test suite only. It allows + to force the version for the generated pack index, and to force + 64-bit index entries on objects located above the given offset. + +--keep-true-parents:: + With this option, parents that are hidden by grafts are packed + nevertheless. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +------------- +Documentation by Junio C Hamano + +SEE ALSO +-------- +linkgit:git-rev-list[1] +linkgit:git-repack[1] +linkgit:git-prune-packed[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-pack-redundant.txt b/Documentation/git-pack-redundant.txt new file mode 100644 index 0000000000..5f9435e59b --- /dev/null +++ b/Documentation/git-pack-redundant.txt @@ -0,0 +1,57 @@ +git-pack-redundant(1) +===================== + +NAME +---- +git-pack-redundant - Find redundant pack files + + +SYNOPSIS +-------- +'git pack-redundant' [ --verbose ] [ --alt-odb ] < --all | .pack filename ... > + +DESCRIPTION +----------- +This program computes which packs in your repository +are redundant. The output is suitable for piping to +`xargs rm` if you are in the root of the repository. + +'git-pack-redundant' accepts a list of objects on standard input. Any objects +given will be ignored when checking which packs are required. This makes the +following command useful when wanting to remove packs which contain unreachable +objects. + +git fsck --full --unreachable | cut -d ' ' -f3 | \ +git pack-redundant --all | xargs rm + +OPTIONS +------- + + +--all:: + Processes all packs. Any filenames on the command line are ignored. + +--alt-odb:: + Don't require objects present in packs from alternate object + directories to be present in local packs. + +--verbose:: + Outputs some statistics to stderr. Has a small performance penalty. + +Author +------ +Written by Lukas Sandström <lukass@etek.chalmers.se> + +Documentation +-------------- +Documentation by Lukas Sandström <lukass@etek.chalmers.se> + +SEE ALSO +-------- +linkgit:git-pack-objects[1] +linkgit:git-repack[1] +linkgit:git-prune-packed[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-pack-refs.txt b/Documentation/git-pack-refs.txt new file mode 100644 index 0000000000..1ee99c208c --- /dev/null +++ b/Documentation/git-pack-refs.txt @@ -0,0 +1,66 @@ +git-pack-refs(1) +================ + +NAME +---- +git-pack-refs - Pack heads and tags for efficient repository access + +SYNOPSIS +-------- +'git pack-refs' [--all] [--no-prune] + +DESCRIPTION +----------- + +Traditionally, tips of branches and tags (collectively known as +'refs') were stored one file per ref 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 +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, +`$GIT_DIR/packed-refs`. When a ref is missing from the +traditional `$GIT_DIR/refs` 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. + +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 +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, +and the next `pack-refs` (without `--all`) will leave them +unpacked. + + +OPTIONS +------- + +--all:: + +The command by default packs all tags and refs that are already +packed, and leaves other refs +alone. This is because branches are expected to be actively +developed and packing their tips does not help performance. +This option causes branch tips to be packed as well. Useful for +a repository with many branches of historical interests. + +--no-prune:: + +The command usually removes loose refs under `$GIT_DIR/refs` +hierarchy after packing them. This option tells it not to. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-parse-remote.txt b/Documentation/git-parse-remote.txt new file mode 100644 index 0000000000..39d9daa7e0 --- /dev/null +++ b/Documentation/git-parse-remote.txt @@ -0,0 +1,30 @@ +git-parse-remote(1) +=================== + +NAME +---- +git-parse-remote - Routines to help parsing remote repository access parameters + + +SYNOPSIS +-------- +'. "$(git --exec-path)/git-parse-remote"' + +DESCRIPTION +----------- +This script is included in various scripts to supply +routines to parse files under $GIT_DIR/remotes/ and +$GIT_DIR/branches/ and configuration variables that are related +to fetching, pulling and pushing. + +Author +------ +Written by Junio C Hamano. + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt new file mode 100644 index 0000000000..253fc0fc25 --- /dev/null +++ b/Documentation/git-patch-id.txt @@ -0,0 +1,42 @@ +git-patch-id(1) +=============== + +NAME +---- +git-patch-id - Compute unique ID for a patch + +SYNOPSIS +-------- +'git patch-id' < <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. + +IOW, you can use this thing to look for likely duplicate commits. + +When dealing with 'git-diff-tree' output, it takes advantage of +the fact that the patch is prefixed with the object name of the +commit, and outputs two 40-byte hexadecimal strings. The first +string is the patch ID, and the second string is the commit ID. +This can be used to make a mapping from patch ID to commit ID. + +OPTIONS +------- +<patch>:: + The diff to create the ID of. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-peek-remote.txt b/Documentation/git-peek-remote.txt new file mode 100644 index 0000000000..8282a5e82b --- /dev/null +++ b/Documentation/git-peek-remote.txt @@ -0,0 +1,50 @@ +git-peek-remote(1) +================== + +NAME +---- +git-peek-remote - List the references in a remote repository + + +SYNOPSIS +-------- +'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. + + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-prune-packed.txt b/Documentation/git-prune-packed.txt new file mode 100644 index 0000000000..abfc6b6ead --- /dev/null +++ b/Documentation/git-prune-packed.txt @@ -0,0 +1,54 @@ +git-prune-packed(1) +===================== + +NAME +---- +git-prune-packed - Remove extra objects that are already in pack files + + +SYNOPSIS +-------- +'git prune-packed' [-n|--dry-run] [-q|--quiet] + + +DESCRIPTION +----------- +This program searches the `$GIT_OBJECT_DIR` for all objects that currently +exist in a pack file as well as the independent object directories. + +All such extra objects are removed. + +A pack is a collection of objects, individually compressed, with delta +compression applied, stored in a single file, with an associated index file. + +Packs are used to reduce the load on mirror systems, backup engines, +disk storage, etc. + + +OPTIONS +------- +-n:: +--dry-run:: + Don't actually remove any objects, only show those that would have been + removed. + +-q:: +--quiet:: + Squelch the progress indicator. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Ryan Anderson <ryan@michonline.com> + +SEE ALSO +-------- +linkgit:git-pack-objects[1] +linkgit:git-repack[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt new file mode 100644 index 0000000000..da6055d4b8 --- /dev/null +++ b/Documentation/git-prune.txt @@ -0,0 +1,89 @@ +git-prune(1) +============ + +NAME +---- +git-prune - Prune all unreachable objects from the object database + + +SYNOPSIS +-------- +'git-prune' [-n] [-v] [--expire <expire>] [--] [<head>...] + +DESCRIPTION +----------- + +NOTE: In most cases, users should run 'git-gc', which calls +'git-prune'. See the section "NOTES", below. + +This runs 'git-fsck --unreachable' using all the refs +available in `$GIT_DIR/refs`, optionally with additional set of +objects specified on the command line, and prunes all unpacked +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'. + +Note that unreachable, packed objects will remain. If this is +not desired, see linkgit:git-repack[1]. + +OPTIONS +------- + +-n:: + Do not remove anything; just report what it would + remove. + +-v:: + Report all removed objects. + +\--:: + Do not interpret any more arguments as options. + +--expire <time>:: + Only expire loose objects older than <time>. + +<head>...:: + In addition to objects + reachable from any of our references, keep objects + reachable from listed <head>s. + +EXAMPLE +------- + +To prune objects not used by your repository nor another that +borrows from your repository via its +`.git/objects/info/alternates`: + +------------ +$ git prune $(cd ../another && $(git rev-parse --all)) +------------ + +Notes +----- + +In most cases, users will not need to call 'git-prune' directly, but +should instead call 'git-gc', which handles pruning along with +many other housekeeping tasks. + +For a description of which objects are considered for pruning, see +'git-fsck''s --unreachable option. + +SEE ALSO +-------- + +linkgit:git-fsck[1], +linkgit:git-gc[1], +linkgit:git-reflog[1] + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt new file mode 100644 index 0000000000..b93201158f --- /dev/null +++ b/Documentation/git-pull.txt @@ -0,0 +1,172 @@ +git-pull(1) +=========== + +NAME +---- +git-pull - Fetch from and merge with another repository or a local branch + + +SYNOPSIS +-------- +'git pull' <options> <repository> <refspec>... + + +DESCRIPTION +----------- +Runs 'git-fetch' with the given parameters, and calls 'git-merge' +to merge the retrieved head(s) into the current branch. +With `--rebase`, calls 'git-rebase' instead of 'git-merge'. + +Note that you can use `.` (current directory) as the +<repository> to pull from the local repository -- this is useful +when merging local branches into the current branch. + +Also note that options meant for 'git-pull' itself and underlying +'git-merge' must be given before the options meant for 'git-fetch'. + +OPTIONS +------- + +Options related to merging +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +include::merge-options.txt[] + +:git-pull: 1 + +--rebase:: + Instead of a merge, perform a rebase after fetching. If + there is a remote ref for the upstream branch, and this branch + was rebased since last fetched, the rebase uses that information + to avoid rebasing non-local changes. To make this the default + for branch `<name>`, set configuration `branch.<name>.rebase` + to `true`. ++ +[NOTE] +This is a potentially _dangerous_ mode of operation. +It rewrites history, which does not bode well when you +published that history already. Do *not* use this option +unless you have read linkgit:git-rebase[1] carefully. + +--no-rebase:: + Override earlier --rebase. + +Options related to fetching +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +include::fetch-options.txt[] + +include::pull-fetch-param.txt[] + +include::urls-remotes.txt[] + +include::merge-strategies.txt[] + +DEFAULT BEHAVIOUR +----------------- + +Often people use `git pull` without giving any parameter. +Traditionally, this has been equivalent to saying `git pull +origin`. However, when configuration `branch.<name>.remote` is +present while on branch `<name>`, that value is used instead of +`origin`. + +In order to determine what URL to use to fetch from, the value +of the configuration `remote.<origin>.url` is consulted +and if there is not any such variable, the value on `URL: ` line +in `$GIT_DIR/remotes/<origin>` file is used. + +In order to determine what remote branches to fetch (and +optionally store in the tracking branches) when the command is +run without any refspec parameters on the command line, values +of the configuration variable `remote.<origin>.fetch` are +consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>` +file is consulted and its `Pull: ` lines are used. +In addition to the refspec formats described in the OPTIONS +section, you can have a globbing refspec that looks like this: + +------------ +refs/heads/*:refs/remotes/origin/* +------------ + +A globbing refspec must have a non-empty RHS (i.e. must store +what were fetched in tracking branches), and its LHS and RHS +must end with `/*`. The above specifies that all remote +branches are tracked using tracking branches in +`refs/remotes/origin/` hierarchy under the same name. + +The rule to determine which remote branch to merge after +fetching is a bit involved, in order not to break backward +compatibility. + +If explicit refspecs were given on the command +line of `git pull`, they are all merged. + +When no refspec was given on the command line, then `git pull` +uses the refspec from the configuration or +`$GIT_DIR/remotes/<origin>`. In such cases, the following +rules apply: + +. If `branch.<name>.merge` configuration for the current + branch `<name>` exists, that is the name of the branch at the + remote site that is merged. + +. If the refspec is a globbing one, nothing is merged. + +. Otherwise the remote branch of the first refspec is merged. + + +EXAMPLES +-------- + +* Update the remote-tracking branches for the repository + you cloned from, then merge one of them into your + current branch: ++ +------------------------------------------------ +$ git pull, git pull origin +------------------------------------------------ ++ +Normally the branch merged in is the HEAD of the remote repository, +but the choice is determined by the branch.<name>.remote and +branch.<name>.merge options; see linkgit:git-config[1] for details. + +* Merge into the current branch the remote branch `next`: ++ +------------------------------------------------ +$ git pull origin next +------------------------------------------------ ++ +This leaves a copy of `next` temporarily in FETCH_HEAD, but +does not update any remote-tracking branches. Using remote-tracking +branches, the same can be done by invoking fetch and merge: ++ +------------------------------------------------ +$ git fetch origin +$ git merge origin/next +------------------------------------------------ + + +If you tried a pull which resulted in a complex conflicts and +would want to start over, you can recover with 'git-reset'. + + +SEE ALSO +-------- +linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1] + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> +and Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Jon Loeliger, +David Greaves, +Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt new file mode 100644 index 0000000000..52c0538df5 --- /dev/null +++ b/Documentation/git-push.txt @@ -0,0 +1,384 @@ +git-push(1) +=========== + +NAME +---- +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] + [<repository> <refspec>...] + +DESCRIPTION +----------- + +Updates remote refs using local refs, while sending objects +necessary to complete the given refs. + +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]. + + +OPTIONS[[OPTIONS]] +------------------ +<repository>:: + The "remote" repository that is destination of a push + operation. This parameter can be either a URL + (see the section <<URLS,GIT URLS>> below) or the name + of a remote (see the section <<REMOTES,REMOTES>> below). + +<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>. + 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 +`HEAD` (see linkgit:git-rev-parse[1]). ++ +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. ++ +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 +EXAMPLES below for details. ++ +`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`. ++ +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 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). + +--all:: + Instead of naming each ref to push, specifies that all + refs under `$GIT_DIR/refs/heads/` be pushed. + +--mirror:: + Instead of naming each ref to push, specifies that all + refs under `$GIT_DIR/refs/` (which includes but is not + limited to `refs/heads/`, `refs/remotes/`, and `refs/tags/`) + be mirrored to the remote repository. Newly created local + refs will be pushed to the remote end, locally updated refs + will be force updated on the remote end, and deleted refs + will be removed from the remote end. This is the default + if the configuration option `remote.<remote>.mirror` is + set. + +-n:: +--dry-run:: + Do everything except actually send the updates. + +--porcelain:: + Produce machine-readable output. The output status line for each ref + will be tab-separated and sent to stdout instead of stderr. The full + symbolic names of the refs will be given. + +--tags:: + All refs under `$GIT_DIR/refs/tags` are pushed, in + addition to refspecs explicitly listed on the command + line. + +--receive-pack=<git-receive-pack>:: +--exec=<git-receive-pack>:: + Path to the 'git-receive-pack' program on the remote + end. Sometimes useful when pushing to a remote + repository over ssh, and you do not have the program in + a directory on the default $PATH. + +-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 ++ +-------------------------- +git push public #1 +git push --repo=public #2 +-------------------------- ++ +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'. + +--thin:: +--no-thin:: + These options are passed to 'git-send-pack'. Thin + transfer spends extra cycles to minimize the number of + objects to be sent and meant to be used on slower connection. + +-v:: +--verbose:: + Run verbosely. + +-q:: +--quiet:: + Suppress all output, including the listing of updated refs, + unless an error occurs. + +include::urls-remotes.txt[] + +OUTPUT +------ + +The output of "git push" depends on the transport method used; this +section describes the output when pushing over the git protocol (either +locally or via ssh). + +The status of the push is output in tabular form, with each line +representing the status of a single ref. Each line is of the form: + +------------------------------- + <flag> <summary> <from> -> <to> (<reason>) +------------------------------- + +If --porcelain is used, then each line of the output is of the form: + +------------------------------- + <flag> \t <from>:<to> \t <summary> (<reason>) +------------------------------- + +flag:: + A single character indicating the status of the ref. This is + blank for a successfully pushed ref, `!` for a ref that was + rejected or failed to push, and '=' for a ref that was up to + date and did not need pushing (note that the status of up to + date refs is shown only when `git push` is running verbosely). + +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). For a + failed update, more details are given for the failure. + The string `rejected` indicates that git did not try to send the + ref at all (typically because it is not a fast-forward). The + string `remote rejected` indicates that the remote end refused + the update; this rejection is typically caused by a hook on the + remote side. The string `remote failure` indicates that the + remote end did not report the successful update of the ref + (perhaps because of a temporary error on the remote side, a + break in the network connection, or other transient error). + +from:: + The name of the local ref being pushed, minus its + `refs/<type>/` prefix. In the case of deletion, the + name of the local ref is omitted. + +to:: + The name of the remote ref being updated, minus its + `refs/<type>/` prefix. + +reason:: + A human-readable explanation. In the case of successfully pushed + refs, no explanation is needed. For a failed ref, the reason for + failure is described. + +Note about fast-forwards +------------------------ + +When an update changes a branch (or more in general, a ref) that used to +point at commit A to point at another commit B, it is called a +fast-forward update if and only if B is a descendant of A. + +In a fast-forward update from A to B, the set of commits that the original +commit A built on top of is a subset of the commits the new commit B +builds on top of. Hence, it does not lose any history. + +In contrast, a non-fast-forward update will lose history. For example, +suppose you and somebody else started at the same commit X, and you built +a history leading to commit B while the other person built a history +leading to commit A. The history looks like this: + +---------------- + + B + / + ---X---A + +---------------- + +Further suppose that the other person already pushed changes leading to A +back to the original repository 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. + +But if you try to push, you will attempt to update the branch (that +now points at A) with commit B. This does _not_ fast-forward. If you did +so, the changes introduced by commit A will be lost, because everybody +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 +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. + +You can perform "git pull", resolve potential conflicts, and "git push" +the result. A "git pull" will create a merge commit C between commits A +and B. + +---------------- + + B---C + / / + ---X---A + +---------------- + +Updating A with the resulting merge commit will fast-forward and your +push will be accepted. + +Alternatively, you can rebase your change between X and B on top of A, +with "git pull --rebase", and push the result back. The rebase will +create a new commit D that builds the change between X and B on top of +A. + +---------------- + + B D + / / + ---X---A + +---------------- + +Again, updating A with this commit will fast-forward and your push will be +accepted. + +There is another common situation where you may encounter non-fast-forward +rejection when you try to push, and it is possible even when you are +pushing into a repository nobody else pushes into. After you push commit +A yourself (in the first picture in this section), replace it with "git +commit --amend" to produce commit B, and you try to push it out, because +forgot that you have pushed A out already. In such a case, and only if +you are certain that nobody in the meantime fetched your earlier commit A +(and started building on top of it), you can run "git push --force" to +overwrite it. In other words, "git push --force" is a method reserved for +a case where you do mean to lose history. + + +Examples +-------- + +git push:: + Works like `git push <remote>`, where <remote> is the + current branch's remote (or `origin`, if no remote is + configured for the current branch). + +git push origin:: + Without additional configuration, works like + `git push origin :`. ++ +The default behavior of this command when no <refspec> is given can be +configured by setting the `push` option of the remote. ++ +For example, to default to pushing only the current branch to `origin` +use `git config remote.origin.push HEAD`. Any valid <refspec> (like +the ones in the examples below) can be configured as the default for +`git push origin`. + +git push origin ::: + Push "matching" branches to `origin`. See + <refspec> in the <<OPTIONS,OPTIONS>> section above for a + description of "matching" branches. + +git push origin master:: + Find a ref that matches `master` in the source repository + (most likely, it would find `refs/heads/master`), and update + the same ref (e.g. `refs/heads/master`) in `origin` repository + with it. If `master` did not exist remotely, it would be + created. + +git push origin HEAD:: + A handy way to push the current branch to the same name on the + remote. + +git push origin 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 + do the same for `dev` and `satellite/dev`. + +git push origin HEAD:master:: + Push the current branch to the remote ref matching `master` in the + `origin` repository. This form is convenient to push the current + branch without thinking about its local name. + +git push origin master:refs/heads/experimental:: + Create the branch `experimental` in the `origin` repository + by copying the current `master` branch. This form is only + needed to create a new branch or tag in the remote repository when + the local name and the remote name are different; otherwise, + the ref name on its own will work. + +git push origin :experimental:: + Find a ref that matches `experimental` in the `origin` repository + (e.g. `refs/heads/experimental`), and delete it. + +git push origin {plus}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 + following situation, where a fast-forward is not possible: ++ +---- + o---o---o---A---B origin/master + \ + X---Y---Z dev +---- ++ +The above command would change the origin repository to ++ +---- + A---B (unnamed branch) + / + o---o---o---X---Y---Z master +---- ++ +Commits A and B would no longer belong to a branch with a symbolic name, +and so would be unreachable. As such, these commits would be removed by +a `git gc` command on the origin repository. + + +Author +------ +Written by Junio C Hamano <gitster@pobox.com>, later rewritten in C +by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-quiltimport.txt b/Documentation/git-quiltimport.txt new file mode 100644 index 0000000000..579e8d2f3b --- /dev/null +++ b/Documentation/git-quiltimport.txt @@ -0,0 +1,62 @@ +git-quiltimport(1) +================ + +NAME +---- +git-quiltimport - Applies a quilt patchset onto the current branch + + +SYNOPSIS +-------- +[verse] +'git quiltimport' [--dry-run | -n] [--author <author>] [--patches <dir>] + + +DESCRIPTION +----------- +Applies a quilt patchset onto the current git branch, preserving +the patch boundaries, patch order, and patch descriptions present +in the quilt patchset. + +For each patch the code attempts to extract the author from the +patch description. If that fails it falls back to the author +specified with --author. If the --author flag was not given +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. + +OPTIONS +------- + +-n:: +--dry-run:: + Walk through the patches in the series and warn + if we cannot find all of the necessary information to commit + a patch. At the time of this writing only missing author + information is warned about. + +--author Author Name <Author Email>:: + The author name and email address to use when no author + information can be found in the patch description. + +--patches <dir>:: + The directory to find the quilt patches and the + quilt series file. ++ +The default for the patch directory is patches +or the value of the $QUILT_PATCHES environment +variable. + +Author +------ +Written by Eric Biederman <ebiederm@lnxi.com> + +Documentation +-------------- +Documentation by Eric Biederman <ebiederm@lnxi.com> + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt new file mode 100644 index 0000000000..a10ce4ba40 --- /dev/null +++ b/Documentation/git-read-tree.txt @@ -0,0 +1,379 @@ +git-read-tree(1) +================ + +NAME +---- +git-read-tree - Reads tree information into the index + + +SYNOPSIS +-------- +'git read-tree' [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] + [-u [--exclude-per-directory=<gitignore>] | -i]] + [--index-output=<file>] + <tree-ish1> [<tree-ish2> [<tree-ish3>]] + + +DESCRIPTION +----------- +Reads the tree information given by <tree-ish> into the index, +but does not actually *update* any of the files it "caches". (see: +linkgit:git-checkout-index[1]) + +Optionally, it can merge a tree into the index, perform a +fast-forward (i.e. 2-way) merge, or a 3-way merge, with the `-m` +flag. When used with `-m`, the `-u` flag causes it to also update +the files in the work tree with the result of the merge. + +Trivial merges are done by 'git-read-tree' itself. Only conflicting paths +will be in unmerged state when 'git-read-tree' returns. + +OPTIONS +------- +-m:: + Perform a merge, not just a read. The command will + refuse to run if your index file has unmerged entries, + indicating that you have not finished previous merge you + started. + +--reset:: + Same as -m, except that unmerged entries are discarded + instead of failing. + +-u:: + After a successful merge, update the files in the work + tree with the result of the merge. + +-i:: + Usually a merge requires the index file as well as the + files in the working tree are up to date with the + current head commit, in order not to lose local + changes. This flag disables the check with the working + tree and is meant to be used when creating a merge of + trees that are not directly related to the current + working tree status into a temporary index file. + +-v:: + Show the progress of checking files out. + +--trivial:: + Restrict three-way merge by 'git-read-tree' to happen + only if there is no file-level merging required, instead + of resolving merge for trivial cases and leaving + conflicting files unresolved in the index. + +--aggressive:: + Usually a three-way merge by 'git-read-tree' resolves + the merge for really trivial cases and leaves other + cases unresolved in the index, so that Porcelains can + implement different merge policies. This flag makes the + command to resolve a few more cases internally: ++ +* when one side removes a path and the other side leaves the path + unmodified. The resolution is to remove that path. +* when both sides remove a path. The resolution is to remove that path. +* when both sides adds a path identically. The resolution + is to add that path. + +--prefix=<prefix>/:: + Keep the current index contents, and read the contents + of named tree-ish under directory at `<prefix>`. The + original index file cannot have anything at the path + `<prefix>` itself, and have nothing in `<prefix>/` + directory. Note that the `<prefix>/` value must end + with a slash. + +--exclude-per-directory=<gitignore>:: + When running the command with `-u` and `-m` options, the + merge result may need to overwrite paths that are not + tracked in the current branch. The command usually + refuses to proceed with the merge to avoid losing such a + path. However this safety valve sometimes gets in the + way. For example, it often happens that the other + branch added a file that used to be a generated file in + your branch, and the safety valve triggers when you try + to switch to that branch after you ran `make` but before + running `make clean` to remove the generated file. This + option tells the command to read per-directory exclude + file (usually '.gitignore') and allows such an untracked + but explicitly ignored file to be overwritten. + +--index-output=<file>:: + Instead of writing the results out to `$GIT_INDEX_FILE`, + write the resulting index in the named file. While the + command is operating, the original index file is locked + with the same mechanism as usual. The file must allow + to be rename(2)ed into from a temporary file that is + created next to the usual index file; typically this + means it needs to be on the same filesystem as the index + file itself, and you need write permission to the + directories the index file and index output file are + located in. + +<tree-ish#>:: + The id of the tree object(s) to be read/merged. + + +Merging +------- +If `-m` is specified, 'git-read-tree' can perform 3 kinds of +merge, a single tree merge if only 1 tree is given, a +fast-forward merge with 2 trees, or a 3-way merge if 3 trees are +provided. + + +Single Tree Merge +~~~~~~~~~~~~~~~~~ +If only 1 tree is specified, 'git-read-tree' operates as if the user did not +specify `-m`, except that if the original index has an entry for a +given pathname, and the contents of the path matches with the tree +being read, the stat info from the index is used. (In other words, the +index's stat()s take precedence over the merged tree's). + +That means that if you do a `git read-tree -m <newtree>` followed by a +`git checkout-index -f -u -a`, the 'git-checkout-index' only checks out +the stuff that really changed. + +This is used to avoid unnecessary false hits when 'git-diff-files' is +run after 'git-read-tree'. + + +Two Tree Merge +~~~~~~~~~~~~~~ + +Typically, this is invoked as `git read-tree -m $H $M`, where $H +is the head commit of the current repository, and $M is the head +of a foreign tree, which is simply ahead of $H (i.e. we are in a +fast-forward situation). + +When two trees are specified, the user is telling 'git-read-tree' +the following: + + 1. The current index and work tree is derived from $H, but + the user may have local changes in them since $H; + + 2. The user wants to fast-forward to $M. + +In this case, the `git read-tree -m $H $M` command makes sure +that no local change is lost as the result of this "merge". +Here are the "carry forward" rules: + + I (index) H M Result + ------------------------------------------------------- + 0 nothing nothing nothing (does not happen) + 1 nothing nothing exists use M + 2 nothing exists nothing remove path from index + 3 nothing exists exists, use M if "initial checkout" + H == M keep index otherwise + exists fail + H != M + + clean I==H I==M + ------------------ + 4 yes N/A N/A nothing nothing keep index + 5 no N/A N/A nothing nothing keep index + + 6 yes N/A yes nothing exists keep index + 7 no N/A yes nothing exists keep index + 8 yes N/A no nothing exists fail + 9 no N/A no nothing exists fail + + 10 yes yes N/A exists nothing remove path from index + 11 no yes N/A exists nothing fail + 12 yes no N/A exists nothing fail + 13 no no N/A exists nothing fail + + clean (H=M) + ------ + 14 yes exists exists keep index + 15 no exists exists keep index + + clean I==H I==M (H!=M) + ------------------ + 16 yes no no exists exists fail + 17 no no no exists exists fail + 18 yes no yes exists exists keep index + 19 no no yes exists exists keep index + 20 yes yes no exists exists use M + 21 no yes no exists exists fail + +In all "keep index" cases, the index entry stays as in the +original index file. If the entry were not up to date, +'git-read-tree' keeps the copy in the work tree intact when +operating under the -u flag. + +When this form of 'git-read-tree' returns successfully, you can +see what "local changes" you made are carried forward by running +`git diff-index --cached $M`. Note that this does not +necessarily match `git diff-index --cached $H` would have +produced before such a two tree merge. This is because of cases +18 and 19 --- if you already had the changes in $M (e.g. maybe +you picked it up via e-mail in a patch form), `git diff-index +--cached $H` would have told you about the change before this +merge, but it would not show in `git diff-index --cached $M` +output after two-tree merge. + +Case #3 is slightly tricky and needs explanation. The result from this +rule logically should be to remove the path if the user staged the removal +of the path and then switching to a new branch. That however will prevent +the initial checkout from happening, so the rule is modified to use M (new +tree) only when the contents of the index is empty. Otherwise the removal +of the path is kept as long as $H and $M are the same. + +3-Way Merge +~~~~~~~~~~~ +Each "index" entry has two bits worth of "stage" state. stage 0 is the +normal one, and is the only one you'd see in any kind of normal use. + +However, when you do 'git-read-tree' with three trees, the "stage" +starts out at 1. + +This means that you can do + +---------------- +$ git read-tree -m <tree1> <tree2> <tree3> +---------------- + +and you will end up with an index with all of the <tree1> entries in +"stage1", all of the <tree2> entries in "stage2" and all of the +<tree3> entries in "stage3". When performing a merge of another +branch into the current branch, we use the common ancestor tree +as <tree1>, the current branch head as <tree2>, and the other +branch head as <tree3>. + +Furthermore, 'git-read-tree' has special-case logic that says: if you see +a file that matches in all respects in the following states, it +"collapses" back to "stage0": + + - stage 2 and 3 are the same; take one or the other (it makes no + difference - the same work has been done on our branch in + stage 2 and their branch in stage 3) + + - stage 1 and stage 2 are the same and stage 3 is different; take + stage 3 (our branch in stage 2 did not do anything since the + ancestor in stage 1 while their branch in stage 3 worked on + it) + + - stage 1 and stage 3 are the same and stage 2 is different take + stage 2 (we did something while they did nothing) + +The 'git-write-tree' command refuses to write a nonsensical tree, and it +will complain about unmerged entries if it sees a single entry that is not +stage 0. + +OK, this all sounds like a collection of totally nonsensical rules, +but it's actually exactly what you want in order to do a fast +merge. The different stages represent the "result tree" (stage 0, aka +"merged"), the original tree (stage 1, aka "orig"), and the two trees +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 +start a 3-way merge with an index file that is already +populated. Here is an outline of how the algorithm works: + +- if a file exists in identical format in all three trees, it will + automatically collapse to "merged" state by 'git-read-tree'. + +- a file that has _any_ difference what-so-ever in the three trees + will stay as separate entries in the index. It's up to "porcelain + policy" to determine how to remove the non-0 stages, and insert a + merged version. + +- the index file saves and restores with all this information, so you + can merge things incrementally, but as long as it has entries in + stages 1/2/3 (i.e., "unmerged entries") you can't write the result. So + now the merge algorithm ends up being really simple: + + * you walk the index in order, and ignore all entries of stage 0, + since they've already been done. + + * if you find a "stage1", but no matching "stage2" or "stage3", you + know it's been removed from both trees (it only existed in the + original tree), and you remove that entry. + + * if you find a matching "stage2" and "stage3" tree, you remove one + of them, and turn the other into a "stage0" entry. Remove any + matching "stage1" entry if it exists too. .. all the normal + trivial rules .. + +You would normally use 'git-merge-index' with supplied +'git-merge-one-file' to do this last step. The script updates +the files in the working tree as it merges each path and at the +end of a successful merge. + +When you start a 3-way merge with an index file that is already +populated, it is assumed that it represents the state of the +files in your work tree, and you can even have files with +changes unrecorded in the index file. It is further assumed +that this state is "derived" from the stage 2 tree. The 3-way +merge refuses to run if it finds an entry in the original index +file that does not match stage 2. + +This is done to prevent you from losing your work-in-progress +changes, and mixing your random changes in an unrelated merge +commit. To illustrate, suppose you start from what has been +committed last to your repository: + +---------------- +$ JC=`git rev-parse --verify "HEAD^0"` +$ git checkout-index -f -u -a $JC +---------------- + +You do random edits, without running 'git-update-index'. And then +you notice that the tip of your "upstream" tree has advanced +since you pulled from him: + +---------------- +$ git fetch git://.... linus +$ LT=`cat .git/FETCH_HEAD` +---------------- + +Your work tree is still based on your HEAD ($JC), but you have +some edits since. Three-way merge makes sure that you have not +added or modified index entries since $JC, and if you haven't, +then does the right thing. So with the following sequence: + +---------------- +$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT +$ git merge-index git-merge-one-file -a +$ echo "Merge with Linus" | \ + git commit-tree `git write-tree` -p $JC -p $LT +---------------- + +what you would commit is a pure merge between $JC and $LT without +your work-in-progress changes, and your work tree would be +updated to the result of the merge. + +However, if you have local changes in the working tree that +would be overwritten by this merge, 'git-read-tree' will refuse +to run to prevent your changes from being lost. + +In other words, there is no need to worry about what exists only +in the working tree. When you have local changes in a part of +the project that is not involved in the merge, your changes do +not interfere with the merge, and are kept intact. When they +*do* interfere, the merge does not even start ('git-read-tree' +complains loudly and fails without modifying anything). In such +a case, you can simply continue doing what you were in the +middle of doing, and when your working tree is ready (i.e. you +have finished your work-in-progress), attempt the merge again. + + +SEE ALSO +-------- +linkgit:git-write-tree[1]; linkgit:git-ls-files[1]; +linkgit:gitignore[5] + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt new file mode 100644 index 0000000000..ca5e1e8653 --- /dev/null +++ b/Documentation/git-rebase.txt @@ -0,0 +1,588 @@ +git-rebase(1) +============= + +NAME +---- +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> + --root [<branch>] + +'git rebase' --continue | --skip | --abort + +DESCRIPTION +----------- +If <branch> is specified, 'git-rebase' will perform an automatic +`git checkout <branch>` before doing anything else. Otherwise +it remains on the current branch. + +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). + +The current branch is reset to <upstream>, or <newbase> if the +--onto option was supplied. This has the exact same effect as +`git reset --hard <upstream>` (or <newbase>). ORIG_HEAD is set +to point at the tip of the branch before the reset. + +The commits that were previously saved into the temporary area are +then reapplied to the current branch, one by one, in order. Note that +any commits in HEAD which introduce the same textual changes as a commit +in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream +with a different commit message or timestamp will be skipped). + +It is possible that a merge failure will prevent this process from being +completely automatic. You will have to resolve any such merge failure +and run `git rebase --continue`. Another option is to bypass the commit +that caused the merge failure with `git rebase --skip`. To restore the +original <branch> and remove the .git/rebase-apply working files, use the +command `git rebase --abort` instead. + +Assume the following history exists and the current branch is "topic": + +------------ + A---B---C topic + / + D---E---F---G master +------------ + +From this point, the result of either of the following commands: + + + git rebase master + git rebase master topic + +would be: + +------------ + A'--B'--C' topic + / + D---E---F---G master +------------ + +The latter form is just a short-hand of `git checkout topic` +followed by `git rebase master`. + +If the upstream branch already contains a change you have made (e.g., +because you mailed a patch which was applied upstream), then that commit +will be skipped. For example, running `git rebase master` on the +following history (in which A' and A introduce the same set of changes, +but have different committer information): + +------------ + A---B---C topic + / + D---E---A'---F master +------------ + +will result in: + +------------ + B'---C' topic + / + D---E---A'---F master +------------ + +Here is how you would transplant a topic branch based on one +branch to another, to pretend that you forked the topic branch +from the latter branch, using `rebase --onto`. + +First let's assume your 'topic' is based on branch 'next'. +For example, a feature developed in 'topic' depends on some +functionality which is found in 'next'. + +------------ + o---o---o---o---o master + \ + o---o---o---o---o next + \ + o---o---o topic +------------ + +We want to make 'topic' forked from branch 'master'; for example, +because the functionality on which 'topic' depends was merged into the +more stable 'master' branch. We want our tree to look like this: + +------------ + o---o---o---o---o master + | \ + | o'--o'--o' topic + \ + o---o---o---o---o next +------------ + +We can get this using the following command: + + git rebase --onto master next topic + + +Another example of --onto option is to rebase part of a +branch. If we have the following situation: + +------------ + H---I---J topicB + / + E---F---G topicA + / + A---B---C---D master +------------ + +then the command + + git rebase --onto master topicA topicB + +would result in: + +------------ + H'--I'--J' topicB + / + | E---F---G topicA + |/ + A---B---C---D master +------------ + +This is useful when topicB does not depend on topicA. + +A range of commits could also be removed with rebase. If we have +the following situation: + +------------ + E---F---G---H---I---J topicA +------------ + +then the command + + git rebase --onto topicA~5 topicA~3 topicA + +would result in the removal of commits F and G: + +------------ + E---H'---I'---J' topicA +------------ + +This is useful if F and G were flawed in some way, or should not be +part of topicA. Note that the argument to --onto and the <upstream> +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, +typically this would be done with + + + git add <filename> + + +After resolving the conflict manually and updating the index with the +desired resolution, you can continue the rebasing process with + + + git rebase --continue + + +Alternatively, you can undo the 'git-rebase' with + + + git rebase --abort + +CONFIGURATION +------------- + +rebase.stat:: + Whether to show a diffstat of what changed upstream since the last + rebase. False by default. + +OPTIONS +------- +<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 + existing branch name. + +<upstream>:: + Upstream branch to compare against. May be any valid commit, + not just an existing branch name. + +<branch>:: + Working branch; defaults to HEAD. + +--continue:: + Restart the rebasing process after having resolved a merge conflict. + +--abort:: + Restore the original branch and abort the rebase operation. + +--skip:: + Restart the rebasing process by skipping the current patch. + +-m:: +--merge:: + Use merging strategies to rebase. When the recursive (default) merge + strategy is used, this allows rebase to be aware of renames on the + upstream side. ++ +Note that a rebase merge works by replaying each commit from the working +branch on top of the <upstream> branch. Because of this, when a merge +conflict happens, the side reported as 'ours' is the so-far rebased +series, starting with <upstream>, and 'theirs' is the working branch. In +other words, the sides are swapped. + +-s <strategy>:: +--strategy=<strategy>:: + Use the given merge strategy. + If there is no `-s` option 'git-merge-recursive' is used + instead. This implies --merge. ++ +Because 'git-rebase' replays each commit from the working branch +on top of the <upstream> branch using the given strategy, using +the 'ours' strategy simply discards all patches from the <branch>, +which makes little sense. + +-q:: +--quiet:: + Be quiet. Implies --no-stat. + +-v:: +--verbose:: + Be verbose. Implies --stat. + +--stat:: + Show a diffstat of what changed upstream since the last rebase. The + diffstat is also controlled by the configuration option rebase.stat. + +-n:: +--no-stat:: + Do not show a diffstat as part of the rebase process. + +--no-verify:: + This option bypasses the pre-rebase hook. See also linkgit:githooks[5]. + +-C<n>:: + Ensure at least <n> lines of surrounding context match before + and after each change. When fewer lines of surrounding + context exist they all must match. By default no context is + ever ignored. + +-f:: +--force-rebase:: + Force the rebase even if the current branch is a descendant + of the commit you are rebasing onto. Normally the command will + exit with the message "Current branch is up to date" in such a + situation. + +--ignore-whitespace:: +--whitespace=<option>:: + These flag are passed to the 'git-apply' program + (see linkgit:git-apply[1]) that applies the patch. + Incompatible with the --interactive option. + +--committer-date-is-author-date:: +--ignore-date:: + These flags are passed to 'git-am' to easily change the dates + of the rebased commits (see linkgit:git-am[1]). + +-i:: +--interactive:: + Make a list of the commits which are about to be rebased. Let the + user edit that list before rebasing. This mode can also be used to + split commits (see SPLITTING COMMITS below). + +-p:: +--preserve-merges:: + Instead of ignoring merges, try to recreate them. + +--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 + 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 + instead. + +include::merge-strategies.txt[] + +NOTES +----- + +You should understand the implications of using 'git-rebase' on a +repository that you share. See also RECOVERING FROM UPSTREAM REBASE +below. + +When the git-rebase command is run, it will first execute a "pre-rebase" +hook if one exists. You can use this hook to do sanity checks and +reject the rebase if it isn't appropriate. Please see the template +pre-rebase hook script for an example. + +Upon completion, <branch> will be the current branch. + +INTERACTIVE MODE +---------------- + +Rebasing interactively means that you have a chance to edit the commits +which are rebased. You can reorder the commits, and you can +remove them (weeding out bad or otherwise unwanted patches). + +The interactive mode is meant for this type of workflow: + +1. have a wonderful idea +2. hack on the code +3. prepare a series for submission +4. submit + +where point 2. consists of several instances of + +a. regular use + 1. finish something worthy of a commit + 2. commit +b. independent fixup + 1. realize that something does not work + 2. fix that + 3. commit it + +Sometimes the thing fixed in b.2. cannot be amended to the not-quite +perfect commit it fixes, because that commit is buried deeply in a +patch series. That is exactly what interactive rebase is for: use it +after plenty of "a"s and "b"s, by rearranging and editing +commits, and squashing multiple commits into one. + +Start it with the last commit you want to retain as-is: + + git rebase -i <after-this-commit> + +An editor will be fired up with all the commits in your current branch +(ignoring merge commits), which come after the given commit. You can +reorder the commits in this list to your heart's content, and you can +remove them. The list looks more or less like this: + +------------------------------------------- +pick deadbee The oneline of this commit +pick fa1afe1 The oneline of the next commit +... +------------------------------------------- + +The oneline descriptions are purely for your pleasure; 'git-rebase' will +not look at them but at the commit names ("deadbee" and "fa1afe1" in this +example), so do not delete or edit the names. + +By replacing the command "pick" with the command "edit", you can tell +'git-rebase' to stop after applying that commit, so that you can edit +the files and/or the commit message, amend the commit, and continue +rebasing. + +If you just want to edit the commit message for a commit, replace the +command "pick" with the command "reword". + +If you want to fold two or more commits into one, replace the command +"pick" with "squash" for the second and subsequent commit. If the +commits had different authors, it will attribute the squashed commit to +the author of the first commit. + +'git-rebase' will stop when "pick" has been replaced with "edit" or +when a command fails due to merge errors. When you are done editing +and/or resolving conflicts you can continue with `git rebase --continue`. + +For example, if you want to reorder the last 5 commits, such that what +was HEAD~4 becomes the new HEAD. To achieve that, you would call +'git-rebase' like this: + +---------------------- +$ git rebase -i HEAD~5 +---------------------- + +And move the first patch to the end of the list. + +You might want to preserve merges, if you have a history like this: + +------------------ + X + \ + A---M---B + / +---o---O---P---Q +------------------ + +Suppose you want to rebase the side branch starting at "A" to "Q". Make +sure that the current HEAD is "B", and call + +----------------------------- +$ git rebase -i -p --onto Q O +----------------------------- + + +SPLITTING COMMITS +----------------- + +In interactive mode, you can mark commits with the action "edit". However, +this does not necessarily mean that 'git-rebase' expects the result of this +edit to be exactly one commit. Indeed, you can undo the commit, or you can +add other commits. This can be used to split a commit into two: + +- Start an interactive rebase with `git rebase -i <commit>^`, where + <commit> is the commit you want to split. In fact, any commit range + will do, as long as it contains that commit. + +- Mark the commit you want to split with the action "edit". + +- When it comes to editing that commit, execute `git reset HEAD^`. The + effect is that the HEAD is rewound by one, and the index follows suit. + However, the working tree stays the same. + +- Now add the changes to the index that you want to have in the first + commit. You can use `git add` (possibly interactively) or + 'git-gui' (or both) to do that. + +- Commit the now-current index with whatever commit message is appropriate + now. + +- Repeat the last two steps until your working tree is clean. + +- Continue the rebase with `git rebase --continue`. + +If you are not absolutely sure that the intermediate revisions are +consistent (they compile, pass the testsuite, etc.) you should use +'git-stash' to stash away the not-yet-committed changes +after each commit, test, and amend the commit if fixes are necessary. + + +RECOVERING FROM UPSTREAM REBASE +------------------------------- + +Rebasing (or any other form of rewriting) a branch that others have +based work on is a bad idea: anyone downstream of it is forced to +manually fix their history. This section explains how to do the fix +from the downstream's point of view. The real fix, however, would be +to avoid rebasing the upstream in the first place. + +To illustrate, suppose you are in a situation where someone develops a +'subsystem' branch, and you are working on a 'topic' that is dependent +on this 'subsystem'. You might end up with a history like the +following: + +------------ + o---o---o---o---o---o---o---o---o master + \ + o---o---o---o---o subsystem + \ + *---*---* topic +------------ + +If 'subsystem' is rebased against 'master', the following happens: + +------------ + o---o---o---o---o---o---o---o master + \ \ + o---o---o---o---o o'--o'--o'--o'--o' subsystem + \ + *---*---* topic +------------ + +If you now continue development as usual, and eventually merge 'topic' +to 'subsystem', the commits from 'subsystem' will remain duplicated forever: + +------------ + o---o---o---o---o---o---o---o master + \ \ + o---o---o---o---o o'--o'--o'--o'--o'--M subsystem + \ / + *---*---*-..........-*--* topic +------------ + +Such duplicates are generally frowned upon because they clutter up +history, making it harder to follow. To clean things up, you need to +transplant the commits on 'topic' to the new 'subsystem' tip, i.e., +rebase 'topic'. This becomes a ripple effect: anyone downstream from +'topic' is forced to rebase too, and so on! + +There are two kinds of fixes, discussed in the following subsections: + +Easy case: The changes are literally the same.:: + + This happens if the 'subsystem' rebase was a simple rebase and + had no conflicts. + +Hard case: The changes are not the same.:: + + This happens if the 'subsystem' rebase had conflicts, or used + `\--interactive` to omit, edit, or squash commits; or if the + upstream used one of `commit \--amend`, `reset`, or + `filter-branch`. + + +The easy case +~~~~~~~~~~~~~ + +Only works if the changes (patch IDs based on the diff contents) on +'subsystem' are literally the same before and after the rebase +'subsystem' did. + +In that case, the fix is easy because 'git-rebase' knows to skip +changes that are already present in the new upstream. So if you say +(assuming you're on 'topic') +------------ + $ git rebase subsystem +------------ +you will end up with the fixed history +------------ + o---o---o---o---o---o---o---o master + \ + o'--o'--o'--o'--o' subsystem + \ + *---*---* topic +------------ + + +The hard case +~~~~~~~~~~~~~ + +Things get more complicated if the 'subsystem' changes do not exactly +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**! + +The idea is to manually tell 'git-rebase' "where the old 'subsystem' +ended and your 'topic' began", that is, what the old merge-base +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 + increase the number. (See linkgit:git-reflog[1].) + +* Relative to the tip of 'topic': knowing that your 'topic' has three + commits, the old tip of 'subsystem' must be `topic~3`. + +You can then transplant the old `subsystem..topic` to the new tip by +saying (for the reflog case, and assuming you are on 'topic' already): +------------ + $ git rebase --onto subsystem subsystem@{1} +------------ + +The ripple effect of a "hard case" recovery is especially bad: +'everyone' downstream from 'topic' will now have to perform a "hard +case" recovery too! + + +Authors +------ +Written by Junio C Hamano <gitster@pobox.com> and +Johannes E. Schindelin <johannes.schindelin@gmx.de> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt new file mode 100644 index 0000000000..cb5f405280 --- /dev/null +++ b/Documentation/git-receive-pack.txt @@ -0,0 +1,165 @@ +git-receive-pack(1) +=================== + +NAME +---- +git-receive-pack - Receive what is pushed into the repository + + +SYNOPSIS +-------- +'git receive-pack' <directory> + +DESCRIPTION +----------- +Invoked by 'git-send-pack' and updates the repository with the +information fed from the remote end. + +This command is usually not invoked directly by the end user. +The UI for the protocol is on the 'git-send-pack' side, and the +program pair is meant to be used to push updates to remote +repository. For pull operations, see linkgit:git-fetch-pack[1]. + +The command allows for creation and fast-forwarding of sha1 refs +(heads/tags) on the remote end (strictly speaking, it is the +local end 'git-receive-pack' runs, but to the user who is sitting at +the send-pack end, it is updating the remote. Confused?) + +There are other real-world examples of using update and +post-update hooks found in the Documentation/howto directory. + +'git-receive-pack' honours the receive.denyNonFastForwards config +option, which tells it if updates to a ref should be denied if they +are not fast-forwards. + +OPTIONS +------- +<directory>:: + The repository to sync into. + +pre-receive Hook +---------------- +Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists +and is executable, it will be invoked once with no parameters. The +standard input of the hook will be one line per ref to be updated: + + sha1-old SP sha1-new SP refname LF + +The refname value is relative to $GIT_DIR; e.g. for the master +head this is "refs/heads/master". The two sha1 values before +each refname are the object names for the refname before and after +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. + +This hook is called before any refname is updated and before any +fast-forward checks are performed. + +If the pre-receive hook exits with a non-zero exit status no updates +will be performed, and the update, post-receive and post-update +hooks will not be invoked either. This can be useful to quickly +bail out if the update is not to be supported. + +update Hook +----------- +Before each ref is updated, if $GIT_DIR/hooks/update file exists +and is executable, it is invoked once per ref, with three parameters: + + $GIT_DIR/hooks/update refname sha1-old sha1-new + +The refname parameter is relative to $GIT_DIR; e.g. for the master +head this is "refs/heads/master". The two sha1 arguments are +the object names for the refname before and after the update. +Note that the hook is called before the refname is updated, +so either sha1-old is 0\{40} (meaning there is no such ref yet), +or it should match what is recorded in refname. + +The hook should exit with non-zero status if it wants to disallow +updating the named ref. Otherwise it should exit with zero. + +Successful execution (a zero exit status) of this hook does not +ensure the ref will actually be updated, it is only a prerequisite. +As such it is not a good idea to send notices (e.g. email) from +this hook. Consider using the post-receive hook instead. + +post-receive Hook +----------------- +After all refs were updated (or attempted to be updated), if any +ref update was successful, and if $GIT_DIR/hooks/post-receive +file exists and is executable, it will be invoked once with no +parameters. The standard input of the hook will be one line +for each successfully updated ref: + + sha1-old SP sha1-new SP refname LF + +The refname value is relative to $GIT_DIR; e.g. for the master +head this is "refs/heads/master". The two sha1 values before +each refname are the object names for the refname before and after +the update. Refs that were created will have sha1-old equal to +0\{40}, while refs that were deleted will have sha1-new equal to +0\{40}, otherwise sha1-old and sha1-new should be valid objects in +the repository. + +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: + + #!/bin/sh + # mail out commit update information. + while read oval nval ref + do + if expr "$oval" : '0*$' >/dev/null + then + echo "Created a new ref, with the following commits:" + git rev-list --pretty "$nval" + else + echo "New commits:" + git rev-list --pretty "$nval" "^$oval" + fi | + mail -s "Changes to ref $ref" commit-list@mydomain + done + exit 0 + +The exit code from this hook invocation is ignored, however a +non-zero exit code will generate an error message. + +Note that it is possible for refname to not have sha1-new when this +hook runs. This can easily occur if another user modifies the ref +after it was updated by 'git-receive-pack', but before the hook was able +to evaluate it. It is recommended that hooks rely on sha1-new +rather than the current value of refname. + +post-update Hook +---------------- +After all other processing, if at least one ref was updated, and +if $GIT_DIR/hooks/post-update file exists and is executable, then +post-update will be called with the list of refs that have been updated. +This can be used to implement any repository wide cleanup tasks. + +The exit code from this hook invocation is ignored; the only thing +left for 'git-receive-pack' to do at that point is to exit itself +anyway. + +This hook can be used, for example, to run `git update-server-info` +if the repository is packed and is served via a dumb transport. + + #!/bin/sh + exec git update-server-info + + +SEE ALSO +-------- +linkgit:git-send-pack[1] + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt new file mode 100644 index 0000000000..7f7a5445c7 --- /dev/null +++ b/Documentation/git-reflog.txt @@ -0,0 +1,105 @@ +git-reflog(1) +============= + +NAME +---- +git-reflog - Manage reflog information + + +SYNOPSIS +-------- +'git reflog' <subcommand> <options> + +DESCRIPTION +----------- +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>] + +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]. + +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:git-rev-parse[1] for +more details. + +To delete single entries from the reflog, use the subcommand "delete" +and specify the _exact_ entry (e.g. "`git reflog delete master@\{2\}`"). + + +OPTIONS +------- + +--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. + +--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. + +--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. + +--updateref:: + Update the ref with the sha1 of the top reflog entry (i.e. + <ref>@\{0\}) after expiring or deleting. + +--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. + +--verbose:: + Print extra information on screen. + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-relink.txt b/Documentation/git-relink.txt new file mode 100644 index 0000000000..25ff8f9dcb --- /dev/null +++ b/Documentation/git-relink.txt @@ -0,0 +1,37 @@ +git-relink(1) +============= + +NAME +---- +git-relink - Hardlink common objects in local repositories + +SYNOPSIS +-------- +'git relink' [--safe] <dir> [<dir>]\* <master_dir> + +DESCRIPTION +----------- +This will scan 1 or more object repositories and look for objects in common +with a master repository. Objects not already hardlinked to the master +repository will be replaced with a hardlink to the master repository. + +OPTIONS +------- +--safe:: + Stops if two objects with the same hash exist but have different sizes. + Default is to warn and continue. + +<dir>:: + Directories containing a .git/objects/ subdirectory. + +Author +------ +Written by Ryan Anderson <ryan@michonline.com> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt new file mode 100644 index 0000000000..8beb42dbb9 --- /dev/null +++ b/Documentation/git-remote-helpers.txt @@ -0,0 +1,146 @@ +git-remote-helpers(1) +===================== + +NAME +---- +git-remote-helpers - Helper programs for interoperation with remote git + +SYNOPSIS +-------- +'git remote-<transport>' <remote> + +DESCRIPTION +----------- + +These programs are normally not used directly by end users, but are +invoked by various git programs that interact with remote repositories +when the repository they would operate on will be accessed using +transport code not linked into the main git binary. Various particular +helper programs will behave as documented here. + +COMMANDS +-------- + +Commands are given by the caller on the helper's standard input, one per line. + +'capabilities':: + Lists the capabilities of the helper, one per line, ending + with a blank line. + +'list':: + Lists the refs, one per line, in the format "<value> <name> + [<attr> ...]". The value may be a hex sha1 hash, "@<dest>" for + a symref, or "?" to indicate that the helper could not get the + value of the ref. A space-separated list of attributes follows + the name; unrecognized attributes are ignored. After the + complete list, outputs a blank line. ++ +If 'push' is supported this may be called as 'list for-push' +to obtain the current refs prior to sending one or more 'push' +commands to the helper. + +'option' <name> <value>:: + Set the transport helper option <name> to <value>. Outputs a + single line containing one of 'ok' (option successfully set), + 'unsupported' (option not recognized) or 'error <msg>' + (option <name> is supported but <value> is not correct + for it). Options should be set before other commands, + and may how those commands behave. ++ +Supported if the helper has the "option" capability. + +'fetch' <sha1> <name>:: + Fetches the given object, writing the necessary objects + to the database. Fetch commands are sent in a batch, one + per line, and the batch is terminated with a blank line. + Outputs a single blank line when all fetch commands in the + same batch are complete. Only objects which were reported + in the ref list with a sha1 may be fetched this way. ++ +Optionally may output a 'lock <file>' line indicating a file under +GIT_DIR/objects/pack which is keeping a pack until refs can be +suitably updated. ++ +Supported if the helper has the "fetch" capability. + +'push' +<src>:<dst>:: + Pushes the given <src> commit or branch locally to the + remote branch described by <dst>. A batch sequence of + one or more push commands is terminated with a blank line. ++ +Zero or more protocol options may be entered after the last 'push' +command, before the batch's terminating blank line. ++ +When the push is complete, outputs one or more 'ok <dst>' or +'error <dst> <why>?' lines to indicate success or failure of +each pushed ref. The status report output is terminated by +a blank line. The option field <why> may be quoted in a C +style string if it contains an LF. ++ +Supported if the helper has the "push" capability. + +If a fatal error occurs, the program writes the error message to +stderr and exits. The caller should expect that a suitable error +message has been printed if the child closes the connection without +completing a valid response for the current command. + +Additional commands may be supported, as may be determined from +capabilities reported by the helper. + +CAPABILITIES +------------ + +'fetch':: + This helper supports the 'fetch' command. + +'option':: + This helper supports the option command. + +'push':: + This helper supports the 'push' command. + +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. + +OPTIONS +------- +'option verbosity' <N>:: + Change the level of messages displayed by the helper. + When N is 0 the end-user has asked the process to be + quiet, and the helper should produce only error output. + N of 1 is the default level of verbosity, higher values + of N correspond to the number of -v flags passed on the + command line. + +'option progress' \{'true'|'false'\}:: + Enable (or disable) progress messages displayed by the + transport helper during a command. + +'option depth' <depth>:: + Deepen the history of a shallow repository. + +'option followtags' \{'true'|'false'\}:: + If enabled the helper should automatically fetch annotated + tag objects if the object the tag points at was transferred + during the fetch command. If the tag is not fetched by + the helper a second fetch command will usually be sent to + ask for the tag specifically. Some helpers may be able to + use this option to avoid a second network connection. + +'option dry-run' \{'true'|'false'\}: + If true, pretend the operation completed successfully, + but don't actually change any repository data. For most + helpers this only applies to the 'push', if supported. + +Documentation +------------- +Documentation by Daniel Barkalow. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt new file mode 100644 index 0000000000..c272c92d4b --- /dev/null +++ b/Documentation/git-remote.txt @@ -0,0 +1,193 @@ +git-remote(1) +============ + +NAME +---- +git-remote - manage set of tracked repositories + + +SYNOPSIS +-------- +[verse] +'git remote' [-v | --verbose] +'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url> +'git remote rename' <old> <new> +'git remote rm' <name> +'git remote set-head' <name> (-a | -d | <branch>) +'git remote' [-v | --verbose] 'show' [-n] <name> +'git remote prune' [-n | --dry-run] <name> +'git remote' [-v | --verbose] 'update' [-p | --prune] [group | remote]... + +DESCRIPTION +----------- + +Manage the set of repositories ("remotes") whose branches you track. + + +OPTIONS +------- + +-v:: +--verbose:: + Be a little more verbose and show remote url after name. + NOTE: This must be placed between `remote` and `subcommand`. + + +COMMANDS +-------- + +With no arguments, shows a list of existing remotes. Several +subcommands are available to perform operations on the remotes. + +'add':: + +Adds a remote named <name> for the repository at +<url>. The command `git fetch <name>` can then be used to create and +update remote-tracking branches <name>/<branch>. ++ +With `-f` option, `git fetch <name>` is run immediately after +the remote information is set up. ++ +With `-t <branch>` option, instead of the default glob +refspec for the remote to track all branches under +`$GIT_DIR/remotes/<name>/`, a refspec to track only `<branch>` +is created. You can give more than one `-t <branch>` to track +multiple branches without grabbing all branches. ++ +With `-m <master>` option, `$GIT_DIR/remotes/<name>/HEAD` is set +up to point at remote's `<master>` branch. See also the set-head command. ++ +In mirror mode, enabled with `\--mirror`, the refs will not be stored +in the 'refs/remotes/' namespace, but in 'refs/heads/'. This option +only makes sense in bare repositories. If a remote uses mirror +mode, furthermore, `git push` will always behave as if `\--mirror` +was passed. + +'rename':: + +Rename the remote named <old> to <new>. All remote tracking branches and +configuration settings for the remote are updated. ++ +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. + +'rm':: + +Remove the remote named <name>. All remote tracking branches and +configuration settings for the remote are removed. + +'set-head':: + +Sets or deletes the default branch (`$GIT_DIR/remotes/<name>/HEAD`) for +the named remote. Having a default branch for a remote is not required, +but allows the name of the remote to be specified in lieu of a specific +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`, `$GIT_DIR/remotes/<name>/HEAD` is deleted. ++ +With `-a`, the remote is queried to determine its `HEAD`, then +`$GIT_DIR/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 +`$GIT_DIR/refs/remotes/origin/HEAD` to `refs/remotes/origin/next`. This will +only work if `refs/remotes/origin/next` already exists; if not it must be +fetched first. ++ +Use `<branch>` to set `$GIT_DIR/remotes/<name>/HEAD` explicitly. e.g., "git +remote set-head origin master" will set `$GIT_DIR/refs/remotes/origin/HEAD` to +`refs/remotes/origin/master`. This will only work if +`refs/remotes/origin/master` already exists; if not it must be fetched first. ++ + +'show':: + +Gives some information about the remote <name>. ++ +With `-n` option, the remote heads are not queried first with +`git ls-remote <name>`; cached information is used instead. + +'prune':: + +Deletes all stale tracking branches under <name>. +These stale branches have already been removed from the remote repository +referenced by <name>, but are still locally available in +"remotes/<name>". ++ +With `--dry-run` option, report what branches will be pruned, but do not +actually prune them. + +'update':: + +Fetch updates for a named set of remotes in the repository as defined by +remotes.<group>. If a named group is not specified on the command line, +the configuration parameter remotes.default will be used; if +remotes.default is not defined, all remotes which do not have the +configuration parameter remote.<name>.skipDefaultUpdate set to true will +be updated. (See linkgit:git-config[1]). ++ +With `--prune` option, prune all the remotes that are updated. + + +DISCUSSION +---------- + +The remote configuration is achieved using the `remote.origin.url` and +`remote.origin.fetch` configuration variables. (See +linkgit:git-config[1]). + +Examples +-------- + +* Add a new remote, fetch, and check out a branch from it ++ +------------ +$ git remote +origin +$ git branch -r +origin/master +$ git remote add linux-nfs git://linux-nfs.org/pub/linux/nfs-2.6.git +$ git remote +linux-nfs +origin +$ git fetch +* refs/remotes/linux-nfs/master: storing branch 'master' ... + commit: bf81b46 +$ git branch -r +origin/master +linux-nfs/master +$ git checkout -b nfs linux-nfs/master +... +------------ + +* Imitate 'git-clone' but track only selected branches ++ +------------ +$ mkdir project.git +$ cd project.git +$ git init +$ git remote add -f -t master -m master origin git://example.com/git.git/ +$ git merge origin +------------ + + +SEE ALSO +-------- +linkgit:git-fetch[1] +linkgit:git-branch[1] +linkgit:git-config[1] + +Author +------ +Written by Junio Hamano + + +Documentation +-------------- +Documentation by J. Bruce Fields and the git-list <git@vger.kernel.org>. + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt new file mode 100644 index 0000000000..c9257a10c9 --- /dev/null +++ b/Documentation/git-repack.txt @@ -0,0 +1,136 @@ +git-repack(1) +============= + +NAME +---- +git-repack - Pack unpacked objects in a repository + + +SYNOPSIS +-------- +'git repack' [-a] [-A] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N] + +DESCRIPTION +----------- + +This script 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. + +A pack is a collection of objects, individually compressed, with +delta compression applied, stored in a single file, with an +associated index file. + +Packs are used to reduce the load on mirror systems, backup +engines, disk storage, etc. + +OPTIONS +------- + +-a:: + Instead of incrementally packing the unpacked objects, + pack everything referenced into a single pack. + 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 + dangling. ++ +Note that users fetching over dumb protocols will have to fetch the +whole new pack in order to get any contained object, no matter how many +other objects in that pack they already have locally. + +-A:: + Same as `-a`, unless '-d' is used. Then any unreachable + objects in a previous pack become loose, unpacked objects, + instead of being left in the old pack. Unreachable objects + are never intentionally added to a pack, even when repacking. + This option prevents unreachable objects from being immediately + deleted by way of being left in the old pack and then + removed. Instead, the loose unreachable objects + will be pruned according to normal expiry rules + with the next 'git-gc' invocation. See linkgit:git-gc[1]. + +-d:: + After packing, if the newly created packs make some + existing packs redundant, remove the redundant packs. + Also run 'git-prune-packed' to remove redundant + loose object files. + +-l:: + Pass the `--local` option to 'git-pack-objects'. See + linkgit:git-pack-objects[1]. + +-f:: + Pass the `--no-reuse-object` option to `git-pack-objects`, see + linkgit:git-pack-objects[1]. + +-q:: + Pass the `-q` option to 'git-pack-objects'. See + linkgit:git-pack-objects[1]. + +-n:: + Do not update the server information with + 'git-update-server-info'. This option skips + updating local catalog files needed to publish + this repository (or a direct copy of it) + over HTTP or FTP. See linkgit:git-update-server-info[1]. + +--window=[N]:: +--depth=[N]:: + These two options affect how the objects contained in the pack are + stored using delta compression. The objects are first internally + sorted by type, size and optionally names and compared against the + other objects within `--window` to see if using delta compression saves + space. `--depth` limits the maximum delta depth; making it too deep + affects the performance on the unpacker side, because delta data needs + to be applied that many times to get to the necessary object. + The default value for --window is 10 and --depth is 50. + +--window-memory=[N]:: + This option provides an additional limit on top of `--window`; + the window size will dynamically scale down so as to not take + up more than N bytes in memory. This is useful in + repositories with a mix of large and small objects to not run + out of memory with a large window, but still be able to take + advantage of the large window for the smaller objects. The + size can be suffixed with "k", "m", or "g". + `--window-memory=0` makes memory usage unlimited, which is the + default. + +--max-pack-size=<n>:: + Maximum size of each output packfile, expressed in MiB. + If specified, multiple packfiles may be created. + The default is unlimited. + + +Configuration +------------- + +When configuration variable `repack.UseDeltaBaseOffset` is set +for the repository, the command passes `--delta-base-offset` +option to 'git-pack-objects'; this typically results in slightly +smaller packs, but the generated packs are incompatible with +versions of git older than (and including) v1.4.3; do not set +the variable in a repository that older version of git needs to +be able to read (this includes repositories from which packs can +be copied out over http or rsync, and people who obtained packs +that way can try to use older git with it). + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Ryan Anderson <ryan@michonline.com> + +SEE ALSO +-------- +linkgit:git-pack-objects[1] +linkgit:git-prune-packed[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt new file mode 100644 index 0000000000..65a0da508a --- /dev/null +++ b/Documentation/git-replace.txt @@ -0,0 +1,96 @@ +git-replace(1) +============== + +NAME +---- +git-replace - Create, list, delete refs to replace objects + +SYNOPSIS +-------- +[verse] +'git replace' [-f] <object> <replacement> +'git replace' -d <object>... +'git replace' -l [<pattern>] + +DESCRIPTION +----------- +Adds a 'replace' reference in `.git/refs/replace/` + +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 +replacement object. + +Unless `-f` is given, the 'replace' reference must not yet exist in +`.git/refs/replace/` directory. + +Replacement references will be used by default by all git commands +except those doing reachability traversal (prune, pack transfer and +fsck). + +It is possible to disable use of replacement references for any +command using the `--no-replace-objects` option just after 'git'. + +For example if commit 'foo' has been replaced by commit 'bar': + +------------------------------------------------ +$ git --no-replace-objects cat-file commit foo +------------------------------------------------ + +shows information about commit 'foo', while: + +------------------------------------------------ +$ git cat-file commit foo +------------------------------------------------ + +shows information about commit 'bar'. + +The 'GIT_NO_REPLACE_OBJECTS' environment variable can be set to +achieve the same effect as the `--no-replace-objects` option. + +OPTIONS +------- +-f:: + If an existing replace ref for the same object exists, it will + be overwritten (instead of failing). + +-d:: + Delete existing replace refs for the given objects. + +-l <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. + +BUGS +---- +Comparing blobs or trees that have been replaced with those that +replace them will not work properly. And using 'git reset --hard' to +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). + +SEE ALSO +-------- +linkgit:git-tag[1] +linkgit:git-branch[1] +linkgit:git[1] + +Author +------ +Written by Christian Couder <chriscool@tuxfamily.org> and Junio C +Hamano <gitster@pobox.com>, based on 'git tag' by Kristian Hogsberg +<krh@redhat.com> and Carlos Rica <jasampler@gmail.com>. + +Documentation +-------------- +Documentation by Christian Couder <chriscool@tuxfamily.org> and the +git-list <git@vger.kernel.org>, based on 'git tag' documentation. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt new file mode 100644 index 0000000000..e5bdb5533e --- /dev/null +++ b/Documentation/git-repo-config.txt @@ -0,0 +1,18 @@ +git-repo-config(1) +================== + +NAME +---- +git-repo-config - Get and set repository or global options + + +SYNOPSIS +-------- +'git repo-config' ... + + +DESCRIPTION +----------- + +This is a synonym for linkgit:git-config[1]. Please refer to the +documentation of that command. diff --git a/Documentation/git-request-pull.txt b/Documentation/git-request-pull.txt new file mode 100644 index 0000000000..19335fddae --- /dev/null +++ b/Documentation/git-request-pull.txt @@ -0,0 +1,39 @@ +git-request-pull(1) +=================== + +NAME +---- +git-request-pull - Generates a summary of pending changes + +SYNOPSIS +-------- +'git request-pull' <start> <url> [<end>] + +DESCRIPTION +----------- + +Summarizes the changes between two commits to the standard output, and includes +the given URL in the generated summary. + +OPTIONS +------- +<start>:: + Commit to start at. + +<url>:: + URL to include in the summary. + +<end>:: + Commit to end at; defaults to HEAD. + +Author +------ +Written by Ryan Anderson <ryan@michonline.com> and Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt new file mode 100644 index 0000000000..7dd515b8cc --- /dev/null +++ b/Documentation/git-rerere.txt @@ -0,0 +1,210 @@ +git-rerere(1) +============= + +NAME +---- +git-rerere - Reuse recorded resolution of conflicted merges + +SYNOPSIS +-------- +'git rerere' ['clear'|'diff'|'status'|'gc'] + +DESCRIPTION +----------- + +In a workflow employing relatively long lived topic branches, +the developer sometimes needs to resolve the same conflicts over +and over again until the topic branches are done (either merged +to the "release" branch, or sent out and accepted upstream). + +This command assists the developer in this process by recording +conflicted automerge results and corresponding hand resolve results +on the initial manual merge, and applying previously recorded +hand resolutions to their corresponding automerge results. + +[NOTE] +You need to set the configuration variable rerere.enabled in order to +enable this command. + + +COMMANDS +-------- + +Normally, 'git-rerere' is run without arguments or user-intervention. +However, it has several commands that allow it to interact with +its working state. + +'clear':: + +This resets 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. + +'diff':: + +This displays 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. + +'gc':: + +This prunes 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 +variables respectively. + + +DISCUSSION +---------- + +When your topic branch modifies an overlapping area that your +master branch (or upstream) touched since your topic branch +forked from it, you may want to test it with the latest master, +even before your topic branch is ready to be pushed upstream: + +------------ + o---*---o topic + / + o---o---o---*---o---o master +------------ + +For such a test, you need to merge master and topic somehow. +One way to do it is to pull master into the topic branch: + +------------ + $ git checkout topic + $ git merge master + + o---*---o---+ topic + / / + o---o---o---*---o---o master +------------ + +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 +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 +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}`, +in which case the final commit graph would look like this: + +------------ + $ git checkout topic + $ git merge master + $ ... work on both topic and master branches + $ git checkout master + $ git merge topic + + o---*---o---+---o---o topic + / / \ + o---o---o---*---o---o---o---o---+ master +------------ + +When your topic branch is long-lived, however, your topic branch +would end up having many such "Merge from master" commits on it, +which would unnecessarily clutter the development history. +Readers of the Linux kernel mailing list may remember that Linus +complained about such too frequent test merges when a subsystem +maintainer asked to pull from a branch full of "useless merges". + +As an alternative, to keep the topic branch clean of test +merges, you could blow away the test merge, and keep building on +top of the tip before the test merge: + +------------ + $ git checkout topic + $ git merge master + $ git reset --hard HEAD^ ;# rewind the test merge + $ ... work on both topic and master branches + $ git checkout master + $ git merge topic + + o---*---o-------o---o topic + / \ + o---o---o---*---o---o---o---o---+ master +------------ + +This would leave only one merge commit when your topic branch is +finally ready and merged into the master branch. This merge +would require you to resolve the conflict, introduced by the +commits marked with `*`. However, this conflict is often the +same conflict you resolved when you created the test merge you +blew away. 'git-rerere' helps you resolve this final +conflicted merge using the information from your earlier hand +resolve. + +Running the 'git-rerere' command immediately after a conflicted +automerge records the conflicted working tree files, with the +usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in +them. Later, after you are done resolving the conflicts, +running 'git-rerere' again will record the resolved state of these +files. Suppose you did this when you created the test merge of +master into the topic branch. + +Next time, after seeing the same conflicted automerge, +running 'git-rerere' will perform a three-way merge between the +earlier conflicted automerge, the earlier manual resolution, and +the current conflicted automerge. +If this three-way merge resolves cleanly, the result is written +out to your working tree file, so you do not have to manually +resolve it. Note that 'git-rerere' leaves the index file alone, +so you still need to do the final sanity checks with `git diff` +(or `git diff -c`) and 'git-add' when you are satisfied. + +As a convenience measure, 'git-merge' automatically invokes +'git-rerere' upon exiting with a failed automerge and 'git-rerere' +records the hand resolve when it is a new conflict, or reuses the earlier hand +resolve when it is not. 'git-commit' also invokes 'git-rerere' +when committing a merge result. What this means is that you do +not have to do anything special yourself (besides enabling +the rerere.enabled config variable). + +In our example, when you do the test merge, the manual +resolution is recorded, and it will be reused when you do the +actual merge later with the updated master and topic branch, as long +as the recorded resolution is still applicable. + +The information 'git-rerere' records is also used when running +'git-rebase'. After blowing away the test merge and continuing +development on the topic branch: + +------------ + o---*---o-------o---o topic + / + o---o---o---*---o---o---o---o master + + $ git rebase master topic + + o---*---o-------o---o topic + / + o---o---o---*---o---o---o---o master +------------ + +you could run `git rebase master topic`, to bring yourself +up-to-date before your topic is ready to be sent upstream. +This would result in falling back to a three-way merge, and it +would conflict the same way as the test merge you resolved earlier. +'git-rerere' will be run by 'git-rebase' to help you resolve this +conflict. + + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt new file mode 100644 index 0000000000..2d27e405a3 --- /dev/null +++ b/Documentation/git-reset.txt @@ -0,0 +1,248 @@ +git-reset(1) +============ + +NAME +---- +git-reset - Reset current HEAD to the specified state + +SYNOPSIS +-------- +[verse] +'git reset' [--mixed | --soft | --hard | --merge] [-q] [<commit>] +'git reset' [-q] [<commit>] [--] <paths>... +'git reset' --patch [<commit>] [--] [<paths>...] + +DESCRIPTION +----------- +Sets the current head to the specified commit and optionally resets the +index and working tree to match. + +This command is useful if you notice some small error in a recent +commit (or set of commits) and want to redo that part without showing +the undo in the history. + +If you want to undo a commit other than the latest on a branch, +linkgit:git-revert[1] is your friend. + +The second and third forms with 'paths' and/or --patch are used to +revert selected paths in the index from a given commit, without moving +HEAD. + + +OPTIONS +------- +--mixed:: + 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. + +--soft:: + Does not touch the index file nor the working tree at all, but + requires them to be in a good order. This leaves all your changed + files "Changes to be committed", as 'git-status' would + put it. + +--hard:: + Matches the working tree and index to that of the tree being + switched to. Any changes to tracked files in the working tree + since <commit> are lost. + +--merge:: + Resets the index to match the tree recorded by the named commit, + and updates the files that are different between the named commit + and the current commit in the working tree. + +-p:: +--patch:: + Interactively select hunks in the difference between the index + and <commit> (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` (see +linkgit:git-add[1]). + +-q:: + Be quiet, only report errors. + +<commit>:: + Commit to make the current HEAD. If not given defaults to HEAD. + +Examples +-------- + +Undo a commit and redo:: ++ +------------ +$ git commit ... +$ git reset --soft HEAD^ <1> +$ edit <2> +$ git commit -a -c ORIG_HEAD <3> +------------ ++ +<1> This is most often done when you remembered what you +just committed is incomplete, or you misspelled your commit +message, or both. Leaves working tree as it was before "reset". +<2> Make corrections to working tree files. +<3> "reset" copies the old head to .git/ORIG_HEAD; redo the +commit by starting with its log message. If you do not need to +edit the message further, you can give -C option instead. ++ +See also the --amend option to linkgit:git-commit[1]. + +Undo commits permanently:: ++ +------------ +$ git commit ... +$ git reset --hard HEAD~3 <1> +------------ ++ +<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad +and you do not want to ever see them again. Do *not* do this if +you have already given these commits to somebody else. (See the +"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for +the implications of doing so.) + +Undo a commit, making it a topic branch:: ++ +------------ +$ git branch topic/wip <1> +$ git reset --hard HEAD~3 <2> +$ git checkout topic/wip <3> +------------ ++ +<1> You have made some commits, but realize they were premature +to be in the "master" branch. You want to continue polishing +them in a topic branch, so create "topic/wip" branch off of the +current HEAD. +<2> Rewind the master branch to get rid of those three commits. +<3> Switch to "topic/wip" branch and keep working. + +Undo add:: ++ +------------ +$ edit <1> +$ git add frotz.c filfre.c +$ mailx <2> +$ git reset <3> +$ git pull git://info.example.com/ nitfol <4> +------------ ++ +<1> You are happily working on something, and find the changes +in these files are in good order. You do not want to see them +when you run "git diff", because you plan to work on other files +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 +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 +changes still in the working tree. + +Undo a merge or pull:: ++ +------------ +$ git pull <1> +Auto-merging nitfol +CONFLICT (content): Merge conflict in nitfol +Automatic merge failed; fix conflicts and then commit the result. +$ git reset --hard <2> +$ git pull . topic/branch <3> +Updating from 41223... to 13134... +Fast-forward +$ git reset --hard ORIG_HEAD <4> +------------ ++ +<1> Try to update from the upstream resulted in a lot of +conflicts; you were not ready to spend a lot of time merging +right now, so you decide to do that later. +<2> "pull" has not made merge commit, so "git reset --hard" +which is a synonym for "git reset --hard HEAD" clears the mess +from the index file and the working tree. +<3> Merge a topic branch into the current branch, which resulted +in a fast-forward. +<4> But you decided that the topic branch is not ready for public +consumption yet. "pull" or "merge" always leaves the original +tip of the current branch in ORIG_HEAD, so resetting hard to it +brings your index file and the working tree back to that state, +and resets the tip of the branch to that commit. + +Undo a merge or pull inside a dirty work tree:: ++ +------------ +$ git pull <1> +Auto-merging nitfol +Merge made by recursive. + nitfol | 20 +++++---- + ... +$ git reset --merge ORIG_HEAD <2> +------------ ++ +<1> Even if you may have local modifications in your +working tree, you can safely say "git pull" when you know +that the change in the other branch does not overlap with +them. +<2> After inspecting the result of the merge, you may find +that the change in the other branch is unsatisfactory. Running +"git reset --hard ORIG_HEAD" will let you go back to where you +were, but it will discard your local changes, which you do not +want. "git reset --merge" keeps your local changes. + + +Interrupted workflow:: ++ +Suppose you are interrupted by an urgent fix request while you +are in the middle of a large change. The files in your +working tree are not in any shape to be committed yet, but you +need to get to the other branch for a quick bugfix. ++ +------------ +$ git checkout feature ;# you were working in "feature" branch and +$ work work work ;# got interrupted +$ git commit -a -m "snapshot WIP" <1> +$ git checkout master +$ fix fix fix +$ git commit ;# commit with real log +$ git checkout feature +$ git reset --soft HEAD^ ;# go back to WIP state <2> +$ git reset <3> +------------ ++ +<1> This commit will get blown away so a throw-away log message is OK. +<2> This removes the 'WIP' commit from the commit history, and sets + your working tree to the state just before you made that snapshot. +<3> At this point the index file still has all the WIP changes you + committed as 'snapshot WIP'. This updates the index to show your + WIP files as uncommitted. ++ +See also linkgit:git-stash[1]. + +Reset a single file in the index:: ++ +Suppose you have added a file to your index, but later decide you do not +want to add it to your commit. You can remove the file from the index +while keeping your changes with git reset. ++ +------------ +$ git reset -- frotz.c <1> +$ git commit -m "Commit files in index" <2> +$ git add frotz.c <3> +------------ ++ +<1> This removes the file from the index while keeping it in the working + directory. +<2> This commits all other changes in the index. +<3> Adds the file to the index again. + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> and Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt new file mode 100644 index 0000000000..3341d1b62f --- /dev/null +++ b/Documentation/git-rev-list.txt @@ -0,0 +1,119 @@ +git-rev-list(1) +=============== + +NAME +---- +git-rev-list - Lists commit objects in reverse chronological order + + +SYNOPSIS +-------- +[verse] +'git-rev-list' [ \--max-count=number ] + [ \--skip=number ] + [ \--max-age=timestamp ] + [ \--min-age=timestamp ] + [ \--sparse ] + [ \--merges ] + [ \--no-merges ] + [ \--first-parent ] + [ \--remove-empty ] + [ \--full-history ] + [ \--not ] + [ \--all ] + [ \--branches ] + [ \--tags ] + [ \--remotes ] + [ \--stdin ] + [ \--quiet ] + [ \--topo-order ] + [ \--parents ] + [ \--timestamp ] + [ \--left-right ] + [ \--cherry-pick ] + [ \--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 ] ] + [ \--pretty | \--header ] + [ \--bisect ] + [ \--bisect-vars ] + [ \--bisect-all ] + [ \--merge ] + [ \--reverse ] + [ \--walk-reflogs ] + [ \--no-walk ] [ \--do-walk ] + <commit>... [ \-- <paths>... ] + +DESCRIPTION +----------- + +List commits that are reachable by following the `parent` links from the +given commit(s), but exclude commits that are reachable from the one(s) +given with a '{caret}' in front of them. The output is given in reverse +chronological order by default. + +You can think of this as a set operation. Commits given on the command +line form a set of commits that are reachable from any of them, and then +commits reachable from any of the ones given with '{caret}' in front are +subtracted from that set. The remaining commits are what comes out in the +command's output. Various other options and paths parameters can be used +to further limit the result. + +Thus, the following command: + +----------------------------------------------------------------------- + $ git rev-list foo bar ^baz +----------------------------------------------------------------------- + +means "list all the commits which are reachable from 'foo' or 'bar', but +not from 'baz'". + +A special notation "'<commit1>'..'<commit2>'" can be used as a +short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of +the following may be used interchangeably: + +----------------------------------------------------------------------- + $ git rev-list origin..HEAD + $ git rev-list HEAD ^origin +----------------------------------------------------------------------- + +Another special notation is "'<commit1>'...'<commit2>'" which is useful +for merges. The resulting set of commits is the symmetric difference +between the two operands. The following two commands are equivalent: + +----------------------------------------------------------------------- + $ git rev-list A B --not $(git merge-base --all A B) + $ git rev-list A...B +----------------------------------------------------------------------- + +'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 +'git-repack'. + +OPTIONS +------- + +:git-rev-list: 1 +include::rev-list-options.txt[] + +include::pretty-formats.txt[] + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano, Jonas Fonseca +and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt new file mode 100644 index 0000000000..82045a2522 --- /dev/null +++ b/Documentation/git-rev-parse.txt @@ -0,0 +1,484 @@ +git-rev-parse(1) +================ + +NAME +---- +git-rev-parse - Pick out and massage parameters + + +SYNOPSIS +-------- +'git rev-parse' [ --option ] <args>... + +DESCRIPTION +----------- + +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 +downstream of 'git-rev-list'. This command is used to +distinguish between them. + + +OPTIONS +------- +--parseopt:: + Use 'git-rev-parse' in option parsing mode (see PARSEOPT section below). + +--keep-dashdash:: + Only meaningful in `--parseopt` mode. Tells the option parser to echo + out the first `--` met instead of skipping it. + +--stop-at-non-option:: + Only meaningful in `--parseopt` mode. Lets the option parser stop at + the first non-option argument. This can be used to parse sub-commands + that take options themself. + +--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. + +--revs-only:: + Do not output flags and parameters not meant for + 'git-rev-list' command. + +--no-revs:: + Do not output flags and parameters meant for + 'git-rev-list' command. + +--flags:: + Do not output non-flag parameters. + +--no-flags:: + Do not output flag parameters. + +--default <arg>:: + If there is no parameter given by the user, use `<arg>` + instead. + +--verify:: + The parameter given must be usable as a single, valid + object name. Otherwise barf and abort. + +-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. + +--sq:: + Usually the output is made one line per flag and + parameter. This option makes output a single line, + properly quoted for consumption by shell. Useful when + you expect your parameter to contain whitespaces and + newlines (e.g. when using pickaxe `-S` with + 'git-diff-\*'). In contrast to the `--sq-quote` option, + the command input is still interpreted as usual. + +--not:: + When showing object names, prefix them with '{caret}' and + strip '{caret}' prefix from the object names that already have + one. + +--symbolic:: + Usually the object names are output in SHA1 form (with + possible '{caret}' prefix); this option makes them output in a + form as close to the original input as possible. + +--symbolic-full-name:: + This is similar to \--symbolic, but it omits input that + are not refs (i.e. branch or tag names; or more + explicitly disambiguating "heads/master" form, when you + want to name the "master" branch when there is an + 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. + +--all:: + Show all refs found in `$GIT_DIR/refs`. + +--branches:: + Show branch refs found in `$GIT_DIR/refs/heads`. + +--tags:: + Show tag refs found in `$GIT_DIR/refs/tags`. + +--remotes:: + Show tag refs found in `$GIT_DIR/refs/remotes`. + +--show-prefix:: + When the command is invoked from a subdirectory, show the + path of the current directory relative to the top-level + directory. + +--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). + +--git-dir:: + Show `$GIT_DIR` if defined else show the path to the .git directory. + +--is-inside-git-dir:: + When the current working directory is below the repository + directory print "true", otherwise "false". + +--is-inside-work-tree:: + When the current working directory is inside the work tree of the + repository print "true", otherwise "false". + +--is-bare-repository:: + When the repository is bare print "true", otherwise "false". + +--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. + +--since=datestring:: +--after=datestring:: + Parse the date string, and output the corresponding + --max-age= parameter for 'git-rev-list'. + +--until=datestring:: +--before=datestring:: + Parse the date string, and output the corresponding + --min-age= parameter for 'git-rev-list'. + +<args>...:: + Flags and parameters to be parsed. + + +SPECIFYING REVISIONS +-------------------- + +A revision parameter typically, but not necessarily, names a +commit object. They use what is called an 'extended SHA1' +syntax. Here are various ways to spell object names. The +ones listed near the end of this list are to name trees and +blobs contained in a commit. + +* The full SHA1 object name (40-byte hexadecimal string), or + a substring of such that is unique within the repository. + E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both + name the same commit object if there are no other object in + your repository whose object name starts with dae86e. + +* An output from 'git-describe'; i.e. a closest tag, optionally + followed by a dash and a number of commits, followed by a dash, a + `g`, and an abbreviated object name. + +* A symbolic ref name. E.g. 'master' typically means the commit + object referenced by $GIT_DIR/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 + first match in the following rules: + + . if `$GIT_DIR/<name>` exists, that is what you mean (this is usually + useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD` and `MERGE_HEAD`); + + . otherwise, `$GIT_DIR/refs/<name>` if exists; + + . otherwise, `$GIT_DIR/refs/tags/<name>` if exists; + + . otherwise, `$GIT_DIR/refs/heads/<name>` if exists; + + . otherwise, `$GIT_DIR/refs/remotes/<name>` if exists; + + . otherwise, `$GIT_DIR/refs/remotes/<name>/HEAD` if exists. ++ +HEAD names the commit your changes in the working tree is based on. +FETCH_HEAD records the branch you fetched from a remote repository +with your last 'git-fetch' invocation. +ORIG_HEAD is created by commands that moves your HEAD in a drastic +way, to record the position of the HEAD before their operation, so that +you can change the tip of the branch back to the state before you ran +them easily. +MERGE_HEAD records the commit(s) you are merging into your branch +when you run 'git-merge'. + +* A ref followed by the suffix '@' with a date specification + enclosed in a brace + pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1 + second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value + of the ref at a prior point in time. This suffix may only be + used immediately following a ref name and the ref must have an + existing log ($GIT_DIR/logs/<ref>). Note that this looks up the state + of your *local* ref at a given time; e.g., what was in your local + `master` branch last week. If you want to look at commits made during + certain times, see `--since` and `--until`. + +* A ref followed by the suffix '@' with an ordinal specification + enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify + the n-th prior value of that ref. For example 'master@\{1\}' + is the immediate prior value of 'master' while 'master@\{5\}' + is the 5th prior value of 'master'. This suffix may only be used + immediately following a ref name and the ref must have an existing + log ($GIT_DIR/logs/<ref>). + +* You can use the '@' construct with an empty ref part to get at a + reflog of the current branch. For example, if you are on the + branch 'blabla', then '@\{1\}' means the same as 'blabla@\{1\}'. + +* The special construct '@\{-<n>\}' means the <n>th branch checked out + before the current one. + +* A suffix '{caret}' to a revision parameter means the first parent of + that commit object. '{caret}<n>' means the <n>th parent (i.e. + 'rev{caret}' + is equivalent to 'rev{caret}1'). As a special rule, + 'rev{caret}0' means the commit itself and is used when 'rev' is the + object name of a tag object that refers to a commit object. + +* A suffix '{tilde}<n>' to a revision parameter means the commit + object that is the <n>th generation grand-parent of the named + commit object, following only the first parent. I.e. rev~3 is + equivalent to rev{caret}{caret}{caret} which is equivalent to + rev{caret}1{caret}1{caret}1. See below for a illustration of + the usage of this form. + +* A suffix '{caret}' followed by an object type name enclosed in + brace pair (e.g. `v0.99.8{caret}\{commit\}`) 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` + introduced earlier is a short-hand for `rev{caret}\{commit\}`. + +* A suffix '{caret}' followed by an empty brace pair + (e.g. `v0.99.8{caret}\{\}`) means the object could be a tag, + and dereference the tag recursively until a non-tag object is + found. + +* A colon, followed by a slash, followed by a text: this names + a commit whose commit message starts with the specified text. + This name returns the youngest matching commit which is + reachable from any ref. If the commit message starts with a + '!', you have to repeat that; the special sequence ':/!', + followed by something else than '!' is reserved for now. + +* A suffix ':' followed by a path; this names the blob or tree + at the given path in the tree-ish object named by the part + before the colon. + +* A colon, optionally followed by a stage number (0 to 3) and a + colon, followed by a path; this names a blob object in the + index at the given path. Missing stage number (and the colon + that follows it) names a stage 0 entry. During a merge, stage + 1 is the common ancestor, stage 2 is the target branch's version + (typically the current branch), and stage 3 is the version from + the branch being merged. + +Here is an illustration, by Jon Loeliger. Both commit nodes B +and C are parents of commit node A. Parent commits are ordered +left-to-right. + +........................................ +G H I J + \ / \ / + D E F + \ | / \ + \ | / | + \|/ | + B C + \ / + \ / + A +........................................ + + A = = A^0 + B = A^ = A^1 = A~1 + C = A^2 = A^2 + D = A^^ = A^1^1 = A~2 + E = B^2 = A^^2 + F = B^3 = A^^3 + G = A^^^ = A^1^1^1 = A~3 + H = D^2 = B^^2 = A^^^2 = A~2^2 + I = F^ = B^3^ = A^^3^ + J = F^2 = B^3^2 = A^^3^2 + + +SPECIFYING RANGES +----------------- + +History traversing commands such as 'git-log' operate on a set +of commits, not just a single commit. To these commands, +specifying a single revision with the notation described in the +previous section means the set of commits reachable from that +commit, following the commit ancestry chain. + +To exclude commits reachable from a commit, a prefix `{caret}` +notation is used. E.g. `{caret}r1 r2` means commits reachable +from `r2` but exclude the ones reachable from `r1`. + +This set operation appears so often that there is a shorthand +for it. When you have two commits `r1` and `r2` (named according +to the syntax explained in SPECIFYING REVISIONS above), you can ask +for commits that are reachable from r2 excluding those that are reachable +from r1 by `{caret}r1 r2` and it can be written as `r1..r2`. + +A similar notation `r1\...r2` is called symmetric difference +of `r1` and `r2` and is defined as +`r1 r2 --not $(git merge-base --all r1 r2)`. +It is the set of commits that are reachable from either one of +`r1` or `r2` but not from both. + +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. + +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 G H D E B C + ^D B C E I J F B C + C^@ I J F + F^! D G H D F + +PARSEOPT +-------- + +In `--parseopt` mode, 'git-rev-parse' helps massaging options to bring to shell +scripts the same facilities C builtins have. It works as an option normalizer +(e.g. splits single switches aggregate values), a bit like `getopt(1)` does. + +It takes on the standard input the specification of the options to parse and +understand, and echoes on the standard output a line suitable for `sh(1)` `eval` +to replace the arguments with normalized ones. In case of error, it outputs +usage on the standard error stream, and exits with code 129. + +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. +The lines after the separator describe the options. + +Each line of options has this format: + +------------ +<opt_spec><flags>* SP+ help LF +------------ + +`<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>`. + +`<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 this option should not be listed in the usage + generated for the `-h` argument. It's shown for `--help-all` as + documented in linkgit:gitcli[7]. + + * Use `!` to not make the corresponding negated long option available. + +The remainder of the line, after stripping the spaces, is used +as the help associated to the option. + +Blank lines are ignored, and lines that don't match this specification are used +as option group headers (start the line with a space to create such +lines on purpose). + +Example +~~~~~~~ + +------------ +OPTS_SPEC="\ +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 + + An option group Header +C? option C with an optional argument" + +eval `echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?` +------------ + +SQ-QUOTE +-------- + +In `--sq-quote` mode, 'git-rev-parse' echoes on the standard output a +single line suitable for `sh(1)` `eval`. This line is made by +normalizing the arguments following `--sq-quote`. Nothing other than +quoting the arguments is done. + +If you want command input to still be interpreted as usual by +'git-rev-parse' before the output is shell quoted, see the `--sq` +option. + +Example +~~~~~~~ + +------------ +$ cat >your-git-script.sh <<\EOF +#!/bin/sh +args=$(git rev-parse --sq-quote "$@") # quote user-supplied arguments +command="git frotz -n24 $args" # and use it inside a handcrafted + # command line +eval "$command" +EOF + +$ sh your-git-script.sh "a b'c" +------------ + +EXAMPLES +-------- + +* Print the object name of the current commit: ++ +------------ +$ git rev-parse --verify HEAD +------------ + +* Print the commit object name from the revision in the $REV shell variable: ++ +------------ +$ git rev-parse --verify $REV +------------ ++ +This will error out if $REV is empty or not a valid revision. + +* Same as above: ++ +------------ +$ git rev-parse --default master --verify $REV +------------ ++ +but if $REV is empty, the commit object name from master will be printed. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> . +Junio C Hamano <gitster@pobox.com> and Pierre Habouzit <madcoder@debian.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt new file mode 100644 index 0000000000..5e1175800a --- /dev/null +++ b/Documentation/git-revert.txt @@ -0,0 +1,89 @@ +git-revert(1) +============= + +NAME +---- +git-revert - Revert an existing commit + +SYNOPSIS +-------- +'git revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit> + +DESCRIPTION +----------- +Given one existing commit, revert the change the patch introduces, and record a +new commit that records it. This requires your working tree to be clean (no +modifications from the HEAD commit). + +Note: 'git revert' is used to record a new commit to reverse the +effect of an earlier commit (often a faulty one). If you want to +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 +both will discard uncommitted changes in your working directory. + +OPTIONS +------- +<commit>:: + Commit to revert. + For a more complete list of ways to spell commit names, see + "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. + +-e:: +--edit:: + With this option, 'git-revert' will let you edit the commit + message prior to committing the revert. This is the default if + you run the command from a terminal. + +-m parent-number:: +--mainline parent-number:: + Usually you cannot revert a merge because you do not know which + side of the merge should be considered the mainline. This + option specifies the parent number (starting from 1) of + the mainline and allows revert to reverse the change + relative to the specified parent. ++ +Reverting a merge commit declares that you will never want the tree changes +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 +more details. + +--no-edit:: + With this option, 'git-revert' will not start the commit + message editor. + +-n:: +--no-commit:: + Usually the command automatically creates a commit with + a commit log message stating which commit was + reverted. This flag applies the change necessary + to revert the named commit to your working tree + and the index, but does not make the commit. In addition, + when this option is used, your index does not have to match + the HEAD commit. The revert is done against the + beginning state of your index. ++ +This is useful when reverting more than one commits' +effect to your index in a row. + +-s:: +--signoff:: + Add Signed-off-by line at the end of the commit message. + + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt new file mode 100644 index 0000000000..5afb1e7428 --- /dev/null +++ b/Documentation/git-rm.txt @@ -0,0 +1,113 @@ +git-rm(1) +========= + +NAME +---- +git-rm - Remove files from the working tree and from the index + +SYNOPSIS +-------- +'git rm' [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>... + +DESCRIPTION +----------- +Remove files from the index, or from the working tree and the index. +'git-rm' will not remove a file from just your working directory. +(There is no option to remove a file only from the work tree +and yet keep it in the index; use `/bin/rm` if you want to do that.) +The files being removed have to be identical to the tip of the branch, +and no updates to their contents can be staged in the index, +though that default behavior can be overridden with the `-f` option. +When '--cached' is given, the staged content has to +match either the tip of the branch or the file on disk, +allowing the file to be removed from just the index. + + +OPTIONS +------- +<file>...:: + Files to remove. Fileglobs (e.g. `*.c`) can be given to + 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 + given to remove all files in the directory, and recursively + all sub-directories, + but this requires the `-r` option to be explicitly given. + +-f:: +--force:: + Override the up-to-date check. + +-n:: +--dry-run:: + Don't actually remove any file(s). Instead, just show + if they exist in the index and would otherwise be removed + by the command. + +-r:: + Allow recursive removal when a leading directory name is + given. + +\--:: + This option can be used to separate command-line options from + the list of files, (useful when filenames might be mistaken + for command-line options). + +--cached:: + Use this option to unstage and remove paths only from the index. + Working tree files, whether modified or not, will be + left alone. + +--ignore-unmatch:: + Exit with a zero status even if no files matched. + +-q:: +--quiet:: + 'git-rm' normally outputs one line (in the form of an "rm" command) + for each file removed. This option suppresses that output. + + +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. + +File globbing matches across directory boundaries. Thus, given +two directories `d` and `d2`, there is a difference between +using `git rm \'d\*\'` and `git rm \'d/\*\'`, as the former will +also remove all of directory `d2`. + +EXAMPLES +-------- +git rm Documentation/\\*.txt:: + Removes all `\*.txt` files from the index that are under the + `Documentation` directory and any of its subdirectories. ++ +Note that the asterisk `\*` is quoted from the shell in this +example; this lets git, and not the shell, expand the pathnames +of files and subdirectories under the `Documentation/` directory. + +git rm -f git-*.sh:: + Because this example lets the shell expand the asterisk + (i.e. you are listing the files explicitly), it + does not remove `subdir/git-foo.sh`. + +SEE ALSO +-------- +linkgit:git-add[1] + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt new file mode 100644 index 0000000000..8c482f40b9 --- /dev/null +++ b/Documentation/git-send-email.txt @@ -0,0 +1,318 @@ +git-send-email(1) +================= + +NAME +---- +git-send-email - Send a collection of patches as emails + + +SYNOPSIS +-------- +'git send-email' [options] <file|directory|rev-list options>... + + +DESCRIPTION +----------- +Takes the patches given on the command line and emails them out. +Patches can be specified as files, directories (which will send all +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 +specified on the command line, the user will be prompted with a ReadLine +enabled interface to provide the necessary information. + +There are two formats accepted for patch files: + +1. mbox format files ++ +This is what linkgit:git-format-patch[1] generates. Most headers and MIME +formatting are ignored. + +2. The original format used by Greg Kroah-Hartman's 'send_lots_of_email.pl' +script ++ +This format expects the first line of the file to contain the "Cc:" value +and the "Subject:" of the message as the second line. + + +OPTIONS +------- + +Composing +~~~~~~~~~ + +--annotate:: + Review and edit each patch you're about to send. See the + CONFIGURATION section for 'sendemail.multiedit'. + +--bcc=<address>:: + Specify a "Bcc:" value for each email. Default is the value of + 'sendemail.bcc'. ++ +The --bcc option must be repeated for each user you want on the bcc list. + +--cc=<address>:: + Specify a starting "Cc:" value for each email. + Default is the value of 'sendemail.cc'. ++ +The --cc option must be repeated for each user you want on the cc list. + +--compose:: + Invoke a text editor (see GIT_EDITOR in linkgit:git-var[1]) + to edit an introductory message for the patch series. ++ +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, +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'. + +--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 + 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". + +--in-reply-to=<identifier>:: + Specify the contents of the first In-Reply-To header. + Subsequent emails will refer to the previous email + instead of this if --chain-reply-to is set (the default) + Only necessary if --compose is also set. If --compose + is not set, this will be prompted for. + +--subject=<string>:: + Specify the initial subject of the email thread. + Only necessary if --compose is also set. If --compose + is not set, this will be prompted for. + +--to=<address>:: + Specify the primary recipient of the emails generated. Generally, this + will be the upstream maintainer of the project involved. Default is the + value of the 'sendemail.to' configuration value; if that is unspecified, + this will be prompted for. ++ +The --to option must be repeated for each user you want on the to list. + + +Sending +~~~~~~~ + +--envelope-sender=<address>:: + Specify the envelope sender used to send the emails. + This is useful if your default address is not the address that is + 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 + 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'. + +--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', + 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-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 + option; the built-in default is `/usr/sbin/sendmail` or + `/usr/lib/sendmail` if such program is available, or + `localhost` otherwise. + +--smtp-server-port=<port>:: + Specifies a port different from the default port (SMTP + servers typically listen to smtp port 25, but may also listen to + 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. + +--smtp-ssl:: + Legacy alias for '--smtp-encryption ssl'. + +--smtp-user=<user>:: + Username for SMTP-AUTH. Default is the value of 'sendemail.smtpuser'; + if a username is not specified (with '--smtp-user' or 'sendemail.smtpuser'), + then authentication is not attempted. + + +Automating +~~~~~~~~~~ + +--cc-cmd=<command>:: + 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. + +--[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. Default is the value of the 'sendemail.chainreplyto' + configuration value; if that is unspecified, default to --chain-reply-to. + +--identity=<identity>:: + A configuration identity. When given, causes values in the + 'sendemail.<identity>' subsection to take precedence over + values in the 'sendemail' section. The default identity is + the value of 'sendemail.identity'. + +--[no-]signed-off-by-cc:: + If this is set, add emails found in Signed-off-by: or Cc: lines to the + cc list. Default is the value of 'sendemail.signedoffbycc' configuration + value; if that is unspecified, default to --signed-off-by-cc. + +--suppress-cc=<category>:: + Specify an additional category of recipients to suppress the + auto-cc of: ++ +-- +- 'author' will avoid including the patch author +- 'self' will avoid including the sender +- 'cc' will avoid including anyone mentioned in Cc lines in the patch header + except for self (use 'self' for that). +- 'bodycc' will avoid including anyone mentioned in Cc lines in the + patch body (commit message) except for self (use 'self' for that). +- 'sob' will avoid including anyone mentioned in Signed-off-by lines except + for self (use 'self' for that). +- 'cccmd' will avoid running the --cc-cmd. +- 'body' is equivalent to 'sob' + 'bodycc' +- 'all' will suppress all auto cc values. +-- ++ +Default is the value of 'sendemail.suppresscc' configuration value; if +that is unspecified, default to 'self' if --suppress-from is +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 + value; if that is unspecified, default to --no-suppress-from. + +--[no-]thread:: + If this is set, the In-Reply-To and References headers will be + added to each email sent. Whether each mail refers to the + previous email (`deep` threading per 'git format-patch' + wording) or to the first email (`shallow` threading) is + governed by "--[no-]chain-reply-to". ++ +If disabled with "--no-thread", those headers will not be added +(unless specified with --in-reply-to). Default is the value of the +'sendemail.thread' configuration value; if that is unspecified, +default to --thread. ++ +It is up to the user to ensure that no In-Reply-To header already +exists when 'git send-email' is asked to add it (especially note that +'git format-patch' can be configured to do the threading itself). +Failure to do so may not produce the expected result in the +recipient's MUA. + + +Administering +~~~~~~~~~~~~~ + +--confirm=<mode>:: + Confirm just before sending: ++ +-- +- 'always' will always confirm before sending +- 'never' will never confirm before sending +- 'cc' will confirm before sending when send-email has automatically + added addresses from the patch to the Cc list +- 'compose' will confirm before sending the first message when using --compose. +- 'auto' is equivalent to 'cc' + 'compose' +-- ++ +Default is the value of 'sendemail.confirm' configuration value; if that +is unspecified, default to 'auto' unless any of the suppress options +have been specified, in which case default to 'compose'. + +--dry-run:: + Do everything except actually send the emails. + +--[no-]format-patch:: + When an argument may be understood either as a reference or as a file name, + choose to understand it as a format-patch argument ('--format-patch') + or as a file name ('--no-format-patch'). By default, when such a conflict + occurs, git send-email will fail. + +--quiet:: + Make git-send-email less verbose. One line per email should be + all that is output. + +--[no-]validate:: + Perform sanity checks on patches. + Currently, validation means the following: ++ +-- + * Warn of patches that contain lines longer than 998 characters; this + is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt. +-- ++ +Default is the value of 'sendemail.validate'; if this is not set, +default to '--validate'. + + +CONFIGURATION +------------- + +sendemail.aliasesfile:: + To avoid typing long email addresses, point this to one or more + email aliases files. You must also supply 'sendemail.aliasfiletype'. + +sendemail.aliasfiletype:: + Format of the file(s) specified in sendemail.aliasesfile. Must be + one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'. + +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 + after the other, spawning a new editor each time. + +sendemail.confirm:: + Sets the default for whether to confirm before sending. Must be + one of 'always', 'never', 'cc', 'compose', or 'auto'. See '--confirm' + in the previous section for the meaning of these values. + + +Author +------ +Written by Ryan Anderson <ryan@michonline.com> + +git-send-email is originally based upon +send_lots_of_email.pl by Greg Kroah-Hartman. + + +Documentation +-------------- +Documentation by Ryan Anderson + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt new file mode 100644 index 0000000000..5a04c6eaf7 --- /dev/null +++ b/Documentation/git-send-pack.txt @@ -0,0 +1,128 @@ +git-send-pack(1) +================ + +NAME +---- +git-send-pack - Push objects over git protocol to another repository + + +SYNOPSIS +-------- +'git send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...] + +DESCRIPTION +----------- +Usually you would want to use 'git-push', which is a +higher-level wrapper of this command, instead. See linkgit:git-push[1]. + +Invokes 'git-receive-pack' on a possibly remote repository, and +updates it from the current repository, sending named refs. + + +OPTIONS +------- +--receive-pack=<git-receive-pack>:: + Path to the 'git-receive-pack' program on the remote + end. Sometimes useful when pushing to a remote + repository over ssh, and you do not have the program in + a directory on the default $PATH. + +--exec=<git-receive-pack>:: + Same as \--receive-pack=<git-receive-pack>. + +--all:: + Instead of explicitly specifying which refs to update, + update all heads that locally exist. + +--dry-run:: + Do everything except actually send the updates. + +--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. What this means is that + the remote repository can lose commits; use it with + care. + +--verbose:: + Run verbosely. + +--thin:: + Spend extra cycles to minimize the number of objects to be sent. + Use it on slower connection. + +<host>:: + A remote host to house the repository. When this + part is specified, 'git-receive-pack' is invoked via + ssh. + +<directory>:: + The repository to update. + +<ref>...:: + The remote refs to update. + + +Specifying the Refs +------------------- + +There are three ways to specify which refs to update on the +remote end. + +With '--all' flag, all refs that exist locally are transferred to +the remote side. You cannot specify any '<ref>' if you use +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 +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>'. + +Each pattern pair consists of the source side (before the colon) +and the destination side (after the colon). The ref to be +pushed is determined by finding a match that matches the source +side, and where it is pushed is determined by using the +destination side. The rules used to match a ref are the same +rules used by 'git-rev-parse' to resolve a symbolic ref +name. See linkgit:git-rev-parse[1]. + + - It is an error if <src> does not match exactly one of the + local refs. + + - It is an error if <dst> matches more than one remote refs. + + - If <dst> does not match any remote ref, either + + * it has to start with "refs/"; <dst> is used as the + destination literally in this case. + + * <src> == <dst> and the ref that matched the <src> must not + exist in the set of remote refs; the ref matched <src> + locally is used as the name of the destination. + +Without '--force', the <src> ref is stored at the remote only if +<dst> does not exist, or <dst> is a proper subset (i.e. an +ancestor) of <src>. This check, known as "fast-forward check", +is performed in order to avoid accidentally overwriting the +remote ref and lose other peoples' commits from there. + +With '--force', the fast-forward check is disabled for all refs. + +Optionally, a <ref> parameter can be prefixed with a plus '+' sign +to disable the fast-forward check only on that ref. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt new file mode 100644 index 0000000000..18f14b5be8 --- /dev/null +++ b/Documentation/git-sh-setup.txt @@ -0,0 +1,80 @@ +git-sh-setup(1) +=============== + +NAME +---- +git-sh-setup - Common git shell script setup code + +SYNOPSIS +-------- +'. "$(git --exec-path)/git-sh-setup"' + +DESCRIPTION +----------- + +This is not a command the end user would want to run. Ever. +This documentation is meant for people who are studying the +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. + +Before sourcing it, your script should set up a few variables; +`USAGE` (and `LONG_USAGE`, if any) is used to define message +given by `usage()` shell function. `SUBDIRECTORY_OK` can be set +if the script can run from a subdirectory of the working tree +(some commands do not). + +The scriptlet sets `GIT_DIR` and `GIT_OBJECT_DIRECTORY` shell +variables, but does *not* export them to the environment. + +FUNCTIONS +--------- + +die:: + exit after emitting the supplied error message to the + standard error stream. + +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. + +git_editor:: + runs an editor of user's choice (GIT_EDITOR, core.editor, VISUAL or + EDITOR) on a given file, but error out if no editor is specified + and the terminal is dumb. + +is_bare_repository:: + outputs `true` or `false` to the standard output stream + to indicate if the repository is a bare repository + (i.e. without an associated working tree). + +cd_to_toplevel:: + runs chdir to the toplevel of the working tree. + +require_work_tree:: + checks if the repository is a bare repository, and dies + if so. Used by scripts that require working tree + (e.g. `checkout`). + +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. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt new file mode 100644 index 0000000000..0f3ad811cf --- /dev/null +++ b/Documentation/git-shell.txt @@ -0,0 +1,35 @@ +git-shell(1) +============ + +NAME +---- +git-shell - Restricted login shell for GIT-only SSH access + + +SYNOPSIS +-------- +'$(git --exec-path)/git-shell' -c <command> <argument> + +DESCRIPTION +----------- +This is meant to be used as a login shell for SSH accounts you want +to restrict to GIT pull/push access only. It permits execution only +of server-side GIT commands implementing the pull/push functionality. +The commands can be executed only by the '-c' option; the shell is not +interactive. + +Currently, only four commands are permitted to be called, 'git-receive-pack' +'git-upload-pack' and 'git-upload-archive' with a single required argument, or +'cvs server' (to invoke 'git-cvsserver'). + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Petr Baudis and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt new file mode 100644 index 0000000000..42463a955d --- /dev/null +++ b/Documentation/git-shortlog.txt @@ -0,0 +1,69 @@ +git-shortlog(1) +=============== + +NAME +---- +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>]]]] [<committish>...] + +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. + +Additionally, "[PATCH]" will be stripped from the commit description. + +OPTIONS +------- + +-h:: +--help:: + Print a short usage message and exit. + +-n:: +--numbered:: + Sort output according to the number of commits per author instead + of author alphabetic order. + +-s:: +--summary:: + Suppress commit description and provide a commit count summary only. + +-e:: +--email:: + Show the email address of each author. + +-w[<width>[,<indent1>[,<indent2>]]]:: + Linewrap the output by wrapping each line at `width`. The first + 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. + + +MAPPING AUTHORS +--------------- + +The `.mailmap` feature is used to coalesce together commits by the same +person in the shortlog, where their name and/or email address was +spelled differently. + +include::mailmap.txt[] + + +Author +------ +Written by Jeff Garzik <jgarzik@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt new file mode 100644 index 0000000000..734336119c --- /dev/null +++ b/Documentation/git-show-branch.txt @@ -0,0 +1,214 @@ +git-show-branch(1) +================== + +NAME +---- +git-show-branch - Show branches and their commits + +SYNOPSIS +-------- +[verse] +'git show-branch' [-a|--all] [-r|--remotes] [--topo-order | --date-order] + [--current] [--color | --no-color] [--sparse] + [--more=<n> | --list | --independent | --merge-base] + [--no-name | --sha1-name] [--topics] + [<rev> | <glob>]... + +'git show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>] + +DESCRIPTION +----------- + +Shows the commit ancestry graph starting from the commits named +with <rev>s or <globs>s (or all refs under $GIT_DIR/refs/heads +and/or $GIT_DIR/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. + + +OPTIONS +------- +<rev>:: + Arbitrary extended SHA1 expression (see linkgit:git-rev-parse[1]) + that typically names a branch head or a tag. + +<glob>:: + A glob pattern that matches branch or tag names under + $GIT_DIR/refs. For example, if you have many topic + branches under $GIT_DIR/refs/heads/topic, giving + `topic/*` would show all of them. + +-r:: +--remotes:: + Show the remote-tracking branches. + +-a:: +--all:: + Show both remote-tracking branches and local branches. + +--current:: + With this option, the command includes the current + branch to the list of revs to be shown when it is not + given on the command line. + +--topo-order:: + By default, the branches and their commits are shown in + reverse chronological order. This option makes them + appear in topological order (i.e., descendant commits + are shown before their parents). + +--date-order:: + This option is similar to '--topo-order' in the sense that no + parent comes before all of its children, but otherwise commits + are ordered according to their commit date. + +--sparse:: + By default, the output omits merges that are reachable + from only one tip being shown. This option makes them + visible. + +--more=<n>:: + Usually the command stops output upon showing the commit + that is the common ancestor of all the branches. This + flag tells the command to go <n> more common commits + beyond that. When <n> is negative, display only the + <reference>s given, without showing the commit ancestry + tree. + +--list:: + Synonym to `--more=-1` + +--merge-base:: + Instead of showing the commit list, determine possible + merge bases for the specified commits. All merge bases + will be contained in all specified commits. This is + different from how linkgit:git-merge-base[1] handles + the case of three or more commits. + +--independent:: + Among the <reference>s given, display only the ones that + cannot be reached from any other <reference>. + +--no-name:: + Do not show naming strings for each commit. + +--sha1-name:: + Instead of naming the commits using the path to reach + them from heads (e.g. "master~2" to mean the grandparent + of "master"), name them with the unique prefix of their + object names. + +--topics:: + Shows only commits that are NOT on the first branch given. + This helps track topic branches by hiding any commit that + is already in the main line of development. When given + "git show-branch --topics master topic1 topic2", this + will show the revisions given by "git rev-list {caret}master + topic1 topic2" + +-g:: +--reflog[=<n>[,<base>]] [<ref>]:: + Shows <n> most recent ref-log entries for the given + ref. If <base> is given, <n> entries going back from + that entry. <base> can be specified as count or date. + When no explicit <ref> parameter is given, it defaults to the + current branch (or `HEAD` if it is detached). + +--color:: + Color the status sign (one of these: `*` `!` `+` `-`) of each commit + corresponding to the branch it's in. + +--no-color:: + Turn off colored output, even when the configuration file gives the + default to color output. + +Note that --more, --list, --independent and --merge-base options +are mutually exclusive. + + +OUTPUT +------ +Given N <references>, the first N lines are the one-line +description from their commit message. The branch head that is +pointed at by $GIT_DIR/HEAD is prefixed with an asterisk `*` +character while other heads are prefixed with a `!` character. + +Following these N lines, one-line log for each commit is +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. + +The following example shows three branches, "master", "fixes" +and "mhf": + +------------------------------------------------ +$ git show-branch master fixes mhf +* [master] Add 'git show-branch'. + ! [fixes] Introduce "reset type" flag to "git reset" + ! [mhf] Allow "+remote:local" refspec to cause --force when fetching. +--- + + [mhf] Allow "+remote:local" refspec to cause --force when fetching. + + [mhf~1] Use git-octopus when pulling more than one heads. + + [fixes] Introduce "reset type" flag to "git reset" + + [mhf~2] "git fetch --force". + + [mhf~3] Use .git/remote/origin, not .git/branches/origin. + + [mhf~4] Make "git pull" and "git fetch" default to origin + + [mhf~5] Infamous 'octopus merge' + + [mhf~6] Retire git-parse-remote. + + [mhf~7] Multi-head fetch. + + [mhf~8] Start adding the $GIT_DIR/remotes/ support. +*++ [master] Add 'git show-branch'. +------------------------------------------------ + +These three branches all forked from a common commit, [master], +whose commit message is "Add \'git show-branch\'". The "fixes" +branch adds one commit "Introduce "reset type" flag to "git reset"". +The "mhf" branch adds many other commits. The current branch +is "master". + + +EXAMPLE +------- + +If you keep your primary branches immediately under +`$GIT_DIR/refs/heads`, and topic branches in subdirectories of +it, having the following in the configuration file may help: + +------------ +[showbranch] + default = --topo-order + default = heads/* + +------------ + +With this, `git show-branch` without extra parameters would show +only the primary branches. In addition, if you happen to be on +your topic branch, it is shown as well. + +------------ +$ git show-branch --reflog="10,1 hour ago" --list master +------------ + +shows 10 reflog entries going back from the tip as of 1 hour ago. +Without `--list`, the output also shows how these tips are +topologically related with each other. + + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + + +Documentation +-------------- +Documentation by Junio C Hamano. + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-show-index.txt b/Documentation/git-show-index.txt new file mode 100644 index 0000000000..e3285aacfd --- /dev/null +++ b/Documentation/git-show-index.txt @@ -0,0 +1,34 @@ +git-show-index(1) +================= + +NAME +---- +git-show-index - Show packed archive index + + +SYNOPSIS +-------- +'git show-index' < idx-file + + +DESCRIPTION +----------- +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. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt new file mode 100644 index 0000000000..70f400b266 --- /dev/null +++ b/Documentation/git-show-ref.txt @@ -0,0 +1,177 @@ +git-show-ref(1) +=============== + +NAME +---- +git-show-ref - List references in a local repository + +SYNOPSIS +-------- +[verse] +'git show-ref' [-q|--quiet] [--verify] [--head] [-d|--dereference] + [-s|--hash[=<n>]] [--abbrev[=<n>]] [--tags] + [--heads] [--] <pattern>... +'git show-ref' --exclude-existing[=<pattern>] < ref-list + +DESCRIPTION +----------- + +Displays references available in a local repository along with the associated +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. + +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. + +Use of this utility is encouraged in favor of directly accessing files under +the `.git` directory. + +OPTIONS +------- + +--head:: + + Show the HEAD reference. + +--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. + +-d:: +--dereference:: + + Dereference tags into object IDs as well. They will be shown with "^{}" + appended. + +-s:: +--hash[=<n>]:: + + Only show the SHA1 hash, not the reference name. When combined with + --dereference the dereferenced tag will still be shown after the SHA1. + +--verify:: + + Enable stricter reference checking by requiring an exact ref path. + Aside from returning an error code of 1, it will also print an error + message if '--quiet' was not specified. + +--abbrev[=<n>]:: + + Abbreviate the object name. When using `--hash`, you do + not have to say `--hash --abbrev`; `--hash=n` would do. + +-q:: +--quiet:: + + Do not print any results to stdout. When combined with '--verify' this + can be used to silently check if a reference exists. + +--exclude-existing[=<pattern>]:: + + Make 'git-show-ref' act as a filter that reads refs from stdin of the + form "^(?:<anything>\s)?<refname>(?:\^\{\})?$" and performs the + following actions on each: + (1) strip "^{}" at the end of line if any; + (2) ignore if pattern is provided and does not head-match refname; + (3) warn if refname is not a well-formed refname and skip; + (4) ignore if refname is a ref that exists in the local repository; + (5) otherwise output the line. + + +<pattern>...:: + + Show references matching one or more patterns. + +OUTPUT +------ + +The output is in the format: '<SHA-1 ID>' '<space>' '<reference name>'. + +----------------------------------------------------------------------------- +$ git show-ref --head --dereference +832e76a9899f560a90ffd62ae2ce83bbeff58f54 HEAD +832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/master +832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/origin +3521017556c5de4159da4615a39fa4d5d2c279b5 refs/tags/v0.99.9c +6ddc0964034342519a87fe013781abf31c6db6ad refs/tags/v0.99.9c^{} +055e4ae3ae6eb344cbabf2a5256a49ea66040131 refs/tags/v1.0rc4 +423325a2d24638ddcc82ce47be5e40be550f4507 refs/tags/v1.0rc4^{} +... +----------------------------------------------------------------------------- + +When using --hash (and not --dereference) the output format is: '<SHA-1 ID>' + +----------------------------------------------------------------------------- +$ git show-ref --heads --hash +2e3ba0114a1f52b47df29743d6915d056be13278 +185008ae97960c8d551adcd9e23565194651b5d1 +03adf42c988195b50e1a1935ba5fcbc39b2b029b +... +----------------------------------------------------------------------------- + +EXAMPLE +------- + +To show all references called "master", whether tags or heads or anything +else, and regardless of how deep in the reference naming hierarchy they are, +use: + +----------------------------------------------------------------------------- + git show-ref master +----------------------------------------------------------------------------- + +This will show "refs/heads/master" but also "refs/remote/other-repo/master", +if such references exists. + +When using the '--verify' flag, the command requires an exact path: + +----------------------------------------------------------------------------- + git show-ref --verify refs/heads/master +----------------------------------------------------------------------------- + +will only match the exact branch called "master". + +If nothing matches, 'git-show-ref' will return an error code of 1, +and in the case of verification, it will show an error message. + +For scripting, you can ask it to be quiet with the "--quiet" flag, which +allows you to do things like + +----------------------------------------------------------------------------- + git show-ref --quiet --verify -- "refs/heads/$headname" || + echo "$headname is not a valid branch" +----------------------------------------------------------------------------- + +to check whether a particular branch exists or not (notice how we don't +actually want to show any results, and we want to use the full refname for it +in order to not trigger the problem with ambiguous partial matches). + +To show only tags, or only proper branch heads, use "--tags" and/or "--heads" +respectively (using both means that it shows tags and heads, but not other +random references under the refs/ subdirectory). + +To do automatic tag object dereferencing, use the "-d" or "--dereference" +flag, so you can do + +----------------------------------------------------------------------------- + git show-ref --tags --dereference +----------------------------------------------------------------------------- + +to get a listing of all tags together with what they dereference. + +SEE ALSO +-------- +linkgit:git-ls-remote[1] + +AUTHORS +------- +Written by Linus Torvalds <torvalds@osdl.org>. +Man page by Jonas Fonseca <fonseca@diku.dk>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt new file mode 100644 index 0000000000..48b612e2ae --- /dev/null +++ b/Documentation/git-show.txt @@ -0,0 +1,84 @@ +git-show(1) +=========== + +NAME +---- +git-show - Show various types of objects + + +SYNOPSIS +-------- +'git show' [options] <object>... + +DESCRIPTION +----------- +Shows one or more objects (blobs, trees, tags and commits). + +For commits it shows the log message and textual diff. It also +presents the merge commit in a special format as produced by +'git-diff-tree --cc'. + +For tags, it shows the tag message and the referenced objects. + +For trees, it shows the names (equivalent to 'git-ls-tree' +with \--name-only). + +For plain blobs, it shows the plain contents. + +The command takes options applicable to the 'git-diff-tree' command to +control how the changes the commit introduces are shown. + +This manual page describes only the most frequently used options. + + +OPTIONS +------- +<object>...:: + The names of objects to show. + For a more complete list of ways to spell object names, see + "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. + +include::pretty-options.txt[] + + +include::pretty-formats.txt[] + + +EXAMPLES +-------- + +git show v1.0.0:: + Shows the tag `v1.0.0`, along with the object the tags + points at. + +git show v1.0.0^\{tree\}:: + Shows the tree pointed to by the tag `v1.0.0`. + +git show next~10:Documentation/README:: + Shows the contents of the file `Documentation/README` as + they were current in the 10th last commit of the branch + `next`. + +git show master:Makefile master:t/Makefile:: + Concatenates the contents of said Makefiles in the head + of the branch `master`. + +Discussion +---------- + +include::i18n.txt[] + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> and +Junio C Hamano <gitster@pobox.com>. Significantly enhanced by +Johannes Schindelin <Johannes.Schindelin@gmx.de>. + + +Documentation +------------- +Documentation by David Greaves, Petr Baudis and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-stage.txt b/Documentation/git-stage.txt new file mode 100644 index 0000000000..7f251a5865 --- /dev/null +++ b/Documentation/git-stage.txt @@ -0,0 +1,19 @@ +git-stage(1) +============== + +NAME +---- +git-stage - Add file contents to the staging area + + +SYNOPSIS +-------- +[verse] +'git stage' args... + + +DESCRIPTION +----------- + +This is a synonym for linkgit:git-add[1]. Please refer to the +documentation of that command. diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt new file mode 100644 index 0000000000..3f14b727b8 --- /dev/null +++ b/Documentation/git-stash.txt @@ -0,0 +1,260 @@ +git-stash(1) +============ + +NAME +---- +git-stash - Stash the changes in a dirty working directory away + +SYNOPSIS +-------- +[verse] +'git stash' list [<options>] +'git stash' show [<stash>] +'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] [<message>]] +'git stash' clear +'git stash' create + +DESCRIPTION +----------- + +Use 'git stash' when you want to record the current state of the +working directory and the index, but want to go back to a clean +working directory. The command saves your local modifications away +and reverts the working directory to match the `HEAD` commit. + +The modifications stashed away by this command can be listed with +`git stash list`, inspected with `git stash show`, and restored +(potentially on top of a different commit) with `git stash apply`. +Calling `git stash` without any arguments is equivalent to `git stash save`. +A stash is by default listed as "WIP on 'branchname' ...", but +you can give a more descriptive message on the command line when +you create one. + +The latest stash you created is stored in `$GIT_DIR/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}` +is also possible). + +OPTIONS +------- + +save [--patch] [--[no-]keep-index] [-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 + the description along with the stashed state. For quickly making + a snapshot, you can omit _both_ "save" and <message>, but giving + only <message> does not trigger this action to prevent a misspelled + subcommand from making an unwanted stash. ++ +If the `--keep-index` option is used, all changes already added to the +index are left intact. ++ +With `--patch`, you can interactively select hunks from in the diff +between HEAD and the working tree to be stashed. The stash entry is +constructed such that its index state is the same as the index state +of your repository, and its worktree contains only the changes you +selected interactively. The selected changes are then rolled back +from your worktree. ++ +The `--patch` option implies `--keep-index`. You can use +`--no-keep-index` to override this. + +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 + 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. ++ +---------------------------------------------------------------- +stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation +stash@{1}: On master: 9cc0589... Add git-stash +---------------------------------------------------------------- ++ +The command takes options applicable to the 'git-log' +command to control what is shown and how. See linkgit:git-log[1]. + +show [<stash>]:: + + Show the changes recorded in the stash as a diff between the + 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). + +pop [--index] [-q|--quiet] [<stash>]:: + + Remove a single stashed state from the stash list and apply it + on top of the current working tree state, i.e., do the inverse + operation of `git stash save`. The working directory must + match the index. ++ +Applying the state can fail with conflicts; in this case, it is not +removed from the stash list. You need to resolve the conflicts by hand +and call `git stash drop` manually afterwards. ++ +If the `--index` option is used, then tries to reinstate not only the working +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. + +apply [--index] [-q|--quiet] [<stash>]:: + + Like `pop`, but do not remove the state from the stash list. + +branch <branchname> [<stash>]:: + + Creates and checks out a new branch named `<branchname>` starting from + the commit at which the `<stash>` was originally created, applies the + changes recorded in `<stash>` to the new working tree and index, then + drops the `<stash>` if that completes successfully. When no `<stash>` + is given, applies the latest one. ++ +This is useful if the branch on which you ran `git stash save` has +changed enough that `git stash apply` fails due to conflicts. Since +the stash is applied on top of the commit that was HEAD at the time +`git stash` was run, it restores the originally stashed state with +no conflicts. + +clear:: + Remove all the stashed states. Note that those states will then + be subject to pruning, and may be impossible to recover (see + 'Examples' below for a possible strategy). + +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}` + +create:: + + Create a stash (which is a regular commit object) and return its + object name, without storing it anywhere in the ref namespace. + + +DISCUSSION +---------- + +A stash is represented as a commit whose tree records the state of the +working directory, and its first parent is the commit at `HEAD` when +the stash was created. The tree of the second parent records the +state of the index when the stash is made, and it is made a child of +the `HEAD` commit. The ancestry graph looks like this: + + .----W + / / + -----H----I + +where `H` is the `HEAD` commit, `I` is a commit that records the state +of the index, and `W` is a commit that records the state of the working +tree. + + +EXAMPLES +-------- + +Pulling into a dirty tree:: + +When you are in the middle of something, you learn that there are +upstream changes that are possibly relevant to what you are +doing. When your local changes do not conflict with the changes in +the upstream, a simple `git pull` will let you move forward. ++ +However, there are cases in which your local changes do conflict with +the upstream changes, and `git pull` refuses to overwrite your +changes. In such a case, you can stash your changes away, +perform a pull, and then unstash, like this: ++ +---------------------------------------------------------------- +$ git pull + ... +file foobar not up to date, cannot merge. +$ git stash +$ git pull +$ git stash pop +---------------------------------------------------------------- + +Interrupted workflow:: + +When you are in the middle of something, your boss comes in and +demands that you fix something immediately. Traditionally, you would +make a commit to a temporary branch to store your changes away, and +return to your original branch to make the emergency fix, like this: ++ +---------------------------------------------------------------- +# ... hack hack hack ... +$ git checkout -b my_wip +$ git commit -a -m "WIP" +$ git checkout master +$ edit emergency fix +$ git commit -a -m "Fix in a hurry" +$ git checkout my_wip +$ git reset --soft HEAD^ +# ... continue hacking ... +---------------------------------------------------------------- ++ +You can use 'git-stash' to simplify the above, like this: ++ +---------------------------------------------------------------- +# ... hack hack hack ... +$ git stash +$ edit emergency fix +$ git commit -a -m "Fix in a hurry" +$ git stash pop +# ... continue hacking ... +---------------------------------------------------------------- + +Testing partial commits:: + +You can use `git stash save --keep-index` when you want to make two or +more commits out of the changes in the work tree, and you want to test +each change before committing: ++ +---------------------------------------------------------------- +# ... hack hack hack ... +$ git add --patch foo # add just first part to the index +$ git stash save --keep-index # save all other changes to the stash +$ edit/build/test first part +$ git commit -m 'First part' # commit fully tested change +$ git stash pop # prepare to work on all other changes +# ... repeat above five steps until one commit remains ... +$ edit/build/test remaining parts +$ git commit foo -m 'Remaining parts' +---------------------------------------------------------------- + +Recovering stashes that were cleared/dropped erroneously:: + +If you mistakenly drop or clear stashes, they cannot be recovered +through the normal safety mechanisms. However, you can try the +following incantation to get a list of stashes that are still in your +repository, but not reachable any more: ++ +---------------------------------------------------------------- +git fsck --unreachable | +grep commit | cut -d\ -f3 | +xargs git log --merges --no-walk --grep=WIP +---------------------------------------------------------------- + + +SEE ALSO +-------- +linkgit:git-checkout[1], +linkgit:git-commit[1], +linkgit:git-reflog[1], +linkgit:git-reset[1] + +AUTHOR +------ +Written by Nanako Shiraishi <nanako3@bluebottle.com> + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt new file mode 100644 index 0000000000..84f60f3407 --- /dev/null +++ b/Documentation/git-status.txt @@ -0,0 +1,75 @@ +git-status(1) +============= + +NAME +---- +git-status - Show the working tree status + + +SYNOPSIS +-------- +'git status' <options>... + +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 +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`. + +The command takes the same set of options as 'git-commit'; it +shows what would be committed if the same options are given to +'git-commit'. + +If there is no path that is different between the index file and +the current HEAD commit (i.e., there is nothing to commit by running +`git commit`), the command exits with non-zero status. + + +OUTPUT +------ +The output from this command is designed to be used as a commit +template comment, and all the output lines are prefixed with '#'. + +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. + + +CONFIGURATION +------------- + +The command honors `color.status` (or `status.color` -- they +mean the same thing and the latter is kept for backward +compatibility) and `color.status.<slot>` configuration variables +to colorize its output. + +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 +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]). + +SEE ALSO +-------- +linkgit:gitignore[5] + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> and +Junio C Hamano <gitster@pobox.com>. + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-stripspace.txt b/Documentation/git-stripspace.txt new file mode 100644 index 0000000000..7508c0e42d --- /dev/null +++ b/Documentation/git-stripspace.txt @@ -0,0 +1,36 @@ +git-stripspace(1) +================= + +NAME +---- +git-stripspace - Filter out empty lines + + +SYNOPSIS +-------- +'git stripspace' [-s | --strip-comments] < <stream> + +DESCRIPTION +----------- +Remove multiple empty lines, and empty lines at beginning and end. + +OPTIONS +------- +-s:: +--strip-comments:: + In addition to empty lines, also strip lines starting with '#'. + +<stream>:: + Byte stream to act on. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt new file mode 100644 index 0000000000..4ef70c42eb --- /dev/null +++ b/Documentation/git-submodule.txt @@ -0,0 +1,260 @@ +git-submodule(1) +================ + +NAME +---- +git-submodule - Initialize, update or inspect submodules + + +SYNOPSIS +-------- +[verse] +'git submodule' [--quiet] add [-b branch] + [--reference <repository>] [--] <repository> [<path>] +'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...] +'git submodule' [--quiet] init [--] [<path>...] +'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase] + [--reference <repository>] [--merge] [--recursive] [--] [<path>...] +'git submodule' [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...] +'git submodule' [--quiet] foreach [--recursive] <command> +'git submodule' [--quiet] sync [--] [<path>...] + + +DESCRIPTION +----------- +Submodules allow foreign repositories to be embedded within +a dedicated subdirectory of the source tree, always pointed +at a particular commit. + +They are not to be confused with remotes, which are meant mainly +for branches of the same project; submodules are meant for +different projects you would like to make part of your source tree, +while the history of the two projects still stays completely +independent and you cannot modify the contents of the submodule +from within the main project. +If you want to merge the project histories and want to treat the +aggregated whole as a single project from then on, you may want to +add a remote for the other project and use the 'subtree' merge strategy, +instead of treating the other project as a submodule. Directories +that come from both projects can be cloned and checked out as a whole +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. +The logical name can be used for overriding this URL within your +local repository configuration (see 'submodule init'). + +This command will manage the tree entries and contents of the +gitmodules file for you, as well as inspect the status of your +submodules and update them. +When adding a new submodule to the tree, the 'add' subcommand +is to be used. However, when pulling a tree containing submodules, +these will not be checked out by default; +the 'init' and 'update' subcommands will maintain submodules +checked out and at appropriate revision in your working tree. +You can briefly inspect the up-to-date status of your submodules +using the 'status' subcommand and get a detailed overview of the +difference between the index and checkouts using the 'summary' +subcommand. + + +COMMANDS +-------- +add:: + Add the given repository as a submodule at the given path + to the changeset to be committed next to the current + project: the current project is termed the "superproject". ++ +This requires at least one argument: <repository>. The optional +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"). ++ +<repository> is the URL of the new submodule's origin repository. +This may be either an absolute URL, or (if it begins with ./ +or ../), the location relative to the superproject's origin +repository. ++ +<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 +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. ++ +In either case, the given URL is recorded into .gitmodules for +use by subsequent users cloning the superproject. If the URL is +given relative to the superproject's repository, the presumption +is the superproject and submodule repositories will be kept +together in the same relative location, and only the +superproject's URL needs to be provided: git-submodule will correctly +locate the submodule using the relative URL in .gitmodules. + +status:: + Show the status of the submodules. This will print the SHA-1 of the + currently checked out commit for each submodule, along with the + submodule path and the output of 'git-describe' for the + SHA-1. Each SHA-1 will be prefixed with `-` if the submodule is not + initialized and `+` if the currently checked out submodule commit + does not match the SHA-1 found in the index of the containing + repository. 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. + +init:: + Initialize the submodules, i.e. register each submodule name + and url found in .gitmodules into .git/config. + The key used in .git/config is `submodule.$name.url`. + This command does not alter existing information in .git/config. + You can then customize the submodule clone URLs in .git/config + for your local setup and proceed to 'git submodule update'; + you can also just use 'git submodule update --init' without + the explicit 'init' step if you do not intend to customize + any submodule locations. + +update:: + Update the registered submodules, i.e. clone missing submodules and + checkout the commit specified in the index of the containing repository. + This will make the submodules HEAD be detached unless '--rebase' or + '--merge' is specified or the key `submodule.$name.update` is set to + `rebase` or `merge`. ++ +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. + +summary:: + Show commit summary between the given commit (defaults to HEAD) and + working tree/index. For a submodule in question, a series of commits + in the submodule between the given super project commit and the + index or working tree (switched by --cached) are shown. If the option + --files is given, show the series of commits in the submodule between + the index of the super project and the working tree of the submodule + (this option doesn't allow to use the --cached option or to provide an + explicit commit). + +foreach:: + Evaluates an arbitrary shell command in each checked out submodule. + The command has access to the variables $name, $path and $sha1: + $name is the name of the relevant submodule section in .gitmodules, + $path is the name of the submodule directory relative to the + superproject, and $sha1 is the commit as recorded in the superproject. + Any submodules defined in the superproject but not checked out are + ignored by this command. Unless given --quiet, foreach prints the name + of each submodule before evaluating the command. + If --recursive is given, submodules are traversed recursively (i.e. + the given shell command is evaluated in nested submodules as well). + A non-zero return from the command in any submodule causes + the processing to terminate. This can be overridden by adding '|| :' + to the end of the command. ++ +As an example, +git submodule foreach \'echo $path {backtick}git +rev-parse HEAD{backtick}'+ will show the path and currently checked out +commit for each submodule. + +sync:: + Synchronizes submodules' remote URL configuration setting + to the value specified in .gitmodules. This is useful when + submodule URLs change upstream and you need to update your local + repositories accordingly. ++ +"git submodule sync" synchronizes all submodules while +"git submodule sync -- A" synchronizes submodule "A" only. + +OPTIONS +------- +-q:: +--quiet:: + Only print error messages. + +-b:: +--branch:: + Branch of repository to add as submodule. + +--cached:: + This option is only valid for status and summary commands. These + commands typically use the commit found in the submodule HEAD, but + with this option, the commit stored in the index is used instead. + +--files:: + This option is only valid for the summary command. This command + compares the commit in the index with that in the submodule HEAD + when this option is used. + +-n:: +--summary-limit:: + This option is only valid for the summary command. + Limit the summary size (number of commits shown in total). + Giving 0 will disable the summary; a negative number means unlimited + (the default). This limit only applies to modified submodules. The + size is always limited to 1 for added/deleted/typechanged submodules. + +-N:: +--no-fetch:: + This option is only valid for the update command. + Don't fetch new objects from the remote site. + +--merge:: + This option is only valid for the update command. + Merge the commit recorded in the superproject into the current branch + of the submodule. If this option is given, the submodule's HEAD will + not be detached. If a merge failure prevents this process, you will + have to resolve the resulting conflicts within the submodule with the + usual conflict resolution tools. + If the key `submodule.$name.update` is set to `merge`, this option is + implicit. + +--rebase:: + This option is only valid for the update command. + Rebase the current branch onto the commit recorded in the + superproject. If this option is given, the submodule's HEAD will not + be detached. If a a merge failure prevents this process, you will have + to resolve these failures with linkgit:git-rebase[1]. + If the key `submodule.$name.update` is set to `rebase`, this option is + implicit. + +--reference <repository>:: + This option is only valid for add and update commands. These + commands sometimes need to clone a remote repository. In this case, + this option will be passed to the linkgit:git-clone[1] command. ++ +*NOTE*: Do *not* use this option unless you have read the note +for linkgit:git-clone[1]'s --reference and --shared options carefully. + +--recursive:: + This option is only valid for foreach, update and status commands. + Traverse submodules recursively. The operation is performed not + only in the submodules of the current repo, but also + in any nested submodules inside those submodules (and so on). + +<path>...:: + Paths to submodule(s). When specified this will restrict the command + to only operate on the submodules found at the specified paths. + (This argument is required with add). + +FILES +----- +When initializing submodules, a .gitmodules file in the top-level directory +of the containing repository is used to find the url of each submodule. +This file should be formatted in the same way as `$GIT_DIR/config`. The key +to each submodule url is "submodule.$name.url". See linkgit:gitmodules[5] +for details. + + +AUTHOR +------ +Written by Lars Hjemli <hjemli@gmail.com> + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt new file mode 100644 index 0000000000..4cdca0d874 --- /dev/null +++ b/Documentation/git-svn.txt @@ -0,0 +1,829 @@ +git-svn(1) +========== + +NAME +---- +git-svn - Bidirectional operation between a Subversion repository and git + +SYNOPSIS +-------- +'git svn' <command> [options] [arguments] + +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 +repository. + +'git svn' can track a standard Subversion repository, +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 +repository can be updated from Subversion by the 'fetch' command and +Subversion updated from git by the 'dcommit' command. + +COMMANDS +-------- + +'init':: + 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 + directory to operate on can be specified as a second + argument. Normally this command initializes the current + directory. + +-T<trunk_subdir>;; +--trunk=<trunk_subdir>;; +-t<tags_subdir>;; +--tags=<tags_subdir>;; +-b<branches_subdir>;; +--branches=<branches_subdir>;; +-s;; +--stdlayout;; + These are optional command-line options for init. Each of + these flags can point to a relative repository path + (--tags=project/tags) or a full url + (--tags=https://foo.org/project/tags). + You can specify more than one --tags and/or --branches options, in case + your Subversion repository places tags or branches under multiple paths. + The option --stdlayout is + a shorthand way of setting trunk,tags,branches as the relative paths, + which is the Subversion default. If any of the other options are given + as well, they take precedence. +--no-metadata;; + Set the 'noMetadata' option in the [svn-remote] config. +--use-svm-props;; + Set the 'useSvmProps' option in the [svn-remote] config. +--use-svnsync-props;; + Set the 'useSvnsyncProps' option in the [svn-remote] config. +--rewrite-root=<URL>;; + Set the 'rewriteRoot' option in the [svn-remote] config. +--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 +--prefix=<prefix>;; + This allows one to specify a prefix which is prepended + to the names of remotes if trunk/branches/tags are + specified. The prefix does not automatically include a + 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. +--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'. +--no-minimize-url;; + When tracking multiple directories (using --stdlayout, + --branches, or --tags options), git svn will attempt to connect + to the root (or highest allowed level) of the Subversion + repository. This default allows better tracking of history if + entire projects are moved within a repository, but may cause + issues on repositories where read access restrictions are in + place. Passing '--no-minimize-url' will allow git svn to + accept URLs as-is without attempting to connect to a higher + level directory. This option is off by default when only + one URL/branch is tracked (it would do little good). + +'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. + +--localtime;; + Store Git commit times in the local timezone instead of UTC. This + makes 'git log' (even without --date=local) show the same times + that `svn log` would in the local timezone. ++ +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. + +--parent;; + Fetch only from the SVN parent of the current HEAD. + +--ignore-paths=<regex>;; + This allows one to specify a Perl regular expression that will + cause skipping of all matching paths from checkout from SVN. + The '--ignore-paths' option should match for every 'fetch' + (including automatic fetches due to 'clone', 'dcommit', + 'rebase', etc) on a given repository. ++ +[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. ++ +Examples: ++ +-- +Skip "doc*" directory for every fetch;; ++ +------------------------------------------------------------------------ +--ignore-paths="^doc" +------------------------------------------------------------------------ + +Skip "branches" and "tags" of first level directories;; ++ +------------------------------------------------------------------------ +--ignore-paths="^[^/]+/(?:branches|tags)" +------------------------------------------------------------------------ +-- + +--use-log-author;; + 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 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 + will retrieve a valid author string for all commits. + +'clone':: + Runs 'init' and 'fetch'. It will automatically create a + directory based on the basename of the URL passed to it; + or if a second argument is passed; it will create a directory + and work within that. It accepts all arguments that the + 'init' and 'fetch' commands accept; with the exception of + '--fetch-all' and '--parent'. After a repository is cloned, + the 'fetch' command will be able to update revisions without + affecting the working tree; and the 'rebase' command will be + able to update the working tree with the latest changes. + +'rebase':: + This fetches revisions from the SVN parent of the current HEAD + and rebases the current (uncommitted to SVN) work against it. ++ +This works similarly to `svn update` or 'git pull' except that +it preserves linear history with 'git rebase' instead of +'git merge' for ease of dcommitting with 'git svn'. ++ +This accepts all options that 'git svn fetch' and 'git rebase' +accept. However, '--fetch-all' only fetches from the current +[svn-remote], and not all [svn-remote] definitions. ++ +Like 'git rebase'; this requires that the working tree be clean +and have no uncommitted changes. + +-l;; +--local;; + Do not fetch remotely; only run 'git rebase' against the + last fetched commit from the upstream SVN. + +'dcommit':: + Commit each diff from a specified head 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. ++ +--no-rebase;; + After committing, do not rebase or reset. +--commit-url <URL>;; + Commit to this SVN URL (the full path). This is intended to + allow existing 'git svn' repositories created with one transport + method (e.g. `svn://` or `http://` for anonymous read) to be + reused if a user is later given access to an alternate transport + method (e.g. `svn+ssh://` or `https://`) for commit. ++ +[verse] +config key: svn-remote.<name>.commiturl +config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options) ++ +Using this option for any other purpose (don't ask) is very strongly +discouraged. + +'branch':: + Create a branch in the SVN repository. + +-m;; +--message;; + Allows to specify the commit message. + +-t;; +--tag;; + Create a tag by using the tags_subdir instead of the branches_subdir + specified during git svn init. + +-d;; +--destination;; + 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 ++ + git config --get-all svn-remote.<name>.branches + git config --get-all svn-remote.<name>.tags ++ +where <name> is the name of the SVN repository as specified by the -R option to +'init' (or "svn" by default). + +'tag':: + Create a tag in the SVN repository. This is a shorthand for + 'branch -t'. + +'log':: + This should make it easy to look up svn log messages when svn + users refer to -r/--revision numbers. ++ +The following features from `svn log' are supported: ++ +-- +-r <n>[:<n>];; +--revision=<n>[:<n>];; + is supported, non-numeric args are not: + HEAD, NEXT, BASE, PREV, etc ... +-v;; +--verbose;; + it's not completely compatible with the --verbose + output in svn log, but reasonably close. +--limit=<n>;; + is NOT the same as --max-count, doesn't count + merged/excluded commits +--incremental;; + supported +-- ++ +New features: ++ +-- +--show-commit;; + shows the git commit sha1, as well +--oneline;; + our version of --pretty=oneline +-- ++ +NOTE: SVN itself only stores times in UTC and nothing else. The regular svn +client converts the UTC time to the local time (or based on the TZ= +environment). This command has the same behaviour. ++ +Any other arguments are passed directly to 'git log' + +'blame':: + Show what revision and author last modified each line of a file. The + output of this mode is format-compatible with the output of + `svn blame' by default. Like the SVN blame command, + local uncommitted changes in the working copy are ignored; + the version of the file in the HEAD revision is annotated. Unknown + arguments are passed directly to 'git blame'. ++ +--git-format;; + Produce output in the same format as 'git blame', but with + 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 + tree-ish to specify which branch should be searched). When given a + tree-ish, returns the corresponding SVN revision number. + +'set-tree':: + You should consider using 'dcommit' instead of this command. + Commit specified commit or tree objects to SVN. This relies on + your imported fetch data being up-to-date. This makes + absolutely no attempts to do patching when committing to SVN, it + simply overwrites files with those specified in the tree or + commit. All merging is assumed to have taken place + independently of 'git svn' functions. + +'create-ignore':: + Recursively finds the svn:ignore property on directories and + creates matching .gitignore files. The resulting files are staged to + be committed, but are not committed. Use -r/--revision to refer to a + specific revision. + +'show-ignore':: + Recursively finds and lists the svn:ignore property on + directories. The output is suitable for appending to + the $GIT_DIR/info/exclude file. + +'mkdirs':: + 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 + for use after commands like "git checkout" or "git reset". + +'commit-diff':: + Commits the diff of two tree-ish arguments from the + command-line. This command does not rely on being inside an `git svn + init`-ed repository. This command takes three arguments, (a) the + original tree to diff against, (b) the new tree result, (c) the + URL of the target Subversion repository. The final argument + (URL) may be omitted if you are working from a 'git svn'-aware + repository (that has been `init`-ed with 'git svn'). + The -r<revision> option is required for this. + +'info':: + Shows information about a file or directory similar to what + `svn info' provides. Does not currently support a -r/--revision + argument. Use the --url option to output only the value of the + 'URL:' field. + +'proplist':: + Lists the properties stored in the Subversion repository about a + given file or directory. Use -r/--revision to refer to a specific + Subversion revision. + +'propget':: + Gets the Subversion property given as the first argument, for a + file. A specific revision can be specified with -r/--revision. + +'show-externals':: + Shows the Subversion externals. Use -r/--revision to specify a + 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. + +'reset':: + Undoes the effects of 'fetch' back to the specified revision. + This allows you to re-'fetch' an SVN revision. Normally the + contents of an SVN revision should never change and 'reset' + should not be necessary. However, if SVN permissions change, + or if you alter your --ignore-paths option, a 'fetch' may fail + with "not found in commit" (file not previously visible) or + "checksum mismatch" (missed a modification). If the problem + 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. + +-r <n>;; +--revision=<n>;; + Specify the most recent revision to keep. All later revisions + are discarded. +-p;; +--parent;; + Discard the specified revision as well, keeping the nearest + parent instead. +Example:;; +Assume you have local changes in "master", but you need to refetch "r2". ++ +------------ + r1---r2---r3 remotes/git-svn + \ + A---B master +------------ ++ +Fix the ignore-paths or SVN permissions problem that caused "r2" to +be incomplete in the first place. Then: ++ +[verse] +git svn reset -r2 -p +git svn fetch ++ +------------ + r1---r2'--r3' remotes/git-svn + \ + r2---r3---A---B master +------------ ++ +Then fixup "master" with 'git rebase'. +Do NOT use 'git merge' or your history will not be compatible with a +future 'dcommit'! ++ +[verse] +git rebase --onto remotes/git-svn A^ master ++ +------------ + r1---r2'--r3' remotes/git-svn + \ + A'--B' master +------------ + +OPTIONS +------- + +--shared[={false|true|umask|group|all|world|everybody}]:: +--template=<template_directory>:: + Only used with the 'init' command. + These are passed directly to 'git init'. + +-r <ARG>:: +--revision <ARG>:: + Used with the 'fetch' command. ++ +This allows revision ranges for partial/cauterized history +to be supported. $NUMBER, $NUMBER1:$NUMBER2 (numeric ranges), +$NUMBER:HEAD, and BASE:$NUMBER are all supported. ++ +This can allow you to make partial mirrors when running fetch; +but is generally not recommended because history will be skipped +and lost. + +-:: +--stdin:: + Only used with the 'set-tree' command. ++ +Read a list of commits from stdin and commit them in reverse +order. Only the leading sha1 is read from each line, so +'git rev-list --pretty=oneline' output can be used. + +--rmdir:: + Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands. ++ +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 +cannot version empty directories. Enabling this flag will make +the commit to SVN act like git. ++ +[verse] +config key: svn.rmdir + +-e:: +--edit:: + Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands. ++ +Edit the commit message before committing to SVN. This is off by +default for objects that are commits, and forced on when committing +tree objects. ++ +[verse] +config key: svn.edit + +-l<num>:: +--find-copies-harder:: + Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands. ++ +They are both passed directly to 'git diff-tree'; see +linkgit:git-diff-tree[1] for more information. ++ +[verse] +config key: svn.l +config key: svn.findcopiesharder + +-A<filename>:: +--authors-file=<filename>:: + Syntax is compatible with the file used by 'git cvsimport': ++ +------------------------------------------------------------------------ + loginname = Joe User <user@example.com> +------------------------------------------------------------------------ ++ +If this option is specified and 'git svn' encounters an SVN +committer name that does not exist in the authors-file, 'git svn' +will abort operation. The user will then have to add the +appropriate entry. Re-running the previous 'git svn' command +after the authors-file is modified should continue operation. ++ +[verse] +config key: svn.authorsfile + +--authors-prog=<filename>:: + If this option is specified, for each SVN committer name that + does not exist in the authors file, the given file is executed + with the committer name as the first argument. The program is + expected to return a single line of the form "Name <email>", + which will be treated as if included in the authors file. + +-q:: +--quiet:: + 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>:: + These are only used with the 'dcommit' and 'rebase' commands. ++ +Passed directly to 'git rebase' when using 'dcommit' if a +'git reset' cannot be used (see 'dcommit'). + +-n:: +--dry-run:: + This can be used with the 'dcommit', 'rebase', 'branch' and + 'tag' commands. ++ +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 +repository associated with the current branch and the URL of svn +repository that will be fetched from. ++ +For 'branch' and 'tag', display the urls that will be used for copying when +creating the branch or tag. + + +ADVANCED OPTIONS +---------------- + +-i<GIT_SVN_ID>:: +--id <GIT_SVN_ID>:: + This sets GIT_SVN_ID (instead of using the environment). This + allows the user to override the default refname to fetch from + when tracking a single URL. The 'log' and 'dcommit' commands + no longer require this switch as an argument. + +-R<remote name>:: +--svn-remote <remote name>:: + Specify the [svn-remote "<remote name>"] section to use, + this allows SVN multiple repositories to be tracked. + Default: "svn" + +--follow-parent:: + 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 + --no-follow-parent to disable it. ++ +[verse] +config key: svn.followparent + +CONFIG FILE-ONLY OPTIONS +------------------------ + +svn.noMetadata:: +svn-remote.<name>.noMetadata:: + This gets rid of the 'git-svn-id:' lines at the end of every commit. ++ +If you lose your .git/svn/git-svn/.rev_db file, 'git svn' will not +be able to rebuild it and you won't be able to fetch again, +either. This is fine for one-shot imports. ++ +The 'git svn log' command will not work on repositories using +this, either. Using this conflicts with the 'useSvmProps' +option for (hopefully) obvious reasons. + +svn.useSvmProps:: +svn-remote.<name>.useSvmProps:: + This allows 'git svn' to re-map repository URLs and UUIDs from + mirrors created using SVN::Mirror (or svk) for metadata. ++ +If an SVN revision has a property, "svm:headrev", it is likely +that the revision was created by SVN::Mirror (also used by SVK). +The property contains a repository UUID and a revision. We want +to make it look like we are mirroring the original URL, so +introduce a helper function that returns the original identity +URL and UUID, and use it when generating metadata in commit +messages. + +svn.useSvnsyncProps:: +svn-remote.<name>.useSvnsyncprops:: + Similar to the useSvmProps option; this is for users + of the svnsync(1) command distributed with SVN 1.4.x and + later. + +svn-remote.<name>.rewriteRoot:: + This allows users to create repositories from alternate + URLs. For example, an administrator could run 'git svn' on the + server locally (accessing via file://) but wish to distribute + the repository with a public http:// or svn:// URL in the + metadata so users of it will see the public URL. + +svn.brokenSymlinkWorkaround:: + This disables potentially expensive checks to workaround + broken symlinks checked into SVN by broken clients. Set this + option to "false" if you track a SVN repository with many + empty blobs that are not symlinks. This option may be changed + while 'git svn' is running and take effect on the next + revision fetched. If unset, 'git svn' assumes this option to + be "true". + +Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps +options all affect the metadata generated and used by 'git svn'; they +*must* be set in the configuration file before any history is imported +and these settings should never be changed once they are set. + +Additionally, only one of these four options can be used per-svn-remote +section because they affect the 'git-svn-id:' metadata line. + + +BASIC EXAMPLES +-------------- + +Tracking and contributing to the trunk of a Subversion-managed project: + +------------------------------------------------------------------------ +# Clone a repo (like git clone): + git svn clone http://svn.example.com/project/trunk +# Enter the newly cloned directory: + cd trunk +# You should be on master branch, double-check with 'git branch' + git branch +# 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, +# as well as automatically updating your working HEAD: + git svn dcommit +# Append svn:ignore settings to the default git exclude file: + git svn show-ignore >> .git/info/exclude +------------------------------------------------------------------------ + +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 +# View all branches and tags you have cloned: + git branch -r +# Create a new branch in SVN + git svn branch waldo +# Reset your master to trunk (or any other branch, replacing 'trunk' +# with the appropriate name): + git reset --hard remotes/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. +------------------------------------------------------------------------ + +The initial 'git svn clone' can be quite time-consuming +(especially for large Subversion repositories). If multiple +people (or one person with multiple machines) want to use +'git svn' to interact with the same Subversion repository, you can +do the initial 'git svn clone' to a repository on a server and +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 +# Clone locally - make sure the refs/remotes/ space matches the server + mkdir project + cd project + git init + git remote add origin server:/pub/project + git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' + git fetch +# 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 +# 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 +`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. + +DESIGN PHILOSOPHY +----------------- +Merge tracking in Subversion is lacking and doing branched development +with Subversion can be cumbersome as a result. 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 +compatibility with SVN (see the CAVEATS section below). + +CAVEATS +------- + +For the sake of simplicity and interoperating with a less-capable system +(SVN), 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 +'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. Subversion does not represent merges in any +reasonable or useful fashion; so users using Subversion cannot see any +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. + +If you do merge, note the following rule: 'git svn dcommit' will +attempt to commit on top of the SVN commit named in +------------------------------------------------------------------------ +git log --grep=^git-svn-id: --first-parent -1 +------------------------------------------------------------------------ +You 'must' therefore ensure that the most recent commit of the branch +you want to dcommit to is the 'first' parent of the merge. Chaos will +ensue otherwise, especially if the first parent is an older commit on +the same SVN branch. + +'git clone' does not clone branches under the refs/remotes/ hierarchy or +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 +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. + +Do not use the --amend option of linkgit:git-commit[1] on a change you've +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 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: + + branches = stable/*:refs/remotes/svn/stable/* + branches = debug/*:refs/remotes/svn/debug/* + +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 +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 +renamed and copied files are fully supported if they're similar enough +for git to detect them. + +CONFIGURATION +------------- + +'git svn' stores [svn-remote] configuration information in the +repository .git/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 +configured with multiple projects glob expansions such those +listed below are allowed: + +------------------------------------------------------------------------ +[svn-remote "project-a"] + url = http://server.org/svn + fetch = trunk/project-a:refs/remotes/project-a/trunk + branches = branches/*/project-a:refs/remotes/project-a/branches/* + tags = tags/*/project-a:refs/remotes/project-a/tags/* +------------------------------------------------------------------------ + +Keep in mind that the '\*' (asterisk) wildcard of the local ref +(right of the ':') *must* be the farthest right path component; +however the remote wildcard may be anywhere as long as it's an +independent path component (surrounded by '/' or EOL). This +type of configuration is not automatically created by 'init' and +should be manually entered with a text-editor or using 'git config'. + +SEE ALSO +-------- +linkgit:git-rebase[1] + +Author +------ +Written by Eric Wong <normalperson@yhbt.net>. + +Documentation +------------- +Written by Eric Wong <normalperson@yhbt.net>. diff --git a/Documentation/git-symbolic-ref.txt b/Documentation/git-symbolic-ref.txt new file mode 100644 index 0000000000..6392538807 --- /dev/null +++ b/Documentation/git-symbolic-ref.txt @@ -0,0 +1,62 @@ +git-symbolic-ref(1) +=================== + +NAME +---- +git-symbolic-ref - Read and modify symbolic refs + +SYNOPSIS +-------- +'git symbolic-ref' [-q] [-m <reason>] <name> [<ref>] + +DESCRIPTION +----------- +Given one argument, reads which branch head the given symbolic +ref refers to and outputs its path, relative to the `.git/` +directory. Typically you would give `HEAD` as the <name> +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>. + +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`. + +OPTIONS +------- + +-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. + +-m:: + Update the reflog for <name> with <reason>. This is valid only + when creating or updating a symbolic ref. + +NOTES +----- +In the past, `.git/HEAD` was a symbolic link pointing at +`refs/heads/master`. When we wanted to switch to another branch, +we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we wanted +to find out which branch we are on, we did `readlink .git/HEAD`. +This was fine, and internally that is what still happens by +default, but on platforms that do not have working symlinks, +or that do not have the `readlink(1)` command, this was a bit +cumbersome. On some platforms, `ln -sf` does not even work as +advertised (horrors). Therefore symbolic links are now deprecated +and symbolic refs are used by default. + +'git-symbolic-ref' will exit with status 0 if the contents of the +symbolic ref were printed correctly, with status 1 if the requested +name is not a symbolic ref, or 128 if another error occurs. + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt new file mode 100644 index 0000000000..299b04f726 --- /dev/null +++ b/Documentation/git-tag.txt @@ -0,0 +1,275 @@ +git-tag(1) +========== + +NAME +---- +git-tag - Create, list, delete or verify a tag object signed with GPG + + +SYNOPSIS +-------- +[verse] +'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' -v <tagname>... + +DESCRIPTION +----------- + +Adds a tag reference in `.git/refs/tags/`. + +Unless `-f` is given, the tag must not yet exist in +`.git/refs/tags/` directory. + +If one of `-a`, `-s`, or `-u <key-id>` is passed, the command +creates a 'tag' object, and requires the tag message. Unless +`-m <msg>` or `-F <file>` is given, an editor is started for the user to type +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 the SHA1 object name of the commit object is +written (i.e. a lightweight tag). + +A GnuPG signed tag object will be created when `-s` or `-u +<key-id>` is used. When `-u <key-id>` is not used, the +committer identity for the current user is used to find the +GnuPG key for signing. + +OPTIONS +------- +-a:: + Make an unsigned, annotated tag object + +-s:: + Make a GPG-signed tag, using the default e-mail address's key + +-u <key-id>:: + Make a GPG-signed tag, using the given key + +-f:: +--force:: + Replace an existing tag with the given name (instead of failing) + +-d:: + Delete existing tags with the given names. + +-v:: + Verify the gpg signature of the given tag names. + +-n<num>:: + <num> specifies how many lines from the annotation, if any, + are printed when using -l. + The default is not to print any annotation lines. + If no number is given to `-n`, only the first line is printed. + If the tag is not annotated, the commit message is displayed instead. + +-l <pattern>:: + List tags with names that match the given pattern (or all if no pattern is given). + Typing "git tag" without arguments, also lists all tags. + +--contains <commit>:: + Only list tags which contain the specified commit. + +-m <msg>:: + Use the given tag message (instead of prompting). + If multiple `-m` options are given, their values are + concatenated as separate paragraphs. + Implies `-a` if none of `-a`, `-s`, or `-u <key-id>` + is given. + +-F <file>:: + Take the tag message from the given file. Use '-' to + read the message from the standard input. + Implies `-a` if none of `-a`, `-s`, or `-u <key-id>` + is given. + +<tagname>:: + The name of the tag to create, delete, or describe. + The new tag name must pass all checks defined by + linkgit:git-check-ref-format[1]. Some of these checks + may restrict the characters allowed in a tag name. + +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 +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> +------------------------------------- + + +DISCUSSION +---------- + +On Re-tagging +~~~~~~~~~~~~~ + +What should you do when you tag a wrong commit and you would +want to re-tag? + +If you never pushed anything out, just re-tag it. Use "-f" to +replace the old one. And you're done. + +But if you have pushed things out (or others could just read +your repository directly), then others will have already seen +the old tag. In that case you can do one of two things: + +. The sane thing. +Just admit you screwed up, and use a different name. Others have +already seen one tag-name, and if you keep the same name, you +may be in the situation that two people both have "version X", +but they actually have 'different' "X"'s. So just call it "X.1" +and be done with it. + +. The insane thing. +You really want to call the new version "X" too, 'even though' +others have already seen the old one. So just use 'git-tag -f' +again, as if you hadn't already published the old one. + +However, Git does *not* (and it should not) change tags behind +users back. So if somebody already got the old tag, doing a +'git-pull' on your tree shouldn't just make them overwrite the old +one. + +If somebody got a release tag from you, you cannot just change +the tag for them by updating your own one. This is a big +security issue, in that people MUST be able to trust their +tag-names. If you really want to do the insane thing, you need +to just fess up to it, and tell people that you messed up. You +can do that by making a very public announcement saying: + +------------ +Ok, I messed up, and I pushed out an earlier version tagged as X. I +then fixed something, and retagged the *fixed* tree as X again. + +If you got the wrong tag, and want the new one, please delete +the old one and fetch the new one by doing: + + git tag -d X + git fetch origin tag X + +to get my updated tag. + +You can test which tag you have by doing + + git rev-parse X + +which should return 0123456789abcdef.. if you have the new version. + +Sorry for inconvenience. +------------ + +Does this seem a bit complicated? It *should* be. There is no +way that it would be correct to just "fix" it behind peoples +backs. People need to know that their tags might have been +changed. + + +On Automatic following +~~~~~~~~~~~~~~~~~~~~~~ + +If you are following somebody else's tree, you are most likely +using tracking branches (`refs/heads/origin` in traditional +layout, or `refs/remotes/origin/master` in the separate-remote +layout). You usually want the tags from the other end. + +On the other hand, if you are fetching because you would want a +one-shot merge from somebody else, you typically do not want to +get tags from there. This happens more often for people near +the toplevel but not limited to them. Mere mortals when pulling +from each other do not necessarily want to automatically get +private anchor point tags from the other person. + +You would notice "please pull" messages on the mailing list says +repo URL and branch name alone. This is designed to be easily +cut&pasted to a 'git-fetch' command line: + +------------ +Linus, please pull from + + git://git..../proj.git master + +to get the following updates... +------------ + +becomes: + +------------ +$ git pull git://git..../proj.git master +------------ + +In such a case, you do not want to automatically follow other's +tags. + +One important aspect of git is it is distributed, and being +distributed 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 +by upper echelon of people and tags only flow downwards, but +that is not the case. It only shows that the usage pattern +determines who are interested in whose tags. + +A one-shot pull is a sign that a commit history is now crossing +the boundary between one circle of people (e.g. "people who are +primarily interested in the networking part of the kernel") who may +have their own set of tags (e.g. "this is the third release +candidate from the networking group to be proposed for general +consumption with 2.6.21 release") to another circle of people +(e.g. "people who integrate various subsystem improvements"). +The latter are usually not interested in the detailed tags used +internally in the former group (that is what "internal" means). +That is why it is desirable not to follow tags automatically in +this case. + +It may well be that among networking people, they may want to +exchange the tags internal to their group, but in that workflow +they are most likely tracking with each other's progress by +having tracking branches. Again, the heuristic to automatically +follow such tags is a good thing. + + +On Backdating Tags +~~~~~~~~~~~~~~~~~~ + +If you have imported some changes from another VCS and would like +to add tags for major releases of your work, it is useful to be able +to specify the date to embed inside of the tag object. The data in +the tag object affects, for example, the ordering of tags in the +gitweb interface. + +To set the date used in future tag objects, set the environment +variable GIT_COMMITTER_DATE to one or more of the date and time. The +date and time can be specified in a number of ways; the most common +is "YYYY-MM-DD HH:MM". + +An example follows. + +------------ +$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1 +------------ + + +SEE ALSO +-------- +linkgit:git-check-ref-format[1]. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org>, +Junio C Hamano <gitster@pobox.com> and Chris Wright <chrisw@osdl.org>. + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt new file mode 100644 index 0000000000..a5d9558dd1 --- /dev/null +++ b/Documentation/git-tar-tree.txt @@ -0,0 +1,89 @@ +git-tar-tree(1) +=============== + +NAME +---- +git-tar-tree - Create a tar archive of the files in the named tree object + + +SYNOPSIS +-------- +'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/'. + +Author +------ +Written by Rene Scharfe. + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt new file mode 100644 index 0000000000..a96403cb8c --- /dev/null +++ b/Documentation/git-tools.txt @@ -0,0 +1,118 @@ +A short git tools survey +======================== + + +Introduction +------------ + +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 +link. + + +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 + storage system. It aims at seamless user interface and ease of use, + 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. + + + - *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 + 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 + until they get merged upstream. + + +History Viewers +--------------- + + - *gitk* (shipped with git-core) + + gitk is a simple Tk GUI for browsing history of GIT repositories easily. + + + - *gitview* (contrib/) + + gitview is a GTK based repository browser for git + + + - *gitweb* (shipped with git-core) + + 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 + 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 + viewers and commit tools. + + - *tig* (http://jonas.nitro.dk/tig/) + + 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. + + +Foreign SCM interface +--------------------- + + - *git-svn* (shipped with git-core) + + git-svn is a simple conduit for changesets between a single Subversion + 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. + + + - *hg-to-git* (contrib/) + + 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 + in sync with the master Mercurial repository. + + +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 + 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 + pcl-cvs. It has been developed on Emacs 21 and will probably need some + tweaking to work on XEmacs. + + +http://git.or.cz/gitwiki/InterfacesFrontendsAndTools has more +comprehensive list. diff --git a/Documentation/git-unpack-file.txt b/Documentation/git-unpack-file.txt new file mode 100644 index 0000000000..995db9fead --- /dev/null +++ b/Documentation/git-unpack-file.txt @@ -0,0 +1,35 @@ +git-unpack-file(1) +================== + +NAME +---- +git-unpack-file - Creates a temporary file with a blob's contents + + + +SYNOPSIS +-------- +'git unpack-file' <blob> + +DESCRIPTION +----------- +Creates a file holding the contents of the blob specified by sha1. It +returns the name of the temporary file in the following format: + .merge_file_XXXXX + +OPTIONS +------- +<blob>:: + Must be a blob id + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt new file mode 100644 index 0000000000..36d1038056 --- /dev/null +++ b/Documentation/git-unpack-objects.txt @@ -0,0 +1,57 @@ +git-unpack-objects(1) +===================== + +NAME +---- +git-unpack-objects - Unpack objects from a packed archive + + +SYNOPSIS +-------- +'git unpack-objects' [-n] [-q] [-r] [--strict] <pack-file + + +DESCRIPTION +----------- +Read a packed archive (.pack) from the standard input, expanding +the objects contained within and writing them into the repository in +"loose" (one object per file) format. + +Objects that already exist in the repository will *not* be unpacked +from the pack-file. Therefore, nothing will be unpacked if you use +this command on a pack-file that exists within the target repository. + +See linkgit:git-repack[1] for options to generate +new packs and replace existing ones. + +OPTIONS +------- +-n:: + Dry run. Check the pack file without actually unpacking + the objects. + +-q:: + The command usually shows percentage progress. This + flag suppresses it. + +-r:: + When unpacking a corrupt packfile, the command dies at + the first corruption. This flag tells it to keep going + and make the best effort to recover as many objects as + possible. + +--strict:: + Don't write objects with broken content or links. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +------------- +Documentation by Junio C Hamano + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt new file mode 100644 index 0000000000..6052484ab9 --- /dev/null +++ b/Documentation/git-update-index.txt @@ -0,0 +1,352 @@ +git-update-index(1) +=================== + +NAME +---- +git-update-index - Register file contents in the working tree to the index + + +SYNOPSIS +-------- +[verse] +'git update-index' + [--add] [--remove | --force-remove] [--replace] + [--refresh] [-q] [--unmerged] [--ignore-missing] + [--cacheinfo <mode> <object> <file>]\* + [--chmod=(+|-)x] + [--assume-unchanged | --no-assume-unchanged] + [--ignore-submodules] + [--really-refresh] [--unresolve] [--again | -g] + [--info-only] [--index-info] + [-z] [--stdin] + [--verbose] + [--] [<file>]\* + +DESCRIPTION +----------- +Modifies the index or directory cache. Each file mentioned is updated +into the index and any 'unmerged' or 'needs updating' state is +cleared. + +See also linkgit:git-add[1] for a more user-friendly way to do some of +the most common operations on the index. + +The way 'git-update-index' handles files it is told about can be modified +using the various options: + +OPTIONS +------- +--add:: + If a specified file isn't in the index already then it's + added. + Default behaviour is to ignore new files. + +--remove:: + If a specified file is in the index but is missing then it's + removed. + Default behavior is to ignore removed file. + +--refresh:: + Looks at the current index and checks to see if merges or + updates are needed by checking stat() information. + +-q:: + Quiet. If --refresh finds that the index needs an update, the + default behavior is to error out. This option makes + 'git-update-index' continue anyway. + +--ignore-submodules:: + Do not try to update submodules. This option is only respected + when passed before --refresh. + +--unmerged:: + If --refresh finds unmerged changes in the index, the default + behavior is to error out. This option makes 'git-update-index' + continue anyway. + +--ignore-missing:: + Ignores missing files during a --refresh + +--cacheinfo <mode> <object> <path>:: + Directly insert the specified info into the index. + +--index-info:: + Read index information from stdin. + +--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 + 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). +You should remember that an explicit 'git add' operation will +still cause the file to be refreshed from the working tree. +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, +you will need to handle the situation manually. + +--really-refresh:: + Like '--refresh', but checks stat information unconditionally, + without regard to the "assume unchanged" setting. + +-g:: +--again:: + Runs 'git-update-index' itself on the paths whose index + entries are different from those from the `HEAD` commit. + +--unresolve:: + Restores the 'unmerged' or 'needs updating' state of a + file during a merge if it was cleared by accident. + +--info-only:: + Do not create objects in the object database for all + <file> arguments that follow this flag; just insert + their object IDs into the index. + +--force-remove:: + Remove the file from the index even when the working directory + still has such a file. (Implies --remove.) + +--replace:: + By default, when a file `path` exists in the index, + 'git-update-index' refuses an attempt to add `path/file`. + Similarly if a file `path/file` exists, a file `path` + cannot be added. With --replace flag, existing entries + that conflict with the entry being added are + automatically removed with warning messages. + +--stdin:: + Instead of taking list of paths from the command line, + read list of paths from the standard input. Paths are + separated by LF (i.e. one path per line) by default. + +--verbose:: + Report what is being added and removed from index. + +-z:: + Only meaningful with `--stdin`; paths are separated with + NUL character instead of LF. + +\--:: + Do not interpret any more arguments as options. + +<file>:: + Files to act on. + Note that files beginning with '.' are discarded. This includes + `./file` and `dir/./file`. If you don't want this, then use + cleaner names. + The same applies to directories ending '/' and paths with '//' + +Using --refresh +--------------- +'--refresh' does not calculate a new sha1 file or bring the index +up-to-date for mode/content changes. But what it *does* do is to +"re-match" the stat information of a file with the index, so that you +can refresh the index for a file that hasn't been changed but where +the stat entry is out of date. + +For example, you'd want to do this after doing a 'git-read-tree', to link +up the stat index details with the proper files. + +Using --cacheinfo or --info-only +-------------------------------- +'--cacheinfo' is used to register a file that is not in the +current working directory. This is useful for minimum-checkout +merging. + +To pretend you have a file with mode and sha1 at path, say: + +---------------- +$ git update-index --cacheinfo mode sha1 path +---------------- + +'--info-only' is used to register files without placing them in the object +database. This is useful for status-only repositories. + +Both '--cacheinfo' and '--info-only' behave similarly: the index is updated +but the object database isn't. '--cacheinfo' is useful when the object is +in the database but the file isn't available locally. '--info-only' is +useful when the file is available, but you do not wish to update the +object database. + + +Using --index-info +------------------ + +`--index-info` is a more powerful mechanism that lets you feed +multiple entry definitions from the standard input, and designed +specifically for scripts. It can take inputs of three formats: + + . mode SP sha1 TAB path ++ +The first format is what "git-apply --index-info" +reports, and used to reconstruct a partial tree +that is used for phony merge base tree when falling +back on 3-way merge. + + . mode SP type SP sha1 TAB path ++ +The second format is to stuff 'git-ls-tree' output +into the index file. + + . mode SP sha1 SP stage TAB path ++ +This format is to put higher order stages into the +index file and matches 'git-ls-files --stage' output. + +To place a higher stage entry to the index, the path should +first be removed by feeding a mode=0 entry for the path, and +then feeding necessary input lines in the third format. + +For example, starting with this index: + +------------ +$ git ls-files -s +100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0 frotz +------------ + +you can feed the following input to `--index-info`: + +------------ +$ git update-index --index-info +0 0000000000000000000000000000000000000000 frotz +100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz +100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz +------------ + +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. +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: + +------------ +$ git ls-files -s +100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz +100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz +------------ + + +Using ``assume unchanged'' bit +------------------------------ + +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 +assume it has *not* changed. When you make changes to working +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` +option. To unset, use `--no-assume-unchanged`. + +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 +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 +`git update-index --refresh` finds the working tree file matches +the index (use `git update-index --really-refresh` if you want +to mark them as "assume unchanged"). + + +Examples +-------- +To update and refresh only the files already checked out: + +---------------- +$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh +---------------- + +On an inefficient filesystem with `core.ignorestat` set:: ++ +------------ +$ git update-index --really-refresh <1> +$ git update-index --no-assume-unchanged foo.c <2> +$ git diff --name-only <3> +$ edit foo.c +$ git diff --name-only <4> +M foo.c +$ git update-index foo.c <5> +$ git diff --name-only <6> +$ edit foo.c +$ git diff --name-only <7> +$ git update-index --no-assume-unchanged foo.c <8> +$ git diff --name-only <9> +M foo.c +------------ ++ +<1> forces lstat(2) to set "assume unchanged" bits for paths that match index. +<2> mark the path to be edited. +<3> this does lstat(2) and finds index matches the path. +<4> this does lstat(2) and finds index does *not* match the path. +<5> registering the new version to index sets "assume unchanged" bit. +<6> and it is assumed unchanged. +<7> even after you edit it. +<8> you can tell about the change after the fact. +<9> now it checks with lstat(2) and finds it has been changed. + + +Configuration +------------- + +The command honors `core.filemode` configuration variable. If +your repository is on a filesystem whose executable bits are +unreliable, this should be set to 'false' (see linkgit:git-config[1]). +This causes the command to ignore differences in file modes recorded +in the index and the file mode on the filesystem if they differ only on +executable bit. On such an unfortunate filesystem, you may +need to use 'git-update-index --chmod='. + +Quite similarly, if `core.symlinks` configuration variable is set +to 'false' (see linkgit:git-config[1]), symbolic links are checked out +as plain files, and this command does not modify a recorded file mode +from symbolic link to regular file. + +The command looks at `core.ignorestat` configuration variable. See +'Using "assume unchanged" bit' section above. + +The command also looks at `core.trustctime` configuration variable. +It can be useful when the inode change time is regularly modified by +something outside Git (file system crawlers and backup systems use +ctime for marking files processed) (see linkgit:git-config[1]). + + +SEE ALSO +-------- +linkgit:git-config[1], +linkgit:git-add[1] + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt new file mode 100644 index 0000000000..9639f705af --- /dev/null +++ b/Documentation/git-update-ref.txt @@ -0,0 +1,93 @@ +git-update-ref(1) +================= + +NAME +---- +git-update-ref - Update the object name stored in a ref safely + +SYNOPSIS +-------- +'git update-ref' [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>]) + +DESCRIPTION +----------- +Given two arguments, stores the <newvalue> in the <ref>, possibly +dereferencing the symbolic refs. E.g. `git update-ref HEAD +<newvalue>` updates the current branch head to the new object. + +Given three arguments, stores the <newvalue> in the <ref>, +possibly dereferencing the symbolic refs, after verifying that +the current value of the <ref> matches <oldvalue>. +E.g. `git update-ref refs/heads/master <newvalue> <oldvalue>` +updates the master branch head to <newvalue> only if its current +value is <oldvalue>. You can specify 40 "0" or an empty string +as <oldvalue> to make sure that the ref you are creating does +not exist. + +It also allows a "ref" file to be a symbolic pointer to another +ref file by starting with the four-byte header sequence of +"ref:". + +More importantly, it allows the update of a ref file to follow +these symbolic pointers, whether they are symlinks or these +"regular file symbolic refs". It follows *real* symlinks only +if they start with "refs/": otherwise it will just try to read +them and update them as a regular file (i.e. it will allow the +filesystem to follow them, but will overwrite such a symlink to +somewhere else with a regular filename). + +If --no-deref is given, <ref> itself is overwritten, rather than +the result of following the symbolic pointers. + +In general, using + + git update-ref HEAD "$head" + +should be a _lot_ safer than doing + + echo "$head" > "$GIT_DIR/HEAD" + +both from a symlink following standpoint *and* an error checking +standpoint. The "refs/" rule for symlinks means that symlinks +that point to "outside" the tree are safe: they'll be followed +for reading but not for writing (so we'll never write through a +ref symlink to some other tree, if you have copied a whole +archive by creating a symlink tree). + +With `-d` flag, it deletes the named <ref> after verifying it +still contains <oldvalue>. + + +Logging Updates +--------------- +If config parameter "core.logAllRefUpdates" is true or the file +"$GIT_DIR/logs/<ref>" exists then `git update-ref` will append +a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all +symbolic refs before creating the log name) describing the change +in ref value. Log lines are formatted as: + + . oldsha1 SP newsha1 SP committer LF ++ +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. + +Optionally with -m: + + . oldsha1 SP newsha1 SP committer TAB message LF ++ +Where all fields are as described above and "message" is the +value supplied to the -m option. + +An update will fail (without changing <ref>) if the current user is +unable to create a new log file, append to the existing log file +or does not have committer information available. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-update-server-info.txt b/Documentation/git-update-server-info.txt new file mode 100644 index 0000000000..035cc3018f --- /dev/null +++ b/Documentation/git-update-server-info.txt @@ -0,0 +1,52 @@ +git-update-server-info(1) +========================= + +NAME +---- +git-update-server-info - Update auxiliary info file to help dumb servers + + +SYNOPSIS +-------- +'git update-server-info' [--force] + +DESCRIPTION +----------- +A dumb server that does not do on-the-fly pack generations must +have some auxiliary information files in $GIT_DIR/info and +$GIT_OBJECT_DIRECTORY/info directories to help clients discover +what references and packs the server has. This command +generates such auxiliary files. + + +OPTIONS +------- + +-f:: +--force:: + Update the info files from scratch. + + +OUTPUT +------ + +Currently the command updates the following files. Please see +linkgit:gitrepository-layout[5] for description of +what they are for: + +* objects/info/packs + +* info/refs + + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-upload-archive.txt b/Documentation/git-upload-archive.txt new file mode 100644 index 0000000000..bbd7617587 --- /dev/null +++ b/Documentation/git-upload-archive.txt @@ -0,0 +1,37 @@ +git-upload-archive(1) +==================== + +NAME +---- +git-upload-archive - Send archive back to git-archive + + +SYNOPSIS +-------- +'git upload-archive' <directory> + +DESCRIPTION +----------- +Invoked by 'git-archive --remote' and sends a generated archive to the +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. + +OPTIONS +------- +<directory>:: + The repository to get a tar archive from. + +Author +------ +Written by Franck Bui-Huu. + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt new file mode 100644 index 0000000000..63f3b5c742 --- /dev/null +++ b/Documentation/git-upload-pack.txt @@ -0,0 +1,48 @@ +git-upload-pack(1) +================== + +NAME +---- +git-upload-pack - Send objects packed back to git-fetch-pack + + +SYNOPSIS +-------- +'git upload-pack' [--strict] [--timeout=<n>] <directory> + +DESCRIPTION +----------- +Invoked by 'git-fetch-pack', learns what +objects the other side is missing, and sends them after packing. + +This command is usually not invoked directly by the end user. +The UI for the protocol is on the 'git-fetch-pack' side, and the +program pair is meant to be used to pull updates from a remote +repository. For push operations, see 'git-send-pack'. + +After finishing the operation successfully, `post-upload-pack` +hook is called (see linkgit:githooks[5]). + +OPTIONS +------- + +--strict:: + Do not try <directory>/.git/ if <directory> is no git directory. + +--timeout=<n>:: + Interrupt transfer after <n> seconds of inactivity. + +<directory>:: + The repository to sync from. + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt new file mode 100644 index 0000000000..ef6aa81872 --- /dev/null +++ b/Documentation/git-var.txt @@ -0,0 +1,78 @@ +git-var(1) +========== + +NAME +---- +git-var - Show a git logical variable + + +SYNOPSIS +-------- +'git var' [ -l | <variable> ] + +DESCRIPTION +----------- +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 + as well. (However, the configuration variables listing functionality + is deprecated in favor of 'git config -l'.) + +EXAMPLE +-------- + $ git var GIT_AUTHOR_IDENT + Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600 + + +VARIABLES +---------- +GIT_AUTHOR_IDENT:: + The author of a piece of code. + +GIT_COMMITTER_IDENT:: + 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 + 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'. + +GIT_PAGER:: + 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. + +SEE ALSO +-------- +linkgit:git-commit-tree[1] +linkgit:git-tag[1] +linkgit:git-config[1] + +Author +------ +Written by Eric Biederman <ebiederm@xmission.com> + +Documentation +-------------- +Documentation by Eric Biederman and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt new file mode 100644 index 0000000000..97f7f9165e --- /dev/null +++ b/Documentation/git-verify-pack.txt @@ -0,0 +1,60 @@ +git-verify-pack(1) +================== + +NAME +---- +git-verify-pack - Validate packed git archive files + + +SYNOPSIS +-------- +'git verify-pack' [-v|--verbose] [--] <pack>.idx ... + + +DESCRIPTION +----------- +Reads given idx file for packed git archive created with the +'git-pack-objects' command and verifies idx file and the +corresponding pack file. + +OPTIONS +------- +<pack>.idx ...:: + The idx files to verify. + +-v:: +--verbose:: + After verifying the pack, show list of objects contained + in the pack and a histogram of delta chain length. + +-s:: +--stat-only:: + Do not verify the pack contents; only show the histogram of delta + chain length. With `--verbose`, list of objects is also shown. + +\--:: + Do not interpret any more arguments as options. + +OUTPUT FORMAT +------------- +When specifying the -v option the format used is: + + SHA1 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 + +for objects that are deltified. + +Author +------ +Written by Junio C Hamano <gitster@pobox.com> + +Documentation +-------------- +Documentation by Junio C Hamano + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-verify-tag.txt b/Documentation/git-verify-tag.txt new file mode 100644 index 0000000000..84e70a0234 --- /dev/null +++ b/Documentation/git-verify-tag.txt @@ -0,0 +1,31 @@ +git-verify-tag(1) +================= + +NAME +---- +git-verify-tag - Check the GPG signature of tags + +SYNOPSIS +-------- +'git verify-tag' <tag>... + +DESCRIPTION +----------- +Validates the gpg signature created by 'git-tag'. + +OPTIONS +------- +<tag>...:: + SHA1 identifiers of git tag objects. + +Author +------ +Written by Jan Harkes <jaharkes@cs.cmu.edu> and Eric W. Biederman <ebiederm@xmission.com> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-web--browse.txt b/Documentation/git-web--browse.txt new file mode 100644 index 0000000000..278cf73527 --- /dev/null +++ b/Documentation/git-web--browse.txt @@ -0,0 +1,125 @@ +git-web--browse(1) +================== + +NAME +---- +git-web--browse - git helper script to launch a web browser + +SYNOPSIS +-------- +'git web--browse' [OPTIONS] URL/FILE ... + +DESCRIPTION +----------- + +This script tries, as much as possible, to display the URLs and FILEs +that are passed as arguments, as HTML pages in new tabs on an already +opened web browser. + +The following browsers (or commands) are currently supported: + +* firefox (this is the default under X Window when not using KDE) +* iceweasel +* konqueror (this is the default under KDE, see 'Note about konqueror' below) +* w3m (this is the default outside graphical environments) +* links +* lynx +* dillo +* open (this is the default under Mac OS X GUI) +* start (this is the default under MinGW) + +Custom commands may also be specified. + +OPTIONS +------- +-b BROWSER:: +--browser=BROWSER:: + Use the specified BROWSER. It must be in the list of supported + browsers. + +-t BROWSER:: +--tool=BROWSER:: + Same as above. + +-c CONF.VAR:: +--config=CONF.VAR:: + CONF.VAR is looked up in the git config files. If it's set, + then its value specify the browser that should be used. + +CONFIGURATION VARIABLES +----------------------- + +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' +configuration variable if the former is not used. + +browser.<tool>.path +~~~~~~~~~~~~~~~~~~~ + +You can explicitly provide a full path to your preferred browser by +setting the configuration variable 'browser.<tool>.path'. For example, +you can configure the absolute path to firefox by setting +'browser.firefox.path'. Otherwise, 'git-web--browse' assumes the tool +is available in PATH. + +browser.<tool>.cmd +~~~~~~~~~~~~~~~~~~ + +When the browser, specified by options or configuration variables, is +not among the supported ones, then the corresponding +'browser.<tool>.cmd' configuration variable will be looked up. If this +variable exists then 'git-web--browse' will treat the specified tool +as a custom command and will use a shell eval to run the command with +the URLs passed as arguments. + +Note about konqueror +-------------------- + +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. + +For consistency, we also try such a trick if 'browser.konqueror.path' is +set to something like 'A_PATH_TO/konqueror'. That means we will try to +launch 'A_PATH_TO/kfmclient' instead. + +If you really want to use 'konqueror', then you can use something like +the following: + +------------------------------------------------ + [web] + browser = konq + + [browser "konq"] + cmd = A_PATH_TO/konqueror +------------------------------------------------ + +Note about git-config --global +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Note that these configuration variables should probably be set using +the '--global' flag, for example like this: + +------------------------------------------------ +$ git config --global web.browser firefox +------------------------------------------------ + +as they are probably more user specific than repository specific. +See linkgit:git-config[1] for more information about this. + +Author +------ +Written by Christian Couder <chriscool@tuxfamily.org> and the git-list +<git@vger.kernel.org>, based on 'git-mergetool' by Theodore Y. Ts'o. + +Documentation +------------- +Documentation by Christian Couder <chriscool@tuxfamily.org> and the +git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt new file mode 100644 index 0000000000..cadfbd9040 --- /dev/null +++ b/Documentation/git-whatchanged.txt @@ -0,0 +1,79 @@ +git-whatchanged(1) +================== + +NAME +---- +git-whatchanged - Show logs with difference each commit introduces + + +SYNOPSIS +-------- +'git whatchanged' <option>... + +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. + + +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. + +-<n>:: + Limit output to <n> commits. + +<since>..<until>:: + Limit output to between the two named commits (bottom + exclusive, top inclusive). + +-r:: + Show git internal diff output, but for the whole tree, + not just the top level. + +-m:: + By default, differences for merge commits are not shown. + With this flag, show differences to that commit from all + of its parents. ++ +However, it is not very useful in general, although it +*is* useful on a file-by-file basis. + +include::pretty-options.txt[] + +include::pretty-formats.txt[] + +Examples +-------- +git whatchanged -p v2.6.12.. include/scsi drivers/scsi:: + + 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:: + + Show the changes during the last two weeks to the file 'gitk'. + The "--" is necessary to avoid confusion with the *branch* named + 'gitk' + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> and +Junio C Hamano <gitster@pobox.com> + + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt new file mode 100644 index 0000000000..c8899d528a --- /dev/null +++ b/Documentation/git-write-tree.txt @@ -0,0 +1,50 @@ +git-write-tree(1) +================= + +NAME +---- +git-write-tree - Create a tree object from the current index + + +SYNOPSIS +-------- +'git write-tree' [--missing-ok] [--prefix=<prefix>/] + +DESCRIPTION +----------- +Creates a tree object using the current index. The name of the new +tree object is printed to standard output. + +The index must be in a fully merged state. + +Conceptually, 'git-write-tree' sync()s the current index contents +into a set of tree files. +In order to have that match what is actually in your directory right +now, you need to have done a 'git-update-index' phase before you did the +'git-write-tree'. + + +OPTIONS +------- +--missing-ok:: + Normally 'git-write-tree' ensures that the objects referenced by the + directory exist in the object database. This option disables this + check. + +--prefix=<prefix>/:: + Writes a tree object that represents a subdirectory + `<prefix>`. This can be used to write the tree object + for a subproject that is in the named subdirectory. + + +Author +------ +Written by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/git.txt b/Documentation/git.txt new file mode 100644 index 0000000000..ad6037baa0 --- /dev/null +++ b/Documentation/git.txt @@ -0,0 +1,684 @@ +git(1) +====== + +NAME +---- +git - the stupid content tracker + + +SYNOPSIS +-------- +[verse] +'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path] + [-p|--paginate|--no-pager] [--no-replace-objects] + [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] + [--help] COMMAND [ARGS] + +DESCRIPTION +----------- +Git is a fast, scalable, distributed revision control system with an +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. + +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]). + +Formatted and hyperlinked version of the latest git +documentation can be viewed at +`http://www.kernel.org/pub/software/scm/git/docs/`. + +ifdef::stalenotes[] +[NOTE] +============ + +You are reading the documentation for the latest (possibly +unreleased) version of git, that is available from 'master' +branch of the `git.git` repository. +Documentation for older releases are available here: + +* link:v1.6.5.5/git.html[documentation for release 1.6.5.5] + +* release notes for + link:RelNotes-1.6.5.5.txt[1.6.5.5], + link:RelNotes-1.6.5.4.txt[1.6.5.4], + link:RelNotes-1.6.5.3.txt[1.6.5.3], + link:RelNotes-1.6.5.2.txt[1.6.5.2], + link:RelNotes-1.6.5.1.txt[1.6.5.1], + link:RelNotes-1.6.5.txt[1.6.5]. + +* link:v1.6.4.4/git.html[documentation for release 1.6.4.4] + +* release notes for + link:RelNotes-1.6.4.4.txt[1.6.4.4], + link:RelNotes-1.6.4.3.txt[1.6.4.3], + link:RelNotes-1.6.4.2.txt[1.6.4.2], + link:RelNotes-1.6.4.1.txt[1.6.4.1], + link:RelNotes-1.6.4.txt[1.6.4]. + +* link:v1.6.3.4/git.html[documentation for release 1.6.3.4] + +* release notes for + link:RelNotes-1.6.3.4.txt[1.6.3.4], + link:RelNotes-1.6.3.3.txt[1.6.3.3], + link:RelNotes-1.6.3.2.txt[1.6.3.2], + link:RelNotes-1.6.3.1.txt[1.6.3.1], + link:RelNotes-1.6.3.txt[1.6.3]. + +* release notes for + link:RelNotes-1.6.2.5.txt[1.6.2.5], + link:RelNotes-1.6.2.4.txt[1.6.2.4], + link:RelNotes-1.6.2.3.txt[1.6.2.3], + link:RelNotes-1.6.2.2.txt[1.6.2.2], + link:RelNotes-1.6.2.1.txt[1.6.2.1], + link:RelNotes-1.6.2.txt[1.6.2]. + +* link:v1.6.1.3/git.html[documentation for release 1.6.1.3] + +* release notes for + link:RelNotes-1.6.1.3.txt[1.6.1.3], + link:RelNotes-1.6.1.2.txt[1.6.1.2], + link:RelNotes-1.6.1.1.txt[1.6.1.1], + link:RelNotes-1.6.1.txt[1.6.1]. + +* link:v1.6.0.6/git.html[documentation for release 1.6.0.6] + +* release notes for + link:RelNotes-1.6.0.6.txt[1.6.0.6], + link:RelNotes-1.6.0.5.txt[1.6.0.5], + link:RelNotes-1.6.0.4.txt[1.6.0.4], + link:RelNotes-1.6.0.3.txt[1.6.0.3], + link:RelNotes-1.6.0.2.txt[1.6.0.2], + link:RelNotes-1.6.0.1.txt[1.6.0.1], + link:RelNotes-1.6.0.txt[1.6.0]. + +* link:v1.5.6.6/git.html[documentation for release 1.5.6.6] + +* release notes for + link:RelNotes-1.5.6.6.txt[1.5.6.6], + link:RelNotes-1.5.6.5.txt[1.5.6.5], + link:RelNotes-1.5.6.4.txt[1.5.6.4], + link:RelNotes-1.5.6.3.txt[1.5.6.3], + link:RelNotes-1.5.6.2.txt[1.5.6.2], + link:RelNotes-1.5.6.1.txt[1.5.6.1], + link:RelNotes-1.5.6.txt[1.5.6]. + +* link:v1.5.5.6/git.html[documentation for release 1.5.5.6] + +* release notes for + link:RelNotes-1.5.5.6.txt[1.5.5.6], + link:RelNotes-1.5.5.5.txt[1.5.5.5], + link:RelNotes-1.5.5.4.txt[1.5.5.4], + link:RelNotes-1.5.5.3.txt[1.5.5.3], + link:RelNotes-1.5.5.2.txt[1.5.5.2], + link:RelNotes-1.5.5.1.txt[1.5.5.1], + link:RelNotes-1.5.5.txt[1.5.5]. + +* link:v1.5.4.7/git.html[documentation for release 1.5.4.7] + +* release notes for + link:RelNotes-1.5.4.7.txt[1.5.4.7], + link:RelNotes-1.5.4.6.txt[1.5.4.6], + link:RelNotes-1.5.4.5.txt[1.5.4.5], + link:RelNotes-1.5.4.4.txt[1.5.4.4], + link:RelNotes-1.5.4.3.txt[1.5.4.3], + link:RelNotes-1.5.4.2.txt[1.5.4.2], + link:RelNotes-1.5.4.1.txt[1.5.4.1], + link:RelNotes-1.5.4.txt[1.5.4]. + +* link:v1.5.3.8/git.html[documentation for release 1.5.3.8] + +* release notes for + link:RelNotes-1.5.3.8.txt[1.5.3.8], + link:RelNotes-1.5.3.7.txt[1.5.3.7], + link:RelNotes-1.5.3.6.txt[1.5.3.6], + link:RelNotes-1.5.3.5.txt[1.5.3.5], + link:RelNotes-1.5.3.4.txt[1.5.3.4], + link:RelNotes-1.5.3.3.txt[1.5.3.3], + link:RelNotes-1.5.3.2.txt[1.5.3.2], + link:RelNotes-1.5.3.1.txt[1.5.3.1], + link:RelNotes-1.5.3.txt[1.5.3]. + +* link:v1.5.2.5/git.html[documentation for release 1.5.2.5] + +* release notes for + link:RelNotes-1.5.2.5.txt[1.5.2.5], + link:RelNotes-1.5.2.4.txt[1.5.2.4], + link:RelNotes-1.5.2.3.txt[1.5.2.3], + link:RelNotes-1.5.2.2.txt[1.5.2.2], + link:RelNotes-1.5.2.1.txt[1.5.2.1], + link:RelNotes-1.5.2.txt[1.5.2]. + +* link:v1.5.1.6/git.html[documentation for release 1.5.1.6] + +* release notes for + link:RelNotes-1.5.1.6.txt[1.5.1.6], + link:RelNotes-1.5.1.5.txt[1.5.1.5], + link:RelNotes-1.5.1.4.txt[1.5.1.4], + link:RelNotes-1.5.1.3.txt[1.5.1.3], + link:RelNotes-1.5.1.2.txt[1.5.1.2], + link:RelNotes-1.5.1.1.txt[1.5.1.1], + link:RelNotes-1.5.1.txt[1.5.1]. + +* link:v1.5.0.7/git.html[documentation for release 1.5.0.7] + +* release notes for + link:RelNotes-1.5.0.7.txt[1.5.0.7], + link:RelNotes-1.5.0.6.txt[1.5.0.6], + link:RelNotes-1.5.0.5.txt[1.5.0.5], + link:RelNotes-1.5.0.3.txt[1.5.0.3], + link:RelNotes-1.5.0.2.txt[1.5.0.2], + link:RelNotes-1.5.0.1.txt[1.5.0.1], + link:RelNotes-1.5.0.txt[1.5.0]. + +* documentation for release link:v1.4.4.4/git.html[1.4.4.4], + link:v1.3.3/git.html[1.3.3], + link:v1.2.6/git.html[1.2.6], + link:v1.0.13/git.html[1.0.13]. + +============ + +endif::stalenotes[] + +OPTIONS +------- +--version:: + 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 + option will bring up the manual page for that command. ++ +Other options are available to control how the manual page is +displayed. See linkgit:git-help[1] for more information, +because `git --help ...` is converted internally into `git +help ...`. + +--exec-path:: + 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 to wherever your git HTML documentation is installed + and exit. + +-p:: +--paginate:: + Pipe all output into 'less' (or if set, $PAGER). + +--no-pager:: + Do not pipe git output into a pager. + +--git-dir=<path>:: + Set the path to the repository. This can also be controlled by + setting the GIT_DIR environment variable. It can be an absolute + path or relative path to current working directory. + +--work-tree=<path>:: + 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 setting the GIT_WORK_TREE + environment variable and the core.worktree configuration + variable. It can be an absolute path or relative path to + the directory specified by --git-dir or GIT_DIR. + Note: If --git-dir or GIT_DIR are specified but none of + --work-tree, GIT_WORK_TREE and core.worktree is specified, + the current working directory is regarded as the top directory + of your working tree. + +--bare:: + Treat the repository as a bare repository. If GIT_DIR + environment is not set, it is set to the current working + directory. + +--no-replace-objects:: + Do not use replacement refs to replace git objects. See + linkgit:git-replace[1] for more information. + + +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. + +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]. + +GIT COMMANDS +------------ + +We divide git into high level ("porcelain") commands and low level +("plumbing") commands. + +High-level commands (porcelain) +------------------------------- + +We separate the porcelain commands into the main commands and some +ancillary user utilities. + +Main porcelain commands +~~~~~~~~~~~~~~~~~~~~~~~ + +include::cmds-mainporcelain.txt[] + +Ancillary Commands +~~~~~~~~~~~~~~~~~~ +Manipulators: + +include::cmds-ancillarymanipulators.txt[] + +Interrogators: + +include::cmds-ancillaryinterrogators.txt[] + + +Interacting with Others +~~~~~~~~~~~~~~~~~~~~~~~ + +These commands are to interact with foreign SCM and with other +people via patch over e-mail. + +include::cmds-foreignscminterface.txt[] + + +Low-level commands (plumbing) +----------------------------- + +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 +linkgit:git-read-tree[1]. + +The interface (input, output, set of options and the semantics) +to these low-level commands are meant to be a lot more stable +than Porcelain level commands, because these commands are +primarily for scripted use. The interface to Porcelain commands +on the other hand are subject to change in order to improve the +end user experience. + +The following description divides +the low-level commands into commands that manipulate objects (in +the repository, index, and working tree), commands that interrogate and +compare objects, and commands that move objects and references between +repositories. + + +Manipulation commands +~~~~~~~~~~~~~~~~~~~~~ + +include::cmds-plumbingmanipulators.txt[] + + +Interrogation commands +~~~~~~~~~~~~~~~~~~~~~~ + +include::cmds-plumbinginterrogators.txt[] + +In general, the interrogate commands do not touch the files in +the working tree. + + +Synching repositories +~~~~~~~~~~~~~~~~~~~~~ + +include::cmds-synchingrepositories.txt[] + +The following are helper commands used by the above; end users +typically do not use them directly. + +include::cmds-synchelpers.txt[] + + +Internal helper commands +~~~~~~~~~~~~~~~~~~~~~~~~ + +These are internal helper commands used by other commands; end +users typically do not use them directly. + +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: + +------------ +# +# A '#' or ';' character indicates a comment. +# + +; core variables +[core] + ; Don't trust file modes + filemode = false + +; user identity +[user] + name = "Junio C Hamano" + email = "junkio@twinsun.com" + +------------ + +Various commands read from the configuration file and adjust +their operation accordingly. + + +Identifier Terminology +---------------------- +<object>:: + Indicates the object name for any type of object. + +<blob>:: + Indicates a blob object name. + +<tree>:: + Indicates a tree object name. + +<commit>:: + Indicates a commit object name. + +<tree-ish>:: + Indicates a tree, commit or tag object name. A + command that takes a <tree-ish> argument ultimately wants to + operate on a <tree> object but automatically dereferences + <commit> and <tag> objects that point at a <tree>. + +<commit-ish>:: + Indicates a commit or tag object name. A + command that takes a <commit-ish> argument ultimately wants to + operate on a <commit> object but automatically dereferences + <tag> objects that point at a <commit>. + +<type>:: + Indicates that an object type is required. + Currently one of: `blob`, `tree`, `commit`, or `tag`. + +<file>:: + Indicates a filename - almost always relative to the + root of the tree structure `GIT_INDEX_FILE` describes. + +Symbolic Identifiers +-------------------- +Any git command accepting any <object> can also use the following +symbolic notation: + +HEAD:: + indicates the head of the current branch (i.e. the + contents of `$GIT_DIR/HEAD`). + +<tag>:: + a valid tag 'name' + (i.e. the contents of `$GIT_DIR/refs/tags/<tag>`). + +<head>:: + a valid head 'name' + (i.e. the contents of `$GIT_DIR/refs/heads/<head>`). + +For a more complete list of ways to spell object names, see +"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. + + +File/Directory Structure +------------------------ + +Please see the linkgit:gitrepository-layout[5] document. + +Read linkgit:githooks[5] for more details about each hook. + +Higher level SCMs may provide and manage additional information in the +`$GIT_DIR`. + + +Terminology +----------- +Please see linkgit:gitglossary[7]. + + +Environment Variables +--------------------- +Various git commands use the following environment variables: + +The git Repository +~~~~~~~~~~~~~~~~~~ +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_INDEX_FILE':: + This environment allows the specification of an alternate + index file. If not specified, the default of `$GIT_DIR/index` + is used. + +'GIT_OBJECT_DIRECTORY':: + If the object storage directory is specified via this + environment variable then the sha1 directories are created + underneath - otherwise the default `$GIT_DIR/objects` + directory is used. + +'GIT_ALTERNATE_OBJECT_DIRECTORIES':: + 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 + 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. + +'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 + option and the core.worktree configuration variable. + +'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.) + +git Commits +~~~~~~~~~~~ +'GIT_AUTHOR_NAME':: +'GIT_AUTHOR_EMAIL':: +'GIT_AUTHOR_DATE':: +'GIT_COMMITTER_NAME':: +'GIT_COMMITTER_EMAIL':: +'GIT_COMMITTER_DATE':: +'EMAIL':: + see linkgit:git-commit-tree[1] + +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. + +'GIT_EXTERNAL_DIFF':: + When the environment variable 'GIT_EXTERNAL_DIFF' is set, the + program named by it is called, instead of the diff invocation + described above. For a path that is added, removed, or modified, + 'GIT_EXTERNAL_DIFF' is called with 7 parameters: + + path old-file old-hex old-mode new-file new-hex new-mode ++ +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>-mode:: are the octal representation of the file modes. + ++ +The file parameters can point at the user's working file +(e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file` +when a new file is added), or a temporary file (e.g. `old-file` in the +index). 'GIT_EXTERNAL_DIFF' should not worry about unlinking the +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>. + +other +~~~~~ +'GIT_MERGE_VERBOSITY':: + A number controlling the amount of output shown by + the recursive merge strategy. Overrides merge.verbosity. + See linkgit:git-merge[1] + +'GIT_PAGER':: + This environment variable overrides `$PAGER`. If it is set + 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_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. ++ +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. ++ +Usually it is easier to configure any desired options through your +personal `.ssh/config` file. Please consult your ssh documentation +for further details. + +'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 + 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 + 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. + +Discussion[[Discussion]] +------------------------ + +More detail on the following is available from 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" +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 +contents of the working tree, and named pointers into that history such +as tags and branch heads. + +The object database contains objects of three main types: blobs, which +hold file data; trees, which point to blobs and other trees to build up +directory hierarchies; and commits, which each reference a single tree +and some number of parent commits. + +The commit, equivalent to what other systems call a "changeset" or +"version", represents a step in the project's history, and each parent +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 +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 +purpose. + +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 +tags of interest are stored under `ref/tags/`. A special ref named +`HEAD` contains the name of the currently checked-out branch. + +The index file is initialized with a list of all paths and, for each +path, a blob object and a set of attributes. The blob object represents +the contents of the file as of the head of the current branch. The +attributes (last modified time, size, etc.) are taken from the +corresponding file in the working tree. Subsequent changes to the +working tree can be found by comparing these attributes. The index may +be updated with new content, and new commits may be created from the +content stored in the index. + +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. + +Authors +------- +* git's founding father is Linus Torvalds <torvalds@osdl.org>. +* The current git nurse is Junio C Hamano <gitster@pobox.com>. +* The git potty was written by Andreas Ericsson <ae@op5.se>. +* General upbringing is handled by the git-list <git@vger.kernel.org>. + +Documentation +-------------- +The documentation for git suite was started by David Greaves +<david@dgreaves.com>, and later enhanced greatly by the +contributors on the git-list <git@vger.kernel.org>. + +SEE ALSO +-------- +linkgit:gittutorial[7], linkgit:gittutorial-2[7], +link:everyday.html[Everyday Git], 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] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt new file mode 100644 index 0000000000..1f472cea59 --- /dev/null +++ b/Documentation/gitattributes.txt @@ -0,0 +1,677 @@ +gitattributes(5) +================ + +NAME +---- +gitattributes - defining attributes per path + +SYNOPSIS +-------- +$GIT_DIR/info/attributes, .gitattributes + + +DESCRIPTION +----------- + +A `gitattributes` file is a simple text file that gives +`attributes` to pathnames. + +Each line in `gitattributes` file is of form: + + pattern attr1 attr2 ... + +That is, a pattern followed by an attributes list, +separated by whitespaces. When the pattern matches the +path in question, the attributes listed on the line are given to +the path. + +Each attribute can be in one of these states for a given path: + +Set:: + + The path has the attribute with special value "true"; + this is specified by listing only the name of the + attribute in the attribute list. + +Unset:: + + The path has the attribute with special value "false"; + this is specified by listing the name of the attribute + prefixed with a dash `-` in the attribute list. + +Set to a value:: + + The path has the attribute with specified string value; + this is specified by listing the name of the attribute + followed by an equal sign `=` and its value in the + attribute list. + +Unspecified:: + + No pattern matches the path, and nothing says if + the path has or does not have the attribute, the + attribute for the path is said to be Unspecified. + +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]. + +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 +work tree (the further the directory that contains `.gitattributes` +is from the path in question, the lower its precedence). + +If you wish to affect only a single repository (i.e., to assign +attributes to files that are particular to one user's workflow), then +attributes should be placed in the `$GIT_DIR/info/attributes` file. +Attributes which should be version-controlled and distributed to other +repositories (i.e., attributes of interest to all users) should go into +`.gitattributes` files. + +Sometimes you would need to override an setting of an attribute +for a path to `unspecified` state. This can be done by listing +the name of the attribute prefixed with an exclamation point `!`. + + +EFFECTS +------- + +Certain operations by git can be influenced by assigning +particular attributes to a path. Currently, the following +operations are attributes-aware. + +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 +repository upon 'git-add' and 'git-commit'. + +`crlf` +^^^^^^ + +This attribute controls the line-ending convention. + +Set:: + + Setting the `crlf` attribute on a path is meant to mark + the path as a "text" file. 'core.autocrlf' conversion + takes place without guessing the content type by + inspection. + +Unset:: + + Unsetting the `crlf` attribute on a path tells git not to + attempt any end-of-line conversion upon checkin or checkout. + +Unspecified:: + + Unspecified `crlf` attribute tells git to apply the + `core.autocrlf` conversion when the file content looks + like text. + +Set to string value "input":: + + This is similar to setting the attribute to `true`, but + also forces git to act as if `core.autocrlf` is set to + `input` for the path. + +Any other value set to `crlf` attribute is ignored and git acts +as if the attribute is left unspecified. + + +The `core.autocrlf` conversion +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If the configuration variable `core.autocrlf` is false, no +conversion is done. + +When `core.autocrlf` is true, it means that the platform wants +CRLF line endings for files in the working tree, and you want to +convert them back to the normal LF line endings when checking +in to the repository. + +When `core.autocrlf` is set to "input", line endings are +converted to LF upon checkin, but there is no conversion done +upon checkout. + +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 +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... + +- 'git-add' itself does not touch the files in the work tree, the + next checkout would, so the safety triggers; + +- 'git-apply' to update a text file with a patch does touch the files + in the work tree, but the operation is about text files and CRLF + conversion is about fixing the line ending inconsistencies, so the + safety does not trigger; + +- 'git-diff' itself does not touch the files in the work tree, it is + often run to inspect the changes you intend to next 'git-add'. To + catch potential problems early, safety triggers. + + +`ident` +^^^^^^^ + +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 +`$Id:` and ends with `$` in the worktree file is replaced +with `$Id$` upon check-in. + + +`filter` +^^^^^^^^ + +A `filter` attribute can be set to a string value that names a +filter driver specified in the configuration. + +A filter driver consists of a `clean` command and a `smudge` +command, either of which can be left unspecified. Upon +checkout, when the `smudge` command is specified, the command is +fed the blob object from its standard input, and its standard +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. + +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. + + +Interaction between checkin/checkout attributes +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In the check-in codepath, the worktree file is first converted +with `filter` driver (if specified and corresponding driver +defined), then the result is processed with `ident` (if +specified), and then finally with `crlf` (again, if specified +and applicable). + +In the check-out codepath, the blob content is first converted +with `crlf`, and then `ident` and fed to `filter`. + + +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 +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 +files to a text format before generating the diff. + +Set:: + + A path to which the `diff` attribute is set is treated + as text, even when they contain byte values that + normally never appear in text files, such as NUL. + +Unset:: + + A path to which the `diff` attribute is unset will + generate `Binary files differ` (or a binary patch, if + binary patches are enabled). + +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`. + +String:: + + Diff is shown using the specified diff driver. Each driver may + 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. + + +Defining an external diff driver +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The definition of a diff driver is done in `gitconfig`, not +`gitattributes` file, so strictly speaking this manual page is a +wrong place to talk about it. However... + +To define an external diff driver `jcdiff`, add a section to your +`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: + +---------------------------------------------------------------- +[diff "jcdiff"] + command = j-c-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. +See linkgit:git[1] for details. + + +Defining a custom hunk-header +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Each group of changes (called a "hunk") in the textual diff output +is prefixed with a line of the form: + + @@ -k,l +n,m @@ TEXT + +This is called a 'hunk header'. The "TEXT" portion is by default a line +that begins with an alphabet, an underscore or a dollar sign; this +matches what GNU 'diff -p' output uses. This default selection however +is not suited for some contents, and you can use a customized pattern +to make a selection. + +First, in .gitattributes, you would assign the `diff` attribute +for paths. + +------------------------ +*.tex diff=tex +------------------------ + +Then, you would define a "diff.tex.xfuncname" configuration to +specify a regular expression that matches a line that you would +want to appear as the hunk header "TEXT". Add a section to your +`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: + +------------------------ +[diff "tex"] + xfuncname = "^(\\\\(sub)*section\\{.*)$" +------------------------ + +Note. A single level of backslashes are eaten by the +configuration file parser, so you would need to double the +backslashes; the pattern above picks a line that begins with a +backslash, and zero or more occurrences of `sub` followed by +`section` followed by open brace, to the end of line. + +There are a few built-in patterns to make this easier, and `tex` +is one of them, so you do not have to write the above in your +configuration file (you still need to enable this with the +attribute mechanism, via `.gitattributes`). The following built in +patterns are available: + +- `bibtex` suitable for files with BibTeX coded references. + +- `cpp` suitable for source code in the C and C++ languages. + +- `html` suitable for HTML/XHTML documents. + +- `java` suitable for source code in the Java language. + +- `objc` suitable for source code in the Objective-C language. + +- `pascal` suitable for source code in the Pascal/Delphi language. + +- `php` suitable for source code in the PHP language. + +- `python` suitable for source code in the Python language. + +- `ruby` suitable for source code in the Ruby language. + +- `tex` suitable for source code for LaTeX documents. + + +Customizing word diff +^^^^^^^^^^^^^^^^^^^^^ + +You can customize the rules that `git diff --color-words` uses to +split words in a line, by specifying an appropriate regular expression +in the "diff.*.wordRegex" configuration variable. For example, in TeX +a backslash followed by a sequence of letters forms a command, but +several such commands can be run together without intervening +whitespace. To separate them, use a regular expression in your +`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: + +------------------------ +[diff "tex"] + wordRegex = "\\\\[a-zA-Z]+|[{}]|\\\\.|[^\\{}[:space:]]+" +------------------------ + +A built-in pattern is provided for all languages listed in the +previous section. + + +Performing text diffs of binary files +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Sometimes it is desirable to see the diff of a text-converted +version of some binary files. For example, a word processor +document can be converted to an ASCII text representation, and +the diff of the text shown. Even though this conversion loses +some information, the resulting diff is useful for human +viewing (but cannot be applied directly). + +The `textconv` config option is used to define a program for +performing such a conversion. The program should take a single +argument, the name of a file to convert, and produce the +resulting text on stdout. + +For example, to show the diff of the exif information of a +file instead of the binary information (assuming you have the +exif tool installed), add the following section to your +`$GIT_DIR/config` file (or `$HOME/.gitconfig` file): + +------------------------ +[diff "jpg"] + textconv = exif +------------------------ + +NOTE: The text conversion is generally a one-way conversion; +in this example, we lose the actual image contents and focus +just on the text data. This means that diffs generated by +textconv are _not_ suitable for applying. For this reason, +only `git diff` and the `git log` family of commands (i.e., +log, whatchanged, show) will perform text conversion. `git +format-patch` will never generate this output. If you want to +send somebody a text-converted diff of a binary file (e.g., +because it quickly conveys the changes you have made), you +should generate it separately and send it as a comment _in +addition to_ the usual binary diff that you might send. + + +Performing a three-way merge +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +`merge` +^^^^^^^ + +The attribute `merge` affects how three versions of a file is +merged when a file-level merge is necessary during `git merge`, +and other commands such as `git revert` and `git cherry-pick`. + +Set:: + + Built-in 3-way merge driver is used to merge the + contents in a way similar to 'merge' command of `RCS` + suite. This is suitable for ordinary text files. + +Unset:: + + Take the version from the current branch as the + tentative merge result, and declare that the merge has + conflicts. This is suitable for binary files that does + not have a well-defined merge semantics. + +Unspecified:: + + By default, this uses the same built-in 3-way merge + driver as is the case the `merge` attribute is set. + However, `merge.default` configuration variable can name + different merge driver to be used for paths to which the + `merge` attribute is unspecified. + +String:: + + 3-way merge is performed using the specified custom + merge driver. The built-in 3-way merge driver can be + explicitly specified by asking for "text" driver; the + built-in "take the current branch" driver can be + requested with "binary". + + +Built-in merge drivers +^^^^^^^^^^^^^^^^^^^^^^ + +There are a few built-in low-level merge drivers defined that +can be asked for via the `merge` attribute. + +text:: + + Usual 3-way file level merge for text files. Conflicted + regions are marked with conflict markers `<<<<<<<`, + `=======` and `>>>>>>>`. The version from your branch + appears before the `=======` marker, and the version + from the merged branch appears after the `=======` + marker. + +binary:: + + Keep the version from your branch in the work tree, but + leave the path in the conflicted state for the user to + sort out. + +union:: + + Run 3-way file level merge for text files, but take + lines from both versions, instead of leaving conflict + markers. This tends to leave the added lines in the + resulting file in random order and the user should + verify the result. Do not use this if you do not + understand the implications. + + +Defining a custom merge driver +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The definition of a merge driver is done in the `.git/config` +file, not in the `gitattributes` file, so strictly speaking this +manual page is a wrong place to talk about it. However... + +To define a custom merge driver `filfre`, add a section to your +`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: + +---------------------------------------------------------------- +[merge "filfre"] + name = feel-free merge driver + driver = filfre %O %A %B + recursive = binary +---------------------------------------------------------------- + +The `merge.*.name` variable gives the driver a human-readable +name. + +The `merge.*.driver` variable's value is used to construct a +command to run to merge ancestor's version (`%O`), current +version (`%A`) and the other branches' version (`%B`). These +three tokens are replaced with the names of temporary files that +hold the contents of these versions when the command line is +built. + +The merge driver is expected to leave the result of the merge in +the file named with `%A` by overwriting it, and exit with zero +status if it managed to merge them cleanly, or non-zero if there +were conflicts. + +The `merge.*.recursive` variable specifies what other merge +driver to use when the merge driver is called for an internal +merge between common ancestors, when there are more than one. +When left unspecified, the driver itself is used for both +internal merge and the final merge. + + +Checking whitespace errors +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +`whitespace` +^^^^^^^^^^^^ + +The `core.whitespace` configuration variable allows you to define what +'diff' and 'apply' should consider whitespace errors for all paths in +the project (See linkgit:git-config[1]). This attribute gives you finer +control per path. + +Set:: + + Notice all types of potential whitespace errors known to git. + +Unset:: + + Do not notice anything as error. + +Unspecified:: + + Use the value of `core.whitespace` configuration variable to + decide what to notice as error. + +String:: + + Specify a comma separate list of common whitespace problems to + notice in the same format as `core.whitespace` configuration + variable. + + +Creating an archive +~~~~~~~~~~~~~~~~~~~ + +`export-ignore` +^^^^^^^^^^^^^^^ + +Files and directories with the attribute `export-ignore` won't be added to +archive files. + +`export-subst` +^^^^^^^^^^^^^^ + +If the attribute `export-subst` is set for a file then git will expand +several placeholders when adding this file to an archive. 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 +tag then no replacement will be done. The placeholders are the same +as those for the option `--pretty=format:` of linkgit:git-log[1], +except that they need to be wrapped like this: `$Format:PLACEHOLDERS$` +in the file. E.g. the string `$Format:%H$` will be replaced by the +commit hash. + + +Packing objects +~~~~~~~~~~~~~~~ + +`delta` +^^^^^^^ + +Delta compression will not be attempted for blobs for paths with the +attribute `delta` set to false. + + +Viewing files in GUI tools +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +`encoding` +^^^^^^^^^^ + +The value of this attribute specifies the character encoding that should +be used by GUI tools (e.g. linkgit:gitk[1] and linkgit:git-gui[1]) to +display the contents of the relevant file. Note that due to performance +considerations linkgit:gitk[1] does not use this attribute unless you +manually enable per-file encodings in its options. + +If this attribute is not set or has an invalid value, the value of the +`gui.encoding` configuration variable is used instead +(See linkgit:git-config[1]). + + +USING ATTRIBUTE MACROS +---------------------- + +You do not want any end-of-line conversions applied to, nor textual diffs +produced for, any binary file you track. You would need to specify e.g. + +------------ +*.jpg -crlf -diff +------------ + +but that may become cumbersome, when you have many attributes. Using +attribute macros, you can specify groups of attributes set or unset at +the same time. The system knows a built-in attribute macro, `binary`: + +------------ +*.jpg binary +------------ + +which is equivalent to the above. Note that the attribute macros can only +be "Set" (see the above example that sets "binary" macro as if it were an +ordinary attribute --- setting it in turn unsets "crlf" and "diff"). + + +DEFINING ATTRIBUTE MACROS +------------------------- + +Custom attribute macros can be defined only in the `.gitattributes` file +at the toplevel (i.e. not in any subdirectory). The built-in attribute +macro "binary" is equivalent to: + +------------ +[attr]binary -diff -crlf +------------ + + +EXAMPLE +------- + +If you have these three `gitattributes` file: + +---------------------------------------------------------------- +(in $GIT_DIR/info/attributes) + +a* foo !bar -baz + +(in .gitattributes) +abc foo bar baz + +(in t/.gitattributes) +ab* merge=filfre +abc -foo -bar +*.c frotz +---------------------------------------------------------------- + +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 + line matches. `merge` attribute is set. It also finds that + the second line matches, and attributes `foo` and `bar` + are unset. + +2. Then it examines `.gitattributes` (which is in the parent + directory), and finds that the first line matches, but + `t/.gitattributes` file already decided how `merge`, `foo` + and `bar` attributes should be given to this path, so it + leaves `foo` and `bar` unset. Attribute `baz` is set. + +3. Finally it examines `$GIT_DIR/info/attributes`. This file + is used to override the in-tree settings. The first line is + a match, and `foo` is set, `bar` is reverted to unspecified + state, and `baz` is unset. + +As the result, the attributes assignment to `t/abc` becomes: + +---------------------------------------------------------------- +foo set to true +bar unspecified +baz set to false +merge set to string value "filfre" +frotz unspecified +---------------------------------------------------------------- + + + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt new file mode 100644 index 0000000000..6928724a05 --- /dev/null +++ b/Documentation/gitcli.txt @@ -0,0 +1,178 @@ +gitcli(7) +========= + +NAME +---- +gitcli - git command line interface and conventions + +SYNOPSIS +-------- +gitcli + + +DESCRIPTION +----------- + +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 +arguments. Here are the rules: + + * Revisions come first and then paths. + E.g. in `git diff v1.0 v2.0 arch/x86 include/asm-x86`, + `v1.0` and `v2.0` are revisions and `arch/x86` and `include/asm-x86` + 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 + 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 + between the HEAD commit and the work tree as a whole". You can say + `git diff HEAD \--` to ask for the latter. + + * 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 + 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. + +Here are the rules regarding the "flags" that you should follow when you are +scripting git: + + * 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 + 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. + + * 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. + + +ENHANCED OPTION PARSER +---------------------- +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. + + +Magic Options +~~~~~~~~~~~~~ +Commands which have the enhanced option parser activated all understand a +couple of magic command line options: + +-h:: + gives a pretty printed usage of the command. ++ +--------------------------------------------- +$ git describe -h +usage: git describe [options] <committish>* + + --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) +--------------------------------------------- + +--help-all:: + 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. + + +Negating options +~~~~~~~~~~~~~~~~ +Options with long option names can be negated by prefixing `--no-`. For +example, `git branch` has the option `--track` which is 'on' by default. You +can use `--no-track` to override that behaviour. The same goes for `--color` +and `--no-color`. + + +Aggregating short options +~~~~~~~~~~~~~~~~~~~~~~~~~ +Commands that support the enhanced option parser allow you to aggregate short +options. This means that you can for example use `git rm -rf` or +`git clean -fdx`. + + +Separating argument from the option +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +You can write the mandatory option parameter to an option as a separate +word on the command line. That means that all the following uses work: + +---------------------------- +$ git foo --long-opt=Arg +$ git foo --long-opt Arg +$ git foo -oArg +$ git foo -o Arg +---------------------------- + +However, this is *NOT* allowed for switches with an optional value, where the +'sticked' form must be used: +---------------------------- +$ git describe --abbrev HEAD # correct +$ git describe --abbrev=10 HEAD # correct +$ git describe --abbrev 10 HEAD # NOT WHAT YOU MEANT +---------------------------- + + +NOTES ON FREQUENTLY CONFUSED OPTIONS +------------------------------------ + +Many commands that can work on files in the working tree +and/or in the index can take `--cached` and/or `--index` +options. Sometimes people incorrectly think that, because +the index was originally called cache, these two are +synonyms. They are *not* -- these two options mean very +different things. + + * The `--cached` option is used to ask a command that + usually works on files in the working tree to *only* work + with the index. For example, `git grep`, when used + without a commit to specify from which commit to look for + strings in, usually works on files in the working tree, + but with the `--cached` option, it looks for strings in + the index. + + * The `--index` option is used to ask a command that + usually works on files in the working tree to *also* + affect the index. For example, `git stash apply` usually + merges changes recorded in a stash to the working tree, + but with the `--index` option, it also merges changes to + the index as well. + +`git apply` command can be used with `--cached` and +`--index` (but not at the same time). Usually the command +only affects the files in the working tree, but with +`--index`, it patches both the files and their index +entries, and with `--cached`, it modifies only the index +entries. + +See also http://marc.info/?l=git&m=116563135620359 and +http://marc.info/?l=git&m=119150393620273 for further +information. + +Documentation +------------- +Documentation by Pierre Habouzit and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt new file mode 100644 index 0000000000..f762dca440 --- /dev/null +++ b/Documentation/gitcore-tutorial.txt @@ -0,0 +1,1701 @@ +gitcore-tutorial(7) +=================== + +NAME +---- +gitcore-tutorial - A git core tutorial for developers + +SYNOPSIS +-------- +git * + +DESCRIPTION +----------- + +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]. + +However, an understanding of these low-level tools can be helpful if +you want to understand git's internals. + +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. + +[NOTE] +Deeper technical details are often marked as Notes, which you can +skip on your first reading. + + +Creating a git repository +------------------------- + +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. + +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': + +------------------------------------------------ +$ mkdir git-tutorial +$ cd git-tutorial +$ git init +------------------------------------------------ + +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 +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 +three entries, among other things: + + - a file called `HEAD`, that has `ref: refs/heads/master` in it. + This is similar to a symbolic link and points at + `refs/heads/master` relative to the `HEAD` file. ++ +Don't worry about the fact that the file that the `HEAD` link points to +doesn't even exist yet -- you haven't created the commit that will +start your `HEAD` development branch yet. + + - a subdirectory called `objects`, which will contain all the + objects of your project. You should never have any real reason to + look at the objects directly, but you might want to know that these + objects are what contains all the real 'data' in your repository. + + - a subdirectory called `refs`, which contains references to objects. + +In particular, the `refs` subdirectory will contain two other +subdirectories, named `heads` and `tags` respectively. They do +exactly what their names imply: they contain references to any number +of different 'heads' of development (aka 'branches'), and to any +'tags' that you have created to name specific versions in your +repository. + +One note: the special `master` head is the default branch, which is +why the `.git/HEAD` file was created points to it even if it +doesn't yet exist. Basically, the `HEAD` link is supposed to always +point to the branch you are working on right now, and you always +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 +valid, though. + +[NOTE] +An 'object' is identified by its 160-bit SHA1 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` +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 +references in these `refs` subdirectories when you actually start +populating your tree. + +[NOTE] +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 +empty, that's not very useful, so let's start populating it with data. + + +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 +get a feel for how this works: + +------------------------------------------------ +$ echo "Hello World" >hello +$ echo "Silly example" >example +------------------------------------------------ + +you have now created two files in your working tree (aka 'working directory'), +but to actually check in your hard work, you will have to go through two steps: + + - fill in the 'index' file (aka 'cache') with the information about your + working tree state. + + - commit that index file as an object. + +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. + +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. + +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 +database. If you did exactly the steps above, you should now be able to do + + +---------------- +$ ls .git/objects/??/* +---------------- + +and see two files: + +---------------- +.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238 +.git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962 +---------------- + +which correspond with the objects with names of `557db...` and +`f24c7...` respectively. + +If you want to, you can use 'git-cat-file' to look at those objects, but +you'll have to use the object name, not the filename of the object: + +---------------- +$ 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 +regular file), and you can see the contents with + +---------------- +$ git cat-file blob 557db03 +---------------- + +which will print out "Hello World". The object `557db03` is nothing +more than the contents of your file `hello`. + +[NOTE] +Don't confuse that object with the file `hello` itself. The +object is literally just those specific *contents* of the file, and +however much you later change the contents in file `hello`, the object +we just looked at will never change. Objects are immutable. + +[NOTE] +The second example demonstrates that you can +abbreviate the object name to only the first several +hexadecimal digits in most places. + +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 +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. + +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 +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 +'git-diff-files' command: + +------------ +$ git diff-files +------------ + +Oops. That wasn't very readable. It just spit out its own internal +version of a 'diff', but that internal version really just tells you +that it has noticed that "hello" has been modified, and that the old object +contents it had have been replaced with something else. + +To make it readable, we can tell 'git-diff-files' to output the +differences as a patch, using the `-p` flag: + +------------ +$ git diff-files -p +diff --git a/hello b/hello +index 557db03..263414f 100644 +--- a/hello ++++ b/hello +@@ -1 +1,2 @@ + Hello World ++It's a new day for git +---- + +i.e. the diff of the change we caused by adding another line to `hello`. + +In other words, 'git-diff-files' always shows us the difference between +what is recorded in the index, and what is currently in the working +tree. That's very useful. + +A common shorthand for `git diff-files -p` is to just write `git +diff`, which will do the same thing. + +------------ +$ git diff +diff --git a/hello b/hello +index 557db03..263414f 100644 +--- a/hello ++++ b/hello +@@ -1 +1,2 @@ + Hello World ++It's a new day for git +------------ + + +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 +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. + +Creating a tree object is trivial, and is done with 'git-write-tree'. +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: + +------------------------------------------------ +$ git write-tree +------------------------------------------------ + +and this will just output the name of the resulting tree, in this case +(if you have done exactly as I've described) it should be + +---------------- +8988da15d077d4829fc51d8544c097def6644dbb +---------------- + +which is another incomprehensible object name. Again, if you want to, +you can use `git cat-file -t 8988d\...` to see that this time the object +is not a "blob" object, but a "tree" object (you can also use +`git cat-file` to actually output the raw object contents, but you'll see +mainly a binary mess, so that's less interesting). + +However -- normally you'd never use 'git-write-tree' on its own, because +normally you always commit a tree into a commit object using the +'git-commit-tree' command. In fact, it's easier to not actually use +'git-write-tree' on its own at all, but to just pass its result in as an +argument to 'git-commit-tree'. + +'git-commit-tree' normally takes several arguments -- it wants to know +what the 'parent' of a commit was, but since this is the first commit +ever in this new repository, and it has no parents, we only need to pass in +the object name of the tree. However, 'git-commit-tree' also wants to get a +commit message on its standard input, and it will write out the resulting +object name for the commit to its standard output. + +And this is where we create the `.git/refs/heads/master` file +which is pointed at by `HEAD`. This file is supposed to contain +the reference to the top-of-tree of the master branch, and since +that's exactly what 'git-commit-tree' spits out, we can do this +all with a sequence of simple shell commands: + +------------------------------------------------ +$ tree=$(git write-tree) +$ commit=$(echo 'Initial commit' | git commit-tree $tree) +$ git update-ref HEAD $commit +------------------------------------------------ + +In this case this creates a totally new commit that is not related to +anything else. Normally you do this only *once* for a project ever, and +all later commits will be parented on top of an earlier commit. + +Again, normally you'd never actually do this by hand. There is a +helpful script called `git commit` that will do all of this for you. So +you could have just written `git commit` +instead, and it would have done the above magic scripting for you. + + +Making a change +--------------- + +Remember how we did the 'git-update-index' on file `hello` and then we +changed `hello` afterward, and could compare the new state of `hello` with the +state we saved in the index file? + +Further, remember how I said that 'git-write-tree' writes the contents +of the *index* file to the tree, and thus what we just committed was in +fact the *original* contents of the file `hello`, not the new ones. We did +that on purpose, to show the difference between the index state, and the +state in the working tree, and how they don't have to match, even +when we commit things. + +As before, if we do `git diff-files -p` in our git-tutorial project, +we'll still see the same difference we saw last time: the index file +hasn't changed by the act of committing anything. However, now that we +have committed something, we can also learn to use a new command: +'git-diff-index'. + +Unlike 'git-diff-files', which showed the difference between the index +file and the working tree, 'git-diff-index' shows the differences +between a committed *tree* and either the index file or the working +tree. In other words, 'git-diff-index' wants a tree to be diffed +against, and before we did the commit, we couldn't do that, because we +didn't have anything to diff against. + +But now we can do + +---------------- +$ git diff-index -p HEAD +---------------- + +(where `-p` has the same meaning as it did in 'git-diff-files'), and it +will show us the same difference, but for a totally different reason. +Now we're comparing the working tree not against the index file, +but against the tree we just wrote. It just so happens that those two +are obviously the same, so we get the same result. + +Again, because this is a common operation, you can also just shorthand +it with + +---------------- +$ 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 +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 +an empty set of differences, and that's exactly what it does. + +[NOTE] +================ +'git-diff-index' really always uses the index for its +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` +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 +never knows (or cares) about files that it is not told about +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. +================ + +However, our next step is to commit the *change* we did, and again, to +understand what's going on, keep in mind the difference between "working +tree contents", "index file" and "committed tree". We have changes +in the working tree that we want to commit, and we always have to +work through the index file, so the first thing we need to do is to +update the index cache: + +------------------------------------------------ +$ git update-index hello +------------------------------------------------ + +(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-\*' versions here. After +we've updated `hello` in the index, `git diff-files -p` now shows no +differences, but `git diff-index -p HEAD` still *does* show that the +current state is different from the state we committed. In fact, now +'git-diff-index' shows the same difference whether we use the `--cached` +flag or not, since now the index is coherent with the working tree. + +Now, since we've updated `hello` in the index, we can commit the new +version. We could do it by writing the tree by hand again, and +committing the tree (this time we'd have to use the `-p HEAD` flag to +tell commit that the HEAD was the *parent* of the new commit, and that +this wasn't an initial commit any more), but you've done that once +already, so let's just use the helpful script this time: + +------------------------------------------------ +$ git commit +------------------------------------------------ + +which starts an editor for you to write the commit message and tells you +a bit about what you have done. + +Write whatever message you want, and all the lines that start with '#' +will be pruned out, and the rest will be used as the commit message for +the change. If you decide you don't want to commit anything after all at +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 +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 +commit itself ('git-commit'). + + +Inspecting Changes +------------------ + +While creating changes is useful, it's even more useful if you can tell +later what changed. The most useful command for this is another of the +'diff' family, namely 'git-diff-tree'. + +'git-diff-tree' can be given two arbitrary trees, and it will tell you the +differences between them. Perhaps even more commonly, though, you can +give it just a single commit object, and it will figure out the parent +of that commit itself, and show the difference directly. Thus, to get +the same diff that we've already seen several times, we can now do + +---------------- +$ git diff-tree -p HEAD +---------------- + +(again, `-p` means to show the difference as a human-readable patch), +and it will show what the last commit (in `HEAD`) actually changed. + +[NOTE] +============ +Here is an ASCII art by Jon Loeliger that illustrates how +various diff-\* commands compare things. + + diff-tree + +----+ + | | + | | + V V + +-----------+ + | Object DB | + | Backing | + | Store | + +-----------+ + ^ ^ + | | + | | diff-index --cached + | | + diff-index | V + | +-----------+ + | | Index | + | | "cache" | + | +-----------+ + | ^ + | | + | | diff-files + | | + V V + +-----------+ + | Working | + | Directory | + +-----------+ +============ + +More interestingly, you can also give 'git-diff-tree' the `--pretty` flag, +which tells it to also show the commit message and author and date of the +commit, and you can tell it to show a whole series of diffs. +Alternatively, you can tell it to be "silent", and not show the diffs at +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'. + + +Tagging a version +----------------- + +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`. +So the simplest form of tag involves nothing more than + +------------------------------------------------ +$ git tag my-first-tag +------------------------------------------------ + +which just writes the current `HEAD` into the `.git/refs/tags/my-first-tag` +file, after which point you can then use this symbolic name for that +particular state. You can, for example, do + +---------------- +$ git diff my-first-tag +---------------- + +to diff your current state against that tag which at this point will +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 +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 +that tag. You create these annotated tags with either the `-a` or +`-s` flag to 'git-tag': + +---------------- +$ git tag -s <tagname> +---------------- + +which will sign the current `HEAD` (but you can also give it another +argument that specifies the thing to tag, e.g., you could have tagged the +current `mybranch` point by using `git tag <tagname> mybranch`). + +You normally only do signed tags for major releases or things +like that, while the light-weight tags are useful for any marking you +want to do -- any time you decide that you want to remember a certain +point, just create a private tag for it, and you have a nice symbolic +name for the state at that point. + + +Copying repositories +-------------------- + +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` +subdirectory. There is nothing else. What you see is what you got. + +[NOTE] +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 +the working tree that it describes" may not be technically 100% +accurate, but it's a good model for all normal use. + +This has two implications: + + - if you grow bored with the tutorial repository you created (or you've + made a mistake and want to start all over), you can just do simple ++ +---------------- +$ 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 + 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 +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 ++ +---------------- +$ 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 +'scp', 'rsync' or 'wget'. + +When copying a remote repository, you'll want to at a minimum update the +index cache when you do this, and especially with other peoples' +repositories you often want to make sure that the index cache is in some +known state (you don't know *what* they've done and not yet checked in), +so usually you'll precede the 'git-update-index' with a + +---------------- +$ git read-tree --reset HEAD +$ git update-index --refresh +---------------- + +which will force a total index re-build from the tree pointed to by `HEAD`. +It resets the index contents to `HEAD`, and then the 'git-update-index' +makes sure to match up all index entries with the checked-out files. +If the original repository had uncommitted changes in its +working tree, `git update-index --refresh` notices them and +tells you they need to be updated. + +The above can also be written as simply + +---------------- +$ git reset +---------------- + +and in fact a lot of the common git command combinations can be scripted +with the `git xyz` interfaces. You can learn things by just looking +at what the various git scripts do. For example, `git reset` 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. + +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 +repository. + +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 + +---------------- +$ mkdir my-git +$ cd my-git +$ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git +---------------- + +followed by + +---------------- +$ 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 +actually have any of the working tree files to work on. To get +those, you'd check them out with + +---------------- +$ git checkout-index -u -a +---------------- + +where the `-u` flag means that you want the checkout to keep the index +up-to-date (so that you don't have to refresh it afterward), and the +`-a` flag means "check out all files" (if you have a stale copy or an +older version of a checked out tree you may also need to add the `-f` +flag first, to tell 'git-checkout-index' to *force* overwriting of any old +files). + +Again, this can all be simplified with + +---------------- +$ git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git +$ cd my-git +$ git checkout +---------------- + +which will end up doing all of the above for you. + +You have now successfully copied somebody else's (mine) remote +repository, and checked it out. + + +Creating a new branch +--------------------- + +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 +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, +and nothing enforces it. + +To show that as an example, let's go back to the git-tutorial repository we +used earlier, and create a branch in it. You do that by simply just +saying that you want to check out a new branch: + +------------ +$ git checkout -b mybranch +------------ + +will create a new branch based at the current `HEAD` position, and switch +to it. + +[NOTE] +================================================ +If you make the decision to start your new branch at some +other point in the history than the current `HEAD`, you can do so by +just telling 'git-checkout' what the base of the checkout would be. +In other words, if you have an earlier tag or branch, you'd just do + +------------ +$ git checkout -b mybranch earlier-commit +------------ + +and it would create the new branch `mybranch` at the earlier commit, +and check out the state at that time. +================================================ + +You can always just jump back to your original `master` branch by doing + +------------ +$ git checkout master +------------ + +(or any other branch-name, for that matter) and if you forget which +branch you happen to be on, a simple + +------------ +$ cat .git/HEAD +------------ + +will tell you where it's pointing. To get the list of branches +you have, you can say + +------------ +$ git branch +------------ + +which used to be nothing more than a simple script around `ls .git/refs/heads`. +There will be an asterisk in front of the branch you are currently on. + +Sometimes you may wish to create a new branch _without_ actually +checking it out and switching to it. If so, just use the command + +------------ +$ git branch <branchname> [startingpoint] +------------ + +which will simply _create_ the branch, but will not do anything further. +You can then later -- once you decide that you want to actually develop +on that branch -- switch to that branch with a regular 'git-checkout' +with the branchname as the argument. + + +Merging two branches +-------------------- + +One of the ideas of having a branch is that you do some (possibly +experimental) work in it, and eventually merge it back to the main +branch. So assuming you created the above `mybranch` that started out +being the same as the original `master` branch, let's make sure we're in +that branch, and do some work there. + +------------------------------------------------ +$ git checkout mybranch +$ echo "Work, work, work" >>hello +$ 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 +the index file so far when making the commit). The `-m` flag is to give the +commit log message from the command line. + +Now, to make it a bit more interesting, let's assume that somebody else +does some work in the original branch, and simulate that by going back +to the master branch, and editing the same file differently there: + +------------ +$ git checkout master +------------ + +Here, take a moment to look at the contents of `hello`, and notice how they +don't contain the work we just did in `mybranch` -- because that work +hasn't happened in the `master` branch at all. Then do + +------------ +$ echo "Play, play, play" >>hello +$ echo "Lots of fun" >>example +$ git commit -m "Some fun." -i hello example +------------ + +since the master branch is obviously in a much better mood. + +Now, you've got two branches, and you decide that you want to merge the +work done. Before we do that, let's introduce a cool graphical tool that +helps you view what's going on: + +---------------- +$ gitk --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. + +Anyway, let's exit 'gitk' (`^Q` or the File menu), and decide that we want +to merge the work we did on the `mybranch` branch into the `master` +branch (which is currently our `HEAD` too). To do that, there's a nice +script called 'git-merge', which wants to know which branches you want +to resolve and what the merge is all about: + +------------ +$ git merge -m "Merge work in mybranch" mybranch +------------ + +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 +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: + +---------------- + Auto-merging hello + CONFLICT (content): Merge conflict in hello + Automatic merge failed; fix conflicts and then commit the result. +---------------- + +It tells you that it did an "Automatic merge", which +failed due to conflicts in `hello`. + +Not to worry. It left the (trivial) conflict in `hello` in the same form you +should already be well used to if you've ever used CVS, so let's just +open `hello` in our editor (whatever that may be), and fix it up somehow. +I'd suggest just making it so that `hello` contains all four lines: + +------------ +Hello World +It's a new day for git +Play, play, play +Work, work, work +------------ + +and once you're happy with your manual merge, just do a + +------------ +$ git commit -i hello +------------ + +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 +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 +have to do _that_ merge again. + +Another useful tool, especially if you do not always work in X-Window +environment, is `git show-branch`. + +------------------------------------------------ +$ git show-branch --topo-order --more=1 master mybranch +* [master] Merge work in mybranch + ! [mybranch] Some work. +-- +- [master] Merge work in mybranch +*+ [mybranch] Some work. +* [master^] Some fun. +------------------------------------------------ + +The first two lines indicate that it is showing the two branches +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 `\*` 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 (`*` +shows an ordinary commit on the current branch, `-` is a merge commit), which +means they are now part of the `master` branch. Only the "Some +work" commit has the plus `+` character in the second column, +because `mybranch` has not been merged to incorporate these +commits from the master branch. The string inside brackets +before the commit log message is a short name you can use to +name the commit. In the above example, 'master' and 'mybranch' +are branch heads. 'master^' is the first parent of 'master' +branch head. Please see linkgit:git-rev-parse[1] if you want to +see more complex cases. + +[NOTE] +Without the '--more=1' option, 'git-show-branch' would not output the +'[master^]' commit, as '[mybranch]' commit is a common ancestor of +both 'master' and 'mybranch' tips. Please see linkgit:git-show-branch[1] +for details. + +[NOTE] +If there were more commits on the 'master' branch after the merge, the +merge commit itself would not be shown by 'git-show-branch' by +default. You would need to provide '--sparse' option to make the +merge commit visible in this case. + +Now, let's pretend you are the one who did all the work in +`mybranch`, and the fruit of your hard work has finally been merged +to the `master` branch. Let's go back to `mybranch`, and run +'git-merge' to get the "upstream changes" back to your branch. + +------------ +$ git checkout mybranch +$ git merge -m "Merge upstream changes." master +------------ + +This outputs something like this (the actual commit object names +would be different) + +---------------- +Updating from ae3a2da... to a80b4aa.... +Fast-forward (no commit created; -m option ignored) + example | 1 + + hello | 1 + + 2 files changed, 2 insertions(+), 0 deletions(-) +---------------- + +Because your branch did not contain anything more than what had +already been merged into the `master` branch, the merge operation did +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 +looks like, or run 'show-branch', which tells you this. + +------------------------------------------------ +$ git show-branch master mybranch +! [master] Merge work in mybranch + * [mybranch] Merge work in mybranch +-- +-- [master] Merge work in mybranch +------------------------------------------------ + + +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 +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" +followed by a 'git-merge'. + +Fetching from a remote repository is done by, unsurprisingly, +'git-fetch': + +---------------- +$ git fetch <remote-repository> +---------------- + +One of the following transports can be used to name the +repository to download from: + +Rsync:: + `rsync://remote.machine/path/to/repo.git/` ++ +Rsync transport is usable for both uploading and downloading, +but is completely unaware of what git does, and can produce +unexpected results when you download from the public repository +while the repository owner is uploading into it via `rsync` +transport. Most notably, it could update the files under +`refs/` which holds the object name of the topmost commits +before uploading the files in `objects/` -- the downloader would +obtain head commit object name while that object itself is still +not available in the repository. For this reason, it is +considered deprecated. + +SSH:: + `remote.machine:/path/to/repo.git/` or ++ +`ssh://remote.machine/path/to/repo.git/` ++ +This transport can be used for both uploading and downloading, +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. + +Local directory:: + `/path/to/repo.git/` ++ +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://remote.machine/path/to/repo.git/` ++ +This transport was designed for anonymous downloading. Like SSH +transport, it finds out the set of objects the downstream side +lacks and transfers (close to) minimum set of objects. + +HTTP(S):: + `http://remote.machine/path/to/repo.git/` ++ +Downloader from http and https URL +first obtains the topmost commit object name from the remote site +by looking at the specified refname under `repo.git/refs/` directory, +and then tries to obtain the +commit object by downloading from `repo.git/objects/xx/xxx\...` +using the object name of that commit object. Then it reads the +commit object to find out its parent commits and the associate +tree object; it repeats this process until it gets all the +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 +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. + +Once you fetch from the remote repository, you `merge` that +with your current branch. + +However -- it's such a common thing to `fetch` and then +immediately `merge`, that it's called `git pull`, and you can +simply do + +---------------- +$ git pull <remote-repository> +---------------- + +and optionally give a branch-name for the remote end as a second +argument. + +[NOTE] +You could do without using any branches at all, by +keeping as many local repositories as you would like to have +branches, and merging between them with 'git-pull', just like +you merge between branches. The advantage of this approach is +that it lets you keep a set of files for each `branch` checked +out and you may find it easier to switch back and forth if you +juggle multiple lines of development simultaneously. Of +course, you will pay the price of more disk usage to hold +multiple working trees, but disk space is cheap these days. + +It is likely that you will be pulling from the same remote +repository from time to time. As a short hand, you can store +the remote repository URL in the local repository's config file +like this: + +------------------------------------------------ +$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/ +------------------------------------------------ + +and use the "linus" keyword with 'git-pull' instead of the full URL. + +Examples. + +. `git pull linus` +. `git pull linus tag v0.99.1` + +the above are equivalent to: + +. `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD` +. `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1` + + +How does the merge work? +------------------------ + +We said this tutorial shows what plumbing does to help you cope +with the porcelain that isn't flushing, but we so far did not +talk about how the merge really works. If you are following +this tutorial the first time, I'd suggest to skip to "Publishing +your work" section and come back here later. + +OK, still with me? To give us an example to look at, let's go +back to the earlier repository with "hello" and "example" file, +and bring ourselves back to the pre-merge state: + +------------ +$ git show-branch --more=2 master mybranch +! [master] Merge work in mybranch + * [mybranch] Merge work in mybranch +-- +-- [master] Merge work in mybranch ++* [master^2] Some work. ++* [master^] Some fun. +------------ + +Remember, before running 'git-merge', our `master` head was at +"Some fun." commit, while our `mybranch` head was at "Some +work." commit. + +------------ +$ git checkout mybranch +$ git reset --hard master^2 +$ git checkout master +$ git reset --hard master^ +------------ + +After rewinding, the commit structure should look like this: + +------------ +$ git show-branch +* [master] Some fun. + ! [mybranch] Some work. +-- +* [master] Some fun. + + [mybranch] Some work. +*+ [master^] Initial commit +------------ + +Now we are ready to experiment with the merge by hand. + +`git merge` command, when merging two branches, uses 3-way merge +algorithm. First, it finds the common ancestor between them. +The command it uses is 'git-merge-base': + +------------ +$ mb=$(git merge-base HEAD mybranch) +------------ + +The command writes the commit object name of the common ancestor +to the standard output, so we captured its output to a variable, +because we will be using it in the next step. By the way, the common +ancestor commit is the "Initial commit" commit in this case. You can +tell it by: + +------------ +$ git name-rev --name-only --tags $mb +my-first-tag +------------ + +After finding out a common ancestor commit, the second step is +this: + +------------ +$ git read-tree -m -u $mb HEAD mybranch +------------ + +This is the same 'git-read-tree' command we have already seen, +but it takes three trees, unlike previous examples. This reads +the contents of each tree into different 'stage' in the index +file (the first tree goes to stage 1, the second 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 +stage 3, whichever is different from stage 1 (i.e. only one side +changed from the common ancestor). + +After 'collapsing' operation, paths that are different in three +trees are left in non-zero stages. At this point, you can +inspect the index file with this command: + +------------ +$ git ls-files --stage +100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example +100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello +100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello +100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello +------------ + +In our example of only two files, we did not have unchanged +files so only 'example' resulted in collapsing. But in real-life +large projects, when only a small number of files change in one commit, +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: + +------------ +$ git ls-files --unmerged +100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello +100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello +100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello +------------ + +The next step of merging is to merge these three versions of the +file, using 3-way merge. This is done by giving +'git-merge-one-file' command as one of the arguments to +'git-merge-index' command: + +------------ +$ git merge-index git-merge-one-file hello +Auto-merging hello +ERROR: Merge conflict in hello +fatal: merge program failed +------------ + +'git-merge-one-file' script is called with parameters to +describe those three versions, and is responsible to leave the +merge results in the working tree. +It is a fairly straightforward shell script, and +eventually calls 'merge' program from RCS suite to perform a +file-level 3-way merge. In this case, 'merge' detects +conflicts, and the merge result with conflict marks is left in +the working tree.. This can be seen if you run `ls-files +--stage` again at this point: + +------------ +$ git ls-files --stage +100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example +100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello +100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello +100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello +------------ + +This is the state of the index file and the working file after +'git-merge' returns control back to you, leaving the conflicting +merge for you to resolve. Notice that the path `hello` is still +unmerged, and what you see with 'git-diff' at this point is +differences since stage 2 (i.e. your version). + + +Publishing your work +-------------------- + +So, we can use somebody else's work from a remote repository, but +how can *you* prepare a repository to let other people pull from +it? + +You do your real work in your working tree that has your +primary repository hanging under it as its `.git` subdirectory. +You *could* make that repository accessible remotely and ask +people to pull from it, but in practice that is not the way +things are usually done. A recommended way is to have a public +repository, make it reachable by other people, and when the +changes you made in your primary working tree are in good shape, +update the public repository from it. This is often called +'pushing'. + +[NOTE] +This public repository could further be mirrored, and that is +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 +the remote machine. You need to have an SSH account there to +run a single command, 'git-receive-pack'. + +First, you need to create an empty repository on the remote +machine that will house your public repository. This empty +repository will be populated and be kept up-to-date by pushing +into it later. Obviously, this repository creation needs to be +done only once. + +[NOTE] +'git-push' uses a pair of commands, +'git-send-pack' on your local machine, and 'git-receive-pack' +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 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 +an empty directory: + +------------ +$ mkdir my-git.git +------------ + +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: + +------------ +$ GIT_DIR=my-git.git git init +------------ + +Make sure this directory is available for others you want your +changes to be pulled via the transport of your choice. Also +you need to make sure that you have the 'git-receive-pack' +program on the `$PATH`. + +[NOTE] +Many installations of sshd do not invoke your shell as the login +shell when you directly run programs; what this means is that if +your login shell is 'bash', only `.bashrc` is read and not +`.bash_profile`. As a workaround, make sure `.bashrc` sets up +`$PATH` so that you can run 'git-receive-pack' program. + +[NOTE] +If you plan to publish this repository to be accessed over http, +you should do `mv my-git.git/hooks/post-update.sample +my-git.git/hooks/post-update` at this point. +This makes sure that every time you push into this +repository, `git update-server-info` is run. + +Your "public repository" is now ready to accept your changes. +Come back to the machine you have your private repository. From +there, run this command: + +------------ +$ git push <public-host>:/path/to/my-git.git master +------------ + +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 +repository. Kernel.org mirror network takes care of the +propagation to other publicly visible machines: + +------------ +$ git push master.kernel.org:/pub/scm/git/git.git/ +------------ + + +Packing your repository +----------------------- + +Earlier, we saw that one file under `.git/objects/??/` directory +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 +immutable once they are created, there is a way to optimize the +storage by "packing them together". The command + +------------ +$ git repack +------------ + +will do it for you. If you followed the tutorial examples, you +would have accumulated about 17 objects in `.git/objects/??/` +directories by now. 'git-repack' tells you how many objects it +packed, and stores the packed file in `.git/objects/pack` +directory. + +[NOTE] +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 +them together. The former holds all the data from the objects +in the pack, and the latter holds the index for random +access. + +If you are paranoid, running 'git-verify-pack' command would +detect if you have a corrupt pack, but do not worry too much. +Our programs are always perfect ;-). + +Once you have packed objects, you do not need to leave the +unpacked objects that are contained in the pack file anymore. + +------------ +$ git prune-packed +------------ + +would remove them for you. + +You can try running `find .git/objects -type f` before and after +you run `git prune-packed` if you are curious. Also `git +count-objects` would tell you how many unpacked objects are in +your repository and how much space they are consuming. + +[NOTE] +`git pull` is slightly cumbersome for HTTP transport, as a +packed repository may contain relatively few objects in a +relatively large pack. If you expect many HTTP pulls from your +public repository you might want to repack & prune often, or +never. + +If you run `git repack` again at this point, it will say +"Nothing new to pack.". Once you continue your development and +accumulate the changes, running `git repack` again will create a +new pack, that contains objects created since you packed your +repository the last time. We recommend that you pack your project +soon after the initial import (unless you are starting your +project from scratch), and then run `git repack` every once in a +while, depending on how active your project is. + +When a repository is synchronized via `git push` and `git pull` +objects packed in the source repository are usually stored +unpacked in the destination, unless rsync transport is used. +While this allows you to use different packing strategies on +both ends, it also means you may need to repack both +repositories every once in a while. + + +Working with Others +------------------- + +Although git is a truly distributed system, it is often +convenient to organize your project with an informal hierarchy +of developers. Linux kernel development is run this way. There +is a nice illustration (page 17, "Merges to Mainline") in +link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation]. + +It should be stressed that this hierarchy is purely *informal*. +There is nothing fundamental in git that enforces the "chain of +patch flow" this hierarchy implies. You do not have to pull +from only one remote repository. + +A recommended workflow for a "project lead" goes like this: + +1. Prepare your primary repository on your local machine. Your + work is done there. + +2. Prepare a public repository accessible to others. ++ +If other people are pulling from your repository over dumb +transport protocols (HTTP), you need to keep this repository +'dumb transport friendly'. After `git init`, +`$GIT_DIR/hooks/post-update.sample` copied from the standard templates +would contain a call to 'git-update-server-info' +but you need to manually enable the hook with +`mv post-update.sample post-update`. This makes sure +'git-update-server-info' keeps the necessary files up-to-date. + +3. Push into the public repository from your primary + repository. + +4. 'git-repack' the public repository. This establishes a big + pack that contains the initial set of objects as the + baseline, and possibly 'git-prune' if the transport + used for pulling from your repository supports packed + repositories. + +5. Keep working in your primary repository. Your changes + include modifications of your own, patches you receive via + e-mails, and merges resulting from pulling the "public" + repositories of your "subsystem maintainers". ++ +You can repack this private repository whenever you feel like. + +6. Push your changes to the public repository, and announce it + to the public. + +7. Every once in a while, 'git-repack' the public repository. + Go back to step 5. and continue working. + + +A recommended work cycle for a "subsystem maintainer" who works +on that project and has an own "public repository" goes like this: + +1. Prepare your work repository, by 'git-clone' the public + repository of the "project lead". The URL used for the + initial cloning is stored in the remote.origin.url + configuration variable. + +2. Prepare a public repository accessible to others, just like + the "project lead" person does. + +3. Copy over the packed files from "project lead" public + repository to your public repository, unless the "project + lead" repository lives on the same machine as yours. In the + latter case, you can use `objects/info/alternates` file to + point at the repository you are borrowing from. + +4. Push into the public repository from your primary + repository. Run 'git-repack', and possibly 'git-prune' if the + transport used for pulling from your repository supports + packed repositories. + +5. Keep working in your primary repository. Your changes + include modifications of your own, patches you receive via + e-mails, and merges resulting from pulling the "public" + repositories of your "project lead" and possibly your + "sub-subsystem maintainers". ++ +You can repack this private repository whenever you feel +like. + +6. Push your changes to your public repository, and ask your + "project lead" and possibly your "sub-subsystem + maintainers" to pull from it. + +7. Every once in a while, 'git-repack' the public repository. + Go back to step 5. and continue working. + + +A recommended work cycle for an "individual developer" who does +not have a "public" repository is somewhat different. It goes +like this: + +1. Prepare your work repository, by 'git-clone' the public + repository of the "project lead" (or a "subsystem + maintainer", if you work on a subsystem). The URL used for + the initial cloning is stored in the remote.origin.url + configuration variable. + +2. Do your work in your repository on 'master' branch. + +3. Run `git fetch origin` from the public repository of your + upstream every once in a while. This does only the first + half of `git pull` but does not merge. The head of the + public repository is stored in `.git/refs/remotes/origin/master`. + +4. Use `git cherry origin` to see which ones of your patches + were accepted, and/or use `git rebase origin` to port your + unmerged changes forward to the updated upstream. + +5. Use `git format-patch origin` to prepare patches for e-mail + submission to your upstream and send it out. Go back to + step 2. and continue. + + +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 +cooperation you are probably more familiar with as well. + +See linkgit:gitcvs-migration[7] for the details. + +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. + +We have already seen how branches work previously, +with "fun and work" example using two branches. The idea is the +same if there are more than two branches. Let's say you started +out from "master" head, and have some new code in the "master" +branch, and two independent fixes in the "commit-fix" and +"diff-fix" branches: + +------------ +$ git show-branch +! [commit-fix] Fix commit message normalization. + ! [diff-fix] Fix rename detection. + * [master] Release candidate #1 +--- + + [diff-fix] Fix rename detection. + + [diff-fix~1] Better common substring algorithm. ++ [commit-fix] Fix commit message normalization. + * [master] Release candidate #1 +++* [diff-fix~2] Pretty-print messages. +------------ + +Both fixes are tested well, and at this point, you want to merge +in both of them. You could merge in 'diff-fix' first and then +'commit-fix' next, like this: + +------------ +$ git merge -m "Merge fix in diff-fix" diff-fix +$ git merge -m "Merge fix in commit-fix" commit-fix +------------ + +Which would result in: + +------------ +$ git show-branch +! [commit-fix] Fix commit message normalization. + ! [diff-fix] Fix rename detection. + * [master] Merge fix in commit-fix +--- + - [master] Merge fix in commit-fix ++ * [commit-fix] Fix commit message normalization. + - [master~1] Merge fix in diff-fix + +* [diff-fix] Fix rename detection. + +* [diff-fix~1] Better common substring algorithm. + * [master~2] Release candidate #1 +++* [master~3] Pretty-print messages. +------------ + +However, there is no particular reason to merge in one branch +first and the other next, when what you have are a set of truly +independent changes (if the order mattered, then they are not +independent by definition). You could instead merge those two +branches into the current branch at once. First let's undo what +we just did and start over. We would want to get the master +branch before these two merges by resetting it to 'master~2': + +------------ +$ git reset --hard master~2 +------------ + +You can make sure `git show-branch` matches the state before +those two 'git-merge' you just did. Then, instead of running +two 'git-merge' commands in a row, you would merge these two +branch heads (this is known as 'making an Octopus'): + +------------ +$ git merge commit-fix diff-fix +$ git show-branch +! [commit-fix] Fix commit message normalization. + ! [diff-fix] Fix rename detection. + * [master] Octopus merge of branches 'diff-fix' and 'commit-fix' +--- + - [master] Octopus merge of branches 'diff-fix' and 'commit-fix' ++ * [commit-fix] Fix commit message normalization. + +* [diff-fix] Fix rename detection. + +* [diff-fix~1] Better common substring algorithm. + * [master~1] Release candidate #1 +++* [master~2] Pretty-print messages. +------------ + +Note that you should not do Octopus because you can. An octopus +is a valid thing to do and often makes it easier to view the +commit history if you are merging more than two independent +changes at the same time. However, if you have merge conflicts +with any of the branches you are merging in and need to hand +resolve, that is an indication that the development happened in +those branches were not independent after all, and you should +merge two at a time, documenting how you resolved the conflicts, +and the reason why you preferred changes made in one side over +the other. Otherwise it would make the project history harder +to follow, not easier. + +SEE ALSO +-------- +linkgit:gittutorial[7], +linkgit:gittutorial-2[7], +linkgit:gitcvs-migration[7], +linkgit:git-help[1], +link:everyday.html[Everyday git], +link:user-manual.html[The Git User's Manual] + +GIT +--- +Part of the linkgit:git[1] suite. diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt new file mode 100644 index 0000000000..0e49c1c037 --- /dev/null +++ b/Documentation/gitcvs-migration.txt @@ -0,0 +1,201 @@ +gitcvs-migration(7) +=================== + +NAME +---- +gitcvs-migration - git for CVS users + +SYNOPSIS +-------- +git cvsimport * + +DESCRIPTION +----------- + +Git differs from CVS in that every working tree contains a repository with +a full copy of the project history, and no repository is inherently more +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 +linkgit:gittutorial[7] and +linkgit:gitglossary[7] should be sufficient. + +Developing against a shared repository +-------------------------------------- + +Suppose a shared repository is set up in /pub/repo.git on the host +foo.com. Then as an individual committer you can clone the shared +repository over ssh with: + +------------------------------------------------ +$ git clone foo.com:/pub/repo.git/ my-project +$ cd my-project +------------------------------------------------ + +and hack away. The equivalent of 'cvs update' is + +------------------------------------------------ +$ git pull origin +------------------------------------------------ + +which merges in any work that others might have done since the clone +operation. If there are uncommitted changes in your working tree, commit +them first before running git pull. + +[NOTE] +================================ +The 'pull' command knows where to get updates from because of certain +configuration variables that were set by the first 'git-clone' +command; see `git config -l` and the linkgit:git-config[1] man +page for details. +================================ + +You can update the shared repository with your changes by first committing +your changes, and then using the 'git-push' command: + +------------------------------------------------ +$ git push origin master +------------------------------------------------ + +to "push" those commits to the shared repository. If someone else has +updated the repository more recently, 'git-push', like 'cvs commit', will +complain, in which case you must pull any changes before attempting the +push again. + +In the 'git-push' command above we specify the name of the remote branch +to update (`master`). If we leave that out, 'git-push' tries to update +any branches in the remote repository that have the same name as a branch +in the local repository. So the last 'push' can be done with either of: + +------------ +$ git push origin +$ git push foo.com:/pub/project.git/ +------------ + +as long as the shared repository does not have any branches +other than `master`. + +Setting Up a Shared Repository +------------------------------ + +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). + +Assume your existing repo is at /home/alice/myproject. Create a new "bare" +repository (a repository without a working tree) and fetch your project into +it: + +------------------------------------------------ +$ mkdir /pub/my-repo.git +$ cd /pub/my-repo.git +$ git --bare init --shared +$ git --bare fetch /home/alice/myproject master:master +------------------------------------------------ + +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]. + +Put all the committers in the same group, and make the repository +writable by that group: + +------------------------------------------------ +$ chgrp -R $group /pub/my-repo.git +------------------------------------------------ + +Make sure committers have a umask of at most 027, so that the directories +they create are writable and searchable by other group members. + +Importing a CVS archive +----------------------- + +First, install version 2.1 or higher of cvsps from +link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make +sure it is in your path. Then cd to a checked out CVS working directory +of the project you are interested in and run linkgit:git-cvsimport[1]: + +------------------------------------------- +$ git cvsimport -C <destination> <module> +------------------------------------------- + +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 +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 +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. + +The import is incremental, so if you call it again next month it will +fetch any CVS updates that have been made in the meantime. For this to +work, you must not modify the imported branches; instead, create new +branches for your own changes, and merge in the imported branches as +necessary. + +If you want a shared repository, you will need to make a bare clone +of the imported directory, as described above. Then treat the imported +directory as another development clone for purposes of merging +incremental imports. + +Advanced Shared Repository Management +------------------------------------- + +Git allows you to specify scripts called "hooks" to be run at certain +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 +update hooks]. + +Providing CVS Access to a git Repository +---------------------------------------- + +It is also possible to provide true CVS access to a git repository, so +that developers can still use CVS; see linkgit:git-cvsserver[1] for +details. + +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, +and you may want to first consider whether one of them might be a better +fit for your project. + +For example, you can choose a single person to maintain the project's +primary public repository. Other developers then clone this repository +and each work in their own clone. When they have a series of changes that +they're happy with, they ask the maintainer to pull from the branch +containing the changes. The maintainer reviews their changes and pulls +them into the primary repository, which other developers pull from as +necessary to stay coordinated. The Linux kernel and other projects use +variants of this model. + +With a small group, developers may just pull changes from each other's +repositories without the need for a central maintainer. + +SEE ALSO +-------- +linkgit:gittutorial[7], +linkgit:gittutorial-2[7], +linkgit:gitcore-tutorial[7], +linkgit:gitglossary[7], +link:everyday.html[Everyday Git], +link:user-manual.html[The Git User's Manual] + +GIT +--- +Part of the linkgit:git[1] suite. diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt new file mode 100644 index 0000000000..e8041bc08f --- /dev/null +++ b/Documentation/gitdiffcore.txt @@ -0,0 +1,281 @@ +gitdiffcore(7) +============== + +NAME +---- +gitdiffcore - Tweaking diff output (June 2005) + +SYNOPSIS +-------- +'git diff' * + +DESCRIPTION +----------- + +The diff commands 'git-diff-index', 'git-diff-files', and 'git-diff-tree' +can be told to manipulate differences they find in +unconventional ways before showing 'diff' output. The manipulation +is collectively called "diffcore transformation". This short note +describes what they are and how to use them to produce 'diff' output +that is easier to understand than the conventional kind. + + +The chain of operation +---------------------- + +The 'git-diff-{asterisk}' family works by first comparing two sets of +files: + + - 'git-diff-index' compares contents of a "tree" object and the + working directory (when '\--cached' flag is not used) or a + "tree" object and the index file (when '\--cached' flag is + used); + + - 'git-diff-files' compares contents of the index file and the + working directory; + + - 'git-diff-tree' compares contents of two "tree" objects; + +In all of these cases, the commands themselves first optionally limit +the two sets of files by any pathspecs given on their command-lines, +and compare corresponding paths in the two resulting sets of files. + +The pathspecs are used to limit the world diff operates in. They remove +the filepairs outside the specified sets of pathnames. E.g. If the +input set of filepairs included: + +------------------------------------------------ +:100644 100644 bcd1234... 0123456... M junkfile +------------------------------------------------ + +but the command invocation was `git diff-files myfile`, then the +junkfile entry would be removed from the list because only "myfile" +is under consideration. + +The result of comparison is passed from these commands to what is +internally called "diffcore", in a format similar to what is output +when the -p option is not used. E.g. + +------------------------------------------------ +in-place edit :100644 100644 bcd1234... 0123456... M file0 +create :000000 100644 0000000... 1234567... A file4 +delete :100644 000000 1234567... 0000000... D file5 +unmerged :000000 000000 0000000... 0000000... U file6 +------------------------------------------------ + +The diffcore mechanism is fed a list of such comparison results +(each of which is called "filepair", although at this point each +of them talks about a single file), and transforms such a list +into another list. There are currently 5 such transformations: + +- diffcore-break +- diffcore-rename +- diffcore-merge-broken +- diffcore-pickaxe +- diffcore-order + +These are applied in sequence. The set of filepairs 'git-diff-{asterisk}' +commands find are used as the input to diffcore-break, and +the output from diffcore-break is used as the input to the +next transformation. The final result is then passed to the +output routine and generates either diff-raw format (see Output +format sections of the manual for 'git-diff-{asterisk}' commands) or +diff-patch format. + + +diffcore-break: For Splitting Up "Complete Rewrites" +---------------------------------------------------- + +The second transformation in the chain is diffcore-break, and is +controlled by the -B option to the 'git-diff-{asterisk}' commands. This is +used to detect a filepair that represents "complete rewrite" and +break such filepair into two filepairs that represent delete and +create. E.g. If the input contained this filepair: + +------------------------------------------------ +:100644 100644 bcd1234... 0123456... M file0 +------------------------------------------------ + +and if it detects that the file "file0" is completely rewritten, +it changes it to: + +------------------------------------------------ +:100644 000000 bcd1234... 0000000... D file0 +:000000 100644 0000000... 0123456... A file0 +------------------------------------------------ + +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 +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 +score defaults to 50% of the size of the smaller of the original +and the result (i.e. if the edit shrinks the file, the size of +the result is used; if the edit lengthens the file, the size of +the original is used), and can be customized by giving a number +after "-B" option (e.g. "-B75" to tell it to use 75%). + + +diffcore-rename: For Detection Renames and Copies +------------------------------------------------- + +This transformation is used to detect renames and copies, and is +controlled by the -M option (to detect renames) and the -C option +(to detect copies as well) to the 'git-diff-{asterisk}' commands. If the +input contained these filepairs: + +------------------------------------------------ +:100644 000000 0123456... 0000000... D fileX +:000000 100644 0000000... 0123456... A file0 +------------------------------------------------ + +and the contents of the deleted file fileX is similar enough to +the contents of the created file file0, then rename detection +merges these filepairs and creates: + +------------------------------------------------ +:100644 100644 0123456... 0123456... R100 fileX file0 +------------------------------------------------ + +When the "-C" option is used, the original contents of modified files, +and deleted files (and also unmodified files, if the +"\--find-copies-harder" option is used) are considered as candidates +of the source files in rename/copy operation. If the input were like +these filepairs, that talk about a modified file fileY and a newly +created file file0: + +------------------------------------------------ +:100644 100644 0123456... 1234567... M fileY +:000000 100644 0000000... bcd3456... A file0 +------------------------------------------------ + +the original contents of fileY and the resulting contents of +file0 are compared, and if they are similar enough, they are +changed to: + +------------------------------------------------ +:100644 100644 0123456... 1234567... M fileY +:100644 100644 0123456... bcd3456... C100 fileY file0 +------------------------------------------------ + +In both rename and copy detection, the same "extent of changes" +algorithm used in diffcore-break is used to determine if two +files are "similar enough", and can be customized to use +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` +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`, +'git-diff-{asterisk}' commands can detect copies only if the file that was +copied happened to have been modified in the same changeset. + + +diffcore-merge-broken: For Putting "Complete Rewrites" Back Together +-------------------------------------------------------------------- + +This transformation is used to merge filepairs broken by +diffcore-break, and not transformed into rename/copy by +diffcore-rename, back into a single modification. This always +runs when diffcore-break is used. + +For the purpose of merging broken filepairs back, it uses a +different "extent of changes" computation from the ones used by +diffcore-break and diffcore-rename. It counts only the deletion +from the original, and does not count insertion. If you removed +only 10 lines from a 100-line document, even if you added 910 +new lines to make a new 1000-line document, you did not do a +complete rewrite. diffcore-break breaks such a case in order to +help diffcore-rename to consider such filepairs as candidate of +rename/copy detection, but if filepairs broken that way were not +matched with other filepairs to create rename/copy, then this +transformation merges them back into the original +"modification". + +The "extent of changes" parameter can be tweaked from the +default 80% (that is, unless more than 80% of the original +material is deleted, the broken pairs are merged back into a +single modification) by giving a second number to -B option, +like these: + +* -B50/60 (give 50% "break score" to diffcore-break, use 60% + for diffcore-merge-broken). + +* -B/60 (the same as above, since diffcore-break defaults to 50%). + +Note that earlier implementation left a broken pair as a separate +creation and deletion patches. This was an unnecessary hack and +the latest implementation always merges all the broken pairs +back into modifications, but the resulting patch output is +formatted differently for easier review in case of such +a complete rewrite by showing the entire contents of old version +prefixed with '-', followed by the entire contents of new +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 "original" side has the specified string and +whose "result" side does not. 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 +changeset easier. + + +diffcore-order: For Sorting the Output Based on Filenames +--------------------------------------------------------- + +This is used to reorder the filepairs according to the user's +(or project's) taste, and is controlled by the -O option to the +'git-diff-{asterisk}' commands. + +This takes a text file each of whose lines is a shell glob +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 +would look like this: + +------------------------------------------------ +README +Makefile +Documentation +*.h +*.c +t +------------------------------------------------ + +SEE ALSO +-------- +linkgit:git-diff[1], +linkgit:git-diff-files[1], +linkgit:git-diff-index[1], +linkgit:git-diff-tree[1], +linkgit:git-format-patch[1], +linkgit:git-log[1], +linkgit:gitglossary[7], +link:user-manual.html[The Git User's Manual] + +GIT +--- +Part of the linkgit:git[1] suite. diff --git a/Documentation/gitglossary.txt b/Documentation/gitglossary.txt new file mode 100644 index 0000000000..d77a45aed6 --- /dev/null +++ b/Documentation/gitglossary.txt @@ -0,0 +1,27 @@ +gitglossary(7) +============== + +NAME +---- +gitglossary - A GIT Glossary + +SYNOPSIS +-------- +* + +DESCRIPTION +----------- + +include::glossary-content.txt[] + +SEE ALSO +-------- +linkgit:gittutorial[7], +linkgit:gittutorial-2[7], +linkgit:gitcvs-migration[7], +link:everyday.html[Everyday git], +link:user-manual.html[The Git User's Manual] + +GIT +--- +Part of the linkgit:git[1] suite. diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt new file mode 100644 index 0000000000..4cc3d1387f --- /dev/null +++ b/Documentation/githooks.txt @@ -0,0 +1,351 @@ +githooks(5) +=========== + +NAME +---- +githooks - Hooks used by git + +SYNOPSIS +-------- +$GIT_DIR/hooks/* + + +DESCRIPTION +----------- + +Hooks are little scripts you can place in `$GIT_DIR/hooks` +directory to trigger action at certain points. When +'git-init' is run, a handful of example hooks are copied into the +`hooks` directory of the new repository, but by default they are +all disabled. To enable a hook, rename it by removing its `.sample` +suffix. + +NOTE: It is also a requirement for a given hook to be executable. +However - in a freshly initialized repository - the `.sample` files are +executable by default. + +This document describes the currently defined hooks. + +HOOKS +----- + +applypatch-msg +~~~~~~~~~~~~~~ + +This hook is invoked by 'git-am' script. It takes a single +parameter, the name of the file that holds the proposed commit +log message. Exiting with non-zero status causes +'git-am' to abort before applying the patch. + +The hook is allowed to edit the message file in place, and can +be used to normalize the message into some project standard +format (if the project has one). It can also be used to refuse +the commit after inspecting the message file. + +The default 'applypatch-msg' hook, when enabled, runs the +'commit-msg' hook, if the latter is enabled. + +pre-applypatch +~~~~~~~~~~~~~~ + +This hook is invoked by 'git-am'. It takes no parameter, and is +invoked after the patch is applied, but before a commit is made. + +If it exits with non-zero status, then the working tree will not be +committed after applying the patch. + +It can be used to inspect the current working tree and refuse to +make a commit if it does not pass certain test. + +The default 'pre-applypatch' hook, when enabled, runs the +'pre-commit' hook, if the latter is enabled. + +post-applypatch +~~~~~~~~~~~~~~~ + +This hook is invoked by 'git-am'. It takes no parameter, +and is invoked after the patch is applied and a commit is made. + +This hook is meant primarily for notification, and cannot affect +the outcome of 'git-am'. + +pre-commit +~~~~~~~~~~ + +This hook is invoked by 'git-commit', and can be bypassed +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. + +The default 'pre-commit' hook, when enabled, catches introduction +of lines with trailing whitespaces and aborts the commit when +such a line is found. + +All the 'git-commit' hooks are invoked with the environment +variable `GIT_EDITOR=:` if the command will not bring up an editor +to modify the commit message. + +prepare-commit-msg +~~~~~~~~~~~~~~~~~~ + +This hook is invoked by 'git-commit' right after preparing the +default log message, and before the editor is started. + +It takes one to three parameters. The first is the name of the file +that contains the commit log message. The second is the source of the commit +message, and can be: `message` (if a `-m` or `-F` option was +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). + +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 +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 +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 +name of the file that holds the proposed commit log message. +Exiting with non-zero status causes the 'git-commit' to +abort. + +The hook is allowed to edit the message file in place, and can +be used to normalize the message into some project standard +format (if the project has one). It can also be used to refuse +the commit after inspecting the message file. + +The default 'commit-msg' hook, when enabled, detects duplicate +"Signed-off-by" lines, and aborts the commit if one is found. + +post-commit +~~~~~~~~~~~ + +This hook is invoked by 'git-commit'. It takes no +parameter, and is invoked after a commit is made. + +This hook is meant primarily for notification, and cannot affect +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. + + +post-checkout +~~~~~~~~~~~~~ + +This hook is invoked when a 'git-checkout' is run after having updated the +worktree. The hook is given three parameters: the ref of the previous HEAD, +the ref of the new HEAD (which may or may not have changed), and a flag +indicating whether the checkout was a branch checkout (changing branches, +flag=1) or a file checkout (retrieving a file from the index, flag=0). +This hook cannot affect the outcome of 'git-checkout'. + +It is also run after 'git-clone', unless the --no-checkout (-n) option is +used. The first parameter given to the hook is the null-ref, the second the +ref of the new HEAD and the flag is always 1. + +This hook can be used to perform repository validity checks, auto-display +differences from the previous HEAD if different, or set working dir metadata +properties. + +post-merge +~~~~~~~~~~ + +This hook is invoked by 'git-merge', which happens when a 'git-pull' +is done on a local repository. The hook takes a single parameter, a status +flag specifying whether or not the merge being done was a squash merge. +This hook cannot affect the outcome of 'git-merge' and is not executed, +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 +for an example of how to do this. + +[[pre-receive]] +pre-receive +~~~~~~~~~~~ + +This hook is invoked by 'git-receive-pack' on the remote repository, +which happens when a 'git-push' is done on a local repository. +Just before starting to update refs on the remote repository, the +pre-receive hook is invoked. Its exit status determines the success +or failure of the update. + +This hook executes once for the receive operation. It takes no +arguments, but for each ref to be updated it receives on standard +input a line of the format: + + <old-value> SP <new-value> SP <ref-name> LF + +where `<old-value>` is the old object name stored in the ref, +`<new-value>` is the new object name to be stored in the ref and +`<ref-name>` is the full name of the ref. +When creating a new ref, `<old-value>` is 40 `0`. + +If the hook exits with non-zero status, none of the refs will be +updated. If the hook exits with zero, updating of individual refs can +still be prevented by the <<update,'update'>> 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. + +[[update]] +update +~~~~~~ + +This hook is invoked by 'git-receive-pack' on the remote repository, +which happens when a 'git-push' is done on a local repository. +Just before updating the ref on the remote repository, the update hook +is invoked. Its exit status determines the success or failure of +the ref update. + +The hook executes once for each ref to be updated, and takes +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. + +A zero exit from the update hook allows the ref to be updated. +Exiting with a non-zero status prevents 'git-receive-pack' +from updating that ref. + +This hook can be used to prevent 'forced' update on certain refs by +making sure that the object name is a commit object that is a +descendant of the commit object named by the old object name. +That is, to enforce a "fast-forward only" policy. + +It could also be used to log the old..new status. However, it +does not know the entire set of branches, so it would end up +firing one e-mail per ref when used naively, though. The +<<post-receive,'post-receive'>> hook is more suited to that. + +Another use suggested on the mailing list is to use this hook to +implement access control which is finer grained than the one +based on filesystem group. + +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. + +The default 'update' hook, when enabled--and with +`hooks.allowunannotated` config option unset or set to false--prevents +unannotated tags to be pushed. + +[[post-receive]] +post-receive +~~~~~~~~~~~~ + +This hook is invoked by 'git-receive-pack' on the remote repository, +which happens when a 'git-push' is done on a local repository. +It executes on the remote repository once after all the refs have +been updated. + +This hook executes once for the receive operation. It takes no +arguments, but gets the same information as the +<<pre-receive,'pre-receive'>> +hook does on its standard input. + +This hook does not affect the outcome of 'git-receive-pack', as it +is called after the real work is done. + +This supersedes the <<post-update,'post-update'>> hook in that it gets +both old and new values of all the refs in addition to their +names. + +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. + +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 +emails. + +[[post-update]] +post-update +~~~~~~~~~~~ + +This hook is invoked by 'git-receive-pack' on the remote repository, +which happens when a 'git-push' is done on a local repository. +It executes on the remote repository once after all the refs have +been updated. + +It takes a variable number of parameters, each of which is the +name of ref that was actually updated. + +This hook is meant primarily for notification, and cannot affect +the outcome of 'git-receive-pack'. + +The 'post-update' hook can tell what are the heads that were pushed, +but it does not know what their original and updated values are, +so it is a poor place to do log old..new. The +<<post-receive,'post-receive'>> hook does get both original and +updated values of the refs. You might consider it instead if you need +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 +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. + +post-upload-pack +---------------- + +After upload-pack successfully finishes its operation, this hook is called +for logging purposes. + +The hook is passed various pieces of information, one per line, from its +standard input. Currently the following items can be fed to the hook, but +more types of information may be added in the future: + +want SHA-1:: + 40-byte hexadecimal object name the client asked to include in the + resulting pack. Can occur one or more times in the input. + +have SHA-1:: + 40-byte hexadecimal object name the client asked to exclude from + the resulting pack, claiming to have them already. Can occur zero + or more times in the input. + +time float:: + Number of seconds spent for creating the packfile. + +size decimal:: + Size of the resulting packfile in bytes. + +kind string: + Either "clone" (when the client did not give us any "have", and asked + for all our refs with "want"), or "fetch" (otherwise). + +pre-auto-gc +~~~~~~~~~~~ + +This hook is invoked by 'git-gc --auto'. It takes no parameter, and +exiting with non-zero status from this script causes the 'git-gc --auto' +to abort. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt new file mode 100644 index 0000000000..7df3cef46f --- /dev/null +++ b/Documentation/gitignore.txt @@ -0,0 +1,146 @@ +gitignore(5) +============ + +NAME +---- +gitignore - Specifies intentionally untracked files to ignore + +SYNOPSIS +-------- +$GIT_DIR/info/exclude, .gitignore + +DESCRIPTION +----------- + +A `gitignore` file specifies intentionally untracked files that +git should ignore. +Note that all the `gitignore` files really concern only files +that are not already tracked by git; +in order to ignore uncommitted changes in already tracked files, +please refer to the 'git update-index --assume-unchanged' +documentation. + +Each line in a `gitignore` file specifies a pattern. +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): + + * Patterns read from the command line for those commands that support + them. + + * Patterns read from a `.gitignore` file in the same directory + as the path, or in any parent directory, with patterns in the + higher level files (up to the toplevel of the work tree) being overridden + by those in lower level files down to the directory containing the file. + These patterns match relative to the location of the + `.gitignore` file. A project normally includes such + `.gitignore` files in its repository, containing patterns for + files generated as part of the project build. + + * Patterns read from `$GIT_DIR/info/exclude`. + + * Patterns read from the file specified by the configuration + 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 +'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 +tools, such as 'git-status' and 'git-add', +use patterns from the sources specified above. + +Patterns have the following format: + + - A blank line matches no files, so it can serve as a separator + for readability. + + - A line starting with # serves as a comment. + + - 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. + + - 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). + + - If the pattern does not contain a slash '/', git treats it as + a shell glob pattern and checks for a match against the + pathname without leading directories. + + - 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/\*.html" matches + "Documentation/git.html" but not + "Documentation/ppc/ppc.html". A leading slash matches the + beginning of the pathname; for example, "/*.c" matches + "cat-file.c" but not "mozilla-sha1/sha1.c". + +An example: + +-------------------------------------------------------------- + $ git status + [...] + # Untracked files: + [...] + # Documentation/foo.html + # Documentation/gitignore.html + # file.o + # lib.a + # src/internal.o + [...] + $ cat .git/info/exclude + # ignore objects and archives, anywhere in the tree. + *.[oa] + $ cat Documentation/.gitignore + # ignore generated html files, + *.html + # except foo.html which is maintained by hand + !foo.html + $ git status + [...] + # Untracked files: + [...] + # Documentation/foo.html + [...] +-------------------------------------------------------------- + +Another example: + +-------------------------------------------------------------- + $ cat .gitignore + vmlinux* + $ ls arch/foo/kernel/vm* + arch/foo/kernel/vmlinux.lds.S + $ echo '!/vmlinux*' >arch/foo/kernel/.gitignore +-------------------------------------------------------------- + +The second .gitignore prevents git from ignoring +`arch/foo/kernel/vmlinux.lds.S`. + +Documentation +------------- +Documentation by David Greaves, Junio C Hamano, Josh Triplett, +Frank Lichtenheld, and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt new file mode 100644 index 0000000000..cf465cb47e --- /dev/null +++ b/Documentation/gitk.txt @@ -0,0 +1,127 @@ +gitk(1) +======= + +NAME +---- +gitk - The git repository browser + +SYNOPSIS +-------- +'gitk' [<option>...] [<revs>] [--] [<path>...] + +DESCRIPTION +----------- +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>:: + + Limits the number of commits to show. + +--since=<date>:: + + Show commits more recent than a specific date. + +--until=<date>:: + + Show commits older than a specific date. + +--all:: + + Show all branches. + +--merge:: + + After an attempt to merge stops with conflicts, show the commits on + the history between two branches (i.e. the HEAD and the MERGE_HEAD) + 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. + +--select-commit=<ref>:: + + Automatically select the specified commit after loading the graph. + Default behavior is equivalent to specifying '--select-commit=HEAD'. + +<revs>:: + + 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 + the form "'<from>'..'<to>'" to show all revisions between '<from>' and + back to '<to>'. Note, more advanced revision selection can be applied. + For a more complete list of ways to spell object names, see + "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. + +<path>...:: + + Limit commits to the ones touching files in the given paths. Note, to + avoid ambiguity with respect to revision names use "--" to separate the paths + from any preceding options. + +Examples +-------- +gitk v2.6.12.. include/scsi drivers/scsi:: + + Show the changes since version 'v2.6.12' that changed any + file in the include/scsi or drivers/scsi subdirectories + +gitk --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 + 'gitk' + +gitk --max-count=100 --all \-- Makefile:: + + Show at most 100 changes made to the file 'Makefile'. Instead of only + looking for changes in the current branch look in all branches. + +Files +----- +Gitk creates the .gitk file in your $HOME directory to store preferences +such as display options, font, and colors. + +SEE ALSO +-------- +'qgit(1)':: + A repository browser written in C++ using Qt. + +'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. + +'tig(1)':: + A minimal repository browser and git tool output highlighter written + in C using Ncurses. + +Author +------ +Written by Paul Mackerras <paulus@samba.org>. + +Documentation +-------------- +Documentation by Junio C Hamano, Jonas Fonseca, and the git-list +<git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt new file mode 100644 index 0000000000..5daf750d19 --- /dev/null +++ b/Documentation/gitmodules.txt @@ -0,0 +1,73 @@ +gitmodules(5) +============= + +NAME +---- +gitmodules - defining submodule properties + +SYNOPSIS +-------- +$GIT_WORK_DIR/.gitmodules + + +DESCRIPTION +----------- + +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 +following required keys: + +submodule.<name>.path:: + 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. + +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. + + +EXAMPLES +-------- + +Consider the following .gitmodules file: + + [submodule "libfoo"] + path = include/foo + url = git://foo.com/git/lib.git + + [submodule "libbar"] + path = include/bar + url = git://bar.com/git/lib.git + + +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. + +SEE ALSO +-------- +linkgit:git-submodule[1] linkgit:git-config[1] + +DOCUMENTATION +------------- +Documentation by Lars Hjemli <hjemli@gmail.com> + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt new file mode 100644 index 0000000000..1befca98d4 --- /dev/null +++ b/Documentation/gitrepository-layout.txt @@ -0,0 +1,209 @@ +gitrepository-layout(5) +======================= + +NAME +---- +gitrepository-layout - Git Repository Layout + +SYNOPSIS +-------- +$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). + +objects:: + Object store associated with this repository. Usually + an object store is self sufficient (i.e. all the objects + that are referred to by an object found in it are also + found in it), but there are couple of ways to violate + it. ++ +. You could populate the repository by running a commit walker +without `-a` option. Depending on which options are given, you +could have only commit objects without associated blobs and +trees this way, for example. A repository with this kind of +incomplete object store is not suitable to be published to the +outside world but sometimes useful for private repository. +. You also could have an incomplete but locally usable repository +by cloning shallowly. See linkgit:git-clone[1]. +. You can be using `objects/info/alternates` mechanism, or +`$GIT_ALTERNATE_OBJECT_DIRECTORIES` mechanism to 'borrow' +objects from other object stores. A repository with this kind +of incomplete object store is not suitable to be published for +use with dumb transports but otherwise is OK as long as +`objects/info/alternates` points at the right object stores +it borrows from. + +objects/[0-9a-f][0-9a-f]:: + Traditionally, each object is stored in its own file. + They are split into 256 subdirectories using the first + two letters from its object name to keep the number of + directory entries `objects` directory itself needs to + hold. Objects found here are often called 'unpacked' + (or 'loose') objects. + +objects/pack:: + Packs (files that store many object in compressed form, + along with index files to allow them to be randomly + accessed) are found in this directory. + +objects/info:: + Additional information about the object store is + recorded in this directory. + +objects/info/packs:: + This file is to help dumb transports discover what packs + are available in this object store. Whenever a pack is + added or removed, `git update-server-info` should be run + to keep this file up-to-date if the repository is + published for dumb transports. 'git-repack' does this + by default. + +objects/info/alternates:: + This file records paths to alternate object stores that + this object store borrows objects from, one pathname per + line. Note that not only native Git tools use it locally, + but the HTTP fetcher also tries to use it remotely; this + will usually work if you have relative paths (relative + to the object database, not to the repository!) in your + alternates file, but it will not work if you use absolute + paths unless the absolute path in filesystem and web URL + is the same. See also 'objects/info/http-alternates'. + +objects/info/http-alternates:: + This file records URLs to alternate object stores that + this object store borrows objects from, to be used when + the repository is fetched over HTTP. + +refs:: + References are stored in subdirectories of this + directory. The 'git-prune' command knows to keep + objects reachable from refs found in this directory and + its subdirectories. + +refs/heads/`name`:: + records tip-of-the-tree commit objects of branch `name` + +refs/tags/`name`:: + records any object name (not necessarily a commit + object, or a tag object that points at a commit object). + +refs/remotes/`name`:: + records tip-of-the-tree commit objects of branches copied + from a remote repository. + +packed-refs:: + records the same information as refs/heads/, refs/tags/, + and friends record in a more efficient way. See + linkgit:git-pack-refs[1]. + +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 + *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 + 'name' does not (yet) exist. In some legacy setups, it is + a symbolic link instead of a symref that points at the current + branch. ++ +HEAD can also record a specific commit directly, instead of +being a symref to point at the current branch. Such a state +is often called 'detached HEAD', and almost all commands work +identically as normal. See linkgit:git-checkout[1] for +details. + +branches:: + A slightly deprecated way to store shorthands to be used + to specify URL to 'git-fetch', 'git-pull' and 'git-push' + commands is to store a file in `branches/<name>` and + give 'name' to these commands in place of 'repository' + argument. + +hooks:: + 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 + removed from the filename by renaming. + Read linkgit:githooks[5] for more details about + each hook. + +index:: + The current index file for the repository. It is + usually not found in a bare repository. + +info:: + Additional information about the repository is recorded + in this directory. + +info/refs:: + This file helps dumb transports discover what refs are + available in this repository. If the repository is + published for dumb transports, this file should be + regenerated by 'git-update-server-info' every time a tag + or branch is created or modified. This is normally done + from the `hooks/update` hook, which is run by the + 'git-receive-pack' command when you 'git-push' into the + repository. + +info/grafts:: + This file records fake commit ancestry information, to + pretend the set of parents a commit has is different + from how the commit was actually created. One record + 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. + +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 + at it. See also: linkgit:gitignore[5]. + +remotes:: + Stores shorthands to be used to give URL and default + refnames to interact with remote repository to + 'git-fetch', 'git-pull' and 'git-push' commands. + +logs:: + Records of changes made to refs are stored in this + directory. See linkgit:git-update-ref[1] + for more information. + +logs/refs/heads/`name`:: + Records all changes made to the branch tip named `name`. + +logs/refs/tags/`name`:: + Records all changes made to the tag named `name`. + +shallow:: + This is similar to `info/grafts` but is internally used + and maintained by shallow clone mechanism. See `--depth` + option to linkgit:git-clone[1] and linkgit:git-fetch[1]. + +SEE ALSO +-------- +linkgit:git-init[1], +linkgit:git-clone[1], +linkgit:git-fetch[1], +linkgit:git-pack-refs[1], +linkgit:git-gc[1], +linkgit:git-checkout[1], +linkgit:gitglossary[7], +link:user-manual.html[The Git User's Manual] + +GIT +--- +Part of the linkgit:git[1] suite. diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt new file mode 100644 index 0000000000..dc8fc3a18a --- /dev/null +++ b/Documentation/gittutorial-2.txt @@ -0,0 +1,434 @@ +gittutorial-2(7) +================ + +NAME +---- +gittutorial-2 - A tutorial introduction to git: part two + +SYNOPSIS +-------- +git * + +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 +provide the reader with everything necessary to understand the rest +of the git documentation. + +The git object database +----------------------- + +Let's start a new project and create a small amount of history: + +------------------------------------------------ +$ mkdir test-project +$ cd test-project +$ git init +Initialized empty Git repository in .git/ +$ echo 'hello world' > file.txt +$ git add . +$ git commit -a -m "initial commit" +[master (root-commit) 54196cc] initial commit + 1 files changed, 1 insertions(+), 0 deletions(-) + create mode 100644 file.txt +$ echo 'hello world!' >file.txt +$ git commit -a -m "add emphasis" +[master c4d59f3] add emphasis + 1 files changed, 1 insertions(+), 1 deletions(-) +------------------------------------------------ + +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 +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 +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` +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: + +------------------------------------------------ +$ git cat-file -t 54196cc2 +commit +$ git cat-file commit 54196cc2 +tree 92b8b694ffb1675e5975148e1121810081dbdffe +author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500 +committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500 + +initial commit +------------------------------------------------ + +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): + +------------------------------------------------ +$ 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 +reference to that file's data: + +------------------------------------------------ +$ git cat-file -t 3b18e512 +blob +------------------------------------------------ + +A "blob" is just file data, which we can also examine with cat-file: + +------------------------------------------------ +$ git cat-file blob 3b18e512 +hello world +------------------------------------------------ + +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 +directory: + +------------------------------------------------ +$ find .git/objects/ +.git/objects/ +.git/objects/pack +.git/objects/info +.git/objects/3b +.git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad +.git/objects/92 +.git/objects/92/b8b694ffb1675e5975148e1121810081dbdffe +.git/objects/54 +.git/objects/54/196cc2703dc165cbd373a65a4dcf22d50ae7f7 +.git/objects/a0 +.git/objects/a0/423896973644771497bdc03eb99d5281615b51 +.git/objects/d0 +.git/objects/d0/492b368b66bdabf2ac1fd8c92b39d3db916e59 +.git/objects/c4 +.git/objects/c4/d59f390b9cfd4318117afde11d601c1085f241 +------------------------------------------------ + +and the contents of these files is just the compressed data plus a +header identifying their length and their type. The type is either a +blob, a tree, a commit, or a tag. + +The simplest commit to find is the HEAD commit, which we can find +from .git/HEAD: + +------------------------------------------------ +$ cat .git/HEAD +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 +examine with cat-file: + +------------------------------------------------ +$ cat .git/refs/heads/master +c4d59f390b9cfd4318117afde11d601c1085f241 +$ git cat-file -t c4d59f39 +commit +$ git cat-file commit c4d59f39 +tree d0492b368b66bdabf2ac1fd8c92b39d3db916e59 +parent 54196cc2703dc165cbd373a65a4dcf22d50ae7f7 +author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500 +committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500 + +add emphasis +------------------------------------------------ + +The "tree" object here refers to the new state of the tree: + +------------------------------------------------ +$ git ls-tree d0492b36 +100644 blob a0423896973644771497bdc03eb99d5281615b51 file.txt +$ git cat-file blob a0423896 +hello world! +------------------------------------------------ + +and the "parent" object refers to the previous commit: + +------------------------------------------------ +$ git cat-file commit 54196cc2 +tree 92b8b694ffb1675e5975148e1121810081dbdffe +author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500 +committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500 + +initial commit +------------------------------------------------ + +The tree object is the tree we examined first, and this commit is +unusual in that it lacks any parent. + +Most commits have only one parent, but it is also common for a commit +to have multiple parents. In that case the commit represents a +merge, with the parent references pointing to the heads of the merged +branches. + +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 +project's history: + + * "commit" objects refer to "tree" objects representing the + snapshot of a directory tree at a particular point in the + history, and refer to "parent" commits to show how they're + connected into the project history. + * "tree" objects represent the state of a single directory, + associating directory names to "blob" objects containing file + data and "tree" objects containing subdirectory information. + * "blob" objects contain file data without any other structure. + * References to commit objects at the head of each branch are + stored in files under .git/refs/heads/. + * The name of the current branch is stored in .git/HEAD. + +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 +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. + +In command synopses, the word "tree-ish" is sometimes used to +designate such an argument. + +The index file +-------------- + +The primary tool we've been using to create commits is `git-commit +-a`, which creates a commit including every change you've made to +your working tree. But what if you want to commit changes only to +certain files? Or only certain changes to certain files? + +If we look at the way commits are created under the cover, we'll see +that there are more flexible ways creating commits. + +Continuing with our test-project, let's modify file.txt again: + +------------------------------------------------ +$ echo "hello world, again" >>file.txt +------------------------------------------------ + +but this time instead of immediately making the commit, let's take an +intermediate step, and ask for diffs along the way to keep track of +what's happening: + +------------------------------------------------ +$ git diff +--- a/file.txt ++++ b/file.txt +@@ -1 +1,2 @@ + hello world! ++hello world, again +$ git add file.txt +$ git diff +------------------------------------------------ + +The last diff is empty, but no new commits have been made, and the +head still doesn't contain the new line: + +------------------------------------------------ +$ git diff HEAD +diff --git a/file.txt b/file.txt +index a042389..513feba 100644 +--- a/file.txt ++++ b/file.txt +@@ -1 +1,2 @@ + hello world! ++hello world, again +------------------------------------------------ + +So 'git-diff' is comparing against something other than the head. +The thing that it's comparing against is actually the index file, +which is stored in .git/index in a binary format, but whose contents +we can examine with ls-files: + +------------------------------------------------ +$ git ls-files --stage +100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt +$ git cat-file -t 513feba2 +blob +$ git cat-file blob 513feba2 +hello world! +hello world, again +------------------------------------------------ + +So what our 'git-add' did was store a new blob and then put +a reference to it in the index file. If we modify the file again, +we'll see that the new modifications are reflected in the 'git-diff' +output: + +------------------------------------------------ +$ echo 'again?' >>file.txt +$ git diff +index 513feba..ba3da7b 100644 +--- a/file.txt ++++ b/file.txt +@@ -1,2 +1,3 @@ + hello world! + hello world, again ++again? +------------------------------------------------ + +With the right arguments, 'git-diff' can also show us the difference +between the working directory and the last commit, or between the +index and the last commit: + +------------------------------------------------ +$ git diff HEAD +diff --git a/file.txt b/file.txt +index a042389..ba3da7b 100644 +--- a/file.txt ++++ b/file.txt +@@ -1 +1,3 @@ + hello world! ++hello world, again ++again? +$ git diff --cached +diff --git a/file.txt b/file.txt +index a042389..513feba 100644 +--- a/file.txt ++++ b/file.txt +@@ -1 +1,2 @@ + hello world! ++hello world, again +------------------------------------------------ + +At any time, we can create a new commit using 'git-commit' (without +the "-a" option), and verify that the state committed only includes the +changes stored in the index file, not the additional change that is +still only in our working tree: + +------------------------------------------------ +$ git commit -m "repeat" +$ git diff HEAD +diff --git a/file.txt b/file.txt +index 513feba..ba3da7b 100644 +--- a/file.txt ++++ b/file.txt +@@ -1,2 +1,3 @@ + hello world! + hello world, again ++again? +------------------------------------------------ + +So by default 'git-commit' uses the index to create the commit, not +the working tree; the "-a" option to commit tells it to first update +the index with all changes in the working tree. + +Finally, it's worth looking at the effect of 'git-add' on the index +file: + +------------------------------------------------ +$ echo "goodbye, world" >closing.txt +$ git add closing.txt +------------------------------------------------ + +The effect of the 'git-add' was to add one entry to the index file: + +------------------------------------------------ +$ git ls-files --stage +100644 8b9743b20d4b15be3955fc8d5cd2b09cd2336138 0 closing.txt +100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt +------------------------------------------------ + +And, as you can see with cat-file, this new entry refers to the +current contents of the file: + +------------------------------------------------ +$ git cat-file blob 8b9743b2 +goodbye, world +------------------------------------------------ + +The "status" command is a useful way to get a quick summary of the +situation: + +------------------------------------------------ +$ git status +# On branch master +# Changes to be committed: +# (use "git reset HEAD <file>..." to unstage) +# +# new file: closing.txt +# +# Changed but not updated: +# (use "git add <file>..." to update what will be committed) +# +# modified: file.txt +# +------------------------------------------------ + +Since the current state of closing.txt is cached in the index file, +it is listed as "Changes to be committed". Since file.txt has +changes in the working directory that aren't reflected in the index, +it is marked "changed but not updated". At this point, running "git +commit" would create a commit that added closing.txt (with its new +contents), but that didn't modify file.txt. + +Also, note that a bare `git diff` shows the changes to file.txt, but +not the addition of closing.txt, because the version of closing.txt +in the index file is identical to the one in the working directory. + +In addition to being the staging area for new commits, the index file +is also populated from the object database when checking out a +branch, and is used to hold the trees involved in a merge operation. +See linkgit:gitcore-tutorial[7] and the relevant man +pages for details. + +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 +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. + +linkgit:gitcvs-migration[7] explains how to +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 +link:howto-index.html[howtos]. + +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 +-------- +linkgit:gittutorial[7], +linkgit:gitcvs-migration[7], +linkgit:gitcore-tutorial[7], +linkgit:gitglossary[7], +linkgit:git-help[1], +link:everyday.html[Everyday git], +link:user-manual.html[The Git User's Manual] + +GIT +--- +Part of the linkgit:git[1] suite. diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt new file mode 100644 index 0000000000..cf0689cfeb --- /dev/null +++ b/Documentation/gittutorial.txt @@ -0,0 +1,673 @@ +gittutorial(7) +============== + +NAME +---- +gittutorial - A tutorial introduction to git (for version 1.5.1 or newer) + +SYNOPSIS +-------- +git * + +DESCRIPTION +----------- + +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, +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]. + +First, note that you can get documentation for a command such as +`git log --graph` with: + +------------------------------------------------ +$ man git-log +------------------------------------------------ + +or: + +------------------------------------------------ +$ 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 +public email address before doing any operation. The easiest +way to do so is: + +------------------------------------------------ +$ git config --global user.name "Your Name Comes Here" +$ git config --global user.email you@yourdomain.example.com +------------------------------------------------ + + +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. + +------------------------------------------------ +$ tar xzf project.tar.gz +$ cd project +$ git init +------------------------------------------------ + +Git will reply + +------------------------------------------------ +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 +current directory (note the '.'), with 'git-add': + +------------------------------------------------ +$ git add . +------------------------------------------------ + +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': + +------------------------------------------------ +$ git commit +------------------------------------------------ + +This will prompt you for a commit message. You've now stored the first +version of your project in git. + +Making changes +-------------- + +Modify some files, then add their updated contents to the index: + +------------------------------------------------ +$ git add file1 file2 file3 +------------------------------------------------ + +You are now ready to commit. You can see what is about to be committed +using 'git-diff' with the --cached option: + +------------------------------------------------ +$ git diff --cached +------------------------------------------------ + +(Without --cached, 'git-diff' will show you any changes that +you've made but not yet added to the index.) You can also get a brief +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 +# +------------------------------------------------ + +If you need to make any further adjustments, do so now, and then add any +newly modified content to the index. Finally, commit your changes with: + +------------------------------------------------ +$ git commit +------------------------------------------------ + +This will again prompt you for a message describing the change, and then +record a new version of the project. + +Alternatively, instead of running 'git-add' beforehand, you can use + +------------------------------------------------ +$ git commit -a +------------------------------------------------ + +which will automatically notice any modified (but not new) files, add +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. + +Git tracks content not files +---------------------------- + +Many revision control systems provide an `add` command that tells the +system to start tracking changes to a new file. Git's `add` command +does something simpler and more powerful: 'git-add' is used both for new +and newly modified files, and in both cases it takes a snapshot of the +given files and stages that content in the index, ready for inclusion in +the next commit. + +Viewing project history +----------------------- + +At any point you can view the history of your changes using + +------------------------------------------------ +$ git log +------------------------------------------------ + +If you also want to see complete diffs at each step, use + +------------------------------------------------ +$ git log -p +------------------------------------------------ + +Often the overview of the change is useful to get a feel of +each step + +------------------------------------------------ +$ git log --stat --summary +------------------------------------------------ + +Managing branches +----------------- + +A single git repository can maintain multiple branches of +development. To create a new branch named "experimental", use + +------------------------------------------------ +$ git branch experimental +------------------------------------------------ + +If you now run + +------------------------------------------------ +$ git branch +------------------------------------------------ + +you'll get a list of all existing branches: + +------------------------------------------------ + experimental +* master +------------------------------------------------ + +The "experimental" branch is the one you just created, and the +"master" branch is a default branch that was created for you +automatically. The asterisk marks the branch you are currently on; +type + +------------------------------------------------ +$ git checkout experimental +------------------------------------------------ + +to switch to the experimental branch. Now edit a file, commit the +change, and switch back to the master branch: + +------------------------------------------------ +(edit file) +$ git commit -a +$ git checkout master +------------------------------------------------ + +Check that the change you made is no longer visible, since it was +made on the experimental branch and you're back on the master branch. + +You can make a different change on the master branch: + +------------------------------------------------ +(edit file) +$ git commit -a +------------------------------------------------ + +at this point the two branches have diverged, with different changes +made in each. To merge the changes made in experimental into master, run + +------------------------------------------------ +$ git merge experimental +------------------------------------------------ + +If the changes don't conflict, you're done. If there are conflicts, +markers will be left in the problematic files showing the conflict; + +------------------------------------------------ +$ git diff +------------------------------------------------ + +will show this. Once you've edited the files to resolve the +conflicts, + +------------------------------------------------ +$ git commit -a +------------------------------------------------ + +will commit the result of the merge. Finally, + +------------------------------------------------ +$ gitk +------------------------------------------------ + +will show a nice graphical representation of the resulting history. + +At this point you could delete the experimental branch with + +------------------------------------------------ +$ git branch -d experimental +------------------------------------------------ + +This command ensures that the changes in the experimental branch are +already in the current branch. + +If you develop on a branch crazy-idea, then regret it, you can always +delete the branch with + +------------------------------------- +$ git branch -D crazy-idea +------------------------------------- + +Branches are cheap and easy, so this is a good way to try something +out. + +Using git for collaboration +--------------------------- + +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. + +Bob begins with: + +------------------------------------------------ +bob$ git clone /home/alice/project myrepo +------------------------------------------------ + +This creates a new directory "myrepo" containing a clone of Alice's +repository. The clone is on an equal footing with the original +project, possessing its own copy of the original project's history. + +Bob then makes some changes and commits them: + +------------------------------------------------ +(edit files) +bob$ git commit -a +(repeat as necessary) +------------------------------------------------ + +When he's ready, he tells Alice to pull changes from the repository +at /home/bob/myrepo. She does this with: + +------------------------------------------------ +alice$ cd /home/alice/project +alice$ git pull /home/bob/myrepo master +------------------------------------------------ + +This merges the changes from Bob's "master" branch into Alice's +current branch. If Alice has made her own changes in the meantime, +then she may need to manually fix any conflicts. + +The "pull" command thus performs two operations: it fetches changes +from a remote branch, then merges them into the current branch. + +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 +refuse to merge --- Alice will have to get rid of her local changes in +some way and pull again when this happens). + +Alice can peek at what Bob did without merging first, using the "fetch" +command; this allows Alice to inspect what Bob did, using a special +symbol "FETCH_HEAD", in order to determine if he has anything worth +pulling, like this: + +------------------------------------------------ +alice$ git fetch /home/bob/myrepo master +alice$ git log -p HEAD..FETCH_HEAD +------------------------------------------------ + +This operation is safe even if Alice has uncommitted local changes. +The range notation "HEAD..FETCH_HEAD" means "show everything that is reachable +from the FETCH_HEAD but exclude anything that is reachable from HEAD". +Alice already knows everything that leads to her current state (HEAD), +and reviews what Bob has in his state (FETCH_HEAD) that she has not +seen with this command. + +If Alice wants to visualize what Bob did since their histories forked +she can issue the following command: + +------------------------------------------------ +$ gitk HEAD..FETCH_HEAD +------------------------------------------------ + +This uses the same two-dot range notation we saw earlier with 'git log'. + +Alice may want to view what both of them did since they forked. +She can use three-dot form instead of the two-dot form: + +------------------------------------------------ +$ gitk HEAD...FETCH_HEAD +------------------------------------------------ + +This means "show everything that is reachable from either one, but +exclude anything that is reachable from both of them". + +Please note that these range notation can be used with both gitk +and "git log". + +After inspecting what Bob did, if there is nothing urgent, Alice may +decide to continue working without pulling from Bob. If Bob's history +does have something Alice would immediately need, Alice may choose to +stash her work-in-progress first, do a "pull", and then finally unstash +her work-in-progress on top of the resulting history. + +When you are working in a small closely knit group, it is not +unusual to interact with the same repository over and over +again. By defining 'remote' repository shorthand, you can make +it easier: + +------------------------------------------------ +alice$ git remote add bob /home/bob/myrepo +------------------------------------------------ + +With this, Alice can perform the first part of the "pull" operation +alone using the 'git-fetch' command without merging them with her own +branch, using: + +------------------------------------- +alice$ git fetch bob +------------------------------------- + +Unlike the longhand form, when Alice fetches from Bob using a +remote repository shorthand set up with 'git-remote', what was +fetched is stored in a remote tracking branch, in this case +`bob/master`. So after this: + +------------------------------------- +alice$ git log -p master..bob/master +------------------------------------- + +shows a list of all the changes that Bob made since he branched from +Alice's master branch. + +After examining those changes, Alice +could merge the changes into her master branch: + +------------------------------------- +alice$ git merge bob/master +------------------------------------- + +This `merge` can also be done by 'pulling from her own remote +tracking branch', like this: + +------------------------------------- +alice$ git pull . remotes/bob/master +------------------------------------- + +Note that git pull always merges into the current branch, +regardless of what else is given on the command line. + +Later, Bob can update his repo with Alice's latest changes using + +------------------------------------- +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 +repository in the repository configuration, and that location is +used for pulls: + +------------------------------------- +bob$ git config --get remote.origin.url +/home/alice/project +------------------------------------- + +(The complete configuration created by 'git-clone' is visible using +`git config -l`, and the linkgit:git-config[1] man page +explains the meaning of each option.) + +Git also keeps a pristine copy of Alice's master branch under the +name "origin/master": + +------------------------------------- +bob$ git branch -r + origin/master +------------------------------------- + +If Bob later decides to work from a different host, he can still +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; +see linkgit:git-pull[1] for details. + +Git can also be used in a CVS-like mode, with a central repository +that various users push changes to; see linkgit:git-push[1] and +linkgit:gitcvs-migration[7]. + +Exploring history +----------------- + +Git history is represented as a series of interrelated commits. We +have already seen that the 'git-log' command can list those commits. +Note that first line of each git log entry also gives a name for the +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. +------------------------------------- + +We can give this name to 'git-show' to see the details about this +commit. + +------------------------------------- +$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 +------------------------------------- + +But there are other ways to refer to commits. You can use any initial +part of the name that is long enough to uniquely identify the commit: + +------------------------------------- +$ git show c82a22c39c # the first few characters of the name are + # usually enough +$ git show HEAD # the tip of the current branch +$ git show experimental # the tip of the "experimental" branch +------------------------------------- + +Every commit usually has one "parent" commit +which points to the previous state of the project: + +------------------------------------- +$ git show HEAD^ # to see the parent of HEAD +$ git show HEAD^^ # to see the grandparent of HEAD +$ git show HEAD~4 # to see the great-great grandparent of HEAD +------------------------------------- + +Note that merge commits may have more than one parent: + +------------------------------------- +$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^) +$ git show HEAD^2 # show the second parent of HEAD +------------------------------------- + +You can also give commits names of your own; after running + +------------------------------------- +$ git tag v2.5 1b2e1d63ff +------------------------------------- + +you can refer to 1b2e1d63ff by the name "v2.5". If you intend to +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 +names. For example: + +------------------------------------- +$ git diff v2.5 HEAD # compare the current HEAD to v2.5 +$ git branch stable v2.5 # start a new branch named "stable" based + # at v2.5 +$ git reset --hard HEAD^ # reset your current branch and working + # directory to its state at HEAD^ +------------------------------------- + +Be careful with that last command: in addition to losing any changes +in the working directory, it will also remove all later commits from +this branch. If this branch is the only branch containing those +commits, they will be lost. Also, don't use 'git-reset' on a +publicly-visible branch that other developers pull from, as it will +force needless merges on other developers to clean up the history. +If you need to undo changes that you have pushed, use 'git-revert' +instead. + +The 'git-grep' command can search for strings in any version of your +project, so + +------------------------------------- +$ git grep "hello" v2.5 +------------------------------------- + +searches for all occurrences of "hello" in v2.5. + +If you leave out the commit name, 'git-grep' will search any of the +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. + +Many git commands also take sets of commits, which can be specified +in a number of ways. Here are some examples with 'git-log': + +------------------------------------- +$ git log v2.5..v2.6 # commits between v2.5 and v2.6 +$ git log v2.5.. # commits since v2.5 +$ git log --since="2 weeks ago" # commits from the last 2 weeks +$ git log v2.5.. Makefile # commits since v2.5 which modify + # Makefile +------------------------------------- + +You can also give 'git-log' a "range" of commits where the first is not +necessarily an ancestor of the second; for example, if the tips of +the branches "stable" and "master" diverged from a common +commit some time ago, then + +------------------------------------- +$ git log stable..master +------------------------------------- + +will list commits made in the master branch but not in the +stable branch, while + +------------------------------------- +$ git log master..stable +------------------------------------- + +will show the list of commits made on the stable branch but not +the master branch. + +The 'git-log' command has a weakness: it must present commits in a +list. When the history has lines of development that diverged and +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 +visualizing their history. For example, + +------------------------------------- +$ gitk --since="2 weeks ago" drivers/ +------------------------------------- + +allows you to browse any commits from the last 2 weeks of commits +that modified files under the "drivers" directory. (Note: you can +adjust gitk's fonts by holding down the control key while pressing +"-" or "+".) + +Finally, most commands that take filenames will optionally allow you +to precede any filename by a commit, to specify a particular version +of the file: + +------------------------------------- +$ git diff v2.5:Makefile HEAD:Makefile.in +------------------------------------- + +You can also use 'git-show' to see any such file: + +------------------------------------- +$ git show v2.5:Makefile +------------------------------------- + +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 +is based: + + * The object database is the rather elegant system used to + store the history of your project--files, directories, and + commits. + + * The index file is a cache of the state of a directory tree, + used to create commits, check out working directories, and + hold the various trees involved in a merge. + +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]. + +If you don't want to continue with that right away, a few other +digressions that may be interesting at this point are: + + * linkgit:git-format-patch[1], linkgit:git-am[1]: These convert + series of git commits into emailed patches, and vice versa, + useful for projects such as the Linux kernel which rely heavily + on emailed patches. + + * linkgit:git-bisect[1]: When there is a regression in your + project, one way to track down the bug is by searching through + the history to find the exact commit that's to blame. Git bisect + can help you perform a binary search for that commit. It is + smart enough to perform a close-to-optimal search even in the + case of complex non-linear history with lots of merged branches. + + * linkgit:gitworkflows[7]: Gives an overview of recommended + workflows. + + * link:everyday.html[Everyday GIT with 20 Commands Or So] + + * linkgit:gitcvs-migration[7]: Git for CVS users. + +SEE ALSO +-------- +linkgit:gittutorial-2[7], +linkgit:gitcvs-migration[7], +linkgit:gitcore-tutorial[7], +linkgit:gitglossary[7], +linkgit:git-help[1], +linkgit:gitworkflows[7], +link:everyday.html[Everyday git], +link:user-manual.html[The Git User's Manual] + +GIT +--- +Part of the linkgit:git[1] suite. diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt new file mode 100644 index 0000000000..065441df64 --- /dev/null +++ b/Documentation/gitworkflows.txt @@ -0,0 +1,479 @@ +gitworkflows(7) +=============== + +NAME +---- +gitworkflows - An overview of recommended workflows with git + +SYNOPSIS +-------- +git * + + +DESCRIPTION +----------- + +This document attempts to write down and motivate some of the workflow +elements used for `git.git` itself. Many ideas apply in general, +though the full workflow is rarely required for smaller projects with +fewer people involved. + +We formulate a set of 'rules' for quick reference, while the prose +tries to motivate each of them. Do not always take them literally; +you should value good reasons for your actions higher than manpages +such as this one. + + +SEPARATE CHANGES +---------------- + +As a general rule, you should try to split your changes into small +logical steps, and commit each of them. They should be consistent, +working independently of any later commits, pass the test suite, etc. +This makes the review process much easier, and the history much more +useful for later inspection and analysis, for example with +linkgit:git-blame[1] and linkgit:git-bisect[1]. + +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 +test suite independent of other uncommitted changes; see the EXAMPLES +section of linkgit:git-stash[1]. + + +MANAGING BRANCHES +----------------- + +There are two main tools that can be used to include changes from one +branch on another: linkgit:git-merge[1] and +linkgit:git-cherry-pick[1]. + +Merges have many advantages, so we try to solve as many problems as +possible with merges alone. Cherry-picking is still occasionally +useful; see "Merging upwards" below for an example. + +Most importantly, merging works at the branch level, while +cherry-picking works at the commit level. This means that a merge can +carry over the changes from 1, 10, or 1000 commits with equal ease, +which in turn means the workflow scales much better to a large number +of contributors (and contributions). Merges are also easier to +understand because a merge commit is a "promise" that all changes from +all its parents are now included. + +There is a tradeoff of course: merges require a more careful branch +management. The following subsections discuss the important points. + + +Graduation +~~~~~~~~~~ + +As a given feature goes from experimental to stable, it also +"graduates" between the corresponding branches of the software. +`git.git` uses the following 'integration branches': + +* 'maint' tracks the commits that should go into the next "maintenance + release", i.e., update of the last released stable version; + +* 'master' tracks the commits that should go into the next release; + +* 'next' is intended as a testing branch for topics being tested for + stability for master. + +There is a fourth official branch that is used slightly differently: + +* 'pu' (proposed updates) is an integration branch for things that are + not quite ready for inclusion yet (see "Integration Branches" + below). + +Each of the four branches is usually a direct descendant of the one +above it. + +Conceptually, the feature enters at an unstable branch (usually 'next' +or 'pu'), and "graduates" to 'master' for the next release once it is +considered stable enough. + + +Merging upwards +~~~~~~~~~~~~~~~ + +The "downwards graduation" discussed above cannot be done by actually +merging downwards, however, since that would merge 'all' changes on +the unstable branch into the stable one. Hence the following: + +.Merge upwards +[caption="Rule: "] +===================================== +Always commit your fixes to the oldest supported branch that require +them. Then (periodically) merge the integration branches upwards into each +other. +===================================== + +This gives a very controlled flow of fixes. If you notice that you +have applied a fix to e.g. 'master' that is also required in 'maint', +you will need to cherry-pick it (using linkgit:git-cherry-pick[1]) +downwards. This will happen a few times and is nothing to worry about +unless you do it very frequently. + + +Topic branches +~~~~~~~~~~~~~~ + +Any nontrivial feature will require several patches to implement, and +may get extra bugfixes or improvements during its lifetime. + +Committing everything directly on the integration branches leads to many +problems: Bad commits cannot be undone, so they must be reverted one +by one, which creates confusing histories and further error potential +when you forget to revert part of a group of changes. Working in +parallel mixes up the changes, creating further confusion. + +Use of "topic branches" solves these problems. The name is pretty +self explanatory, with a caveat that comes from the "merge upwards" +rule above: + +.Topic branches +[caption="Rule: "] +===================================== +Make a side branch for every topic (feature, bugfix, ...). Fork it off +at the oldest integration branch that you will eventually want to merge it +into. +===================================== + +Many things can then be done very naturally: + +* To get the feature/bugfix into an integration branch, simply merge + it. If the topic has evolved further in the meantime, merge again. + (Note that you do not necessarily have to merge it to the oldest + integration branch first. For example, you can first merge a bugfix + to 'next', give it some testing time, and merge to 'maint' when you + know it is stable.) + +* If you find you need new features from the branch 'other' to continue + working on your topic, merge 'other' to 'topic'. (However, do not + do this "just habitually", see below.) + +* If you find you forked off the wrong branch and want to move it + "back in time", use linkgit:git-rebase[1]. + +Note that the last point clashes with the other two: a topic that has +been merged elsewhere should not be rebased. See the section on +RECOVERING FROM UPSTREAM REBASE in linkgit:git-rebase[1]. + +We should point out that "habitually" (regularly for no real reason) +merging an integration branch into your topics -- and by extension, +merging anything upstream into anything downstream on a regular basis +-- is frowned upon: + +.Merge to downstream only at well-defined points +[caption="Rule: "] +===================================== +Do not merge to downstream except with a good reason: upstream API +changes affect your branch; your branch no longer merges to upstream +cleanly; etc. +===================================== + +Otherwise, the topic that was merged to suddenly contains more than a +single (well-separated) change. The many resulting small merges will +greatly clutter up history. Anyone who later investigates the history +of a file will have to find out whether that merge affected the topic +in development. An upstream might even inadvertently be merged into a +"more stable" branch. And so on. + + +Throw-away integration +~~~~~~~~~~~~~~~~~~~~~~ + +If you followed the last paragraph, you will now have many small topic +branches, and occasionally wonder how they interact. Perhaps the +result of merging them does not even work? But on the other hand, we +want to avoid merging them anywhere "stable" because such merges +cannot easily be undone. + +The solution, of course, is to make a merge that we can undo: merge +into a throw-away branch. + +.Throw-away integration branches +[caption="Rule: "] +===================================== +To test the interaction of several topics, merge them into a +throw-away branch. You must never base any work on such a branch! +===================================== + +If you make it (very) clear that this branch is going to be deleted +right after the testing, you can even publish this branch, for example +to give the testers a chance to work with it, or other developers a +chance to see if their in-progress work will be compatible. `git.git` +has such an official throw-away integration branch called 'pu'. + + +Branch management for a release +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Assuming you are using the merge approach discussed above, when you +are releasing your project you will need to do some additional branch +management work. + +A feature release is created from the 'master' branch, since 'master' +tracks the commits that should go into the next feature release. + +The 'master' branch is supposed to be a superset of 'maint'. If this +condition does not hold, then 'maint' contains some commits that +are not included on 'master'. The fixes represented by those commits +will therefore not be included in your feature release. + +To verify that 'master' is indeed a superset of 'maint', use git log: + +.Verify 'master' is a superset of 'maint' +[caption="Recipe: "] +===================================== +`git log master..maint` +===================================== + +This command should not list any commits. Otherwise, check out +'master' and merge 'maint' into it. + +Now you can proceed with the creation of the feature release. Apply a +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` +===================================== + +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 +release tarballs and preformatted documentation pages. + +Similarly, for a maintenance release, 'maint' is tracking the commits +to be released. Therefore, in the steps above simply tag and push +'maint' rather than 'master'. + + +Maintenance branch management after a feature release +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +After a feature release, you need to manage your maintenance branches. + +First, if you wish to continue to release maintenance fixes for the +feature release made before the recent one, then you must create +another branch to track commits for that previous release. + +To do this, the current maintenance branch is copied to another branch +named with the previous release version number (e.g. maint-X.Y.(Z-1) +where X.Y.Z is the current release). + +.Copy maint +[caption="Recipe: "] +===================================== +`git branch maint-X.Y.(Z-1) maint` +===================================== + +The 'maint' branch should now be fast-forwarded to the newly released +code so that maintenance fixes can be tracked for the current release: + +.Update maint to new release +[caption="Recipe: "] +===================================== +* `git checkout maint` +* `git merge --ff-only master` +===================================== + +If the merge fails because it is not a fast-forward, then it is +possible some fixes on 'maint' were missed in the feature release. +This will not happen if the content of the branches was verified as +described in the previous section. + + +Branch management for next and pu after a feature release +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +After a feature release, the integration branch 'next' may optionally be +rewound and rebuilt from the tip of 'master' using the surviving +topics on 'next': + +.Rewind and rebuild next +[caption="Recipe: "] +===================================== +* `git checkout next` +* `git reset --hard master` +* `git merge ai/topic_in_next1` +* `git merge ai/topic_in_next2` +* ... +===================================== + +The advantage of doing this is that the history of 'next' will be +clean. For example, some topics merged into 'next' may have initially +looked promising, but were later found to be undesirable or premature. +In such a case, the topic is reverted out of 'next' but the fact +remains in the history that it was once merged and reverted. By +recreating 'next', you give another incarnation of such topics a clean +slate to retry, and a feature release is a good point in history to do +so. + +If you do this, then you should make a public announcement indicating +that 'next' was rewound and rebuilt. + +The same rewind and rebuild process may be followed for 'pu'. A public +announcement is not necessary since 'pu' is a throw-away branch, as +described above. + + +DISTRIBUTED WORKFLOWS +--------------------- + +After the last section, you should know how to manage topics. In +general, you will not be the only person working on the project, so +you will have to share your work. + +Roughly speaking, there are two important workflows: merge and patch. +The important difference is that the merge workflow can propagate full +history, including merges, while patches cannot. Both workflows can +be used in parallel: in `git.git`, only subsystem maintainers use +the merge workflow, while everyone else sends patches. + +Note that the maintainer(s) may impose restrictions, such as +"Signed-off-by" requirements, that all commits/patches submitted for +inclusion must adhere to. Consult your project's documentation for +more information. + + +Merge workflow +~~~~~~~~~~~~~~ + +The merge workflow works by copying branches between upstream and +downstream. Upstream can merge contributions into the official +history; downstream base their work on the official history. + +There are three main tools that can be used for this: + +* linkgit:git-push[1] copies your branches to a remote repository, + usually to one that can be read by all involved parties; + +* linkgit:git-fetch[1] that copies remote branches to your repository; + and + +* linkgit:git-pull[1] that does fetch and merge in one go. + +Note the last point. Do 'not' use 'git-pull' unless you actually want +to merge the remote branch. + +Getting changes out is easy: + +.Push/pull: Publishing branches/topics +[caption="Recipe: "] +===================================== +`git push <remote> <branch>` and tell everyone where they can fetch +from. +===================================== + +You will still have to tell people by other means, such as mail. (Git +provides the linkgit:git-request-pull[1] to send preformatted pull +requests to upstream maintainers to simplify this task.) + +If you just want to get the newest copies of the integration branches, +staying up to date is easy too: + +.Push/pull: Staying up to date +[caption="Recipe: "] +===================================== +Use `git fetch <remote>` or `git remote update` to stay up to date. +===================================== + +Then simply fork your topic branches from the stable remotes as +explained earlier. + +If you are a maintainer and would like to merge other people's topic +branches to the integration branches, they will typically send a +request to do so by mail. Such a request looks like + +------------------------------------- +Please pull from + <url> <branch> +------------------------------------- + +In that case, 'git-pull' can do the fetch and merge in one go, as +follows. + +.Push/pull: Merging remote topics +[caption="Recipe: "] +===================================== +`git pull <url> <branch>` +===================================== + +Occasionally, the maintainer may get merge conflicts when he tries to +pull changes from downstream. In this case, he can ask downstream to +do the merge and resolve the conflicts themselves (perhaps they will +know better how to resolve them). It is one of the rare cases where +downstream 'should' merge from upstream. + + +Patch workflow +~~~~~~~~~~~~~~ + +If you are a contributor that sends changes upstream in the form of +emails, you should use topic branches as usual (see above). Then use +linkgit:git-format-patch[1] to generate the corresponding emails +(highly recommended over manually formatting them because it makes the +maintainer's life easier). + +.format-patch/am: Publishing branches/topics +[caption="Recipe: "] +===================================== +* `git format-patch -M upstream..topic` to turn them into preformatted + patch files +* `git send-email --to=<recipient> <patches>` +===================================== + +See the linkgit:git-format-patch[1] and linkgit:git-send-email[1] +manpages for further usage notes. + +If the maintainer tells you that your patch no longer applies to the +current upstream, you will have to rebase your topic (you cannot use a +merge because you cannot format-patch merges): + +.format-patch/am: Keeping topics up to date +[caption="Recipe: "] +===================================== +`git pull --rebase <url> <branch>` +===================================== + +You can then fix the conflicts during the rebase. Presumably you have +not published your topic other than by mail, so rebasing it is not a +problem. + +If you receive such a patch series (as maintainer, or perhaps as a +reader of the mailing list it was sent to), save the mails to files, +create a new topic branch and use 'git-am' to import the commits: + +.format-patch/am: Importing patches +[caption="Recipe: "] +===================================== +`git am < patch` +===================================== + +One feature worth pointing out is the three-way merge, which can help +if you get conflicts: `git am -3` will use index information contained +in patches to figure out the merge base. See linkgit:git-am[1] for +other options. + + +SEE ALSO +-------- +linkgit:gittutorial[7], +linkgit:git-push[1], +linkgit:git-pull[1], +linkgit:git-merge[1], +linkgit:git-rebase[1], +linkgit:git-format-patch[1], +linkgit:git-send-email[1], +linkgit:git-am[1] + +GIT +--- +Part of the linkgit:git[1] suite. diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt new file mode 100644 index 0000000000..1f029f8aa0 --- /dev/null +++ b/Documentation/glossary-content.txt @@ -0,0 +1,461 @@ +[[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". + +[[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` + administrative and control files that would normally be present in the + hidden `.git` sub-directory are directly present in the + `repository.git` directory instead, + and no other files are present and checked out. Usually publishers of + public repositories make bare repositories available. + +[[def_blob_object]]blob object:: + Untyped <<def_object,object>>, e.g. the contents of a file. + +[[def_branch]]branch:: + A "branch" is an active line of development. The most recent + <<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 + <<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" + branch), and <<def_HEAD,HEAD>> points to that branch. + +[[def_cache]]cache:: + Obsolete for: <<def_index,index>>. + +[[def_chain]]chain:: + A list of objects, where each <<def_object,object>> in the list contains + a reference to its successor (for example, the successor of a + <<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 + store changes, but states, it really does not make sense to use the term + "changesets" with git. + +[[def_checkout]]checkout:: + The action of updating all or part of the + <<def_working_tree,working tree>> with a <<def_tree_object,tree object>> + or <<def_blob_object,blob>> from the + <<def_object_database,object database>>, and updating the + <<def_index,index>> and <<def_HEAD,HEAD>> if the whole working tree has + been pointed at a new <<def_branch,branch>>. + +[[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 + 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. + +[[def_clean]]clean:: + A <<def_working_tree,working tree>> is clean, if it + corresponds to the <<def_revision,revision>> referenced by the current + <<def_head,head>>. Also see "<<def_dirty,dirty>>". + +[[def_commit]]commit:: + As a noun: A single point in the + 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 + 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 of the <<def_index,index>> and advancing <<def_HEAD,HEAD>> +to point at the new commit. + +[[def_commit_object]]commit object:: + An <<def_object,object>> which contains the information about a + particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer, + author, date and the <<def_tree_object,tree object>> which corresponds + 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 + source code management tools. + +[[def_DAG]]DAG:: + Directed acyclic graph. The <<def_commit_object,commit objects>> form a + directed acyclic graph, because they have parents (directed), and the + graph of commit objects is acyclic (there is no <<def_chain,chain>> + which begins and ends with the same <<def_object,object>>). + +[[def_dangling_object]]dangling object:: + An <<def_unreachable_object,unreachable object>> which is not + <<def_reachable,reachable>> even from other unreachable objects; a + dangling object has no references to it from any + reference or <<def_object,object>> in the <<def_repository,repository>>. + +[[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_directory]]directory:: + The list you get with "ls" :-) + +[[def_dirty]]dirty:: + A <<def_working_tree,working tree>> is said to be "dirty" if + 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>>. + +[[def_fast_forward]]fast-forward:: + A fast-forward is a special type of <<def_merge,merge>> where you have a + <<def_revision,revision>> and you are "merging" another + <<def_branch,branch>>'s changes that happen to be a descendant of what + you have. In such these cases, you do not make a new <<def_merge,merge>> + <<def_commit,commit>> but instead just update to his + revision. This will happen frequently on a + <<def_tracking_branch,tracking branch>> of a remote + <<def_repository,repository>>. + +[[def_fetch]]fetch:: + Fetching a <<def_branch,branch>> means to get the + branch's <<def_head_ref,head ref>> from a remote + <<def_repository,repository>>, to find out which objects are + missing from the local <<def_object_database,object database>>, + 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, + i.e. the infrastructure to hold files and directories. That ensured the + efficiency and speed of git. + +[[def_git_archive]]git archive:: + Synonym for <<def_repository,repository>> (for arch people). + +[[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 + is different from what was recorded when the commit was + created. Configured via the `.git/info/grafts` file. + +[[def_hash]]hash:: + In git's context, synonym to <<def_object_name,object name>>. + +[[def_head]]head:: + A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a + <<def_branch,branch>>. Heads are stored in + `$GIT_DIR/refs/heads/`, except when using packed refs. (See + linkgit:git-pack-refs[1].) + +[[def_HEAD]]HEAD:: + The current <<def_branch,branch>>. In more detail: Your <<def_working_tree, + working tree>> is normally derived from the state of the tree + referred to by HEAD. HEAD is a reference to one of the + <<def_head,heads>> in your repository, except when using a + <<def_detached_HEAD,detached HEAD>>, in which case it may + reference an arbitrary commit. + +[[def_head_ref]]head ref:: + A synonym for <<def_head,head>>. + +[[def_hook]]hook:: + 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. + +[[def_index]]index:: + A collection of files with stat information, whose contents are stored + as objects. The index is a stored version of your + <<def_working_tree,working tree>>. Truth be told, it can also contain a second, and even + a third version of a working tree, which are used + when <<def_merge,merging>>. + +[[def_index_entry]]index entry:: + The information regarding a particular file, stored in the + <<def_index,index>>. An index entry can be unmerged, if a + <<def_merge,merge>> was started, but not yet finished (i.e. if + the index contains multiple versions of that file). + +[[def_master]]master:: + The default development <<def_branch,branch>>. Whenever you + 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. + +[[def_merge]]merge:: + As a verb: To bring the contents of another + <<def_branch,branch>> (possibly from an external + <<def_repository,repository>>) into the current branch. In the + case where the merged-in branch is from a different repository, + this is done by first <<def_fetch,fetching>> the remote branch + and then merging the result into the current branch. This + combination of fetch and merge operations is called a + <<def_pull,pull>>. Merging is performed by an automatic process + that identifies changes made since the branches diverged, and + then applies all those changes together. In cases where changes + conflict, manual intervention may be required to complete the + merge. ++ +As a noun: unless it is a <<def_fast_forward,fast-forward>>, a +successful merge results in the creation of a new <<def_commit,commit>> +representing the result of the merge, and having as +<<def_parent,parents>> the tips of the merged <<def_branch,branches>>. +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 + object can not be changed. + +[[def_object_database]]object database:: + Stores a set of "objects", and an individual <<def_object,object>> is + identified by its <<def_object_name,object name>>. The objects usually + live in `$GIT_DIR/objects/`. + +[[def_object_identifier]]object identifier:: + 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. + +[[def_object_type]]object type:: + One of the identifiers "<<def_commit_object,commit>>", + "<<def_tree_object,tree>>", "<<def_tag_object,tag>>" or + "<<def_blob_object,blob>>" describing the type of an + <<def_object,object>>. + +[[def_octopus]]octopus:: + To <<def_merge,merge>> more than two <<def_branch,branches>>. Also denotes an + intelligent predator. + +[[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_tracking_branch,tracking branches>> named + origin/name-of-upstream-branch, which you can see using + `git branch -r`. + +[[def_pack]]pack:: + A set of objects which have been compressed into one file (to save space + or to transmit them efficiently). + +[[def_pack_index]]pack index:: + The list of identifiers, and other information, of the objects in a + <<def_pack,pack>>, to assist in efficiently accessing the contents of a + pack. + +[[def_parent]]parent:: + A <<def_commit_object,commit object>> contains a (possibly empty) list + of the logical predecessor(s) in the line of development, i.e. its + parents. + +[[def_pickaxe]]pickaxe:: + The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore + routines that help select changes that add or delete a given text + string. With the `--pickaxe-all` option, it can be used to view the full + <<def_changeset,changeset>> that introduced or removed, say, a + particular line of text. See linkgit:git-diff[1]. + +[[def_plumbing]]plumbing:: + 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>> + interface than the <<def_plumbing,plumbing>>. + +[[def_pull]]pull:: + Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and + <<def_merge,merge>> it. See also linkgit:git-pull[1]. + +[[def_push]]push:: + Pushing a <<def_branch,branch>> means to get the branch's + <<def_head_ref,head ref>> from a remote <<def_repository,repository>>, + find out if it is a direct ancestor to the branch's local + head ref, and in that case, putting all + objects, which are <<def_reachable,reachable>> from the local + head ref, and which are missing from the remote + repository, into the remote + <<def_object_database,object database>>, and updating the remote + head ref. If the remote <<def_head,head>> is not an + ancestor to the local head, the push fails. + +[[def_reachable]]reachable:: + All of the ancestors of a given <<def_commit,commit>> are said to be + "reachable" from that commit. More + generally, one <<def_object,object>> is reachable from + another if we can reach the one from the other by a <<def_chain,chain>> + that follows <<def_tag,tags>> to whatever they tag, + <<def_commit_object,commits>> to their parents or trees, and + <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>> + that they contain. + +[[def_rebase]]rebase:: + To reapply a series of changes from a <<def_branch,branch>> to a + different base, and reset the <<def_head,head>> of that branch + 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>>. These may be stored in + `$GIT_DIR/refs/`. + +[[def_reflog]]reflog:: + A reflog shows the local "history" of a ref. In other words, + it can tell you what the 3rd last revision in _this_ repository + was, and what was the current state in _this_ repository, + yesterday 9:14pm. See linkgit:git-reflog[1] for details. + +[[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_repository]]repository:: + A collection of <<def_ref,refs>> together with an + <<def_object_database,object database>> containing all objects + which are <<def_reachable,reachable>> from the refs, possibly + accompanied by meta data from one or more <<def_porcelain,porcelains>>. A + repository can share an object database with other repositories + via <<def_alternate_object_database,alternates mechanism>>. + +[[def_resolve]]resolve:: + The action of fixing up manually what a failed automatic + <<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>>. + +[[def_rewind]]rewind:: + To throw away part of the development, i.e. to assign the + <<def_head,head>> to an earlier <<def_revision,revision>>. + +[[def_SCM]]SCM:: + Source code management (tool). + +[[def_SHA1]]SHA1:: + 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 + 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 + upstream is much larger. A shallow repository + is created by giving the `--depth` option to linkgit:git-clone[1], and + its history can be later deepened with linkgit:git-fetch[1]. + +[[def_symref]]symref:: + Symbolic reference: instead of containing the <<def_SHA1,SHA1>> + 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 + references are manipulated with the linkgit:git-symbolic-ref[1] + command. + +[[def_tag]]tag:: + A <<def_ref,ref>> pointing to a <<def_tag_object,tag>> or + <<def_commit_object,commit object>>. In contrast to a <<def_head,head>>, + a tag is not changed by a <<def_commit,commit>>. Tags (not + <<def_tag_object,tag objects>>) are stored in `$GIT_DIR/refs/tags/`. 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 point in the + commit ancestry <<def_chain,chain>>. + +[[def_tag_object]]tag object:: + An <<def_object,object>> containing a <<def_ref,ref>> pointing to + another object, which can contain a message just like a + <<def_commit_object,commit object>>. It can also contain a (PGP) + 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 + 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 + related changes. + +[[def_tracking_branch]]tracking branch:: + A regular git <<def_branch,branch>> that is used to follow changes from + another <<def_repository,repository>>. A tracking + branch should not contain direct modifications or have local commits + made to it. A tracking branch can usually be + identified as the right-hand-side <<def_ref,ref>> in a Pull: + <<def_refspec,refspec>>. + +[[def_tree]]tree:: + Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree + object>> together with the dependent <<def_blob_object,blob>> and tree objects + (i.e. a stored representation of a working tree). + +[[def_tree_object]]tree object:: + An <<def_object,object>> containing a list of file names and modes along + 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_unmerged_index]]unmerged index:: + An <<def_index,index>> which contains unmerged + <<def_index_entry,index entries>>. + +[[def_unreachable_object]]unreachable object:: + An <<def_object,object>> which is not <<def_reachable,reachable>> from a + <<def_branch,branch>>, <<def_tag,tag>>, or any other reference. + +[[def_upstream_branch]]upstream branch:: + The default <<def_branch,branch>> that is merged into the branch in + question (or the branch in question is rebased onto). It is configured + via branch.<name>.remote and branch.<name>.merge. If the upstream branch + of 'A' is 'origin/B' sometimes we say "'A' is tracking 'origin/B'". + +[[def_working_tree]]working tree:: + The tree of actual checked out files. The working tree normally + contains the contents of the <<def_HEAD,HEAD>> commit's tree, + plus any local changes that you have made but not yet committed. diff --git a/Documentation/howto-index.sh b/Documentation/howto-index.sh new file mode 100755 index 0000000000..34aa30c5b9 --- /dev/null +++ b/Documentation/howto-index.sh @@ -0,0 +1,56 @@ +#!/bin/sh + +cat <<\EOF +GIT Howto Index +=============== + +Here is a collection of mailing list postings made by various +people describing how they use git in their workflow. + +EOF + +for txt +do + title=`expr "$txt" : '.*/\(.*\)\.txt$'` + from=`sed -ne ' + /^$/q + /^From:[ ]/{ + s/// + s/^[ ]*// + s/[ ]*$// + s/^/by / + p + } + ' "$txt"` + + abstract=`sed -ne ' + /^Abstract:[ ]/{ + s/^[^ ]*// + x + s/.*// + x + : again + /^[ ]/{ + s/^[ ]*// + H + n + b again + } + x + p + q + }' "$txt"` + + if grep 'Content-type: text/asciidoc' >/dev/null $txt + then + file=`expr "$txt" : '\(.*\)\.txt$'`.html + else + file="$txt" + fi + + echo "* link:$file[$title] $from +$abstract + +" + +done diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt new file mode 100644 index 0000000000..d527b30770 --- /dev/null +++ b/Documentation/howto/maintain-git.txt @@ -0,0 +1,277 @@ +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 + 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. + +The maintainer's git time is spent on three activities. + + - Communication (60%) + + Mailing list discussions on general design, fielding user + questions, diagnosing bug reports; reviewing, commenting on, + suggesting alternatives to, and rejecting patches. + + - Integration (30%) + + 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%) + + Scratching my own itch and sending proposed patch series out. + +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 + 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). + + - '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. + + - 'maint' branch is used to prepare for the next maintenance + release. After the feature release vX.Y.Z 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. + + - 'next' branch is used to publish changes (both enhancements + and fixes) that (1) have worthwhile goal, (2) are in a fairly + good shape suitable for everyday use, (3) but have not yet + demonstrated to be regression free. New changes are tested + in 'next' before merged to 'master'. + + - '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. + + - Usually 'master' contains all of 'maint', 'next' contains all + of 'master' and 'pu' contains all of 'next'. + + - The tip of 'master' is meant to be more stable than any + tagged releases, and the users are encouraged to follow it. + + - The 'next' branch is where new action takes place, and the + users are encouraged to test it so that regressions and bugs + are found before new topics are merged to 'master'. + + +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). + + - Review the patches in the saved mailboxes. Edit proposed log + message for typofixes and clarifications, and add Acks + collected from the list. Edit patch to incorporate "Oops, + that should have been like this" fixes from the discussion. + + - Classify the collected patches and handle 'master' and + 'maint' updates: + + - Obviously correct fixes that pertain to the tip of 'maint' + are directly applied to 'maint'. + + - Obviously correct fixes that pertain to the tip of 'master' + are directly applied to 'master'. + + This step is done with "git am". + + $ git checkout master ;# or "git checkout maint" + $ git am -3 -s mailbox + $ make test + + - Merge downwards (maint->master): + + $ git checkout master + $ git merge maint + $ make test + + - Review the last issue of "What's cooking" message, review the + topics scheduled for merging upwards (topic->master and + topic->maint), and merge. + + $ git checkout master ;# or "git checkout maint" + $ git merge ai/topic ;# or "git merge ai/maint-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: + + - Anything unobvious that is applicable to 'master' (in other + words, does not depend on anything that is still in 'next' + 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"). + + - An unobvious fix meant for 'maint' is applied to a new + topic branch that is forked from the tip of 'maint'. The + topic is named as ai/maint-topic. + + - Changes that pertain to an existing topic are applied to + the branch, but: + + - obviously correct ones are applied first; + + - questionable ones are discarded or applied to near the tip; + + - Replacement patches to an existing topic are accepted only + for commits not in 'next'. + + The above except the "replacement" are all done with: + + $ git am -3 -s mailbox + + while patch replacement is often done by: + + $ git format-patch ai/topic~$n..ai/topic ;# export existing + + then replace some parts with the new patch, and reapplying: + + $ git reset --hard ai/topic~$n + $ git am -3 -s 000*.txt + + The full test suite is always run for 'maint' and 'master' + after patch application; for topic branches the tests are run + as time permits. + + - Update "What's cooking" message to review the updates to + existing topics, newly added topics and graduated topics. + + This step is helped with Meta/UWC script (where Meta/ contains + a checkout of the 'todo' branch). + + - Merge 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: + + $ git checkout next + $ git merge ai/topic ;# or "git merge ai/maint-topic" + $ make test + + - The new parts are of mixed quality, but earlier ones are + next-worthy; merge the early parts to next: + + $ git checkout next + $ git merge ai/topic~2 ;# the tip two are dubious + $ make test + + - Nothing is next-worthy; do not do anything. + + - Rebase topics that do not have any commit in next yet. This + step is optional but sometimes is worth doing when an old + series that is not in next can take advantage of low-level + framework change that is merged to 'master' already. + + $ git rebase master ai/topic + + 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. + + - Rebuild "pu" to merge the tips of topics not in 'next'. + + $ git checkout pu + $ git reset --hard next + $ git merge ai/topic ;# repeat for all remaining topics + $ make test + + This step is helped with Meta/PU script + + - Push four integration branches to a private repository at + k.org and run "make test" on all of them. + + - Push four integration branches to /pub/scm/git/git.git at + k.org. This triggers its post-update hook which: + + (1) runs "git pull" in $HOME/git-doc/ repository to pull + 'master' just pushed out; + + (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. + + (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. + + (4) installs generated documentation to /pub/software/scm/git/docs/ + to be viewed from http://www.kernel.org/ + + - Fetch html and man branches back from k.org, and push four + integration branches and the two documentation branches to + repo.or.cz + + +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'. + + * 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. + + * An unobvious fix for 'maint' is cooked in 'next' and then + merged to 'master' to make extra sure it is Ok and then + merged to 'maint'. + + * Even when 'next' becomes empty (in other words, all topics + prove stable and are merged to 'master' and "git diff master + next" shows empty), it has tons of merge commits that will + never be in 'master'. + + * In principle, "git log --first-parent master..next" should + show nothing but merges (in practice, there are fixup commits + and reverts that are not merges). + + * Commits near the tip of a topic branch that are not in 'next' + are fair game to be discarded, replaced or rewritten. + Commits already merged to 'next' will not be. + + * 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. diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt new file mode 100644 index 0000000000..74a1c0c4ba --- /dev/null +++ b/Documentation/howto/rebase-from-internal-branch.txt @@ -0,0 +1,163 @@ +From: Junio C Hamano <gitster@pobox.com> +To: git@vger.kernel.org +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 + the "master" branch, and how "rebase" works. Also discussed + is how this applies to individual developers who sends patches + upstream. + +Petr Baudis <pasky@suse.cz> writes: + +> Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter +> where Junio C Hamano <junkio@cox.net> told me that... +>> Linus Torvalds <torvalds@osdl.org> writes: +>> +>> > Junio, maybe you want to talk about how you move patches from your "pu" +>> > 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. + +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 +placing new things in pu first. At the beginning, the commit +ancestry graph looked like this: + + *"pu" head + master --> #1 --> #2 --> #3 + +So I started from master, made a bunch of edits, and committed: + + $ git checkout master + $ cd Documentation; ed git.txt ... + $ cd ..; git add Documentation/*.txt + $ git commit -s + +After the commit, the ancestry graph would look like this: + + *"pu" head + master^ --> #1 --> #2 --> #3 + \ + \---> master + +The old master is now master^ (the first parent of the master). +The new master commit holds my documentation updates. + +Now I have to deal with "pu" branch. + +This is the kind of situation I used to have all the time when +Linus was the maintainer and I was a contributor, when you look +at "master" branch being the "maintainer" branch, and "pu" +branch being the "contributor" branch. Your work started at the +tip of the "maintainer" branch some time ago, you made a lot of +progress in the meantime, and now the maintainer branch has some +other commits you do not have yet. And "git rebase" was written +with the explicit purpose of helping to maintain branches like +"pu". You _could_ merge master to pu and keep going, but if you +eventually want to cherrypick and merge some but not necessarily +all changes back to the master branch, it often makes later +operations for _you_ easier if you rebase (i.e. carry forward +your changes) "pu" rather than merge. So I ran "git rebase": + + $ git checkout pu + $ git rebase master pu + +What this does is to pick all the commits since the current +branch (note that I now am on "pu" branch) forked from the +master branch, and forward port these changes. + + master^ --> #1 --> #2 --> #3 + \ *"pu" head + \---> master --> #1' --> #2' --> #3' + +The diff between master^ and #1 is applied to master and +committed to create #1' commit with the commit information (log, +author and date) taken from commit #1. On top of that #2' and #3' +commits are made similarly out of #2 and #3 commits. + +Old #3 is not recorded in any of the .git/refs/heads/ file +anymore, so after doing this you will have dangling commit if +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. + +Let's go back to the earlier picture, with different labels. + +You, as an individual developer, cloned upstream repository and +made a couple of commits on top of it. + + *your "master" head + upstream --> #1 --> #2 --> #3 + +You would want changes #2 and #3 incorporated in the upstream, +while you feel that #1 may need further improvements. So you +prepare #2 and #3 for e-mail submission. + + $ git format-patch master^^ master + +This creates two files, 0001-XXXX.patch and 0002-XXXX.patch. Send +them out "To: " your project maintainer and "Cc: " your mailing +list. You could use contributed script git-send-email if +your host has necessary perl modules for this, but your usual +MUA would do as long as it does not corrupt whitespaces in the +patch. + +Then you would wait, and you find out that the upstream picked +up your changes, along with other changes. + + where *your "master" head + upstream --> #1 --> #2 --> #3 + used \ + to be \--> #A --> #2' --> #3' --> #B --> #C + *upstream head + +The two commits #2' and #3' in the above picture record the same +changes your e-mail submission for #2 and #3 contained, but +probably with the new sign-off line added by the upstream +maintainer and definitely with different committer and ancestry +information, they are different objects from #2 and #3 commits. + +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. +You run "git rebase" now. + + $ git rebase FETCH_HEAD master + +Earlier, I said that rebase applies all the commits from your +branch on top of the upstream head. Well, I lied. "git rebase" +is a bit smarter than that and notices that #2 and #3 need not +be applied, so it only applies #1. The commit ancestry graph +becomes something like this: + + where *your old "master" head + upstream --> #1 --> #2 --> #3 + used \ your new "master" head* + to be \--> #A --> #2' --> #3' --> #B --> #C --> #1' + *upstream + head + +Again, "git prune" would discard the disused commits #1-#3 and +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 new file mode 100644 index 0000000000..48c67568d3 --- /dev/null +++ b/Documentation/howto/rebuild-from-update-hook.txt @@ -0,0 +1,86 @@ +Subject: [HOWTO] Using post-update hook +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 + shown at http://www.kernel.org/pub/software/scm/git/docs/. + +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. + +The directories relevant to this how-to are these two: + + /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 +home directory over there. + + $ cd + $ mkdir doc-git && cd doc-git + $ git clone /pub/scm/git/git.git/ docgen + +What needs to happen is to update the $HOME/doc-git/docgen/ +working tree, build HTML docs there and install the result in +/pub/software/scm/git/docs/ directory. So I wrote a little +script: + + $ cat >dododoc.sh <<\EOF + #!/bin/sh + cd $HOME/doc-git/docgen || exit + + unset GIT_DIR + + git pull /pub/scm/git/git.git/ master && + cd Documentation && + make install-webdoc + 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 +day. The current round uses the post-update hook mechanism, +like this: + + $ cat >/pub/scm/git/git.git/hooks/post-update <<\EOF + #!/bin/sh + # + # An example hook script to prepare a packed repository for use over + # dumb transports. + # + # To enable this hook, make this file executable by "chmod +x post-update". + + case " $* " in + *' refs/heads/master '*) + echo $HOME/doc-git/dododoc.sh | at now + ;; + esac + exec git-update-server-info + EOF + $ chmod +x /pub/scm/git/git.git/hooks/post-update + +There are four things worth mentioning: + + - The update-hook is run after the repository accepts a "git + push", under my user privilege. It is given the full names + of refs that have been updated as arguments. My post-update + runs the dododoc.sh script only when the master head is + updated. + + - When update-hook is run, GIT_DIR is set to '.' by the calling + receive-pack. This is inherited by the dododoc.sh run via + the "at" command, and needs to be unset; otherwise, "git + pull" it does into $HOME/doc-git/docgen/ repository would not + work correctly. + + - The stdout of update hook script is not connected to git + push; I run the heavy part of the command inside "at", to + receive the execution report via e-mail. + + - This is still crude and does not protect against simultaneous + make invocations stomping on each other. I would need to add + some locking mechanism for this. diff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt new file mode 100644 index 0000000000..323b513ed0 --- /dev/null +++ b/Documentation/howto/recover-corrupted-blob-object.txt @@ -0,0 +1,134 @@ +Date: Fri, 9 Nov 2007 08:28:38 -0800 (PST) +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. + +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 +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 +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). + +But since you don't seem to have backups right now, the good news is that +especially with a single blob being corrupt, these things *are* somewhat +debuggable. + +First off, move the corrupt object away, and *save* it. The most common +cause of corruption so far has been memory corruption, but even so, there +are people who would be interested in seeing the corruption - but it's +basically impossible to judge the corruption until we can also see the +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 ;). + +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 +at all interesting. But what remains is still very useful. In particular, +we now know which tree points to it! + +Now you can do + + git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 + +which will show something like + + 100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8 .gitignore + 100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883 .mailmap + 100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c COPYING + 100644 blob ee909f2cc49e54f0799a4739d24c4cb9151ae453 CREDITS + 040000 tree 0f5f709c17ad89e72bdbbef6ea221c69807009f6 Documentation + 100644 blob 1570d248ad9237e4fa6e4d079336b9da62d9ba32 Kbuild + 100644 blob 1c7c229a092665b11cd46a25dbd40feeb31661d9 MAINTAINERS + ... + +and you should now have a line that looks like + + 10064 blob 4b9458b3786228369c63936db65827de3cc06200 my-magic-file + +in the output. This already tells you a *lot* it tells you what file the +corrupt blob came from! + +Now, it doesn't tell you quite enough, though: it doesn't tell what +*version* of the file didn't get correctly written! You might be really +lucky, and it may be the version that you already have checked out in your +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! + +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? + +The easiest way to do it is to do + + git log --raw --all --full-history -- subdirectory/my-magic-file + +and that will show you the whole log for that file (please realize that +the tree you had may not be the top-level tree, so you need to figure out +which subdirectory it was in on your own), and because you're asking for +raw output, you'll now get something like + + commit abc + Author: + Date: + .. + :100644 100644 4b9458b... newsha... M somedirectory/my-magic-file + + + commit xyz + Author: + Date: + + .. + :100644 100644 oldsha... 4b9458b... M somedirectory/my-magic-file + +and this actually tells you what the *previous* and *subsequent* versions +of that file were! So now you can look at those ("oldsha" and "newsha" +respectively), and hopefully you have done commits often, and can +re-create the missing my-magic-file version by looking at those older and +newer versions! + +If you can do that, you can now recreate the missing object with + + git hash-object -w <recreated-file> + +and your repository is good again! + +(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 +just missing one particular blob version. + +Trying to recreate trees and especially commits is *much* harder. So you +were lucky that it's a blob. It's quite possible that you can recreate the +thing. + + Linus diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt new file mode 100644 index 0000000000..3b4a390005 --- /dev/null +++ b/Documentation/howto/revert-a-faulty-merge.txt @@ -0,0 +1,179 @@ +Date: Fri, 19 Dec 2008 00:45:19 -0800 +From: Linus Torvalds <torvalds@linux-foundation.org>, Junio C Hamano <gitster@pobox.com> +Subject: Re: Odd merge behaviour involving reverts +Abstract: Sometimes a branch that was already merged to the mainline + is later found to be faulty. Linus and Junio give guidance on + recovering from such a premature merge and continuing development + after the offending branch is fixed. +Message-ID: <7vocz8a6zk.fsf@gitster.siamese.dyndns.org> +References: <alpine.LFD.2.00.0812181949450.14014@localhost.localdomain> + +Alan <alan@clueserver.org> said: + + I have a master branch. We have a branch off of that that some + developers are doing work on. They claim it is ready. We merge it + into the master branch. It breaks something so we revert the merge. + They make changes to the code. they get it to a point where they say + it is ok and we merge again. + + When examined, we find that code changes made before the revert are + not in the master branch, but code changes after are in the master + branch. + +and asked for help recovering from this situation. + +The history immediately after the "revert of the merge" would look like +this: + + ---o---o---o---M---x---x---W + / + ---A---B + +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". + +Such a "revert" of a merge can be made with: + + $ git revert -m 1 M + +After the developers of the side branch fix their mistakes, the history +may look like this: + + ---o---o---o---M---x---x---W---x + / + ---A---B-------------------C---D + +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 +by W. That is what Alan saw. + +Linus explains the situation: + + Reverting a regular commit just effectively undoes what that commit + did, and is fairly straightforward. But reverting a merge commit also + undoes the _data_ that the commit changed, but it does absolutely + nothing to the effects on _history_ that the merge had. + + So the merge will still exist, and it will still be seen as joining + the two branches together, and future merges will see that merge as + the last shared state - and the revert that reverted the merge brought + in will not affect that at all. + + So a "revert" undoes the data changes, but it's very much _not_ an + "undo" in the sense that it doesn't undo the effects of a commit on + the repository history. + + So if you think of "revert" as "undo", then you're going to always + miss this part of reverts. Yes, it undoes the data, but no, it doesn't + undo history. + +In such a situation, you would want to first revert the previous revert, +which would make the history look like this: + + ---o---o---o---M---x---x---W---x---Y + / + ---A---B-------------------C---D + +where Y is the revert of W. Such a "revert of the revert" can be done +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: + + ---o---o---o---M---x---x-------x---- + / + ---A---B-------------------C---D + +and merging the side branch again will not have conflict arising from an +earlier revert and revert of the revert. + + ---o---o---o---M---x---x-------x-------* + / / + ---A---B-------------------C---D + +Of course the changes made in C and D still can conflict with what was +done by any of the x, but that is just a normal merge conflict. + +On the other hand, if the developers of the side branch discarded their +faulty A and B, and redone the changes on top of the updated mainline +after the revert, the history would have looked like this: + + ---o---o---o---M---x---x---W---x---x + / \ + ---A---B A'--B'--C' + +If you reverted the revert in such a case as in the previous example: + + ---o---o---o---M---x---x---W---x---x---Y---* + / \ / + ---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, +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.. + + ---o---o---o---M---x---x---W---x---x + / \ + ---A---B A'--B'--C' + +In the history with rebased side branch, W (and M) are behind the merge +base of the updated branch and the tip of the mainline, and they should +merge without the past faulty merge and its revert getting in the way. + +To recap, these are two very different scenarios, and they want two very +different resolution strategies: + + - If the faulty side branch was fixed by adding corrections on top, then + doing a revert of the previous revert would be the right thing to do. + + - If the faulty side branch whose effects were discarded by an earlier + revert of a merge was rebuilt from scratch (i.e. rebasing and fixing, + as you seem to have interpreted), then re-merging the result without + doing anything else fancy would be the right thing to do. + +However, there are things to keep in mind when reverting a merge (and +reverting such a revert). + +For example, think about what reverting a merge (and then reverting the +revert) does to bisectability. Ignore the fact that the revert of a revert +is undoing it - just think of it as a "single commit that does a lot". +Because that is what it does. + +When you have a problem you are chasing down, and you hit a "revert this +merge", what you're hitting is essentially a single commit that contains +all the changes (but obviously in reverse) of all the commits that got +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 +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. + +So from a technical angle, there's nothing wrong with reverting a merge, +but from a workflow angle it's something that you generally should try to +avoid. + +If at all possible, for example, if you find a problem that got merged +into the main tree, rather than revert the merge, try _really_ hard to +bisect the problem down into the branch you merged, and just fix it, or +try to revert the individual commit that caused it. + +Yes, it's more complex, and no, it's not always going to work (sometimes +the answer is: "oops, I really shouldn't have merged it, because it wasn't +ready yet, and I really need to undo _all_ of the merge"). So then you +really should revert the merge, but when you want to re-do the merge, you +now need to do it by reverting the revert. diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt new file mode 100644 index 0000000000..8c32da6deb --- /dev/null +++ b/Documentation/howto/revert-branch-rebase.txt @@ -0,0 +1,193 @@ +From: Junio C Hamano <gitster@pobox.com> +To: git@vger.kernel.org +Subject: [HOWTO] Reverting an existing commit +Abstract: In this article, JC gives a small real-life example of using + 'git revert' command, and using a temporary branch and tag for safety + and easier sanity checking. +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 +============================ + +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 +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 +barebone Porcelain. + +First, prepare a throw-away branch in case I screw things up. + +------------------------------------------------ +$ git checkout -b revert-c99 master +------------------------------------------------ + +Now I am on the 'revert-c99' branch. Let's figure out which commit to +revert. I happen to know that the top of the 'master' branch is a +merge, and its second parent (i.e. foreign commit I merged from) has +the change I would want to undo. Further I happen to know that that +merge introduced 5 commits or so: + +------------------------------------------------ +$ git show-branch --more=4 master master^2 | head +* [master] Merge refs/heads/portable from http://www.cs.berkeley.... + ! [master^2] Replace C99 array initializers with code. +-- +- [master] Merge refs/heads/portable from http://www.cs.berkeley.... +*+ [master^2] Replace C99 array initializers with code. +*+ [master^2~1] Replace unsetenv() and setenv() with older putenv(). +*+ [master^2~2] Include sys/time.h in daemon.c. +*+ [master^2~3] Fix ?: statements. +*+ [master^2~4] Replace zero-length array decls with []. +* [master~1] tutorial note about git branch +------------------------------------------------ + +The '--more=4' above means "after we reach the merge base of refs, +show until we display four more common commits". That last commit +would have been where the "portable" branch was forked from the main +git.git repository, so this would show everything on both branches +since then. I just limited the output to the first handful using +'head'. + +Now I know 'master^2~4' (pronounce it as "find the second parent of +the 'master', and then go four generations back following the first +parent") is the one I would want to revert. Since I also want to say +why I am reverting it, the '-n' flag is given to 'git revert'. This +prevents it from actually making a commit, and instead 'git revert' +leaves the commit log message it wanted to use in '.msg' file: + +------------------------------------------------ +$ git revert -n master^2~4 +$ cat .msg +Revert "Replace zero-length array decls with []." + +This reverts 6c5f9baa3bc0d63e141e0afc23110205379905a4 commit. +$ git diff HEAD ;# to make sure what we are reverting makes sense. +$ make CC=gcc-2.95 clean test ;# make sure it fixed the breakage. +$ make clean test ;# make sure it did not cause other breakage. +------------------------------------------------ + +The reverted change makes sense (from reading the 'diff' output), does +fix the problem (from 'make CC=gcc-2.95' test), and does not cause new +breakage (from the last 'make test'). I'm ready to commit: + +------------------------------------------------ +$ git commit -a -s ;# read .msg into the log, + # and explain why I am reverting. +------------------------------------------------ + +I could have screwed up in any of the above steps, but in the worst +case I could just have done 'git checkout master' to start over. +Fortunately I did not have to; what I have in the current branch +'revert-c99' is what I want. So merge that back into 'master': + +------------------------------------------------ +$ git checkout master +$ git merge revert-c99 ;# this should be a fast-forward +Updating from 10d781b9caa4f71495c7b34963bef137216f86a8 to e3a693c... + cache.h | 8 ++++---- + commit.c | 2 +- + ls-files.c | 2 +- + receive-pack.c | 2 +- + server-info.c | 2 +- + 5 files changed, 8 insertions(+), 8 deletions(-) +------------------------------------------------ + +There is no need to redo the test at this point. We fast-forwarded +and we know 'master' matches 'revert-c99' exactly. In fact: + +------------------------------------------------ +$ git diff master..revert-c99 +------------------------------------------------ + +says nothing. + +Then we rebase the 'pu' branch as usual. + +------------------------------------------------ +$ git checkout pu +$ git tag pu-anchor pu +$ git rebase master +* Applying: Redo "revert" using three-way merge machinery. +First trying simple merge strategy to cherry-pick. +Finished one cherry-pick. +* Applying: Remove git-apply-patch-script. +First trying simple merge strategy to cherry-pick. +Simple cherry-pick fails; trying Automatic cherry-pick. +Removing Documentation/git-apply-patch-script.txt +Removing git-apply-patch-script +Finished one cherry-pick. +* Applying: Document "git cherry-pick" and "git revert" +First trying simple merge strategy to cherry-pick. +Finished one cherry-pick. +* Applying: mailinfo and applymbox updates +First trying simple merge strategy to cherry-pick. +Finished one cherry-pick. +* Applying: Show commits in topo order and name all commits. +First trying simple merge strategy to cherry-pick. +Finished one cherry-pick. +* Applying: More documentation updates. +First trying simple merge strategy to cherry-pick. +Finished one cherry-pick. +------------------------------------------------ + +The temporary tag 'pu-anchor' is me just being careful, in case 'git +rebase' screws up. After this, I can do these for sanity check: + +------------------------------------------------ +$ git diff pu-anchor..pu ;# make sure we got the master fix. +$ make CC=gcc-2.95 clean test ;# make sure it fixed the breakage. +$ 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: + +------------------------------------------------ +$ rm -f .git/refs/tags/pu-anchor +$ git branch -d revert-c99 +------------------------------------------------ + +It was an emergency fix, so we might as well merge it into the +'release candidate' branch, although I expect the next release would +be some days off: + +------------------------------------------------ +$ git checkout rc +$ git pull . master +Packing 0 objects +Unpacking 0 objects + +* committish: e3a693c... refs/heads/master from . +Trying to merge e3a693c... into 8c1f5f0... using 10d781b... +Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f + cache.h | 8 ++++---- + commit.c | 2 +- + ls-files.c | 2 +- + receive-pack.c | 2 +- + server-info.c | 2 +- + 5 files changed, 8 insertions(+), 8 deletions(-) +------------------------------------------------ + +And the final repository status looks like this: + +------------------------------------------------ +$ git show-branch --more=1 master pu rc +! [master] Revert "Replace zero-length array decls with []." + ! [pu] git-repack: Add option to repack all objects. + * [rc] Merge refs/heads/master from . +--- + + [pu] git-repack: Add option to repack all objects. + + [pu~1] More documentation updates. + + [pu~2] Show commits in topo order and name all commits. + + [pu~3] mailinfo and applymbox updates + + [pu~4] Document "git cherry-pick" and "git revert" + + [pu~5] Remove git-apply-patch-script. + + [pu~6] Redo "revert" using three-way merge machinery. + - [rc] Merge refs/heads/master from . +++* [master] Revert "Replace zero-length array decls with []." + - [rc~1] Merge refs/heads/master from . +... [master~1] Merge refs/heads/portable from http://www.cs.berkeley.... +------------------------------------------------ diff --git a/Documentation/howto/separating-topic-branches.txt b/Documentation/howto/separating-topic-branches.txt new file mode 100644 index 0000000000..6d3eb8ed00 --- /dev/null +++ b/Documentation/howto/separating-topic-branches.txt @@ -0,0 +1,90 @@ +From: Junio C Hamano <gitster@pobox.com> +Subject: Separating topic branches +Abstract: In this article, JC describes how to separate topic branches. + +This text was originally a footnote to a discussion about the +behaviour of the git diff commands. + +Often I find myself doing that [running diff against something other +than HEAD] while rewriting messy development history. For example, I +start doing some work without knowing exactly where it leads, and end +up with a history like this: + + "master" + o---o + \ "topic" + o---o---o---o---o---o + +At this point, "topic" contains something I know I want, but it +contains two concepts that turned out to be completely independent. +And often, one topic component is larger than the other. It may +contain more than two topics. + +In order to rewrite this mess to be more manageable, I would first do +"diff master..topic", to extract the changes into a single patch, start +picking pieces from it to get logically self-contained units, and +start building on top of "master": + + $ git diff master..topic >P.diff + $ git checkout -b topicA master + ... pick and apply pieces from P.diff to build + ... commits on topicA branch. + + o---o---o + / "topicA" + o---o"master" + \ "topic" + o---o---o---o---o---o + +Before doing each commit on "topicA" HEAD, I run "diff HEAD" +before update-index the affected paths, or "diff --cached HEAD" +after. Also I would run "diff --cached master" to make sure +that the changes are only the ones related to "topicA". Usually +I do this for smaller topics first. + +After that, I'd do the remainder of the original "topic", but +for that, I do not start from the patchfile I extracted by +comparing "master" and "topic" I used initially. Still on +"topicA", I extract "diff topic", and use it to rebuild the +other topic: + + $ git diff -R topic >P.diff ;# --cached also would work fine + $ git checkout -b topicB master + ... pick and apply pieces from P.diff to build + ... commits on topicB branch. + + "topicB" + o---o---o---o---o + / + /o---o---o + |/ "topicA" + o---o"master" + \ "topic" + o---o---o---o---o---o + +After I am done, I'd try a pretend-merge between "topicA" and +"topicB" in order to make sure I have not missed anything: + + $ git pull . topicA ;# merge it into current "topicB" + $ git diff topic + "topicB" + o---o---o---o---o---* (pretend merge) + / / + /o---o---o----------' + |/ "topicA" + o---o"master" + \ "topic" + o---o---o---o---o---o + +The last diff better not to show anything other than cleanups +for crufts. Then I can finally clean things up: + + $ git branch -D topic + $ git reset --hard HEAD^ ;# nuke pretend merge + + "topicB" + o---o---o---o---o + / + /o---o---o + |/ "topicA" + o---o"master" diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt new file mode 100644 index 0000000000..622ee5c8dd --- /dev/null +++ b/Documentation/howto/setup-git-server-over-http.txt @@ -0,0 +1,277 @@ +From: Rutger Nijlunsing <rutger@nospam.com> +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 + +Since Apache is one of those packages people like to compile +themselves while others prefer the bureaucrat's dream Debian, it is +impossible to give guidelines which will work for everyone. Just send +some feedback to the mailing list at git@vger.kernel.org to get this +document tailored to your favorite distro. + + +What's needed: + +- Have an Apache web-server + + On Debian: + $ apt-get install apache2 + To get apache2 by default started, + edit /etc/default/apache2 and set NO_START=0 + +- can edit the configuration of it. + + This could be found under /etc/httpd, or refer to your Apache documentation. + + On Debian: this means being able to edit files under /etc/apache2 + +- can restart it. + + 'apachectl --graceful' might do. If it doesn't, just stop and + restart apache. Be warning that active connections to your server + might be aborted by this. + + On Debian: + $ /etc/init.d/apache2 restart + or + $ /etc/init.d/apache2 force-reload + (which seems to do the same) + This adds symlinks from the /etc/apache2/mods-enabled to + /etc/apache2/mods-available. + +- have permissions to chown a directory + +- have git installed on the client, and + +- 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 +----------------------------------- + +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). + +Create the directory under the DocumentRoot of the directories served +by Apache. As an example we take /usr/local/apache2, but try "grep +DocumentRoot /where/ever/httpd.conf" to find your root: + + $ cd /usr/local/apache/htdocs + $ mkdir my-new-repo.git + + On Debian: + + $ cd /var/www + $ mkdir my-new-repo.git + + +Initialize a bare repository + + $ cd my-new-repo.git + $ 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: + + $ chown -R www.www . + + On Debian: + + $ chown -R www-data.www-data . + + +If you do not know which user Apache runs as, you can alternatively do +a "chmod -R a+w .", inspect the files which are created later on, and +set the permissions appropriately. + +Restart apache2, and check whether http://server/my-new-repo.git gives +a directory listing. If not, check whether apache started up +successfully. + + +Step 2: enable DAV on this repository +------------------------------------- + +First make sure the dav_module is loaded. For this, insert in httpd.conf: + + LoadModule dav_module libexec/httpd/libdav.so + AddModule mod_dav.c + +Also make sure that this line exists which is the file used for +locking DAV operations: + + DAVLockDB "/usr/local/apache2/temp/DAV.lock" + + On Debian these steps can be performed with: + + Enable the dav and dav_fs modules of apache: + $ a2enmod dav_fs + (just to be sure. dav_fs might be unneeded, I don't know) + $ a2enmod dav + The DAV lock is located in /etc/apache2/mods-available/dav_fs.conf: + DAVLockDB /var/lock/apache2/DAVLock + +Of course, it can point somewhere else, but the string is actually just a +prefix in some Apache configurations, and therefore the _directory_ has to +be writable by the user Apache runs as. + +Then, add something like this to your httpd.conf + + <Location /my-new-repo.git> + DAV on + AuthType Basic + AuthName "Git" + AuthUserFile /usr/local/apache2/conf/passwd.git + Require valid-user + </Location> + + On Debian: + Create (or add to) /etc/apache2/conf.d/git.conf : + + <Location /my-new-repo.git> + DAV on + AuthType Basic + AuthName "Git" + AuthUserFile /etc/apache2/passwd.git + Require valid-user + </Location> + + Debian automatically reads all files under /etc/apache2/conf.d. + +The password file can be somewhere else, but it has to be readable by +Apache and preferably not readable by the world. + +Create this file by + $ htpasswd -c /usr/local/apache2/conf/passwd.git <user> + + On Debian: + $ htpasswd -c /etc/apache2/passwd.git <user> + +You will be asked a password, and the file is created. Subsequent calls +to htpasswd should omit the '-c' option, since you want to append to the +existing file. + +You need to restart Apache. + +Now go to http://<username>@<servername>/my-new-repo.git in your +browser to check whether it asks for a password and accepts the right +password. + +On Debian: + + To test the WebDAV part, do: + + $ apt-get install litmus + $ litmus http://<servername>/my-new-repo.git <username> <password> + + Most tests should pass. + +A command line tool to test WebDAV is cadaver. If you prefer GUIs, for +example, konqueror can open WebDAV URLs as "webdav://..." or +"webdavs://...". + +If you're into Windows, from XP onwards Internet Explorer supports +WebDAV. For this, do Internet Explorer -> Open Location -> +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 +libcurl (version more recent than 7.10). The command 'git http-push' with +no argument should display a usage message. + +Then, add the following to your $HOME/.netrc (you can do without, but will be +asked to input your password a _lot_ of times): + + machine <servername> + login <username> + password <password> + +...and set permissions: + chmod 600 ~/.netrc + +If you want to access the web-server by its IP, you have to type that in, +instead of the server name. + +To check whether all is OK, do: + + curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/HEAD + +...this should give something like 'ref: refs/heads/master', which is +the content of the file HEAD on the server. + +Now, add the remote in your existing repository which contains the project +you want to export: + + $ git-config remote.upload.url \ + http://<username>@<servername>/my-new-repo.git/ + +It is important to put the last '/'; Without it, the server will send +a redirect which git-http-push does not (yet) understand, and git-http-push +will repeat the request infinitely. + + +Step 4: make the initial push +----------------------------- + +From your client repository, do + + $ git push upload master + +This pushes branch 'master' (which is assumed to be the branch you +want to export) to repository called 'upload', which we previously +defined with git-config. + + +Using a proxy: +-------------- + +If you have to access the WebDAV server from behind an HTTP(S) proxy, +set the variable 'all_proxy' to 'http://proxy-host.com:port', or +'http://login-on-proxy:passwd-on-proxy@proxy-host.com:port'. See 'man +curl' for details. + + +Troubleshooting: +---------------- + +If git-http-push says + + Error: no DAV locking support on remote repo http://... + +then it means the web-server did not accept your authentication. Make sure +that the user name and password matches in httpd.conf, .netrc and the URL +you are uploading to. + +If git-http-push shows you an error (22/502) when trying to MOVE a blob, +it means that your web-server somehow does not recognize its name in the +request; This can happen when you start Apache, but then disable the +network interface. A simple restart of Apache helps. + +Errors like (22/502) are of format (curl error code/http error +code). So (22/404) means something like 'not found' at the server. + +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 +certificate (this is return code 60). Setting http.sslVerify=false can +help diagnosing the problem, but removes security checks. + + +Debian References: http://www.debian-administration.org/articles/285 + +Authors + Johannes Schindelin <Johannes.Schindelin@gmx.de> + Rutger Nijlunsing <git@wingding.demon.nl> + Matthieu Moy <Matthieu.Moy@imag.fr> diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt new file mode 100644 index 0000000000..b7f8d416d6 --- /dev/null +++ b/Documentation/howto/update-hook-example.txt @@ -0,0 +1,192 @@ +From: Junio C Hamano <gitster@pobox.com> and Carl Baldwin <cnb@fc.hp.com> +Subject: control access to branches. +Date: Thu, 17 Nov 2005 23:55:32 -0800 +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. + +When your developer runs git-push into the repository, +git-receive-pack is run (either locally or over ssh) as that +developer, so is hooks/update script. Quoting from the relevant +section of the documentation: + + Before each ref is updated, if $GIT_DIR/hooks/update file exists + and executable, it is called with three parameters: + + $GIT_DIR/hooks/update refname sha1-old sha1-new + + The refname parameter is relative to $GIT_DIR; e.g. for the + master head this is "refs/heads/master". Two sha1 are the + object names for the refname before and after the update. Note + that the hook is called before the refname is updated, so either + sha1-old is 0{40} (meaning there is no such ref yet), or it + should match what is recorded in refname. + +So if your policy is (1) always require fast-forward push +(i.e. never allow "git-push repo +branch:branch"), (2) you +have a list of users allowed to update each branch, and (3) you +do not let tags to be overwritten, then you can use something +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 + +# If you are having trouble with this access control hook script +# you can try setting this to true. It will tell you exactly +# why a user is being allowed/denied access. + +verbose=false + +# Default shell globbing messes things up downstream +GLOBIGNORE=* + +function grant { + $verbose && echo >&2 "-Grant- $1" + echo grant + exit 0 +} + +function deny { + $verbose && echo >&2 "-Deny- $1" + echo deny + exit 1 +} + +function info { + $verbose && echo >&2 "-Info- $1" +} + +# Implement generic branch and tag policies. +# - Tags should not be updated once created. +# - Branches should only be fast-forwarded unless their pattern starts with '+' +case "$1" in + refs/tags/*) + git rev-parse --verify -q "$1" && + deny >/dev/null "You can't overwrite an existing tag" + ;; + refs/heads/*) + # No rebasing or rewinding + if expr "$2" : '0*$' >/dev/null; then + info "The branch '$1' is new..." + else + # updating -- make sure it is a fast-forward + mb=$(git-merge-base "$2" "$3") + case "$mb,$2" in + "$2,$mb") info "Update is fast-forward" ;; + *) noff=y; info "This is not a fast-forward update.";; + esac + fi + ;; + *) + deny >/dev/null \ + "Branch is not under refs/heads or refs/tags. What are you trying to do?" + ;; +esac + +# Implement per-branch controls based on username +allowed_users_file=$GIT_DIR/info/allowed-users +username=$(id -u -n) +info "The user is: '$username'" + +if test -f "$allowed_users_file" +then + rc=$(cat $allowed_users_file | grep -v '^#' | grep -v '^$' | + while read heads user_patterns + do + # does this rule apply to us? + head_pattern=${heads#+} + matchlen=$(expr "$1" : "${head_pattern#+}") + test "$matchlen" = ${#1} || continue + + # if non-ff, $heads must be with the '+' prefix + test -n "$noff" && + test "$head_pattern" = "$heads" && continue + + 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 + done + deny "The user is not in the access list for this branch" + done + ) + case "$rc" in + grant) grant >/dev/null "Granting access based on $allowed_users_file" ;; + deny) deny >/dev/null "Denying access based on $allowed_users_file" ;; + *) ;; + esac +fi + +allowed_groups_file=$GIT_DIR/info/allowed-groups +groups=$(id -G -n) +info "The user belongs to the following groups:" +info "'$groups'" + +if test -f "$allowed_groups_file" +then + rc=$(cat $allowed_groups_file | grep -v '^#' | grep -v '^$' | + while read heads group_patterns + do + # does this rule apply to us? + head_pattern=${heads#+} + matchlen=$(expr "$1" : "${head_pattern#+}") + test "$matchlen" = ${#1} || continue + + # if non-ff, $heads must be with the '+' prefix + test -n "$noff" && + test "$head_pattern" = "$heads" && continue + + 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 + done + done + deny "None of the user's groups are in the access list for this branch" + done + ) + case "$rc" in + grant) grant >/dev/null "Granting access based on $allowed_groups_file" ;; + deny) deny >/dev/null "Denying access based on $allowed_groups_file" ;; + *) ;; + esac +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 + +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 new file mode 100644 index 0000000000..4e2f75cb61 --- /dev/null +++ b/Documentation/howto/use-git-daemon.txt @@ -0,0 +1,51 @@ +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 +real quick, right? + +Note that git-daemon is not really chatty at the moment, especially when +things do not go according to plan (e.g. a socket could not be bound). + +Another word of warning: if you run + + $ git ls-remote git://127.0.0.1/rule-the-world.git + +and you see a message like + + fatal: The remote end hung up unexpectedly + +it only means that _something_ went wrong. To find out _what_ went wrong, +you have to ask the server. (Git refuses to be more precise for your +security only. Take off your shoes now. You have any coins in your pockets? +Sorry, not allowed -- who knows what you planned to do with them?) + +With these two caveats, let's see an example: + + $ git daemon --reuseaddr --verbose --base-path=/home/gitte/git \ + --export-all -- /home/gitte/git/rule-the-world.git + +(Of course, unless your user name is `gitte` _and_ your repository is in +~/rule-the-world.git, you have to adjust the paths. If your repository is +not bare, be aware that you have to type the path to the .git directory!) + +This invocation tries to reuse the address if it is already taken +(this can save you some debugging, because otherwise killing and restarting +git-daemon could just silently fail to bind to a socket). + +Also, it is (relatively) verbose when somebody actually connects to it. +It also sets the base path, which means that all the projects which can be +accessed using this daemon have to reside in or under that path. + +The option `--export-all` just means that you _don't_ have to create a +file named `git-daemon-export-ok` in each exported repository. (Otherwise, +git-daemon would complain loudly, and refuse to cooperate.) + +Last of all, the repository which should be exported is specified. It is +a good practice to put the paths after a "--" separator. + +Now, test your daemon with + + $ git ls-remote git://127.0.0.1/rule-the-world.git + +If this does not work, find out why, and submit a patch to this document. diff --git a/Documentation/howto/using-merge-subtree.txt b/Documentation/howto/using-merge-subtree.txt new file mode 100644 index 0000000000..0953a50b69 --- /dev/null +++ b/Documentation/howto/using-merge-subtree.txt @@ -0,0 +1,75 @@ +Date: Sat, 5 Jan 2008 20:17:40 -0500 +From: Sean <seanlkml@sympatico.ca> +To: Miklos Vajna <vmiklos@frugalware.org> +Cc: git@vger.kernel.org +Subject: how to use git merge -s subtree? +Abstract: In this article, Sean demonstrates how one can use the subtree merge + strategy. +Content-type: text/asciidoc +Message-ID: <BAYC1-PASMTP12374B54BA370A1E1C6E78AE4E0@CEZ.ICE> + +How to use the subtree merge strategy +===================================== + +There are situations where you want to include contents in your project +from an independently developed project. You can just pull from the +other project as long as there are no conflicting paths. + +The problematic case is when there are conflicting files. Potential +candidates are Makefiles and other standard filenames. You could merge +these files but probably you do not want to. A better solution for this +problem can be to merge the project as its own subdirectory. This is not +supported by the 'recursive' merge strategy, so just pulling won't work. + +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' +branch of that repository to the `dir-B` subdirectory in your current +branch. + +Here is the command sequence you need: + +---------------- +$ git remote add -f Bproject /path/to/B <1> +$ git merge -s ours --no-commit Bproject/master <2> +$ git read-tree --prefix=dir-B/ -u Bproject/master <3> +$ git commit -m "Merge B project as our subdirectory" <4> + +$ git pull -s subtree Bproject master <5> +---------------- +<1> name the other project "Bproject", and fetch. +<2> prepare for the later step to record the result as a merge. +<3> read "master" branch of Bproject to the subdirectory "dir-B". +<4> record the merge result. +<5> maintain the result with subsequent merges using "subtree" + +The first four commands are used for the initial merge, while the last +one is to merge updates from 'B project'. + +Comparing 'subtree' merge with submodules +----------------------------------------- + +- The benefit of using subtree merge is that it requires less + administrative burden from the users of your repository. It works with + older (before Git v1.5.2) clients and you have the code right after + clone. + +- However if you use submodules then you can choose not to transfer the + submodule objects. This may be a problem with the subtree merge. + +- Also, in case you make changes to the other project, it is easier to + submit changes if you just use submodules. + +Additional tips +--------------- + +- If you made changes to the other project in your repository, they may + want to merge from your project. This is possible using subtree -- it + can shift up the paths in your tree and then they can merge only the + relevant parts of your tree. + +- Please note that if the other project merges from you, then it will + connects its history to yours, which can be something they don't want + to. diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt new file mode 100644 index 0000000000..708da6ca31 --- /dev/null +++ b/Documentation/i18n.txt @@ -0,0 +1,57 @@ +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 + to be what lstat(2) and creat(2) accepts. There is no such + thing as pathname encoding translation. + + - The contents of the blob objects are uninterpreted sequences + of bytes. There is no encoding translation at the core + level. + + - The commit log messages are uninterpreted sequences of non-NUL + bytes. + +Although we encourage that the commit log messages are encoded +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 +does not forbid it. However, there are a few things to keep in +mind. + +. 'git-commit' and 'git-commit-tree' issues + a warning if the commit log message given to it does not look + like a valid UTF-8 string, unless you explicitly say your + project uses a legacy encoding. The way to say this is to + have i18n.commitencoding in `.git/config` file, like this: ++ +------------ +[i18n] + commitencoding = ISO-8859-1 +------------ ++ +Commit objects created with the above setting record the value +of `i18n.commitencoding` in its `encoding` header. This is to +help other people who look at them later. Lack of this header +implies that the commit log message is encoded in UTF-8. + +. 'git-log', 'git-show', 'git-blame' and friends look at the + `encoding` header of a commit object, and try to re-code the + log message into UTF-8 unless otherwise specified. You can + specify the desired output encoding with + `i18n.logoutputencoding` in `.git/config` file, like this: ++ +------------ +[i18n] + logoutputencoding = ISO-8859-1 +------------ ++ +If you do not have this configuration variable, the value of +`i18n.commitencoding` is used instead. + +Note that we deliberately chose not to re-code the commit log +message when a commit is made to force UTF-8 at the commit +object level, because re-coding to UTF-8 is not necessarily a +reversible operation. diff --git a/Documentation/install-doc-quick.sh b/Documentation/install-doc-quick.sh new file mode 100755 index 0000000000..35f440876e --- /dev/null +++ b/Documentation/install-doc-quick.sh @@ -0,0 +1,31 @@ +#!/bin/sh +# This requires a branch named in $head +# (usually 'man' or 'html', provided by the git.git repository) +set -e +head="$1" +mandir="$2" +SUBDIRECTORY_OK=t +USAGE='<refname> <target directory>' +. "$(git --exec-path)"/git-sh-setup +cd_to_toplevel + +test -z "$mandir" && usage +if ! git rev-parse --verify "$head^0" >/dev/null; then + echo >&2 "head: $head does not exist in the current repository" + usage +fi + +GIT_INDEX_FILE=`pwd`/.quick-doc.index +export GIT_INDEX_FILE +rm -f "$GIT_INDEX_FILE" +trap 'rm -f "$GIT_INDEX_FILE"' 0 + +git read-tree $head +git checkout-index -a -f --prefix="$mandir"/ + +if test -n "$GZ"; then + git ls-tree -r --name-only $head | + xargs printf "$mandir/%s\n" | + xargs gzip -f +fi +rm -f "$GIT_INDEX_FILE" diff --git a/Documentation/install-webdoc.sh b/Documentation/install-webdoc.sh new file mode 100755 index 0000000000..2135a8ee1f --- /dev/null +++ b/Documentation/install-webdoc.sh @@ -0,0 +1,39 @@ +#!/bin/sh + +T="$1" + +for h in \ + *.txt *.html \ + howto/*.txt howto/*.html \ + technical/*.txt technical/*.html \ + RelNotes-*.txt *.css +do + if test ! -f "$h" + then + : did not match + elif test -f "$T/$h" && + diff -u -I'Last updated [0-9][0-9]-[A-Z][a-z][a-z]-' "$T/$h" "$h" + then + :; # up to date + else + echo >&2 "# install $h $T/$h" + rm -f "$T/$h" + mkdir -p `dirname "$T/$h"` + cp "$h" "$T/$h" + fi +done +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"'\(.*\)'` + case "$h" in + index.html) continue ;; + esac + test -f "$h" && continue + echo >&2 "# rm -f $th" + rm -f "$th" +done +ln -sf git.html "$T/index.html" diff --git a/Documentation/mailmap.txt b/Documentation/mailmap.txt new file mode 100644 index 0000000000..288f04e70c --- /dev/null +++ b/Documentation/mailmap.txt @@ -0,0 +1,74 @@ +If the file `.mailmap` exists at the toplevel of the repository, or at +the location pointed to by the mailmap.file configuration option, it +is used to map author and committer names and email addresses to +canonical real names and email addresses. + +In the simple form, each line in the file consists of the canonical +real name of an author, whitespace, and an email address used in the +commit (enclosed by '<' and '>') to map to the name. For example: +-- + Proper Name <commit@email.xx> +-- + +The more complex forms are: +-- + <proper@email.xx> <commit@email.xx> +-- +which allows mailmap to replace only the email part of a commit, and: +-- + Proper Name <proper@email.xx> <commit@email.xx> +-- +which allows mailmap to replace both the name and the email of a +commit matching the specified commit email address, and: +-- + Proper Name <proper@email.xx> Commit Name <commit@email.xx> +-- +which allows mailmap to replace both the name and the email of a +commit matching both the specified commit name and email address. + +Example 1: Your history contains commits by two authors, Jane +and Joe, whose names appear in the repository under several forms: + +------------ +Joe Developer <joe@example.com> +Joe R. Developer <joe@example.com> +Jane Doe <jane@example.com> +Jane Doe <jane@laptop.(none)> +Jane D. <jane@desktop.(none)> +------------ + +Now suppose that Joe wants his middle name initial used, and Jane +prefers her family name fully spelled out. A proper `.mailmap` file +would look like: + +------------ +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 +real name of that author is already correct. + +Example 2: Your repository contains commits from the following +authors: + +------------ +nick1 <bugs@company.xx> +nick2 <bugs@company.xx> +nick2 <nick2@company.xx> +santa <me@company.xx> +claus <me@company.xx> +CTO <cto@coompany.xx> +------------ + +Then you might want a `.mailmap` file that looks like: +------------ +<cto@company.xx> <cto@coompany.xx> +Some Dude <some@dude.xx> nick1 <bugs@company.xx> +Other Author <other@author.xx> nick2 <bugs@company.xx> +Other Author <other@author.xx> <nick2@company.xx> +Santa Claus <santa.claus@northpole.xx> <me@company.xx> +------------ + +Use hash '#' for comments that are either on their own line, or after +the email address. diff --git a/Documentation/manpage-1.72.xsl b/Documentation/manpage-1.72.xsl new file mode 100644 index 0000000000..b4d315cb8c --- /dev/null +++ b/Documentation/manpage-1.72.xsl @@ -0,0 +1,14 @@ +<!-- manpage-1.72.xsl: + special settings for manpages rendered from asciidoc+docbook + handles peculiarities in docbook-xsl 1.72.0 --> +<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" + version="1.0"> + +<xsl:import href="manpage-base.xsl"/> + +<!-- these are the special values for the roff control characters + needed for docbook-xsl 1.72.0 --> +<xsl:param name="git.docbook.backslash">▓</xsl:param> +<xsl:param name="git.docbook.dot" >⌂</xsl:param> + +</xsl:stylesheet> diff --git a/Documentation/manpage-base-url.xsl.in b/Documentation/manpage-base-url.xsl.in new file mode 100644 index 0000000000..e800904df3 --- /dev/null +++ b/Documentation/manpage-base-url.xsl.in @@ -0,0 +1,10 @@ +<!-- manpage-base-url.xsl: + special settings for manpages rendered from newer docbook --> +<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" + version="1.0"> + +<!-- set a base URL for relative links --> +<xsl:param name="man.base.url.for.relative.links" + >@@MAN_BASE_URL@@</xsl:param> + +</xsl:stylesheet> diff --git a/Documentation/manpage-base.xsl b/Documentation/manpage-base.xsl new file mode 100644 index 0000000000..a264fa6160 --- /dev/null +++ b/Documentation/manpage-base.xsl @@ -0,0 +1,35 @@ +<!-- manpage-base.xsl: + special formatting for manpages rendered from asciidoc+docbook --> +<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" + version="1.0"> + +<!-- these params silence some output from xmlto --> +<xsl:param name="man.output.quietly" select="1"/> +<xsl:param name="refentry.meta.get.quietly" select="1"/> + +<!-- convert asciidoc callouts to man page format; + git.docbook.backslash and git.docbook.dot params + must be supplied by another XSL file or other means --> +<xsl:template match="co"> + <xsl:value-of select="concat( + $git.docbook.backslash,'fB(', + substring-after(@id,'-'),')', + $git.docbook.backslash,'fR')"/> +</xsl:template> +<xsl:template match="calloutlist"> + <xsl:value-of select="$git.docbook.dot"/> + <xsl:text>sp </xsl:text> + <xsl:apply-templates/> + <xsl:text> </xsl:text> +</xsl:template> +<xsl:template match="callout"> + <xsl:value-of select="concat( + $git.docbook.backslash,'fB', + substring-after(@arearefs,'-'), + '. ',$git.docbook.backslash,'fR')"/> + <xsl:apply-templates/> + <xsl:value-of select="$git.docbook.dot"/> + <xsl:text>br </xsl:text> +</xsl:template> + +</xsl:stylesheet> diff --git a/Documentation/manpage-bold-literal.xsl b/Documentation/manpage-bold-literal.xsl new file mode 100644 index 0000000000..608eb5df62 --- /dev/null +++ b/Documentation/manpage-bold-literal.xsl @@ -0,0 +1,17 @@ +<!-- manpage-bold-literal.xsl: + special formatting for manpages rendered from asciidoc+docbook --> +<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" + version="1.0"> + +<!-- render literal text as bold (instead of plain or monospace); + this makes literal text easier to distinguish in manpages + viewed on a tty --> +<xsl:template match="literal"> + <xsl:value-of select="$git.docbook.backslash"/> + <xsl:text>fB</xsl:text> + <xsl:apply-templates/> + <xsl:value-of select="$git.docbook.backslash"/> + <xsl:text>fR</xsl:text> +</xsl:template> + +</xsl:stylesheet> diff --git a/Documentation/manpage-normal.xsl b/Documentation/manpage-normal.xsl new file mode 100644 index 0000000000..a48f5b11f3 --- /dev/null +++ b/Documentation/manpage-normal.xsl @@ -0,0 +1,13 @@ +<!-- manpage-normal.xsl: + special settings for manpages rendered from asciidoc+docbook + handles anything we want to keep away from docbook-xsl 1.72.0 --> +<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" + version="1.0"> + +<xsl:import href="manpage-base.xsl"/> + +<!-- these are the normal values for the roff control characters --> +<xsl:param name="git.docbook.backslash">\</xsl:param> +<xsl:param name="git.docbook.dot" >.</xsl:param> + +</xsl:stylesheet> diff --git a/Documentation/manpage-quote-apos.xsl b/Documentation/manpage-quote-apos.xsl new file mode 100644 index 0000000000..aeb8839f33 --- /dev/null +++ b/Documentation/manpage-quote-apos.xsl @@ -0,0 +1,16 @@ +<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" + version="1.0"> + +<!-- work around newer groff/man setups using a prettier apostrophe + that unfortunately does not quote anything when cut&pasting + examples to the shell --> +<xsl:template name="escape.apostrophe"> + <xsl:param name="content"/> + <xsl:call-template name="string.subst"> + <xsl:with-param name="string" select="$content"/> + <xsl:with-param name="target">'</xsl:with-param> + <xsl:with-param name="replacement">\(aq</xsl:with-param> + </xsl:call-template> +</xsl:template> + +</xsl:stylesheet> diff --git a/Documentation/manpage-suppress-sp.xsl b/Documentation/manpage-suppress-sp.xsl new file mode 100644 index 0000000000..a63c7632a8 --- /dev/null +++ b/Documentation/manpage-suppress-sp.xsl @@ -0,0 +1,21 @@ +<!-- manpage-suppress-sp.xsl: + special settings for manpages rendered from asciidoc+docbook + handles erroneous, inline .sp in manpage output of some + versions of docbook-xsl --> +<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" + version="1.0"> + +<!-- attempt to work around spurious .sp at the tail of the line + that some versions of docbook stylesheets seem to add --> +<xsl:template match="simpara"> + <xsl:variable name="content"> + <xsl:apply-templates/> + </xsl:variable> + <xsl:value-of select="normalize-space($content)"/> + <xsl:if test="not(ancestor::authorblurb) and + not(ancestor::personblurb)"> + <xsl:text> </xsl:text> + </xsl:if> +</xsl:template> + +</xsl:stylesheet> diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt new file mode 100644 index 0000000000..a403155052 --- /dev/null +++ b/Documentation/merge-config.txt @@ -0,0 +1,49 @@ +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, + a `=======` marker, changes made by the other side, and then + a `>>>>>>>` marker. An alternate style, "diff3", adds a `|||||||` + marker and the original text before the `=======` marker. + +merge.log:: + Whether to include summaries of merged commits in newly created + merge commit messages. False by default. + +merge.renameLimit:: + The number of files to consider when performing rename detection + during a merge; if not specified, defaults to the value of + diff.renameLimit. + +merge.stat:: + Whether to print the diffstat between ORIG_HEAD and the merge result + 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: "kdiff3", + "tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", + "diffuse", "ecmerge", "tortoisemerge", "p4merge", "araxis" and + "opendiff". Any other value is treated is custom merge tool + and there must be a corresponding mergetool.<tool>.cmd option. + +merge.verbosity:: + Controls the amount of output shown by the recursive merge + strategy. Level 0 outputs nothing except a final error + message if conflicts were detected. Level 1 outputs only + conflicts, 2 outputs conflicts and file changes. Level 5 and + above outputs debugging information. The default is level 2. + Can be overridden by the 'GIT_MERGE_VERBOSITY' environment variable. + +merge.<driver>.name:: + Defines a human-readable name for a custom low-level + merge driver. See linkgit:gitattributes[5] for details. + +merge.<driver>.driver:: + Defines the command that implements a custom low-level + merge driver. See linkgit:gitattributes[5] for details. + +merge.<driver>.recursive:: + Names a low-level merge driver to be used when + performing an internal merge between common ancestors. + See linkgit:gitattributes[5] for details. diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt new file mode 100644 index 0000000000..fec3394305 --- /dev/null +++ b/Documentation/merge-options.txt @@ -0,0 +1,76 @@ +--commit:: +--no-commit:: + Perform the merge and commit the result. This option can + be used to override --no-commit. ++ +With --no-commit perform the merge but pretend the merge +failed and do not autocommit, to give the user a chance to +inspect and further tweak the merge result before committing. + +--ff:: +--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. + +--log:: +--no-log:: + In addition to branch names, populate the log message with + one-line descriptions from the actual commits that are being + merged. ++ +With --no-log do not list one-line descriptions from the +actual commits being merged. + + +--stat:: +-n:: +--no-stat:: + Show a diffstat at the end of the merge. The diffstat is also + controlled by the configuration option merge.stat. ++ +With -n or --no-stat do not show a diffstat at the end of the +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). ++ +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 + once to specify them in the order they should be tried. + If there is no `-s` option, a built-in list of strategies + is used instead ('git-merge-recursive' when merging a single + head, 'git-merge-octopus' otherwise). + +--summary:: +--no-summary:: + Synonyms to --stat and --no-stat; these are deprecated and will be + removed in the future. + +-q:: +--quiet:: + Operate quietly. + +-v:: +--verbose:: + Be verbose. diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt new file mode 100644 index 0000000000..42910a3d5e --- /dev/null +++ b/Documentation/merge-strategies.txt @@ -0,0 +1,43 @@ +MERGE STRATEGIES +---------------- + +resolve:: + This can only resolve two heads (i.e. the current branch + and another branch you pulled from) using a 3-way merge + algorithm. It tries to carefully detect criss-cross + merge ambiguities and is considered generally safe and + fast. + +recursive:: + This can only resolve two heads using a 3-way merge + algorithm. When there is more than one common + ancestor that can be used for 3-way merge, it creates a + 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 + taken from Linux 2.6 kernel development history. + Additionally this can detect and handle merges involving + renames. This is the default merge strategy when + pulling or merging one branch. + +octopus:: + This resolves cases with more than two heads, but refuses to do + a complex merge that needs manual resolution. It is + primarily meant to be used for bundling topic branch + heads together. This is the default merge strategy when + pulling or merging more than one branch. + +ours:: + This resolves any number of heads, but the resulting tree of the + merge is always that of the current branch head, effectively + ignoring all changes from all other branches. It is meant to + be used to supersede old development history of side + branches. + +subtree:: + This is a modified recursive strategy. When merging trees A and + B, if B corresponds to a subtree of A, B is first adjusted to + 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. diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt new file mode 100644 index 0000000000..53a9168ba7 --- /dev/null +++ b/Documentation/pretty-formats.txt @@ -0,0 +1,184 @@ +PRETTY FORMATS +-------------- + +If the commit is a merge, and if the pretty-format +is not 'oneline', 'email' or 'raw', an additional line is +inserted before the 'Author:' line. This line begins with +"Merge: " and the sha1s of ancestral commits are printed, +separated by spaces. Note that the listed commits may not +necessarily be the list of the *direct* parent commits if you +have limited your view of history: for example, if you are +only interested in changes related to a certain directory or +file. + +Here are some additional details for each format: + +* 'oneline' + + <sha1> <title line> ++ +This is designed to be as compact as possible. + +* 'short' + + commit <sha1> + Author: <author> + + <title line> + +* 'medium' + + commit <sha1> + Author: <author> + Date: <author date> + + <title line> + + <full commit message> + +* 'full' + + commit <sha1> + Author: <author> + Commit: <committer> + + <title line> + + <full commit message> + +* 'fuller' + + commit <sha1> + Author: <author> + AuthorDate: <author date> + Commit: <committer> + CommitDate: <committer date> + + <title line> + + <full commit message> + +* 'email' + + From <sha1> <date> + From: <author> + Date: <author date> + Subject: [PATCH] <title line> + + <full commit message> + +* 'raw' ++ +The 'raw' format shows the entire commit exactly as +stored in the commit object. Notably, the SHA1s 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 +simplification into account. + +* 'format:' ++ +The 'format:' format allows you to specify which information +you want to show. It works a little bit like printf format, +with the notable exception that you get a newline with '%n' +instead of '\n'. ++ +E.g, 'format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"' +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: + +- '%H': commit hash +- '%h': abbreviated commit hash +- '%T': tree hash +- '%t': abbreviated tree hash +- '%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]) +- '%ae': author email +- '%aE': author email (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1]) +- '%ad': author date (format respects --date= option) +- '%aD': author date, RFC2822 style +- '%ar': author date, relative +- '%at': author date, UNIX timestamp +- '%ai': author date, ISO 8601 format +- '%cn': committer name +- '%cN': committer name (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1]) +- '%ce': committer email +- '%cE': committer email (respecting .mailmap, see linkgit:git-shortlog[1] or linkgit:git-blame[1]) +- '%cd': committer date +- '%cD': committer date, RFC2822 style +- '%cr': committer date, relative +- '%ct': committer date, UNIX timestamp +- '%ci': committer date, ISO 8601 format +- '%d': ref names, like the --decorate option of linkgit:git-log[1] +- '%e': encoding +- '%s': subject +- '%f': sanitized subject line, suitable for a filename +- '%b': body +- '%N': commit notes +- '%gD': reflog selector, e.g., `refs/stash@\{1\}` +- '%gd': shortened reflog selector, e.g., `stash@\{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 +- '%m': left, right or boundary mark +- '%n': newline +- '%x00': print a byte from a hex code +- '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of + linkgit:git-shortlog[1]. + +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. + +If you add a `{plus}` (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. + +If you add a `-` (minus sign) after '%' of a placeholder, line-feeds that +immediately precede the expansion are deleted if and only if the +placeholder expands to an empty string. + +* 'tformat:' ++ +The 'tformat:' format works exactly like 'format:', except that it +provides "terminator" semantics instead of "separator" semantics. In +other words, each commit has the message terminator character (usually a +newline) appended, rather than a separator placed between entries. +This means that the final entry of a single-line format will be properly +terminated with a new line, just as the "oneline" format does. +For example: ++ +--------------------- +$ git log -2 --pretty=format:%h 4da45bef \ + | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' +4da45be +7134973 -- NO NEWLINE + +$ git log -2 --pretty=tformat:%h 4da45bef \ + | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' +4da45be +7134973 +--------------------- ++ +In addition, any unrecognized string that has a `%` in it is interpreted +as if it has `tformat:` in front of it. For example, these two are +equivalent: ++ +--------------------- +$ git log -2 --pretty=tformat:%h 4da45bef +$ git log -2 --pretty=%h 4da45bef +--------------------- diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt new file mode 100644 index 0000000000..bff94991b6 --- /dev/null +++ b/Documentation/pretty-options.txt @@ -0,0 +1,30 @@ +--pretty[='<format>']:: +--format[='<format>']:: + + 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>'. + When omitted, the format defaults to 'medium'. ++ +Note: you can specify the default pretty format in the repository +configuration (see linkgit:git-config[1]). + +--abbrev-commit:: + Instead of showing the full 40-byte hexadecimal commit object + name, show only a partial prefix. Non default number of + digits can be specified with "--abbrev=<n>" (which also modifies + diff output, if it is displayed). ++ +This should make "--pretty=oneline" a whole lot more readable for +people using 80-column terminals. + +--oneline:: + This is a shorthand for "--pretty=oneline --abbrev-commit" + used together. + +--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 + preferred by the user. For non plumbing commands this + defaults to UTF-8. diff --git a/Documentation/pt_BR/gittutorial.txt b/Documentation/pt_BR/gittutorial.txt new file mode 100644 index 0000000000..beba065252 --- /dev/null +++ b/Documentation/pt_BR/gittutorial.txt @@ -0,0 +1,675 @@ +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 new file mode 100644 index 0000000000..0551ebdfaf --- /dev/null +++ b/Documentation/pull-fetch-param.txt @@ -0,0 +1,73 @@ +<repository>:: + The "remote" repository that is the source of a fetch + or pull operation. This parameter can be either a URL + (see the section <<URLS,GIT URLS>> below) or the name + of a remote (see the section <<REMOTES,REMOTES>> below). + +ifndef::git-pull[] +<group>:: + A name referring to a list of repositories as the value + of remotes.<group> in the configuration file. + (See linkgit:git-config[1]). +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>. ++ +The remote ref that matches <src> +is fetched, and if <dst> is not empty string, the local +ref that matches it is fast-forwarded using <src>. +If the optional plus `+` is used, the local ref +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 +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. ++ +[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 +'git-pull' command without any explicit <refspec> parameters. +<refspec> 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 +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 diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt new file mode 100644 index 0000000000..1f57aed337 --- /dev/null +++ b/Documentation/rev-list-options.txt @@ -0,0 +1,655 @@ +Commit Formatting +~~~~~~~~~~~~~~~~~ + +ifdef::git-rev-list[] +Using these options, linkgit:git-rev-list[1] will act similar to the +more specialized family of commit log tools: linkgit:git-log[1], +linkgit:git-show[1], and linkgit:git-whatchanged[1] +endif::git-rev-list[] + +include::pretty-options.txt[] + +--relative-date:: + + Synonym for `--date=relative`. + +--date={relative,local,default,iso,rfc,short,raw}:: + + Only takes effect for dates shown in human-readable format, such + as when using "--pretty". `log.date` config variable sets a default + value for log command's --date option. ++ +`--date=relative` shows dates relative to the current time, +e.g. "2 hours ago". ++ +`--date=local` shows timestamps in user's local timezone. ++ +`--date=iso` (or `--date=iso8601`) shows timestamps in ISO 8601 format. ++ +`--date=rfc` (or `--date=rfc2822`) shows timestamps in RFC 2822 +format, often found in E-mail messages. ++ +`--date=short` shows only date but not time, in `YYYY-MM-DD` format. ++ +`--date=raw` shows the date in the internal raw git format `%s %z` format. ++ +`--date=default` shows timestamps in the original timezone +(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 the parents of the commit. Also enables parent + rewriting, see 'History Simplification' below. + +--children:: + + Print the children of the commit. Also enables parent + rewriting, see 'History Simplification' below. + +ifdef::git-rev-list[] +--timestamp:: + Print the raw commit timestamp. +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 + commits are prefixed with `-`. ++ +For example, if you have this topology: ++ +----------------------------------------------------------------------- + y---b---b branch B + / \ / + / . + / / \ + o---x---a---a branch A +----------------------------------------------------------------------- ++ +you would get an output like this: ++ +----------------------------------------------------------------------- + $ git rev-list --left-right --boundary --pretty=oneline A...B + + >bbbbbbb... 3rd on b + >bbbbbbb... 2nd on b + <aaaaaaa... 3rd on a + <aaaaaaa... 2nd on a + -yyyyyyy... 1st on b + -xxxxxxx... 1st on a +----------------------------------------------------------------------- + +--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. ++ +This implies the '--topo-order' option by default, but the +'--date-order' option may also be specified. + +ifndef::git-rev-list[] +Diff Formatting +~~~~~~~~~~~~~~~ + +Below are listed 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:: + + This flag changes the way a merge commit is displayed. It shows + the differences from each of the parents to the merge result + simultaneously instead of showing pairwise diff between a parent + and the result one at a time. Furthermore, it lists only files + which were modified from all parents. + +--cc:: + + This flag implies the '-c' options 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. + +-r:: + + Show recursive diffs. + +-t:: + + Show the tree objects in the diff output. This implies '-r'. +endif::git-rev-list[] + +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. + +-- + +-n 'number':: +--max-count=<number>:: + + Limit the number of commits 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). + +--grep=<pattern>:: + + Limit the commits output to ones with log message that + matches the specified pattern (regular expression). + +--all-match:: + Limit the commits output to ones that match all given --grep, + --author and --committer instead of ones that match at least one. + +-i:: +--regexp-ignore-case:: + + Match the regexp limiting patterns without regard to letters case. + +-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:: + + Stop when a given path disappears from the tree. + +--merges:: + + Print only merge commits. + +--no-merges:: + + Do not print commits with more than one parent. + +--first-parent:: + Follow only the first parent commit upon seeing a merge + commit. This option can give a better overview when + viewing the evolution of a particular topic branch, + 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. + +--not:: + + Reverses the meaning of the '{caret}' prefix (or lack thereof) + for all following revision specifiers, up to the next '--not'. + +--all:: + + Pretend as if all the refs in `$GIT_DIR/refs/` are listed on the + command line as '<commit>'. + +--branches:: + + Pretend as if all the refs in `$GIT_DIR/refs/heads` are listed + on the command line as '<commit>'. + +--tags:: + + Pretend as if all the refs in `$GIT_DIR/refs/tags` are listed + on the command line as '<commit>'. + +--remotes:: + + Pretend as if all the refs in `$GIT_DIR/refs/remotes` are listed + on the command line as '<commit>'. + +ifndef::git-rev-list[] +--bisect:: + + Pretend as if the bad bisection ref `$GIT_DIR/refs/bisect/bad` + was listed and as if it was followed by `--not` and the good + bisection refs `$GIT_DIR/refs/bisect/good-*` on the command + line. +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 + result. + +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. +endif::git-rev-list[] + +--cherry-pick:: + + Omit any commit that introduces the same change as + 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`, like the example above in the description of +that 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 +excluded from the output. + +-g:: +--walk-reflogs:: + + Instead of walking the commit ancestry chain, walk + reflog entries from the most recent one to older ones. + When this option is used you cannot specify commits to + exclude (that is, '{caret}commit', 'commit1..commit2', + nor 'commit1...commit2' notations cannot be used). ++ +With '\--pretty' format other than oneline (for obvious reasons), +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 +prefixed with this information on the same line. +This option cannot be combined with '\--reverse'. +See also linkgit:git-reflog[1]. + +--merge:: + + After a failed merge, show refs that touch files having a + conflict and don't exist on all heads to merge. + +--boundary:: + + Output uninteresting commits at the boundary, which are usually + not shown. + +-- + +History Simplification +~~~~~~~~~~~~~~~~~~~~~~ + +Sometimes you are only interested in parts of the history, for example the +commits modifying a particular <path>. But there are two parts of +'History Simplification', one part is selecting the commits and the other +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. + +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:: + + 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 + merges from the resulting history, as there are no selected + commits contributing to this merge. + +A more detailed explanation follows. + +Suppose you specified `foo` as the <paths>. We shall call commits +that modify `foo` !TREESAME, and the rest TREESAME. (In a diff +filtered for `foo`, they look different and equal, respectively.) + +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 + \ / / / / + `-------------' +----------------------------------------------------------------------- +The horizontal line of history A--P 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 + commits are compared to an empty tree, so `I` is !TREESAME. + +* 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", + 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. + +* `E` changes `quux` to "xyzzy", and its merge `P` combines the + strings to "quux xyzzy". Despite appearing interesting, `P` is + TREESAME to all parents. + +'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 + 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 + parents. ++ +This results in: ++ +----------------------------------------------------------------------- + .-A---N---O + / / + I---------D +----------------------------------------------------------------------- ++ +Note how the rule to only follow the TREESAME parent, if one is +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 +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 + included, this does not imply that the merge itself is! In + the example, we get ++ +----------------------------------------------------------------------- + I A B N D O +----------------------------------------------------------------------- ++ +`P` and `M` were excluded because they are TREESAME to a parent. `E`, +`C` and `B` were all walked, but only `B` was !TREESAME, so the others +do not appear. ++ +Note that without parent rewriting, it is not really possible to talk +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). ++ +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 + / / / / / + I B / D / + \ / / / / + `-------------' +----------------------------------------------------------------------- ++ +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. + +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 +one of the parents is TREESAME, we follow only that one, so the other +sides of the merge are never walked. + +Finally, there is a fourth simplification mode available: + +--simplify-merges:: + + First, build a history graph in the same way that + '\--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: ++ +-- +* 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. ++ +* If after this parent rewriting, `C'` is a root or merge commit (has + zero or >1 parents), a boundary commit, or !TREESAME, it remains. + Otherwise, it is replaced with its only parent. +-- ++ +The effect of this is best shown by way of comparing to +'\--full-history' with parent rewriting. The example turns into: ++ +----------------------------------------------------------------------- + .-A---M---N---O + / / / + I B D + \ / / + `---------' +----------------------------------------------------------------------- ++ +Note the major differences in `N` and `P` over '\--full-history': ++ +-- +* `N`'s parent list had `I` removed, because it is an ancestor of the + other parent `M`. Still, `N` remained because it is !TREESAME. ++ +* `P`'s parent list similarly had `I` removed. `P` was then + removed completely, because it had one parent and is TREESAME. +-- + +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 +above) if (1) they are referenced by tags, or (2) they change the +contents of the paths given on the command line. All other +commits are marked as TREESAME (subject to be simplified away). + +ifdef::git-rev-list[] +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 +`$GIT_DIR/refs/bisect/bad` is added to the included commits (if it +exists) and the good bisection refs `$GIT_DIR/refs/bisect/good-*` are +added to the excluded commits (if they exist). Thus, supposing there +are no refs in `$GIT_DIR/refs/bisect/`, if + +----------------------------------------------------------------------- + $ git rev-list --bisect foo ^bar ^baz +----------------------------------------------------------------------- + +outputs 'midpoint', the output of the two commands + +----------------------------------------------------------------------- + $ git rev-list foo ^midpoint + $ git rev-list midpoint ^bar ^baz +----------------------------------------------------------------------- + +would be of roughly the same length. Finding the change which +introduces a regression is thus reduced to a binary search: repeatedly +generate and test new 'midpoint's until the commit chain is of length +one. + +--bisect-vars:: + +This calculates the same as `--bisect`, except that refs in +`$GIT_DIR/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 `$GIT_DIR/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 +may not compile for example). ++ +This option can be used along with `--bisect-vars`, in this case, +after all the sorted commit objects, there will be the same text as if +`--bisect-vars` had been used alone. +endif::git-rev-list[] + + +Commit Ordering +~~~~~~~~~~~~~~~ + +By default, the commits are shown in reverse chronological order. + +--topo-order:: + + This option makes them appear in topological order (i.e. + descendant commits are shown before their parents). + +--date-order:: + + 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. + +--reverse:: + + Output the commits in reverse order. + Cannot be combined with '\--walk-reflogs'. + +Object Traversal +~~~~~~~~~~~~~~~~ + +These options are mostly targeted for packing of git repositories. + +--objects:: + + Print the object IDs of any object referenced by the listed + commits. '--objects foo ^bar' thus means "send me + all object IDs which I need to download if I have the commit + 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 + objects in deltified form based on objects contained in these + excluded commits to reduce network traffic. + +--unpacked:: + + Only useful with '--objects'; print the object IDs that are not + in packs. + +--no-walk:: + + Only show the given revs, but do not traverse their ancestors. + +--do-walk:: + + Overrides a previous --no-walk. diff --git a/Documentation/technical/.gitignore b/Documentation/technical/.gitignore new file mode 100644 index 0000000000..8aa891daee --- /dev/null +++ b/Documentation/technical/.gitignore @@ -0,0 +1 @@ +api-index.txt diff --git a/Documentation/technical/api-allocation-growing.txt b/Documentation/technical/api-allocation-growing.txt new file mode 100644 index 0000000000..43dbe09f73 --- /dev/null +++ b/Documentation/technical/api-allocation-growing.txt @@ -0,0 +1,34 @@ +allocation growing API +====================== + +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`; + +* an integer variable (`alloc`) that keeps track of how big the current + allocation is, initialized to `0`; + +* 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, +alloc)`. This ensures that the array can hold at least `n` elements by +calling `realloc(3)` and adjusting `alloc` variable. + +------------ +sometype *ary; +size_t nr; +size_t alloc + +for (i = 0; i < nr; i++) + if (we like ary[i] already) + return; + +/* we did not like any existing one, so add one */ +ALLOC_GROW(ary, nr + 1, alloc); +ary[nr++] = value you like; +------------ + +You are responsible for updating the `nr` variable. diff --git a/Documentation/technical/api-builtin.txt b/Documentation/technical/api-builtin.txt new file mode 100644 index 0000000000..5cb2b0590a --- /dev/null +++ b/Documentation/technical/api-builtin.txt @@ -0,0 +1,68 @@ +builtin API +=========== + +Adding a new built-in +--------------------- + +There are 4 things to do to add a built-in command implementation to +git: + +. Define the implementation of the built-in command `foo` with + signature: + + int cmd_foo(int argc, const char **argv, const char *prefix); + +. 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: + + { "foo", cmd_foo, <options> }, ++ +where options is the bitwise-or of: + +`RUN_SETUP`:: + + 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. + +`USE_PAGER`:: + + If the standard output is connected to a tty, spawn a pager and + feed our output to it. + +`NEED_WORK_TREE`:: + + Make sure there is a work tree, i.e. the command cannot act + on bare repositories. + This only makes sense when `RUN_SETUP` is also set. + +. Add `builtin-foo.o` to `BUILTIN_OBJS` in `Makefile`. + +Additionally, if `foo` is a new command, there are 3 more things to do: + +. Add tests to `t/` directory. + +. Write documentation in `Documentation/git-foo.txt`. + +. Add an entry for `git-foo` to `command-list.txt`. + + +How a built-in is called +------------------------ + +The implementation `cmd_foo()` takes three parameters, `argc`, `argv, +and `prefix`. The first two are similar to what `main()` of a +standalone command would be called with. + +When `RUN_SETUP` is specified in the `commands[]` table, and when you +were started from a subdirectory of the work tree, `cmd_foo()` is called +after chdir(2) to the top of the work tree, and `prefix` gets the path +to the subdirectory the command started from. This allows you to +convert a user-supplied pathname (typically relative to that directory) +to a pathname relative to the top of the work tree. + +The return value from `cmd_foo()` becomes the exit status of the +command. diff --git a/Documentation/technical/api-decorate.txt b/Documentation/technical/api-decorate.txt new file mode 100644 index 0000000000..1d52a6ce14 --- /dev/null +++ b/Documentation/technical/api-decorate.txt @@ -0,0 +1,6 @@ +decorate API +============ + +Talk about <decorate.h> + +(Linus) diff --git a/Documentation/technical/api-diff.txt b/Documentation/technical/api-diff.txt new file mode 100644 index 0000000000..20b0241d30 --- /dev/null +++ b/Documentation/technical/api-diff.txt @@ -0,0 +1,166 @@ +diff API +======== + +The diff API is for programs that compare two sets of files (e.g. two +trees, one tree and the index) and present the found difference in +various ways. The calling program is responsible for feeding the API +pairs of files, one from the "old" set and the corresponding one from +"new" set, that are different. The library called through this API is +called diffcore, and is responsible for two things. + +* finding total rewrites (`-B`), renames (`-M`) and copies (`-C`), and + changes that touch a string (`-S`), as specified by the caller. + +* outputting the differences in various formats, as specified by the + caller. + +Calling sequence +---------------- + +* Prepare `struct diff_options` to record the set of diff options, and + then call `diff_setup()` to initialize this structure. This sets up + the vanilla default. + +* Fill in the options structure to specify desired output format, rename + detection, etc. `diff_opt_parse()` can be used to parse options given + from the command line in a way consistent with existing git-diff + family of programs. + +* 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). + +* As you find different pairs of files, call `diff_change()` to feed + modified files, `diff_addremove()` to feed created or deleted files, + or `diff_unmerged()` to feed a file whose state is 'unmerged' to the + API. These are thin wrappers to a lower-level `diff_queue()` function + that is flexible enough to record any of these kinds of changes. + +* Once you finish feeding the pairs of files, call `diffcore_std()`. + This will tell the diffcore library to go ahead and do its work. + +* Calling `diff_flush()` will produce the output. + + +Data structures +--------------- + +* `struct diff_filespec` + +This is the internal representation for a single file (blob). It +records the blob object name (if known -- for a work tree file it +typically is a NUL SHA-1), filemode and pathname. This is what the +`diff_addremove()`, `diff_change()` and `diff_unmerged()` synthesize and +feed `diff_queue()` function with. + +* `struct diff_filepair` + +This records a pair of `struct diff_filespec`; the filespec for a file +in the "old" set (i.e. preimage) is called `one`, and the filespec for a +file in the "new" set (i.e. postimage) is called `two`. A change that +represents file creation has NULL in `one`, and file deletion has NULL +in `two`. + +A `filepair` starts pointing at `one` and `two` that are from the same +filename, but `diffcore_std()` can break pairs and match component +filespecs with other filespecs from a different filepair to form new +filepair. This is called 'rename detection'. + +* `struct diff_queue` + +This is a collection of filepairs. Notable members are: + +`queue`:: + + An array of pointers to `struct diff_filepair`. This + dynamically grows as you add filepairs; + +`alloc`:: + + The allocated size of the `queue` array; + +`nr`:: + + The number of elements in the `queue` array. + + +* `struct diff_options` + +This describes the set of options the calling program wants to affect +the operation of diffcore library with. + +Notable members are: + +`output_format`:: + The output format used when `diff_flush()` is run. + +`context`:: + Number of context lines to generate in patch output. + +`break_opt`, `detect_rename`, `rename-score`, `rename_limit`:: + Affects the way detection logic for complete rewrites, renames + and copies. + +`abbrev`:: + Number of hexdigits to abbreviate raw format output to. + +`pickaxe`:: + A constant string (can and typically does contain newlines to + look for a block of text, not just a single line) to filter out + the filepairs that do not change the number of strings contained + in its preimage and postimage of the diff_queue. + +`flags`:: + This is mostly a collection of boolean options that affects the + operation, but some do not have anything to do with the diffcore + library. + +BINARY, TEXT;; + Affects the way how a file that is seemingly binary is treated. + +FULL_INDEX;; + Tells the patch output format not to use abbreviated object + names on the "index" lines. + +FIND_COPIES_HARDER;; + Tells the diffcore library that the caller is feeding unchanged + filepairs to allow copies from unmodified files be detected. + +COLOR_DIFF;; + Output should be colored. + +COLOR_DIFF_WORDS;; + Output is a colored word-diff. + +NO_INDEX;; + Tells diff-files that the input is not tracked files but files + in random locations on the filesystem. + +ALLOW_EXTERNAL;; + Tells output routine that it is Ok to call user specified patch + output routine. Plumbing disables this to ensure stable output. + +QUIET;; + Do not show any output. + +REVERSE_DIFF;; + Tells the library that the calling program is feeding the + filepairs reversed; `one` is two, and `two` is one. + +EXIT_WITH_STATUS;; + For communication between the calling program and the options + parser; tell the calling program to signal the presence of + difference using program exit code. + +HAS_CHANGES;; + Internal; used for optimization to see if there is any change. + +SILENT_ON_REMOVE;; + Affects if diff-files shows removed files. + +RECURSIVE, TREE_IN_RECURSIVE;; + Tells if tree traversal done by tree-diff should recursively + descend into a tree object pair that are different in preimage + and postimage set. + +(JC) diff --git a/Documentation/technical/api-directory-listing.txt b/Documentation/technical/api-directory-listing.txt new file mode 100644 index 0000000000..5bbd18f020 --- /dev/null +++ b/Documentation/technical/api-directory-listing.txt @@ -0,0 +1,76 @@ +directory listing API +===================== + +The directory listing API is used to enumerate paths in the work tree, +optionally taking `.git/info/exclude` and `.gitignore` files per +directory into account. + +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: + +`exclude_per_dir`:: + + The name of the file to be read in each directory for excluded + files (typically `.gitignore`). + +`collect_ignored`:: + + Include paths that are to be excluded in the result. + +`show_ignored`:: + + The traversal is for finding just ignored files, not unignored + files. + +`show_other_directories`:: + + Include a directory that is not tracked. + +`hide_empty_directories`:: + + Do not include a directory that is not tracked and is empty. + +`no_gitlinks`:: + + 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:: + +`entries[]`:: + + An array of `struct dir_entry`, each element of which describes + a path. + +`nr`:: + + The number of members in `entries[]` array. + +`alloc`:: + + Internal use; keeps track of allocation of `entries[]` array. + + +Calling sequence +---------------- + +* 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. + +* Set options described in the Data Structure section above. + +* Call `read_directory()`. + +* Use `dir.entries[]`. + +(JC) diff --git a/Documentation/technical/api-gitattributes.txt b/Documentation/technical/api-gitattributes.txt new file mode 100644 index 0000000000..9d97eaa9de --- /dev/null +++ b/Documentation/technical/api-gitattributes.txt @@ -0,0 +1,111 @@ +gitattributes API +================= + +gitattributes mechanism gives a uniform way to associate various +attributes to set of paths. + + +Data Structure +-------------- + +`struct git_attr`:: + + An attribute is an opaque object that is identified by its name. + Pass the name and its length to `git_attr()` function to obtain + the object of this type. The internal representation of this + structure is of no interest to the calling programs. + +`struct git_attr_check`:: + + This structure represents a set of attributes to check in a call + to `git_checkattr()` function, and receives the results. + + +Calling Sequence +---------------- + +* Prepare an array of `struct git_attr_check` to define the list of + attributes you would want to check. To populate this array, you would + need to define necessary attributes by calling `git_attr()` function. + +* Call git_checkattr() to check the attributes for the path. + +* Inspect `git_attr_check` structure to see how each of the attribute in + the array is defined for the path. + + +Attribute Values +---------------- + +An attribute for a path can be in one of four states: Set, Unset, +Unspecified or set to a string, and `.value` member of `struct +git_attr_check` records it. There are three macros to check these: + +`ATTR_TRUE()`:: + + Returns true if the attribute is Set for the path. + +`ATTR_FALSE()`:: + + Returns true if the attribute is Unset for the path. + +`ATTR_UNSET()`:: + + Returns true if the attribute is Unspecified for the path. + +If none of the above returns true, `.value` member points at a string +value of the attribute for the path. + + +Example +------- + +To see how attributes "crlf" and "indent" are set for different paths. + +. Prepare an array of `struct git_attr_check` with two elements (because + we are checking two attributes). Initialize their `attr` member with + pointers to `struct git_attr` obtained by calling `git_attr()`: + +------------ +static struct git_attr_check check[2]; +static void setup_check(void) +{ + if (check[0].attr) + return; /* already done */ + check[0].attr = git_attr("crlf", 4); + check[1].attr = git_attr("ident", 5); +} +------------ + +. Call `git_checkattr()` with the prepared array of `struct git_attr_check`: + +------------ + const char *path; + + setup_check(); + git_checkattr(path, ARRAY_SIZE(check), check); +------------ + +. Act on `.value` member of the result, left in `check[]`: + +------------ + const char *value = check[0].value; + + if (ATTR_TRUE(value)) { + The attribute is Set, by listing only the name of the + attribute in the gitattributes file for the path. + } else if (ATTR_FALSE(value)) { + 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. + } 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 + file for the path by saying "attr=value". + } else if (... other check using value as string ...) { + ... + } +------------ + +(JC) diff --git a/Documentation/technical/api-grep.txt b/Documentation/technical/api-grep.txt new file mode 100644 index 0000000000..a69cc8964d --- /dev/null +++ b/Documentation/technical/api-grep.txt @@ -0,0 +1,8 @@ +grep API +======== + +Talk about <grep.h>, things like: + +* grep_buffer() + +(JC) diff --git a/Documentation/technical/api-hash.txt b/Documentation/technical/api-hash.txt new file mode 100644 index 0000000000..c784d3edcb --- /dev/null +++ b/Documentation/technical/api-hash.txt @@ -0,0 +1,6 @@ +hash API +======== + +Talk about <hash.h> + +(Linus) diff --git a/Documentation/technical/api-history-graph.txt b/Documentation/technical/api-history-graph.txt new file mode 100644 index 0000000000..d6fc90ac7e --- /dev/null +++ b/Documentation/technical/api-history-graph.txt @@ -0,0 +1,174 @@ +history graph API +================= + +The graph API is used to draw a text-based representation of the commit +history. The API generates the graph in a line-by-line fashion. + +Functions +--------- + +Core functions: + +* `graph_init()` creates a new `struct git_graph` + +* `graph_update()` moves the graph to a new commit. + +* `graph_next_line()` outputs the next line of the graph into a strbuf. It + does not add a terminating newline. + +* `graph_padding_line()` outputs a line of vertical padding in the graph. It + is similar to `graph_next_line()`, but is guaranteed to never print the line + containing the current commit. Where `graph_next_line()` would print the + commit line next, `graph_padding_line()` prints a line that simply extends + all branch lines downwards one row, leaving their positions unchanged. + +* `graph_is_commit_finished()` determines if the graph has output all lines + necessary for the current commit. If `graph_update()` is called before all + lines for the current commit have been printed, the next call to + `graph_next_line()` will output an ellipsis, to indicate that a portion of + the graph was omitted. + +The following utility functions are wrappers around `graph_next_line()` and +`graph_is_commit_finished()`. They always print the output to stdout. +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_oneline()` calls `graph_next_line()` and prints the result to + stdout. The line printed does not contain a terminating newline. + +* `graph_show_padding()` calls `graph_padding_line()` and prints the result to + stdout. The line printed does not contain a terminating newline. + +* `graph_show_remainder()` calls `graph_next_line()` until + `graph_is_commit_finished()` returns non-zero. Output is printed to stdout. + The last line printed does not contain a terminating newline. Returns 1 if + output was printed, and 0 if no output was necessary. + +* `graph_show_strbuf()` prints the specified strbuf to stdout, prefixing all + lines but the first with a graph line. The caller is responsible for + ensuring graph output for the first line has already been printed to stdout. + (This can be done with `graph_show_commit()` or `graph_show_oneline()`.) If + a NULL graph is supplied, the strbuf is printed as-is. + +* `graph_show_commit_msg()` is similar to `graph_show_strbuf()`, but it also + prints the remainder of the graph, if more lines are needed after the strbuf + ends. It is better than directly calling `graph_show_strbuf()` followed by + `graph_show_remainder()` since it properly handles buffers that do not end in + a terminating newline. The output printed by `graph_show_commit_msg()` will + end in a newline if and only if the strbuf ends in a newline. + +Data structure +-------------- +`struct git_graph` is an opaque data type used to store the current graph +state. + +Calling sequence +---------------- + +* Create a `struct git_graph` by calling `graph_init()`. When using the + revision walking API, this is done automatically by `setup_revisions()` if + the '--graph' option is supplied. + +* Use the revision walking API to walk through a group of contiguous commits. + The `get_revision()` function automatically calls `graph_update()` each time + it is invoked. + +* For each commit, call `graph_next_line()` repeatedly, until + `graph_is_commit_finished()` returns non-zero. Each call go + `graph_next_line()` will output a single line of the graph. The resulting + lines will not contain any newlines. `graph_next_line()` returns 1 if the + resulting line contains the current commit, or 0 if this is merely a line + needed to adjust the graph before or after the current commit. This return + value can be used to determine where to print the commit summary information + alongside the graph output. + +Limitations +----------- + +* `graph_update()` must be called with commits in topological order. It should + not be called on a commit if it has already been invoked with an ancestor of + that commit, or the graph output will be incorrect. + +* `graph_update()` must be called on a contiguous group of commits. If + `graph_update()` is called on a particular commit, it should later be called + on all parents of that commit. Parents must not be skipped, or the graph + output will appear incorrect. ++ +`graph_update()` may be used on a pruned set of commits only if the parent list +has been rewritten so as to include only ancestors from the pruned set. + +* The graph API does not currently support reverse commit ordering. In + order to implement reverse ordering, the graphing API needs an + (efficient) mechanism to find the children of a commit. + +Sample usage +------------ + +------------ +struct commit *commit; +struct git_graph *graph = graph_init(opts); + +while ((commit = get_revision(opts)) != NULL) { + graph_update(graph, commit); + while (!graph_is_commit_finished(graph)) + { + struct strbuf sb; + int is_commit_line; + + strbuf_init(&sb, 0); + is_commit_line = graph_next_line(graph, &sb); + fputs(sb.buf, stdout); + + if (is_commit_line) + log_tree_commit(opts, commit); + else + putchar(opts->diffopt.line_termination); + } +} +------------ + +Sample output +------------- + +The following is an example of the output from the graph API. This output does +not include any commit summary information--callers are responsible for +outputting that information, if desired. + +------------ +* +* +* +|\ +* | +| | * +| \ \ +| \ \ +*-. \ \ +|\ \ \ \ +| | * | | +| | | | | * +| | | | | * +| | | | | * +| | | | | |\ +| | | | | | * +| * | | | | | +| | | | | * \ +| | | | | |\ | +| | | | * | | | +| | | | * | | | +* | | | | | | | +| |/ / / / / / +|/| / / / / / +* | | | | | | +|/ / / / / / +* | | | | | +| | | | | * +| | | | |/ +| | | | * +------------ diff --git a/Documentation/technical/api-in-core-index.txt b/Documentation/technical/api-in-core-index.txt new file mode 100644 index 0000000000..adbdbf5d75 --- /dev/null +++ b/Documentation/technical/api-in-core-index.txt @@ -0,0 +1,21 @@ +in-core index API +================= + +Talk about <read-cache.c> and <cache-tree.c>, things like: + +* cache -> the_index macros +* read_index() +* write_index() +* ie_match_stat() and ie_modified(); how they are different and when to + use which. +* index_name_pos() +* remove_index_entry_at() +* remove_file_from_index() +* add_file_to_index() +* add_index_entry() +* refresh_index() +* discard_index() +* cache_tree_invalidate_path() +* cache_tree_update() + +(JC, Linus) diff --git a/Documentation/technical/api-index-skel.txt b/Documentation/technical/api-index-skel.txt new file mode 100644 index 0000000000..af7cc2e395 --- /dev/null +++ b/Documentation/technical/api-index-skel.txt @@ -0,0 +1,15 @@ +GIT API Documents +================= + +GIT has grown a set of internal API over time. This collection +documents them. + +//////////////////////////////////////////////////////////////// +// table of contents begin +//////////////////////////////////////////////////////////////// + +//////////////////////////////////////////////////////////////// +// table of contents end +//////////////////////////////////////////////////////////////// + +2007-11-24 diff --git a/Documentation/technical/api-index.sh b/Documentation/technical/api-index.sh new file mode 100755 index 0000000000..9c3f4131b8 --- /dev/null +++ b/Documentation/technical/api-index.sh @@ -0,0 +1,28 @@ +#!/bin/sh + +( + c=//////////////////////////////////////////////////////////////// + skel=api-index-skel.txt + sed -e '/^\/\/ table of contents begin/q' "$skel" + echo "$c" + + ls api-*.txt | + while read filename + do + case "$filename" in + api-index-skel.txt | api-index.txt) continue ;; + esac + title=$(sed -e 1q "$filename") + html=${filename%.txt}.html + echo "* link:$html[$title]" + done + echo "$c" + sed -n -e '/^\/\/ table of contents end/,$p' "$skel" +) >api-index.txt+ + +if test -f api-index.txt && cmp api-index.txt api-index.txt+ >/dev/null +then + rm -f api-index.txt+ +else + mv api-index.txt+ api-index.txt +fi diff --git a/Documentation/technical/api-lockfile.txt b/Documentation/technical/api-lockfile.txt new file mode 100644 index 0000000000..dd894043ae --- /dev/null +++ b/Documentation/technical/api-lockfile.txt @@ -0,0 +1,74 @@ +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. + + +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. + +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). + +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. + +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. diff --git a/Documentation/technical/api-object-access.txt b/Documentation/technical/api-object-access.txt new file mode 100644 index 0000000000..03bb0e950d --- /dev/null +++ b/Documentation/technical/api-object-access.txt @@ -0,0 +1,15 @@ +object access API +================= + +Talk about <sha1_file.c> and <object.h> family, things like + +* read_sha1_file() +* read_object_with_reference() +* has_sha1_file() +* write_sha1_file() +* pretend_sha1_file() +* lookup_{object,commit,tag,blob,tree} +* parse_{object,commit,tag,blob,tree} +* Use of object flags + +(JC, Shawn, Daniel, Dscho, Linus) diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt new file mode 100644 index 0000000000..50f9e9ac17 --- /dev/null +++ b/Documentation/technical/api-parse-options.txt @@ -0,0 +1,251 @@ +parse-options API +================= + +The parse-options API is used to parse and massage options in git +and to provide a usage help with consistent look. + +Basics +------ + +The argument vector `argv[]` may usually contain mandatory or optional +'non-option arguments', e.g. a filename or a branch, and 'options'. +Options are optional arguments that start with a dash and +that allow to change the behavior of a command. + +* There are basically three types of options: + 'boolean' options, + options with (mandatory) 'arguments' and + options with 'optional arguments' + (i.e. a boolean option that can be adjusted). + +* 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 + alphanumeric characters. + +* Options are case-sensitive. + Please define 'lower-case long options' only. + +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. + +* Long options may be 'abbreviated', as long as the abbreviation + is unambiguous. + +* 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`. + +* 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 +---------------------- + +. `#include "parse-options.h"` + +. define a NULL-terminated + `static const char * const builtin_foo_usage[]` array + containing alternative usage strings + +. define `builtin_foo_options` array as described below + in section 'Data Structure'. + +. in `cmd_foo(int argc, const char **argv, const char *prefix)` + call + + argc = parse_options(argc, argv, prefix, builtin_foo_options, builtin_foo_usage, flags); ++ +`parse_options()` will filter out the processed options of `argv[]` and leave the +non-option arguments in `argv[]`. +`argc` is updated appropriately because of the assignment. ++ +You can also pass NULL instead of a usage array as the fifth parameter of +parse_options(), to avoid displaying a help screen with usage info and +option list. This should only be done if necessary, e.g. to implement +a limited parser for only a subset of the options that needs to be run +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 + non-option arguments. + +`PARSE_OPT_STOP_AT_NON_OPTION`:: + Usually the whole argument vector is massaged and reordered. + Using this flag, processing is stopped at the first non-option + argument. + +`PARSE_OPT_KEEP_ARGV0`:: + Keep the first argument, which contains the program name. It's + removed from argv[] by default. + +`PARSE_OPT_KEEP_UNKNOWN`:: + Keep unknown arguments instead of erroring out. This doesn't + work for all combinations of arguments as users might expect + it to do. E.g. if the first argument in `--unknown --known` + takes a value (which we can't know), the second one is + mistakenly interpreted as a known option. Similarly, if + `PARSE_OPT_STOP_AT_NON_OPTION` is set, the second argument in + `--unknown value` will be mistakenly interpreted as a + non-option, not as a value belonging to the unknown option, + the parser early. That's why parse_options() errors out if + both options are set. + +`PARSE_OPT_NO_INTERNAL_HELP`:: + By default, parse_options() handles `-h`, `--help` and + `--help-all` internally, by showing a help screen. This option + turns it off and allows one to add custom handlers for these + options, or to just leave them unknown. + +Data Structure +-------------- + +The main data structure is an array of the `option` struct, +say `static struct option builtin_add_options[]`. +There are some macros to easily define options: + +`OPT__ABBREV(&int_var)`:: + Add `\--abbrev[=<n>]`. + +`OPT__DRY_RUN(&int_var)`:: + Add `-n, \--dry-run`. + +`OPT__QUIET(&int_var)`:: + Add `-q, \--quiet`. + +`OPT__VERBOSE(&int_var)`:: + Add `-v, \--verbose`. + +`OPT_GROUP(description)`:: + Start an option group. `description` is a short string that + describes the group or an empty string. + Start the description with an upper-case letter. + +`OPT_BOOLEAN(short, long, &int_var, description)`:: + Introduce a boolean option. + `int_var` is incremented on each use. + +`OPT_BIT(short, long, &int_var, description, mask)`:: + Introduce a boolean option. + If used, `int_var` is bitwise-ored with `mask`. + +`OPT_NEGBIT(short, long, &int_var, description, mask)`:: + Introduce a boolean option. + If used, `int_var` is bitwise-anded with the inverted `mask`. + +`OPT_SET_INT(short, long, &int_var, description, integer)`:: + Introduce a boolean option. + If used, set `int_var` to `integer`. + +`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`. + +`OPT_INTEGER(short, long, &int_var, description)`:: + Introduce an option with integer argument. + The integer is put into `int_var`. + +`OPT_DATE(short, long, &int_var, description)`:: + Introduce an option with date argument, see `approxidate()`. + 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` + and the result will be put into `var`. + See 'Option Callbacks' below for a more elaborate description. + +`OPT_FILENAME(short, long, &var, description)`:: + Introduce an option with a filename argument. + The filename will be prefixed by passing the filename along with + the prefix argument of `parse_options()` to `prefix_filename()`. + +`OPT_ARGUMENT(long, description)`:: + Introduce a long-option argument that will be kept in `argv[]`. + +`OPT_NUMBER_CALLBACK(&var, description, func_ptr)`:: + Recognize numerical options like -123 and feed the integer as + if it was an argument to the function given by `func_ptr`. + The result will be put into `var`. There can be only one such + option definition. It cannot be negated and it takes no + arguments. Short options that happen to be digits take + precedence over it. + + +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. `\'e\'` for `-e`, use `0` to omit), + +* `long` is a string for the long option + (e.g. `"example"` for `\--example`, use `NULL` to omit), + +* `int_var` is an integer variable, + +* `str_var` is a string variable (`char *`), + +* `arg_str` is the string that is shown as argument + (e.g. `"branch"` will result in `<branch>`). + If set to `NULL`, three dots (`...`) will be displayed. + +* `description` is a short string to describe the effect of the option. + It shall begin with a lower-case letter and a full stop (`.`) shall be + omitted at the end. + +Option Callbacks +---------------- + +The function must be defined in this form: + + int func(const struct option *opt, const char *arg, int unset) + +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 + use `OPT_CALLBACK()`. + 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 + value will invoke `usage_with_options()` and, thus, die. + +* If the user negates the option, `arg` is `NULL` and `unset` is 1. + +Sophisticated option parsing +---------------------------- + +If you need, for example, option callbacks with optional arguments +or without arguments at all, or if you need other special cases, +that are not handled by the macros above, you need to specify the +members of the `option` structure manually. + +This is not covered in this document, but well documented +in `parse-options.h` itself. + +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` +for real-world examples. diff --git a/Documentation/technical/api-quote.txt b/Documentation/technical/api-quote.txt new file mode 100644 index 0000000000..e8a1bce94e --- /dev/null +++ b/Documentation/technical/api-quote.txt @@ -0,0 +1,10 @@ +quote API +========= + +Talk about <quote.h>, things like + +* sq_quote and unquote +* c_style quote and unquote +* quoting for foreign languages + +(JC) diff --git a/Documentation/technical/api-remote.txt b/Documentation/technical/api-remote.txt new file mode 100644 index 0000000000..c54b17db69 --- /dev/null +++ b/Documentation/technical/api-remote.txt @@ -0,0 +1,127 @@ +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 +fashion. Note that the code also handles plain URLs without any +configuration, giving them just the default information. + +struct remote +------------- + +`name`:: + + The user's nickname for the remote + +`url`:: + + An array of all of the url_nr URLs configured for the remote + +`pushurl`:: + + An array of all of the pushurl_nr push URLs configured for the remote + +`push`:: + + An array of refspecs configured for pushing, with + push_refspec being the literal strings, and push_refspec_nr + being the quantity. + +`fetch`:: + + An array of refspecs configured for fetching, with + fetch_refspec being the literal strings, and fetch_refspec_nr + being the quantity. + +`fetch_tags`:: + + The setting for whether to fetch tags (as a separate rule from + the configured refspecs); -1 means never to fetch tags, 0 + means to auto-follow tags based on the default heuristic, 1 + means to always auto-follow tags, and 2 means to fetch all + tags. + +`receivepack`, `uploadpack`:: + + The configured helper programs to run on the remote side, for + git-native protocols. + +`http_proxy`:: + + The proxy to use for curl (http, https, ftp, etc.) URLs. + +struct remotes can be found by name with remote_get(), and iterated +through with for_each_remote(). remote_get(NULL) will return the +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 "". + +This parsing can be done to an array of strings to give an array of +struct refpsecs with parse_ref_spec(). + +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 +result is in the "fetch" specification for the remote (note that this +evaluates patterns and returns a single result). + +struct branch +------------- + +Note that this may end up moving to branch.h + +struct branch holds the configuration for a branch. It can be looked +up with branch_get(name) for "refs/heads/{name}", or with +branch_get(NULL) for HEAD. + +It contains: + +`name`:: + + The short name of the branch. + +`refname`:: + + The full path for the branch ref. + +`remote_name`:: + + The name of the remote listed in the configuration. + +`remote`:: + + The struct remote for that remote. + +`merge_name`:: + + An array of the "merge" lines in the configuration. + +`merge`:: + + An array of the struct refspecs used for the merge lines. That + is, merge[i]->dst is a local tracking ref which should be + merged into this branch by default. + +`merge_nr`:: + + The number of merge configurations + +branch_has_merge_config() returns true if the given branch has merge +configuration given. + +Other stuff +----------- + +There is other stuff in remote.h that is related, in general, to the +process of interacting with remotes. + +(Daniel Barkalow) diff --git a/Documentation/technical/api-revision-walking.txt b/Documentation/technical/api-revision-walking.txt new file mode 100644 index 0000000000..996da0503a --- /dev/null +++ b/Documentation/technical/api-revision-walking.txt @@ -0,0 +1,67 @@ +revision walking API +==================== + +The revision walking API offers functions to build a list of revisions +and then iterate over that list. + +Calling sequence +---------------- + +The walking API has a given calling sequence: first you need to +initialize a rev_info structure, then add revisions to control what kind +of revision list do you want to get, finally you can iterate over the +revision list. + +Functions +--------- + +`init_revisions`:: + + Initialize a rev_info structure with default values. The second + parameter may be NULL or can be prefix path, and then the `.prefix` + variable will be set to it. This is typically the first function you + want to call when you want to deal with a revision list. After calling + this function, you are free to customize options, like set + `.ignore_merges` to 0 if you don't want to ignore merges, and so on. See + `revision.h` for a complete list of available options. + +`add_pending_object`:: + + This function can be used if you want to add commit objects as revision + information. You can use the `UNINTERESTING` object flag to indicate if + you want to include or exclude the given commit (and commits reachable + from the given commit) from the revision list. ++ +NOTE: If you have the commits as a string list then you probably want to +use setup_revisions(), instead of parsing each string and using this +function. + +`setup_revisions`:: + + Parse revision information, filling in the `rev_info` structure, and + removing the used arguments from the argument list. Returns the number + of arguments left that weren't recognized, which are also moved to the + head of the argument list. The last parameter is used in case no + parameter given by the first two arguments. + +`prepare_revision_walk`:: + + Prepares the rev_info structure for a walk. You should check if it + returns any error (non-zero return code) and if it does not, you can + start using get_revision() to do the iteration. + +`get_revision`:: + + Takes a pointer to a `rev_info` structure and iterates over it, + returning a `struct commit *` each time you call it. The end of the + revision list is indicated by returning a NULL pointer. + +Data structures +--------------- + +Talk about <revision.h>, things like: + +* two diff_options, one for path limiting, another for output; +* remaining functions; + +(Linus, JC, Dscho) diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt new file mode 100644 index 0000000000..b26c28133c --- /dev/null +++ b/Documentation/technical/api-run-command.txt @@ -0,0 +1,212 @@ +run-command API +=============== + +The run-command API offers a versatile tool to run sub-processes with +redirected input and output as well as with a modified environment +and an alternate current directory. + +A similar API offers the capability to run a function asynchronously, +which is primarily used to capture the output that the function +produces in the caller in order to process it. + + +Functions +--------- + +`start_command`:: + + Start a sub-process. Takes a pointer to a `struct child_process` + that specifies the details and returns pipe FDs (if requested). + See below for details. + +`finish_command`:: + + Wait for the completion of a sub-process that was started with + start_command(). + +`run_command`:: + + A convenience function that encapsulates a sequence of + start_command() followed by finish_command(). Takes a pointer + to a `struct child_process` that specifies the details. + +`run_command_v_opt`, `run_command_v_opt_cd_env`:: + + Convenience functions that encapsulate a sequence of + start_command() followed by finish_command(). The argument argv + specifies the program and its arguments. The argument opt is zero + or more of the flags `RUN_COMMAND_NO_STDIN`, `RUN_GIT_CMD`, + `RUN_COMMAND_STDOUT_TO_STDERR`, or `RUN_SILENT_EXEC_FAILURE` + that correspond to the members .no_stdin, .git_cmd, + .stdout_to_stderr, .silent_exec_failure of `struct child_process`. + The argument dir corresponds the member .dir. The argument env + corresponds to the member .env. + +The functions above do the following: + +. If a system call failed, errno is set and -1 is returned. A diagnostic + is printed. + +. If the program was not found, then -1 is returned and errno is set to + ENOENT; a diagnostic is printed only if .silent_exec_failure is 0. + +. Otherwise, the program is run. If it terminates regularly, its exit + code is returned. No diagnistic is printed, even if the exit code is + 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. + + +`start_async`:: + + Run a function asynchronously. Takes a pointer to a `struct + async` that specifies the details and returns a pipe FD + from which the caller reads. See below for details. + +`finish_async`:: + + Wait for the completion of an asynchronous function that was + started with start_async(). + +`run_hook`:: + + Run a hook. + The first argument is a pathname to an index file, or NULL + if the hook uses the default index file or no index is needed. + The second argument is the name of the hook. + The further arguments correspond to the hook arguments. + The last argument has to be NULL to terminate the arguments list. + If the hook does not exist or is not executable, the return + value will be zero. + If it is executable, the hook will be executed and the exit + status of the hook is returned. + On execution, .stdout_to_stderr and .no_stdin will be set. + (See below.) + + +Data structures +--------------- + +* `struct child_process` + +This describes the arguments, redirections, and environment of a +command to run in a sub-process. + +The caller: + +1. allocates and clears (memset(&chld, 0, sizeof(chld));) a + struct child_process variable; +2. initializes the members; +3. calls start_command(); +4. processes the data; +5. closes file descriptors (if necessary; see below); +6. calls finish_command(). + +The .argv member is set up as an array of string pointers (NULL +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. + +The members .in, .out, .err are used to redirect stdin, stdout, +stderr as follows: + +. Specify 0 to request no special redirection. No new file descriptor + is allocated. The child process simply inherits the channel from the + parent. + +. Specify -1 to have a pipe allocated; start_command() replaces -1 + by the pipe FD in the following way: + + .in: Returns the writable pipe end into which the caller writes; + the readable end of the pipe becomes the child's stdin. + + .out, .err: Returns the readable pipe end from which the caller + reads; the writable end of the pipe end becomes child's + stdout/stderr. + + The caller of start_command() must close the so returned FDs + after it has completed reading from/writing to it! + +. Specify a file descriptor > 0 to be used by the child: + + .in: The FD must be readable; it becomes child's stdin. + .out: The FD must be writable; it becomes child's stdout. + .err > 0 is not supported. + + The specified FD is closed by start_command(), even if it fails to + run the sub-process! + +. Special forms of redirection are available by setting these members + to 1: + + .no_stdin, .no_stdout, .no_stderr: The respective channel is + redirected to /dev/null. + + .stdout_to_stderr: stdout of the child is redirected to its + stderr. This happens after stderr is itself redirected. + So stdout will follow stderr to wherever it is + redirected. + +To modify the environment of the sub-process, specify an array of +string pointers (NULL terminated) in .env: + +. If the string is of the form "VAR=value", i.e. it contains '=' + the variable is added to the child process's environment. + +. If the string does not contain '=', it names an environment + variable that will be removed from the child process's environment. + +To specify a new initial working directory for the sub-process, +specify it in the .dir member. + +If the program cannot be found, the functions return -1 and set +errno to ENOENT. Normally, an error message is printed, but if +.silent_exec_failure is set to 1, no message is printed for this +special error condition. + + +* `struct async` + +This describes a function to run asynchronously, whose purpose is +to produce output that the caller reads. + +The caller: + +1. allocates and clears (memset(&asy, 0, sizeof(asy));) a + struct async variable; +2. initializes .proc and .data; +3. calls start_async(); +4. processes the data by reading from the fd in .out; +5. closes .out; +6. calls finish_async(). + +The function pointer in .proc has the following signature: + + int proc(int fd, void *data); + +. fd specifies a writable file descriptor to which the function must + write the data that it produces. The function *must* close this + descriptor before it returns. + +. data is the value that the caller has specified in the .data member + of struct async. + +. The return value of the function is 0 on success and non-zero + on failure. If the function indicates failure, finish_async() will + report failure as well. + + +There are serious restrictions on what the asynchronous function can do +because this facility is implemented by a pipe to a forked process on +UNIX, but by a thread in the same address space on Windows: + +. It cannot change the program's state (global variables, environment, + etc.) in a way that the caller notices; in other words, .out is the + only communication channel to the caller. + +. It must not change the program's state that the caller of the + facility also uses. diff --git a/Documentation/technical/api-setup.txt b/Documentation/technical/api-setup.txt new file mode 100644 index 0000000000..4f63a04d7d --- /dev/null +++ b/Documentation/technical/api-setup.txt @@ -0,0 +1,13 @@ +setup API +========= + +Talk about + +* setup_git_directory() +* setup_git_directory_gently() +* is_inside_git_dir() +* is_inside_work_tree() +* setup_work_tree() +* get_pathspec() + +(Dscho) diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt new file mode 100644 index 0000000000..7438149249 --- /dev/null +++ b/Documentation/technical/api-strbuf.txt @@ -0,0 +1,255 @@ +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 you 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 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. ++ +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_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`:: diff --git a/Documentation/technical/api-string-list.txt b/Documentation/technical/api-string-list.txt new file mode 100644 index 0000000000..293bb15d20 --- /dev/null +++ b/Documentation/technical/api-string-list.txt @@ -0,0 +1,128 @@ +string-list API +=============== + +The string_list API offers a data structure and functions to handle sorted +and unsorted string lists. + +The 'string_list' struct used to be called 'path_list', but was renamed +because it is not specific to paths. + +The caller: + +. Allocates and clears a `struct string_list` variable. + +. Initializes the members. You might want to set the flag `strdup_strings` + if the strings should be strdup()ed. For example, this is necessary + when you add something like git_path("..."), since that function returns + a static buffer that will change with the next call to git_path(). ++ +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`. + +. 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`. + +. Finally it should free the list using `string_list_clear`. + +Example: + +---- +struct string_list list; +int i; + +memset(&list, 0, sizeof(struct string_list)); +string_list_append("foo", &list); +string_list_append("bar", &list); +for (i = 0; i < list.nr; i++) + printf("%s\n", list.items[i].string) +---- + +NOTE: It is more efficient to build an unsorted list and sort it +afterwards, instead of building a sorted list (`O(n log n)` instead of +`O(n^2)`). ++ +However, if you use the list to check if a certain string was added +already, you should not do that (using unsorted_string_list_has_string()), +because the complexity would be quadratic again (but with a worse factor). + +Functions +--------- + +* General ones (works with sorted and unsorted lists as well) + +`print_string_list`:: + + Dump a string_list to stdout, useful mainly for debugging purposes. It + can take an optional header argument and it writes out the + string-pointer pairs of the string_list, each one in its own line. + +`string_list_clear`:: + + Free a string_list. The `string` pointer of the items will be freed in + case the `strdup_strings` member of the string_list is set. The second + parameter controls if the `util` pointer of the items should be freed + or not. + +* Functions for sorted lists only + +`string_list_has_string`:: + + Determine if the string_list has a given string or not. + +`string_list_insert`:: + + 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. ++ +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 +write `string_list_insert(...)->util = ...;`. + +`string_list_lookup`:: + + Look up a given string in the string_list, returning the containing + string_list_item. If the string is not found, NULL is returned. + +* Functions for unsorted lists only + +`string_list_append`:: + + Append a new string to the end of the string_list. + +`sort_string_list`:: + + Make an unsorted list sorted. + +`unsorted_string_list_has_string`:: + + It's like `string_list_has_string()` but for unsorted lists. ++ +This function needs to look through all items, as opposed to its +counterpart for sorted lists, which performs a binary search. + +Data structures +--------------- + +* `struct string_list_item` + +Represents an item of the list. The `string` member is a pointer to the +string, and you may use the `util` member for any purpose, if you want. + +* `struct string_list` + +Represents the list itself. + +. The array of items are available via the `items` member. +. The `nr` member contains the number of items stored in the list. +. The `alloc` member is used to avoid reallocating at every insertion. + You should not tamper with it. +. Setting the `strdup_strings` member to 1 will strdup() the strings + before adding them, see above. diff --git a/Documentation/technical/api-tree-walking.txt b/Documentation/technical/api-tree-walking.txt new file mode 100644 index 0000000000..55b728632c --- /dev/null +++ b/Documentation/technical/api-tree-walking.txt @@ -0,0 +1,145 @@ +tree walking API +================ + +The tree walking API is used to traverse and inspect trees. + +Data Structures +--------------- + +`struct name_entry`:: + + An entry in a tree. Each entry has a sha1 identifier, pathname, and + mode. + +`struct tree_desc`:: + + A semi-opaque data structure used to maintain the current state of the + walk. ++ +* `buffer` is a pointer into the memory representation of the tree. It always +points at the current entry being visited. + +* `size` counts the number of bytes left in the `buffer`. + +* `entry` points to the current entry being visited. + +`struct traverse_info`:: + + A structure used to maintain the state of a traversal. ++ +* `prev` points to the traverse_info which was used to descend into the +current tree. If this is the top-level tree `prev` will point to +a dummy traverse_info. + +* `name` is the entry for the current tree (if the tree is a subtree). + +* `pathlen` is the length of the full path for the current tree. + +* `conflicts` can be used by callbacks to maintain directory-file conflicts. + +* `fn` is a callback called for each entry in the tree. See Traversing for more +information. + +* `data` can be anything the `fn` callback would want to use. + +Initializing +------------ + +`init_tree_desc`:: + + Initialize a `tree_desc` and decode its first entry. The buffer and + size parameters are assumed to be the same as the buffer and size + members of `struct tree`. + +`fill_tree_descriptor`:: + + Initialize a `tree_desc` and decode its first entry given the sha1 of + a tree. Returns the `buffer` member if the sha1 is a valid tree + identifier and NULL otherwise. + +`setup_traverse_info`:: + + Initialize a `traverse_info` given the pathname of the tree to start + traversing from. The `base` argument is assumed to be the `path` + member of the `name_entry` being recursed into unless the tree is a + top-level tree in which case the empty string ("") is used. + +Walking +------- + +`tree_entry`:: + + Visit the next entry in a tree. Returns 1 when there are more entries + left to visit and 0 when all entries have been visited. This is + commonly used in the test of a while loop. + +`tree_entry_len`:: + + Calculate the length of a tree entry's pathname. This utilizes the + memory structure of a tree entry to avoid the overhead of using a + generic strlen(). + +`update_tree_entry`:: + + Walk to the next entry in a tree. This is commonly used in conjunction + with `tree_entry_extract` to inspect the current entry. + +`tree_entry_extract`:: + + Decode the entry currently being visited (the one pointed to by + `tree_desc's` `entry` member) and return the sha1 of the entry. The + `pathp` and `modep` arguments are set to the entry's pathname and mode + respectively. + +`get_tree_entry`:: + + Find an entry in a tree given a pathname and the sha1 of a tree to + search. Returns 0 if the entry is found and -1 otherwise. The third + and fourth parameters are set to the entry's sha1 and mode + respectively. + +Traversing +---------- + +`traverse_trees`:: + + Traverse `n` number of trees in parallel. The `fn` callback member of + `traverse_info` is called once for each tree entry. + +`traverse_callback_t`:: + The arguments passed to the traverse callback are as follows: ++ +* `n` counts the number of trees being traversed. + +* `mask` has its nth bit set if something exists in the nth entry. + +* `dirmask` has its nth bit set if the nth tree's entry is a directory. + +* `entry` is an array of size `n` where the nth entry is from the nth tree. + +* `info` maintains the state of the traversal. + ++ +Returning a negative value will terminate the traversal. Otherwise the +return value is treated as an update mask. If the nth bit is set the nth tree +will be updated and if the bit is not set the nth tree entry will be the +same in the next callback invocation. + +`make_traverse_path`:: + + Generate the full pathname of a tree entry based from the root of the + traversal. For example, if the traversal has recursed into another + tree named "bar" the pathname of an entry "baz" in the "bar" + tree would be "bar/baz". + +`traverse_path_len`:: + + Calculate the length of a pathname returned by `make_traverse_path`. + This utilizes the memory structure of a tree entry to avoid the + overhead of using a generic strlen(). + +Authors +------- + +Written by Junio C Hamano <gitster@pobox.com> and Linus Torvalds +<torvalds@linux-foundation.org> diff --git a/Documentation/technical/api-xdiff-interface.txt b/Documentation/technical/api-xdiff-interface.txt new file mode 100644 index 0000000000..6296ecad1d --- /dev/null +++ b/Documentation/technical/api-xdiff-interface.txt @@ -0,0 +1,7 @@ +xdiff interface API +=================== + +Talk about our calling convention to xdiff library, including +xdiff_emit_consume_fn. + +(Dscho, JC) diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt new file mode 100644 index 0000000000..1803e64e46 --- /dev/null +++ b/Documentation/technical/pack-format.txt @@ -0,0 +1,160 @@ +GIT pack format +=============== + += pack-*.pack files have the following format: + + - A header appears at the beginning and consists of the following: + + 4-byte signature: + The signature is: {'P', 'A', 'C', 'K'} + + 4-byte version number (network byte order): + 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) + + Observation: we cannot have more than 4G versions ;-) and + more than 4G objects in a pack. + + - The header is followed by number of object entries, each of + which looks like this: + + (undeltified representation) + n-byte type and length (3-bit type, (n-1)*7+4-bit length) + compressed data + + (deltified representation) + n-byte type and length (3-bit type, (n-1)*7+4-bit length) + 20-byte base object name + 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. + += 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 + objects in the corresponding pack, the first byte of whose + object name is less than or equal to N. This is called the + 'first-level fan-out' table. + + - The header is followed by sorted 24-byte entries, one entry + per object in the pack. Each entry is: + + 4-byte network byte order integer, recording where the + object is stored in the packfile as the offset from the + beginning. + + 20-byte object name. + + - The file is concluded with a trailer: + + A copy of the 20-byte SHA1 checksum at the end of + corresponding packfile. + + 20-byte SHA1-checksum of all of the above. + +Pack Idx file: + + -- +--------------------------------+ +fanout | fanout[0] = 2 (for example) |-. +table +--------------------------------+ | + | fanout[1] | | + +--------------------------------+ | + | fanout[2] | | + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | + | fanout[255] = total objects |---. + -- +--------------------------------+ | | +main | offset | | | +index | object name 00XXXXXXXXXXXXXXXX | | | +table +--------------------------------+ | | + | offset | | | + | object name 00XXXXXXXXXXXXXXXX | | | + +--------------------------------+<+ | + .-| offset | | + | | object name 01XXXXXXXXXXXXXXXX | | + | +--------------------------------+ | + | | offset | | + | | object name 01XXXXXXXXXXXXXXXX | | + | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | + | | offset | | + | | object name FFXXXXXXXXXXXXXXXX | | + --| +--------------------------------+<--+ +trailer | | packfile checksum | + | +--------------------------------+ + | | idxfile checksum | + | +--------------------------------+ + .-------. + | +Pack file entry: <+ + + packed object header: + 1-byte size extension bit (MSB) + type (next 3 bit) + size0 (lower 4-bit) + n-byte sizeN (as long as MSB is set, each 7-bit) + size0..sizeN form 4+7+7+..+7 bit integer, size0 + is the least significant part, and sizeN is the + most significant part. + packed object data: + 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 + size of the delta data that follows). + delta data, deflated. + If it is OFS_DELTA, then + n-byte offset (see below) interpreted as a negative + offset from the type-byte of the header of the + ofs-delta entry (the size above is the size of + the delta data that follows). + delta data, deflated. + + offset encoding: + n bytes with MSB set in all but the last one. + The offset is then the number constructed by + concatenating the lower 7 bit of each byte, and + for n >= 2 adding 2^7 + 2^14 + ... + 2^(7*(n-1)) + to the result. + + + += 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. + + - A 4-byte version number (= 2) + + - A 256-entry fan-out table just like v1. + + - A table of sorted 20-byte SHA1 object names. These are + packed together without offset values to reduce the cache + footprint of the binary search for a specific object name. + + - A table of 4-byte CRC32 values of the packed object data. + This is new in v2 so compressed data can be copied directly + from pack to pack during repacking without undetected + data corruption. + + - A table of 4-byte offset values (in network byte order). + These are usually 31-bit pack file offsets, but large + offsets are encoded as an index into the next table with + the msbit set. + + - A table of 8-byte offset entries (empty for pack files less + than 2 GiB). Pack files are organized with heavily used + objects toward the front, so most object references should + not need to refer to this table. + + - The same trailer as a v1 pack file: + + A copy of the 20-byte SHA1 checksum at the end of + corresponding packfile. + + 20-byte SHA1-checksum of all of the above. diff --git a/Documentation/technical/pack-heuristics.txt b/Documentation/technical/pack-heuristics.txt new file mode 100644 index 0000000000..103eb5d989 --- /dev/null +++ b/Documentation/technical/pack-heuristics.txt @@ -0,0 +1,466 @@ + 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? + +Be careful what you ask! + +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, +Linus Torvalds (linus). Nathaniel Smith, (njs`), has the floor +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 + me not, reading the source didn't help a lot, and wading + through the whole mailing list seems less efficient than any + of that. + +It is a bold start! A plea for help combined with a simultaneous +tri-part attack on some of the tried and true mainstays in the quest +for enlightenment. Brash accusations of google being useless. Hubris! +Maligning the source. Heresy! Disdain for the mailing list archives. +Woe. + + <pasky> yes, the packing-related delta stuff is somewhat + mysterious even for me ;) + +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 + Junio), but packing nobody touched after I did it. + +It's cryptic, yet vague. Linus in style for sure. Wise men +interpret this as an apology. A few argue it is merely a +statement of fact. + + <njs`> I guess the next step is "read the source again", but I + have to build up a certain level of gumption first :-) + +Indeed! On both points. + + <linus> The packing heuristic is actually really really simple. + +Bait... + + <linus> But strange. + +And switch. That ought to do it! + + <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 + can be diffed against another object in the window + - write out the list in recency order + +The traditional understatement: + + <njs`> I suspect that what I'm missing is the precise definition of + the word "magic" + +The traditional insight: + + <pasky> yes + +And Babel-like confusion flowed. + + <njs`> oh, hmm, and I'm not sure what this sliding window means either + + <pasky> iirc, it appeared to me to be just the sha1 of the object + when reading the code casually ... + + ... which simply doesn't sound as a very good heuristics, though ;) + + <njs`> .....and recency order. okay, I think it's clear I didn't + even realize how much I wasn't realizing :-) + +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. + + Before talking about the ordering for the sliding delta + window, let's talk about the recency order. That's more + important in one way. + + <njs`> Right, but if all you want is a working way to pack things + together, you could just use cat and save yourself some + trouble... + +Waaait for it.... + + <linus> The recency ordering (which is basically: put objects + _physically_ into the pack in the order that they are + "reachable" from the head) is important. + + <njs`> okay + + <linus> It's important because that's the thing that gives packs + good locality. It keeps the objects close to the head (whether + they are old or new, but they are _reachable_ from the head) + at the head of the pack. So packs actually have absolutely + _wonderful_ IO patterns. + +Read that again, because it is important. + + <linus> But recency ordering is totally useless for deciding how + to actually generate the deltas, so the delta ordering is + something else. + + The delta ordering is (wait for it): + - first sort by the "basename" of the object, as defined by + the name the object was _first_ reached through when + generating the object list + - within the same basename, sort by size of the object + - but always sort different types separately (commits first). + + That's not exactly it, but it's very close. + + <njs`> The "_first_ reached" thing is not too important, just you + need some way to break ties since the same objects may be + reachable many ways, yes? + +And as if to clarify: + + <linus> The point is that it's all really just any random + heuristic, and the ordering is totally unimportant for + correctness, but it helps a lot if the heuristic gives + "clumping" for things that are likely to delta well against + each other. + +It is an important point, so secretly, I did my own research and have +included my results below. To be fair, it has changed some over time. +And through the magic of Revisionistic History, I draw upon this entry +from The Git IRC Logs on my father's birthday, March 1: + + <gitster> The quote from the above linus should be rewritten a + bit (wait for it): + - first sort by type. Different objects never delta with + each other. + - then sort by filename/dirname. hash of the basename + occupies the top BITS_PER_INT-DIR_BITS bits, and bottom + DIR_BITS are for the hash of leading path elements. + - then if we are doing "thin" pack, the objects we are _not_ + going to pack but we know about are sorted earlier than + other objects. + - and finally sort by size, larger to smaller. + +In one swell-foop, clarification and obscurification! Nonetheless, +authoritative. Cryptic, yet concise. It even solicits notions of +quotes from The Source Code. Clearly, more study is needed. + + <gitster> That's the sort order. What this means is: + - we do not delta different object types. + - we prefer to delta the objects with the same full path, but + allow files with the same name from different directories. + - we always prefer to delta against objects we are not going + to send, if there are some. + - we prefer to delta against larger objects, so that we have + lots of removals. + + The penultimate rule is for "thin" packs. It is used when + the other side is known to have such objects. + +There it is again. "Thin" packs. I'm thinking to myself, "What +is a 'thin' pack?" So I ask: + + <jdl> What is a "thin" pack? + + <gitster> Use of --objects-edge to rev-list as the upstream of + pack-objects. The pack transfer protocol negotiates that. + +Woo hoo! Cleared that _right_ up! + + <gitster> There are two directions - push and fetch. + +There! Did you see it? It is not '"push" and "pull"'! How often the +confusion has started here. So casually mentioned, too! + + <gitster> For push, git-send-pack invokes git-receive-pack on the + other end. The receive-pack says "I have up to these commits". + send-pack looks at them, and computes what are missing from + the other end. So "thin" could be the default there. + + In the other direction, fetch, git-fetch-pack and + git-clone-pack invokes git-upload-pack on the other end + (via ssh or by talking to the daemon). + + There are two cases: fetch-pack with -k and clone-pack is one, + fetch-pack without -k is the other. clone-pack and fetch-pack + with -k will keep the downloaded packfile without expanded, so + we do not use thin pack transfer. Otherwise, the generated + pack will have delta without base object in the same pack. + + But fetch-pack without -k will explode the received pack into + individual objects, so we automatically ask upload-pack to + give us a thin pack if upload-pack supports it. + +OK then. + +Uh. + +Let's return to the previous conversation still in progress. + + <njs`> and "basename" means something like "the tail of end of + path of file objects and dir objects, as per basename(3), and + we just declare all commit and tag objects to have the same + basename" or something? + +Luckily, that too is a point that gitster clarified for us! + +If I might add, the trick is to make files that _might_ be similar be +located close to each other in the hash buckets based on their file +names. It used to be that "foo/Makefile", "bar/baz/quux/Makefile" and +"Makefile" all landed in the same bucket due to their common basename, +"Makefile". However, now they land in "close" buckets. + +The algorithm allows not just for the _same_ bucket, but for _close_ +buckets to be considered delta candidates. The rationale is +essentially that files, like Makefiles, often have very similar +content no matter what directory they live in. + + <linus> I played around with different delta algorithms, and with + making the "delta window" bigger, but having too big of a + sliding window makes it very expensive to generate the pack: + you need to compare every object with a _ton_ of other objects. + + There are a number of other trivial heuristics too, which + basically boil down to "don't bother even trying to delta this + pair" if we can tell before-hand that the delta isn't worth it + (due to size differences, where we can take a previous delta + result into account to decide that "ok, no point in trying + that one, it will be worse"). + + End result: packing is actually very size efficient. It's + somewhat CPU-wasteful, but on the other hand, since you're + really only supposed to do it maybe once a month (and you can + do it during the night), nobody really seems to care. + +Nice Engineering Touch, there. Find when it doesn't matter, and +proclaim it a non-issue. Good style too! + + <njs`> So, just to repeat to see if I'm following, we start by + getting a list of the objects we want to pack, we sort it by + this heuristic (basically lexicographically on the tuple + (type, basename, size)). + + Then we walk through this list, and calculate a delta of + each object against the last n (tunable parameter) objects, + and pick the smallest of these deltas. + +Vastly simplified, but the essence is there! + + <linus> Correct. + + <njs`> And then once we have picked a delta or fulltext to + represent each object, we re-sort by recency, and write them + out in that order. + + <linus> Yup. Some other small details: + +And of course there is the "Other Shoe" Factor too. + + <linus> - We limit the delta depth to another magic value (right + now both the window and delta depth magic values are just "10") + + <njs`> Hrm, my intuition is that you'd end up with really _bad_ IO + patterns, because the things you want are near by, but to + actually reconstruct them you may have to jump all over in + random ways. + + <linus> - When we write out a delta, and we haven't yet written + out the object it is a delta against, we write out the base + object first. And no, when we reconstruct them, we actually + get nice IO patterns, because: + - larger objects tend to be "more recent" (Linus' law: files grow) + - we actively try to generate deltas from a larger object to a + smaller one + - this means that the top-of-tree very seldom has deltas + (i.e. deltas in _practice_ are "backwards deltas") + +Again, we should reread that whole paragraph. Not just because +Linus has slipped Linus's Law in there on us, but because it is +important. Let's make sure we clarify some of the points here: + + <njs`> So the point is just that in practice, delta order and + recency order match each other quite well. + + <linus> Yes. There's another nice side to this (and yes, it was + designed that way ;): + - the reason we generate deltas against the larger object is + actually a big space saver too! + + <njs`> Hmm, but your last comment (if "we haven't yet written out + the object it is a delta against, we write out the base object + first"), seems like it would make these facts mostly + irrelevant because even if in practice you would not have to + wander around much, in fact you just brute-force say that in + the cases where you might have to wander, don't do that :-) + + <linus> Yes and no. Notice the rule: we only write out the base + object first if the delta against it was more recent. That + means that you can actually have deltas that refer to a base + object that is _not_ close to the delta object, but that only + happens when the delta is needed to generate an _old_ object. + + <linus> See? + +Yeah, no. I missed that on the first two or three readings myself. + + <linus> This keeps the front of the pack dense. The front of the + pack never contains data that isn't relevant to a "recent" + object. The size optimization comes from our use of xdelta + (but is true for many other delta algorithms): removing data + is cheaper (in size) than adding data. + + When you remove data, you only need to say "copy bytes n--m". + In contrast, in a delta that _adds_ data, you have to say "add + these bytes: 'actual data goes here'" + + *** njs` has quit: Read error: 104 (Connection reset by peer) + + <linus> Uhhuh. I hope I didn't blow njs` mind. + + *** njs` has joined channel #git + + <pasky> :) + +The silent observers are amused. Of course. + +And as if njs` was expected to be omniscient: + + <linus> njs - did you miss anything? + +OK, I'll spell it out. That's Geek Humor. If njs` was not actually +connected for a little bit there, how would he know if missed anything +while he was disconnected? He's a benevolent dictator with a sense of +humor! Well noted! + + <njs`> Stupid router. Or gremlins, or whatever. + +It's a cheap shot at Cisco. Take 'em when you can. + + <njs`> Yes and no. Notice the rule: we only write out the base + object first if the delta against it was more recent. + + I'm getting lost in all these orders, let me re-read :-) + So the write-out order is from most recent to least recent? + (Conceivably it could be the opposite way too, I'm not sure if + we've said) though my connection back at home is logging, so I + can just read what you said there :-) + +And for those of you paying attention, the Omniscient Trick has just +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. + + <linus> With the caveat that if the "most recent" needs an older + object to delta against (hey, shrinking sometimes does + happen), we write out the old object with the delta. + + <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 + for on-disk, it has a few pessimizations. + +Actually, it is a made-up word. But it is a made-up word being +used as setup for a later optimization, which is a real word: + + <linus> In particular, while the pack-file is then compressed, + it's compressed just one object at a time, so the actual + compression factor is less than it could be in theory. But it + means that it's all nice random-access with a simple index to + do "object name->location in packfile" translation. + + <njs`> I'm assuming the real win for delta-ing large->small is + more homogeneous statistics for gzip to run over? + + (You have to put the bytes in one place or another, but + putting them in a larger blob wins on compression) + + Actually, what is the compression strategy -- each delta + individually gzipped, the whole file gzipped, somewhere in + between, no compression at all, ....? + + Right. + +Reality IRC sets in. For example: + + <pasky> I'll read the rest in the morning, I really have to go + sleep or there's no hope whatsoever for me at the today's + exam... g'nite all. + +Heh. + + <linus> pasky: g'nite + + <njs`> pasky: 'luck + + <linus> Right: large->small matters exactly because of compression + behaviour. If it was non-compressed, it probably wouldn't make + any difference. + + <njs`> yeah + + <linus> Anyway: I'm not even trying to claim that the pack-files + are perfect, but they do tend to have a nice balance of + density vs ease-of use. + +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_ + 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 + straightforward. + + It's all been quite stable. + + Which I think is very much a result of having very simple + basic ideas, so that there's never any confusion about what's + going on. + + Bugs happen, but they are "simple" bugs. And bugs that + actually get some object store detail wrong are almost always + so obvious that they never go anywhere. + + <njs`> Yeah. + +Nuff said. + + <linus> Anyway. I'm off for bed. It's not 6AM here, but I've got + three kids, and have to get up early in the morning to send + them off. I need my beauty sleep. + + <njs`> :-) + + <njs`> appreciate the infodump, I really was failing to find the + 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 new file mode 100644 index 0000000000..7950eeeda4 --- /dev/null +++ b/Documentation/technical/pack-protocol.txt @@ -0,0 +1,494 @@ +Packfile transfer protocols +=========================== + +Git supports transferring data in packfiles over the ssh://, git:// and +file:// transports. There exist two sets of protocols, one for pushing +data from a client to a server and another for fetching data from a +server to a client. All three transports (ssh, git, file) use the same +protocol to transfer data. + +The processes invoked in the canonical Git implementation are 'upload-pack' +on the server side and 'fetch-pack' on the client side for fetching data; +then 'receive-pack' on the server and 'send-pack' on the client for pushing +data. The protocol functions to have a server tell a client what is +currently on the server, then for the two to negotiate the smallest amount +of data to send in order to fully update one or the other. + +Transports +---------- +There are three transports over which the packfile protocol is +initiated. The Git transport is a simple, unauthenticated server that +takes the command (almost always 'upload-pack', though Git +servers can be configured to be globally writable, in which 'receive- +pack' initiation is also allowed) with which the client wishes to +communicate and executes it and connects it to the requesting +process. + +In the SSH transport, the client just runs the 'upload-pack' +or 'receive-pack' process on the server over the SSH protocol and then +communicates with that invoked process over the SSH connection. + +The file:// transport runs the 'upload-pack' or 'receive-pack' +process locally and communicates with it over a pipe. + +Git Transport +------------- + +The Git transport starts off by sending the command and repository +on the wire using the pkt-line format, followed by a NUL byte and a +hostname paramater, terminated by a NUL byte. + + 0032git-upload-pack /project.git\0host=myserver.com\0 + +-- + git-proto-request = request-command SP pathname NUL [ host-parameter NUL ] + request-command = "git-upload-pack" / "git-receive-pack" / + "git-upload-archive" ; case sensitive + pathname = *( %x01-ff ) ; exclude NUL + host-parameter = "host=" hostname [ ":" port ] +-- + +Only host-parameter is allowed in the git-proto-request. Clients +MUST NOT attempt to send additional parameters. It is used for the +git-daemon name based virtual hosting. See --interpolated-path +option to git daemon, with the %H/%CH format characters. + +Basically what the Git client is doing to connect to an 'upload-pack' +process on the server side over the Git protocol is this: + + $ echo -e -n \ + "0039git-upload-pack /schacon/gitbook.git\0host=example.com\0" | + nc -v example.com 9418 + + +SSH Transport +------------- + +Initiating the upload-pack or receive-pack processes over SSH is +executing the binary on the server via SSH remote execution. +It is basically equivalent to running this: + + $ ssh git.example.com "git-upload-pack '/project.git'" + +For a server to support Git pushing and pulling for a given user over +SSH, that user needs to be able to execute one or both of those +commands via the SSH shell that they are provided on login. On some +systems, that shell access is limited to only being able to run those +two commands, or even just one of them. + +In an ssh:// format URI, it's absolute in the URI, so the '/' after +the host name (or port number) is sent as an argument, which is then +read by the remote git-upload-pack exactly as is, so it's effectively +an absolute path in the remote filesystem. + + git clone ssh://user@example.com/project.git + | + v + ssh user@example.com "git-upload-pack '/project.git'" + +In a "user@host:path" format URI, its relative to the user's home +directory, because the Git client will run: + + git clone user@example.com:project.git + | + v + ssh user@example.com "git-upload-pack 'project.git'" + +The exception is if a '~' is used, in which case +we execute it without the leading '/'. + + ssh://user@example.com/~alice/project.git, + | + v + ssh user@example.com "git-upload-pack '~alice/project.git'" + +A few things to remember here: + +- The "command name" is spelled with dash (e.g. git-upload-pack), but + this can be overridden by the client; + +- 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 +what data the server has that the client does not then streams that +data down to the client in packfile format. + + +Reference Discovery +------------------- + +When the client initially connects the server will immediately respond +with a listing of each reference it has (all branches and tags) along +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 + 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration + 003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master + 003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9 + 003c525128480b96c89e6418b1e40909bf6c5b2d580f refs/tags/v1.0 + 003fe92df48743b7bc7d26bcaabfddde0a1e20cae47c refs/tags/v1.0^{} + 0000 + +Server SHOULD terminate each non-flush line using LF ("\n") terminator; +client MUST NOT complain if there is no terminator. + +The returned response is a pkt-line stream describing each ref and +its current value. The stream MUST be sorted by name according to +the C locale ordering. + +If HEAD is a valid ref, HEAD MUST appear as the first advertised +ref. If HEAD is not a valid ref, HEAD MUST NOT appear in the +advertisement list at all, but other refs may still appear. + +The stream MUST include capability declarations behind a NUL on the +first ref. The peeled value of a ref (that is "ref^{}") MUST be +immediately after the ref itself, if presented. A conforming server +MUST peel the ref if its an annotated tag. + +---- + advertised-refs = (no-refs / list-of-refs) + flush-pkt + + no-refs = PKT-LINE(zero-id SP "capabilities^{}" + NUL capability-list LF) + + list-of-refs = first-ref *other-ref + first-ref = PKT-LINE(obj-id SP refname + NUL capability-list LF) + + other-ref = PKT-LINE(other-tip / other-peeled) + other-tip = obj-id SP refname LF + other-peeled = obj-id SP refname "^{}" LF + + capability-list = capability *(SP capability) + capability = 1*(LC_ALPHA / DIGIT / "-" / "_") + LC_ALPHA = %x61-7A +---- + +Server and client MUST use lowercase for obj-id, both MUST treat obj-id +as case-insensitive. + +See protocol-capabilities.txt for a list of allowed server capabilities +and descriptions. + +Packfile Negotiation +-------------------- +After reference and capabilities discovery, the client can decide +to terminate the connection by sending a flush-pkt, telling the +server it can now gracefully terminate (as happens with the ls-remote +command) or it can enter the negotiation phase, where the client and +server determine what the minimal packfile necessary for transport is. + +Once the client has the initial list of references that the server +has, as well as the list of capabilities, it will begin telling the +server what objects it wants and what objects it has, so the server +can make a packfile that only contains the objects that the client needs. +The client will also send a list of the capabilities it wants to be in +effect, out of what the server said it could do with the first 'want' line. + +---- + upload-request = want-list + have-list + compute-end + + want-list = first-want + *additional-want + flush-pkt + + first-want = PKT-LINE("want" SP obj-id SP capability-list LF) + additional-want = PKT-LINE("want" SP obj-id LF) + + have-list = *have-line + have-line = PKT-LINE("have" SP obj-id LF) + compute-end = flush-pkt / PKT-LINE("done") +---- + +Clients MUST send all the obj-ids it wants from the reference +discovery phase as 'want' lines. Clients MUST send at least one +'want' command in the request body. Clients MUST NOT mention an +obj-id in a 'want' command which did not appear in the response +obtained through ref discovery. + +If client is requesting a shallow clone, it will now send a 'deepen' +line with the depth it is requesting. + +Once all the "want"s (and optional 'deepen') are transferred, +clients MUST send a flush-pkt. If the client has all the references +on the server, client flushes and disconnects. + +TODO: shallow/unshallow response and document the deepen command in the ABNF. + +Now the client will send a list of the obj-ids it has using 'have' +lines. In multi_ack mode, the canonical implementation will send up +to 32 of these at a time, then will send a flush-pkt. The canonical +implementation will skip ahead and send the next 32 immediately, +so that there is always a block of 32 "in-flight on the wire" at a +time. + +If the server reads 'have' lines, it then will respond by ACKing any +of the obj-ids the client said it had that the server also has. The +server will ACK obj-ids differently depending on which ack mode is +chosen by the client. + +In multi_ack mode: + + * the server will respond with 'ACK obj-id continue' for any common + commits. + + * once the server has found an acceptable common base commit and is + ready to make a packfile, it will blindly ACK all 'have' obj-ids + back to the client. + + * the server will then send a 'NACK' and then wait for another response + from the client - either a 'done' or another list of 'have' lines. + +In multi_ack_detailed mode: + + * the server will differentiate the ACKs where it is signaling + that it is ready to send data with 'ACK obj-id ready' lines, and + signals the identified common commits with 'ACK obj-id common' lines. + +Without either multi_ack or multi_ack_detailed: + + * upload-pack sends "ACK obj-id" on the first common object it finds. + After that it says nothing until the client gives it a "done". + + * upload-pack sends "NAK" on a flush-pkt if no common object + has been found yet. If one has been found, and thus an ACK + was already sent, its silent on the flush-pkt. + +After the client has gotten enough ACK responses that it can determine +that the server has enough information to send an efficient packfile +(in the canonical implementation, this is determined when it has received +enough ACKs that it can color everything left in the --date-order queue +as common with the server, or the --date-order queue is empty), or the +client determines that it wants to give up (in the canonical implementation, +this is determined when the client sends 256 'have' lines without getting +any of them ACKed by the server - meaning there is nothing in common and +the server should just send all it's objects), then the client will send +a 'done' command. The 'done' command signals to the server that the client +is ready to receive it's packfile data. + +However, the 256 limit *only* turns on in the canonical client +implementation if we have received at least one "ACK %s continue" +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 +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. + +Then the server will start sending it's packfile data. + +---- + server-response = *ack_multi ack / nak + ack_multi = PKT-LINE("ACK" SP obj-id ack_status LF) + ack_status = "continue" / "common" / "ready" + ack = PKT-LINE("ACK SP obj-id LF) + nak = PKT-LINE("NAK" LF) +---- + +A simple clone may look like this (with no 'have' lines): + +---- + C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\0multi_ack \ + side-band-64k ofs-delta\n + C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n + C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n + C: 0032want 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01\n + C: 0032want 74730d410fcb6603ace96f1dc55ea6196122532d\n + C: 0000 + C: 0009done\n + + S: 0008NAK\n + S: [PACKFILE] +---- + +An incremental update (fetch) response might look like this: + +---- + C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\0multi_ack \ + side-band-64k ofs-delta\n + C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n + C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n + C: 0000 + C: 0032have 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01\n + C: [30 more have lines] + C: 0032have 74730d410fcb6603ace96f1dc55ea6196122532d\n + C: 0000 + + S: 003aACK 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01 continue\n + S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d continue\n + S: 0008NAK\n + + C: 0009done\n + + S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d\n + S: [PACKFILE] +---- + + +Packfile Data +------------- + +Now that the client and server have finished negotiation about what +the minimal amount of data that needs to be sent to the client is, the server +will construct and send the required data in packfile format. + +See pack-format.txt for what the packfile itself actually looks like. + +If 'side-band' or 'side-band-64k' capabilities have been specified by +the client, the server will send the packfile data multiplexed. + +Each packet starting with the packet-line length of the amount of data +that follows, followed by a single byte specifying the sideband the +following data is coming in on. + +In 'side-band' mode, it will send up to 999 data bytes plus 1 control +code, for a total of up to 1000 bytes in a pkt-line. In 'side-band-64k' +mode it will send up to 65519 data bytes plus 1 control code, for a +total of up to 65520 bytes in a pkt-line. + +The sideband byte will be a '1', '2' or a '3'. Sideband '1' will contain +packfile data, sideband '2' will be used for progress information that the +client will generally print to stderr and sideband '3' is used for error +information. + +If no 'side-band' capability was specified, the server will stream the +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 +update and then send all the data the server will need for those new +references to be complete. Once all the data is received and validated, +the server will then update its references to what the client specified. + +Authentication +-------------- + +The protocol itself contains no authentication mechanisms. That is to be +handled by the transport, such as SSH, before the 'receive-pack' process is +invoked. If 'receive-pack' is configured over the Git transport, those +repositories will be writable by anyone who can access that port (9418) as +that transport is unauthenticated. + +Reference Discovery +------------------- + +The reference discovery phase is done nearly the same way as it is in the +fetching protocol. Each reference obj-id and name on the server is sent +in packet-line format to the client, followed by a flush-pkt. The only +real difference is that the capability listing is different - the only +possible values are 'report-status', 'delete-refs' and 'ofs-delta'. + +Reference Update Request and Packfile Transfer +---------------------------------------------- + +Once the client knows what references the server is at, it can send a +list of reference update requests. For each reference on the server +that it wants to update, it sends a line listing the obj-id currently on +the server, the obj-id the client would like to update it to and the name +of the reference. + +This list is followed by a flush-pkt and then the packfile that should +contain all the objects that the server will need to complete the new +references. + +---- + update-request = command-list [pack-file] + + command-list = PKT-LINE(command NUL capability-list LF) + *PKT-LINE(command LF) + flush-pkt + + 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 + + old-id = obj-id + new-id = obj-id + + pack-file = "PACK" 28*(OCTET) +---- + +If the receiving end does not support delete-refs, the sending end MUST +NOT ask for delete command. + +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, +even if the server already has all the necessary objects. In this +case the client MUST send an empty pack-file. The only time this +is likely to happen is if the client is creating +a new branch or a tag that points to an existing obj-id. + +The server will receive the packfile, unpack it, then validate each +reference that is being updated that it hasn't changed while the request +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. + +Report Status +------------- + +After receiving the pack data from the sender, the receiver sends a +report if 'report-status' capability is in effect. +It is a short listing of what happened in that update. It will first +list the status of the packfile unpacking as either 'unpack ok' or +'unpack [error]'. Then it will list the status for each of the references +that it tried to update. Each line is either 'ok [refname]' if the +update was successful, or 'ng [refname] [error]' if the update was not. + +---- + report-status = unpack-status + 1*(command-status) + flush-pkt + + unpack-status = PKT-LINE("unpack" SP unpack-result LF) + unpack-result = "ok" / error-msg + + command-status = command-ok / command-fail + command-ok = PKT-LINE("ok" SP refname LF) + command-fail = PKT-LINE("ng" SP refname SP error-msg LF) + + error-msg = 1*(OCTECT) ; where not "ok" +---- + +Updates can be unsuccessful for a number of reasons. The reference can have +changed since the reference discovery phase was originally sent, meaning +someone pushed in the meantime. The reference being pushed could be a +non-fast-forward reference and the update hooks or configuration could be +set to not allow that, etc. Also, some references can be updated while others +can be rejected. + +An example client/server communication might look like this: + +---- + S: 007c74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/local\0report-status delete-refs ofs-delta\n + S: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe refs/heads/debug\n + S: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/master\n + S: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/team\n + S: 0000 + + C: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe 74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/debug\n + C: 003e74730d410fcb6603ace96f1dc55ea6196122532d 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a refs/heads/master\n + C: 0000 + C: [PACKDATA] + + S: 000aunpack ok\n + S: 0014ok refs/heads/debug\n + S: 0026ng refs/heads/master non-fast-forward\n +---- diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt new file mode 100644 index 0000000000..1892d3eeac --- /dev/null +++ b/Documentation/technical/protocol-capabilities.txt @@ -0,0 +1,187 @@ +Git Protocol Capabilities +========================= + +Servers SHOULD support all capabilities defined in this document. + +On the very first line of the initial server response of either +receive-pack and upload-pack the first reference is followed by +a NUL byte and then a list of space delimited server capabilities. +These allow the server to declare what it can and cannot support +to the client. + +Client will then send a space separated list of capabilities it wants +to be in effect. The client MUST NOT ask for capabilities the server +did not say it supports. + +Server MUST diagnose and abort if capabilities it does not understand +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 'ofs-delta' capability is sent and recognized by both upload-pack +and receive-pack protocols. + +All other capabilities are only recognized by the upload-pack (fetch +from server) process. + +multi_ack +--------- + +The 'multi_ack' capability allows the server to return "ACK obj-id +continue" as soon as it finds a commit that it can use as a common +base, between the client's wants and the client's have set. + +By sending this early, the server can potentially head off the client +from walking any further down that particular branch of the client's +repository history. The client may still need to walk down other +branches, sending have lines for those, until the server has a +complete cut across the DAG, or the client has said "done". + +Without multi_ack, a client sends have lines in --date-order until +the server has found a common base. That means the client will send +have lines that are already known by the server to be common, because +they overlap in time with another branch that the server hasn't found +a common base on yet. + +For example suppose the client has commits in caps that the server +doesn't and the server has commits in lower case that the client +doesn't, as in the following diagram: + + +---- u ---------------------- x + / +----- y + / / + a -- b -- c -- d -- E -- F + \ + +--- Q -- R -- S + +If the client wants x,y and starts out by saying have F,S, the server +doesn't know what F,S is. Eventually the client says "have d" and +the server sends "ACK d continue" to let the client know to stop +walking down that line (so don't send c-b-a), but its not done yet, +it needs a base for x. The client keeps going with S-R-Q, until a +gets reached, at which point the server has a clear base and it all +ends. + +Without multi_ack the client would have sent that c-b-a chain anyway, +interleaved with S-R-Q. + +thin-pack +--------- + +This capability means that the server can send a 'thin' pack, a pack +which does not contain base objects; if those base objects are available +on client side. Client requests 'thin-pack' capability when it +understands how to "thicken" it by adding required delta bases making +it self-contained. + +Client MUST NOT request 'thin-pack' capability if it cannot turn a thin +pack into a self-contained pack. + + +side-band, side-band-64k +------------------------ + +This capability means that server can send, and client understand multiplexed +progress reports and error info interleaved with the packfile itself. + +These two options are mutually exclusive. A modern client always +favors 'side-band-64k'. + +Either mode indicates that the packfile data will be streamed broken +up into packets of up to either 1000 bytes in the case of 'side_band', +or 65520 bytes in the case of 'side_band_64k'. Each packet is made up +of a leading 4-byte pkt-line length of how much data is in the packet, +followed by a 1-byte stream code, followed by the actual data. + +The stream code can be one of: + + 1 - pack data + 2 - progress messages + 3 - fatal error message just before stream aborts + +The "side-band-64k" capability came about as a way for newer clients +that can handle much larger packets to request packets that are +actually crammed nearly full, while maintaining backward compatibility +for the older clients. + +Further, with side-band and its up to 1000-byte messages, it's actually +999 bytes of payload and 1 byte for the stream code. With side-band-64k, +same deal, you have up to 65519 bytes of data and 1 byte for the stream +code. + +The client MUST send only maximum of one of "side-band" and "side- +band-64k". Server MUST diagnose it as an error if client requests +both. + +ofs-delta +--------- + +Server can send, and client understand PACKv2 with delta refering 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. + +shallow +------- + +This capability adds "deepen", "shallow" and "unshallow" commands to +the fetch-pack/upload-pack protocol so clients can request shallow +clones. + +no-progress +----------- + +The client was started with "git clone -q" or something, and doesn't +want that side band 2. Basically the client just says "I do not +wish to receive stream 2 on sideband, so do not send it to me, and if +you did, I will drop it on the floor anyway". However, the sideband +channel 3 is still used for error responses. + +include-tag +----------- + +The 'include-tag' capability is about sending annotated tags if we are +sending objects they point to. If we pack an object to the client, and +a tag object points exactly at that object, we pack the tag object too. +In general this allows a client to get all new annotated tags when it +fetches a branch, in a single network connection. + +Clients MAY always send include-tag, hardcoding it into a request when +the server advertises this capability. The decision for a client to +request include-tag only has to do with the client's desires for tag +data, whether or not a server had advertised objects in the +refs/tags/* namespace. + +Servers MUST pack the tags if their referrant is packed and the client +has requested include-tags. + +Clients MUST be prepared for the case where a server has ignored +include-tag and has not actually sent tags in the pack. In such +cases the client SHOULD issue a subsequent fetch to acquire the tags +that include-tag would have otherwise given the client. + +The server SHOULD send include-tag, if it supports it, regardless +of whether or not there are tags available. + +report-status +------------- + +The upload-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 +will respond with whether the packfile unpacked successfully and if +each reference was updated successfully. If any of those were not +successful, it will send back an error message. See pack-protocol.txt +for example messages. + +delete-refs +----------- + +If the server sends back the 'delete-refs' capability, it means that +it is capable of accepting an 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. diff --git a/Documentation/technical/protocol-common.txt b/Documentation/technical/protocol-common.txt new file mode 100644 index 0000000000..d30a1b9510 --- /dev/null +++ b/Documentation/technical/protocol-common.txt @@ -0,0 +1,96 @@ +Documentation Common to Pack and Http Protocols +=============================================== + +ABNF Notation +------------- + +ABNF notation as described by RFC 5234 is used within the protocol documents, +except the following replacement core rules are used: +---- + HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" +---- + +We also define the following common rules: +---- + NUL = %x00 + zero-id = 40*"0" + obj-id = 40*(HEXDIGIT) + + refname = "HEAD" + refname /= "refs/" <see discussion below> +---- + +A refname is a hierarchical octet string beginning with "refs/" and +not violating the 'git-check-ref-format' command's validation rules. +More specifically, they: + +. They can include slash `/` for hierarchical (directory) + grouping, but no slash-separated component can begin with a + dot `.`. + +. They must contain at least one `/`. This enforces the presence of a + category like `heads/`, `tags/` etc. but the actual names are not + restricted. + +. They cannot have two consecutive dots `..` anywhere. + +. They cannot have ASCII control characters (i.e. bytes whose + values are lower than \040, or \177 `DEL`), space, tilde `~`, + caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`, + or open bracket `[` anywhere. + +. They cannot end with a slash `/` nor a dot `.`. + +. They cannot end with the sequence `.lock`. + +. They cannot contain a sequence `@{`. + +. They cannot contain a `\\`. + + +pkt-line Format +--------------- + +Much (but not all) of the payload is described around pkt-lines. + +A pkt-line is a variable length binary string. The first four bytes +of the line, the pkt-len, indicates the total length of the line, +in hexadecimal. The pkt-len includes the 4 bytes used to contain +the length's hexadecimal representation. + +A pkt-line MAY contain binary data, so implementors MUST ensure +pkt-line parsing/formatting routines are 8-bit clean. + +A non-binary line SHOULD BE terminated by an LF, which if present +MUST be included in the total length. + +The maximum length of a pkt-line's data component is 65520 bytes. +Implementations MUST NOT send pkt-line whose length exceeds 65524 +(65520 bytes of payload + 4 bytes of length data). + +Implementations SHOULD NOT send an empty pkt-line ("0004"). + +A pkt-line with a length field of 0 ("0000"), called a flush-pkt, +is a special case and MUST be handled differently than an empty +pkt-line ("0004"). + +---- + pkt-line = data-pkt / flush-pkt + + data-pkt = pkt-len pkt-payload + pkt-len = 4*(HEXDIG) + pkt-payload = (pkt-len - 4)*(OCTET) + + flush-pkt = "0000" +---- + +Examples (as C-style strings): + +---- + pkt-line actual value + --------------------------------- + "0006a\n" "a\n" + "0005a" "a" + "000bfoobar\n" "foobar\n" + "0004" "" +---- diff --git a/Documentation/technical/racy-git.txt b/Documentation/technical/racy-git.txt new file mode 100644 index 0000000000..53aa0c82c2 --- /dev/null +++ b/Documentation/technical/racy-git.txt @@ -0,0 +1,197 @@ +Use of index and Racy git problem +================================= + +Background +---------- + +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 +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 +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. + +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 +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 +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 +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. +With a `USE_STDEV` compile-time option, `st_dev` is also +compared, but this is not enabled by default because this member +is not stable on network filesystems. With `USE_NSEC` +compile-time option, `st_mtim.tv_nsec` and `st_ctim.tv_nsec` +members are also compared, but this is not enabled by default +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, +2005-01-04). + +Racy git +-------- + +There is one slight problem with the optimization based on the +cached stat information. Consider this sequence: + + : modify 'foo' + $ git update-index 'foo' + : modify 'foo' again, in-place, without changing its size + +The first `update-index` computes the object name of the +contents of file `foo` and updates the index entry for `foo` +along with the `struct stat` information. If the modification +that follows it happens very fast so that the file's `st_mtime` +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 +are unmodified even though they actually are. This is called +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: + +. When the cached stat information says the file has not been + modified, and the `st_mtime` is the same as (or newer than) + the timestamp of the index file itself (which is the time `git + update-index foo` finished running in the above example), it + also compares the contents with the object registered in the + index entry to make sure they match. + +. When the index file is updated that contains racily clean + entries, cached `st_size` information is truncated to zero + before writing a new version of the index file. + +Because the index file itself is written after collecting all +the stat information from updated paths, `st_mtime` timestamp of +it is usually the same as or newer than any of the paths the +index contains. And no matter how quick the modification that +follows `git update-index foo` finishes, the resulting +`st_mtime` timestamp on `foo` cannot get a value earlier +than the index file. Therefore, index entries that can be +racily clean are limited to the ones that have the same +timestamp as the index file itself. + +The callers that want to check if an index entry matches the +corresponding file in the working tree continue to call +`ce_match_stat()`, but with this change, `ce_match_stat()` uses +`ce_modified_check_fs()` to see if racily clean ones are +actually clean after comparing the cached stat information using +`ce_match_stat_basic()`. + +The problem the latter solves is this sequence: + + $ git update-index 'foo' + : modify 'foo' in-place without changing its size + : wait for enough time + $ git update-index 'bar' + +Without the latter, the timestamp of the index file gets a newer +value, and falsely clean entry `foo` would not be caught by the +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 +expensive `ce_modified_check_fs()`. + + +Runtime penalty +--------------- + +The runtime penalty of falling back to `ce_modified_check_fs()` +from `ce_match_stat()` can be very expensive when there are many +racily clean entries. An obvious way to artificially create +this situation is to give the same timestamp to all the files in +the working tree in a large project, run `git update-index` on +them, and give the same timestamp to the index file: + + $ date >.datestamp + $ git ls-files | xargs touch -r .datestamp + $ 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: + + $ /usr/bin/time git diff-files + 1.68user 0.54system 0:02.22elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+67111minor)pagefaults 0swaps + $ git update-index MAINTAINERS + $ /usr/bin/time git diff-files + 0.02user 0.12system 0:00.14elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+935minor)pagefaults 0swaps + +Running `git update-index` in the middle checked the racily +clean entries, and left the cached `st_mtime` for all the paths +intact because they were actually clean (so this step took about +the same amount of time as the first `git diff-files`). After +that, they are not racily clean anymore but are truly clean, so +the second invocation of `git diff-files` fully took advantage +of the cached stat information. + + +Avoiding runtime penalty +------------------------ + +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 +resulting index file would otherwise would have by waiting +before finishing writing the index file out. + +I suspected that in practice the situation where many paths in the +index are all racily clean was quite rare. The only code paths +that can record recent timestamp for large number of paths are: + +. Initial `git add .` of a large project. + +. `git checkout` of a large project from an empty index into an + unpopulated working tree. + +Note: switching branches with `git checkout` keeps the cached +stat information of existing working tree files that are the +same between the current branch and the new branch, which are +all older than the resulting index file, and they will not +become racily clean. Only the files that are actually checked +out can become racily clean. + +In a large project where raciness avoidance cost really matters, +however, the initial computation of all object names in the +index takes more than one second, and the index file is written +out after all that happens. Therefore the timestamp of the +index file will be more than one seconds later than the +youngest file in the working tree. This means that in these +cases there actually will not be any racily clean entry in +the resulting index. + +Based on this discussion, the current code does not use the +"workaround" to avoid the runtime penalty that does not exist in +practice anymore. This was done with commit 0fc82cff on Aug 15, +2006. diff --git a/Documentation/technical/send-pack-pipeline.txt b/Documentation/technical/send-pack-pipeline.txt new file mode 100644 index 0000000000..681efe4219 --- /dev/null +++ b/Documentation/technical/send-pack-pipeline.txt @@ -0,0 +1,63 @@ +git-send-pack +============= + +Overall operation +----------------- + +. Connects to the remote side and invokes git-receive-pack. + +. Learns what refs the remote has and what commit they point at. + Matches them to the refspecs we are pushing. + +. Checks if there are non-fast-forwards. Unlike fetch-pack, + the repository send-pack runs in is supposed to be a superset + of the recipient in fast-forward cases, so there is no need + for want/have exchanges, and fast-forward check can be done + locally. Tell the result to the other end. + +. Calls pack_objects() which generates a packfile and sends it + over to the other end. + +. If the remote side is new enough (v1.1.0 or later), wait for + the unpack and hook status from the other end. + +. Exit with appropriate error codes. + + +Pack_objects pipeline +--------------------- + +This function gets one file descriptor (`fd`) which is either a +socket (over the network) or a pipe (local). What's written to +this fd goes to git-receive-pack to be unpacked. + + send-pack ---> fd ---> receive-pack + +The function pack_objects creates a pipe and then forks. The +forked child execs pack-objects with --revs to receive revision +parameters from its standard input. This process will write the +packfile to the other end. + + send-pack + | + pack_objects() ---> fd ---> receive-pack + | ^ (pipe) + v | + (child) + +The child dup2's to arrange its standard output to go back to +the other end, and read its standard input to come from the +pipe. After that it exec's pack-objects. On the other hand, +the parent process, before starting to feed the child pipeline, +closes the reading side of the pipe and fd to receive-pack. + + send-pack + | + pack_objects(parent) + | + v [0] + pack-objects [0] ---> receive-pack + + +[jc: the pipeline was much more complex and needed documentation before + I understood an earlier bug, but now it is trivial and straightforward.] diff --git a/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt new file mode 100644 index 0000000000..559263af48 --- /dev/null +++ b/Documentation/technical/shallow.txt @@ -0,0 +1,49 @@ +Def.: 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 +$GIT_DIR/shallow, and handle its contents like the contents +of $GIT_DIR/info/grafts (with the difference that shallow +cannot contain parent information). + +This information is stored in a new file instead of grafts, or +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 +will be constructed, which has nr_parent < 0 to make it easier +to discern from user provided grafts. + +Since fsck-objects relies on the library to read the objects, +it honours shallow commits automatically. + +There are some unfinished ends of the whole shallow business: + +- maybe we have to force non-thin packs when fetching into a + shallow repo (ATM they are forced non-thin). + +- A special handling of a shallow upstream is needed. At some + stage, upload-pack has to check if it sends a shallow commit, + and it should send that information early (or fail, if the + client does not support shallow repositories). There is no + support at all for this in this patch series. + +- Instead of locking $GIT_DIR/shallow at the start, just + the timestamp of it is noted, and when it comes to writing it, + a check is performed if the mtime is still the same, dying if + it is not. + +- It is unclear how "push into/from a shallow repo" should behave. + +- If you deepen a history, you'd want to get the tags of the + newly stored (but older!) commits. This does not work right now. + +To make a shallow clone, you can call "git-clone --depth 20 repo". +The result contains only commit chains with a length of at most 20. +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. diff --git a/Documentation/technical/trivial-merge.txt b/Documentation/technical/trivial-merge.txt new file mode 100644 index 0000000000..24c84100b0 --- /dev/null +++ b/Documentation/technical/trivial-merge.txt @@ -0,0 +1,121 @@ +Trivial merge rules +=================== + +This document describes the outcomes of the trivial merge logic in read-tree. + +One-way merge +------------- + +This replaces the index with a different tree, keeping the stat info +for entries that don't change, and allowing -u to make the minimum +required changes to the working tree to have it match. + +Entries marked '+' have stat information. Spaces marked '*' don't +affect the result. + + index tree result + ----------------------- + * (empty) (empty) + (empty) tree tree + index+ tree tree + index+ index index+ + +Two-way merge +------------- + +It is permitted for the index to lack an entry; this does not prevent +any case from applying. + +If the index exists, it is an error for it not to match either the old +or the result. + +If multiple cases apply, the one used is listed first. + +A result which changes the index is an error if the index is not empty +and not up-to-date. + +Entries marked '+' have stat information. Spaces marked '*' don't +affect the result. + + case index old new result + ------------------------------------- + 0/2 (empty) * (empty) (empty) + 1/3 (empty) * new new + 4/5 index+ (empty) (empty) index+ + 6/7 index+ (empty) index index+ + 10 index+ index (empty) (empty) + 14/15 index+ old old index+ + 18/19 index+ old index index+ + 20 index+ index new new + +Three-way merge +--------------- + +It is permitted for the index to lack an entry; this does not prevent +any case from applying. + +If the index exists, it is an error for it not to match either the +head or (if the merge is trivial) the result. + +If multiple cases apply, the one used is listed first. + +A result of "no merge" means that index is left in stage 0, ancest in +stage 1, head in stage 2, and remote in stage 3 (if any of these are +empty, no entry is left for that stage). Otherwise, the given entry is +left in stage 0, and there are no other entries. + +A result of "no merge" is an error if the index is not empty and not +up-to-date. + +*empty* means that the tree must not have a directory-file conflict + with the entry. + +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 + +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 +allow directory-file conflicts between things in different stages +after the trivial merge. + +A possible alternative for #6 is (empty), which would make it like +#1. This is not used, due to the likelihood that it arises due to +moving the file to multiple different locations or moving and deleting +it in different branches. + +Case #1 is included for completeness, and also in case we decide to +put on '+' markings; any path that is never mentioned at all isn't +handled. + +Note that #16 is when both #13 and #14 apply; in this case, we refuse +the trivial merge, because we can't tell from this data which is +right. This is a case of a reverted patch (in some direction, maybe +multiple times), and the right answer depends on looking at crossings +of history or common ancestors of the ancestors. + +Note that, between #6, #7, #9, and #11, all cases not otherwise +covered are handled in this table. + +For #8 and #10, there is alternative behavior, not currently +implemented, where the result is (empty). As currently implemented, +the automatic merge will generally give this effect. diff --git a/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt new file mode 100644 index 0000000000..2a0e7b8944 --- /dev/null +++ b/Documentation/urls-remotes.txt @@ -0,0 +1,94 @@ +include::urls.txt[] + +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 file in the `$GIT_DIR/remotes` directory, or +* a file in the `$GIT_DIR/branches` directory. + +All of these also allow you to omit the refspec from the command line +because they each contain a refspec which git will use by default. + +Named remote in configuration file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can choose to provide the name of a remote which you had previously +configured using linkgit:git-remote[1], linkgit:git-config[1] +or even by a manual edit to the `$GIT_DIR/config` file. The URL of +this remote will be used to access the repository. The refspec +of this remote will be used by default when you do +not provide a refspec on the command line. The entry in the +config file would appear like this: + +------------ + [remote "<name>"] + url = <url> + pushurl = <pushurl> + push = <refspec> + fetch = <refspec> +------------ + +The `<pushurl>` is used for pushes only. It is optional and defaults +to `<url>`. + +Named file in `$GIT_DIR/remotes` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can choose to provide the name of a +file in `$GIT_DIR/remotes`. The URL +in this file will be used to access the repository. The refspec +in this file will be used as default when you do not +provide a refspec on the command line. This file should have the +following format: + +------------ + URL: one of the above URL format + Push: <refspec> + Pull: <refspec> + +------------ + +`Push:` lines are used by 'git-push' and +`Pull:` lines are used by 'git-pull' and 'git-fetch'. +Multiple `Push:` and `Pull:` lines may +be specified for additional branch mappings. + +Named file in `$GIT_DIR/branches` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can choose to provide the name of a +file in `$GIT_DIR/branches`. +The URL in this file will be used to access the repository. +This file should have the following format: + + +------------ + <url>#<head> +------------ + +`<url>` is required; `#<head>` is optional. + +Depending on the operation, git will use one of the following +refspecs, if you don't provide one on the command line. +`<branch>` is the name of this file in `$GIT_DIR/branches` and +`<head>` defaults to `master`. + +git fetch uses: + +------------ + refs/heads/<head>:refs/heads/<branch> +------------ + +git push uses: + +------------ + HEAD:refs/heads/<head> +------------ + + + + diff --git a/Documentation/urls.txt b/Documentation/urls.txt new file mode 100644 index 0000000000..d813ceb723 --- /dev/null +++ b/Documentation/urls.txt @@ -0,0 +1,87 @@ +GIT URLS[[URLS]] +---------------- + +One of the following notations can be used +to name the remote repository: + +=============================================================== +- rsync://host.xz/path/to/repo.git/ +- http://host.xz{startsb}:port{endsb}/path/to/repo.git/ +- https://host.xz{startsb}:port{endsb}/path/to/repo.git/ +- git://host.xz{startsb}:port{endsb}/path/to/repo.git/ +- git://host.xz{startsb}:port{endsb}/~user/path/to/repo.git/ +- ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/ +- ssh://{startsb}user@{endsb}host.xz/path/to/repo.git/ +- ssh://{startsb}user@{endsb}host.xz/~user/path/to/repo.git/ +- ssh://{startsb}user@{endsb}host.xz/~/path/to/repo.git +=============================================================== + +SSH is the default transport protocol over the network. You can +optionally specify which user to log-in as, and an alternate, +scp-like syntax is also supported. Both syntaxes support +username expansion, as does the native git protocol, but +only the former supports port specification. The following +three are identical to the last three above, respectively: + +=============================================================== +- {startsb}user@{endsb}host.xz:/path/to/repo.git/ +- {startsb}user@{endsb}host.xz:~user/path/to/repo.git/ +- {startsb}user@{endsb}host.xz:path/to/repo.git +=============================================================== + +To sync with a local directory, you can use: + +=============================================================== +- /path/to/repo.git/ +- file:///path/to/repo.git/ +=============================================================== + +ifndef::git-clone[] +They are mostly equivalent, except when cloning. See +linkgit:git-clone[1] for details. +endif::git-clone[] + +ifdef::git-clone[] +They are equivalent, except the former implies --local option. +endif::git-clone[] + + +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 +use will be rewritten into URLs that work), you can create a +configuration section of the form: + +------------ + [url "<actual url base>"] + insteadOf = <other url base> +------------ + +For example, with this: + +------------ + [url "git://git.host.xz/"] + insteadOf = host.xz:/path/to/ + insteadOf = work: +------------ + +a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be +rewritten in any context that takes a URL to be "git://git.host.xz/repo.git". + +If you want to rewrite URLs for push only, you can create a +configuration section of the form: + +------------ + [url "<actual url base>"] + pushInsteadOf = <other url base> +------------ + +For example, with this: + +------------ + [url "ssh://example.org/"] + pushInsteadOf = git://example.org/ +------------ + +a URL like "git://example.org/path/to/repo.git" will be rewritten to +"ssh://example.org/path/to/repo.git" for pushes, but pulls will still +use the original URL. diff --git a/Documentation/user-manual.conf b/Documentation/user-manual.conf new file mode 100644 index 0000000000..339b30919e --- /dev/null +++ b/Documentation/user-manual.conf @@ -0,0 +1,21 @@ +[titles] + underlines="__","==","--","~~","^^" + +[attributes] +caret=^ +startsb=[ +endsb=] +tilde=~ + +[linkgit-inlinemacro] +<ulink url="{target}.html">{target}{0?({0})}</ulink> + +ifdef::backend-docbook[] +# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this. +[listingblock] +<example><title>{title}</title> +<literallayout> +| +</literallayout> +{title#}</example> +endif::backend-docbook[] diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt new file mode 100644 index 0000000000..b169836684 --- /dev/null +++ b/Documentation/user-manual.txt @@ -0,0 +1,4590 @@ +Git User's Manual (for version 1.5.3 or newer) +______________________________________________ + + +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. + +<<repositories-and-branches>> and <<exploring-git-history>> explain how +to fetch and study a project using git--read these chapters to learn how +to build and test a particular version of a software project, search for +regressions, and so on. + +People needing to do actual development will also want to read +<<Developing-With-git>> and <<sharing-development>>. + +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: + +------------------------------------------------ +$ man git-clone +------------------------------------------------ + +or: + +------------------------------------------------ +$ 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, +without any explanation. + +Finally, see <<todo>> for ways that you can help make this manual more +complete. + + +[[repositories-and-branches]] +Repositories and Branches +========================= + +[[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 +read this manual. + +The best way to get one is by using the linkgit:git-clone[1] command to +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 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 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 +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 +about the history of the project. + +[[how-to-check-out]] +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 +version is called a <<def_commit,commit>>. + +Those snapshots aren't necessarily all arranged in a single line from +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 +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: + +------------------------------------------------ +$ git branch +* master +------------------------------------------------ + +A freshly cloned repository contains a single branch head, by default +named "master", with the working directory initialized to the state of +the project referred to by that branch head. + +Most projects also use <<def_tag,tags>>. Tags, like heads, are +references into the project's history, and can be listed using the +linkgit:git-tag[1] command: + +------------------------------------------------ +$ git tag -l +v2.6.11 +v2.6.11-tree +v2.6.12 +v2.6.12-rc2 +v2.6.12-rc3 +v2.6.12-rc4 +v2.6.12-rc5 +v2.6.12-rc6 +v2.6.13 +... +------------------------------------------------ + +Tags are expected to always point at the same version of a project, +while heads are expected to advance as development progresses. + +Create a new branch head pointing to one of these versions and check it +out using linkgit:git-checkout[1]: + +------------------------------------------------ +$ git checkout -b new v2.6.13 +------------------------------------------------ + +The working directory then reflects the contents that the project had +when it was tagged v2.6.13, and linkgit:git-branch[1] shows two +branches, with an asterisk marking the currently checked-out branch: + +------------------------------------------------ +$ git branch + master +* new +------------------------------------------------ + +If you decide that you'd rather see version 2.6.17, you can modify +the current branch to point at v2.6.17 instead, with + +------------------------------------------------ +$ git reset --hard v2.6.17 +------------------------------------------------ + +Note that if the current branch head was your only reference to a +particular point in history, then resetting that branch may leave you +with no way to find the history it used to point to; so use this command +carefully. + +[[understanding-commits]] +Understanding History: Commits +------------------------------ + +Every change in the history of a project is represented by a commit. +The linkgit:git-show[1] command shows the most recent commit on the +current branch: + +------------------------------------------------ +$ git show +commit 17cf781661e6d38f737f15f53ab552f1e95960d7 +Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)> +Date: Tue Apr 19 14:11:06 2005 -0700 + + Remove duplicate getenv(DB_ENVIRONMENT) call + + Noted by Tony Luck. + +diff --git a/init-db.c b/init-db.c +index 65898fa..b002dc6 100644 +--- a/init-db.c ++++ b/init-db.c +@@ -7,7 +7,7 @@ + + int main(int argc, char **argv) + { +- char *sha1_dir = getenv(DB_ENVIRONMENT), *path; ++ char *sha1_dir, *path; + int len, i; + + if (mkdir(".git", 0755) < 0) { +------------------------------------------------ + +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 +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 +example in email), then you are guaranteed that name will refer to the same +commit in their repository that it does in yours (assuming their repository +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 +history, including file data and directory contents, is stored in an object +with a name that is a hash of its contents. + +[[understanding-reachability]] +Understanding history: commits, parents, and reachability +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Every commit (except the very first commit in a project) also has a +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 +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 +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. + +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 +that Y is a descendant of X, or that there is a chain of parents +leading from commit Y to commit X. + +[[history-diagrams]] +Understanding history: History diagrams +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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: + + +................................................ + o--o--o <-- Branch A + / + o--o--o <-- master + \ + o--o--o <-- Branch B +................................................ + +If we need to talk about a particular commit, the character "o" may +be replaced with another letter or number. + +[[what-is-a-branch]] +Understanding history: What is a branch? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When we need to be precise, we will use the word "branch" to mean a line +of development, and "branch head" (or just "head") to mean a reference +to the most recent commit on a branch. In the example above, the branch +head named "A" is a pointer to one particular commit, but we refer to +the line of three commits leading up to that point as all being part of +"branch A". + +However, when no confusion will result, we often just use the term +"branch" both for branches and for branch heads. + +[[manipulating-branches]] +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 + 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: + +------------------------------------------------ +$ cat .git/HEAD +ref: refs/heads/master +------------------------------------------------ + +[[detached-head]] +Examining an old version without creating a new branch +------------------------------------------------------ + +The `git checkout` command normally expects a branch head, but will also +accept an arbitrary commit; for example, you can check out the commit +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> +HEAD is now at 427abfa... Linux v2.6.17 +------------------------------------------------ + +The HEAD then refers to the SHA-1 of the commit instead of to a branch, +and git branch shows that you are no longer on a branch: + +------------------------------------------------ +$ cat .git/HEAD +427abfa28afedffadfca9dd8b067eb6d36bac53f +$ git branch +* (no branch) + master +------------------------------------------------ + +In this case we say that the HEAD is "detached". + +This is an easy way to check out a particular version without having to +make up a name for the new branch. You can still create a new branch +(or tag) for this version later if you decide to. + +[[examining-remote-branches]] +Examining branches from a remote repository +------------------------------------------- + +The "master" branch that was created at the time you cloned is a copy +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, which you +can view using the "-r" option to linkgit:git-branch[1]: + +------------------------------------------------ +$ git branch -r + origin/HEAD + origin/html + origin/maint + origin/man + origin/master + origin/next + origin/pu + origin/todo +------------------------------------------------ + +You cannot check out these remote-tracking branches, but you can +examine them on a branch of your own, just as you would a tag: + +------------------------------------------------ +$ git checkout -b my-todo-copy origin/todo +------------------------------------------------ + +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]] +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 +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 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, +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]). + +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 +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:git-rev-parse[1]. + +[[Updating-a-repository-With-git-fetch]] +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. + +The command "git fetch", with no arguments, will update all of the +remote-tracking branches to the latest version found in her +repository. It will not touch any of your own branches--not even the +"master" branch that was created for you on clone. + +[[fetching-branches]] +Fetching branches from other repositories +----------------------------------------- + +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 +------------------------------------------------- + +New remote-tracking branches will be stored under the shorthand name +that you gave "git remote add", in this case linux-nfs: + +------------------------------------------------- +$ git branch -r +linux-nfs/master +origin/master +------------------------------------------------- + +If you run "git fetch <remote>" later, the tracking branches for the +named <remote> will be updated. + +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/* +... +------------------------------------------------- + +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 +===================== + +Git is best thought of as a tool for storing the history of a +collection of files. It does this by storing compressed snapshots of +the contents of a file hierarchy, together with "commits" which show +the relationships between these snapshots. + +Git provides extremely flexible and fast tools for exploring the +history of a project. + +We start with one specialized tool that is useful for finding the +commit that introduced a bug into a project. + +[[using-bisect]] +How to use bisect to find a regression +-------------------------------------- + +Suppose version 2.6.18 of your project worked, but the version at +"master" crashes. Sometimes the best way to find the cause of such a +regression is to perform a brute-force search through the project's +history to find the particular commit that caused the problem. The +linkgit:git-bisect[1] command can help you do this: + +------------------------------------------------- +$ git bisect start +$ git bisect good v2.6.18 +$ git bisect bad master +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 +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, +and see whether it crashes. Assume it does crash. Then: + +------------------------------------------------- +$ git bisect bad +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 +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. + +After about 13 tests (in this case), it will output the commit id of +the guilty commit. You can then examine the commit with +linkgit:git-show[1], find out who wrote it, and mail them your bug +report with the commit id. Finally, run + +------------------------------------------------- +$ git bisect reset +------------------------------------------------- + +to return you to the branch you were on before. + +Note that the version which `git bisect` checks out for you at each +point is just a suggestion, and you're free to try a different +version if you think it would be a good idea. For example, +occasionally you may land on a commit that broke something unrelated; +run + +------------------------------------------------- +$ git bisect visualize +------------------------------------------------- + +which will run gitk and label the commit it chose with a marker that +says "bisect". Choose a safe-looking commit nearby, note its commit +id, and check it out with: + +------------------------------------------------- +$ git reset --hard fb47ddb2db... +------------------------------------------------- + +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 +the current commit: + +------------------------------------------------- +$ git bisect skip +------------------------------------------------- + +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. + +[[naming-commits]] +Naming commits +-------------- + +We have seen several ways of naming commits already: + + - 40-hexdigit object name + - branch name: refers to the commit at the head of the given + branch + - tag name: refers to the commit pointed to by the given tag + (we've seen branches and tags are special cases of + <<how-git-stores-references,references>>). + - HEAD: refers to the head of the current branch + +There are many more; see the "SPECIFYING REVISIONS" section of the +linkgit:git-rev-parse[1] man page for the complete list of ways to +name revisions. Some examples: + +------------------------------------------------- +$ git show fb47ddb2 # the first few characters of the object name + # are usually enough to specify it uniquely +$ git show HEAD^ # the parent of the HEAD commit +$ git show HEAD^^ # the grandparent +$ 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 +also choose: + +------------------------------------------------- +$ git show HEAD^1 # show the first parent of HEAD +$ git show HEAD^2 # show the second parent of HEAD +------------------------------------------------- + +In addition to HEAD, there are several other special names for +commits: + +Merges (to be discussed later), as well as operations such as +`git reset`, which change the currently checked-out commit, generally +set ORIG_HEAD to the value HEAD had before the current operation. + +The `git fetch` operation always stores the head of the last fetched +branch in FETCH_HEAD. For example, if you run `git fetch` without +specifying a local branch as the target of the operation + +------------------------------------------------- +$ git fetch git://example.com/proj.git theirbranch +------------------------------------------------- + +the fetched commits will still be available from FETCH_HEAD. + +When we discuss merges we'll also see the special name MERGE_HEAD, +which refers to the other branch that we're merging in to the current +branch. + +The linkgit:git-rev-parse[1] command is a low-level command that is +occasionally useful for translating some name for a commit to the object +name for that commit: + +------------------------------------------------- +$ git rev-parse origin +e05db0fd4f31dde7005f075a84f96b360d05984b +------------------------------------------------- + +[[creating-tags]] +Creating tags +------------- + +We can also create a tag to refer to a particular commit; after +running + +------------------------------------------------- +$ git tag stable-1 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 +should create a tag object instead; see the linkgit:git-tag[1] man page +for details. + +[[browsing-revisions]] +Browsing revisions +------------------ + +The linkgit:git-log[1] command can show lists of commits. On its +own, it shows all commits reachable from the parent commit; but you +can also make more specific requests: + +------------------------------------------------- +$ git log v2.5.. # commits since (not reachable from) v2.5 +$ git log test..master # commits reachable from master but not test +$ git log master..test # ...reachable from test but not master +$ git log master...test # ...reachable from either test or master, + # but not both +$ git log --since="2 weeks ago" # commits from the last 2 weeks +$ git log Makefile # commits which modify Makefile +$ git log fs/ # ... which modify any file under fs/ +$ git log -S'foo()' # commits which add or remove any file data + # matching the string 'foo()' +------------------------------------------------- + +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: + +------------------------------------------------- +$ git log v2.5.. Makefile fs/ +------------------------------------------------- + +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 +display options. + +Note that git log starts with the most recent commit and works +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. + +[[generating-diffs]] +Generating diffs +---------------- + +You can generate diffs between any two versions using +linkgit:git-diff[1]: + +------------------------------------------------- +$ git diff master..test +------------------------------------------------- + +That will produce the diff between the tips of the two branches. If +you'd prefer to find the diff from their common ancestor to test, you +can use three dots instead of two: + +------------------------------------------------- +$ git diff master...test +------------------------------------------------- + +Sometimes what you want instead is a set of patches; for this you can +use linkgit:git-format-patch[1]: + +------------------------------------------------- +$ git format-patch master..test +------------------------------------------------- + +will generate a file with a patch for each commit reachable from test +but not from master. + +[[viewing-old-file-versions]] +Viewing old file versions +------------------------- + +You can always view an old version of a file by just checking out the +correct revision first. But sometimes it is more convenient to be +able to view an old version of a single file without checking +anything out; this command does that: + +------------------------------------------------- +$ 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. + +[[history-examples]] +Examples +-------- + +[[counting-commits-on-a-branch]] +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": + +------------------------------------------------- +$ git log --pretty=oneline origin..mybranch | wc -l +------------------------------------------------- + +Alternatively, you may often see this sort of thing done with the +lower-level command linkgit:git-rev-list[1], which just lists the SHA-1's +of all the given commits: + +------------------------------------------------- +$ git rev-list origin..mybranch | wc -l +------------------------------------------------- + +[[checking-for-equal-branches]] +Check whether two branches point at the same history +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Suppose you want to check whether two branches point at the same point +in history. + +------------------------------------------------- +$ git diff origin..master +------------------------------------------------- + +will tell you whether the contents of the project are the same at the +two branches; in theory, however, it's possible that the same project +contents could have been arrived at by two different historical +routes. You could compare the object names: + +------------------------------------------------- +$ git rev-list origin +e05db0fd4f31dde7005f075a84f96b360d05984b +$ 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 + +------------------------------------------------- +$ git log origin...master +------------------------------------------------- + +will return no commits when the two branches are equal. + +[[finding-tagged-descendants]] +Find first tagged version including a given fix +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Suppose you know that the commit e05db0fd fixed a certain problem. +You'd like to find the earliest tagged release that contains that +fix. + +Of course, there may be more than one answer--if the history branched +after commit e05db0fd, then there could be multiple "earliest" tagged +releases. + +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 +name based on any tag it finds pointing to one of the commit's +descendants: + +------------------------------------------------- +$ git name-rev --tags e05db0fd +e05db0fd tags/v1.5.0-rc1^0~23 +------------------------------------------------- + +The linkgit:git-describe[1] command does the opposite, naming the +revision using a tag on which the given commit is based: + +------------------------------------------------- +$ git describe e05db0fd +v1.5.0-rc0-260-ge05db0f +------------------------------------------------- + +but that may sometimes help you guess which tags might come after the +given commit. + +If you just want to verify whether a given tagged version contains a +given commit, you could use linkgit:git-merge-base[1]: + +------------------------------------------------- +$ git merge-base e05db0fd v1.5.0-rc1 +e05db0fd4f31dde7005f075a84f96b360d05984b +------------------------------------------------- + +The merge-base command finds a common ancestor of the given commits, +and always returns one or the other in the case where one is a +descendant of the other; so the above output shows that e05db0fd +actually is an ancestor of v1.5.0-rc1. + +Alternatively, note that + +------------------------------------------------- +$ git log v1.5.0-rc1..e05db0fd +------------------------------------------------- + +will produce empty output if and only if v1.5.0-rc1 includes e05db0fd, +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 + +------------------------------------------------- +$ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2 +! [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if +available + ! [v1.5.0-rc0] GIT v1.5.0 preview + ! [v1.5.0-rc1] GIT v1.5.0-rc1 + ! [v1.5.0-rc2] GIT v1.5.0-rc2 +... +------------------------------------------------- + +then search for a line that looks 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. + +[[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. + +We can list all the heads in this repository with +linkgit:git-show-ref[1]: + +------------------------------------------------- +$ git show-ref --heads +bf62196b5e363d73353a9dcf094c59595f3153b7 refs/heads/core-tutorial +db768d5504c1bb46f63ee9d6e1772bd047e05bf9 refs/heads/maint +a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master +24dbc180ea14dc1aebe09f14c8ecf32010690627 refs/heads/tutorial-2 +1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes +------------------------------------------------- + +We can get just the branch-head names, and remove "master", with +the help of the standard utilities cut and grep: + +------------------------------------------------- +$ git show-ref --heads | cut -d' ' -f2 | grep -v '^refs/heads/master' +refs/heads/core-tutorial +refs/heads/maint +refs/heads/tutorial-2 +refs/heads/tutorial-fixes +------------------------------------------------- + +And then we can ask to see all the commits reachable from master +but not from these other heads: + +------------------------------------------------- +$ gitk master --not $( git show-ref --heads | cut -d' ' -f2 | + grep -v '^refs/heads/master' ) +------------------------------------------------- + +Obviously, endless variations are possible; for example, to see all +commits reachable from some head but not from any tag in the repository: + +------------------------------------------------- +$ gitk $( git show-ref --heads ) --not $( git show-ref --tags ) +------------------------------------------------- + +(See linkgit:git-rev-parse[1] for explanations of commit-selecting +syntax such as `--not`.) + +[[making-a-release]] +Creating a changelog and tarball for a software release +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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 +------------------------------------------------- + +will use HEAD to produce a tar archive in which each filename is +preceded by "project/". + +If you're releasing a new version of a software project, you may want +to simultaneously make a changelog to include in the release +announcement. + +Linus Torvalds, for example, makes new kernel releases by tagging them, +then running: + +------------------------------------------------- +$ release-script 2.6.12 2.6.13-rc6 2.6.13-rc7 +------------------------------------------------- + +where release-script is a shell script that looks like: + +------------------------------------------------- +#!/bin/sh +stable="$1" +last="$2" +new="$3" +echo "# git tag v$new" +echo "git archive --prefix=linux-$new/ v$new | gzip -9 > ../linux-$new.tar.gz" +echo "git diff v$stable v$new | gzip -9 > ../patch-$new.gz" +echo "git log --no-merges v$new ^v$last > ../ChangeLog-$new" +echo "git shortlog --no-merges v$new ^v$last > ../ShortLog" +echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new" +------------------------------------------------- + +and then he just cut-and-pastes the output commands after verifying that +they look OK. + +[[Finding-comments-With-given-Content]] +Finding commits referencing a file with given content +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Somebody hands you a copy of a file, and asks which commits modified a +file such that it contained the given content either before or after the +commit. You can find out with this: + +------------------------------------------------- +$ git log --raw --abbrev=40 --pretty=oneline | + grep -B 1 `git hash-object filename` +------------------------------------------------- + +Figuring out why this works is left as an exercise to the (advanced) +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 +=================== + +[[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: + +------------------------------------------------ +[user] + name = Your Name Comes Here + email = you@yourdomain.example.com +------------------------------------------------ + +(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for +details on the configuration file.) + + +[[creating-a-new-repository]] +Creating a new repository +------------------------- + +Creating a new repository from scratch is very easy: + +------------------------------------------------- +$ mkdir project +$ cd project +$ git init +------------------------------------------------- + +If you have some initial content (say, a tarball): + +------------------------------------------------- +$ tar xzvf project.tar.gz +$ cd project +$ git init +$ git add . # include everything below ./ in the first commit: +$ git commit +------------------------------------------------- + +[[how-to-make-a-commit]] +How to make a commit +-------------------- + +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 + 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 +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 +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 + +------------------------------------------------- +$ git add path/to/file +------------------------------------------------- + +To remove a file from the index and from the working tree, + +------------------------------------------------- +$ git rm path/to/file +------------------------------------------------- + +After each step you can verify that + +------------------------------------------------- +$ git diff --cached +------------------------------------------------- + +always shows the difference between the HEAD and the index file--this +is what you'd commit if you created the commit now--and that + +------------------------------------------------- +$ 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 +to the index; further changes to the same file will be ignored unless +you run `git add` on the file again. + +When you're ready, just run + +------------------------------------------------- +$ git commit +------------------------------------------------- + +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 + +------------------------------------------------- +$ git show +------------------------------------------------- + +As a special shortcut, + +------------------------------------------------- +$ git commit -a +------------------------------------------------- + +will update the index with any files that you've modified or removed +and create a commit, all in one step. + +A number of commands are useful for keeping track of what you're +about to commit: + +------------------------------------------------- +$ git diff --cached # difference between HEAD and the index; what + # would be committed if you ran "commit" now. +$ git diff # difference between the index file and your + # working directory; changes that would not + # be included if you ran "commit" now. +$ git diff HEAD # difference between HEAD and working tree; what + # would be committed if you ran "commit -a" now. +$ git status # a brief per-file summary of the above. +------------------------------------------------- + +You can also use linkgit:git-gui[1] to create commits, view changes in +the index and the working tree files, and individually select diff hunks +for inclusion in the index (by right-clicking on the diff hunk and +choosing "Stage Hunk For Commit"). + +[[creating-good-commit-messages]] +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. + +[[ignoring-files]] +Ignoring files +-------------- + +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 +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: + +------------------------------------------------- +# Lines starting with '#' are considered comments. +# Ignore any file named foo.txt. +foo.txt +# Ignore (generated) html files, +*.html +# except foo.html which is maintained by hand. +!foo.html +# Ignore objects and archives. +*.[oa] +------------------------------------------------- + +See linkgit:gitignore[5] for a detailed explanation of the syntax. You can +also place .gitignore files in other directories in your working tree, and they +will apply to those directories and their subdirectories. The `.gitignore` +files can be added to your repository like any other files (just run `git add +.gitignore` and `git commit`, as usual), which is convenient when the exclude +patterns (such as patterns matching build output files) would also make sense +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. + +[[how-to-merge]] +How to merge +------------ + +You can rejoin two diverging branches of development using +linkgit:git-merge[1]: + +------------------------------------------------- +$ git merge branchname +------------------------------------------------- + +merges the development in the branch "branchname" into the current +branch. + +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 +half-merged results when this combining results in conflicts. +Therefore, if you have uncommitted changes touching the same files as +the ones impacted by the merge, Git will refuse to proceed. Most of +the time, you will want to commit your changes before you can merge, +and if you don't, then linkgit:git-stash[1] can take these changes +away while you're doing the merge, and reapply them afterwards. + +If the changes are independant enough, Git will automatically complete +the merge and commit the result (or reuse an existing commit in case +of <<fast-forwards,fast-forward>>, see below). On the other hand, +if there are conflicts--for example, if the same file is +modified in two different ways in the remote branch and the local +branch--then you are warned; the output may look something like this: + +------------------------------------------------- +$ git merge next + 100% (4/4) done +Auto-merged file.txt +CONFLICT (content): Merge conflict in file.txt +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 +creating a new file. + +If you examine the resulting commit using gitk, you will see that it +has two parents, one pointing to the top of the current branch, and +one to the top of the other branch. + +[[resolving-a-merge]] +Resolving a merge +----------------- + +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. + +Files with conflicts are marked specially in the index, so until you +resolve the problem and update the index, linkgit:git-commit[1] will +fail: + +------------------------------------------------- +$ git commit +file.txt: needs merge +------------------------------------------------- + +Also, linkgit:git-status[1] will list those files as "unmerged", and the +files with conflicts will have conflict markers added, like this: + +------------------------------------------------- +<<<<<<< HEAD:file.txt +Hello world +======= +Goodbye +>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt +------------------------------------------------- + +All you need to do is edit the files to resolve the conflicts, and then + +------------------------------------------------- +$ git add file.txt +$ git commit +------------------------------------------------- + +Note that the commit message will already be filled in for you with +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 +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 +already added to the index file, so linkgit:git-diff[1] shows only +the conflicts. It uses an unusual syntax: + +------------------------------------------------- +$ git diff +diff --cc file.txt +index 802992c,2b60207..0000000 +--- a/file.txt ++++ b/file.txt +@@@ -1,1 -1,1 +1,5 @@@ +++<<<<<<< HEAD:file.txt + +Hello world +++======= ++ Goodbye +++>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt +------------------------------------------------- + +Recall that the commit which will be committed after we resolve this +conflict will have two parents instead of the usual one: one parent +will be HEAD, the tip of the current branch; the other will be the +tip of the other branch, which is stored temporarily in MERGE_HEAD. + +During the merge, the index holds three versions of each file. Each of +these three "file stages" represents a different version of the file: + +------------------------------------------------- +$ git show :1:file.txt # the file in a common ancestor of both branches +$ git show :2:file.txt # the version from HEAD. +$ git show :3:file.txt # the version from MERGE_HEAD. +------------------------------------------------- + +When you ask linkgit:git-diff[1] to show the conflicts, it runs a +three-way diff between the conflicted merge results in the work tree with +stages 2 and 3 to show only hunks whose contents come from both sides, +mixed (in other words, when a hunk's merge results come only from stage 2, +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 +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 +of linkgit:git-diff-files[1] for a details of the format.) + +After resolving the conflict in the obvious way (but before updating the +index), the diff will look like: + +------------------------------------------------- +$ git diff +diff --cc file.txt +index 802992c,2b60207..0000000 +--- a/file.txt ++++ b/file.txt +@@@ -1,1 -1,1 +1,1 @@@ +- Hello world + -Goodbye +++Goodbye world +------------------------------------------------- + +This shows that our resolved version deleted "Hello world" from the +first parent, deleted "Goodbye" from the second parent, and added +"Goodbye world", which was previously absent from both. + +Some special diff options allow diffing the working directory against +any of these stages: + +------------------------------------------------- +$ git diff -1 file.txt # diff against stage 1 +$ git diff --base file.txt # same as the above +$ git diff -2 file.txt # diff against stage 2 +$ git diff --ours file.txt # same as the above +$ git diff -3 file.txt # diff against stage 3 +$ git diff --theirs file.txt # same as the above. +------------------------------------------------- + +The linkgit:git-log[1] and linkgit:gitk[1] commands also provide special help +for merges: + +------------------------------------------------- +$ git log --merge +$ gitk --merge +------------------------------------------------- + +These will display all commits which exist only on HEAD or on +MERGE_HEAD, and which touch an unmerged file. + +You may also use linkgit:git-mergetool[1], which lets you merge the +unmerged files using external tools such as Emacs or kdiff3. + +Each time you resolve the conflicts in a file and update the index: + +------------------------------------------------- +$ git add file.txt +------------------------------------------------- + +the different stages of that file will be "collapsed", after which +`git diff` will (by default) no longer show diffs for that file. + +[[undoing-a-merge]] +Undoing a merge +--------------- + +If you get stuck and decide to just give up and throw the whole mess +away, you can always return to the pre-merge state with + +------------------------------------------------- +$ git reset --hard HEAD +------------------------------------------------- + +Or, if you've already committed the merge that you want to throw away, + +------------------------------------------------- +$ git reset --hard ORIG_HEAD +------------------------------------------------- + +However, this last command can be dangerous in some cases--never +throw away a commit you have already committed if that commit may +itself have been merged into another branch, as doing so may confuse +further merges. + +[[fast-forwards]] +Fast-forward merges +------------------- + +There is one special case not mentioned above, which is treated +differently. Normally, a merge results in a merge commit, with two +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 +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. + +[[fixing-mistakes]] +Fixing mistakes +--------------- + +If you've messed up the working tree, but haven't yet committed your +mistake, you can return the entire working tree to the last committed +state with + +------------------------------------------------- +$ git reset --hard HEAD +------------------------------------------------- + +If you make a commit that you later wish you hadn't, there are two +fundamentally different ways to fix the problem: + + 1. You can create a new commit that undoes whatever was done + by the old commit. This is the correct thing if your + mistake has already been made public. + + 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 + change, and cannot correctly perform repeated merges from + a branch that has had its history changed. + +[[reverting-a-commit]] +Fixing a mistake with a new commit +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Creating a new commit that reverts an earlier change is very easy; +just pass the linkgit:git-revert[1] command a reference to the bad +commit; for example, to revert the most recent commit: + +------------------------------------------------- +$ git revert HEAD +------------------------------------------------- + +This will create a new commit which undoes the change in HEAD. You +will be given a chance to edit the commit message for the new commit. + +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 +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, +resolving a merge>>. + +[[fixing-a-mistake-by-rewriting-history]] +Fixing a mistake by rewriting history +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If the problematic commit is the most recent commit, and you have not +yet made that commit public, then you may just +<<undoing-a-merge,destroy it using `git reset`>>. + +Alternatively, you +can edit the working directory and update the index to fix your +mistake, just as if you were going to <<how-to-make-a-commit,create a +new commit>>, then run + +------------------------------------------------- +$ 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. + +Again, you should never do this to a commit that may already have +been merged into another branch; use linkgit:git-revert[1] instead in +that case. + +It is also possible to replace commits further back in the history, but +this is an advanced topic to be left for +<<cleaning-up-history,another chapter>>. + +[[checkout-of-path]] +Checking out an old version of a file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the process of undoing a previous bad change, you may find it +useful to check out an older version of a particular file using +linkgit:git-checkout[1]. We've used `git checkout` before to switch +branches, but it has quite different behavior if it is given a path +name: the command + +------------------------------------------------- +$ git checkout HEAD^ path/to/file +------------------------------------------------- + +replaces path/to/file by the contents it had in the commit HEAD^, and +also updates the index to match. It does not change branches. + +If you just want to look at an old version of the file, without +modifying the working directory, you can do that with +linkgit:git-show[1]: + +------------------------------------------------- +$ git show HEAD^:path/to/file +------------------------------------------------- + +which will display the given version of the file. + +[[interrupted-work]] +Temporarily setting aside work in progress +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +While you are in the middle of working on something complicated, you +find an unrelated but obvious and trivial bug. You would like to fix it +before continuing. You can use linkgit:git-stash[1] to save the current +state of your work, and after fixing the bug (or, optionally after doing +so on a different branch and then coming back), unstash the +work-in-progress changes. + +------------------------------------------------ +$ git stash save "work in progress for foo feature" +------------------------------------------------ + +This command will save your changes away to the `stash`, and +reset your working tree and the index to match the tip of your +current branch. Then you can make your fix as usual. + +------------------------------------------------ +... edit and test ... +$ git commit -a -m "blorpl: typofix" +------------------------------------------------ + +After that, you can go back to what you were working on with +`git stash pop`: + +------------------------------------------------ +$ git stash pop +------------------------------------------------ + + +[[ensuring-good-performance]] +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. + + +[[ensuring-reliability]] +Ensuring reliability +-------------------- + +[[checking-for-corruption]] +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: + +------------------------------------------------- +$ git fsck +dangling commit 7281251ddd2a61e38657c827739c57015671a6b3 +dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63 +dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5 +dangling blob 218761f9d90712d37a9c5e36f406f92202db07eb +dangling commit bf093535a34a4d35731aa2bd90fe6b176302f14f +dangling commit 8e4bec7f2ddaa268bef999853c25755452100f8e +dangling tree d50bb86186bf27b681d25af89d3b5b68382e4085 +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. + +[[recovering-lost-changes]] +Recovering lost changes +~~~~~~~~~~~~~~~~~~~~~~~ + +[[reflogs]] +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. + +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, + +------------------------------------------------- +$ 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: + +------------------------------------------------- +$ git show master@{2} # See where the branch pointed 2, +$ git show master@{3} # 3, ... changes ago. +$ gitk master@{yesterday} # See where it pointed yesterday, +$ gitk master@{"1 week ago"} # ... or last week +$ git log --walk-reflogs master # show reflog entries for master +------------------------------------------------- + +A separate reflog is kept for the HEAD, so + +------------------------------------------------- +$ git show HEAD@{"1 week ago"} +------------------------------------------------- + +will show what HEAD pointed to one week ago, not what the current branch +pointed to one week ago. This allows you to see the history of what +you've checked out. + +The reflogs are kept by default for 30 days, after which they may be +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:git-rev-parse[1] for details. + +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. + +[[dangling-object-recovery]] +Examining dangling objects +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In some situations the reflog may not be able to save you. For example, +suppose you delete a branch, then realize you need the history it +contained. The reflog is also deleted; however, if you have not yet +pruned the repository, then you may still be able to find the lost +commits in the dangling objects that `git fsck` reports. See +<<dangling-objects>> for the details. + +------------------------------------------------- +$ git fsck +dangling commit 7281251ddd2a61e38657c827739c57015671a6b3 +dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63 +dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5 +... +------------------------------------------------- + +You can examine +one of those dangling commits with, for example, + +------------------------------------------------ +$ gitk 7281251ddd --not --all +------------------------------------------------ + +which does what it sounds like: it says that you want to see the commit +history that is described by the dangling commit(s), but not the +history that is described by all your existing branches and tags. Thus +you get exactly the history reachable from that commit that is lost. +(And notice that it might not be just one commit: we only report the +"tip of the line" as being dangling, but there might be a whole deep +and complex commit history that was dropped.) + +If you decide you want the history back, you can always create a new +reference pointing to it, for example, a new branch: + +------------------------------------------------ +$ git branch recovered-branch 7281251ddd +------------------------------------------------ + +Other types of dangling objects (blobs and trees) are also possible, and +dangling objects can arise in other situations. + + +[[sharing-development]] +Sharing development with others +=============================== + +[[getting-updates-With-git-pull]] +Getting updates with git pull +----------------------------- + +After you clone a repository and commit a few changes of your own, you +may wish to check the original repository for updates and merge them +into your own work. + +We have already seen <<Updating-a-repository-With-git-fetch,how to +keep remote tracking branches up to date>> with linkgit:git-fetch[1], +and how to merge two branches. So you can merge in changes from the +original repository's master branch with: + +------------------------------------------------- +$ git fetch +$ git merge origin/master +------------------------------------------------- + +However, the linkgit:git-pull[1] command provides a way to do this in +one step: + +------------------------------------------------- +$ git pull origin master +------------------------------------------------- + +In fact, if you have "master" checked out, then by default "git pull" +merges from the HEAD branch of the origin repository. So often you can +accomplish the above with just a simple + +------------------------------------------------- +$ git pull +------------------------------------------------- + +More generally, a branch that is created from a remote branch will pull +by default from that branch. See the descriptions of the +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 +producing a default commit message documenting the branch and +repository that you pulled from. + +(But note that no such commit will be created in the case of a +<<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, +in which case it just merges in a branch from the current repository; so +the commands + +------------------------------------------------- +$ git pull . branch +$ git merge branch +------------------------------------------------- + +are roughly equivalent. The former is actually very commonly used. + +[[submitting-patches]] +Submitting patches to a project +------------------------------- + +If you just have a few changes, the simplest way to submit them may +just be to send them as patches in email: + +First, use linkgit:git-format-patch[1]; for example: + +------------------------------------------------- +$ 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. + +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. + +[[importing-patches]] +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 + +------------------------------------------------- +$ 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 +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 +------------------------------------------------- + +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 +the original mailbox, with authorship and commit log message each +taken from the message containing each patch. + +[[public-repositories]] +Public git repositories +----------------------- + +Another way to submit changes to a project is to tell the maintainer +of that project to pull the changes from your repository using +linkgit:git-pull[1]. In the section "<<getting-updates-With-git-pull, +Getting updates with `git pull`>>" we described this as a way to get +updates from the "main" repository, but it works just as well in the +other direction. + +If you and the maintainer both have accounts on the same machine, then +you can just pull changes from each other's repositories directly; +commands that accept repository URLs as arguments will also accept a +local directory name: + +------------------------------------------------- +$ git clone /path/to/repository +$ git pull /path/to/other/repository +------------------------------------------------- + +or an ssh URL: + +------------------------------------------------- +$ git clone ssh://yourhost/~you/repository +------------------------------------------------- + +For projects with few developers, or for synchronizing a few private +repositories, this may be all you need. + +However, the more common way to do this is to maintain a separate public +repository (usually on a different host) for others to pull changes +from. This is usually more convenient, and allows you to cleanly +separate private work in progress from publicly visible work. + +You will continue to do your day-to-day work in your personal +repository, but periodically "push" changes from your personal +repository into your public repository, allowing other developers to +pull from that repository. So the flow of changes, in a situation +where there is one other developer with a public repository, looks +like this: + + you push + your personal repo ------------------> your public repo + ^ | + | | + | you pull | they pull + | | + | | + | they push V + their public repo <------------------- their repo + +We explain how to do this in the following sections. + +[[setting-up-a-public-repository]] +Setting up a public repository +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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: + +------------------------------------------------- +$ git clone --bare ~/proj proj.git +$ 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 +around it. + +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 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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 +"<<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 +git-daemon-export-ok. Passing some directory paths as `git daemon` +arguments will further restrict the exports to those paths. + +You can also run `git daemon` as an inetd service; see the +linkgit:git-daemon[1] man page for details. (See especially the +examples section.) + +[[exporting-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. + +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: + +------------------------------------------------- +$ mv proj.git /home/you/public_html/proj.git +$ cd proj.git +$ git --bare update-server-info +$ 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 +clone or pull from that URL, for example with a command line like: + +------------------------------------------------- +$ git clone http://yourserver.com/~you/proj.git +------------------------------------------------- + +(See also +link:howto/setup-git-server-over-http.txt[setup-git-server-over-http] +for a slightly more sophisticated setup using WebDAV which also +allows pushing over http.) + +[[pushing-changes-to-a-public-repository]] +Pushing changes to a public repository +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Note that the two techniques outlined above (exporting via +<<exporting-via-http,http>> or <<exporting-via-git,git>>) allow other +maintainers to fetch your latest changes, but they do not allow write +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 + +------------------------------------------------- +$ git push ssh://yourserver.com/~you/proj.git master:master +------------------------------------------------- + +or just + +------------------------------------------------- +$ git push ssh://yourserver.com/~you/proj.git master +------------------------------------------------- + +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 +<<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! + +As with `git fetch`, you may also set up configuration options to +save typing; so, for example, after + +------------------------------------------------- +$ cat >>.git/config <<EOF +[remote "public-repo"] + url = ssh://yourserver.com/~you/proj.git +EOF +------------------------------------------------- + +you should be able to perform the above 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. + +[[forcing-push]] +What to do when a push fails +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If a push would not result in a <<fast-forwards,fast-forward>> of the +remote branch, then it will fail with an error like: + +------------------------------------------------- +error: remote 'refs/heads/master' is not an ancestor of + local 'refs/heads/master'. + Maybe you are not up-to-date and need to pull first? +error: failed to push to 'ssh://yourserver.com/~you/proj.git' +------------------------------------------------- + +This can happen, for example, if you: + + - use `git reset --hard` to remove already-published commits, or + - use `git commit --amend` to replace already-published commits + (as in <<fixing-a-mistake-by-rewriting-history>>), or + - use `git rebase` to rebase any already-published commits (as + in <<using-git-rebase>>). + +You may force `git push` to perform the update anyway by preceding the +branch name with a plus sign: + +------------------------------------------------- +$ git push 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. +(See <<problems-With-rewriting-history>>.) + +Nevertheless, this is a common practice for people that need a simple +way to publish a work-in-progress patch series, and it is an acceptable +compromise as long as you warn other developers that this is how you +intend to manage the branch. + +It's also possible for a push to fail in this way when other people have +the right to push to the same repository. In that case, the correct +solution is to retry the push after first updating your work: either by a +pull, or by a fetch followed by a rebase; see the +<<setting-up-a-shared-repository,next section>> and +linkgit:gitcvs-migration[7] for more. + +[[setting-up-a-shared-repository]] +Setting up a shared repository +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Another way to collaborate is by using a model similar to that +commonly used in CVS, where several developers with special rights +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 +repositories, this mode of operation is not generally recommended, +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: + + - Git's ability to quickly import and merge patches allows a + single maintainer to process incoming changes even at very + high rates. And when that becomes too much, `git pull` provides + an easy way for that maintainer to delegate this job to other + maintainers while still allowing optional review of incoming + changes. + - Since every developer's repository has the same complete copy + of the project history, no repository is special, and it is + trivial for another developer to take over maintenance of a + project, either by mutual agreement, or because a maintainer + becomes unresponsive or difficult to work with. + - The lack of a central group of "committers" means there is + less need for formal decisions about who is "in" and who is + "out". + +[[setting-up-gitweb]] +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. + +[[sharing-development-examples]] +Examples +-------- + +[[maintaining-topic-branches]] +Maintaining topic branches for a Linux subsystem maintainer +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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: + + - A "test" tree into which patches are initially placed so that they + can get some exposure when integrated with other ongoing development. + This tree is available to Andrew for pulling into -mm whenever he + wants. + + - A "release" tree into which tested patches are moved for final sanity + checking, and as a vehicle to send them upstream to Linus (by sending + him a "please pull" request.) + +He also uses a set of temporary branches ("topic branches"), each +containing a logical grouping of patches. + +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 +$ cd work +------------------------------------------------- + +Linus's tree will be stored in the remote branch named origin/master, +and can be updated using linkgit:git-fetch[1]; you can track other +public trees using linkgit:git-remote[1] to set up a "remote" and +linkgit:git-fetch[1] to keep them up-to-date; see +<<repositories-and-branches>>. + +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 +Linus by default. + +------------------------------------------------- +$ git branch --track test origin/master +$ git branch --track release origin/master +------------------------------------------------- + +These can be easily kept up to date using linkgit:git-pull[1]. + +------------------------------------------------- +$ git checkout test && git pull +$ 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 +the "noise" that this creates in the Linux history, so you should avoid +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. + +A few configuration variables (see linkgit:git-config[1]) can +make it easy to push both branches to your public tree. (See +<<setting-up-a-public-repository>>.) + +------------------------------------------------- +$ cat >> .git/config <<EOF +[remote "mytree"] + url = master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git + push = release + push = test +EOF +------------------------------------------------- + +Then you can push both the test and release trees using +linkgit:git-push[1]: + +------------------------------------------------- +$ git push mytree +------------------------------------------------- + +or push just one of the test and release branches using: + +------------------------------------------------- +$ git push mytree test +------------------------------------------------- + +or + +------------------------------------------------- +$ git push mytree release +------------------------------------------------- + +Now to apply some patches from the community. Think of a short +snappy name for a branch to hold this patch (or related group of +patches), and create a new branch from the current tip of Linus's +branch: + +------------------------------------------------- +$ git checkout -b speed-up-spinlocks origin +------------------------------------------------- + +Now you apply the patch(es), run some tests, and commit the change(s). If +the patch is a multi-part series, then you should apply each as a separate +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 +"test" branch in preparation to make it public: + +------------------------------------------------- +$ git checkout test && git pull . 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 +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. + +------------------------------------------------- +$ git checkout release && git pull . speed-up-spinlocks +------------------------------------------------- + +After a while, you will have a number of branches, and despite the +well chosen names you picked for each of them, you may forget what +they are for, or what status they are in. To get a reminder of what +changes are in a specific branch, use: + +------------------------------------------------- +$ git log linux..branchname | git shortlog +------------------------------------------------- + +To see whether it has already been merged into the test or release branches, +use: + +------------------------------------------------- +$ git log test..branchname +------------------------------------------------- + +or + +------------------------------------------------- +$ git log release..branchname +------------------------------------------------- + +(If this branch has not yet been merged, you will see some log entries. +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. +You detect this when the output from: + +------------------------------------------------- +$ git log origin..branchname +------------------------------------------------- + +is empty. At this point the branch can be deleted: + +------------------------------------------------- +$ 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 +------------------------------------------------- + +and + +------------------------------------------------- +$ git log -p origin..release | git shortlog +------------------------------------------------- + +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 +# is origin, then pull from kernel.org. Otherwise merge +# origin/master branch into test|release branch + +case "$1" in +test|release) + git checkout $1 && git pull . origin + ;; +origin) + before=$(git rev-parse refs/remotes/origin/master) + git fetch origin + after=$(git rev-parse refs/remotes/origin/master) + if [ $before != $after ] + then + git log $before..$after | git shortlog + fi + ;; +*) + echo "Usage: $0 origin|test|release" 1>&2 + exit 1 + ;; +esac +------------------------------------------------- + +------------------------------------------------- +==== merge script ==== +# Merge a branch into either the test or release branch + +pname=$0 + +usage() +{ + echo "Usage: $pname branch test|release" 1>&2 + exit 1 +} + +git show-ref -q --verify -- refs/heads/"$1" || { + echo "Can't see branch <$1>" 1>&2 + usage +} + +case "$2" in +test|release) + if [ $(git log $2..$1 | wc -c) -eq 0 ] + then + echo $1 already merged into $2 1>&2 + exit 1 + fi + git checkout $2 && git pull . $1 + ;; +*) + usage + ;; +esac +------------------------------------------------- + +------------------------------------------------- +==== status script ==== +# report on status of my ia64 GIT tree + +gb=$(tput setab 2) +rb=$(tput setab 1) +restore=$(tput setab 9) + +if [ `git rev-list test..release | wc -c` -gt 0 ] +then + echo $rb Warning: commits in release that are not in test $restore + git log test..release +fi + +for branch in `git show-ref --heads | sed 's|^.*/||'` +do + if [ $branch = test -o $branch = release ] + then + continue + fi + + echo -n $gb ======= $branch ====== $restore " " + status= + for ref in test release origin/master + do + if [ `git rev-list $ref..$branch | wc -c` -gt 0 ] + then + status=$status${ref:0:1} + fi + done + case $status in + trl) + echo $rb Need to pull into test $restore + ;; + rl) + echo "In test" + ;; + l) + echo "Waiting for linus" + ;; + "") + echo $rb All done $restore + ;; + *) + echo $rb "<$status>" $restore + ;; + esac + git log origin/master..$branch | git shortlog +done +------------------------------------------------- + + +[[cleaning-up-history]] +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. + +However, there is a situation in which it can be useful to violate this +assumption. + +[[patch-series]] +Creating the perfect patch series +--------------------------------- + +Suppose you are a contributor to a large project, and you want to add a +complicated feature, and to present it to the other developers in a way +that makes it easy for them to read your changes, verify that they are +correct, and understand why you made each change. + +If you present all of your changes as a single patch (or commit), they +may find that it is too much to digest all at once. + +If you present them with the entire history of your work, complete with +mistakes, corrections, and dead ends, they may be overwhelmed. + +So the ideal is usually to produce a series of patches such that: + + 1. Each patch can be applied in order. + + 2. Each patch includes a single logical change, together with a + message explaining the change. + + 3. No patch introduces a regression: after applying any initial + part of the series, the resulting project still compiles and + works, and has no bugs that it didn't have before. + + 4. The complete series produces the same end result as your own + (probably much messier!) development process did. + +We will introduce some tools that can help you do this, explain how to +use them, and then explain some of the problems that can arise because +you are rewriting history. + +[[using-git-rebase]] +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: + +------------------------------------------------- +$ git checkout -b mywork origin +$ vi file.txt +$ git commit +$ vi otherfile.txt +$ git commit +... +------------------------------------------------- + +You have performed no merges into mywork, so it is just a simple linear +sequence of patches on top of "origin": + +................................................ + o--o--o <-- origin + \ + o--o--o <-- mywork +................................................ + +Some more interesting work has been done in the upstream project, and +"origin" has advanced: + +................................................ + o--o--O--o--o--o <-- origin + \ + a--b--c <-- mywork +................................................ + +At this point, you could use "pull" to merge your changes back in; +the result would create a new merge commit, like this: + +................................................ + o--o--O--o--o--o <-- origin + \ \ + a--b--c--m <-- mywork +................................................ + +However, if you prefer to keep the history in mywork a simple series of +commits without any merges, you may instead choose to use +linkgit:git-rebase[1]: + +------------------------------------------------- +$ git checkout mywork +$ 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 +point at the latest version of origin, then apply each of the saved +patches to the new mywork. The result will look like: + + +................................................ + o--o--O--o--o--o <-- origin + \ + a'--b'--c' <-- mywork +................................................ + +In the process, it may discover conflicts. In that case it will stop +and allow you to fix the conflicts; after fixing conflicts, use `git add` +to update the index with those contents, and then, instead of +running `git commit`, just run + +------------------------------------------------- +$ git rebase --continue +------------------------------------------------- + +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: + +------------------------------------------------- +$ git rebase --abort +------------------------------------------------- + +[[rewriting-one-commit]] +Rewriting a single commit +------------------------- + +We saw in <<fixing-a-mistake-by-rewriting-history>> that you can replace the +most recent commit using + +------------------------------------------------- +$ 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. + +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 +------------------------------------------------- + +(Either gitk or `git log` may be useful for finding the commit.) + +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>>): + +------------------------------------------------- +$ git checkout bad +$ # make changes here and update the index +$ git commit --amend +$ git rebase --onto HEAD bad mywork +------------------------------------------------- + +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 + +------------------------------------------------- +$ git tag -d bad +------------------------------------------------- + +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. + +[[reordering-patch-series]] +Reordering or selecting from a patch series +------------------------------------------- + +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: + +------------------------------------------------- +$ git checkout -b mywork-new origin +$ gitk origin..mywork & +------------------------------------------------- + +and browse through the list of patches in the mywork branch using gitk, +applying them (possibly in a different order) to mywork-new using +cherry-pick, and possibly modifying them as you go using `git commit --amend`. +The linkgit:git-gui[1] command may also help as it allows you to +individually select diff hunks for inclusion in the index (by +right-clicking on the diff hunk and choosing "Stage Hunk for Commit"). + +Another technique is to use `git format-patch` to create a series of +patches, then reset the state to before the patches: + +------------------------------------------------- +$ git format-patch origin +$ git reset --hard origin +------------------------------------------------- + +Then modify, reorder, or eliminate patches as preferred before applying +them again with linkgit:git-am[1]. + +[[patch-series-tools]] +Other tools +----------- + +There are numerous other tools, such as StGit, which exist for the +purpose of maintaining a patch series. These are outside of the scope of +this manual. + +[[problems-With-rewriting-history]] +Problems with rewriting history +------------------------------- + +The primary problem with rewriting the history of a branch has to do +with merging. Suppose somebody fetches your branch and merges it into +their branch, with a result something like this: + +................................................ + o--o--O--o--o--o <-- origin + \ \ + t--t--t--m <-- their branch: +................................................ + +Then suppose you modify the last three commits: + +................................................ + o--o--o <-- new head of origin + / + o--o--O--o--o--o <-- old head of origin +................................................ + +If we examined all this history together in one repository, it will +look like: + +................................................ + o--o--o <-- new head of origin + / + o--o--O--o--o--o <-- old head of origin + \ \ + t--t--t--m <-- their branch: +................................................ + +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 +new) lines of development, instead of trying to replace the old by the +new. The results are likely to be unexpected. + +You may still choose to publish branches whose history is rewritten, +and it may be useful for others to be able to fetch those branches in +order to examine or test them, but they should not attempt to pull such +branches into their own work. + +For true distributed development that supports proper merging, +published branches should never be rewritten. + +[[bisect-merges]] +Why bisecting merge commits can be harder than bisecting linear history +----------------------------------------------------------------------- + +The linkgit:git-bisect[1] command correctly handles history that +includes merge commits. However, when the commit that it finds is a +merge commit, the user may need to work harder than usual to figure out +why that commit introduced a problem. + +Imagine this history: + +................................................ + ---Z---o---X---...---o---A---C---D + \ / + o---o---Y---...---o---B +................................................ + +Suppose that on the upper line of development, the meaning of one +of the functions that exists at Z is changed at commit X. The +commits from Z leading to A change both the function's +implementation and all calling sites that exist at Z, as well +as new calling sites they add, to be consistent. There is no +bug at A. + +Suppose that in the meantime on the lower line of development somebody +adds a new calling site for that function at commit Y. The +commits from Z leading to B all assume the old semantics of that +function and the callers and the callee are consistent with each +other. There is no bug at B, either. + +Suppose further that the two development lines merge cleanly at C, +so no conflict resolution is required. + +Nevertheless, the code at C is broken, because the callers added +on the lower line of development have not been converted to the new +semantics introduced on the upper line of development. So if all +you know is that D is bad, that Z is good, and that +linkgit:git-bisect[1] identifies C as the culprit, how will you +figure out that the problem is due to this change in semantics? + +When the result of a `git bisect` is a non-merge commit, you should +normally be able to discover the problem by examining just that commit. +Developers can make this easy by breaking their changes into small +self-contained commits. That won't help in the case above, however, +because the problem isn't obvious from examination of any single +commit; instead, a global view of the development is required. To +make matters worse, the change in semantics in the problematic +function may be just one small part of the changes in the upper +line of development. + +On the other hand, if instead of merging at C you had rebased the +history between Z to B on top of A, you would have gotten this +linear history: + +................................................................ + ---Z---o---X--...---o---A---o---o---Y*--...---o---B*--D* +................................................................ + +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 +working on an otherwise merge-heavy project, keep the history +linear by rebasing against the latest upstream version before +publishing. + +[[advanced-branch-management]] +Advanced branch management +========================== + +[[fetching-individual-branches]] +Fetching individual branches +---------------------------- + +Instead of using linkgit:git-remote[1], you can also choose just +to update one branch at a time, and to store it locally under an +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. + +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 +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: + +[[fetch-fast-forwards]] +git fetch and fast-forwards +--------------------------- + +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 +commit. Git calls this process a <<fast-forwards,fast-forward>>. + +A fast-forward looks something like this: + +................................................ + o--o--o--o <-- old head of the branch + \ + o--o--o <-- new head of the branch +................................................ + + +In some cases it is possible that the new head will *not* actually be +a descendant of the old head. For example, the developer may have +realized she made a serious mistake, and decided to backtrack, +resulting in a situation like: + +................................................ + o--o--o--o--a--b <-- old head of the branch + \ + o--o--o <-- new head of the branch +................................................ + +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 +described in the following section. However, note that in the +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. + +[[forcing-fetch]] +Forcing git fetch to do non-fast-forward updates +------------------------------------------------ + +If git fetch fails because the new head of a branch is not a +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" +flag to force updates of all the fetched branches, as in: + +------------------------------------------------- +$ git fetch -f origin +------------------------------------------------- + +Be aware that commits that the old version of example/master pointed at +may be lost, as we saw in the previous section. + +[[remote-branch-configuration]] +Configuring remote branches +--------------------------- + +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 +linkgit:git-config[1]: + +------------------------------------------------- +$ git config -l +core.repositoryformatversion=0 +core.filemode=true +core.logallrefupdates=true +remote.origin.url=git://git.kernel.org/pub/scm/git/git.git +remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* +branch.master.remote=origin +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 +------------------------------------------------- + +then the following two 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 +------------------------------------------------- + +Even better, if you add one more option: + +------------------------------------------------- +$ git config remote.example.fetch master:refs/remotes/example/master +------------------------------------------------- + +then the following commands will all 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 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. + + +[[git-concepts]] +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. + +We start with the most important, the <<def_object_database,object +database>> and the <<def_index,index>>. + +[[the-object-database]] +The Object Database +------------------- + + +We already saw in <<understanding-commits>> that all commits are stored +under a 40-digit "object name". In fact, all the information needed to +represent the history of a project is stored in objects with such names. +In each case the name is calculated by taking the SHA-1 hash of the +contents of the object. The SHA-1 hash is a cryptographic hash function. +What that means to us is that it is impossible to find two different +objects with the same name. This has a number of advantages; among +others: + +- Git can quickly determine whether two objects are identical or not, + just by comparing names. +- Since object names are computed the same way in every repository, the + same content stored in two repositories will always be stored under + the same name. +- Git can detect errors when it reads an object, by checking that the + object's name is still the SHA-1 hash of its contents. + +(See <<object-details>> for the details of the object formatting and +SHA-1 calculation.) + +There are four different types of objects: "blob", "tree", "commit", and +"tag". + +- A <<def_blob_object,"blob" object>> is used to store file data. +- A <<def_tree_object,"tree" object>> ties one or more + "blob" objects into a directory structure. In addition, a tree object + can refer to other tree objects, thus creating a directory hierarchy. +- A <<def_commit_object,"commit" object>> ties such directory hierarchies + together into a <<def_DAG,directed acyclic graph>> of revisions--each + commit contains the object name of exactly one tree designating the + directory hierarchy at the time of the commit. In addition, a commit + refers to "parent" commit objects that describe the history of how we + arrived at that directory hierarchy. +- A <<def_tag_object,"tag" object>> symbolically identifies and can be + used to sign other objects. It contains the object name and type of + another object, a symbolic name (of course!) and, optionally, a + signature. + +The object types in some more detail: + +[[commit-object]] +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 +linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite +commit: + +------------------------------------------------ +$ git show -s --pretty=raw 2be7fcb476 +commit 2be7fcb4764f2dbcee52635b91fedb1b3dcf7ab4 +tree fb3a8bdd0ceddd019615af4d57a53f43d8cee2bf +parent 257a84d9d02e90447b149af58b271c19405edb6a +author Dave Watson <dwatson@mimvista.com> 1187576872 -0400 +committer Junio C Hamano <gitster@pobox.com> 1187591163 -0700 + + Fix misspelling of 'suppress' in docs + + Signed-off-by: Junio C Hamano <gitster@pobox.com> +------------------------------------------------ + +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 + 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 + represents the initial revision of a project. Each project must have + at least one root. A project can also have multiple roots, though + that isn't common (or necessarily a good idea). +- an author: The name of the person responsible for this change, together + with its date. +- a committer: The name of the person who actually created the commit, + with the date it was done. This may be different from the author, for + example, if the author was someone who wrote a patch and emailed it + to the person who used it to create the commit. +- a comment describing this commit. + +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 +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]). + +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 +taken from the content currently stored in the index. + +[[tree-object]] +Tree Object +~~~~~~~~~~~ + +The ever-versatile linkgit:git-show[1] command can also be used to +examine tree objects, but linkgit:git-ls-tree[1] will give you more +details: + +------------------------------------------------ +$ git ls-tree fb3a8bdd0ce +100644 blob 63c918c667fa005ff12ad89437f2fdc80926e21c .gitignore +100644 blob 5529b198e8d14decbe4ad99db3f7fb632de0439d .mailmap +100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3 COPYING +040000 tree 2fb783e477100ce076f6bf57e4a6f026013dc745 Documentation +100755 blob 3c0032cec592a765692234f1cba47dfdcc3a9200 GIT-VERSION-GEN +100644 blob 289b046a443c0647624607d471289b2c7dcd470b INSTALL +100644 blob 4eb463797adc693dc168b926b6932ff53f17d0b1 Makefile +100644 blob 548142c327a6790ff8821d67c2ee1eff7a656b52 README +... +------------------------------------------------ + +As you can see, a tree object contains a list of entries, each with a +mode, object type, SHA-1 name, and name, sorted by name. It represents +the contents of a single directory tree. + +The object type may be a blob, representing the contents of a file, or +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 +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 +attention to the executable bit. + +[[blob-object]] +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: + +------------------------------------------------ +$ git show 6ff87c4664 + + Note that the only valid version of the GPL as far as this project + is concerned is _this_ particular version of the license (ie v2, not + v2.2 or v3.x or whatever), unless explicitly otherwise stated. +... +------------------------------------------------ + +A "blob" object is nothing but a binary blob of data. It doesn't refer +to anything else or have attributes of any kind. + +Since the blob is entirely defined by its data, if two files in a +directory tree (or in multiple different versions of the repository) +have the same contents, they will share the same blob object. The object +is totally independent of its location in the directory tree, and +renaming a file does not change the object that file is associated with. + +Note that any tree or blob object can be examined using +linkgit:git-show[1] with the <revision>:<path> syntax. This can +sometimes be useful for browsing the contents of a tree that is not +currently checked out. + +[[trust]] +Trust +~~~~~ + +If you receive the SHA-1 name of a blob from one source, and its contents +from another (possibly untrusted) source, you can still trust that those +contents are correct as long as the SHA-1 name agrees. This is because +the SHA-1 is designed so that it is infeasible to find different contents +that produce the same hash. + +Similarly, you need only trust the SHA-1 name of a top-level tree object +to trust the contents of the entire directory that it refers to, and if +you receive the SHA-1 name of a commit from a trusted source, then you +can easily verify the entire history of commits reachable through +parents of that commit, and all of those contents of the trees referred +to by those commits. + +So to introduce some real trust in the system, the only thing you need +to do is to digitally sign just 'one' special note, which includes the +name of a top-level commit. Your digital signature shows others +that you trust that commit, and the immutability of the history of +commits tells others that they can trust the whole history. + +In other words, you can easily validate a whole archive by just +sending out a single email that tells the people the name (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... + +[[tag-object]] +Tag Object +~~~~~~~~~~ + +A tag object contains an object, object type, tag name, the name of the +person ("tagger") who created the tag, and a message, which may contain +a signature, as can be seen using linkgit:git-cat-file[1]: + +------------------------------------------------ +$ git cat-file tag v1.5.0 +object 437b1b20df4b356c9342dac8d38849f24ef44f27 +type commit +tag v1.5.0 +tagger Junio C Hamano <junkio@cox.net> 1171411200 +0000 + +GIT 1.5.0 +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.6 (GNU/Linux) + +iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui +nLE/L9aUXdWeTFPron96DLA= +=2E+0 +-----END PGP SIGNATURE----- +------------------------------------------------ + +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/"). + +[[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). + +Unfortunately this system becomes inefficient once a project has a +lot of objects. Try this on an old project: + +------------------------------------------------ +$ git count-objects +6930 objects, 47620 kilobytes +------------------------------------------------ + +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 +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]. + +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. +------------------------------------------------ + +You can then run + +------------------------------------------------ +$ 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). +You can verify that the loose objects are gone by looking at the +.git/objects directory or by running + +------------------------------------------------ +$ git count-objects +0 objects, 0 kilobytes +------------------------------------------------ + +Although the object files are gone, any commands that refer to those +objects will work exactly as they did before. + +The linkgit:git-gc[1] command performs packing, pruning, and more for +you, so is normally the only high-level command you need. + +[[dangling-objects]] +Dangling objects +~~~~~~~~~~~~~~~~ + +The linkgit:git-fsck[1] command will sometimes complain about dangling +objects. They are not a problem. + +The most common cause of dangling objects is that you've rebased a +branch, or you have pulled from somebody else who rebased a branch--see +<<cleaning-up-history>>. In that case, the old head of the original +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 +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 +not being pointed to by any commit or tree, so it's now a dangling blob +object. + +Similarly, when the "recursive" merge strategy runs, and finds that +there are criss-cross merges and thus more than one merge base (which is +fairly unusual, but it does happen), it will generate one temporary +midway tree (or possibly even more, if you had lots of criss-crossing +merges and more than two merge bases) as a temporary internal merge +base, and again, those are real objects, but the end result will not end +up pointing to them, so they end up "dangling" in your repository. + +Generally, dangling objects aren't anything to worry about. They can +even be very useful: if you screw something up, the dangling objects can +be how you recover your old tree (say, you did a rebase, and realized +that you really didn't want to--you can look at what dangling objects +you have, and decide to reset your head to some old dangling state). + +For commits, you can just use: + +------------------------------------------------ +$ gitk <dangling-commit-sha-goes-here> --not --all +------------------------------------------------ + +This asks for all the history reachable from the given commit but not +from any branch, tag, or other reference. If you decide it's something +you want, you can always create a new reference to it, e.g., + +------------------------------------------------ +$ git branch recovered-branch <dangling-commit-sha-goes-here> +------------------------------------------------ + +For blobs and trees, you can't do the same, but you can still examine +them. You can just do + +------------------------------------------------ +$ 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 +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, +leaving _some_ of the new objects in the object database, but just +dangling and useless. + +Anyway, once you are sure that you're not interested in any dangling +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 +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). + +[[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 +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 +mechanism. + +As a last resort, you can search for the corrupted objects and attempt +to replace them by hand. Back up your repository before attempting this +in case you corrupt things even more in the process. + +We'll assume that the problem is a single missing or corrupted blob, +which is sometimes a solvable problem. (Recovering missing trees and +especially commits is *much* harder). + +Before starting, verify that there is corruption, and figure out where +it is with linkgit:git-fsck[1]; this may be time-consuming. + +Assume the output looks like this: + +------------------------------------------------ +$ git fsck --full +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 +still examine the tree that pointed to it with linkgit:git-ls-tree[1], +which might output something like: + +------------------------------------------------ +$ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 +100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8 .gitignore +100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883 .mailmap +100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c COPYING +... +100644 blob 4b9458b3786228369c63936db65827de3cc06200 myfile +... +------------------------------------------------ + +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 +the same as the copy you have checked out in your working tree at +"somedirectory/myfile"; you can test whether that's right with +linkgit:git-hash-object[1]: + +------------------------------------------------ +$ git hash-object -w somedirectory/myfile +------------------------------------------------ + +which will create and store a blob object with the contents of +somedirectory/myfile, and output the SHA-1 of that object. if you're +extremely lucky it might be 4b9458b3786228369c63936db65827de3cc06200, in +which case you've guessed right, and the corruption is fixed! + +Otherwise, you need more information. How do you tell which version of +the file has been lost? + +The easiest way to do this is with: + +------------------------------------------------ +$ git log --raw --all --full-history -- somedirectory/myfile +------------------------------------------------ + +Because you're asking for raw output, you'll now get something like + +------------------------------------------------ +commit abc +Author: +Date: +... +:100644 100644 4b9458b... newsha... M somedirectory/myfile + + +commit xyz +Author: +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". +You also know the commit messages that went with the change from oldsha +to 4b9458b and with the change from 4b9458b to newsha. + +If you've been committing small enough changes, you may now have a good +shot at reconstructing the contents of the in-between state 4b9458b. + +If you can do that, you can now recreate the missing object with + +------------------------------------------------ +$ git hash-object -w <recreated-file> +------------------------------------------------ + +and your repository is good again! + +(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 +just missing one particular blob version. + +[[the-index]] +The index +----------- + +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: + +------------------------------------------------- +$ git ls-files --stage +100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0 .gitignore +100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0 .mailmap +100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0 COPYING +100644 a37b2152bd26be2c2289e1f57a292534a51a93c7 0 Documentation/.gitignore +100644 fbefe9a45b00a54b58d94d06eca48b03d40a50e0 0 Documentation/Makefile +... +100644 2511aef8d89ab52be5ec6a5e46236b4b6bcd07ea 0 xdiff/xtypes.h +100644 2ade97b2574a9f77e7ae4002a4e07a6a38e46d07 0 xdiff/xutils.c +100644 d5de8292e05e7c36c4b68857c1cf9855e3d2f70a 0 xdiff/xutils.h +------------------------------------------------- + +Note that in older documentation you may see the index called the +"current directory cache" or just the "cache". It has three important +properties: + +1. The index contains all the information necessary to generate a single +(uniquely determined) tree object. ++ +For example, running linkgit:git-commit[1] generates this tree object +from the index, stores it in the object database, and uses it as the +tree object associated with the new commit. + +2. The index enables fast comparisons between the tree object it defines +and the working tree. ++ +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 +data from such files to look for changes. + +3. It can efficiently represent information about merge conflicts +between different tree objects, allowing each pathname to be +associated with sufficient information about the trees involved that +you can create a three-way merge between them. ++ +We saw in <<conflict-resolution>> that during a merge the index can +store multiple versions of a single file (called "stages"). The third +column in the linkgit:git-ls-files[1] output above is the stage +number, and will take on values other than 0 for files with merge +conflicts. + +The index is thus a sort of temporary staging area, which is filled with +a tree which you are in the process of working on. + +If you blow the index away entirely, you generally haven't lost any +information as long as you have the name of the tree that it described. + +[[submodules]] +Submodules +========== + +Large projects are often composed of smaller, self-contained modules. For +example, an embedded Linux distribution's source tree would include every +piece of software in the distribution with some local modifications; a movie +player might need to build against a specific, known-working version of a +decompression library; several independent programs might all share the same +build scripts. + +With centralized revision control systems this is often accomplished by +including every module in one single repository. Developers can check out +all modules or only the modules they need to work with. They can even modify +files across several modules in a single commit while moving things around +or updating APIs and translations. + +Git does not allow partial checkouts, so duplicating this approach in Git +would force developers to keep a local copy of modules they are not +interested in touching. Commits in an enormous checkout would be slower +than you'd expect as Git would have to scan every directory for changes. +If modules have a lot of local history, clones would take forever. + +On the plus side, distributed revision control systems can much better +integrate with external sources. In a centralized model, a single arbitrary +snapshot of the external project is exported from its own revision control +and then imported into the local revision control on a vendor branch. All +the history is hidden. With distributed revision control you can clone the +entire external history and much more easily follow development and re-merge +local changes. + +Git's submodule support allows a repository to contain, as a subdirectory, a +checkout of an external project. Submodules maintain their own identity; +the submodule support just stores the submodule repository location and +commit ID, so other developers who clone the containing project +("superproject") can easily clone all the submodules at the same revision. +Partial checkouts of the superproject are possible: you can tell Git to +clone none, some or all of the submodules. + +The linkgit:git-submodule[1] command is available since Git 1.5.3. Users +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 +repositories that can be used later as a submodule: + +------------------------------------------------- +$ mkdir ~/git +$ cd ~/git +$ for i in a b c d +do + mkdir $i + cd $i + git init + echo "module $i" > $i.txt + git add $i.txt + git commit -m "Initial commit, submodule $i" + cd .. +done +------------------------------------------------- + +Now create the superproject and add all the submodules: + +------------------------------------------------- +$ mkdir super +$ cd super +$ git init +$ for i in a b c d +do + git submodule add ~/git/$i $i +done +------------------------------------------------- + +NOTE: Do not use local URLs here if you plan to publish your superproject! + +See what files `git submodule` created: + +------------------------------------------------- +$ ls -a +. .. .git .gitmodules a b c d +------------------------------------------------- + +The `git submodule add <repo> <path>` command does a couple of things: + +- 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. +- It adds the submodule's current commit ID to the index, ready to be + committed. + +Commit the superproject: + +------------------------------------------------- +$ git commit -m "Add submodules a, b, c and d." +------------------------------------------------- + +Now clone the superproject: + +------------------------------------------------- +$ cd .. +$ git clone super cloned +$ cd cloned +------------------------------------------------- + +The submodule directories are there, but they're empty: + +------------------------------------------------- +$ ls -a a +. .. +$ git submodule status +-d266b9873ad50488163457f025db7cdd9683d88b a +-e81d457da15309b4fef4249aba9b50187999670d b +-c1536a972b9affea0f16e0680ba87332dc059146 c +-d96249ff5d57de5de093e6baff9e0aafa5276a74 d +------------------------------------------------- + +NOTE: The commit object names shown above would be different for you, but they +should match the HEAD commit object names of your repositories. You can check +it by running `git ls-remote ../a`. + +Pulling down the submodules is a two-step process. First run `git submodule +init` to add the submodule repository URLs to `.git/config`: + +------------------------------------------------- +$ git submodule init +------------------------------------------------- + +Now use `git submodule update` to clone the repositories and check out the +commits specified in the superproject: + +------------------------------------------------- +$ git submodule update +$ cd a +$ ls -a +. .. .git a.txt +------------------------------------------------- + +One major difference between `git submodule update` and `git submodule add` is +that `git submodule update` checks out a specific commit, rather than the tip +of a branch. It's like checking out a tag: the head is detached, so you're not +working on a branch. + +------------------------------------------------- +$ git branch +* (no branch) + master +------------------------------------------------- + +If you want to make a change within a submodule and you have a detached head, +then you should create or checkout a branch, make your changes, publish the +change within the submodule, and then update the superproject to reference the +new commit: + +------------------------------------------------- +$ git checkout master +------------------------------------------------- + +or + +------------------------------------------------- +$ git checkout -b fix-up +------------------------------------------------- + +then + +------------------------------------------------- +$ echo "adding a line again" >> a.txt +$ git commit -a -m "Updated the submodule from within the superproject." +$ git push +$ cd .. +$ git diff +diff --git a/a b/a +index d266b98..261dfac 160000 +--- a/a ++++ b/a +@@ -1 +1 @@ +-Subproject commit d266b9873ad50488163457f025db7cdd9683d88b ++Subproject commit 261dfac35cb99d380eb966e102c1197139f7fa24 +$ git add a +$ git commit -m "Updated submodule a." +$ git push +------------------------------------------------- + +You have to run `git submodule update` after `git pull` if you want to update +submodules, too. + +Pitfalls with submodules +------------------------ + +Always publish the submodule change before publishing the change to the +superproject that references it. If you forget to publish the submodule change, +others won't be able to clone the repository: + +------------------------------------------------- +$ cd ~/git/super/a +$ echo i added another line to this file >> a.txt +$ git commit -a -m "doing it wrong this time" +$ cd .. +$ git add a +$ git commit -m "Updated submodule a again." +$ git push +$ cd ~/git/cloned +$ git pull +$ git submodule update +error: pathspec '261dfac35cb99d380eb966e102c1197139f7fa24' did not match any file(s) known to git. +Did you forget to 'git add'? +Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a' +------------------------------------------------- + +You also should not rewind branches in a submodule beyond commits that were +ever recorded in any superproject. + +It's not safe to run `git submodule update` if you've made and committed +changes within a submodule without checking out a branch first. They will be +silently overwritten: + +------------------------------------------------- +$ cat a.txt +module a +$ echo line added from private2 >> a.txt +$ git commit -a -m "line added inside private2" +$ cd .. +$ git submodule update +Submodule path 'a': checked out 'd266b9873ad50488163457f025db7cdd9683d88b' +$ cd a +$ cat a.txt +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. + +[[low-level-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 +understand its inner workings. + +[[object-manipulation]] +Object access and manipulation +------------------------------ + +The linkgit:git-cat-file[1] command can show the contents of any object, +though the higher-level linkgit:git-show[1] is usually more useful. + +The linkgit:git-commit-tree[1] command allows constructing commits with +arbitrary parents and trees. + +A tree can be created with linkgit:git-write-tree[1] and its data can be +accessed by linkgit:git-ls-tree[1]. Two trees can be compared with +linkgit:git-diff-tree[1]. + +A tag is created with linkgit:git-mktag[1], and the signature can be +verified by linkgit:git-verify-tag[1], though it is normally simpler to +use linkgit:git-tag[1] for both. + +[[the-workflow]] +The Workflow +------------ + +High-level operations such as linkgit:git-commit[1], +linkgit:git-checkout[1] and linkgit:git-reset[1] work by moving data +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 +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 +combinations: + +[[working-directory-to-index]] +working directory -> index +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The linkgit:git-update-index[1] command updates the index with +information from the working directory. You generally update the +index information by just specifying the filename you want to update, +like so: + +------------------------------------------------- +$ git update-index filename +------------------------------------------------- + +but to avoid common mistakes with filename globbing etc, the command +will not normally add totally new entries or remove old entries, +i.e. it will normally just update existing cache entries. + +To tell git that yes, you really do realize that certain files no +longer exist, or that new files should be added, you +should use the `--remove` and `--add` flags respectively. + +NOTE! A `--remove` flag does 'not' mean that subsequent filenames will +necessarily be removed: if the files still exist in your directory +structure, the index will be updated with their new status, not +removed. The only thing `--remove` means is that update-index will be +considering a removed file to be a valid thing, and if the file really +does not exist any more, it will update the index accordingly. + +As a special case, you can also do `git update-index --refresh`, which +will refresh the "stat" information of each index to match the current +stat information. It will 'not' update the object status itself, and +it will only update the fields that are used to quickly test whether +an object still matches its old backing store object. + +The previously introduced linkgit:git-add[1] is just a wrapper for +linkgit:git-update-index[1]. + +[[index-to-object-database]] +index -> object database +~~~~~~~~~~~~~~~~~~~~~~~~ + +You write your current index file to a "tree" object with the program + +------------------------------------------------- +$ git write-tree +------------------------------------------------- + +that doesn't come with any options--it will just write out the +current index into the set of tree objects that describe that state, +and it will return the name of the resulting top-level tree. You can +use that tree to re-generate the index at any time by going in the +other direction: + +[[object-database-to-index]] +object database -> index +~~~~~~~~~~~~~~~~~~~~~~~~ + +You read a "tree" file from the object database, and use that to +populate (and overwrite--don't do this if your index contains any +unsaved state that you might want to restore later!) your current +index. Normal operation is just + +------------------------------------------------- +$ git read-tree <SHA-1 of tree> +------------------------------------------------- + +and your index file will now be equivalent to the tree that you saved +earlier. However, that is only your 'index' file: your working +directory contents have not been modified. + +[[index-to-working-directory]] +index -> working directory +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You update your working directory from the index by "checking out" +files. This is not a very common operation, since normally you'd just +keep your files updated, and rather than write to your working +directory, you'd tell the index files about the changes in your +working directory (i.e. `git update-index`). + +However, if you decide to jump to a new version, or check out somebody +else's version, or just restore a previous tree, you'd populate your +index file with read-tree, and then you need to check out the result +with + +------------------------------------------------- +$ git checkout-index filename +------------------------------------------------- + +or, if you want to check out all of the index, use `-a`. + +NOTE! `git checkout-index` normally refuses to overwrite old files, so +if you have an old version of the tree already checked out, you will +need to use the "-f" flag ('before' the "-a" flag or the filename) to +'force' the checkout. + + +Finally, there are a few odds and ends which are not purely moving +from one representation to the other: + +[[tying-it-all-together]] +Tying it all together +~~~~~~~~~~~~~~~~~~~~~ + +To commit a tree you have instantiated with "git write-tree", you'd +create a "commit" object that refers to that tree and the history +behind it--most notably the "parent" commits that preceded it in +history. + +Normally a "commit" has one parent: the previous state of the tree +before a certain change was made. However, sometimes it can have two +or more parent commits, in which case we call it a "merge", due to the +fact that such a commit brings together ("merges") two or more +previous states represented by other commits. + +In other words, while a "tree" represents a particular directory state +of a working directory, a "commit" represents that state in "time", +and explains how we got there. + +You create a commit object by giving it the tree that describes the +state at the time of the commit, and a list of parents: + +------------------------------------------------- +$ git commit-tree <tree> -p <parent> [-p <parent2> ..] +------------------------------------------------- + +and then giving the reason for the commit on stdin (either through +redirection from a pipe or file, or by just typing it at the tty). + +`git commit-tree` will return the name of the object that represents +that commit, and you should save it away for later use. Normally, +you'd commit a new `HEAD` state, and while git doesn't care where you +save the note about that state, in practice we tend to just write the +result to the file pointed at by `.git/HEAD`, so that we can always see +what the last committed state was. + +Here is an ASCII art by Jon Loeliger that illustrates how +various pieces fit together. + +------------ + + commit-tree + commit obj + +----+ + | | + | | + V V + +-----------+ + | Object DB | + | Backing | + | Store | + +-----------+ + ^ + write-tree | | + tree obj | | + | | read-tree + | | tree obj + V + +-----------+ + | Index | + | "cache" | + +-----------+ + update-index ^ + blob obj | | + | | + checkout-index -u | | checkout-index + stat | | blob obj + V + +-----------+ + | Working | + | Directory | + +-----------+ + +------------ + + +[[examining-the-data]] +Examining the data +------------------ + +You can examine the data represented in the object database and the +index with various helper tools. For every object, you can use +linkgit:git-cat-file[1] to examine details about the +object: + +------------------------------------------------- +$ git cat-file -t <objectname> +------------------------------------------------- + +shows the type of the object, and once you have the type (which is +usually implicit in where you find the object), you can use + +------------------------------------------------- +$ git cat-file blob|tree|commit|tag <objectname> +------------------------------------------------- + +to show its contents. NOTE! Trees have binary content, and as a result +there is a special helper for showing that content, called +`git ls-tree`, which turns the binary content into a more easily +readable form. + +It's especially instructive to look at "commit" objects, since those +tend to be small and fairly self-explanatory. In particular, if you +follow the convention of having the top commit name in `.git/HEAD`, +you can do + +------------------------------------------------- +$ git cat-file commit HEAD +------------------------------------------------- + +to see what the top commit was. + +[[merging-multiple-trees]] +Merging multiple trees +---------------------- + +Git helps you do a three-way merge, which you can expand to n-way by +repeating the merge procedure arbitrary times until you finally +"commit" the state. The normal situation is that you'd only do one +three-way merge (two parents), and commit it, but if you like to, you +can do multiple parents in one go. + +To do a three-way merge, you need the two sets of "commit" objects +that you want to merge, use those to find the closest common parent (a +third "commit" object), and then use those commit objects to find the +state of the directory ("tree" object) at these points. + +To get the "base" for the merge, you first look up the common parent +of two commits with + +------------------------------------------------- +$ git merge-base <commit1> <commit2> +------------------------------------------------- + +which will return you the commit they are both based on. You should +now look up the "tree" objects of those commits, which you can easily +do with (for example) + +------------------------------------------------- +$ git cat-file commit <commitname> | head -1 +------------------------------------------------- + +since the tree object information is always the first line in a commit +object. + +Once you know the three trees you are going to merge (the one "original" +tree, aka the common tree, and the two "result" trees, aka the branches +you want to merge), you do a "merge" read into the index. This will +complain if it has to throw away your old index contents, so you should +make sure that you've committed those--in fact you would normally +always do a merge against your last commit (which should thus match what +you have in your current index anyway). + +To do the merge, do + +------------------------------------------------- +$ git read-tree -m -u <origtree> <yourtree> <targettree> +------------------------------------------------- + +which will do all trivial merge operations for you directly in the +index file, and you can just write the result out with +`git write-tree`. + + +[[merging-multiple-trees-2]] +Merging multiple trees, continued +--------------------------------- + +Sadly, many merges aren't trivial. If there are files that have +been added, moved or removed, or if both branches have modified the +same file, you will be left with an index tree that contains "merge +entries" in it. Such an index tree can 'NOT' be written out to a tree +object, and you will have to resolve any such merge clashes using +other tools before you can write out the result. + +You can examine such index state with `git ls-files --unmerged` +command. An example: + +------------------------------------------------ +$ git read-tree -m $orig HEAD $target +$ git ls-files --unmerged +100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c +100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c +100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c +------------------------------------------------ + +Each line of the `git ls-files --unmerged` output begins with +the blob mode bits, blob 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. + +Earlier we said that trivial merges are done inside +`git read-tree -m`. For example, if the file did not change +from `$orig` to `HEAD` nor `$target`, or if the file changed +from `$orig` to `HEAD` and `$orig` to `$target` the same way, +obviously the final outcome is what is in `HEAD`. What the +above example shows is that file `hello.c` was changed from +`$orig` to `HEAD` and `$orig` to `$target` in a different way. +You could resolve this by running your favorite 3-way merge +program, e.g. `diff3`, `merge`, or git's own merge-file, on +the blob objects from these three stages yourself, like this: + +------------------------------------------------ +$ git cat-file blob 263414f... >hello.c~1 +$ git cat-file blob 06fa6a2... >hello.c~2 +$ git cat-file blob cc44c73... >hello.c~3 +$ 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 +merge result for this file is by: + +------------------------------------------------- +$ mv -f hello.c~2 hello.c +$ 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. + +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 +for this. There is a `git merge-index` program that extracts the +stages to temporary files and calls a "merge" script on it: + +------------------------------------------------- +$ git merge-index git-merge-one-file hello.c +------------------------------------------------- + +and that is what higher level `git merge -s resolve` is implemented with. + +[[hacking-git]] +Hacking git +=========== + +This chapter covers internal details of the git implementation which +probably only git developers need to understand. + +[[object-details]] +Object storage format +--------------------- + +All objects have a statically determined "type" which identifies the +format of the object (i.e. how it is used, and how it can refer to other +objects). There are currently four different object types: "blob", +"tree", "commit", and "tag". + +Regardless of object type, all objects share the following +characteristics: they are all deflated with zlib, and have a header +that not only specifies their type, but also provides size information +about the data in the object. It's worth noting that the 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>. + +The structured objects can further have their structure and +connectivity to other objects verified. This is generally done with +the `git fsck` program, which generates a full dependency graph +of all objects, and verifies their internal consistency (in addition +to just verifying their superficial consistency through the hash). + +[[birdview-on-the-source-code]] +A birds-eye view of Git's source code +------------------------------------- + +It is not always easy for new developers to find their way through Git's +source code. This section gives you a little guidance to show where to +start. + +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 +today, but is small enough to read in one sitting. + +Note that terminology has changed since that revision. For example, the +README in that revision uses the word "changeset" to describe what we +now call a <<def_commit_object,commit>>. + +Also, we do not call it "cache" any more, but rather "index"; however, the +file is still called `cache.h`. Remark: Not much reason to change it now, +especially since there is no good single name for it anyway, because it is +basically _the_ header file which is included by _all_ of Git's C sources. + +If you grasp the ideas in that initial commit, you should check out a +more recent version and skim `cache.h`, `object.h` and `commit.h`. + +In the early days, Git (in the tradition of UNIX) was a bunch of programs +which were extremely simple, and which you used in scripts, piping the +output of one into another. This turned out to be good for initial +development, since it was easier to test new things. However, recently +many of these parts have become builtins, and some of the core has been +"libified", i.e. put into libgit.a for performance, portability reasons, +and to avoid code duplication. + +By now, you know what the index is (and find the corresponding data +structures in `cache.h`), and that there are just a couple of object types +(blobs, trees, commits and tags) which inherit their common structure from +`struct object`, which is their first member (and thus, you can cast e.g. +`(struct object *)commit` to achieve the _same_ as `&commit->object`, i.e. +get at the object name and flags). + +Now is a good point to take a break to let this information sink in. + +Next step: get familiar with the object naming. Read <<naming-commits>>. +There are quite a few ways to name an object (and not only revisions!). +All of these are handled in `sha1_name.c`. Just have a quick look at +the function `get_sha1()`. A lot of the special handling is done by +functions like `get_sha1_basic()` or the likes. + +This is just to get you into the groove for the most libified part of Git: +the revision walker. + +Basically, the initial version of `git log` was a shell script: + +---------------------------------------------------------------- +$ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \ + LESS=-S ${PAGER:-less} +---------------------------------------------------------------- + +What does this mean? + +`git rev-list` is the original version of the revision walker, which +_always_ printed a list of revisions to stdout. It is still functional, +and needs to, since most new Git commands start out as scripts using +`git rev-list`. + +`git rev-parse` is not as important any more; it was only used to filter out +options that were relevant for the different plumbing commands that were +called by the script. + +Most of what `git rev-list` did is contained in `revision.c` and +`revision.h`. It wraps the options in a struct named `rev_info`, which +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 +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 +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 +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`, + +- 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`, +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`. + +`git log` looks more complicated in C than it does in the original script, +but that allows for a much greater flexibility and performance. + +Here again it is a good point to take a pause. + +Lesson three is: study the code. Really, it is the best way to learn about +the organization of Git (after you know the basic concepts). + +So, think about something which you are interested in, say, "how can I +access a blob just knowing the object name of it?". The first step is to +find a Git command with which you can do it. In this example, it is either +`git show` or `git cat-file`. + +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` + 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 +it does. + +------------------------------------------------------------------ + git_config(git_default_config); + if (argc != 3) + usage("git cat-file [-t|-s|-e|-p|<type>] <sha1>"); + if (get_sha1(argv[2], sha1)) + die("Not a valid object name %s", argv[2]); +------------------------------------------------------------------ + +Let's skip over the obvious details; the only really interesting part +here is the call to `get_sha1()`. It tries to interpret `argv[2]` as an +object name, and if it refers to an object which is present in the current +repository, it writes the resulting SHA-1 into the variable `sha1`. + +Two things are interesting here: + +- `get_sha1()` returns 0 on _success_. This might surprise some new + Git hackers, but there is a long tradition in UNIX to return different + negative numbers in case of different errors--and 0 on success. + +- the variable `sha1` in the function signature of `get_sha1()` is `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 \*`, it + is the binary representation, as opposed to the ASCII representation in + hex characters, which is passed as `char *`. + +You will see both of these things throughout the code. + +Now, for the meat: + +----------------------------------------------------------------------------- + case 0: + buf = read_object_with_reference(sha1, argv[1], &size, NULL); +----------------------------------------------------------------------------- + +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 +the source. + +To find out how the result can be used, just read on in `cmd_cat_file()`: + +----------------------------------- + write_or_die(1, buf, size); +----------------------------------- + +Sometimes, you do not know where to look for a feature. In many such cases, +it helps to search through the output of `git log`, and then `git show` the +corresponding commit. + +Example: If you know that there was some test case for `git bundle`, but +do not remember where it was (yes, you _could_ `git grep bundle t/`, but that +does not illustrate the point!): + +------------------------ +$ git log --no-merges t/ +------------------------ + +In the pager (`less`), just search for "bundle", go a few lines back, +and see that it is in commit 18449ab0... Now just copy this object name, +and paste it into the command line + +------------------- +$ git show 18449ab0 +------------------- + +Voila. + +Another example: Find out what to do in order to make some script a +builtin: + +------------------------------------------------- +$ 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 +itself! + +[[glossary]] +Git Glossary +============ + +include::glossary-content.txt[] + +[[git-quick-start]] +Appendix A: Git Quick Reference +=============================== + +This is a quick summary of the major commands; the previous chapters +explain how these work in more detail. + +[[quick-creating-a-new-repository]] +Creating a new repository +------------------------- + +From a tarball: + +----------------------------------------------- +$ tar xzf project.tar.gz +$ cd project +$ git init +Initialized empty Git repository in .git/ +$ git add . +$ git commit +----------------------------------------------- + +From a remote repository: + +----------------------------------------------- +$ git clone git://example.com/pub/project.git +$ cd project +----------------------------------------------- + +[[managing-branches]] +Managing branches +----------------- + +----------------------------------------------- +$ git branch # list all local branches in this repo +$ git checkout test # switch working directory to branch "test" +$ git branch new # create branch "new" starting at current HEAD +$ git branch -d new # delete branch "new" +----------------------------------------------- + +Instead of basing a new branch on current HEAD (the default), use: + +----------------------------------------------- +$ git branch new test # branch named "test" +$ git branch new v2.6.15 # tag named v2.6.15 +$ git branch new HEAD^ # commit before the most recent +$ git branch new HEAD^^ # commit before that +$ git branch new test~10 # ten commits before tip of branch "test" +----------------------------------------------- + +Create and switch to a new branch at the same time: + +----------------------------------------------- +$ git checkout -b new v2.6.15 +----------------------------------------------- + +Update and examine branches from the repository you cloned from: + +----------------------------------------------- +$ git fetch # update +$ git branch -r # list + origin/master + origin/next + ... +$ git checkout -b masterwork origin/master +----------------------------------------------- + +Fetch a branch from a different repository, and give it a new +name in your repository: + +----------------------------------------------- +$ git fetch git://example.com/project.git theirbranch:mybranch +$ git fetch git://example.com/project.git v2.6.15:mybranch +----------------------------------------------- + +Keep a list of repositories you work with regularly: + +----------------------------------------------- +$ git remote add example git://example.com/project.git +$ git remote # list remote repositories +example +origin +$ git remote show example # get details +* remote example + URL: git://example.com/project.git + Tracked remote branches + master + next + ... +$ git fetch example # update branches from example +$ git branch -r # list all remote branches +----------------------------------------------- + + +[[exploring-history]] +Exploring history +----------------- + +----------------------------------------------- +$ gitk # visualize and browse history +$ git log # list all commits +$ git log src/ # ...modifying src/ +$ git log v2.6.15..v2.6.16 # ...in v2.6.16, not in v2.6.15 +$ git log master..test # ...in branch test, not in branch master +$ git log test..master # ...in branch master, but not in test +$ git log test...master # ...in one branch, not in both +$ git log -S'foo()' # ...where difference contain "foo()" +$ git log --since="2 weeks ago" +$ git log -p # show patches as well +$ git show # most recent commit +$ git diff v2.6.15..v2.6.16 # diff between two tagged versions +$ git diff v2.6.15..HEAD # diff with current head +$ git grep "foo()" # search working directory for "foo()" +$ git grep v2.6.15 "foo()" # search old tree for "foo()" +$ git show v2.6.15:a.txt # look at old version of a.txt +----------------------------------------------- + +Search for regressions: + +----------------------------------------------- +$ git bisect start +$ git bisect bad # current version is bad +$ git bisect good v2.6.13-rc2 # last known good revision +Bisecting: 675 revisions left to test after this + # test here, then: +$ git bisect good # if this revision is good, or +$ git bisect bad # if this revision is bad. + # repeat until done. +----------------------------------------------- + +[[making-changes]] +Making changes +-------------- + +Make sure git knows who to blame: + +------------------------------------------------ +$ cat >>~/.gitconfig <<\EOF +[user] + name = Your Name Comes Here + email = you@yourdomain.example.com +EOF +------------------------------------------------ + +Select file contents to include in the next commit, then make the +commit: + +----------------------------------------------- +$ git add a.txt # updated file +$ git add b.txt # new file +$ git rm c.txt # old file +$ git commit +----------------------------------------------- + +Or, prepare and create the commit in one step: + +----------------------------------------------- +$ git commit d.txt # use latest content only of d.txt +$ git commit -a # use latest content of all tracked files +----------------------------------------------- + +[[merging]] +Merging +------- + +----------------------------------------------- +$ git merge test # merge branch "test" into the current branch +$ git pull git://example.com/project.git master + # fetch and merge in remote branch +$ git pull . test # equivalent to git merge test +----------------------------------------------- + +[[sharing-your-changes]] +Sharing your changes +-------------------- + +Importing or exporting patches: + +----------------------------------------------- +$ git format-patch origin..HEAD # format a patch for each commit + # in HEAD but not in origin +$ git am mbox # import patches from the mailbox "mbox" +----------------------------------------------- + +Fetch a branch in a different git repository, then merge into the +current branch: + +----------------------------------------------- +$ git pull git://example.com/project.git theirbranch +----------------------------------------------- + +Store the fetched branch into a local branch before merging into the +current branch: + +----------------------------------------------- +$ git pull git://example.com/project.git theirbranch:mybranch +----------------------------------------------- + +After creating commits on a local branch, update the remote +branch with your commits: + +----------------------------------------------- +$ git push ssh://example.com/project.git mybranch:theirbranch +----------------------------------------------- + +When remote and local branch are both named "test": + +----------------------------------------------- +$ git push ssh://example.com/project.git test +----------------------------------------------- + +Shortcut version for a frequently used remote repository: + +----------------------------------------------- +$ git remote add example ssh://example.com/project.git +$ git push example test +----------------------------------------------- + +[[repository-maintenance]] +Repository maintenance +---------------------- + +Check for corruption: + +----------------------------------------------- +$ git fsck +----------------------------------------------- + +Recompress, remove unused cruft: + +----------------------------------------------- +$ git gc +----------------------------------------------- + + +[[todo]] +Appendix B: Notes and todo list for this manual +=============================================== + +This is a work in progress. + +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 + 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 + than necessary: for example, "importing patches into a project" rather + than "the `git am` command" + +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: + +- howto's +- some of technical/? +- hooks +- list of commands in linkgit:git[1] + +Scan email archives for other stuff left out + +Scan man pages to see if any assume more background than this manual +provides. + +Simplify beginning by suggesting disconnected head instead of +temporary branch creation? + +Add more good examples. Entire sections of just cookbook examples +might be a good idea; maybe make an "advanced examples" section a +standard end-of-chapter section? + +Include cross-references to the glossary, where appropriate. + +Document shallow clones? See draft 1.5.0 release notes for some +documentation. + +Add a section on working with other version control systems, including +CVS, Subversion, and just imports of series of release tarballs. + +More details on gitweb? + +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 |