diff options
Diffstat (limited to 'Documentation')
175 files changed, 8243 insertions, 1721 deletions
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index f628c1f3b7..b8bf618a30 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -21,8 +21,13 @@ code. For git in general, three rough rules are: As for more concrete guidelines, just imitate the existing code (this is a good guideline, no matter which project you are -contributing to). But if you must have a list of rules, -here they are. +contributing to). It is always preferable to match the _local_ +convention. New code added to git suite is expected to match +the overall style of existing code. Modifications to existing +code is expected to match the style the surrounding code already +uses (even if it doesn't match the overall style of existing code). + +But if you must have a list of rules, here they are. For shell scripts specifically (not exhaustive): @@ -124,3 +129,6 @@ For C programs: used in the git core command set (unless your command is clearly separate from it, such as an importer to convert random-scm-X repositories to git). + + - When we pass <string, length> pair to functions, we should try to + pass them in that order. diff --git a/Documentation/Makefile b/Documentation/Makefile index 62269e39c4..1c9dfcea5a 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -6,7 +6,7 @@ MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \ gitrepository-layout.txt MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \ gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \ - gitdiffcore.txt + gitdiffcore.txt gitworkflows.txt MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT)) @@ -32,6 +32,7 @@ DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT)) prefix?=$(HOME) bindir?=$(prefix)/bin htmldir?=$(prefix)/share/doc/git-doc +pdfdir?=$(prefix)/share/doc/git-doc mandir?=$(prefix)/share/man man1dir=$(mandir)/man1 man5dir=$(mandir)/man5 @@ -40,15 +41,18 @@ man7dir=$(mandir)/man7 ASCIIDOC=asciidoc ASCIIDOC_EXTRA = -MANPAGE_XSL = callouts.xsl +MANPAGE_XSL = manpage-normal.xsl +XMLTO_EXTRA = INSTALL?=install RM ?= rm -f DOC_REF = origin/man +HTML_REF = origin/html infodir?=$(prefix)/share/info MAKEINFO=makeinfo INSTALL_INFO=install-info DOCBOOK2X_TEXI=docbook2x-texi +DBLATEX=dblatex ifndef PERL_PATH PERL_PATH = /usr/bin/perl endif @@ -56,14 +60,75 @@ endif -include ../config.mak.autogen -include ../config.mak +# +# For asciidoc ... +# -7.1.2, no extra settings are needed. +# 8.0-, set ASCIIDOC8. +# + +# +# For docbook-xsl ... +# -1.68.1, set ASCIIDOC_NO_ROFF? (based on changelog from 1.73.0) +# 1.69.0, no extra settings are needed? +# 1.69.1-1.71.0, set DOCBOOK_SUPPRESS_SP? +# 1.71.1, no extra settings are needed? +# 1.72.0, set DOCBOOK_XSL_172. +# 1.73.0-, set ASCIIDOC_NO_ROFF +# + +# +# If you had been using DOCBOOK_XSL_172 in an attempt to get rid +# of 'the ".ft C" problem' in your generated manpages, and you +# instead ended up with weird characters around callouts, try +# using ASCIIDOC_NO_ROFF instead (it works fine with ASCIIDOC8). +# + ifdef ASCIIDOC8 -ASCIIDOC_EXTRA += -a asciidoc7compatible +ASCIIDOC_EXTRA += -a asciidoc7compatible -a no-inline-literal endif ifdef DOCBOOK_XSL_172 -ASCIIDOC_EXTRA += -a docbook-xsl-172 +ASCIIDOC_EXTRA += -a git-asciidoc-no-roff MANPAGE_XSL = manpage-1.72.xsl +else + ifdef ASCIIDOC_NO_ROFF + # docbook-xsl after 1.72 needs the regular XSL, but will not + # pass-thru raw roff codes from asciidoc.conf, so turn them off. + ASCIIDOC_EXTRA += -a git-asciidoc-no-roff + endif +endif +ifdef MAN_BOLD_LITERAL +XMLTO_EXTRA += -m manpage-bold-literal.xsl +endif +ifdef DOCBOOK_SUPPRESS_SP +XMLTO_EXTRA += -m manpage-suppress-sp.xsl +endif + +# Newer DocBook stylesheet emits warning cruft in the output when +# this is not set, and if set it shows an absolute link. We can +# use MAN_BASE_URL=http://www.kernel.org/pub/software/scm/git/docs/ +# but distros may want to set it to /usr/share/doc/git-core/docs/ or +# something like that. +# +# As older stylesheets simply ignore this parameter, it ought to be +# safe to set it to empty string when the base URL is not specified, +# but unfortunately we cannot do so unconditionally because at least +# xmlto 0.0.18 is reported to lack --stringparam option. +ifdef MAN_BASE_URL +XMLTO_EXTRA += --stringparam man.base.url.for.relative.links=$(MAN_BASE_URL) +endif + +# 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: @@ -73,6 +138,32 @@ endif # yourself - yes, all 6 characters of it! # +QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir +QUIET_SUBDIR1 = + +ifneq ($(findstring $(MAKEFLAGS),w),w) +PRINT_DIR = --no-print-directory +else # "make -w" +NO_SUBDIR = : +endif + +ifneq ($(findstring $(MAKEFLAGS),s),s) +ifndef V + QUIET_ASCIIDOC = @echo ' ' ASCIIDOC $@; + QUIET_XMLTO = @echo ' ' XMLTO $@; + QUIET_DB2TEXI = @echo ' ' DB2TEXI $@; + QUIET_MAKEINFO = @echo ' ' MAKEINFO $@; + QUIET_DBLATEX = @echo ' ' DBLATEX $@; + QUIET_XSLTPROC = @echo ' ' XSLTPROC $@; + QUIET_GEN = @echo ' ' GEN $@; + QUIET_STDERR = 2> /dev/null + QUIET_SUBDIR0 = +@subdir= + QUIET_SUBDIR1 = ;$(NO_SUBDIR) echo ' ' SUBDIR $$subdir; \ + $(MAKE) $(PRINT_DIR) -C $$subdir + export V +endif +endif + all: html man html: $(DOC_HTML) @@ -86,7 +177,11 @@ man7: $(DOC_MAN7) info: git.info gitman.info -install: man +pdf: user-manual.pdf + +install: install-man + +install-man: man $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir) $(INSTALL) -d -m 755 $(DESTDIR)$(man5dir) $(INSTALL) -d -m 755 $(DESTDIR)$(man7dir) @@ -104,11 +199,15 @@ install-info: info 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 - sh ./install-webdoc.sh $(DESTDIR)$(htmldir) + '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir) ../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE - $(MAKE) -C ../ GIT-VERSION-FILE + $(QUIET_SUBDIR0)../ $(QUIET_SUBDIR1) GIT-VERSION-FILE -include ../GIT-VERSION-FILE @@ -116,8 +215,8 @@ install-html: html # Determine "include::" file references in asciidoc files. # doc.dep : $(wildcard *.txt) build-docdep.perl - $(RM) $@+ $@ - $(PERL_PATH) ./build-docdep.perl >$@+ + $(QUIET_GEN)$(RM) $@+ $@ && \ + $(PERL_PATH) ./build-docdep.perl >$@+ $(QUIET_STDERR) && \ mv $@+ $@ -include doc.dep @@ -135,91 +234,105 @@ cmds_txt = cmds-ancillaryinterrogators.txt \ $(cmds_txt): cmd-list.made cmd-list.made: cmd-list.perl ../command-list.txt $(MAN1_TXT) - $(RM) $@ - $(PERL_PATH) ./cmd-list.perl ../command-list.txt + $(QUIET_GEN)$(RM) $@ && \ + $(PERL_PATH) ./cmd-list.perl ../command-list.txt $(QUIET_STDERR) && \ date >$@ clean: $(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 - $(RM) *.texi *.texi+ git.info gitman.info + $(RM) *.texi *.texi+ *.texi++ git.info gitman.info $(RM) howto-index.txt howto/*.html doc.dep $(RM) technical/api-*.html technical/api-index.txt $(RM) $(cmds_txt) *.made $(MAN_HTML): %.html : %.txt - $(RM) $@+ $@ + $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< + $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ mv $@+ $@ %.1 %.5 %.7 : %.xml - $(RM) $@ - xmlto -m $(MANPAGE_XSL) man $< + $(QUIET_XMLTO)$(RM) $@ && \ + xmlto -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $< %.xml : %.txt - $(RM) $@+ $@ + $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ $(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \ - $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< + $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \ mv $@+ $@ user-manual.xml: user-manual.txt user-manual.conf - $(ASCIIDOC) -b docbook -d book $< + $(QUIET_ASCIIDOC)$(ASCIIDOC) $(ASCIIDOC_EXTRA) -b docbook -d book $< technical/api-index.txt: technical/api-index-skel.txt \ technical/api-index.sh $(patsubst %,%.txt,$(API_DOCS)) - cd technical && sh ./api-index.sh + $(QUIET_GEN)cd technical && '$(SHELL_PATH_SQ)' ./api-index.sh $(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt - $(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ + $(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt XSLT = docbook.xsl XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css user-manual.html: user-manual.xml - xsltproc $(XSLTOPTS) -o $@ $(XSLT) $< + $(QUIET_XSLTPROC)xsltproc $(XSLTOPTS) -o $@ $(XSLT) $< git.info: user-manual.texi - $(MAKEINFO) --no-split -o $@ user-manual.texi + $(QUIET_MAKEINFO)$(MAKEINFO) --no-split -o $@ user-manual.texi user-manual.texi: user-manual.xml - $(RM) $@+ $@ - $(DOCBOOK2X_TEXI) user-manual.xml --to-stdout | $(PERL_PATH) fix-texi.perl >$@+ + $(QUIET_DB2TEXI)$(RM) $@+ $@ && \ + $(DOCBOOK2X_TEXI) user-manual.xml --encoding=UTF-8 --to-stdout >$@++ && \ + $(PERL_PATH) fix-texi.perl <$@++ >$@+ && \ + rm $@++ && \ + mv $@+ $@ + +user-manual.pdf: user-manual.xml + $(QUIET_DBLATEX)$(RM) $@+ $@ && \ + $(DBLATEX) -o $@+ -p /etc/asciidoc/dblatex/asciidoc-dblatex.xsl -s /etc/asciidoc/dblatex/asciidoc-dblatex.sty $< && \ mv $@+ $@ gitman.texi: $(MAN_XML) cat-texi.perl - $(RM) $@+ $@ - ($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --to-stdout $(xml);)) | \ - $(PERL_PATH) cat-texi.perl $@ >$@+ + $(QUIET_DB2TEXI)$(RM) $@+ $@ && \ + ($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --encoding=UTF-8 \ + --to-stdout $(xml) &&) true) > $@++ && \ + $(PERL_PATH) cat-texi.perl $@ <$@++ >$@+ && \ + rm $@++ && \ mv $@+ $@ gitman.info: gitman.texi - $(MAKEINFO) --no-split $*.texi + $(QUIET_MAKEINFO)$(MAKEINFO) --no-split --no-validate $*.texi $(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml - $(RM) $@+ $@ - $(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@+ + $(QUIET_DB2TEXI)$(RM) $@+ $@ && \ + $(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@+ && \ mv $@+ $@ howto-index.txt: howto-index.sh $(wildcard howto/*.txt) - $(RM) $@+ $@ - sh ./howto-index.sh $(wildcard howto/*.txt) >$@+ + $(QUIET_GEN)$(RM) $@+ $@ && \ + '$(SHELL_PATH_SQ)' ./howto-index.sh $(wildcard howto/*.txt) >$@+ && \ mv $@+ $@ $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt - $(ASCIIDOC) -b xhtml11 $*.txt + $(QUIET_ASCIIDOC)$(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 $*.txt WEBDOC_DEST = /pub/software/scm/git/docs $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt - $(RM) $@+ $@ - sed -e '1,/^$$/d' $< | $(ASCIIDOC) -b xhtml11 - >$@+ + $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ + sed -e '1,/^$$/d' $< | $(ASCIIDOC) $(ASCIIDOC_EXTRA) -b xhtml11 - >$@+ && \ mv $@+ $@ install-webdoc : html - sh ./install-webdoc.sh $(WEBDOC_DEST) + '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(WEBDOC_DEST) + +quick-install: quick-install-man + +quick-install-man: + '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir) -quick-install: - sh ./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.2.2.txt b/Documentation/RelNotes-1.5.2.2.txt index f6393f8a94..7bfa341750 100644 --- a/Documentation/RelNotes-1.5.2.2.txt +++ b/Documentation/RelNotes-1.5.2.2.txt @@ -45,7 +45,7 @@ Fixes since v1.5.2.1 correctly when the branch name had slash in it. - The email address of the user specified with user.email - configuration was overriden by EMAIL environment variable. + configuration was overridden by EMAIL environment variable. - The tree parser did not warn about tree entries with nonsense file modes, and assumed they must be blobs. diff --git a/Documentation/RelNotes-1.6.0.2.txt b/Documentation/RelNotes-1.6.0.2.txt index 7a9646fc4f..51b32f5d94 100644 --- a/Documentation/RelNotes-1.6.0.2.txt +++ b/Documentation/RelNotes-1.6.0.2.txt @@ -7,7 +7,7 @@ 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 nto +* 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 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.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/SubmittingPatches b/Documentation/SubmittingPatches index 34fdc83ad4..76fc84d878 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -6,9 +6,13 @@ Checklist (and a short version for the impatient): - check for unnecessary whitespace with "git diff --check" before committing - do not check in commented out code or unneeded files - - provide a meaningful commit message - the first line of the commit message should be a short description and should skip the full stop + - the body should provide a meaningful commit message, which: + - uses the imperative, present tense: "change", + not "changed" or "changes". + - includes motivation for the change, and contrasts + its implementation with previous behaviour - if you want your work included in git.git, add a "Signed-off-by: Your Name <you@example.com>" line to the commit message (or just use the option "-s" when @@ -62,6 +66,14 @@ Describe the technical detail of the change(s). If your description starts to get too long, that's a sign that you probably need to split up your commit to finer grained pieces. +That being said, patches which plainly describe the things that +help reviewers check the patch, and future maintainers understand +the code, are the most beautiful patches. Descriptions that summarise +the point in the subject well, and describe the motivation for the +change, the approach taken by the change, and if relevant how this +differs substantially from the prior version, can be found on Usenet +archives back into the late 80's. Consider it like good Netiquette, +but for code. Oh, another thing. I am picky about whitespaces. Make sure your changes do not trigger errors with the sample pre-commit hook shipped @@ -71,7 +83,7 @@ run git diff --check on your changes before you commit. (1a) Try to be nice to older C compilers -We try to support wide range of C compilers to compile +We try to support a wide range of C compilers to compile git with. That means that you should not use C99 initializers, even if a lot of compilers grok it. @@ -376,9 +388,36 @@ Thunderbird (A Large Angry SCM) +By default, Thunderbird will both wrap emails as well as flag them as +being 'format=flowed', both of which will make the resulting email unusable +by git. + Here are some hints on how to successfully submit patches inline using Thunderbird. +There are two different approaches. One approach is to configure +Thunderbird to not mangle patches. The second approach is to use +an external editor to keep Thunderbird from mangling the patches. + +Approach #1 (configuration): + +This recipe is current as of Thunderbird 2.0.0.19. Three steps: + 1. Configure your mail server composition as plain text + Edit...Account Settings...Composition & Addressing, + uncheck 'Compose Messages in HTML'. + 2. Configure your general composition window to not wrap + Edit..Preferences..Composition, wrap plain text messages at 0 + 3. Disable the use of format=flowed + Edit..Preferences..Advanced..Config Editor. Search for: + mailnews.send_plaintext_flowed + toggle it to make sure it is set to 'false'. + +After that is done, you should be able to compose email as you +otherwise would (cut + paste, git-format-patch | git-imap-send, etc), +and the patches should not be mangled. + +Approach #2 (external editor): + This recipe appears to work with the current [*1*] Thunderbird from Suse. The following Thunderbird extensions are needed: @@ -464,6 +503,12 @@ 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: @@ -476,6 +521,9 @@ account settings: 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. @@ -486,3 +534,4 @@ command to send the patch emails to your Gmail Drafts folder. 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 index 2da867d2f8..87a90f2c3f 100644 --- a/Documentation/asciidoc.conf +++ b/Documentation/asciidoc.conf @@ -7,6 +7,9 @@ # Show GIT link as: <command>(<section>); if section is defined, else just show # the command. +[macros] +(?su)[\\]?(?P<name>linkgit):(?P<target>\S*?)\[(?P<attrlist>.*?)\]= + [attributes] asterisk=* plus=+ @@ -14,6 +17,7 @@ caret=^ startsb=[ endsb=] tilde=~ +backtick=` ifdef::backend-docbook[] [linkgit-inlinemacro] @@ -24,7 +28,7 @@ ifdef::backend-docbook[] endif::backend-docbook[] ifdef::backend-docbook[] -ifndef::docbook-xsl-172[] +ifndef::git-asciidoc-no-roff[] # "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this. # v1.72 breaks with this because it replaces dots not in roff requests. [listingblock] @@ -39,16 +43,16 @@ ifdef::doctype-manpage[] endif::doctype-manpage[] </literallayout> {title#}</example> -endif::docbook-xsl-172[] +endif::git-asciidoc-no-roff[] -ifdef::docbook-xsl-172[] +ifdef::git-asciidoc-no-roff[] ifdef::doctype-manpage[] # The following two small workarounds insert a simple paragraph after screen [listingblock] <example><title>{title}</title> -<screen> +<literallayout> | -</screen><simpara></simpara> +</literallayout><simpara></simpara> {title#}</example> [verseblock] @@ -56,10 +60,11 @@ ifdef::doctype-manpage[] {title%}<literallayout{id? id="{id}"}> {title#}<literallayout> | -</literallayout><simpara></simpara> +</literallayout> {title#}</para></formalpara> +{title%}<simpara></simpara> endif::doctype-manpage[] -endif::docbook-xsl-172[] +endif::git-asciidoc-no-roff[] endif::backend-docbook[] ifdef::doctype-manpage[] diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt index 5428111d73..1625ffce6a 100644 --- a/Documentation/blame-options.txt +++ b/Documentation/blame-options.txt @@ -39,7 +39,14 @@ of lines before or after the line given by <start>. Show raw timestamp (Default: off). -S <revs-file>:: - Use revs from revs-file instead of calling linkgit:git-rev-list[1]. + Use revisions from revs-file instead of calling linkgit:git-rev-list[1]. + +--reverse:: + Walk history forward instead of backward. Instead of showing + the revision in which a line appeared, this shows the last + revision in which a line has existed. This requires a range of + revision like START..END where the path to blame exists in + START. -p:: --porcelain:: @@ -49,6 +56,13 @@ of lines before or after the line given by <start>. Show the result incrementally in a format designed for machine consumption. +--encoding=<encoding>:: + Specifies the encoding used to output author names + and commit summaries. Setting it to `none` makes blame + output unconverted data. For more information see the + discussion about encoding in the linkgit:git-log[1] + manual page. + --contents <file>:: When <rev> is not specified, the command annotates the changes starting backwards from the working tree copy. @@ -56,11 +70,19 @@ of lines before or after the line given by <start>. tree copy has the contents of the named file (specify `-` to make the command read from the standard input). +--date <format>:: + The value is one of the following alternatives: + {relative,local,default,iso,rfc,short}. If --date is not + provided, the value of the blame.date config variable is + used. If the blame.date config variable is also not set, the + iso format is used. For more information, See the discussion + of the --date option at linkgit:git-log[1]. + -M|<num>|:: Detect moving lines in the file as well. When a commit moves a block of lines in a file (e.g. the original file has A and then B, and the commit changes it to B and - then A), traditional 'blame' algorithm typically blames + then A), the traditional 'blame' algorithm typically blames the lines that were moved up (i.e. B) to the parent and assigns blame to the lines that were moved down (i.e. A) to the child commit. With this option, both groups of lines @@ -76,8 +98,8 @@ commit. files that were modified in the same commit. This is useful when you reorganize your program and move code around across files. When this option is given twice, - the command looks for copies from all other files in the - parent for the commit that creates the file in addition. + the command additionally looks for copies from all other + files in the parent for the commit that creates the file. + <num> is optional but it is the lower bound on the number of alphanumeric characters that git must detect as moving diff --git a/Documentation/callouts.xsl b/Documentation/callouts.xsl deleted file mode 100644 index 6a361a2136..0000000000 --- a/Documentation/callouts.xsl +++ /dev/null @@ -1,30 +0,0 @@ -<!-- callout.xsl: converts asciidoc callouts to man page format --> -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> -<xsl:template match="co"> - <xsl:value-of select="concat('\fB(',substring-after(@id,'-'),')\fR')"/> -</xsl:template> -<xsl:template match="calloutlist"> - <xsl:text>.sp </xsl:text> - <xsl:apply-templates/> - <xsl:text> </xsl:text> -</xsl:template> -<xsl:template match="callout"> - <xsl:value-of select="concat('\fB',substring-after(@arearefs,'-'),'. \fR')"/> - <xsl:apply-templates/> - <xsl:text>.br </xsl:text> -</xsl:template> - -<!-- sorry, this is not about callouts, but attempts to work around - spurious .sp at the tail of the line docbook stylesheets seem to add --> -<xsl:template match="simpara"> - <xsl:variable name="content"> - <xsl:apply-templates/> - </xsl:variable> - <xsl:value-of select="normalize-space($content)"/> - <xsl:if test="not(ancestor::authorblurb) and - not(ancestor::personblurb)"> - <xsl:text> </xsl:text> - </xsl:if> -</xsl:template> - -</xsl:stylesheet> diff --git a/Documentation/cat-texi.perl b/Documentation/cat-texi.perl index dbc133cd3c..828ec62554 100755 --- a/Documentation/cat-texi.perl +++ b/Documentation/cat-texi.perl @@ -18,8 +18,12 @@ close TMP; printf '\input texinfo @setfilename gitman.info -@documentencoding us-ascii -@node Top,,%s +@documentencoding UTF-8 +@dircategory Development +@direntry +* Git Man Pages: (gitman). Manual pages for Git revision control system +@end direntry +@node Top,,, (dir) @top Git Manual Pages @documentlanguage en @menu diff --git a/Documentation/config.txt b/Documentation/config.txt index 113d9d1438..35e26972e9 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2,15 +2,15 @@ CONFIGURATION FILE ------------------ The git configuration file contains a number of variables that affect -the git command's behavior. `.git/config` file for each repository -is used to store the information for that repository, and -`$HOME/.gitconfig` is used to store per user information to give -fallback values for `.git/config` file. The file `/etc/gitconfig` -can be used to store system-wide defaults. - -They can be used by both the git plumbing -and the porcelains. The variables are divided into sections, where -in the fully qualified variable name the variable itself is the last +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. @@ -25,35 +25,36 @@ 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 section -header before first setting of a variable. +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 example below: +in the section header, like in the example below: -------- [section "subsection"] -------- -Subsection names can contain any characters except newline (doublequote -'`"`' and backslash have to be escaped as '`\"`' and '`\\`', -respectively) and are case sensitive. Section header cannot span multiple +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 (case insensitive) alternative `[section.subsection]` syntax. -In this syntax subsection names follow the same restrictions as for section -name. +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 are recognized as setting variables, in the form +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 +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. @@ -61,26 +62,26 @@ 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 or true/false. Case is not significant in boolean values, when +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 value in double quotes if you want to -preserve leading or trailing whitespace, or if variable value contains -beginning of comment characters (if it contains '#' or ';'). -Double quote '`"`' and backslash '`\`' characters in variable value 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 +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 value ending in a '`\`' is continued on the next line in the +Variable values ending in a `\` are continued on the next line in the customary UNIX fashion. -Some variables may require special value format. +Some variables may require a special value format. Example ~~~~~~~ @@ -112,11 +113,41 @@ 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]. True by default. +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.trustctime:: If false, the ctime differences between the index and the working copy are ignored; useful when the inode change time @@ -142,9 +173,10 @@ core.autocrlf:: 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. + `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 @@ -210,6 +242,11 @@ core.gitProxy:: 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 @@ -279,8 +316,10 @@ core.sharedRepository:: 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, and thus, users with a safe umask (0077) can use - this option. Examples: '0660' is equivalent to 'group'. '0640' is a + 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. @@ -346,8 +385,9 @@ 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. See - linkgit:gitignore[5]. + 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 @@ -371,9 +411,9 @@ core.pager:: 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 + 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`". + `LESS=FRSX less -+FRSX -FRX`. core.whitespace:: A comma separated list of common whitespace problems to @@ -382,13 +422,17 @@ core.whitespace:: consider them as errors. You can prefix `-` to disable any of them (e.g. `-trailing-space`): + -* `trailing-space` treats trailing whitespaces at the end of the line +* `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 @@ -402,6 +446,29 @@ 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. + +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 @@ -415,7 +482,17 @@ 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". +"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 @@ -448,10 +525,14 @@ branch.autosetuprebase:: This option defaults to never. branch.<name>.remote:: - When in branch <name>, it tells 'git-fetch' which remote to fetch. - If this option is not given, 'git-fetch' defaults to remote "origin". + 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 @@ -468,7 +549,7 @@ branch.<name>.merge:: branch.<name>.mergeoptions:: Sets default options for merging into branch <name>. The syntax and - supported options are equal to that of linkgit:git-merge[1], but + supported options are the same as those of linkgit:git-merge[1], but option values containing whitespace characters are currently not supported. @@ -528,6 +609,25 @@ color.diff.<slot>:: 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"). @@ -536,15 +636,21 @@ color.interactive:: color.interactive.<slot>:: Use customized color for 'git-add --interactive' - output. `<slot>` may be `prompt`, `header`, or `help`, for - three distinct types of normal output from interactive - programs. The values of these variables may be specified as + 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`, @@ -570,6 +676,8 @@ color.ui:: 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 @@ -590,6 +698,22 @@ diff.external:: 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'. @@ -599,6 +723,37 @@ diff.renames:: 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 @@ -610,16 +765,32 @@ fetch.unpackLimit:: especially on slow filesystems. If not set, the value of `transfer.unpackLimit` is used instead. -format.numbered:: - A boolean which can enable sequence numbers in patch subjects. - Setting this option to "auto" will enable it only if there is - more than one patch. See --numbered option in +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 @@ -630,6 +801,23 @@ format.pretty:: 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 @@ -661,7 +849,9 @@ gc.packrefs:: gc.pruneexpire:: When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'. - Override the grace period with this config variable. + 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 @@ -682,6 +872,10 @@ gc.rerereunresolved:: 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]. @@ -752,6 +946,14 @@ 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 @@ -774,6 +976,73 @@ gui.spellingdictionary:: 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]. @@ -783,6 +1052,15 @@ help.format:: 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 @@ -803,6 +1081,12 @@ http.sslKey:: 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 @@ -863,6 +1147,13 @@ 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 @@ -875,6 +1166,14 @@ log.showroot:: Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which normally hide the root commit will now show it. True by default. +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]. @@ -919,6 +1218,16 @@ mergetool.keepBackup:: 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. @@ -944,12 +1253,20 @@ pack.compression:: pack.deltaCacheSize:: The maximum memory in bytes used for caching deltas in - linkgit:git-pack-objects[1]. - A value of 0 means no limit. Defaults to 0. + 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]. Defaults to 1000. + 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 @@ -989,7 +1306,7 @@ pager.<cmd>:: 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`". + all commands, set `core.pager` or `GIT_PAGER` to `cat`. pull.octopus:: The default merge strategy to use when pulling multiple branches @@ -998,6 +1315,28 @@ pull.octopus:: 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 @@ -1014,16 +1353,36 @@ receive.unpackLimit:: 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 @@ -1081,6 +1440,50 @@ rerere.enabled:: 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]. @@ -1133,6 +1536,19 @@ url.<base>.insteadOf:: 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 diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt index 1eeb1c7683..b71712473e 100644 --- a/Documentation/diff-format.txt +++ b/Documentation/diff-format.txt @@ -1,4 +1,7 @@ -The output format from "git-diff-index", "git-diff-tree", +Raw output format +----------------- + +The raw output format from "git-diff-index", "git-diff-tree", "git-diff-files" and "git diff --raw" are very similar. These commands all compare two sets of things; what is @@ -16,6 +19,9 @@ git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]:: git-diff-files [<pattern>...]:: compares the index and the files on the filesystem. +The "git-diff-tree" command begins its 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: diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 45885bbbb2..9276faeb11 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -19,16 +19,12 @@ endif::git-format-patch[] ifndef::git-format-patch[] -p:: +-u:: Generate patch (see section on generating patches). {git-diff? This is the default.} endif::git-format-patch[] --u:: - Synonym for "-p". - -U<n>:: - Shorthand for "--unified=<n>". - --unified=<n>:: Generate diffs with <n> lines of context instead of the usual three. Implies "-p". @@ -40,6 +36,9 @@ endif::git-format-patch[] --patch-with-raw:: Synonym for "-p --raw". +--patience:: + Generate a diff using the "patience diff" algorithm. + --stat[=width[,name-width]]:: Generate a diffstat. You can override the default output width for 80-column terminal by "--stat=width". @@ -65,6 +64,9 @@ endif::git-format-patch[] 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. @@ -92,8 +94,22 @@ endif::git-format-patch[] Turn off colored diff, even when the configuration file gives the default to color output. ---color-words:: - Show colored word diff, i.e. color words which have changed. +--color-words[=<regex>]:: + Show colored word diff, i.e., color words which have changed. + By default, words are separated by whitespace. ++ +When a <regex> is specified, every non-overlapping match of the +<regex> is considered a word. Anything between these matches is +considered whitespace and ignored(!) for the purposes of finding +differences. You may want to append `|[^[:space:]]` to your regular +expression to make sure that it matches all non-whitespace characters. +A match that contains a newline is silently truncated(!) at the +newline. ++ +The regex can also be set via a diff driver or configuration option, see +linkgit:gitattributes[1] or linkgit:git-config[1]. Giving it explicitly +overrides any diff driver or configuration setting. Diff drivers +override configuration settings. --no-renames:: Turn off rename detection, even when the configuration @@ -106,9 +122,9 @@ endif::git-format-patch[] --exit-code. --full-index:: - Instead of the first handful characters, show full - object name of pre- and post-image blob on the "index" - line when generating a patch format output. + Instead of the first handful of characters, show the full + pre- and post-image blob object names on the "index" + line when generating patch format output. --binary:: In addition to --full-index, output "binary diff" that @@ -117,7 +133,7 @@ endif::git-format-patch[] --abbrev[=<n>]:: Instead of showing the full 40-byte hexadecimal object name in diff-raw format output and diff-tree header - lines, show only handful hexdigits prefix. This is + lines, show only a partial prefix. This is independent of --full-index option above, which controls the diff-patch output format. Non default number of digits can be specified with --abbrev=<n>. @@ -160,7 +176,10 @@ endif::git-format-patch[] number. -S<string>:: - Look for differences that contain the change in <string>. + Look for differences that introduce or remove an instance of + <string>. Note that this is different than the string simply + appearing in diff output; see the 'pickaxe' entry in + linkgit:gitdiffcore[7] for more details. --pickaxe-all:: When -S finds a change, show all the changes in that @@ -187,30 +206,28 @@ endif::git-format-patch[] can name which subdirectory to make the output relative to by giving a <path> as an argument. +-a:: --text:: Treat all files as text. --a:: - Shorthand for "--text". - --ignore-space-at-eol:: Ignore changes in whitespace at EOL. +-b:: --ignore-space-change:: Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent. --b:: - Shorthand for "--ignore-space-change". - +-w:: --ignore-all-space:: Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none. --w:: - Shorthand for "--ignore-all-space". +--inter-hunk-context=<lines>:: + Show the context between diff hunks, up to the specified number + of lines, thereby fusing hunks that are close to each other. --exit-code:: Make the program exit with codes similar to diff(1). diff --git a/Documentation/docbook-xsl.css b/Documentation/docbook-xsl.css index b878b385c6..e11c8f053a 100644 --- a/Documentation/docbook-xsl.css +++ b/Documentation/docbook-xsl.css @@ -16,6 +16,7 @@ body blockquote { html body { margin: 1em 5% 1em 5%; line-height: 1.2; + font-family: sans-serif; } body div { @@ -128,6 +129,15 @@ body pre { tt.literal, code.literal { color: navy; + font-family: sans-serif; +} + +code.literal:before { content: "'"; } +code.literal:after { content: "'"; } + +em { + font-style: italic; + color: #064; } div.literallayout p { @@ -137,7 +147,6 @@ div.literallayout p { div.literallayout { font-family: monospace; -# margin: 0.5em 10% 0.5em 1em; margin: 0em; color: navy; border: 1px solid silver; @@ -187,7 +196,8 @@ dt { } dt span.term { - font-style: italic; + font-style: normal; + color: navy; } div.variablelist dd p { diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index d313795fdb..28868747da 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -1,23 +1,13 @@ --q:: ---quiet:: - Pass --quiet to git-fetch-pack and silence any other internally - used programs. - --v:: ---verbose:: - Be verbose. - -a:: --append:: Append ref names and object names of fetched refs to the existing contents of `.git/FETCH_HEAD`. Without this option old data in `.git/FETCH_HEAD` will be overwritten. ---upload-pack <upload-pack>:: - When given, and the repository to fetch from is handled - by 'git-fetch-pack', '--exec=<upload-pack>' is passed to - the command to specify non-default path for the command - run on the other end. +--depth=<depth>:: + Deepen the history of a 'shallow' repository created by + `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1]) + by the specified number of commits. -f:: --force:: @@ -27,6 +17,10 @@ fetches is a descendant of `<lbranch>`. This option overrides that check. +-k:: +--keep:: + Keep downloaded pack. + ifdef::git-pull[] --no-tags:: endif::git-pull[] @@ -47,10 +41,6 @@ endif::git-pull[] flag lets all tags and their associated objects be downloaded. --k:: ---keep:: - Keep downloaded pack. - -u:: --update-head-ok:: By default 'git-fetch' refuses to update the head which @@ -60,7 +50,19 @@ endif::git-pull[] implementing your own Porcelain you are not supposed to use it. ---depth=<depth>:: - Deepen the history of a 'shallow' repository created by - `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1]) - by the specified number of commits. +--upload-pack <upload-pack>:: + When given, and the repository to fetch from is handled + by 'git-fetch-pack', '--exec=<upload-pack>' is passed to + the command to specify non-default path for the command + run on the other end. + +ifndef::git-pull[] +-q:: +--quiet:: + Pass --quiet to git-fetch-pack and silence any other internally + used git commands. + +-v:: +--verbose:: + Be verbose. +endif::git-pull[] diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 2b6d6c8654..e93e606f45 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -9,8 +9,8 @@ SYNOPSIS -------- [verse] 'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p] - [--all | [--update | -u]] [--refresh] [--ignore-errors] [--] - <filepattern>... + [--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N] + [--refresh] [--ignore-errors] [--] [<filepattern>...] DESCRIPTION ----------- @@ -72,9 +72,23 @@ OPTIONS -p:: --patch:: - Similar to Interactive mode but the initial command loop is - bypassed and the 'patch' subcommand is invoked using each of - the specified filepatterns before exiting. + Interactively choose hunks of patch between the index and the + work tree and add them to the index. This gives the user a chance + to review the difference before adding modified contents to the + index. ++ +This effectively runs `add --interactive`, but bypasses the +initial command menu and directly jumps to the `patch` subcommand. +See ``Interactive mode'' for details. + +-e, \--edit:: + Open the diff vs. the index in an editor and let the user + edit it. After the editor was closed, adjust the hunk headers + and apply the patch to the index. ++ +*NOTE*: Obviously, if you change anything else than the first character +on lines beginning with a space or a minus, the patch will no longer +apply. -u:: --update:: @@ -92,6 +106,15 @@ OPTIONS 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. @@ -127,7 +150,7 @@ $ git add Documentation/\\*.txt ------------ + Note that the asterisk `\*` is quoted from the shell in this -example; this lets the command to include the files from +example; this lets the command include the files from subdirectories of `Documentation/` directory. * Considers adding content from all git-*.sh scripts: @@ -136,7 +159,7 @@ subdirectories of `Documentation/` directory. $ git add git-*.sh ------------ + -Because this example lets shell expand the asterisk (i.e. you are +Because this example lets the shell expand the asterisk (i.e. you are listing the files explicitly), it does not consider `subdir/git-foo.sh`. @@ -189,8 +212,8 @@ one deletion). update:: - This shows the status information and gives prompt - "Update>>". When the prompt ends with double '>>', you can + This shows the status information and issues an "Update>>" + prompt. When the prompt ends with double '>>', you can make more than one selection, concatenated with whitespace or comma. Also you can say ranges. E.g. "2-5 7,9" to choose 2,3,4,5,7,9 from the list. If the second number in a range is @@ -229,15 +252,18 @@ add untracked:: patch:: - This lets you choose one path out of 'status' like selection. - After choosing the path, it presents diff between the index + This lets you choose one path out of a 'status' like selection. + After choosing the path, it presents the diff between the index and the working tree file and asks you if you want to stage the change of each hunk. You can say: y - stage this hunk n - do not stage this hunk + q - quit, do not stage this hunk nor any of the remaining ones a - stage this and all the remaining hunks in the file d - do not stage this hunk nor any of the remaining hunks in the file + g - select a hunk to go to + / - search for a hunk matching the given regex j - leave this hunk undecided, see next undecided hunk J - leave this hunk undecided, see next hunk k - leave this hunk undecided, see previous undecided hunk @@ -254,13 +280,6 @@ diff:: This lets you review what will be committed (i.e. between HEAD and index). -Bugs ----- -The interactive mode does not work with files whose names contain -characters that need C-quoting. `core.quotepath` configuration can be -used to work this limitation around to some degree, but backslash, -double-quote and control characters will still have problems. - SEE ALSO -------- linkgit:git-status[1] diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index b9c6fac748..67ad5da9cc 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -10,8 +10,10 @@ SYNOPSIS -------- [verse] 'git am' [--signoff] [--keep] [--utf8 | --no-utf8] - [--3way] [--interactive] - [--whitespace=<option>] [-C<n>] [-p<n>] + [--3way] [--interactive] [--committer-date-is-author-date] + [--ignore-date] [--ignore-space-change | --ignore-whitespace] + [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>] + [--reject] [-q | --quiet] [--scissors | --no-scissors] [<mbox> | <Maildir>...] 'git am' (--skip | --resolved | --abort) @@ -25,18 +27,30 @@ OPTIONS ------- <mbox>|<Maildir>...:: The list of mailbox files to read patches from. If you do not - supply this argument, reads from the standard input. If you supply - directories, they'll be treated as Maildirs. + supply this argument, the command reads from the standard input. + If you supply directories, they will be treated as Maildirs. -s:: --signoff:: - Add `Signed-off-by:` line to the commit message, using + Add a `Signed-off-by:` line to the commit message, using the committer identity of yourself. -k:: --keep:: Pass `-k` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]). +-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]). @@ -46,7 +60,7 @@ OPTIONS preferred encoding if it is not UTF-8). + This was optional in prior versions of git, but now it is the -default. You could use `--no-utf8` to override this. +default. You can use `--no-utf8` to override this. --no-utf8:: Pass `-n` flag to 'git-mailinfo' (see @@ -55,17 +69,18 @@ default. You could use `--no-utf8` to override this. -3:: --3way:: When the patch does not apply cleanly, fall back on - 3-way merge, if the patch records the identity of blobs - it is supposed to apply to, and we have those blobs + 3-way merge if the patch records the identity of blobs + it is supposed to apply to and we have those blobs available locally. +--ignore-date:: +--ignore-space-change:: +--ignore-whitespace:: --whitespace=<option>:: - This flag is passed to the 'git-apply' (see linkgit:git-apply[1]) - program that applies - the patch. - -C<n>:: -p<n>:: +--directory=<dir>:: +--reject:: These flags are passed to the 'git-apply' (see linkgit:git-apply[1]) program that applies the patch. @@ -74,6 +89,20 @@ default. You could use `--no-utf8` to override this. --interactive:: Run interactively. +--committer-date-is-author-date:: + By default the command records the date from the e-mail + message as the commit author date, and uses the time of + commit creation as the committer date. This allows the + user to lie about the committer date by using the same + value as the author date. + +--ignore-date:: + By default the command records the date from the e-mail + message as the commit author date, and uses the time of + commit creation as the committer date. This allows the + user to lie about the author date by using the same + value as the committer date. + --skip:: Skip the current patch. This is only meaningful when restarting an aborted patch. @@ -101,24 +130,22 @@ DISCUSSION ---------- The commit author name is taken from the "From: " line of the -message, and commit author time is taken from the "Date: " line +message, and commit author date is taken from the "Date: " line of the message. The "Subject: " line is used as the title of the commit, after stripping common prefix "[PATCH <anything>]". -It is supposed to describe what the commit is about concisely as -a one line text. +The "Subject: " line is supposed to concisely describe what the +commit is about in one line of text. -The body of the message (iow, after a blank line that terminates -RFC2822 headers) can begin with "Subject: " and "From: " lines -that are different from those of the mail header, to override -the values of these fields. +"From: " and "Subject: " lines starting the body override the respective +commit author name and title values taken from the headers. The commit message is formed by the title taken from the "Subject: ", a blank line and the body of the message up to -where the patch begins. Excess whitespaces at the end of the -lines are automatically stripped. +where the patch begins. Excess whitespace at the end of each +line is automatically stripped. The patch is expected to be inline, directly following the -message. Any line that is of form: +message. Any line that is of the form: * three-dashes and end-of-line, or * a line that begins with "diff -", or @@ -127,18 +154,18 @@ message. Any line that is of form: is taken as the beginning of a patch, and the commit log message is terminated before the first occurrence of such a line. -When initially invoking it, you give it names of the mailboxes -to crunch. Upon seeing the first patch that does not apply, it -aborts in the middle,. You can recover from this in one of two ways: +When initially invoking `git am`, you give it the names of the mailboxes +to process. Upon seeing the first patch that does not apply, it +aborts in the middle. You can recover from this in one of two ways: -. skip the current patch by re-running the command with '--skip' +. skip the current patch by re-running the command with the '--skip' option. . hand resolve the conflict in the working directory, and update - the index file to bring it in a state that the patch should - have produced. Then run the command with '--resolved' option. + the index file to bring it into a state that the patch should + have produced. Then run the command with the '--resolved' option. -The command refuses to process new mailboxes while `.git/rebase-apply` +The command refuses to process new mailboxes while the `.git/rebase-apply` directory exists, so if you decide to start over from scratch, run `rm -f -r .git/rebase-apply` before running the command with mailbox names. diff --git a/Documentation/git-annotate.txt b/Documentation/git-annotate.txt index 0aba022ba6..0590eec056 100644 --- a/Documentation/git-annotate.txt +++ b/Documentation/git-annotate.txt @@ -3,7 +3,7 @@ git-annotate(1) NAME ---- -git-annotate - Annotate file lines with commit info +git-annotate - Annotate file lines with commit information SYNOPSIS -------- @@ -12,11 +12,11 @@ SYNOPSIS DESCRIPTION ----------- Annotates each line in the given file with information from the commit -which introduced the line. Optionally annotate from a given revision. +which introduced the line. Optionally annotates from a given revision. The only difference between this command and linkgit:git-blame[1] is that they use slightly different output formats, and this command exists only -for backward compatibility to support existing scripts, and provide more +for backward compatibility to support existing scripts, and provide a more familiar command name for people coming from other SCM systems. OPTIONS diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt index 44e1968a1c..5ee8c91f2d 100644 --- a/Documentation/git-apply.txt +++ b/Documentation/git-apply.txt @@ -3,18 +3,20 @@ git-apply(1) NAME ---- -git-apply - Apply a patch on a git index file and a working tree +git-apply - Apply a patch on a git index file and/or a working tree SYNOPSIS -------- [verse] 'git apply' [--stat] [--numstat] [--summary] [--check] [--index] - [--apply] [--no-add] [--build-fake-ancestor <file>] [-R | --reverse] + [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse] [--allow-binary-replacement | --binary] [--reject] [-z] [-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached] + [--ignore-space-change | --ignore-whitespace ] [--whitespace=<nowarn|warn|fix|error|error-all>] - [--exclude=PATH] [--directory=<root>] [--verbose] [<patch>...] + [--exclude=PATH] [--include=PATH] [--directory=<root>] + [--verbose] [<patch>...] DESCRIPTION ----------- @@ -24,7 +26,7 @@ and a work tree. OPTIONS ------- <patch>...:: - The files to read patch from. '-' can be used to read + The files to read the patch from. '-' can be used to read from the standard input. --stat:: @@ -32,8 +34,8 @@ OPTIONS input. Turns off "apply". --numstat:: - Similar to \--stat, but shows number of added and - deleted lines in decimal notation and pathname without + Similar to \--stat, but shows the number of added and + deleted lines in decimal notation and the pathname without abbreviation, to make it more machine friendly. For binary files, outputs two `-` instead of saying `0 0`. Turns off "apply". @@ -59,15 +61,15 @@ OPTIONS causes the index file to be updated. --cached:: - Apply a patch without touching the working tree. Instead, take the - cached data, apply the patch, and store the result in the index, + Apply a patch without touching the working tree. Instead take the + cached data, apply the patch, and store the result in the index without using the working tree. This implies '--index'. ---build-fake-ancestor <file>:: +--build-fake-ancestor=<file>:: Newer 'git-diff' output has embedded 'index information' for each blob to help identify the original version that the patch applies to. When this flag is given, and if - the original versions of the blobs is available locally, + the original versions of the blobs are available locally, builds a temporary index containing those blobs. + When a pure mode change is encountered (which has no index information), @@ -108,13 +110,13 @@ the information is read from the current index instead. applying a diff generated with --unified=0. To bypass these checks use '--unidiff-zero'. + -Note, for the reasons stated above usage of context-free patches are +Note, for the reasons stated above usage of context-free patches is discouraged. --apply:: If you use any of the options marked "Turns off 'apply'" above, 'git-apply' reads and outputs the - information you asked without actually applying the + requested information without actually applying the patch. Give this flag after those flags to also apply the patch. @@ -123,7 +125,7 @@ discouraged. patch. This can be used to extract the common part between two files by first running 'diff' on them and applying the result with this option, which would apply the - deletion part but not addition part. + deletion part but not the addition part. --allow-binary-replacement:: --binary:: @@ -137,6 +139,25 @@ discouraged. be useful when importing patchsets, where you want to exclude certain files or directories. +--include=<path-pattern>:: + Apply changes to files matching the given path pattern. This can + be useful when importing patchsets, where you want to include certain + files or directories. ++ +When --exclude and --include patterns are used, they are examined in the +order they appear on the command line, and the first match determines if a +patch to each path is used. A patch to a path that does not match any +include/exclude pattern is used by default if there is no include pattern +on the command line, and ignored if there is any include pattern. + +--ignore-space-change:: +--ignore-whitespace:: + When applying a patch, ignore changes in whitespace in context + lines if necessary. + Context lines will preserve their whitespace, and they will not + undergo whitespace fixing regardless of the value of the + `--whitespace` option. New lines will still be fixed, though. + --whitespace=<action>:: When applying a patch, detect a new or modified line that has whitespace errors. What are considered whitespace errors is @@ -150,7 +171,7 @@ 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>` to control this +You can use different `<action>` values to control this behavior: + * `nowarn` turns off the trailing whitespace warning. @@ -158,7 +179,7 @@ behavior: patch as-is (default). * `fix` outputs warnings for a few such errors, and applies the patch after fixing them (`strip` is a synonym --- the tool - used to consider only trailing whitespaces as errors, and the + used to consider only trailing whitespace characters as errors, and the fix involved 'stripping' them, but modern gits do more). * `error` outputs warnings for a few such errors, and refuses to apply the patch. @@ -183,7 +204,7 @@ behavior: adjusting the hunk headers appropriately). --directory=<root>:: - Prepend <root> to all filenames. If a "-p" argument was passed, too, + Prepend <root> to all filenames. If a "-p" argument was also passed, it is applied before prepending the new root. + For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh` @@ -193,6 +214,10 @@ 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. @@ -209,7 +234,7 @@ ignored, i.e., they are not required to be up-to-date or clean and they are not updated. If --index is not specified, then the submodule commits in the patch -are ignored and only the absence of presence of the corresponding +are ignored and only the absence or presence of the corresponding subdirectory is checked and (if possible) updated. Author diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt index 818ce94260..3d1c1e75b7 100644 --- a/Documentation/git-archive.txt +++ b/Documentation/git-archive.txt @@ -10,6 +10,7 @@ SYNOPSIS -------- [verse] 'git archive' [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>] + [-o | --output=<file>] [--worktree-attributes] [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish> [path...] @@ -22,7 +23,7 @@ prepended to the filenames in the archive. 'git-archive' behaves differently when given a tree ID versus when given a commit ID or tag ID. In the first case the current time is -used as modification time of each file in the archive. In the latter +used as the modification time of each file in the archive. In the latter case the commit time as recorded in the referenced commit object is used instead. Additionally the commit ID is stored in a global extended pax header if the tar format is used; it can be extracted @@ -33,8 +34,11 @@ OPTIONS ------- --format=<fmt>:: - Format of the resulting archive: 'tar' or 'zip'. The default - is 'tar'. + Format of the resulting archive: 'tar' or 'zip'. If this option + is not given, and the output file is specified, the format is + inferred from the filename if possible (e.g. writing to "foo.zip" + makes the output to be in the zip format). Otherwise the output + format is `tar`. -l:: --list:: @@ -47,12 +51,19 @@ OPTIONS --prefix=<prefix>/:: Prepend <prefix>/ to each filename in the archive. +-o <file>:: +--output=<file>:: + Write the archive to <file> instead of stdout. + +--worktree-attributes:: + Look for attributes in .gitattributes in working directory too. + <extra>:: - This can be any options that the archiver backend understand. + This can be any options that the archiver backend understands. See next section. --remote=<repo>:: - Instead of making a tar archive from local repository, + Instead of making a tar archive from the local repository, retrieve a tar archive from a remote repository. --exec=<git-upload-archive>:: @@ -88,12 +99,24 @@ tar.umask:: archiving user's umask will be used instead. See umask(2) for details. +ATTRIBUTES +---------- + +export-ignore:: + Files and directories with the attribute export-ignore won't be + added to archive files. See linkgit:gitattributes[5] for details. + +export-subst:: + If the attribute export-subst is set for a file then git will + expand several placeholders when adding this file to an archive. + See linkgit:gitattributes[5] for details. + EXAMPLES -------- git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -):: Create a tar archive that contains the contents of the - latest commit on the current branch, and extracts it in + latest commit on the current branch, and extract it in the `/var/tmp/junk` directory. git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz:: @@ -110,6 +133,17 @@ git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs Put everything in the current head's Documentation/ directory into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'. +git archive -o latest.zip HEAD:: + + Create a Zip archive that contains the contents of the latest + commit on the current branch. Note that the output format is + inferred by the extension of the output file. + + +SEE ALSO +-------- +linkgit:gitattributes[5] + Author ------ Written by Franck Bui-Huu and Rene Scharfe. diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index 39034ec7d6..63e7a42cb3 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -3,7 +3,7 @@ git-bisect(1) NAME ---- -git-bisect - Find the change that introduced a bug by binary search +git-bisect - Find by binary search the change that introduced a bug SYNOPSIS @@ -19,7 +19,7 @@ on the subcommand: git bisect start [<bad> [<good>...]] [--] [<paths>...] git bisect bad [<rev>] git bisect good [<rev>...] - git bisect skip [<rev>...] + git bisect skip [(<rev>|<range>)...] git bisect reset [<branch>] git bisect visualize git bisect replay <logfile> @@ -39,7 +39,8 @@ help" or "git bisect -h" to get a long usage description. Basic bisect commands: start, bad, good ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The way you use it is: +Using the Linux kernel tree as an example, basic use of the bisect +command is as follows: ------------------------------------------------ $ git bisect start @@ -48,61 +49,63 @@ $ git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good ------------------------------------------------ -When you give at least one bad and one good versions, it will bisect -the revision tree and say something like: +When you have specified at least one bad and one good version, the +command bisects the revision tree and outputs something similar to +the following: ------------------------------------------------ Bisecting: 675 revisions left to test after this ------------------------------------------------ -and check out the state in the middle. Now, compile that kernel, and -boot it. Now, let's say that this booted kernel works fine, then just -do +The state in the middle of the set of revisions is then checked out. +You would now compile that kernel and boot it. If the booted kernel +works correctly, you would then issue the following command: ------------------------------------------------ $ git bisect good # this one is good ------------------------------------------------ -which will now say +The output of this command would be something similar to the following: ------------------------------------------------ Bisecting: 337 revisions left to test after this ------------------------------------------------ -and you continue along, compiling that one, testing it, and depending -on whether it is good or bad, you say "git bisect good" or "git bisect -bad", and ask for the next bisection. +You keep repeating this process, compiling the tree, testing it, and +depending on whether it is good or bad issuing the command "git bisect good" +or "git bisect bad" to ask for the next bisection. -Until you have no more left, and you'll have been left with the first -bad kernel rev in "refs/bisect/bad". +Eventually there will be no more revisions left to bisect, and you +will have been left with the first bad kernel revision in "refs/bisect/bad". Bisect reset ~~~~~~~~~~~~ -Oh, and then after you want to reset to the original head, do a +To return to the original head after a bisect session, issue the +following command: ------------------------------------------------ $ git bisect reset ------------------------------------------------ -to get back to the original branch, instead of being on the bisection -commit ("git bisect start" will do that for you too, actually: it will -reset the bisection state). +This resets the tree to the original branch instead of being on the +bisection commit ("git bisect start" will also do that, as it resets +the bisection state). Bisect visualize ~~~~~~~~~~~~~~~~ -During the bisection process, you can say +To see the currently remaining suspects in 'gitk', issue the following +command during the bisection process: ------------ $ git bisect visualize ------------ -to see the currently remaining suspects in 'gitk'. `visualize` is a bit -too long to type and `view` is provided as a synonym. +`view` may also be used as a synonym for `visualize`. -If 'DISPLAY' environment variable is not set, 'git log' is used -instead. You can even give command line options such as `-p` and +If the 'DISPLAY' environment variable is not set, 'git log' is used +instead. You can also give command line options such as `-p` and `--stat`. ------------ @@ -112,73 +115,93 @@ $ git bisect view --stat Bisect log and bisect replay ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The good/bad input is logged, and +After having marked revisions as good or bad, issue the following +command to show what has been done so far: ------------ $ git bisect log ------------ -shows what you have done so far. You can truncate its output somewhere -and save it in a file, and run +If you discover that you made a mistake in specifying the status of a +revision, you can save the output of this command to a file, edit it to +remove the incorrect entries, and then issue the following commands to +return to a corrected state: ------------ +$ git bisect reset $ git bisect replay that-file ------------ -if you find later you made a mistake telling good/bad about a -revision. - -Avoiding to test a commit +Avoiding testing a commit ~~~~~~~~~~~~~~~~~~~~~~~~~ -If in a middle of bisect session, you know what the bisect suggested -to try next is not a good one to test (e.g. the change the commit +If, in the middle of a bisect session, you know that the next suggested +revision is not a good one to test (e.g. the change the commit introduces is known not to work in your environment and you know it does not have anything to do with the bug you are chasing), you may -want to find a near-by commit and try that instead. +want to find a nearby commit and try that instead. -It goes something like this: +For example: ------------ -$ git bisect good/bad # previous round was good/bad. +$ git bisect good/bad # previous round was good or bad. Bisecting: 337 revisions left to test after this $ git bisect visualize # oops, that is uninteresting. -$ git reset --hard HEAD~3 # try 3 revs before what +$ git reset --hard HEAD~3 # try 3 revisions before what # was suggested ------------ -Then compile and test the one you chose to try. After that, tell -bisect what the result was as usual. +Then compile and test the chosen revision, and afterwards mark +the revision as good or bad in the usual manner. Bisect skip ~~~~~~~~~~~~ -Instead of choosing by yourself a nearby commit, you may just want git -to do it for you using: +Instead of choosing by yourself a nearby commit, you can ask git +to do it for you by issuing the command: ------------ $ git bisect skip # Current version cannot be tested ------------ -But computing the commit to test may be slower afterwards and git may -eventually not be able to tell the first bad among a bad and one or -more "skip"ped commits. +But git may eventually be unable to tell the first bad commit among +a bad commit and one or more skipped commits. + +You can even skip a range of commits, instead of just one commit, +using the "'<commit1>'..'<commit2>'" notation. For example: + +------------ +$ git bisect skip v2.5..v2.6 +------------ + +This tells the bisect process that no commit after `v2.5`, up to and +including `v2.6`, should be tested. + +Note that if you also want to skip the first commit of the range you +would issue the command: + +------------ +$ git bisect skip v2.5 v2.5..v2.6 +------------ + +This tells the bisect process that the commits between `v2.5` included +and `v2.6` included should be skipped. + Cutting down bisection by giving more parameters to bisect start ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -You can further cut down the number of trials if you know what part of -the tree is involved in the problem you are tracking down, by giving -paths parameters when you say `bisect start`, like this: +You can further cut down the number of trials, if you know what part of +the tree is involved in the problem you are tracking down, by specifying +path parameters when issuing the `bisect start` command: ------------ $ git bisect start -- arch/i386 include/asm-i386 ------------ -If you know beforehand more than one good commits, you can narrow the -bisect space down without doing the whole tree checkout every time you -give good commits. You give the bad revision immediately after `start` -and then you give all the good revisions you have: +If you know beforehand more than one good commit, you can narrow the +bisect space down by specifying all of the good commits immediately after +the bad commit when issuing the `bisect start` command: ------------ $ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 -- @@ -190,38 +213,38 @@ Bisect run ~~~~~~~~~~ If you have a script that can tell if the current source code is good -or bad, you can automatically bisect using: +or bad, you can bisect by issuing the command: ------------ -$ git bisect run my_script +$ git bisect run my_script arguments ------------ -Note that the "run" script (`my_script` in the above example) should -exit with code 0 in case the current source code is good. Exit with a +Note that the script (`my_script` in the above example) should +exit with code 0 if the current source code is good, and exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad. -Any other exit code will abort the automatic bisect process. (A -program that does "exit(-1)" leaves $? = 255, see exit(3) manual page, -the value is chopped with "& 0377".) +Any other exit code will abort the bisect process. It should be noted +that a program that terminates via "exit(-1)" leaves $? = 255, (see the +exit(3) manual page), as the value is chopped with "& 0377". The special exit code 125 should be used when the current source code -cannot be tested. If the "run" script exits with this code, the current -revision will be skipped, see `git bisect skip` above. +cannot be tested. If the script exits with this code, the current +revision will be skipped (see `git bisect skip` above). -You may often find that during bisect you want to have near-constant -tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or -"revision that does not have this commit needs this patch applied to -work around other problem this bisection is not interested in") -applied to the revision being tested. +You may often find that during a bisect session you want to have +temporary modifications (e.g. s/#define DEBUG 0/#define DEBUG 1/ in a +header file, or "revision that does not have this commit needs this +patch applied to work around another problem this bisection is not +interested in") applied to the revision being tested. To cope with such a situation, after the inner 'git bisect' finds the -next revision to test, with the "run" script, you can apply that tweak -before compiling, run the real test, and after the test decides if the -revision (possibly with the needed tweaks) passed the test, rewind the -tree to the pristine state. Finally the "run" script can exit with -the status of the real test to let the "git bisect run" command loop to -determine the outcome. +next revision to test, the script can apply the patch +before compiling, run the real test, and afterwards decide if the +revision (possibly with the needed patch) passed the test and then +rewind the tree to the pristine state. Finally the script should exit +with the status of the real test to let the "git bisect run" command loop +determine the eventual outcome of the bisect session. EXAMPLES -------- @@ -233,44 +256,60 @@ $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good $ git bisect run make # "make" builds the app ------------ +* Automatically bisect a test failure between origin and HEAD: ++ +------------ +$ git bisect start HEAD origin -- # HEAD is bad, origin is good +$ git bisect run make test # "make test" builds and tests +------------ + * Automatically bisect a broken test suite: + ------------ $ cat ~/test.sh #!/bin/sh -make || exit 125 # this "skip"s broken builds +make || exit 125 # this skips broken builds make test # "make test" runs the test suite $ git bisect start v1.3 v1.1 -- # v1.3 is bad, v1.1 is good $ git bisect run ~/test.sh ------------ + Here we use a "test.sh" custom script. In this script, if "make" -fails, we "skip" the current commit. +fails, we skip the current commit. + -It's safer to use a custom script outside the repo to prevent +It is safer to use a custom script outside the repository to prevent interactions between the bisect, make and test processes and the script. + -And "make test" should "exit 0", if the test suite passes, and -"exit 1" (for example) otherwise. +"make test" should "exit 0", if the test suite passes, and +"exit 1" otherwise. * Automatically bisect a broken test case: + ------------ $ cat ~/test.sh #!/bin/sh -make || exit 125 # this "skip"s broken builds +make || exit 125 # this skips broken builds ~/check_test_case.sh # does the test case passes ? $ git bisect start HEAD HEAD~10 -- # culprit is among the last 10 $ git bisect run ~/test.sh ------------ + -Here "check_test_case.sh" should "exit 0", if the test case passes, -and "exit 1" (for example) otherwise. +Here "check_test_case.sh" should "exit 0" if the test case passes, +and "exit 1" otherwise. ++ +It 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" +------------ + -It's safer if both "test.sh" and "check_test_case.sh" scripts are -outside the repo to prevent interactions between the bisect, make and -test processes and the scripts. +Does the same as the previous example, but on a single line. Author ------ diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index fba374d652..8c7b7b0838 100644 --- a/Documentation/git-blame.txt +++ b/Documentation/git-blame.txt @@ -10,7 +10,7 @@ SYNOPSIS [verse] 'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m] [-S <revs-file>] [-M] [-C] [-C] [--since=<date>] - [<rev> | --contents <file>] [--] <file> + [<rev> | --contents <file> | --reverse <rev>] [--] <file> DESCRIPTION ----------- @@ -18,9 +18,9 @@ DESCRIPTION Annotates each line in the given file with information from the revision which last modified the line. Optionally, start annotating from the given revision. -Also it can limit the range of lines annotated. +The command can also limit the range of lines annotated. -This report doesn't tell you anything about lines which have been deleted or +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. @@ -48,26 +48,26 @@ include::blame-options.txt[] lines between files (see `-C`) and lines moved within a file (see `-M`). The first number listed is the score. This is the number of alphanumeric characters detected - to be moved between or within files. This must be above + as having been moved between or within files. This must be above a certain threshold for 'git-blame' to consider those lines of code to have been moved. -f:: --show-name:: - Show filename in the original commit. By default - filename is shown if there is any line that came from a - file with different name, due to rename detection. + Show the filename in the original commit. By default + the filename is shown if there is any line that came from a + file with a different name, due to rename detection. -n:: --show-number:: - Show line number in the original commit (Default: off). + Show the line number in the original commit (Default: off). -s:: - Suppress author name and timestamp from the output. + Suppress the author name and timestamp from the output. -w:: - Ignore whitespace when comparing parent's version and - child's to find where the lines came from. + Ignore whitespace when comparing the parent's version and + the child's to find where the lines came from. THE PORCELAIN FORMAT @@ -79,17 +79,17 @@ header at the minimum has the first line which has: - 40-byte SHA-1 of the commit the line is attributed to; - the line number of the line in the original file; - the line number of the line in the final file; -- on a line that starts a group of line from a different +- on a line that starts a group of lines from a different commit than the previous one, the number of lines in this group. On subsequent lines this field is absent. This header line is followed by the following information at least once for each commit: -- author name ("author"), email ("author-mail"), time +- the author name ("author"), email ("author-mail"), time ("author-time"), and timezone ("author-tz"); similarly for committer. -- filename in the commit the line is attributed to. +- the filename in the commit that the line is attributed to. - the first line of the commit log message ("summary"). The contents of the actual line is output after the above @@ -100,23 +100,23 @@ header elements later. SPECIFYING RANGES ----------------- -Unlike 'git-blame' and 'git-annotate' in older git, the extent -of annotation can be limited to both line ranges and revision +Unlike 'git-blame' and 'git-annotate' in older versions of git, the extent +of the annotation can be limited to both line ranges and revision ranges. When you are interested in finding the origin for -ll. 40-60 for file `foo`, you can use `-L` option like these +lines 40-60 for file `foo`, you can use the `-L` option like so (they mean the same thing -- both ask for 21 lines starting at line 40): git blame -L 40,60 foo git blame -L 40,+21 foo -Also you can use regular expression to specify the line range. +Also you can use a regular expression to specify the line range: git blame -L '/^sub hello {/,/^}$/' foo -would limit the annotation to the body of `hello` subroutine. +which limits the annotation to the body of the `hello` subroutine. -When you are not interested in changes older than the version +When you are not interested in changes older than version v2.6.18, or changes older than 3 weeks, you can use revision range specifiers similar to 'git-rev-list': @@ -129,7 +129,7 @@ commit v2.6.18 or the most recent commit that is more than 3 weeks old in the above example) are blamed for that range boundary commit. -A particularly useful way is to see if an added file have lines +A particularly useful way is to see if an added file has lines created by copy-and-paste from existing files. Sometimes this indicates that the developer was being sloppy and did not refactor the code properly. You can first find the commit that @@ -162,26 +162,32 @@ annotated. + Line numbers count from 1. -. The first time that commit shows up in the stream, it has various +. The first time that a commit shows up in the stream, it has various other information about it printed out with a one-word tag at the - beginning of each line about that "extended commit info" (author, - email, committer, dates, summary etc). + beginning of each line describing the extra commit information (author, + email, committer, dates, summary, etc.). -. Unlike Porcelain format, the filename information is always +. Unlike the Porcelain format, the filename information is always given and terminates the entry: "filename" <whitespace-quoted-filename-goes-here> + -and thus it's really quite easy to parse for some line- and word-oriented +and thus it is really quite easy to parse for some line- and word-oriented parser (which should be quite natural for most scripting languages). + [NOTE] For people who do parsing: to make it more robust, just ignore any -lines in between the first and last one ("<sha1>" and "filename" lines) -where you don't recognize the tag-words (or care about that particular +lines between the first and last one ("<sha1>" and "filename" lines) +where you do not recognize the tag words (or care about that particular one) at the beginning of the "extended information" lines. That way, if there is ever added information (like the commit encoding or extended -commit commentary), a blame viewer won't ever care. +commit commentary), a blame viewer will not care. + + +MAPPING AUTHORS +--------------- + +include::mailmap.txt[] SEE ALSO diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 6103d62fe3..0e836809c2 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -18,22 +18,20 @@ SYNOPSIS DESCRIPTION ----------- -With no arguments, existing branches are listed, the current branch will +With no arguments, existing branches are listed and the current branch will be highlighted with an asterisk. Option `-r` causes the remote-tracking branches to be listed, and option `-a` shows both. -With `--contains`, shows only the branches that contains the named commit -(in other words, the branches whose tip commits are descendant of the +With `--contains`, shows only the branches that contain the named commit +(in other words, the branches whose tip commits are descendants of the named commit). With `--merged`, only branches merged into the named commit (i.e. the branches whose tip commits are reachable from the named commit) will be listed. With `--no-merged` only branches not merged into -the named commit will be listed. Missing <commit> argument defaults to -'HEAD' (i.e. the tip of the current branch). +the named commit will be listed. If the <commit> argument is missing it +defaults to 'HEAD' (i.e. the tip of the current branch). -In its second form, a new branch named <branchname> will be created. -It will start out with a head equal to the one given as <start-point>. -If no <start-point> is given, the branch will be created with a head -equal to that of the currently checked out branch. +The command's second form creates a new branch head named <branchname> +which points to the current 'HEAD', or <start-point> if given. Note that this will create the new branch, but it will not switch the working tree to it; use "git checkout <newbranch>" to switch to the @@ -57,9 +55,9 @@ has a reflog then the reflog will also be deleted. Use -r together with -d to delete remote-tracking branches. Note, that it only makes sense to delete remote-tracking branches if they no longer exist -in remote repository or if 'git-fetch' was configured not to fetch -them again. See also 'prune' subcommand of linkgit:git-remote[1] for way to -clean up all obsolete remote-tracking branches. +in the remote repository or if 'git-fetch' was configured not to fetch +them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a +way to clean up all obsolete remote-tracking branches. OPTIONS @@ -76,14 +74,15 @@ OPTIONS based sha1 expressions such as "<branchname>@\{yesterday}". -f:: - Force the creation of a new branch even if it means deleting - a branch that already exists with the same name. +--force:: + Reset <branchname> to <startpoint> if <branchname> exists + already. Without `-f` 'git-branch' refuses to change an existing branch. -m:: Move/rename a branch and the corresponding reflog. -M:: - Move/rename a branch even if the new branchname already exists. + Move/rename a branch even if the new branch name already exists. --color:: Color branches to highlight current, local, and remote branches. @@ -100,38 +99,46 @@ OPTIONS -v:: --verbose:: - Show sha1 and commit subject line for each head. + Show sha1 and commit subject line for each head, along with + relationship to upstream branch (if any). If given twice, print + the name of the upstream branch, as well. --abbrev=<length>:: - Alter minimum display length for sha1 in output listing, - default value is 7. + Alter the sha1's minimum display length in the output listing. + The default value is 7. --no-abbrev:: - Display the full sha1s in output listing rather than abbreviating them. + Display the full sha1s in the output listing rather than abbreviating them. +-t:: --track:: - When creating a new branch, set up configuration so that 'git-pull' - will automatically retrieve data from the start point, which must be - a branch. Use this if you always pull from the same upstream branch - into the new branch, and if you don't want to use "git pull - <repository> <refspec>" explicitly. This behavior is the default - when the start point is a remote branch. Set the - branch.autosetupmerge configuration variable to `false` if you want - 'git-checkout' and 'git-branch' to always behave as if '--no-track' were - given. Set it to `always` if you want this behavior when the - start-point is either a local or remote branch. + When creating a new branch, set up configuration to mark the + start-point branch as "upstream" from the new branch. This + configuration will tell git to show the relationship between the + two branches in `git status` and `git branch -v`. Furthermore, + it directs `git pull` without arguments to pull from the + upstream when the new branch is checked out. ++ +This behavior is the default when the start point is a remote branch. +Set the branch.autosetupmerge configuration variable to `false` if you +want `git checkout` and `git branch` to always behave as if '--no-track' +were given. Set it to `always` if you want this behavior when the +start-point is either a local or remote branch. --no-track:: - Ignore the branch.autosetupmerge configuration variable. + Do not set up "upstream" configuration, even if the + branch.autosetupmerge configuration variable is true. --contains <commit>:: Only list branches which contain the specified commit. ---merged:: - Only list branches which are fully contained by HEAD. +--merged [<commit>]:: + Only list branches whose tips are reachable from the + specified commit (HEAD if not specified). ---no-merged:: - Do not list branches which are fully contained by HEAD. +--no-merged [<commit>]:: + Only list branches whose tips are not reachable from the + specified commit (HEAD if not specified). <branchname>:: The name of the branch to create or delete. @@ -140,22 +147,22 @@ OPTIONS may restrict the characters allowed in a branch name. <start-point>:: - The new branch will be created with a HEAD equal to this. It may - be given as a branch name, a commit-id, or a tag. If this option - is omitted, the current branch is assumed. + The new branch head will point to this commit. It may be + given as a branch name, a commit-id, or a tag. If this + option is omitted, the current HEAD will be used instead. <oldbranch>:: The name of an existing branch to rename. <newbranch>:: The new name for an existing branch. The same restrictions as for - <branchname> applies. + <branchname> apply. Examples -------- -Start development off of a known tag:: +Start development from a known tag:: + ------------ $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 @@ -167,7 +174,7 @@ $ git checkout my2.6.14 <1> This step and the next one could be combined into a single step with "checkout -b my2.6.14 v2.6.14". -Delete unneeded branch:: +Delete an unneeded branch:: + ------------ $ git clone git://git.kernel.org/.../git.git my.git @@ -176,21 +183,21 @@ $ git branch -d -r origin/todo origin/html origin/man <1> $ git branch -D test <2> ------------ + -<1> Delete remote-tracking branches "todo", "html", "man". Next 'fetch' or -'pull' will create them again unless you configure them not to. See -linkgit:git-fetch[1]. -<2> Delete "test" branch even if the "master" branch (or whichever branch is -currently checked out) does not have all commits from test branch. +<1> Delete the remote-tracking branches "todo", "html" and "man". The next +'fetch' or 'pull' will create them again unless you configure them not to. +See linkgit:git-fetch[1]. +<2> Delete the "test" branch even if the "master" branch (or whichever branch +is currently checked out) does not have all commits from the test branch. Notes ----- -If you are creating a branch that you want to immediately checkout, it's +If you are creating a branch that you want to checkout immediately, it is easier to use the git checkout command with its `-b` option to create a branch and check it out with a single command. -The options `--contains`, `--merged` and `--no-merged` serves three related +The options `--contains`, `--merged` and `--no-merged` serve three related but different purposes: - `--contains <commit>` is used to find all branches which will need @@ -203,6 +210,14 @@ but different purposes: - `--no-merged` is used to find branches which are candidates for merging into HEAD, since those branches are not fully contained by HEAD. +SEE ALSO +-------- +linkgit:git-check-ref-format[1], +linkgit:git-fetch[1], +linkgit:git-remote[1], +link:user-manual.html#what-is-a-branch[``Understanding history: What is +a branch?''] in the Git User's Manual. + Author ------ Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <gitster@pobox.com> diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt index 1b66ab743c..c3a066e60c 100644 --- a/Documentation/git-bundle.txt +++ b/Documentation/git-bundle.txt @@ -19,13 +19,13 @@ DESCRIPTION Some workflows require that one or more branches of development on one machine be replicated on another machine, but the two machines cannot -be directly connected so the interactive git protocols (git, ssh, -rsync, http) cannot be used. This command provides support for +be directly connected, and therefore the interactive git protocols (git, +ssh, rsync, http) cannot be used. This command provides support for 'git-fetch' and 'git-pull' to operate by packaging objects and references in an archive at the originating machine, then importing those into another repository using 'git-fetch' and 'git-pull' -after moving the archive by some means (i.e., by sneakernet). As no -direct connection between repositories exists, the user must specify a +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. @@ -43,7 +43,7 @@ verify <file>:: bundle format itself as well as checking that the prerequisite commits exist and are fully linked in the current repository. 'git-bundle' prints a list of missing commits, if any, and exits - with non-zero status. + with a non-zero status. list-heads <file>:: Lists the references defined in the bundle. If followed by a @@ -53,14 +53,14 @@ list-heads <file>:: 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 reflist is given, only references - matching those in the given list are printed. This command is + defined references. If a list of references is given, only + references matching those in the list are printed. This command is really plumbing, intended to be called only by 'git-fetch'. [git-rev-list-args...]:: A list of arguments, acceptable to 'git-rev-parse' and - 'git-rev-list', that specify the specific objects and references - to transport. For example, "master~10..master" causes the + '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 @@ -71,98 +71,134 @@ unbundle <file>:: 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' is - acting like 'git-fetch-pack'). + necessarily everything in the pack (in this case, 'git-bundle' acts + like 'git-fetch-pack'). SPECIFYING REFERENCES --------------------- 'git-bundle' will only package references that are shown by 'git-show-ref': this includes heads, tags, and remote heads. References -such as master~1 cannot be packaged, but are perfectly suitable for +such as `master\~1` cannot be packaged, but are perfectly suitable for defining the basis. More than one reference may be packaged, and more than one basis can be specified. The objects packaged are those not contained in the union of the given bases. Each basis can be -specified explicitly (e.g., ^master~10), or implicitly (e.g., -master~10..master, master --since=10.days.ago). +specified explicitly (e.g. `^master\~10`), or implicitly (e.g. +`master\~10..master`, `--since=10.days.ago master`). It is very important that the basis used be held by the destination. -It is okay to err on the side of conservatism, causing the bundle file -to contain objects already in the destination as these are ignored +It is okay to err on the side of caution, causing the bundle file +to contain objects already in the destination, as these are ignored when unpacking at the destination. EXAMPLE ------- -Assume two repositories exist as R1 on machine A, and R2 on machine B. +Assume you want to transfer the history from a repository R1 on machine A +to another repository R2 on machine B. For whatever reason, direct connection between A and B is not allowed, -but we can move data from A to B via some mechanism (CD, email, etc). -We want to update R2 with developments made on branch master in R1. +but we can move data from A to B via some mechanism (CD, email, etc.). +We want to update R2 with development made on the branch master in R1. -To create the bundle you have to specify the basis. You have some options: +To bootstrap the process, you can first create a bundle that does not have +any basis. You can use a tag to remember up to what commit you last +processed, in order to make it easy to later update the other repository +with an incremental bundle: -- Without basis. -+ -This is useful when sending the whole history. +---------------- +machineA$ cd R1 +machineA$ git bundle create file.bundle master +machineA$ git tag -f lastR2bundle master +---------------- ------------- -$ git bundle create mybundle master ------------- +Then you transfer file.bundle to the target machine B. If you are creating +the repository on machine B, then you can clone from the bundle as if it +were a remote repository instead of creating an empty repository and then +pulling or fetching objects from the bundle: -- Using temporally tags. -+ -We set a tag in R1 (lastR2bundle) after the previous such transport, -and move it afterwards to help build the bundle. +---------------- +machineB$ git clone /home/me/tmp/file.bundle R2 +---------------- ------------- -$ git bundle create mybundle master ^lastR2bundle -$ git tag -f lastR2bundle master ------------- +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: -- Using a tag present in both repositories +------------------------ +[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 +---------------- ------------- -$ git bundle create mybundle master ^v1.0.0 ------------- +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: -- A basis based on time. +You can use a tag that is present in both: ------------- -$ git bundle create mybundle master --since=10.days.ago ------------- +---------------- +$ git bundle create mybundle v1.0.0..master +---------------- -- With a limit on the number of commits +You can use a basis based on time: ------------- -$ git bundle create mybundle master -n 10 ------------- +---------------- +$ git bundle create mybundle --since=10.days master +---------------- -Then you move mybundle from A to B, and in R2 on B: +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 -$ git fetch mybundle master:localRef ------------- +---------------- -With something like this in the config in R2: +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. ------------------------- -[remote "bundle"] - url = /home/me/tmp/file.bdl - fetch = refs/heads/*:refs/remotes/origin/* ------------------------- +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: -You can first sneakernet the bundle file to ~/tmp/file.bdl and -then these commands on machine B: +---------------- +$ git fetch mybundle master:localRef +---------------- ------------- -$ git ls-remote bundle -$ git fetch bundle -$ git pull bundle ------------- +You can also see what references it offers. -would treat it as if it is talking with a remote side over the -network. +---------------- +$ git ls-remote mybundle +---------------- Author ------ diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt index 668f697c2a..58c8d65772 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -3,30 +3,30 @@ git-cat-file(1) NAME ---- -git-cat-file - Provide content or type/size information for repository objects +git-cat-file - Provide content or type and size information for repository objects SYNOPSIS -------- [verse] -'git cat-file' [-t | -s | -e | -p | <type>] <object> -'git cat-file' [--batch | --batch-check] < <list-of-objects> +'git cat-file' (-t | -s | -e | -p | <type>) <object> +'git cat-file' (--batch | --batch-check) < <list-of-objects> DESCRIPTION ----------- -In the first form, provides content or type of objects in the repository. The -type is required unless '-t' or '-p' is used to find the object type, or '-s' -is used to find the object size. +In its first form, the command provides the content or the type of an object in +the repository. The type is required unless '-t' or '-p' is used to find the +object type, or '-s' is used to find the object size. -In the second form, a list of object (separated by LFs) is provided on stdin, -and the SHA1, type, and size of each object is printed on stdout. +In the second form, a list of objects (separated by linefeeds) is provided on +stdin, and the SHA1, type, and size of each object is printed on stdout. OPTIONS ------- <object>:: The name of the object to show. For a more complete list of ways to spell object names, see - "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. + the "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. -t:: Instead of the content, show the object type identified by @@ -56,8 +56,8 @@ OPTIONS stdin. May not be combined with any other options or arguments. --batch-check:: - Print the SHA1, type, and size of each object provided on stdin. May not be - combined with any other options or arguments. + Print the SHA1, type, and size of each object provided on stdin. May not + be combined with any other options or arguments. OUTPUT ------ diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt index 043274b1b7..50824e3a2d 100644 --- a/Documentation/git-check-attr.txt +++ b/Documentation/git-check-attr.txt @@ -8,17 +8,26 @@ git-check-attr - Display gitattributes information SYNOPSIS -------- +[verse] 'git check-attr' attr... [--] pathname... +'git check-attr' --stdin [-z] attr... < <list-of-paths> DESCRIPTION ----------- -For every pathname, this command will list if each attr is 'unspecified', +For every pathname, this command will list if each attribute is 'unspecified', 'set', or 'unset' as a gitattribute on that pathname. OPTIONS ------- +--stdin:: + Read file names from stdin instead of from the command-line. + +-z:: + Only meaningful with `--stdin`; paths are separated with a + NUL character instead of a linefeed character. + \--:: - Interpret all preceding arguments as attributes, and all following + Interpret all preceding arguments as attributes and all following arguments as path names. If not supplied, only the first argument will be treated as an attribute. @@ -28,12 +37,12 @@ OUTPUT The output is of the form: <path> COLON SP <attribute> COLON SP <info> LF -Where <path> is the path of a file being queried, <attribute> is an attribute +<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 to false. -'set';; when the attribute is defined to true. +'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 @@ -60,7 +69,7 @@ org/example/MyClass.java: diff: java org/example/MyClass.java: myAttr: set --------------- -* Listing attribute for multiple files: +* Listing an attribute for multiple files: --------------- $ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java org/example/MyClass.java: myAttr: set diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index 034223cc5a..e9b3b40af4 100644 --- a/Documentation/git-check-ref-format.txt +++ b/Documentation/git-check-ref-format.txt @@ -3,52 +3,79 @@ git-check-ref-format(1) NAME ---- -git-check-ref-format - Make sure ref name is well formed +git-check-ref-format - Ensures that a reference name is well formed SYNOPSIS -------- +[verse] 'git check-ref-format' <refname> +'git check-ref-format' --branch <branchname-shorthand> DESCRIPTION ----------- -Checks if a given 'refname' is acceptable, and exits non-zero if -it is not. +Checks if a given 'refname' is acceptable, and exits with a non-zero +status if it is not. A reference is used in git to specify branches and tags. A -branch head is stored under `$GIT_DIR/refs/heads` directory, and -a tag is stored under `$GIT_DIR/refs/tags` directory. git -imposes the following rules on how refs are named: +branch head is stored under the `$GIT_DIR/refs/heads` directory, and +a tag is stored under the `$GIT_DIR/refs/tags` directory. git +imposes the following rules on how references are named: -. It can include slash `/` for hierarchical (directory) +. They can include slash `/` for hierarchical (directory) grouping, but no slash-separated component can begin with a - dot `.`; + dot `.`. -. It cannot have two consecutive dots `..` anywhere; +. They must contain at least one `/`. This enforces the presence of a + category like `heads/`, `tags/` etc. but the actual names are not + restricted. -. It cannot have ASCII control character (i.e. bytes whose +. They cannot have two consecutive dots `..` anywhere. + +. They cannot have ASCII control characters (i.e. bytes whose values are lower than \040, or \177 `DEL`), space, tilde `~`, caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`, - or open bracket `[` anywhere; + or open bracket `[` anywhere. + +. They cannot end with a slash `/` nor a dot `.`. + +. They cannot end with the sequence `.lock`. -. It cannot end with a slash `/`. +. They cannot contain a sequence `@{`. -These rules makes it easy for shell script based tools to parse -refnames, pathname expansion by the shell when a refname is used +- They cannot contain a `\\`. + +These rules make it easy for shell script based tools to parse +reference names, pathname expansion by the shell when a reference name is used unquoted (by mistake), and also avoids ambiguities in certain -refname expressions (see linkgit:git-rev-parse[1]). Namely: +reference name expressions (see linkgit:git-rev-parse[1]): -. double-dot `..` are often used as in `ref1..ref2`, and in some - context this notation means `{caret}ref1 ref2` (i.e. not in - ref1 and in ref2). +. A double-dot `..` is often used as in `ref1..ref2`, and in some + contexts this notation means `{caret}ref1 ref2` (i.e. not in + `ref1` and in `ref2`). -. tilde `~` and caret `{caret}` are used to introduce postfix +. A tilde `~` and caret `{caret}` are used to introduce the postfix 'nth parent' and 'peel onion' operation. -. colon `:` is used as in `srcref:dstref` to mean "use srcref\'s +. A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s value and store it in dstref" in fetch and push operations. It may also be used to select a specific object such as with 'git-cat-file': "git cat-file blob v1.3.3:refs.c". +. at-open-brace `@{` is used as a notation to access a reflog entry. + +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. + +EXAMPLE +------- + +git check-ref-format --branch @{-1}:: + +Print the name of the previous branch. + GIT --- diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 19510de151..37c1810e3f 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -8,68 +8,92 @@ git-checkout - Checkout a branch or paths to the working tree SYNOPSIS -------- [verse] -'git checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>] -'git checkout' [<tree-ish>] [--] <paths>... +'git checkout' [-q] [-f] [-m] [<branch>] +'git checkout' [-q] [-f] [-m] [-b <new_branch>] [<start_point>] +'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>... +'git checkout' --patch [<tree-ish>] [--] [<paths>...] DESCRIPTION ----------- When <paths> are not given, this command switches branches by -updating the index and working tree to reflect the specified -branch, <branch>, and updating HEAD to be <branch> or, if -specified, <new_branch>. Using -b will cause <new_branch> to -be created; in this case you can use the --track or --no-track -options, which will be passed to `git branch`. +updating the index, working tree, and HEAD to reflect the specified +branch. -When <paths> are given, this command does *not* switch +If `-b` is given, a new branch is created and checked out, as if +linkgit:git-branch[1] were called; in this case you can +use the --track or --no-track options, which will be passed to `git +branch`. As a convenience, --track without `-b` implies branch +creation; see the description of --track below. + +When <paths> or --patch are given, this command does *not* switch branches. It updates the named paths in the working tree from -the index file (i.e. it runs `git checkout-index -f -u`), or -from a named commit. In -this case, the `-f` and `-b` options are meaningless and giving -either of them results in an error. <tree-ish> argument can be +the index file, or from a named <tree-ish> (most often a commit). In +this case, the `-b` and `--track` options are meaningless and giving +either of them results in an error. The <tree-ish> argument can be used to specify a specific tree-ish (i.e. commit, tag or tree) to update the index for the given paths before updating the working tree. +The index may contain unmerged entries after a failed merge. By +default, if you try to check out such an entry from the index, the +checkout operation will fail and nothing will be checked out. +Using -f will ignore these unmerged entries. The contents from a +specific side of the merge can be checked out of the index by +using --ours or --theirs. With -m, changes made to the working tree +file can be discarded to recreate the original conflicted merge result. OPTIONS ------- -q:: +--quiet:: Quiet, suppress feedback messages. -f:: - Proceed even if the index or the working tree differs - from HEAD. This is used to throw away local changes. +--force:: + When switching branches, proceed even if the index or the + working tree differs from HEAD. This is used to throw away + local changes. ++ +When checking out paths from the index, do not fail upon unmerged +entries; instead, unmerged entries are ignored. + +--ours:: +--theirs:: + When checking out paths from the index, check out stage #2 + ('ours') or #3 ('theirs') for unmerged paths. -b:: Create a new branch named <new_branch> and start it at - <branch>. The new branch name must pass all checks defined - by linkgit:git-check-ref-format[1]. Some of these checks - may restrict the characters allowed in a branch name. + <start_point>; see linkgit:git-branch[1] for details. -t:: --track:: - When creating a new branch, set up configuration so that 'git-pull' - will automatically retrieve data from the start point, which must be - a branch. Use this if you always pull from the same upstream branch - into the new branch, and if you don't want to use "git pull - <repository> <refspec>" explicitly. This behavior is the default - when the start point is a remote branch. Set the - branch.autosetupmerge configuration variable to `false` if you want - 'git-checkout' and 'git-branch' to always behave as if '--no-track' were - given. Set it to `always` if you want this behavior when the - start-point is either a local or remote branch. + When creating a new branch, set up "upstream" configuration. See + "--track" in linkgit:git-branch[1] for details. ++ +If no '-b' option is given, the name of the new branch will be +derived from the remote branch. If "remotes/" or "refs/remotes/" +is prefixed it is stripped away, and then the part up to the +next slash (which would be the nickname of the remote) is removed. +This would tell us to use "hack" as the local branch when branching +off of "origin/hack" (or "remotes/origin/hack", or even +"refs/remotes/origin/hack"). If the given name has no slash, or the above +guessing results in an empty name, the guessing is aborted. You can +explicitly give a name with '-b' in such a case. --no-track:: - Ignore the branch.autosetupmerge configuration variable. + Do not set up "upstream" configuration, even if the + branch.autosetupmerge configuration variable is true. -l:: - Create the new branch's reflog. This activates recording of - all changes made to the branch ref, enabling use of date - based sha1 expressions such as "<branchname>@\{yesterday}". + Create the new branch's reflog; see linkgit:git-branch[1] for + details. -m:: - If you have local modifications to one or more files that +--merge:: + When switching branches, + if you have local modifications to one or more files that are different between the current branch and the branch to which you are switching, the command refuses to switch branches in order to preserve your modifications in context. @@ -81,20 +105,49 @@ When a merge conflict happens, the index entries for conflicting paths are left unmerged, and you need to resolve the conflicts and mark the resolved paths with `git add` (or `git rm` if the merge should result in deletion of the path). ++ +When checking out paths from the index, this option lets you recreate +the conflicted merge in the specified paths. + +--conflict=<style>:: + The same as --merge option above, but changes the way the + conflicting hunks are presented, overriding the + merge.conflictstyle configuration variable. Possible values are + "merge" (default) and "diff3" (in addition to what is shown by + "merge" style, shows the original contents). + +-p:: +--patch:: + Interactively select hunks in the difference between the + <tree-ish> (or the index, if unspecified) and the working + tree. The chosen hunks are then applied in reverse to the + working tree (and if a <tree-ish> was specified, the index). ++ +This means that you can use `git checkout -p` to selectively discard +edits from your current working tree. + +<branch>:: + Branch to checkout; if it refers to a branch (i.e., a name that, + when prepended with "refs/heads/", is a valid ref), then that + branch is checked out. Otherwise, if it refers to a valid + commit, your HEAD becomes "detached" and you are no longer on + any branch (see below for details). ++ +As a special case, the `"@\{-N\}"` syntax for the N-th last branch +checks out the branch (instead of detaching). You may also specify +`-` which is synonymous with `"@\{-1\}"`. <new_branch>:: Name for the new branch. +<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. -<branch>:: - Branch to checkout (when no paths are given); may be any object - ID that resolves to a commit. Defaults to HEAD. -+ -When this parameter names a non-branch (but still a valid commit object), -your HEAD becomes 'detached'. Detached HEAD @@ -110,12 +163,12 @@ $ git checkout v2.6.18 ------------ Earlier versions of git did not allow this and asked you to -create a temporary branch using `-b` option, but starting from +create a temporary branch using the `-b` option, but starting from version 1.5.0, the above command 'detaches' your HEAD from the -current branch and directly point at the commit named by the tag -(`v2.6.18` in the above example). +current branch and directly points at the commit named by the tag +(`v2.6.18` in the example above). -You can use usual git commands while in this state. You can use +You can use all git commands while in this state. You can use `git reset --hard $othercommit` to further move around, for example. You can make changes and create a new commit on top of a detached HEAD. You can even create a merge by using `git @@ -160,7 +213,7 @@ You should instead write: $ git checkout -- hello.c ------------ -. After working in a wrong branch, switching to the correct +. After working in the wrong branch, switching to the correct branch would be done using: + ------------ @@ -168,7 +221,7 @@ $ git checkout mytopic ------------ + However, your "wrong" branch and correct "mytopic" branch may -differ in files that you have locally modified, in which case, +differ in files that you have modified locally, in which case the above checkout would fail like this: + ------------ @@ -194,7 +247,6 @@ the `-m` option, you would see something like this: ------------ $ git checkout -m mytopic Auto-merging frotz -merge: warning: conflicts during merge ERROR: Merge conflict in frotz fatal: merge program failed ------------ diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt index 74d14c4e7f..7deefdae8f 100644 --- a/Documentation/git-cherry.txt +++ b/Documentation/git-cherry.txt @@ -7,7 +7,7 @@ git-cherry - Find commits not merged upstream SYNOPSIS -------- -'git cherry' [-v] <upstream> [<head>] [<limit>] +'git cherry' [-v] [<upstream> [<head> [<limit>]]] DESCRIPTION ----------- @@ -51,6 +51,7 @@ OPTIONS <upstream>:: Upstream branch to compare against. + Defaults to the first tracked remote branch, if available. <head>:: Working branch; defaults to HEAD. diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt index 8a114509f4..9d291bdd26 100644 --- a/Documentation/git-clean.txt +++ b/Documentation/git-clean.txt @@ -12,20 +12,27 @@ SYNOPSIS DESCRIPTION ----------- -Removes files unknown to git. This allows to clean the working tree -from files that are not under version control. If the '-x' option is -specified, ignored files are also removed, allowing to remove all -build products. + +Cleans the working tree by recursively removing files that are not +under version control, starting from the current directory. + +Normally, only files unknown to git are removed, but if the '-x' +option is specified, ignored files are also removed. This can, for +example, be useful to remove all build products. + If any optional `<path>...` arguments are given, only those paths are affected. - OPTIONS ------- -d:: Remove untracked directories in addition to untracked files. + If an untracked directory is managed by a different git + repository, it is not removed by default. Use -f option twice + if you really want to remove such a directory. -f:: +--force:: If the git configuration specifies clean.requireForce as true, 'git-clean' will refuse to run unless given -f or -n. diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index 307f2521b4..7ccd742a87 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -11,16 +11,17 @@ SYNOPSIS [verse] 'git clone' [--template=<template_directory>] [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] - [-o <name>] [-u <upload-pack>] [--reference <repository>] - [--depth <depth>] [--] <repository> [<directory>] + [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] + [--depth <depth>] [--recursive] [--] <repository> [<directory>] DESCRIPTION ----------- Clones a repository into a newly created directory, creates remote-tracking branches for each branch in the cloned repository -(visible using `git branch -r`), and creates and checks out an initial -branch equal to the cloned repository's currently active branch. +(visible using `git branch -r`), and creates and checks out an +initial branch that is forked from the cloned repository's +currently active branch. After the clone, a plain `git fetch` without arguments will update all the remote-tracking branches, and a `git pull` without @@ -38,7 +39,7 @@ OPTIONS --local:: -l:: When the repository to clone from is on a local machine, - this flag bypasses normal "git aware" transport + this flag bypasses the normal "git aware" transport mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under `.git/objects/` directory are hardlinked @@ -59,7 +60,7 @@ OPTIONS -s:: When the repository to clone is on the local machine, instead of using hard links, automatically setup - .git/objects/info/alternates to share the objects + `.git/objects/info/alternates` to share the objects with the source repository. The resulting repository starts out without any object of its own. + @@ -68,28 +69,41 @@ it unless you understand what it does. If you clone your repository using this option and then delete branches (or use any other git command that makes any existing commit unreferenced) in the source repository, some objects may become unreferenced (or dangling). -These objects may be removed by normal git operations (such as 'git-commit') +These objects may be removed by normal git operations (such as `git commit`) which automatically call `git gc --auto`. (See linkgit:git-gc[1].) If these objects are removed and were referenced by the cloned repository, then the cloned repository will become corrupt. - - ++ +Note that running `git repack` without the `-l` option in a repository +cloned with `-s` will copy objects from the source repository into a pack +in the cloned repository, removing the disk space savings of `clone -s`. +It is safe, however, to run `git gc`, which uses the `-l` option by +default. ++ +If you want to break the dependency of a repository cloned with `-s` on +its source repository, you can simply run `git repack -a` to copy all +objects from the source repository into a pack in the cloned repository. --reference <repository>:: - If the reference repository is on the local machine - automatically setup .git/objects/info/alternates to + If the reference repository is on the local machine, + automatically setup `.git/objects/info/alternates` to obtain objects from the reference repository. Using an already existing repository as an alternate will require fewer objects to be copied from the repository being cloned, reducing network and local storage costs. + -*NOTE*: see NOTE to --shared option. +*NOTE*: see the NOTE for the `--shared` option. --quiet:: -q:: Operate quietly. This flag is also passed to the `rsync' 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. @@ -107,12 +121,19 @@ then the cloned repository will become corrupt. configuration variables are created. --mirror:: - Set up a mirror of the remote repository. This implies --bare. + Set up a mirror of the remote repository. This implies `--bare`. --origin <name>:: -o <name>:: - Instead of using the remote name 'origin' to keep track - of the upstream repository, use <name>. + Instead of using the remote name `origin` to keep track + of the upstream repository, use `<name>`. + +--branch <name>:: +-b <name>:: + Instead of pointing the newly created HEAD to the branch pointed + to by the cloned repository's HEAD, point to `<name>` branch + instead. In a non-bare repository, this is the branch that will + be checked out. --upload-pack <upload-pack>:: -u <upload-pack>:: @@ -134,6 +155,14 @@ then the cloned repository will become corrupt. with a long history, and would want to send in fixes as patches. +--recursive:: + After the clone is created, initialize all submodules within, + using their default settings. This is equivalent to running + `git submodule update --init --recursive` immediately after + the clone is finished. This option is ignored if the cloned + repository does not have a worktree/checkout (i.e. if any of + `--no-checkout`/`-n`, `--bare`, or `--mirror` is given) + <repository>:: The (possibly remote) repository to clone from. See the <<URLS,URLS>> section below for more information on specifying @@ -142,9 +171,9 @@ then the cloned repository will become corrupt. <directory>:: The name of a new directory to clone into. The "humanish" part of the source repository is used if no directory is - explicitly given ("repo" for "/path/to/repo.git" and "foo" - for "host.xz:foo/.git"). Cloning into an existing directory - is not allowed. + explicitly given (`repo` for `/path/to/repo.git` and `foo` + for `host.xz:foo/.git`). Cloning into an existing directory + is only allowed if the directory is empty. :git-clone: 1 include::urls.txt[] diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 5cce3a3791..0578a40d84 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -8,7 +8,7 @@ git-commit - Record changes to the repository SYNOPSIS -------- [verse] -'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] +'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run] [(-c | -C) <commit>] [-F <file> | -m <msg>] [--allow-empty] [--no-verify] [-e] [--author=<author>] [--cleanup=<mode>] [--] [[-i | -o ]<file>...] @@ -29,7 +29,8 @@ The content to be added can be specified in several ways: 3. by listing files as arguments to the 'commit' command, in which case the commit will ignore changes staged in the index, and instead - record the current content of the listed files; + 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 @@ -41,10 +42,9 @@ The content to be added can be specified in several ways: by one which files should be part of the commit, before finalizing the operation. Currently, this is done by invoking 'git-add --interactive'. -The 'git-status' command can be used to obtain a +The `--dry-run` option can be used to obtain a summary of what is included by any of the above for the next -commit by giving the same set of parameters you would give to -this command. +commit by giving the same set of parameters (options and paths). If you make a commit and then find a mistake immediately after that, you can recover from it with 'git-reset'. @@ -75,8 +75,10 @@ OPTIONS read the message from the standard input. --author=<author>:: - Override the author name used in the commit. Use - `A U Thor <author@example.com>` format. + Override the author name used in the commit. You can use the + standard `A U Thor <author@example.com>` format. Otherwise, + an existing commit that matches the given string and its author + name is used. -m <msg>:: --message=<msg>:: @@ -143,6 +145,10 @@ It is a rough equivalent for: ------ but can be used to amend a merge commit. -- ++ +You should understand the implications of rewriting history if you +amend a commit that has already been published. (See the "RECOVERING +FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].) -i:: --include:: @@ -191,6 +197,11 @@ specified. --quiet:: Suppress commit summary message. +--dry-run:: + Do not create a commit, but show a list of paths that are + to be committed, paths with local changes that will be left + uncommitted and paths that are untracked. + \--:: Do not interpret any more arguments as options. diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index 19a8917b83..f68b198205 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -11,7 +11,7 @@ SYNOPSIS [verse] 'git config' [<file-option>] [type] [-z|--null] name [value [value_regex]] 'git config' [<file-option>] [type] --add name value -'git config' [<file-option>] [type] --replace-all name [value [value_regex]] +'git config' [<file-option>] [type] --replace-all name value [value_regex] 'git config' [<file-option>] [type] [-z|--null] --get name [value_regex] 'git config' [<file-option>] [type] [-z|--null] --get-all name [value_regex] 'git config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex] @@ -22,6 +22,7 @@ SYNOPSIS 'git config' [<file-option>] [-z|--null] -l | --list 'git config' [<file-option>] --get-color name [default] 'git config' [<file-option>] --get-colorbool name [stdout-is-tty] +'git config' [<file-option>] -e | --edit DESCRIPTION ----------- @@ -68,7 +69,8 @@ OPTIONS --add:: Adds a new line to the option without altering any existing - values. This is the same as providing '^$' as the value_regex. + values. This is the same as providing '^$' as the value_regex + in `--replace-all`. --get:: Get the value for a given key (optionally filtered by a regex @@ -130,6 +132,10 @@ See also <<FILES>>. 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 @@ -150,13 +156,18 @@ See also <<FILES>>. When the color setting for `name` is undefined, the command uses `color.ui` as fallback. ---get-color name default:: +--get-color name [default]:: Find the color configured for `name` (e.g. `color.diff.new`) and output it as the ANSI color escape sequence to the standard output. The optional `default` parameter is used instead, if there is no color configured for `name`. +-e:: +--edit:: + Opens an editor to modify the specified config file; either + '--system', '--global', or repository (default). + [[FILES]] FILES ----- diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt index 75a8da1ca9..6bc1c21e62 100644 --- a/Documentation/git-count-objects.txt +++ b/Documentation/git-count-objects.txt @@ -21,8 +21,9 @@ OPTIONS --verbose:: In addition to the number of loose objects and disk space consumed, it reports the number of in-pack - objects, number of packs, and number of objects that can be - removed by running `git prune-packed`. + objects, number of packs, disk space consumed by those packs, + and number of objects that can be removed by running + `git prune-packed`. Author diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt index 2da8588f4f..abaaf273bb 100644 --- a/Documentation/git-cvsexportcommit.txt +++ b/Documentation/git-cvsexportcommit.txt @@ -63,6 +63,10 @@ OPTIONS -u:: Update affected files from CVS repository before attempting export. +-k:: + Reverse CVS keyword expansion (e.g. $Revision: 1.2.3.4$ + becomes $Revision$) in working CVS checkout before applying patch. + -w:: Specify the location of the CVS checkout to use for the export. This option does not require GIT_DIR to be set before execution if the diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index b7a8c10b87..614e769f4e 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -24,6 +24,9 @@ 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 @@ -62,7 +65,7 @@ OPTIONS -r <remote>:: The git remote to import this CVS repository into. Moves all CVS branches into remotes/<remote>/<branch> - akin to the 'git-clone' "--use-separate-remote" option. + akin to the way 'git-clone' uses 'origin' by default. -o <branch-for-HEAD>:: When no remote is specified (via -r) the 'HEAD' branch @@ -164,6 +167,39 @@ If '-v' is specified, the script reports what it is doing. Otherwise, success is indicated the Unix way, i.e. by simply exiting with a zero exit status. +[[issues]] +ISSUES +------ +Problems related to timestamps: + + * If timestamps of commits in the cvs repository are not stable enough + to be used for ordering commits changes may show up in the wrong + order. + * If any files were ever "cvs import"ed more than once (e.g., import of + more than one vendor release) the HEAD contains the wrong content. + * If the timestamp order of different files cross the revision order + within the commit matching time window the order of commits may be + wrong. + +Problems related to branches: + + * Branches on which no commits have been made are not imported. + * All files from the branching point are added to a branch even if + never added in cvs. + * This applies to files added to the source branch *after* a daughter + branch was created: if previously no commit was made on the daughter + branch they will erroneously be added to the daughter branch in git. + +Problems related to tags: + +* Multiple tags on the same revision are not imported. + +If you suspect that any of these issues may apply to the repository you +want to import consider using these alternative tools which proved to be +more stable in practice: + +* cvs2git (part of cvs2svn), `http://cvs2svn.tigris.org` +* parsecvs, `http://cgit.freedesktop.org/~keithp/parsecvs` Author ------ diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt index 2172e1fedc..a85121c689 100644 --- a/Documentation/git-daemon.txt +++ b/Documentation/git-daemon.txt @@ -9,8 +9,9 @@ SYNOPSIS -------- [verse] 'git daemon' [--verbose] [--syslog] [--export-all] - [--timeout=n] [--init-timeout=n] [--strict-paths] - [--base-path=path] [--user-path | --user-path=path] + [--timeout=n] [--init-timeout=n] [--max-connections=n] + [--strict-paths] [--base-path=path] [--base-path-relaxed] + [--user-path | --user-path=path] [--interpolated-path=pathtemplate] [--reuseaddr] [--detach] [--pid-file=file] [--enable=service] [--disable=service] @@ -99,15 +100,19 @@ OPTIONS 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 ~user notation to be used in requests. When + Allow {tilde}user notation to be used in requests. When specified with no parameter, requests to - git://host/~alice/foo is taken as a request to access + git://host/{tilde}alice/foo is taken as a request to access 'foo' repository in the home directory of user `alice`. If `--user-path=path` is specified, the same request is taken as a request to access `path/foo` repository in @@ -265,6 +270,15 @@ selectively enable/disable services per repository:: ---------------------------------------------------------------- +ENVIRONMENT +----------- +'git-daemon' will set REMOTE_ADDR to the IP address of the client +that connected to it, if the IP address is available. REMOTE_ADDR will +be available in the environment of hooks called when +services are performed. + + + Author ------ Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt index 59a6fd17ab..2f97916781 100644 --- a/Documentation/git-describe.txt +++ b/Documentation/git-describe.txt @@ -18,6 +18,9 @@ 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 ------- @@ -26,11 +29,13 @@ OPTIONS --all:: Instead of using only the annotated tags, use any ref - found in `.git/refs/`. + found in `.git/refs/`. This option enables matching + any known branch, remote branch, or lightweight tag. --tags:: Instead of using only the annotated tags, use any tag - found in `.git/refs/tags`. + found in `.git/refs/tags`. This option enables matching + a lightweight (non-annotated) tag. --contains:: Instead of finding the tag that predates the commit, find @@ -39,7 +44,9 @@ OPTIONS --abbrev=<n>:: Instead of using the default 7 hexadecimal digits as the - abbreviated object name, use <n> digits. + abbreviated object name, use <n> digits, or as many digits + as needed to form a unique object name. An <n> of 0 + will suppress long format, only showing the closest tag. --candidates=<n>:: Instead of considering only the 10 most recent tags as @@ -63,8 +70,8 @@ OPTIONS This is useful when you want to see parts of the commit object name in "describe" output, even when the commit in question happens to be a tagged version. Instead of just emitting the tag name, it will - describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2 - that points at object deadbeef....). + describe such a commit as v1.2-0-gdeadbee (0th commit since tag v1.2 + that points at object deadbee....). --match <pattern>:: Only consider tags matching the given pattern (can be used to avoid @@ -82,7 +89,7 @@ With something like git.git current tree, I get: v1.0.4-14-g2414721 i.e. the current head of my "parent" branch is based on v1.0.4, -but since it has a handful commits on top of that, +but since it has a few commits on top of that, describe has added the number of additional commits ("14") and an abbreviated object name for the commit itself ("2414721") at the end. @@ -103,7 +110,7 @@ the output shows the reference path as well: [torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2 tags/v1.0.0-21-g975b - [torvalds@g5 git]$ git describe --all HEAD^ + [torvalds@g5 git]$ git describe --all --abbrev=4 HEAD^ heads/lt/describe-7-g975b With --abbrev set to 0, the command can be used to find the @@ -112,6 +119,13 @@ 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 --------------- diff --git a/Documentation/git-diff-files.txt b/Documentation/git-diff-files.txt index c526141564..4ef03578eb 100644 --- a/Documentation/git-diff-files.txt +++ b/Documentation/git-diff-files.txt @@ -43,8 +43,7 @@ omit diff output for unmerged entries and just show "Unmerged". -q:: Remain silent even on nonexistent files -Output format -------------- + include::diff-format.txt[] diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt index 26920d4f63..8b9ed29299 100644 --- a/Documentation/git-diff-index.txt +++ b/Documentation/git-diff-index.txt @@ -34,8 +34,6 @@ include::diff-options.txt[] 'git-diff-index' say that all non-checked-out files are up to date. -Output format -------------- include::diff-format.txt[] Operating Modes diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt index 4e83067c4a..f2cef1260b 100644 --- a/Documentation/git-diff-tree.txt +++ b/Documentation/git-diff-tree.txt @@ -49,13 +49,22 @@ include::diff-options.txt[] --stdin:: When '--stdin' is specified, the command does not take <tree-ish> arguments from the command line. Instead, it - reads either one <commit> or a list of <commit> - separated with a single space from its standard input. + reads lines containing either two <tree>, one <commit>, or a + list of <commit> from its standard input. (Use a single space + as separator.) + -When a single commit is given on one line of such input, it compares -the commit with its parents. The following flags further affects its -behavior. The remaining commits, when given, are used as if they are +When two trees are given, it compares the first tree with the second. +When a single commit is given, it compares the commit with its +parents. The remaining commits, when given, are used as if they are parents of the first commit. ++ +When comparing two trees, the ID of both trees (separated by a space +and terminated by a newline) is printed before the difference. When +comparing commits, the ID of the first (or only) commit, followed by a +newline, is printed. ++ +The following flags further affect the behavior when comparing +commits (but not trees). -m:: By default, 'git-diff-tree --stdin' does not show @@ -150,8 +159,7 @@ HEAD commits it finds, which is even more interesting. in case you care). -Output format -------------- + include::diff-format.txt[] diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index c53eba557d..0ac711230e 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -33,6 +33,7 @@ forced by --no-index. commit relative to the named <commit>. Typically you would want comparison with the latest commit, so if you do not give <commit>, it defaults to HEAD. + --staged is a synonym of --cached. 'git diff' [--options] <commit> [--] [<path>...]:: @@ -83,8 +84,7 @@ include::diff-options.txt[] the diff to the named paths (you can give directory names and get diff for all files under them). -Output format -------------- + include::diff-format.txt[] EXAMPLES diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt new file mode 100644 index 0000000000..96a6c51a4b --- /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 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 index 539decbeb2..75b06f33e7 100644 --- a/Documentation/git-fast-export.txt +++ b/Documentation/git-fast-export.txt @@ -15,7 +15,7 @@ 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 +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'. @@ -36,6 +36,17 @@ when encountering a signed tag. With 'strip', the tags will be made unsigned, with 'verbatim', they will be silently exported and with 'warn', they will be exported, but you will see a warning. +--tag-of-filtered-object=(abort|drop|rewrite):: + Specify how to handle tags whose tagged 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 @@ -71,6 +82,20 @@ marks the same across runs. 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 -------- diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt index d3164c5c88..f2483d624e 100644 --- a/Documentation/git-fetch.txt +++ b/Documentation/git-fetch.txt @@ -37,6 +37,35 @@ 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] diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 7747c4877d..2b40babb6b 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -12,6 +12,7 @@ SYNOPSIS [--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>...] @@ -39,7 +40,9 @@ 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. +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 @@ -92,7 +95,9 @@ OPTIONS --index-filter <command>:: This is the filter for rewriting the index. It is similar to the tree filter but does not check out the tree, which makes it much - faster. For hairy cases, see linkgit:git-update-index[1]. + 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. @@ -123,6 +128,10 @@ 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, @@ -152,6 +161,16 @@ to other tags will be rewritten to point to the underlying commit. The result will contain that directory (and only that) as its project root. +--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'. @@ -191,10 +210,14 @@ 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. -A significantly faster version: +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 filename' HEAD +git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD -------------------------------------------------------------------------- Now, you will get the rewritten history saved in HEAD. @@ -283,6 +306,16 @@ 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 @@ -321,6 +354,47 @@ git filter-branch --index-filter \ --------------------------------------------------------------- + +Checklist for Shrinking a Repository +------------------------------------ + +git-filter-branch is often used to get rid of a subset of files, +usually with some combination of `\--index-filter` and +`\--subdirectory-filter`. People expect the resulting repository to +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>, diff --git a/Documentation/git-fmt-merge-msg.txt b/Documentation/git-fmt-merge-msg.txt index 1c24796d66..a586950b48 100644 --- a/Documentation/git-fmt-merge-msg.txt +++ b/Documentation/git-fmt-merge-msg.txt @@ -18,8 +18,8 @@ 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 script is intended mostly for internal use by scripts -automatically invoking 'git-merge'. +This command is intended mostly for internal use by scripts +automatically invoking 'git merge'. OPTIONS ------- diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index ebd7c5fbb3..8dc873fd44 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -74,6 +74,9 @@ 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`). @@ -84,6 +87,11 @@ objectsize:: 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. diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 7426109f62..687e667598 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -9,9 +9,10 @@ git-format-patch - Prepare patches for e-mail submission SYNOPSIS -------- [verse] -'git format-patch' [-k] [-o <dir> | --stdout] [--thread] - [--attach[=<boundary>] | --inline[=<boundary>]] - [-s | --signoff] [<common diff options>] +'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>] @@ -19,6 +20,7 @@ SYNOPSIS [--subject-prefix=Subject-Prefix] [--cc=<email>] [--cover-letter] + [<common diff options>] [ <since> | <revision range> ] DESCRIPTION @@ -39,15 +41,11 @@ There are two ways to specify which commits to operate on. REVISIONS" section in linkgit:git-rev-parse[1]) means the commits in the specified range. -A single commit, when interpreted as a <revision range> -expression, means "everything that leads to that commit", but -if you write 'git format-patch <commit>', the previous rule -applies to that command line and you do not get "everything -since the beginning of the time". If you want to format -everything since project inception to one commit, say "git -format-patch \--root <commit>" to make it clear that it is the -latter case. If you want to format a single commit, you can do -this with "git format-patch -1 <commit>". +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 @@ -59,8 +57,10 @@ 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. -If -n is specified, instead of "[PATCH] Subject", the first line -is formatted as "[PATCH n/m] Subject". +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 @@ -82,7 +82,7 @@ include::diff-options.txt[] -n:: --numbered:: - Name output in '[PATCH n/m]' format. + Name output in '[PATCH n/m]' format, even with a single patch. -N:: --no-numbered:: @@ -94,7 +94,6 @@ include::diff-options.txt[] --numbered-files:: Output file names will be a simple number sequence without the default first line of the commit appended. - Mutually exclusive with the --stdout option. -k:: --keep-subject:: @@ -115,15 +114,35 @@ include::diff-options.txt[] 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:: - Add In-Reply-To and References headers to make the second and - subsequent mails appear as replies to the first. Also generates - the Message-Id header to reference. +--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 hreading, 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 @@ -147,6 +166,11 @@ include::diff-options.txt[] 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 @@ -155,24 +179,31 @@ include::diff-options.txt[] --suffix=.<sfx>:: Instead of using `.patch` as the suffix for generated filenames, use specified suffix. A common alternative is - `--suffix=.txt`. + `--suffix=.txt`. Leaving this empty will remove the `.patch` + suffix. + -Note that you would need to include the leading dot `.` if you -want a filename like `0001-description-of-my-change.patch`, and -the first letter does not have to be a dot. Leaving it empty would -not add any 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:: - Don't output contents of changes in binary files, just take note - that they differ. Note that this disable the patch to be properly - applied. By default the contents of changes in those files are - encoded in the patch. + 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 -in the repository configuration, new defaults for the subject prefix -and file suffix, and number patches when outputting more than one. +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] @@ -181,6 +212,8 @@ and file suffix, and number patches when outputting more than one. suffix = .txt numbered = auto cc = <email> + attach [ = mime-boundary-string ] + signoff = true ------------ @@ -218,8 +251,8 @@ $ git format-patch -M -B origin + Additionally, it detects and handles renames and complete rewrites intelligently to produce a renaming patch. A renaming patch reduces -the amount of text output, and generally makes it easier to review it. -Note that the "patch" program does not understand renaming patches, so +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 diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index 7086eea74a..4cd9cdf905 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository SYNOPSIS -------- -'git gc' [--aggressive] [--auto] [--quiet] +'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] DESCRIPTION ----------- @@ -59,6 +59,14 @@ 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. @@ -98,7 +106,7 @@ 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 10. +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 @@ -112,7 +120,7 @@ Notes 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 references commits in branches +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 diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt index fa4d133c1b..8c700200f5 100644 --- a/Documentation/git-grep.txt +++ b/Documentation/git-grep.txt @@ -15,7 +15,10 @@ SYNOPSIS [-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>...] @@ -45,6 +48,10 @@ OPTIONS -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 @@ -94,11 +101,23 @@ OPTIONS 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 @@ -108,6 +127,14 @@ OPTIONS -<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. diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt index 0e650f497b..d0bc98b852 100644 --- a/Documentation/git-gui.txt +++ b/Documentation/git-gui.txt @@ -65,9 +65,28 @@ git gui blame v0.99.8 Makefile:: 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:: diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt index ac928e198e..0af40cfb85 100644 --- a/Documentation/git-hash-object.txt +++ b/Documentation/git-hash-object.txt @@ -8,7 +8,9 @@ git-hash-object - Compute object ID and optionally creates a blob from a file SYNOPSIS -------- -'git hash-object' [-t <type>] [-w] [--stdin | --stdin-paths] [--] <file>... +[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 ----------- @@ -35,6 +37,22 @@ OPTIONS --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> diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt index f414583fc4..d9b9c34b3a 100644 --- a/Documentation/git-help.txt +++ b/Documentation/git-help.txt @@ -112,7 +112,9 @@ For example, this configuration: 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 the 'man' program will be tried anyway. +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 ~~~~~~~~~~~~~~~ diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt index b3d8da33ee..d016dafd49 100644 --- a/Documentation/git-imap-send.txt +++ b/Documentation/git-imap-send.txt @@ -3,7 +3,7 @@ git-imap-send(1) NAME ---- -git-imap-send - Dump a mailbox from stdin into an imap folder +git-imap-send - Send a collection of patches from stdin to an IMAP folder SYNOPSIS @@ -13,9 +13,9 @@ SYNOPSIS 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 sent with mail clients that cannot read mailbox +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: @@ -26,24 +26,99 @@ git format-patch --signoff --stdout --attach origin | git imap-send CONFIGURATION ------------- -'git-imap-send' requires the following values in the repository -configuration file (shown with examples): +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" + folder = "INBOX.Drafts" + tunnel = "ssh -q -C user@example.com /usr/bin/imapd ./Maildir 2> /dev/null" +.......................... +Using direct mode: + +......................... [imap] - Tunnel = "ssh -q user@server.com /usr/bin/imapd ./Maildir 2> /dev/null" + folder = "INBOX.Drafts" + host = imap://imap.example.com + user = bob + pass = p4ssw0rd +.......................... +Using direct mode with SSL: + +......................... [imap] - Host = imap.server.com - User = bob - Pass = pwd - Port = 143 + 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. diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt index 1fd0ff2610..eba3cb4998 100644 --- a/Documentation/git-init-db.txt +++ b/Documentation/git-init-db.txt @@ -8,7 +8,7 @@ git-init-db - Creates an empty git repository SYNOPSIS -------- -'git init-db' [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]] +'git init-db' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]] DESCRIPTION diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index 71749c09d3..f081b24d9d 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -8,7 +8,7 @@ git-init - Create an empty git repository or reinitialize an existing one SYNOPSIS -------- -'git init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]] +'git init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]] [directory] OPTIONS @@ -54,20 +54,29 @@ is given: - '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' - Any option except 'umask' can be set using this option. '0xxx' will - override users umask(2) value, and thus, users with a safe umask (0077) - can use this option. '0640' will create a repository which is group-readable - but not writable. '0660' is equivalent to 'group'. + - '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). + -- diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt index 22da21a54f..0771f25443 100644 --- a/Documentation/git-instaweb.txt +++ b/Documentation/git-instaweb.txt @@ -29,7 +29,7 @@ OPTIONS 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 lighttpd, apache2 and webrick are supported. + Currently apache2, lighttpd, mongoose and webrick are supported. (Default: lighttpd) -m:: diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 93a2a227c4..3d79de11ec 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -37,8 +37,16 @@ include::diff-options.txt[] and <until>, see "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. ---decorate:: - Print out the ref names of any commits that are shown. +--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 diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt index 9f85d60b5f..625723e41f 100644 --- a/Documentation/git-ls-files.txt +++ b/Documentation/git-ls-files.txt @@ -44,12 +44,14 @@ OPTIONS -o:: --others:: - Show other files in the output + Show other (i.e. untracked) files in the output -i:: --ignored:: - Show ignored files in the output. - Note that this also reverses any exclude list present. + 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:: @@ -126,7 +128,7 @@ OPTIONS --abbrev[=<n>]:: Instead of showing the full 40-byte hexadecimal object - lines, show only handful hexdigits prefix. + lines, show only a partial prefix. Non default number of digits can be specified with --abbrev=<n>. \--:: diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt index 3f87d7266b..c3fdccb4c2 100644 --- a/Documentation/git-ls-tree.txt +++ b/Documentation/git-ls-tree.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git ls-tree' [-d] [-r] [-t] [-l] [-z] - [--name-only] [--name-status] [--full-name] [--abbrev=[<n>]] + [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev=[<n>]] <tree-ish> [paths...] DESCRIPTION @@ -30,6 +30,8 @@ in the current working directory. Note that: '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 ------- @@ -59,13 +61,17 @@ OPTIONS --abbrev[=<n>]:: Instead of showing the full 40-byte hexadecimal object - lines, show only handful hexdigits prefix. + 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 diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt index 8d95aaa304..996c3fcc6c 100644 --- a/Documentation/git-mailinfo.txt +++ b/Documentation/git-mailinfo.txt @@ -8,7 +8,7 @@ git-mailinfo - Extracts patch and authorship from a single e-mail message SYNOPSIS -------- -'git mailinfo' [-k] [-u | --encoding=<encoding> | -n] <msg> <patch> +'git mailinfo' [-k] [-u | --encoding=<encoding> | -n] [--scissors] <msg> <patch> DESCRIPTION @@ -49,6 +49,25 @@ conversion, even with this flag. -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. diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt index 1a7ecbf8f3..ce5b369985 100644 --- a/Documentation/git-merge-base.txt +++ b/Documentation/git-merge-base.txt @@ -8,26 +8,85 @@ git-merge-base - Find as good common ancestors as possible for a merge SYNOPSIS -------- -'git merge-base' [--all] <commit> <commit> +'git merge-base' [-a|--all] <commit> <commit>... DESCRIPTION ----------- -'git-merge-base' finds as good a common ancestor as possible between -the two commits. That is, 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. +'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. -Given a selection of equally good common ancestors it should not be -relied on to decide in any particular way. +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. -The 'git-merge-base' algorithm is still in flux - use the source... +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 common ancestors for the two commits instead of - just one. + 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 ------ diff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt index 024ec015a3..303537357b 100644 --- a/Documentation/git-merge-file.txt +++ b/Documentation/git-merge-file.txt @@ -15,17 +15,17 @@ SYNOPSIS DESCRIPTION ----------- -'git-file-merge' incorporates all changes that lead from the `<base-file>` +'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. +`<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 <<<<<<< and ->>>>>>> lines. A typical conflict will look like this: +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 @@ -60,7 +60,7 @@ OPTIONS `<current-file>`. -q:: - Quiet; do not warn about conflicts. + Quiet; do not warn about conflicts. EXAMPLES diff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt index ff088c5c29..123e6d024a 100644 --- a/Documentation/git-merge-index.txt +++ b/Documentation/git-merge-index.txt @@ -29,11 +29,11 @@ OPTIONS 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 are over. + merges. -q:: - Do not complain about failed merge program (the merge program - failure usually indicates conflicts during merge). This is for + 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 diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt index dbb0c18668..f869a7f00f 100644 --- a/Documentation/git-merge-tree.txt +++ b/Documentation/git-merge-tree.txt @@ -14,14 +14,14 @@ DESCRIPTION ----------- Reads three treeish, and output trivial merge results and conflicting stages to the standard output. This is similar to -what three-way read-tree -m does, but instead of storing the +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 index, and stuff the results back into the +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 <branch1> tree. +entries that match the <branch1> tree. Author ------ diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 17a15acb07..e886c2ef54 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]... - [-m <msg>] <remote> <remote>... + [-m <msg>] <remote>... 'git merge' <msg> HEAD <remote>... DESCRIPTION @@ -28,9 +28,10 @@ OPTIONS include::merge-options.txt[] -m <msg>:: - The commit message to be used for the merge commit (in case - it is created). The 'git-fmt-merge-msg' script can be used - to give a good default for automated 'git-merge' invocations. + 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 @@ -40,8 +41,8 @@ include::merge-options.txt[] include::merge-strategies.txt[] -If you tried a merge which resulted in a complex conflicts and -would want to start over, you can recover with 'git-reset'. +If you tried a merge which resulted in complex conflicts and +want to start over, you can recover with 'git-reset'. CONFIGURATION ------------- @@ -49,8 +50,8 @@ include::merge-config.txt[] branch.<name>.mergeoptions:: Sets default options for merging into branch <name>. The syntax and - supported options are equal to that of 'git-merge', but option values - containing whitespace characters are currently not supported. + supported options are the same as those of 'git merge', but option + values containing whitespace characters are currently not supported. HOW MERGE WORKS --------------- @@ -69,20 +70,20 @@ Three kinds of merge can happen: simplest case, called "Already up-to-date." * `HEAD` is already contained in the merged commit. This is the - most common case especially when involved through 'git pull': - you are tracking an upstream repository, committed no local + 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 at point the merged + 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 them both as its parents. + 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 cleanly merge, these things happen: +When things merge cleanly, this is what happens: 1. The results are updated both in the index file and in your working tree; @@ -91,16 +92,16 @@ When things cleanly merge, these things happen: 4. The `HEAD` pointer gets advanced. Because of 2., we require that the original state of the index -file to match exactly the current `HEAD` commit; otherwise we +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 the paths different between your +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, these things happen: +When there are conflicts, the following happens: 1. `HEAD` stays the same. @@ -111,27 +112,137 @@ When there are conflicts, these things happen: 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 have the result of "merge" program; i.e. 3-way - merge result with familiar conflict markers `<<< === >>>`. + 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-up you need are to reset + * 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 diff` would report only the - conflicting paths because of the above 2. and 3. - Edit the working tree files into a desirable shape - ('git mergetool' can ease this task), 'git-add' or 'git-rm' - them, to make the index file contain what the merge result - should be, and run 'git-commit' to commit the result. + * 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 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 index e0b2703b38..68ed6c0956 100644 --- a/Documentation/git-mergetool.txt +++ b/Documentation/git-mergetool.txt @@ -7,7 +7,7 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts SYNOPSIS -------- -'git mergetool' [--tool=<tool>] [<file>]... +'git mergetool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<file>]... DESCRIPTION ----------- @@ -22,10 +22,12 @@ with merge conflicts. OPTIONS ------- --t or --tool=<tool>:: +-t <tool>:: +--tool=<tool>:: Use the merge resolution program specified by <tool>. Valid merge tools are: - kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff + kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, + diffuse, tortoisemerge, opendiff and araxis. + If a merge resolution program is not specified, 'git-mergetool' will use the configuration variable `merge.tool`. If the @@ -38,7 +40,7 @@ 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 +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`. @@ -55,11 +57,21 @@ 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 +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> diff --git a/Documentation/git-mktree.txt b/Documentation/git-mktree.txt index af19f06ed7..81e3326772 100644 --- a/Documentation/git-mktree.txt +++ b/Documentation/git-mktree.txt @@ -8,12 +8,13 @@ git-mktree - Build a tree-object from ls-tree formatted text SYNOPSIS -------- -'git mktree' [-z] +'git mktree' [-z] [--missing] [--batch] DESCRIPTION ----------- -Reads standard input in non-recursive `ls-tree` output format, -and creates a tree object. The object name of the tree object +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 @@ -21,6 +22,18 @@ 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> diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt index 9c5660275b..bdcb58526e 100644 --- a/Documentation/git-mv.txt +++ b/Documentation/git-mv.txt @@ -28,6 +28,7 @@ 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 diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt index 7d4c1a7556..f54d433d36 100644 --- a/Documentation/git-pack-objects.txt +++ b/Documentation/git-pack-objects.txt @@ -9,9 +9,11 @@ git-pack-objects - Create a packed archive of objects SYNOPSIS -------- [verse] -'git pack-objects' [-q] [--no-reuse-delta] [--delta-base-offset] [--non-empty] - [--local] [--incremental] [--window=N] [--depth=N] [--all-progress] - [--revs [--unpacked | --all]*] [--stdout | base-name] < object-list +'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 @@ -136,7 +138,7 @@ base-name:: --all-progress:: When --stdout is specified then progress report is - displayed during the object count and deltification phases + 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 @@ -145,6 +147,11 @@ base-name:: 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. @@ -197,6 +204,10 @@ base-name:: 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 ------ diff --git a/Documentation/git-pack-refs.txt b/Documentation/git-pack-refs.txt index a5244d35f4..1ee99c208c 100644 --- a/Documentation/git-pack-refs.txt +++ b/Documentation/git-pack-refs.txt @@ -26,7 +26,7 @@ problem by stashing the refs in a single file, traditional `$GIT_DIR/refs` hierarchy, it is looked up in this file and used if found. -Subsequent updates to branches always creates new file under +Subsequent updates to branches always create new files under `$GIT_DIR/refs` hierarchy. A recommended practice to deal with a repository with too many @@ -35,7 +35,7 @@ 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 next `pack-refs` (without `--all`) will leave them +and the next `pack-refs` (without `--all`) will leave them unpacked. diff --git a/Documentation/git-parse-remote.txt b/Documentation/git-parse-remote.txt index cd43069874..39d9daa7e0 100644 --- a/Documentation/git-parse-remote.txt +++ b/Documentation/git-parse-remote.txt @@ -17,26 +17,6 @@ routines to parse files under $GIT_DIR/remotes/ and $GIT_DIR/branches/ and configuration variables that are related to fetching, pulling and pushing. -The primary entry points are: - -get_remote_refs_for_fetch:: - Given the list of user-supplied `<repo> <refspec>...`, - return the list of refs to fetch after canonicalizing - them into `$GIT_DIR` relative paths - (e.g. `refs/heads/foo`). When `<refspec>...` is empty - the returned list of refs consists of the defaults - for the given `<repo>`, if specified in - `$GIT_DIR/remotes/`, `$GIT_DIR/branches/`, or `remote.*.fetch` - configuration. - -get_remote_refs_for_push:: - Given the list of user-supplied `<repo> <refspec>...`, - return the list of refs to push in a form suitable to be - fed to the 'git-send-pack' command. When `<refspec>...` - is empty the returned list of refs consists of the - defaults for the given `<repo>`, if specified in - `$GIT_DIR/remotes/`. - Author ------ Written by Junio C Hamano. diff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt index 477785e134..253fc0fc25 100644 --- a/Documentation/git-patch-id.txt +++ b/Documentation/git-patch-id.txt @@ -20,7 +20,7 @@ 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 string. The first +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. diff --git a/Documentation/git-prune-packed.txt b/Documentation/git-prune-packed.txt index b5f26cee13..abfc6b6ead 100644 --- a/Documentation/git-prune-packed.txt +++ b/Documentation/git-prune-packed.txt @@ -8,7 +8,7 @@ git-prune-packed - Remove extra objects that are already in pack files SYNOPSIS -------- -'git prune-packed' [-n] [-q] +'git prune-packed' [-n|--dry-run] [-q|--quiet] DESCRIPTION @@ -28,10 +28,12 @@ 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 diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt index 54f1dab38d..da6055d4b8 100644 --- a/Documentation/git-prune.txt +++ b/Documentation/git-prune.txt @@ -8,7 +8,7 @@ git-prune - Prune all unreachable objects from the object database SYNOPSIS -------- -'git-prune' [-n] [--expire <expire>] [--] [<head>...] +'git-prune' [-n] [-v] [--expire <expire>] [--] [<head>...] DESCRIPTION ----------- @@ -34,6 +34,9 @@ OPTIONS Do not remove anything; just report what it would remove. +-v:: + Report all removed objects. + \--:: Do not interpret any more arguments as options. diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index 7578623edb..b93201158f 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -26,6 +26,10 @@ Also note that options meant for 'git-pull' itself and underlying OPTIONS ------- + +Options related to merging +~~~~~~~~~~~~~~~~~~~~~~~~~~ + include::merge-options.txt[] :git-pull: 1 @@ -47,6 +51,9 @@ 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[] @@ -131,54 +138,13 @@ $ git pull origin next ------------------------------------------------ + This leaves a copy of `next` temporarily in FETCH_HEAD, but -does not update any remote-tracking branches. - -* Bundle local branch `fixes` and `enhancements` on top of - the current branch, making an Octopus merge: -+ ------------------------------------------------- -$ git pull . fixes enhancements ------------------------------------------------- -+ -This `git pull .` syntax is equivalent to `git merge`. - -* Merge local branch `obsolete` into the current branch, using `ours` - merge strategy: -+ ------------------------------------------------- -$ git pull -s ours . obsolete ------------------------------------------------- - -* Merge local branch `maint` into the current branch, but do not make - a commit automatically: +does not update any remote-tracking branches. Using remote-tracking +branches, the same can be done by invoking fetch and merge: + ------------------------------------------------ -$ git pull --no-commit . maint +$ git fetch origin +$ git merge origin/next ------------------------------------------------ -+ -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. - -* Command line pull of multiple branches from one repository: -+ ------------------------------------------------- -$ git checkout master -$ git fetch origin +pu:pu maint:tmp -$ git pull . 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; -the others will not be. -+ -The final command then merges the newly fetched `tmp` into master. If you tried a pull which resulted in a complex conflicts and diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 6150b1b959..37c88953d1 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects SYNOPSIS -------- [verse] -'git push' [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] +'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v | --verbose] [<repository> <refspec>...] @@ -24,40 +24,45 @@ every time you push into it, by setting up 'hooks' there. See documentation for linkgit:git-receive-pack[1]. -OPTIONS -------- +OPTIONS[[OPTIONS]] +------------------ <repository>:: The "remote" repository that is destination of a push - operation. See the section <<URLS,GIT URLS>> below. + 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 canonical format of a <refspec> parameter is - `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed - by the source ref, followed by a colon `:`, followed by - the destination ref. + 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> side represents the source branch (or arbitrary -"SHA1 expression", such as `master~4` (four parents before the -tip of `master` branch); see linkgit:git-rev-parse[1]) that you -want to push. The <dst> side represents the destination location. +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 local ref that matches <src> is used -to fast forward the remote ref that matches <dst> (or, if no <dst> was -specified, the same ref that <src> referred to locally). If -the optional leading plus `+` is used, the remote ref is updated -even if it does not result in a fast forward update. +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. + -`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`. +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. + -A parameter <ref> without a colon pushes the <ref> from the source -repository to the destination repository under the same name. +`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 `+:` to allow non-fast forward updates) -directs git to push "matching" heads: for every head that exists on -the local side, the remote side is updated if a head of the same name +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). @@ -77,23 +82,27 @@ nor in any Push line of the corresponding remotes file---see below). 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. ---exec=<git-receive-pack>:: - Same as \--receive-pack=<git-receive-pack>. - -f:: --force:: Usually, the command refuses to update a remote ref that is @@ -129,6 +138,11 @@ useful if you write an alias or script around 'git-push'. --verbose:: Run verbosely. +-q:: +--quiet:: + Suppress all output, including the listing of updated refs, + unless an error occurs. + include::urls-remotes.txt[] OUTPUT @@ -145,6 +159,12 @@ 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 @@ -181,9 +201,117 @@ reason:: 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 @@ -191,9 +319,9 @@ git push origin master:: with it. If `master` did not exist remotely, it would be created. -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 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`) @@ -201,6 +329,11 @@ git push origin master:satellite/master dev:satellite/dev:: `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 @@ -208,6 +341,35 @@ git push origin master:refs/heads/experimental:: 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 diff --git a/Documentation/git-quiltimport.txt b/Documentation/git-quiltimport.txt index d4037de512..579e8d2f3b 100644 --- a/Documentation/git-quiltimport.txt +++ b/Documentation/git-quiltimport.txt @@ -9,7 +9,7 @@ git-quiltimport - Applies a quilt patchset onto the current branch SYNOPSIS -------- [verse] -'git quiltimport' [--dry-run] [--author <author>] [--patches <dir>] +'git quiltimport' [--dry-run | -n] [--author <author>] [--patches <dir>] DESCRIPTION diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt index 309deac23b..4a932b08c6 100644 --- a/Documentation/git-read-tree.txt +++ b/Documentation/git-read-tree.txt @@ -8,7 +8,10 @@ git-read-tree - Reads tree information into the index SYNOPSIS -------- -'git read-tree' (<tree-ish> | [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] [--index-output=<file>] <tree-ish1> [<tree-ish2> [<tree-ish3>]]) +'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 @@ -212,7 +215,7 @@ 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 swiching to a new branch. That however will prevent +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. diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 59c1b021a6..0aefc34d0d 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -8,10 +8,11 @@ git-rebase - Forward-port local commits to the updated upstream head SYNOPSIS -------- [verse] -'git rebase' [-i | --interactive] [-v | --verbose] [-m | --merge] - [-s <strategy> | --strategy=<strategy>] - [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges] - [--onto <newbase>] <upstream> [<branch>] +'git rebase' [-i | --interactive] [options] [--onto <newbase>] + <upstream> [<branch>] +'git rebase' [-i | --interactive] [options] --onto <newbase> + --root [<branch>] + 'git rebase' --continue | --skip | --abort DESCRIPTION @@ -22,7 +23,8 @@ 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`. +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 @@ -92,7 +94,7 @@ 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 feature developed in 'topic' depends on some +For example, a feature developed in 'topic' depends on some functionality which is found in 'next'. ------------ @@ -103,9 +105,9 @@ functionality which is found in 'next'. o---o---o topic ------------ -We would want to make 'topic' forked from branch 'master', -for example because the functionality 'topic' branch depend on -got merged into more stable 'master' branch, like this: +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 @@ -190,6 +192,13 @@ 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>:: @@ -222,15 +231,29 @@ OPTIONS -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. + Use the given merge strategy. 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). This implies --merge. +-q:: +--quiet:: + Be quiet. Implies --no-stat. + -v:: --verbose:: - Display a diffstat of what changed upstream since the last rebase. + 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 @@ -238,9 +261,23 @@ OPTIONS context exist they all must match. By default no context is ever ignored. ---whitespace=<nowarn|warn|error|error-all|strip>:: - This flag is passed to the 'git-apply' program +-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:: @@ -250,18 +287,25 @@ OPTIONS -p:: --preserve-merges:: - Instead of ignoring merges, try to recreate them. This option - only works in interactive mode. + 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 ----- -When you rebase a branch, you are changing its history in a way that -will cause problems for anyone who already has a copy of the branch -in their repository and tries to pull updates from you. You should -understand the implications of using 'git-rebase' on a repository that -you share. + +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 @@ -396,6 +440,127 @@ consistent (they compile, pass the testsuite, etc.) you should use 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 diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt new file mode 100644 index 0000000000..173ee232f2 --- /dev/null +++ b/Documentation/git-remote-helpers.txt @@ -0,0 +1,71 @@ +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. + +'fetch' <sha1> <name>:: + Fetches the given object, writing the necessary objects to the + database. Outputs a blank line when the fetch is + complete. Only objects which were reported in the ref list + with a sha1 may be fetched this way. ++ +Supported if the helper has the "fetch" 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. + +REF LIST ATTRIBUTES +------------------- + +None are defined yet, but the caller must accept any which are supplied. + +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 index bb99810ec7..c272c92d4b 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -11,10 +11,12 @@ 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 show' [-n] <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 update' [group] +'git remote' [-v | --verbose] 'update' [-p | --prune] [group | remote]... DESCRIPTION ----------- @@ -28,6 +30,7 @@ OPTIONS -v:: --verbose:: Be a little more verbose and show remote url after name. + NOTE: This must be placed between `remote` and `subcommand`. COMMANDS @@ -52,8 +55,7 @@ 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 instead of whatever -branch the `HEAD` at the remote repository actually points at. +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 @@ -61,11 +63,44 @@ 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>. @@ -80,17 +115,19 @@ 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 no +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 get used; if +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 diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt index aaa8852629..c9257a10c9 100644 --- a/Documentation/git-repack.txt +++ b/Documentation/git-repack.txt @@ -31,11 +31,14 @@ OPTIONS 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 and there is no need to worry - about people fetching via dumb protocols from it. Use + 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 diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt new file mode 100644 index 0000000000..915cb77b29 --- /dev/null +++ b/Documentation/git-replace.txt @@ -0,0 +1,71 @@ +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. + +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] + +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-rerere.txt b/Documentation/git-rerere.txt index a53c3cd35b..7dd515b8cc 100644 --- a/Documentation/git-rerere.txt +++ b/Documentation/git-rerere.txt @@ -23,7 +23,7 @@ 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 to +You need to set the configuration variable rerere.enabled in order to enable this command. diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index 6abaeac28c..469cf6dbac 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt @@ -8,8 +8,9 @@ git-reset - Reset current HEAD to the specified state SYNOPSIS -------- [verse] -'git reset' [--mixed | --soft | --hard] [-q] [<commit>] +'git reset' [--mixed | --soft | --hard | --merge] [-q] [<commit>] 'git reset' [-q] [<commit>] [--] <paths>... +'git reset' --patch [<commit>] [--] [<paths>...] DESCRIPTION ----------- @@ -23,8 +24,9 @@ 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 form with 'paths' is used to revert selected paths in -the index from a given commit, without moving HEAD. +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 @@ -45,6 +47,20 @@ OPTIONS 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. @@ -82,7 +98,9 @@ $ 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. +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:: + @@ -128,7 +146,7 @@ Undo a merge or pull:: $ git pull <1> Auto-merging nitfol CONFLICT (content): Merge conflict in nitfol -Automatic merge failed/prevented; fix up by hand +Automatic merge failed; fix conflicts and then commit the result. $ git reset --hard <2> $ git pull . topic/branch <3> Updating from 41223... to 13134... @@ -150,6 +168,28 @@ 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 @@ -175,6 +215,8 @@ $ git reset <3> <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:: + diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt index 1c9cc28895..3341d1b62f 100644 --- a/Documentation/git-rev-list.txt +++ b/Documentation/git-rev-list.txt @@ -14,6 +14,7 @@ SYNOPSIS [ \--max-age=timestamp ] [ \--min-age=timestamp ] [ \--sparse ] + [ \--merges ] [ \--no-merges ] [ \--first-parent ] [ \--remove-empty ] @@ -50,20 +51,26 @@ SYNOPSIS DESCRIPTION ----------- -Lists commit objects in reverse chronological order starting at the -given commit(s), taking ancestry relationship into account. This is -useful to produce human-readable log output. +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. -Commits which are stated with a preceding '{caret}' cause listing to -stop at that point. Their parents are implied. Thus the following -command: +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 included in 'foo' and 'bar', but -not in '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 @@ -83,7 +90,7 @@ between the two operands. The following two commands are equivalent: $ git rev-list A...B ----------------------------------------------------------------------- -'git-rev-list' is a very essential git program, since it +'rev-list' is a very essential git command, since it provides the ability to build and traverse commit ancestry graphs. For this reason, it has a lot of different options that enables it to be used by commands as different as 'git-bisect' and diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index 2921da320d..82045a2522 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -26,10 +26,20 @@ OPTIONS --parseopt:: Use 'git-rev-parse' in option parsing mode (see PARSEOPT section below). ---keep-dash-dash:: +--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. @@ -64,7 +74,8 @@ OPTIONS 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-\*'). + '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 @@ -84,6 +95,11 @@ OPTIONS unfortunately named tag "master"), and show them as full refnames (e.g. "refs/heads/master"). +--abbrev-ref[={strict|loose}]:: + A non-ambiguous short name of the objects name. + The option core.warnAmbiguousRefs is used to select the strict + abbreviation mode. + --all:: Show all refs found in `$GIT_DIR/refs`. @@ -212,6 +228,9 @@ when you run 'git-merge'. 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}' @@ -296,18 +315,18 @@ 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 +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`". +from r1 by `{caret}r1 r2` and it can be written as `r1..r2`. -A similar notation "`r1\...r2`" is called symmetric difference +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)`". +`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. @@ -398,6 +417,33 @@ 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 -------- diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt index caa07298a6..5e1175800a 100644 --- a/Documentation/git-revert.txt +++ b/Documentation/git-revert.txt @@ -44,6 +44,14 @@ OPTIONS 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 diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 3c3e1b0e77..767cf4d4bd 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -8,82 +8,129 @@ git-send-email - Send a collection of patches as emails SYNOPSIS -------- -'git send-email' [options] <file|directory> [... file|directory] - +'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 ------- -The options available are: ---bcc:: - Specify a "Bcc:" value for each email. +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:: +--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. ---cc-cmd:: - 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. - ---chain-reply-to:: ---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. - --compose:: Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR 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:: - Specify the sender of the emails. This will default to - the value GIT_COMMITTER_IDENT, as returned by "git var -l". - The user will still be prompted to confirm this entry. +--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:: +--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. ---signed-off-by-cc:: ---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.signedoffcc' configuration value; - if that is unspecified, default to --signed-off-by-cc. +--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. ---quiet:: - Make git-send-email less verbose. One line per email should be - all that is output. +--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. ---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'. ---smtp-server:: +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. 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; @@ -93,114 +140,144 @@ The --cc option must be repeated for each user you want on the cc list. `/usr/lib/sendmail` if such program is available, or `localhost` otherwise. ---smtp-server-port:: +--smtp-server-port=<port>:: Specifies a port different from the default port (SMTP - servers typically listen to smtp port 25 and ssmtp port - 465). + 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. ---smtp-user:: - Username for SMTP-AUTH. In place of this option, the following - configuration variables can be specified: +--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: + -- - * sendemail.smtpuser - * sendemail.<identity>.smtpuser (see sendemail.identity). +- '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. -- + -However, --smtp-user always overrides these variables. +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 a username is not specified (with --smtp-user or a -configuration variable), then authentication is not attempted. - ---smtp-pass:: - Password for SMTP-AUTH. The argument is optional: If no - argument is specified, then the empty string is used as - the password. +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. + -In place of this option, the following configuration variables -can be specified: +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: + -- - * sendemail.smtppass - * sendemail.<identity>.smtppass (see sendemail.identity). +- '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' -- + -However, --smtp-pass always overrides these variables. -+ -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 configuration variable), but no password has been -specified (with --smtp-pass or a configuration variable), then the -user is prompted for a password while the input is masked for privacy. - ---smtp-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-ssl:: - Legacy alias for '--smtp-encryption=ssl'. - ---subject:: - 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. - ---suppress-from:: ---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. - ---suppress-cc:: - Specify an additional category of recipients to suppress the - auto-cc of. 'self' will avoid including the sender, 'author' will - avoid including the patch author, 'cc' will avoid including anyone - mentioned in Cc lines in the patch, 'sob' will avoid including - anyone mentioned in Signed-off-by lines, and 'cccmd' will avoid - running the --cc-cmd. '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 'sob' if --no-signed-off-cc is specified. - ---thread:: ---no-thread:: - If this is set, the In-Reply-To header will be set on each email sent. - If disabled with "--no-thread", no emails will have the In-Reply-To - header set. - Default is the value of the 'sendemail.thread' configuration value; - if that is unspecified, default to --thread. +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. ---envelope-sender:: - 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. 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. - ---to:: - 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. +--[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: + -The --to option must be repeated for each user you want on the to list. +-- + * 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.identity:: - The default configuration identity. When specified, - 'sendemail.<identity>.<item>' will have higher precedence than - 'sendemail.<item>'. This is useful to declare multiple SMTP - identities and to hoist sensitive authentication information - out of the repository and into the global configuration file. sendemail.aliasesfile:: To avoid typing long email addresses, point this to one or more @@ -208,40 +285,19 @@ sendemail.aliasesfile:: sendemail.aliasfiletype:: Format of the file(s) specified in sendemail.aliasesfile. Must be - one of 'mutt', 'mailrc', 'pine', or 'gnus'. - -sendemail.to:: - Email address (or alias) to always send to. - -sendemail.cccmd:: - Command to execute to generate per patch file specific "Cc:"s. + one of 'mutt', 'mailrc', 'pine', 'elm', or 'gnus'. -sendemail.bcc:: - Email address (or alias) to always bcc. +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.chainreplyto:: - Boolean value specifying the default to the '--chain_reply_to' - parameter. +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. -sendemail.smtpserver:: - Default SMTP server to use. - -sendemail.smtpserverport:: - Default SMTP server port to use. - -sendemail.smtpuser:: - Default SMTP-AUTH username. - -sendemail.smtppass:: - Default SMTP-AUTH password. - -sendemail.smtpencryption:: - Default encryption method. Use 'ssl' for SSL (and specify an - appropriate port), or 'tls' for TLS. Takes precedence over - 'smtpssl' if both are specified. - -sendemail.smtpssl:: - Legacy boolean that sets 'smtpencryption=ssl' if enabled. Author ------ @@ -250,10 +306,12 @@ 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-shell.txt b/Documentation/git-shell.txt index ff420f8f8c..0f3ad811cf 100644 --- a/Documentation/git-shell.txt +++ b/Documentation/git-shell.txt @@ -18,8 +18,9 @@ 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 the 'git-receive-pack' and 'git-upload-pack' commands -are permitted to be called, with a single required argument. +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 ------ diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index 7ccf31ccc4..42463a955d 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -45,19 +45,16 @@ OPTIONS and subsequent lines are indented by `indent2` spaces. `width`, `indent1`, and `indent2` default to 76, 6 and 9 respectively. -FILES ------ - -If the file `.mailmap` exists, it will be used for mapping author -email addresses to a real author name. One mapping per line, first -the author name followed by the email address enclosed by -'<' and '>'. Use hash '#' for comments. Example: - ------------- -# Keep alphabetized -Adam Morrow <adam@localhost.localdomain> -Eve Jones <eve@laptop.(none)> ------------- + +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 ------ diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt index fb269fff87..734336119c 100644 --- a/Documentation/git-show-branch.txt +++ b/Documentation/git-show-branch.txt @@ -8,9 +8,12 @@ git-show-branch - Show branches and their commits SYNOPSIS -------- [verse] -'git show-branch' [--all] [--remotes] [--topo-order] [--current] +'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>]... + [--no-name | --sha1-name] [--topics] + [<rev> | <glob>]... + 'git show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>] DESCRIPTION @@ -57,6 +60,11 @@ OPTIONS 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 @@ -74,9 +82,11 @@ OPTIONS Synonym to `--more=-1` --merge-base:: - Instead of showing the commit list, just act like the - 'git-merge-base -a' command, except that it can accept - more than two heads. + 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 @@ -99,14 +109,22 @@ OPTIONS 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. - `-g` can be used as a short-hand for this option. When - no explicit <ref> parameter is given, it defaults to the + 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. @@ -148,9 +166,10 @@ $ git show-branch master fixes mhf ------------------------------------------------ These three branches all forked from a common commit, [master], -whose commit message is "Add 'git show-branch'. "fixes" branch -adds one commit 'Introduce "reset type"'. "mhf" branch has many -other commits. The current branch is "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 @@ -172,7 +191,7 @@ 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 +$ git show-branch --reflog="10,1 hour ago" --list master ------------ shows 10 reflog entries going back from the tip as of 1 hour ago. diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt index 98e294aa86..f4429bdc68 100644 --- a/Documentation/git-show-ref.txt +++ b/Documentation/git-show-ref.txt @@ -9,8 +9,9 @@ SYNOPSIS -------- [verse] 'git show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] - [-s|--hash] [--abbrev] [--tags] [--heads] [--] <pattern>... -'git show-ref' --exclude-existing[=pattern] + [-s|--hash[=<n>]] [--abbrev[=<n>]] [--tags] + [--heads] [--] <pattern>... +'git show-ref' --exclude-existing[=<pattern>] < ref-list DESCRIPTION ----------- @@ -48,7 +49,7 @@ OPTIONS appended. -s:: ---hash:: +--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. @@ -59,11 +60,10 @@ OPTIONS Aside from returning an error code of 1, it will also print an error message if '--quiet' was not specified. ---abbrev:: ---abbrev=len:: +--abbrev[=<n>]:: Abbreviate the object name. When using `--hash`, you do - not have to say `--hash --abbrev`; `--hash=len` would do. + not have to say `--hash --abbrev`; `--hash=n` would do. -q:: --quiet:: @@ -71,8 +71,7 @@ OPTIONS Do not print any results to stdout. When combined with '--verify' this can be used to silently check if a reference exists. ---exclude-existing:: ---exclude-existing=pattern:: +--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 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 index 051f94d26f..fafe728f89 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -9,10 +9,11 @@ SYNOPSIS -------- [verse] 'git stash' list [<options>] -'git stash' (show | drop | pop ) [<stash>] -'git stash' apply [--index] [<stash>] +'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 [--keep-index] [<message>]] +'git stash' [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] [<message>]] 'git stash' clear 'git stash' create @@ -41,15 +42,27 @@ is also possible). OPTIONS ------- -save [--keep-index] [<message>]:: +save [--patch] [--[no-]keep-index] [-q|--quiet] [<message>]:: Save your local modifications to a new 'stash', and run `git reset - --hard` to revert them. This is the default action when no - subcommand is given. The <message> part is optional and gives - the description along with the stashed state. + --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>]:: @@ -65,7 +78,8 @@ 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]. +command to control what is shown and how. If no options are set, the +default is `-n 10`. See linkgit:git-log[1]. show [<stash>]:: @@ -75,19 +89,27 @@ show [<stash>]:: 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). -apply [--index] [<stash>]:: +pop [--index] [-q|--quiet] [<stash>]:: - Restore the changes recorded in the stash on top of the current - working tree state. When no `<stash>` is given, applies the latest - one. The working directory must match the index. + 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. + -This operation can fail with conflicts; you need to resolve them -by hand in the working tree. +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>]:: @@ -105,19 +127,14 @@ no conflicts. clear:: Remove all the stashed states. Note that those states will then - be subject to pruning, and may be difficult or impossible to recover. + be subject to pruning, and may be impossible to recover (see + 'Examples' below for a possible strategy). -drop [<stash>]:: +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}` -pop [<stash>]:: - - Remove a single stashed state from the stash list and apply on top - of the current working tree state. When no `<stash>` is given, - `stash@\{0}` is assumed. See also `apply`. - create:: Create a stash (which is a regular commit object) and return its @@ -163,7 +180,7 @@ $ git pull file foobar not up to date, cannot merge. $ git stash $ git pull -$ git stash apply +$ git stash pop ---------------------------------------------------------------- Interrupted workflow:: @@ -192,7 +209,7 @@ You can use 'git-stash' to simplify the above, like this: $ git stash $ edit emergency fix $ git commit -a -m "Fix in a hurry" -$ git stash apply +$ git stash pop # ... continue hacking ... ---------------------------------------------------------------- @@ -214,6 +231,20 @@ $ 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], diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index e6652a7de1..5ccdd18c89 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -9,11 +9,15 @@ git-submodule - Initialize, update or inspect submodules SYNOPSIS -------- [verse] -'git submodule' [--quiet] add [-b branch] [--] <repository> <path> -'git submodule' [--quiet] status [--cached] [--] [<path>...] +'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] [--] [<path>...] -'git submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<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 @@ -96,6 +100,9 @@ status:: 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 @@ -111,17 +118,54 @@ init:: 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. + 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. + 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 ------- @@ -138,6 +182,11 @@ OPTIONS 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. @@ -146,6 +195,44 @@ OPTIONS (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. diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index b6577dd4c4..1812890a7e 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -3,7 +3,7 @@ git-svn(1) NAME ---- -git-svn - Bidirectional operation between a single Subversion branch and git +git-svn - Bidirectional operation between a Subversion repository and git SYNOPSIS -------- @@ -11,27 +11,25 @@ SYNOPSIS DESCRIPTION ----------- -'git-svn' is a simple conduit for changesets between Subversion and git. +'git svn' is a simple conduit for changesets between Subversion and git. It provides a bidirectional flow of changes between a Subversion and a git repository. -'git-svn' can track a single Subversion branch simply by using a -URL to the branch, follow branches laid out in the Subversion recommended -method (trunk, branches, tags directories) with the --stdlayout option, or -follow branches in any layout with the -T/-t/-b options (see options to -'init' below, and also the 'clone' command). +'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 branch (with any of the above methods), the git +Once tracking a Subversion repository (with any of the above methods), the git repository can be updated from Subversion by the 'fetch' command and Subversion updated from git by the 'dcommit' command. COMMANDS -------- --- 'init':: Initializes an empty git repository with additional - metadata directories for 'git-svn'. The Subversion URL + 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 @@ -48,8 +46,11 @@ COMMANDS --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). The option --stdlayout is + (--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. @@ -61,16 +62,6 @@ COMMANDS Set the 'useSvnsyncProps' option in the [svn-remote] config. --rewrite-root=<URL>;; Set the 'rewriteRoot' option in the [svn-remote] config. ---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. --username=<USER>;; For transports that SVN handles authentication for (http, https, and plain svn), specify the username. For other @@ -85,6 +76,21 @@ COMMANDS 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 @@ -92,35 +98,89 @@ COMMANDS .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'. 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. + '--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' ++ +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 ++ +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 + Do not fetch remotely; only run 'git rebase' against the last fetched commit from the upstream SVN. 'dcommit':: @@ -128,11 +188,12 @@ and have no uncommitted changes. 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 + 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 command-line argument may be specified as an - alternative to HEAD. + 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. + @@ -140,14 +201,47 @@ and have no uncommitted changes. 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 + 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). - Using this option for any other purpose (don't ask) - is very strongly discouraged. --- +'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 @@ -156,10 +250,12 @@ and have no uncommitted changes. 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;; +-v;; +--verbose;; it's not completely compatible with the --verbose output in svn log, but reasonably close. --limit=<n>;; @@ -182,7 +278,7 @@ 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' +Any other arguments are passed directly to 'git log' 'blame':: Show what revision and author last modified each line of a file. The @@ -190,15 +286,14 @@ Any other arguments are passed directly to 'git-log' `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'. + arguments are passed directly to 'git blame'. + --git-format;; - Produce output in the same format as 'git-blame', but with + 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 @@ -212,7 +307,7 @@ Any other arguments are passed directly to 'git-log' 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. + independently of 'git svn' functions. 'create-ignore':: Recursively finds the svn:ignore property on directories and @@ -227,12 +322,12 @@ Any other arguments are passed directly to 'git-log' '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 + 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'). + (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':: @@ -254,107 +349,170 @@ Any other arguments are passed directly to 'git-log' 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'. + These are passed directly to 'git init'. -r <ARG>:: --revision <ARG>:: - -Used with the 'fetch' command. - + 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. - + 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. +'git rev-list --pretty=oneline' output can be used. --rmdir:: - -Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands. - + 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. - + 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 + 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': - + 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' ++ +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 +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. + 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. - + 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'. - ++ +--repack-flags are passed directly to 'git repack'. ++ [verse] config key: svn.repack config key: svn.repackflags @@ -363,37 +521,36 @@ config key: svn.repackflags --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'). + 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' and 'rebase' commands. - + 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. + 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>:: @@ -407,33 +564,30 @@ no longer require this switch as an argument. 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 + 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 ++ +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. - + 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 @@ -450,15 +604,22 @@ svn-remote.<name>.useSvnsyncprops:: svn-remote.<name>.rewriteRoot:: This allows users to create repositories from alternate - URLs. For example, an administrator could run 'git-svn' on the + 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 +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. @@ -476,7 +637,7 @@ Tracking and contributing to the trunk of a Subversion-managed project: 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 +# You should be on master branch, double-check with 'git branch' git branch # Do some work and commit locally to git: git commit ... @@ -498,6 +659,8 @@ Tracking and contributing to an entire Subversion-managed project 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 @@ -505,12 +668,12 @@ Tracking and contributing to an entire Subversion-managed project # of dcommit/rebase/show-ignore should be the same as above. ------------------------------------------------------------------------ -The initial 'git-svn clone' can be quite time-consuming +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': +'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 @@ -524,7 +687,7 @@ have each person clone that repository with 'git-clone': 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) +# 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 @@ -533,7 +696,7 @@ have each person clone that repository with 'git-clone': REBASE VS. PULL/MERGE --------------------- -Originally, 'git-svn' recommended that the 'remotes/git-svn' branch be +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. @@ -548,7 +711,7 @@ 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 +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 @@ -559,25 +722,25 @@ 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' +(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. +'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 +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. -'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 +'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 +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. @@ -587,6 +750,16 @@ 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 ---- @@ -603,7 +776,7 @@ for git to detect them. CONFIGURATION ------------- -'git-svn' stores [svn-remote] configuration information in the +'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' @@ -614,17 +787,17 @@ 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/* - trunk = trunk/project-a:refs/remotes/project-a/trunk ------------------------------------------------------------------------ -Keep in mind that the '*' (asterisk) wildcard of the local ref +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 own +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'. +should be manually entered with a text-editor or using 'git config'. SEE ALSO -------- diff --git a/Documentation/git-symbolic-ref.txt b/Documentation/git-symbolic-ref.txt index 210fde03a1..6392538807 100644 --- a/Documentation/git-symbolic-ref.txt +++ b/Documentation/git-symbolic-ref.txt @@ -14,9 +14,9 @@ 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 on which branch your working tree is on. +argument to see which branch your working tree is on. -Give two arguments, create or update a symbolic ref <name> to +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 diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 1f34948167..299b04f726 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -10,14 +10,15 @@ SYNOPSIS -------- [verse] 'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] - <name> [<commit> | <object>] -'git tag' -d <name>... -'git tag' [-n[<num>]] -l [<pattern>] -'git tag' -v <name>... + <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/` + +Adds a tag reference in `.git/refs/tags/`. Unless `-f` is given, the tag must not yet exist in `.git/refs/tags/` directory. @@ -50,6 +51,7 @@ OPTIONS Make a GPG-signed tag, using the given key -f:: +--force:: Replace an existing tag with the given name (instead of failing) -d:: @@ -69,9 +71,12 @@ OPTIONS 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, there values are + 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. @@ -82,6 +87,12 @@ OPTIONS 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 @@ -208,7 +219,7 @@ 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 networking part of the kernel") who may +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 @@ -246,6 +257,10 @@ $ 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>, diff --git a/Documentation/git-update-server-info.txt b/Documentation/git-update-server-info.txt index 35d27b0c7f..035cc3018f 100644 --- a/Documentation/git-update-server-info.txt +++ b/Documentation/git-update-server-info.txt @@ -39,12 +39,6 @@ what they are for: * info/refs -BUGS ----- -When you remove an existing ref, the command fails to update -info/refs file unless `--force` flag is given. - - Author ------ Written by Junio C Hamano <gitster@pobox.com> diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt index b8e49dce4a..63f3b5c742 100644 --- a/Documentation/git-upload-pack.txt +++ b/Documentation/git-upload-pack.txt @@ -20,6 +20,8 @@ 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 ------- diff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt index c8611632d1..97f7f9165e 100644 --- a/Documentation/git-verify-pack.txt +++ b/Documentation/git-verify-pack.txt @@ -8,7 +8,7 @@ git-verify-pack - Validate packed git archive files SYNOPSIS -------- -'git verify-pack' [-v] [--] <pack>.idx ... +'git verify-pack' [-v|--verbose] [--] <pack>.idx ... DESCRIPTION @@ -23,8 +23,15 @@ OPTIONS The idx files to verify. -v:: +--verbose:: After verifying the pack, show list of objects contained - in the pack. + 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. diff --git a/Documentation/git-web--browse.txt b/Documentation/git-web--browse.txt index 7f7a45b2ea..278cf73527 100644 --- a/Documentation/git-web--browse.txt +++ b/Documentation/git-web--browse.txt @@ -26,6 +26,7 @@ The following browsers (or commands) are currently supported: * 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. diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt index 26d3850e73..c8899d528a 100644 --- a/Documentation/git-write-tree.txt +++ b/Documentation/git-write-tree.txt @@ -12,7 +12,8 @@ SYNOPSIS DESCRIPTION ----------- -Creates a tree object using the current index. +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. diff --git a/Documentation/git.txt b/Documentation/git.txt index df420aeb33..7aa2edee58 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -9,7 +9,7 @@ git - the stupid content tracker SYNOPSIS -------- [verse] -'git' [--version] [--exec-path[=GIT_EXEC_PATH]] +'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS] @@ -43,16 +43,64 @@ 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.0.2/git.html[documentation for release 1.6.0.2] +* link:v1.6.5.4/git.html[documentation for release 1.6.5.4] * release notes for + 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.5/git.html[documentation for release 1.5.6.5] +* 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], @@ -60,18 +108,22 @@ Documentation for older releases are available here: link:RelNotes-1.5.6.1.txt[1.5.6.1], link:RelNotes-1.5.6.txt[1.5.6]. -* link:v1.5.5.4/git.html[documentation for release 1.5.5.4] +* 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.5/git.html[documentation for release 1.5.4.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], @@ -155,6 +207,10 @@ help ...`. 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). @@ -196,6 +252,8 @@ 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. @@ -282,7 +340,7 @@ Synching repositories include::cmds-synchingrepositories.txt[] -The following are helper programs used by the above; end users +The following are helper commands used by the above; end users typically do not use them directly. include::cmds-synchelpers.txt[] @@ -613,7 +671,8 @@ 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:gitcli[7], link:user-manual.html[The Git User's Manual], +linkgit:gitworkflows[7] GIT --- diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index c4aebc4351..1f472cea59 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -18,10 +18,10 @@ A `gitattributes` file is a simple text file that gives Each line in `gitattributes` file is of form: - glob attr1 attr2 ... + pattern attr1 attr2 ... -That is, a glob pattern followed by an attributes list, -separated by whitespaces. When the glob pattern matches the +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. @@ -48,13 +48,14 @@ Set to a value:: Unspecified:: - No glob pattern matches the path, and nothing says if + 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 glob pattern matches the path, a later line +When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per -attribute. +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 @@ -216,10 +217,12 @@ Generating diff text `diff` ^^^^^^ -The attribute `diff` affects if 'git-diff' generates textual -patch for the path or just says `Binary files differ`. It also -can affect what line is shown on the hunk header `@@ -k,l +n,m @@` -line. +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:: @@ -230,7 +233,8 @@ Set:: Unset:: A path to which the `diff` attribute is unset will - generate `Binary files differ`. + generate `Binary files differ` (or a binary patch, if + binary patches are enabled). Unspecified:: @@ -241,21 +245,21 @@ Unspecified:: String:: - Diff is shown using the specified custom diff driver. - The driver program is given its input using the same - calling convention as used for GIT_EXTERNAL_DIFF - program. This name is also used for custom hunk header - selection. + 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 a custom diff driver -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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 a custom diff driver `jcdiff`, add a section to your +To define an external diff driver `jcdiff`, add a section to your `$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: ---------------------------------------------------------------- @@ -293,7 +297,8 @@ for paths. 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", like this: +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"] @@ -314,15 +319,83 @@ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -331,7 +404,7 @@ Performing a three-way 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 programs such as `git revert` and `git cherry-pick`. +and other commands such as `git revert` and `git cherry-pick`. Set:: @@ -487,6 +560,33 @@ 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 ---------------------- diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index 29e5929db2..6928724a05 100644 --- a/Documentation/gitcli.txt +++ b/Documentation/gitcli.txt @@ -46,20 +46,20 @@ 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"`. + 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). + * 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"` + 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 + `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. @@ -81,7 +81,7 @@ couple of magic command line options: + --------------------------------------------- $ git describe -h -usage: git-describe [options] <committish>* +usage: git describe [options] <committish>* --contains find the tag that comes after the commit --debug debug search strategy on stderr @@ -99,17 +99,17 @@ usage: git-describe [options] <committish>* 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"`. +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"`. +options. This means that you can for example use `git rm -rf` or +`git clean -fdx`. Separating argument from the option diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 896cbdf686..0382d2c0ad 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -12,7 +12,7 @@ git * DESCRIPTION ----------- -This tutorial explains how to use the "core" git programs to set up and +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 @@ -602,7 +602,7 @@ $ git tag -s <tagname> ---------------- which will sign the current `HEAD` (but you can also give it another -argument that specifies the thing to tag, i.e., you could have tagged the +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 @@ -899,7 +899,7 @@ file, which had no differences in the `mybranch` branch), and say: ---------------- Auto-merging hello CONFLICT (content): Merge conflict in hello - Automatic merge failed; fix up by hand + Automatic merge failed; fix conflicts and then commit the result. ---------------- It tells you that it did an "Automatic merge", which @@ -993,7 +993,7 @@ would be different) ---------------- Updating from ae3a2da... to a80b4aa.... -Fast forward +Fast forward (no commit created; -m option ignored) example | 1 + hello | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) @@ -1243,10 +1243,10 @@ $ git ls-files --stage ------------ 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, only small number of files change in one commit, -and this 'collapsing' tends to trivially merge most of the paths -fairly quickly, leaving only a handful the real changes in non-zero +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: @@ -1265,9 +1265,8 @@ file, using 3-way merge. This is done by giving ------------ $ git merge-index git-merge-one-file hello -Auto-merging hello. -merge: warning: conflicts during merge -ERROR: Merge conflict in hello. +Auto-merging hello +ERROR: Merge conflict in hello fatal: merge program failed ------------ @@ -1329,7 +1328,7 @@ into it later. Obviously, this repository creation needs to be done only once. [NOTE] -'git-push' uses a pair of programs, +'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. @@ -1447,7 +1446,7 @@ public repository you might want to repack & prune often, or never. If you run `git repack` again at this point, it will say -"Nothing to pack". Once you continue your development and +"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 @@ -1693,6 +1692,7 @@ 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] diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt index aaa7ef737a..0e49c1c037 100644 --- a/Documentation/gitcvs-migration.txt +++ b/Documentation/gitcvs-migration.txt @@ -118,7 +118,7 @@ Importing a CVS archive First, install version 2.1 or higher of cvsps from link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make sure it is in your path. Then cd to a checked out CVS working directory -of the project you are interested in and run 'git-cvsimport': +of the project you are interested in and run linkgit:git-cvsimport[1]: ------------------------------------------- $ git cvsimport -C <destination> <module> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index 024abb2ff1..06e0f315c3 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -15,15 +15,22 @@ 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 example hooks are copied in the +'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 @@ -39,7 +46,7 @@ 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. @@ -54,7 +61,7 @@ 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. @@ -63,7 +70,7 @@ 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 @@ -80,7 +87,7 @@ 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. @@ -105,7 +112,7 @@ 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 @@ -122,7 +129,7 @@ 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. @@ -131,14 +138,14 @@ 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, @@ -147,12 +154,16 @@ 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 @@ -167,7 +178,7 @@ 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. @@ -196,7 +207,7 @@ 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. @@ -234,12 +245,12 @@ Both standard output and standard error output are forwarded to for the user. The default 'update' hook, when enabled--and with -`hooks.allowunannotated` config option turned on--prevents +`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. @@ -269,7 +280,7 @@ 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. @@ -299,8 +310,37 @@ 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' diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index 5ef3687e39..cf465cb47e 100644 --- a/Documentation/gitk.txt +++ b/Documentation/gitk.txt @@ -47,7 +47,8 @@ frequently used options. 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. + 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 @@ -56,6 +57,11 @@ frequently used options. 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 @@ -68,7 +74,7 @@ frequently used options. <path>...:: Limit commits to the ones touching files in the given paths. Note, to - avoid ambiguity wrt. revision names use "--" to separate the paths + avoid ambiguity with respect to revision names use "--" to separate the paths from any preceding options. Examples diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt index d1a17e2625..5daf750d19 100644 --- a/Documentation/gitmodules.txt +++ b/Documentation/gitmodules.txt @@ -30,6 +30,17 @@ submodule.<name>.path:: 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 -------- diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt index a969b3fbc3..1befca98d4 100644 --- a/Documentation/gitrepository-layout.txt +++ b/Documentation/gitrepository-layout.txt @@ -134,7 +134,8 @@ 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, they need to be made executable. + 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. diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt index 660904686c..dc8fc3a18a 100644 --- a/Documentation/gittutorial-2.txt +++ b/Documentation/gittutorial-2.txt @@ -32,22 +32,27 @@ Initialized empty Git repository in .git/ $ echo 'hello world' > file.txt $ git add . $ git commit -a -m "initial commit" -Created initial commit 54196cc2703dc165cbd373a65a4dcf22d50ae7f7 +[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" -Created commit c4d59f390b9cfd4318117afde11d601c1085f241 +[master c4d59f3] add emphasis + 1 files changed, 1 insertions(+), 1 deletions(-) ------------------------------------------------ -What are the 40 digits of hex that git responded to the commit with? +What are the 7 digits of hex that git responded to the commit with? We saw in part one of the tutorial that commits have names like this. It turns out that every object in the git history is stored under -such a 40-digit hex name. That name is the SHA1 hash of the object's +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). +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 @@ -420,6 +425,7 @@ 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] diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index 384972cb9b..cf0689cfeb 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -26,6 +26,15 @@ First, note that you can get documentation for a command such as $ 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: @@ -299,9 +308,7 @@ 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. (Note that the -"master" argument in the above command is actually unnecessary, as it -is the default.) +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. @@ -325,11 +332,11 @@ 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. +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 reviewing what Bob has in his state (FETCH_HEAD) that she has not -seen with this command +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: @@ -368,9 +375,9 @@ 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: +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 @@ -559,29 +566,29 @@ $ git log v2.5.. Makefile # commits since v2.5 which modify 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-release" and "master" diverged from a common +the branches "stable" and "master" diverged from a common commit some time ago, then ------------------------------------- -$ git log stable..experimental +$ git log stable..master ------------------------------------- -will list commits made in the experimental branch but not in the +will list commits made in the master branch but not in the stable branch, while ------------------------------------- -$ git log experimental..stable +$ git log master..stable ------------------------------------- will show the list of commits made on the stable branch but not -the experimental branch. +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, +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, @@ -633,7 +640,7 @@ 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 + 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 @@ -643,6 +650,9 @@ digressions that may be interesting at this point are: 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. @@ -653,6 +663,8 @@ 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] diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt new file mode 100644 index 0000000000..91c0eea890 --- /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 index 9b4a4f45e9..43d84d15e9 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -183,7 +183,8 @@ to point at the new commit. 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 - making them executable. + 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 @@ -261,7 +262,7 @@ This commit is referred to as a "merge commit", or sometimes just a '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`". + `git branch -r`. [[def_pack]]pack:: A set of objects which have been compressed into one file (to save space @@ -448,7 +449,13 @@ This commit is referred to as a "merge commit", or sometimes just a 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 is - normally equal to the <<def_HEAD,HEAD>> plus any local changes - that you have made but not yet committed. + 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/rebase-and-edit.txt b/Documentation/howto/rebase-and-edit.txt deleted file mode 100644 index 554909fe08..0000000000 --- a/Documentation/howto/rebase-and-edit.txt +++ /dev/null @@ -1,79 +0,0 @@ -Date: Sat, 13 Aug 2005 22:16:02 -0700 (PDT) -From: Linus Torvalds <torvalds@osdl.org> -To: Steve French <smfrench@austin.rr.com> -cc: git@vger.kernel.org -Subject: Re: sending changesets from the middle of a git tree -Abstract: In this article, Linus demonstrates how a broken commit - in a sequence of commits can be removed by rewinding the head and - reapplying selected changes. - -On Sat, 13 Aug 2005, Linus Torvalds wrote: - -> That's correct. Same things apply: you can move a patch over, and create a -> new one with a modified comment, but basically the _old_ commit will be -> immutable. - -Let me clarify. - -You can entirely _drop_ old branches, so commits may be immutable, but -nothing forces you to keep them. Of course, when you drop a commit, you'll -always end up dropping all the commits that depended on it, and if you -actually got somebody else to pull that commit you can't drop it from -_their_ repository, but undoing things is not impossible. - -For example, let's say that you've made a mess of things: you've committed -three commits "old->a->b->c", and you notice that "a" was broken, but you -want to save "b" and "c". What you can do is - - # Create a branch "broken" that is the current code - # for reference - git branch broken - - # Reset the main branch to three parents back: this - # effectively undoes the three top commits - git reset HEAD^^^ - git checkout -f - - # Check the result visually to make sure you know what's - # going on - gitk --all - - # Re-apply the two top ones from "broken" - # - # First "parent of broken" (aka b): - git-diff-tree -p broken^ | git-apply --index - git commit --reedit=broken^ - - # Then "top of broken" (aka c): - git-diff-tree -p broken | git-apply --index - git commit --reedit=broken - -and you've now re-applied (and possibly edited the comments) the two -commits b/c, and commit "a" is basically gone (it still exists in the -"broken" branch, of course). - -Finally, check out the end result again: - - # Look at the new commit history - gitk --all - -to see that everything looks sensible. - -And then, you can just remove the broken branch if you decide you really -don't want it: - - # remove 'broken' branch - git branch -d broken - - # Prune old objects if you're really really sure - git prune - -And yeah, I'm sure there are other ways of doing this. And as usual, the -above is totally untested, and I just wrote it down in this email, so if -I've done something wrong, you'll have to figure it out on your own ;) - - Linus -- -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/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt index d214d4bf9d..74a1c0c4ba 100644 --- a/Documentation/howto/rebase-from-internal-branch.txt +++ b/Documentation/howto/rebase-from-internal-branch.txt @@ -27,7 +27,7 @@ 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 commits that were ahead of master in pu, and I +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: 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/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt index 4032748608..622ee5c8dd 100644 --- a/Documentation/howto/setup-git-server-over-http.txt +++ b/Documentation/howto/setup-git-server-over-http.txt @@ -143,7 +143,7 @@ Then, add something like this to your httpd.conf Require valid-user </Location> - Debian automatically reads all files under /etc/apach2/conf.d. + 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. diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt index c673966331..708da6ca31 100644 --- a/Documentation/i18n.txt +++ b/Documentation/i18n.txt @@ -37,9 +37,9 @@ 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' and friends looks at the `encoding` - header of a commit object, and tries to re-code the log - message into UTF-8 unless otherwise specified. You can +. '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: + 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 index 4065a3a27a..b4d315cb8c 100644 --- a/Documentation/manpage-1.72.xsl +++ b/Documentation/manpage-1.72.xsl @@ -1,21 +1,14 @@ -<!-- Based on callouts.xsl. Fixes man page callouts for DocBook 1.72 XSL --> -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> +<!-- 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:param name="man.output.quietly" select="1"/> -<xsl:param name="refentry.meta.get.quietly" select="1"/> +<xsl:import href="manpage-base.xsl"/> -<xsl:template match="co"> - <xsl:value-of select="concat('▓fB(',substring-after(@id,'-'),')▓fR')"/> -</xsl:template> -<xsl:template match="calloutlist"> - <xsl:text>⌂sp </xsl:text> - <xsl:apply-templates/> - <xsl:text> </xsl:text> -</xsl:template> -<xsl:template match="callout"> - <xsl:value-of select="concat('▓fB',substring-after(@arearefs,'-'),'. ▓fR')"/> - <xsl:apply-templates/> - <xsl:text>⌂br </xsl:text> -</xsl:template> +<!-- 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.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 index c735788b0f..c0f96e7070 100644 --- a/Documentation/merge-config.txt +++ b/Documentation/merge-config.txt @@ -1,6 +1,10 @@ -merge.stat:: - Whether to print the diffstat between ORIG_HEAD and the merge result - at the end of the merge. True by default. +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 @@ -11,10 +15,15 @@ merge.renameLimit:: 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", and + "tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", + "diffuse", "ecmerge", "tortoisemerge", "araxis", and "opendiff". Any other value is treated is custom merge tool and there must be a corresponding mergetool.<tool>.cmd option. @@ -24,10 +33,10 @@ merge.verbosity:: 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 'GIT_MERGE_VERBOSITY' environment variable. + Can be overridden by the 'GIT_MERGE_VERBOSITY' environment variable. merge.<driver>.name:: - Defines a human readable name for a custom low-level + Defines a human-readable name for a custom low-level merge driver. See linkgit:gitattributes[5] for details. merge.<driver>.driver:: diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index 007909a82f..48d04a5d88 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -1,55 +1,53 @@ ---stat:: - Show a diffstat at the end of the merge. The diffstat is also - controlled by the configuration option merge.stat. - --n:: ---no-stat:: - Do not show diffstat at the end of the merge. +--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. ---summary:: ---no-summary:: - Synonyms to --stat and --no-stat; these are deprecated and will be - removed in the future. +--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. ---no-log:: - Do not list one-line descriptions from the actual commits being - merged. - ---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. ---commit:: - Perform the merge and commit the result. This option can - be used to override --no-commit. +--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, but do not actually make a commit or + 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). - ---no-squash:: - Perform the merge and commit the result. This option can - be used to override --squash. - ---no-ff:: - Generate a merge commit even if the merge resolved as a - fast-forward. - ---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-squash perform the merge and commit the result. This +option can be used to override --squash. -s <strategy>:: --strategy=<strategy>:: @@ -58,3 +56,16 @@ 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 index 1276f858ad..4365b7e842 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -3,15 +3,15 @@ MERGE STRATEGIES resolve:: This can only resolve two heads (i.e. the current branch - and another branch you pulled from) using 3-way merge + 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 3-way merge - algorithm. When there are more than one common - ancestors that can be used for 3-way merge, it creates a + 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 @@ -22,11 +22,11 @@ recursive:: pulling or merging one branch. octopus:: - This resolves more than two-head case, but refuses to do - complex merge that needs manual resolution. It is + 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 branches. + pulling or merging more than one branch. ours:: This resolves any number of heads, but the result of the diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index 388d4925e6..2a845b1e57 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -30,7 +30,7 @@ This is designed to be as compact as possible. commit <sha1> Author: <author> - Date: <author date> + Date: <author date> <title line> @@ -49,9 +49,9 @@ This is designed to be as compact as possible. * 'fuller' commit <sha1> - Author: <author> + Author: <author> AuthorDate: <author date> - Commit: <committer> + Commit: <committer> CommitDate: <committer date> <title line> @@ -101,28 +101,33 @@ The placeholders are: - '%P': parent hashes - '%p': abbreviated parent hashes - '%an': author name -- '%aN': author name (respecting .mailmap) +- '%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) +- '%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 - '%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 @@ -148,3 +153,12 @@ $ git log -2 --pretty=tformat:%h 4da45bef \ 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 index 6d66c74cc1..bff94991b6 100644 --- a/Documentation/pretty-options.txt +++ b/Documentation/pretty-options.txt @@ -1,4 +1,5 @@ --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', @@ -10,13 +11,17 @@ configuration (see linkgit:git-config[1]). --abbrev-commit:: Instead of showing the full 40-byte hexadecimal commit object - name, show only handful hexdigits prefix. Non default number of + 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 diff --git a/Documentation/pt_BR/gittutorial.txt b/Documentation/pt_BR/gittutorial.txt new file mode 100644 index 0000000000..81e7ad7df4 --- /dev/null +++ b/Documentation/pt_BR/gittutorial.txt @@ -0,0 +1,675 @@ +gittutorial(7) +============== + +NAME +---- +gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova) + +SYNOPSIS +-------- +git * + +DESCRIPTION +----------- + +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/ +------------------------------------------------ + +Você agora iniciou seu diretório de trabalho--você deve ter notado um +novo diretório 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 corrente (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 +------------------------------------------------ + +Isto irá novamente te pedir por uma mensagem descrevendo a mudança, e, +então, 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 história do projeto +----------------------- + +Em qualquer ponto você pode visualizar a história das suas mudanças +usando + +------------------------------------------------ +$ git log +------------------------------------------------ + +Se você também quer ver a diferença completa a cada passo, use + +------------------------------------------------ +$ git log -p +------------------------------------------------ + +Geralmente, uma visão geral da mudança é útil para ter a sensação de +cada passo + +------------------------------------------------ +$ git log --stat --summary +------------------------------------------------ + +Gerenciando "branches"/ramos +----------------- + +Um simples repositório git pode manter múltiplos ramos de +desenvolvimento. Para criar um novo ramo chamado "experimental", use + +------------------------------------------------ +$ git branch experimental +------------------------------------------------ + +Se você executar agora + +------------------------------------------------ +$ git branch +------------------------------------------------ + +você vai obter uma lista de todos os ramos existentes: + +------------------------------------------------ + experimental +* master +------------------------------------------------ + +O ramo "experimental" é o que você acaba de criar, e o ramo "master" é o +ramo padrão que foi criado pra você automaticamente. O asterisco marca +o ramo em que você está atualmente; digite + +------------------------------------------------ +$ git checkout experimental +------------------------------------------------ + +para mudar para o ramo experimental. Agora edite um arquivo, grave a +mudança, e mude de volta para o ramo master: + +------------------------------------------------ +(edita arquivo) +$ git commit -a +$ git checkout master +------------------------------------------------ + +Verifique que a mudança que você fez não está mais visÃvel, já que ela +foi feita no ramo experimental e você está de volta ao ramo master. + +Você pode fazer uma mudança diferente no ramo master: + +------------------------------------------------ +(edit file) +$ git commit -a +------------------------------------------------ + +neste ponto, os dois ramos divergiram, com diferentes mudanças feitas em +cada um. Para unificar as mudanças feitas no experimental para o +master, execute + +------------------------------------------------ +$ git merge experimental +------------------------------------------------ + +Se as mudanças não conflitarem, estará pronto. Se existirem conflitos, +marcadores serão deixados nos arquivos problemáticos exibindo o +conflito; + +------------------------------------------------ +$ git diff +------------------------------------------------ + +vai exibir isto. Após você editar os arquivos para resolver os +conflitos, + +------------------------------------------------ +$ git commit -a +------------------------------------------------ + +irá gravar o resultado da unificação. Finalmente, + +------------------------------------------------ +$ gitk +------------------------------------------------ + +vai mostrar uma bela representação gráfica da história resultante. + +Neste ponto você pode remover seu ramo experimental com + +------------------------------------------------ +$ git branch -d experimental +------------------------------------------------ + +Este comando garante que as mudanças no ramo experimental já estão no +ramo atual. + +Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode +sempre remover o ramo com + +------------------------------------- +$ git branch -D ideia-louca +------------------------------------- + +Ramos são baratos e fáceis, então isto é uma boa maneira de experimentar +alguma coisa. + +Usando git para colaboração +--------------------------- + +Suponha que Alice começou um novo projeto com um repositório git em +/home/alice/project, e que Bob, que tem um diretório home na mesma +máquina, quer contribuir. + +Bob começa com: + +------------------------------------------------ +bob$ git clone /home/alice/project myrepo +------------------------------------------------ + +Isso cria um novo diretório "myrepo" contendo um clone do repositório de +Alice. O clone está no mesmo pé que o projeto original, possuindo sua +própria cópia da história do projeto original. + +Bob então faz algumas mudanças e as grava: + +------------------------------------------------ +(editar arquivos) +bob$ git commit -a +(repetir conforme necessário) +------------------------------------------------ + +Quanto está pronto, ele diz a Alice para puxar as mudanças do +repositório em /home/bob/myrepo. Ela o faz com: + +------------------------------------------------ +alice$ cd /home/alice/project +alice$ git pull /home/bob/myrepo master +------------------------------------------------ + +Isto unifica as mudanças do ramo "master" do Bob ao ramo atual de Alice. +Se Alice fez suas próprias mudanças no intervalo, ela, então, pode +precisar corrigir manualmente quaisquer conflitos. (Note que o argumento +"master" no comando acima é, de fato, desnecessário, já que é o padrão.) + +O comando "pull" executa, então, duas operações: ele obtém mudanças de +um ramo remoto, e, então, as unifica no ramo atual. + +Note que, em geral, Alice gostaria que suas mudanças locais fossem +gravadas antes de iniciar este "pull". Se o trabalho de Bob conflita +com o que Alice fez desde que suas histórias se ramificaram, Alice irá +usar seu diretório de trabalho e o Ãndice para resolver conflitos, e +mudanças locais existentes irão interferir com o processo de resolução +de conflitos (git ainda irá realizar a obtenção mas irá se recusar a +unificar --- Alice terá que se livrar de suas mudanças locais de alguma +forma e puxar de novo quando isso acontecer). + +Alice pode espiar o que Bob fez sem unificar primeiro, usando o comando +"fetch"; isto permite Alice inspecionar o que Bob fez, usando um sÃmbolo +especial "FETCH_HEAD", com o fim de determinar se ele tem alguma coisa +que vale puxar, assim: + +------------------------------------------------ +alice$ git fetch /home/bob/myrepo master +alice$ git log -p HEAD..FETCH_HEAD +------------------------------------------------ + +Esta operação é segura mesmo se Alice tem mudanças locais não gravadas. +A notação de intervalo "HEAD..FETCH_HEAD" significa mostrar tudo que é +alcançável de FETCH_HEAD mas exclua tudo o que é alcançável de HEAD. +Alice já sabe tudo que leva a seu estado atual (HEAD), e revisa o que Bob +tem em seu estado (FETCH_HEAD) que ela ainda não viu com esse comando. + +Se Alice quer visualizar o que Bob fez desde que suas histórias se +ramificaram, ela pode disparar o seguinte comando: + +------------------------------------------------ +$ gitk HEAD..FETCH_HEAD +------------------------------------------------ + +Isto usa a mesma notação de intervalo que vimos antes com 'git log'. + +Alice pode querer ver o que ambos fizeram desde que ramificaram. Ela +pode usar a forma com três pontos ao invés da forma com dois pontos: + +------------------------------------------------ +$ gitk HEAD...FETCH_HEAD +------------------------------------------------ + +Isto significa "mostre tudo que é alcançável de qualquer um deles, mas +exclua tudo que é alcançável a partir de ambos". + +Por favor, note que essas notações de intervalo podem ser usadas tanto +com gitk quanto com "git log". + +Após inspecionar o que Bob fez, se não há nada urgente, Alice pode +decidir continuar trabalhando sem puxar de Bob. Se a história de Bob +tem alguma coisa que Alice precisa imediatamente, Alice pode optar por +separar seu trabalho em progresso primeiro, fazer um "pull", e, então, +finalmente, retomar seu trabalho em progresso em cima da história +resultante. + +Quando você está trabalhando em um pequeno grupo unido, não é incomum +interagir com o mesmo repositório várias e várias vezes. Definindo um +repositório remoto antes de tudo, você pode fazê-lo mais facilmente: + +------------------------------------------------ +alice$ git remote add bob /home/bob/myrepo +------------------------------------------------ + +Com isso, Alice pode executar a primeira parte da operação "pull" usando +o comando 'git-fetch' sem unificar suas mudanças com seu próprio ramo, +usando: + +------------------------------------- +alice$ git fetch bob +------------------------------------- + +Diferente da forma longa, quando Alice obteve de Bob usando um +repositório remoto antes definido com 'git-remote', o que foi obtido é +armazenado em um ramo remoto, neste caso `bob/master`. Então, após isso: + +------------------------------------- +alice$ git log -p master..bob/master +------------------------------------- + +mostra uma lista de todas as mudanças que Bob fez desde que ramificou do +ramo master de Alice. + +Após examinar essas mudanças, Alice pode unificá-las em seu ramo master: + +------------------------------------- +alice$ git merge bob/master +------------------------------------- + +Esse `merge` pode também ser feito puxando de seu próprio ramo remoto, +assim: + +------------------------------------- +alice$ git pull . remotes/bob/master +------------------------------------- + +Note que 'git pull' sempre unifica ao ramo atual, independente do que +mais foi passado na linha de comando. + +Depois, Bob pode atualizar seu repositório com as últimas mudanças de +Alice, usando + +------------------------------------- +bob$ git pull +------------------------------------- + +Note que ele não precisa dar o caminho do repositório de Alice; quando +Bob clonou seu repositório, o git armazenou a localização de seu +repositório na configuração do mesmo, e essa localização é usada +para puxar: + +------------------------------------- +bob$ git config --get remote.origin.url +/home/alice/project +------------------------------------- + +(A configuração completa criada por 'git-clone' é visÃvel usando `git +config -l`, e a página de manual linkgit:git-config[1] explica o +significado de cada opção.) + +Git também mantém uma cópia limpa do ramo master de Alice sob o nome +"origin/master": + +------------------------------------- +bob$ git branch -r + origin/master +------------------------------------- + +Se Bob decidir depois em trabalhar em um host diferente, ele ainda pode +executar clones e puxar usando o protocolo ssh: + +------------------------------------- +bob$ git clone alice.org:/home/alice/project myrepo +------------------------------------- + +Alternativamente, o git tem um protocolo nativo, ou pode usar rsync ou +http; veja linkgit:git-pull[1] para detalhes. + +Git pode também ser usado em um modo parecido com CVS, com um +repositório central para o qual vários usuários empurram modificações; +veja linkgit:git-push[1] e linkgit:gitcvs-migration[7]. + +Explorando história +----------------- + +A história no git é representada como uma série de commits +interrelacionados. Nós já vimos que o comando 'git-log' pode listar +esses commits. Note que a primeira linha de cada entrada no log também +dá o nome para o commit: + +------------------------------------- +$ git log +commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 +Author: Junio C Hamano <junkio@cox.net> +Date: Tue May 16 17:18:22 2006 -0700 + + merge-base: Clarify the comments on post processing. +------------------------------------- + +Nós podemos dar este nome ao 'git-show' para ver os detalhes sobre este +commit. + +------------------------------------- +$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 +------------------------------------- + +Mas há outras formas de se referir aos commits. Você pode usar qualquer +parte inicial do nome que seja longo o bastante para identificar +unicamente o commit: + +------------------------------------- +$ git show c82a22c39c # os primeiros caracteres do nome são o bastante + # usualmente +$ git show HEAD # a ponta do ramo atual +$ git show experimental # a ponta do ramo "experimental" +------------------------------------- + +Todo commit normalmente tem um commit "pai" que aponta para o estado +anterior do projeto: + +------------------------------------- +$ git show HEAD^ # para ver o pai de HEAD +$ git show HEAD^^ # para ver o avô de HEAD +$ git show HEAD~4 # para ver o trisavô de HEAD +------------------------------------- + +Note que commits de unificação podem ter mais de um pai: + +------------------------------------- +$ git show HEAD^1 # mostra o primeiro pai de HEAD (o mesmo que HEAD^) +$ git show HEAD^2 # mostra o segundo pai de HEAD +------------------------------------- + +Você também pode dar aos commits nomes à sua escolha; após executar + +------------------------------------- +$ git tag v2.5 1b2e1d63ff +------------------------------------- + +você pode se referir a 1b2e1d63ff pelo nome "v2.5". Se você pretende +compartilhar esse nome com outras pessoas (por exemplo, para identificar +uma versão de lançamento), você deveria criar um objeto "tag", e talvez +assiná-lo; veja linkgit:git-tag[1] para detalhes. + +Qualquer comando git que precise conhecer um commit pode receber +quaisquer desses nomes. Por exemplo: + +------------------------------------- +$ git diff v2.5 HEAD # compara o HEAD atual com v2.5 +$ git branch stable v2.5 # inicia um novo ramo chamado "stable" baseado + # em v2.5 +$ git reset --hard HEAD^ # reseta seu ramo atual e seu diretório de + # trabalho a seu estado em HEAD^ +------------------------------------- + +Seja cuidadoso com o último comando: além de perder quaisquer mudanças +em seu diretório de trabalho, ele também remove todos os commits +posteriores desse ramo. Se esse ramo é o único ramo contendo esses +commits, eles serão perdidos. Também, não use 'git-reset' num ramo +publicamente visÃvel de onde outros desenvolvedores puxam, já que vai +forçar unificações desnecessárias para que outros desenvolvedores limpem +a história. Se você precisa desfazer mudanças que você empurrou, use +'git-revert' no lugar. + +O comando 'git-grep' pode buscar strings em qualquer versão de seu +projeto, então + +------------------------------------- +$ git grep "hello" v2.5 +------------------------------------- + +procura por todas as ocorrências de "hello" em v2.5. + +Se você deixar de fora o nome do commit, 'git-grep' irá procurar +quaisquer dos arquivos que ele gerencia no diretório corrente. Então + +------------------------------------- +$ git grep "hello" +------------------------------------- + +é uma forma rápida de buscar somente os arquivos que são rastreados pelo +git. + +Muitos comandos git também recebem um conjunto de commits, o que pode +ser especificado de várias formas. Aqui estão alguns exemplos com 'git-log': + +------------------------------------- +$ git log v2.5..v2.6 # commits entre v2.5 e v2.6 +$ git log v2.5.. # commits desde v2.5 +$ git log --since="2 weeks ago" # commits das últimas 2 semanas +$ git log v2.5.. Makefile # commits desde v2.5 que modificam + # Makefile +------------------------------------- + +Você também pode dar ao 'git-log' um "intervalo" de commits onde o +primeiro não é necessariamente um ancestral do segundo; por exemplo, se +as pontas dos ramos "stable" e "master" divergiram de um commit +comum algum tempo atrás, então + +------------------------------------- +$ git log stable..master +------------------------------------- + +irá listar os commits feitos no ramo "master" mas não no ramo +"stable", enquanto + +------------------------------------- +$ git log master..stable +------------------------------------- + +irá listar a lista de commits feitos no ramo "stable" mas não no ramo +"master". + +O comando 'git-log' tem uma fraqueza: ele precisa mostrar os commits em +uma lista. Quando a história tem linhas de desenvolvimento que +divergiram e então foram unificadas novamente, a ordem em que 'git-log' +apresenta essas mudanças é irrelevante. + +A maioria dos projetos com múltiplos contribuidores (como o kernel +Linux, ou o próprio git) tem unificações frequentes, e 'gitk' faz um +trabalho melhor de visualizar sua história. Por exemplo, + +------------------------------------- +$ gitk --since="2 weeks ago" drivers/ +------------------------------------- + +permite a você navegar em quaisquer commits desde as últimas duas semanas +de commits que modificaram arquivos sob o diretório "drivers". (Nota: +você pode ajustar as fontes do gitk segurando a tecla control enquanto +pressiona "-" ou "+".) + +Finalmente, a maioria dos comandos que recebem nomes de arquivo permitirão +também, opcionalmente, preceder qualquer nome de arquivo por um +commit, para especificar uma versão particular do arquivo: + +------------------------------------- +$ git diff v2.5:Makefile HEAD:Makefile.in +------------------------------------- + +Você pode usar 'git-show' para ver tal arquivo: + +------------------------------------- +$ git show v2.5:Makefile +------------------------------------- + +Próximos passos +---------- + +Este tutorial deve ser o bastante para operar controle de revisão +distribuÃdo básico para seus projetos. No entanto, para entender +plenamente a profundidade e o poder do git você precisa entender duas +idéias simples nas quais ele se baseia: + + * A base de objetos é um sistema bem elegante usado para armazenar a + história de seu projeto--arquivos, diretórios, e commits. + + * O arquivo de Ãndice é um cache do estado de uma árvore de diretório, + usado para criar commits, restaurar diretórios de trabalho, e + armazenar as várias árvores envolvidas em uma unificação. + +A parte dois deste tutorial explica a base de objetos, o arquivo de +Ãndice, e algumas outras coisinhas que você vai precisar pra usar o +máximo do git. Você pode encontrá-la em linkgit:gittutorial-2[7]. + +Se você não quiser continuar com o tutorial agora nesse momento, algumas +outras digressões que podem ser interessantes neste ponto são: + + * linkgit:git-format-patch[1], linkgit:git-am[1]: Estes convertem + séries de commits em patches para email, e vice-versa, úteis para + projetos como o kernel Linux que dependem fortemente de patches + enviados por email. + + * linkgit:git-bisect[1]: Quando há uma regressão em seu projeto, uma + forma de rastrear um bug é procurando pela história para encontrar o + commit culpado. Git bisect pode ajudar a executar uma busca binária + por esse commit. Ele é inteligente o bastante para executar uma + busca próxima da ótima mesmo no caso de uma história complexa + não-linear com muitos ramos unificados. + + * link:everyday.html[GIT diariamente com 20 e tantos comandos] + + * linkgit:gitcvs-migration[7]: Git para usuários de CVS. + +VEJA TAMBÉM +-------- +linkgit:gittutorial-2[7], +linkgit:gitcvs-migration[7], +linkgit:gitcore-tutorial[7], +linkgit:gitglossary[7], +linkgit:git-help[1], +link:everyday.html[git diariamente], +link:user-manual.html[O Manual do Usuário git] + +GIT +--- +Parte da suite linkgit:git[1]. diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt index ebdd948cd2..f9811f2473 100644 --- a/Documentation/pull-fetch-param.txt +++ b/Documentation/pull-fetch-param.txt @@ -5,15 +5,14 @@ of a remote (see the section <<REMOTES,REMOTES>> below). <refspec>:: - The canonical format of a <refspec> parameter is - `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed - by the source ref, followed by a colon `:`, followed by - the destination ref. + 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>. -Again, if the optional plus `+` is used, the local ref +If the optional plus `+` is used, the local ref is updated even if it does not result in a fast forward update. + diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 1023ac2b59..bf66116d61 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -13,7 +13,7 @@ include::pretty-options.txt[] Synonym for `--date=relative`. ---date={relative,local,default,iso,rfc,short}:: +--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 @@ -31,6 +31,8 @@ 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). @@ -138,38 +140,38 @@ limiting may be applied. -- -n 'number':: ---max-count='number':: +--max-count=<number>:: Limit the number of commits output. ---skip='number':: +--skip=<number>:: Skip 'number' commits before starting to show the commit output. ---since='date':: ---after='date':: +--since=<date>:: +--after=<date>:: Show commits more recent than a specific date. ---until='date':: ---before='date':: +--until=<date>:: +--before=<date>:: Show commits older than a specific date. ifdef::git-rev-list[] ---max-age='timestamp':: ---min-age='timestamp':: +--max-age=<timestamp>:: +--min-age=<timestamp>:: Limit the commits output to specified time range. endif::git-rev-list[] ---author='pattern':: ---committer='pattern':: +--author=<pattern>:: +--committer=<pattern>:: Limit the commits output to ones with author/committer header lines that match the specified pattern (regular expression). ---grep='pattern':: +--grep=<pattern>:: Limit the commits output to ones with log message that matches the specified pattern (regular expression). @@ -199,6 +201,10 @@ endif::git-rev-list[] 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. @@ -222,6 +228,21 @@ endif::git-rev-list[] 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>'. + ifdef::git-rev-list[] --stdin:: @@ -285,8 +306,52 @@ See also linkgit:git-reflog[1]. History Simplification ~~~~~~~~~~~~~~~~~~~~~~ -When optional paths are given, 'git rev-list' simplifies commits with -various strategies, according to the options you have selected. +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 @@ -413,6 +478,56 @@ 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 @@ -457,11 +572,11 @@ This outputs all the commit objects between the included and excluded commits, ordered by their distance to the included and excluded commits. 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. diff --git a/Documentation/technical/api-history-graph.txt b/Documentation/technical/api-history-graph.txt index d66e61b1ec..d6fc90ac7e 100644 --- a/Documentation/technical/api-history-graph.txt +++ b/Documentation/technical/api-history-graph.txt @@ -11,9 +11,6 @@ Core functions: * `graph_init()` creates a new `struct git_graph` -* `graph_release()` destroys a `struct git_graph`, and frees the memory - associated with it. - * `graph_update()` moves the graph to a new commit. * `graph_next_line()` outputs the next line of the graph into a strbuf. It @@ -134,8 +131,6 @@ while ((commit = get_revision(opts)) != NULL) { putchar(opts->diffopt.line_termination); } } - -graph_release(graph); ------------ Sample output diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt index 539863b1f9..50f9e9ac17 100644 --- a/Documentation/technical/api-parse-options.txt +++ b/Documentation/technical/api-parse-options.txt @@ -60,12 +60,18 @@ Steps to parse options . in `cmd_foo(int argc, const char **argv, const char *prefix)` call - argc = parse_options(argc, argv, builtin_foo_options, builtin_foo_usage, flags); + 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`:: @@ -77,6 +83,28 @@ Flags are the bitwise-or of: 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 -------------- @@ -109,6 +137,10 @@ There are some macros to easily define options: 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`. @@ -135,9 +167,22 @@ There are some macros to easily define options: 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()`. @@ -170,7 +215,7 @@ The function must be defined in this form: The callback mechanism is as follows: -* Inside `funct`, the only interesting member of the structure +* 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()`. diff --git a/Documentation/technical/api-remote.txt b/Documentation/technical/api-remote.txt index 073b22bd83..c54b17db69 100644 --- a/Documentation/technical/api-remote.txt +++ b/Documentation/technical/api-remote.txt @@ -18,6 +18,10 @@ struct remote 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 diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt index 75aa5d4923..b26c28133c 100644 --- a/Documentation/technical/api-run-command.txt +++ b/Documentation/technical/api-run-command.txt @@ -30,17 +30,37 @@ Functions 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`, `run_command_v_opt_cd_env`:: +`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`, or - `RUN_COMMAND_STDOUT_TO_STDERR` that correspond to the members - .no_stdin, .git_cmd, .stdout_to_stderr of `struct child_process`. + 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 @@ -52,6 +72,21 @@ Functions 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 --------------- @@ -128,6 +163,11 @@ string pointers (NULL terminated) in .env: 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` diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt index 4242dc0142..7438149249 100644 --- a/Documentation/technical/api-strbuf.txt +++ b/Documentation/technical/api-strbuf.txt @@ -133,8 +133,10 @@ Functions * Adding data to the buffer -NOTE: All of these functions in this section will grow the buffer as - necessary. +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`:: @@ -205,6 +207,13 @@ 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. @@ -213,7 +222,7 @@ which can be used by the programmer of the callback as she sees fit. Read a given size of data from a FILE* pointer to the buffer. + -NOTE: The buffer is rewinded if the read fails. If -1 is returned, +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. @@ -228,6 +237,11 @@ same behaviour as well. 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 diff --git a/Documentation/technical/api-tree-walking.txt b/Documentation/technical/api-tree-walking.txt index e3ddf91284..55b728632c 100644 --- a/Documentation/technical/api-tree-walking.txt +++ b/Documentation/technical/api-tree-walking.txt @@ -1,12 +1,145 @@ tree walking API ================ -Talk about <tree-walk.h>, things like +The tree walking API is used to traverse and inspect trees. -* struct tree_desc -* init_tree_desc -* tree_entry_extract -* update_tree_entry -* get_tree_entry +Data Structures +--------------- -(JC, Linus) +`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/racy-git.txt b/Documentation/technical/racy-git.txt index 6bdf034b3a..53aa0c82c2 100644 --- a/Documentation/technical/racy-git.txt +++ b/Documentation/technical/racy-git.txt @@ -42,10 +42,12 @@ 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 the value of this member becomes meaningless once the -inode is evicted from the inode cache on filesystems that do not -store it on disk. - +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 -------- @@ -135,7 +137,7 @@ them, and give the same timestamp to the index file: 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 Athron 64X2 3800+, after the above: +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 diff --git a/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt index 41ec7774f4..2a0e7b8944 100644 --- a/Documentation/urls-remotes.txt +++ b/Documentation/urls-remotes.txt @@ -27,10 +27,13 @@ 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` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/urls.txt b/Documentation/urls.txt index fa34c67471..d813ceb723 100644 --- a/Documentation/urls.txt +++ b/Documentation/urls.txt @@ -6,10 +6,10 @@ to name the remote repository: =============================================================== - rsync://host.xz/path/to/repo.git/ -- http://host.xz/path/to/repo.git/ -- https://host.xz/path/to/repo.git/ -- git://host.xz/path/to/repo.git/ -- git://host.xz/~user/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/ @@ -67,3 +67,21 @@ For example, with this: 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.txt b/Documentation/user-manual.txt index 2ae88c575d..c32dd87c8b 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -18,12 +18,22 @@ People needing to do actual development will also want to read Further chapters cover more specialized topics. Comprehensive reference documentation is available through the man -pages. For a command such as "git clone <repo>", just use +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. @@ -49,7 +59,7 @@ 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): + # the Linux kernel (approx. 150MB download): $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git ------------------------------------------------ @@ -178,7 +188,7 @@ As you can see, a commit shows who made the latest change, what they did, and why. Every commit has a 40-hexdigit id, sometimes called the "object name" or the -"SHA1 id", shown on the first line of the "git-show" output. You can usually +"SHA-1 id", shown on the first line of the "git show" output. You can usually refer to a commit by a shorter name, such as a tag or a branch name, but this longer name can also be useful. Most importantly, it is a globally unique name for this commit: so if you tell somebody else the object name (for @@ -297,7 +307,7 @@ ref: refs/heads/master Examining an old version without creating a new branch ------------------------------------------------------ -The git-checkout command normally expects a branch head, but will also +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: @@ -310,7 +320,7 @@ If you want to create a new branch from this checkout, you may do so HEAD is now at 427abfa... Linux v2.6.17 ------------------------------------------------ -The HEAD then refers to the SHA1 of the commit instead of to a branch, +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: ------------------------------------------------ @@ -390,7 +400,7 @@ 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 +Updating a repository with git fetch ------------------------------------ Eventually the developer cloned from will do additional work in her @@ -417,7 +427,7 @@ $ git fetch linux-nfs ------------------------------------------------- New remote-tracking branches will be stored under the shorthand name -that you gave "git-remote add", in this case linux-nfs: +that you gave "git remote add", in this case linux-nfs: ------------------------------------------------- $ git branch -r @@ -506,7 +516,7 @@ $ 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 +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; @@ -582,11 +592,11 @@ 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 +`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 +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 ------------------------------------------------- @@ -729,7 +739,7 @@ $ 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 SHA1's +lower-level command linkgit:git-rev-list[1], which just lists the SHA-1's of all the given commits: ------------------------------------------------- @@ -999,7 +1009,7 @@ $ git init If you have some initial content (say, a tarball): ------------------------------------------------- -$ tar -xzvf project.tar.gz +$ tar xzvf project.tar.gz $ cd project $ git init $ git add . # include everything below ./ in the first commit: @@ -1063,9 +1073,9 @@ $ git diff shows the difference between the working tree and the index file. -Note that "git-add" always adds just the current contents of a file +Note that "git add" always adds just the current contents of a file to the index; further changes to the same file will be ignored unless -you run git-add on the file again. +you run `git add` on the file again. When you're ready, just run @@ -1126,10 +1136,10 @@ 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 +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`". +`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: @@ -1173,7 +1183,23 @@ $ git merge branchname ------------------------------------------------- merges the development in the branch "branchname" into the current -branch. If there are conflicts--for example, if the same file is +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: @@ -1330,7 +1356,7 @@ 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. +unmerged files using external tools such as Emacs or kdiff3. Each time you resolve the conflicts in a file and update the index: @@ -1339,7 +1365,7 @@ $ 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. +`git diff` will (by default) no longer show diffs for that file. [[undoing-a-merge]] Undoing a merge @@ -1436,7 +1462,7 @@ 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>>. +<<undoing-a-merge,destroy it using `git reset`>>. Alternatively, you can edit the working directory and update the index to fix your @@ -1464,7 +1490,7 @@ 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 +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 @@ -1510,10 +1536,10 @@ $ git commit -a -m "blorpl: typofix" ------------------------------------------------ After that, you can go back to what you were working on with -`git stash apply`: +`git stash pop`: ------------------------------------------------ -$ git stash apply +$ git stash pop ------------------------------------------------ @@ -1532,7 +1558,7 @@ $ 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. +you may prefer to run `git gc` when you are not doing other work. [[ensuring-reliability]] @@ -1624,7 +1650,7 @@ 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 +commits in the dangling objects that `git fsck` reports. See <<dangling-objects>> for the details. ------------------------------------------------- @@ -1666,10 +1692,10 @@ Sharing development with others =============================== [[getting-updates-With-git-pull]] -Getting updates with git-pull +Getting updates with git pull ----------------------------- -After you clone a repository and make a few changes of your own, you +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. @@ -1712,7 +1738,7 @@ repository that you pulled from. <<fast-forwards,fast forward>>; instead, your branch will just be updated to point to the latest commit from the upstream branch.) -The git-pull command can also be given "." as the "remote" repository, +The `git pull` command can also be given "." as the "remote" repository, in which case it just merges in a branch from the current repository; so the commands @@ -1785,7 +1811,7 @@ 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 +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. @@ -1837,7 +1863,7 @@ 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 +first create a new clone of the repository and tell `git daemon` that it is meant to be public: ------------------------------------------------- @@ -1868,10 +1894,10 @@ 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 +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 +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.) @@ -1932,7 +1958,7 @@ 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 +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. @@ -1942,7 +1968,7 @@ 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 +As with `git fetch`, you may also set up configuration options to save typing; so, for example, after ------------------------------------------------- @@ -1978,13 +2004,13 @@ 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 + - 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 + - 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 +You may force `git push` to perform the update anyway by preceding the branch name with a plus sign: ------------------------------------------------- @@ -2026,7 +2052,7 @@ 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 + 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. @@ -2394,7 +2420,7 @@ 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 +Keeping a patch series up to date using git rebase -------------------------------------------------- Suppose that you create a branch "mywork" on a remote-tracking branch @@ -2458,9 +2484,9 @@ patches to the new mywork. The result will look like: ................................................ 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" +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 +running `git commit`, just run ------------------------------------------------- $ git rebase --continue @@ -2498,7 +2524,7 @@ with $ git tag bad mywork~5 ------------------------------------------------- -(Either gitk or git-log may be useful for finding the commit.) +(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 @@ -2539,12 +2565,12 @@ $ 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 `commit --amend`. +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 +Another technique is to use `git format-patch` to create a series of patches, then reset the state to before the patches: ------------------------------------------------- @@ -2652,7 +2678,7 @@ 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 +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, @@ -2715,7 +2741,7 @@ master branch. In more detail: git fetch and fast-forwards --------------------------- -In the previous example, when updating an existing branch, "git-fetch" +In the previous example, when updating an existing branch, "git fetch" checks to make sure that the most recent commit on the remote branch is a descendant of the most recent commit on your copy of the branch before updating your copy of the branch to point at the new @@ -2741,7 +2767,7 @@ resulting in a situation like: o--o--o <-- new head of the branch ................................................ -In this case, "git-fetch" will fail, and print out a warning. +In this case, "git fetch" will fail, and print out a warning. In that case, you can still force git to update to the new head, as described in the following section. However, note that in the @@ -2750,7 +2776,7 @@ unless you've already created a reference of your own pointing to them. [[forcing-fetch]] -Forcing git-fetch to do non-fast-forward updates +Forcing git fetch to do non-fast-forward updates ------------------------------------------------ If git fetch fails because the new head of a branch is not a @@ -2855,8 +2881,8 @@ 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 SHA1 hash of the -contents of the object. The SHA1 hash is a cryptographic hash function. +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: @@ -2867,10 +2893,10 @@ others: 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 SHA1 hash of its contents. + object's name is still the SHA-1 hash of its contents. (See <<object-details>> for the details of the object formatting and -SHA1 calculation.) +SHA-1 calculation.) There are four different types of objects: "blob", "tree", "commit", and "tag". @@ -2916,9 +2942,9 @@ committer Junio C Hamano <gitster@pobox.com> 1187591163 -0700 As you can see, a commit is defined by: -- a tree: The SHA1 name of a tree object (as defined below), representing +- 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 SHA1 name of some number of commits which represent the +- 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 @@ -2967,13 +2993,13 @@ $ git ls-tree fb3a8bdd0ce ------------------------------------------------ As you can see, a tree object contains a list of entries, each with a -mode, object type, SHA1 name, and name, sorted by name. It represents +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 SHA1 hash of their -contents, two trees have the same SHA1 name if and only if their +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 @@ -3019,15 +3045,15 @@ currently checked out. Trust ~~~~~ -If you receive the SHA1 name of a blob from one source, and its contents +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 SHA1 name agrees. This is because -the SHA1 is designed so that it is infeasible to find different contents +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 SHA1 name of a top-level tree object +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 SHA1 name of a commit from a trusted source, then you +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. @@ -3039,7 +3065,7 @@ that you trust that commit, and the immutability of the history of commits tells others that they can trust the whole history. In other words, you can easily validate a whole archive by just -sending out a single email that tells the people the name (SHA1 hash) +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. @@ -3080,7 +3106,7 @@ How git stores objects efficiently: pack files ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Newly created objects are initially created in a file named after the -object's SHA1 hash (stored in .git/objects). +object's SHA-1 hash (stored in .git/objects). Unfortunately this system becomes inefficient once a project has a lot of objects. Try this on an old project: @@ -3121,7 +3147,7 @@ $ git prune to remove any of the "loose" objects that are now contained in the pack. This will also remove any unreferenced objects (which may be -created when, for example, you use "git-reset" to remove a commit). +created when, for example, you use "git reset" to remove a commit). You can verify that the loose objects are gone by looking at the .git/objects directory or by running @@ -3150,7 +3176,7 @@ branch still exists, as does everything it pointed to. The branch pointer itself just doesn't, since you replaced it with another one. There are also other situations that cause dangling objects. For -example, a "dangling blob" may arise because you did a "git-add" of a +example, a "dangling blob" may arise because you did a "git add" of a file, but then, before you actually committed it and made it part of the bigger picture, you changed something else in that file and committed that *updated* thing--the old state that you added originally ends up @@ -3200,7 +3226,7 @@ Usually, dangling blobs and trees aren't very interesting. They're almost always the result of either being a half-way mergebase (the blob will often even have the conflict markers from a merge in it, if you have had conflicting merges that you fixed up by hand), or simply -because you interrupted a "git-fetch" with ^C or something like that, +because you interrupted a "git fetch" with ^C or something like that, leaving _some_ of the new objects in the object database, but just dangling and useless. @@ -3215,9 +3241,9 @@ 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. +(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 @@ -3287,7 +3313,7 @@ $ git hash-object -w somedirectory/myfile ------------------------------------------------ which will create and store a blob object with the contents of -somedirectory/myfile, and output the sha1 of that object. if you're +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! @@ -3349,7 +3375,7 @@ 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 SHA1 of a blob +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: ------------------------------------------------- @@ -3479,14 +3505,14 @@ done NOTE: Do not use local URLs here if you plan to publish your superproject! -See what files `git-submodule` created: +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: +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. @@ -3532,7 +3558,7 @@ 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 +Now use `git submodule update` to clone the repositories and check out the commits specified in the superproject: ------------------------------------------------- @@ -3542,8 +3568,8 @@ $ 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 +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. @@ -3744,7 +3770,7 @@ unsaved state that you might want to restore later!) your current index. Normal operation is just ------------------------------------------------- -$ git read-tree <sha1 of tree> +$ git read-tree <SHA-1 of tree> ------------------------------------------------- and your index file will now be equivalent to the tree that you saved @@ -3759,7 +3785,7 @@ 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`). +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 @@ -3772,7 +3798,7 @@ $ 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 +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. @@ -3810,7 +3836,7 @@ $ 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 +`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 @@ -3879,7 +3905,7 @@ $ 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 +`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 @@ -3968,13 +3994,13 @@ $ git ls-files --unmerged ------------------------------------------------ Each line of the `git ls-files --unmerged` output begins with -the blob mode bits, blob SHA1, 'stage number', and the +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 +`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 @@ -4001,20 +4027,20 @@ $ 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 +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 +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. +and that is what higher level `git merge -s resolve` is implemented with. [[hacking-git]] Hacking git @@ -4035,12 +4061,12 @@ objects). There are currently four different object types: "blob", Regardless of object type, all objects share the following characteristics: they are all deflated with zlib, and have a header that not only specifies their type, but also provides size information -about the data in the object. It's worth noting that the SHA1 hash +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 sha1 of the 'compressed' object.) +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 @@ -4051,7 +4077,7 @@ 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 +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). @@ -4110,7 +4136,7 @@ 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: +Basically, the initial version of `git log` was a shell script: ---------------------------------------------------------------- $ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \ @@ -4119,20 +4145,20 @@ $ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \ What does this mean? -`git-rev-list` is the original version of the revision walker, which +`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 programs start out as scripts using -`git-rev-list`. +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 +`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 +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 +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 @@ -4145,7 +4171,7 @@ 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 +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`, @@ -4161,7 +4187,7 @@ 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, +`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. @@ -4172,9 +4198,9 @@ 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`. +`git show` or `git cat-file`. -For the sake of clarity, let's stay with `git-cat-file`, because it +For the sake of clarity, let's stay with `git cat-file`, because it - is plumbing, and @@ -4188,7 +4214,7 @@ it does. ------------------------------------------------------------------ git_config(git_default_config); if (argc != 3) - usage("git-cat-file [-t|-s|-e|-p|<type>] <sha1>"); + 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]); ------------------------------------------------------------------ @@ -4233,10 +4259,10 @@ To find out how the result can be used, just read on in `cmd_cat_file()`: ----------------------------------- 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 +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 +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!): @@ -4356,7 +4382,9 @@ $ git remote show example # get details * remote example URL: git://example.com/project.git Tracked remote branches - master next ... + master + next + ... $ git fetch example # update branches from example $ git branch -r # list all remote branches ----------------------------------------------- @@ -4518,7 +4546,7 @@ The basic requirements: - 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" + 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 |