diff options
Diffstat (limited to 'Documentation')
44 files changed, 827 insertions, 192 deletions
diff --git a/Documentation/Makefile b/Documentation/Makefile index 5d76a84078..267dfe135d 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -44,9 +44,10 @@ man5dir=$(mandir)/man5 man7dir=$(mandir)/man7 # DESTDIR= -ASCIIDOC=asciidoc +ASCIIDOC = asciidoc ASCIIDOC_EXTRA = MANPAGE_XSL = manpage-normal.xsl +XMLTO = xmlto XMLTO_EXTRA = INSTALL?=install RM ?= rm -f @@ -66,12 +67,6 @@ endif -include ../config.mak # -# For asciidoc ... -# -7.1.2, set ASCIIDOC7 -# 8.0-, no extra settings are needed -# - -# # For docbook-xsl ... # -1.68.1, no extra settings are needed? # 1.69.0, set ASCIIDOC_ROFF? @@ -81,9 +76,6 @@ endif # 1.73.0-, no extra settings are needed # -ifndef ASCIIDOC7 -ASCIIDOC_EXTRA += -a asciidoc7compatible -endif ifdef DOCBOOK_XSL_172 ASCIIDOC_EXTRA += -a git-asciidoc-no-roff MANPAGE_XSL = manpage-1.72.xsl @@ -134,15 +126,6 @@ DEFAULT_EDITOR_SQ = $(subst ','\'',$(DEFAULT_EDITOR)) ASCIIDOC_EXTRA += -a 'git-default-editor=$(DEFAULT_EDITOR_SQ)' endif -# -# Please note that there is a minor bug in asciidoc. -# The version after 6.0.3 _will_ include the patch found here: -# http://marc.theaimsgroup.com/?l=git&m=111558757202243&w=2 -# -# Until that version is released you may have to apply the patch -# yourself - yes, all 6 characters of it! -# - QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir QUIET_SUBDIR1 = @@ -263,7 +246,7 @@ manpage-base-url.xsl: manpage-base-url.xsl.in %.1 %.5 %.7 : %.xml manpage-base-url.xsl $(QUIET_XMLTO)$(RM) $@ && \ - xmlto -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $< + $(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $< %.xml : %.txt $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ @@ -362,4 +345,7 @@ require-htmlrepo:: quick-install-html: require-htmlrepo '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REPO) $(DESTDIR)$(htmldir) +print-man1: + @for i in $(MAN1_TXT); do echo $$i; done + .PHONY: FORCE diff --git a/Documentation/RelNotes/1.7.12.1.txt b/Documentation/RelNotes/1.7.12.1.txt new file mode 100644 index 0000000000..b8f04af19f --- /dev/null +++ b/Documentation/RelNotes/1.7.12.1.txt @@ -0,0 +1,134 @@ +Git 1.7.12.1 Release Notes +========================== + +Fixes since v1.7.12 +------------------- + + * "git apply -p0" did not parse pathnames on "diff --git" line + correctly. This caused patches that had pathnames in no other + places to be mistakenly rejected (most notably, binary patch that + does not rename nor change mode). Textual patches, renames or mode + changes have preimage and postimage pathnames in different places + in a form that can be parsed unambiguously and did not suffer from + this problem. + + * "git cherry-pick A C B" used to replay changes in A and then B and + then C if these three commits had committer timestamps in that + order, which is not what the user who said "A C B" naturally + expects. + + * "git commit --amend" let the user edit the log message and then + died when the human-readable committer name was given + insufficiently by getpwent(3). + + * Some capabilities were asked by fetch-pack even when upload-pack + did not advertise that they are available. fetch-pack has been + fixed not to do so. + + * "git diff" had a confusion between taking data from a path in the + working tree and taking data from an object that happens to have + name 0{40} recorded in a tree. + + * "git for-each-ref" did not correctly support more than one --sort + option. + + * "git log .." errored out saying it is both rev range and a path + when there is no disambiguating "--" is on the command line. + Update the command line parser to interpret ".." as a path in such + a case. + + * The "--topo-order", "--date-order" (and the lack of either means + the default order) options to "rev-list" and "log" family of + commands were poorly described in the documentation. + + * "git prune" without "-v" used to warn about leftover temporary + files (which is an indication of an earlier aborted operation). + + * Pushing to smart HTTP server with recent Git fails without having + the username in the URL to force authentication, if the server is + configured to allow GET anonymously, while requiring authentication + for POST. + + * The reflog entries left by "git rebase" and "git rebase -i" were + inconsistent (the interactive one gave an abbreviated object name). + + * When "git push" triggered the automatic gc on the receiving end, a + message from "git prune" that said it was removing cruft leaked to + the standard output, breaking the communication protocol. + + * "git show --quiet" ought to be a synonym for "git show -s", but + wasn't. + + * "git show --format='%ci'" did not give timestamp correctly for + commits created without human readable name on "committer" line. + + * "git send-email" did not unquote encoded words that appear on the + header correctly, and lost "_" from strings. + + * The interactive prompt "git send-email" gives was error prone. It + asked "What e-mail address do you want to use?" with the address it + guessed (correctly) the user would want to use in its prompt, + tempting the user to say "y". But the response was taken as "No, + please use 'y' as the e-mail address instead", which is most + certainly not what the user meant. + + * "gitweb" when used with PATH_INFO failed to notice directories with + SP (and other characters that need URL-style quoting) in them. + + * When the user gives an argument that can be taken as both a + revision name and a pathname without disambiguating with "--", we + used to give a help message "Use '--' to separate". The message + has been clarified to show where that '--' goes on the command + line. + + * When the user exports a non-default IFS without HT, scripts that + rely on being able to parse "ls-files -s | while read a b c..." + started to fail. Protect them from such a misconfiguration. + + * The attribute system may be asked for a path that itself or its + leading directories no longer exists in the working tree, and it is + fine if we cannot open .gitattribute file in such a case. Failure + to open per-directory .gitattributes with error status other than + ENOENT and ENOTDIR should be diagnosed, but it wasn't. + + * After "gitk" showed the contents of a tag, neither "Reread + references" nor "Reload" did not update what is shown as the + contents of it, when the user overwrote the tag with "git tag -f". + + * "ciabot" script (in contrib/) has been updated with extensive + documentation. + + * "git-jump" script (in contrib/) did not work well when + diff.noprefix or diff.mnemonicprefix is in effect. + + * Older parts of the documentation described as if having a regular + file in .git/refs/ hierarchy were the only way to have branches and + tags, which is not true for quite some time. + + * A utility shell function test_seq has been added as a replacement + for the 'seq' utility found on some platforms. + + * Compatibility wrapper to learn the maximum number of file + descriptors we can open around sysconf(_SC_OPEN_MAX) and + getrlimit(RLIMIT_NO_FILE) has been introduced for portability. + + * We used curl_easy_strerror() without checking version of cURL, + breaking the build for versions before curl 7.12.0. + + * Code to work around MacOS X UTF-8 gotcha has been cleaned up. + + * Fallback 'getpass' implementation made unportable use of stdio API. + + * The "--rebase" option to "git pull" can be abbreviated to "-r", + but we didn't document it. + + * It was generally understood that "--long-option"s to many of our + subcommands can be abbreviated to the unique prefix, but it was not + easy to find it described for new readers of the documentation set. + + * The synopsis said "checkout [-B branch]" to make it clear the + branch name is a parameter to the option, but the heading for the + option description was "-B::", not "-B branch::", making the + documentation misleading. + +Also contains numerous documentation updates. diff --git a/Documentation/RelNotes/1.7.12.2.txt b/Documentation/RelNotes/1.7.12.2.txt new file mode 100644 index 0000000000..69255745e6 --- /dev/null +++ b/Documentation/RelNotes/1.7.12.2.txt @@ -0,0 +1,40 @@ +Git 1.7.12.2 Release Notes +========================== + +Fixes since v1.7.12.1 +--------------------- + + * When "git am" is fed an input that has multiple "Content-type: ..." + header, it did not grok charset= attribute correctly. + + * Even during a conflicted merge, "git blame $path" always meant to + blame uncommitted changes to the "working tree" version; make it + more useful by showing cleanly merged parts as coming from the other + branch that is being merged. + + * "git blame MAKEFILE" run in a history that has "Makefile" but not + "MAKEFILE" should say "No such file MAKEFILE in HEAD", but got + confused on a case insensitive filesystem and failed to do so. + + * "git fetch --all", when passed "--no-tags", did not honor the + "--no-tags" option while fetching from individual remotes (the same + issue existed with "--tags", but combination "--all --tags" makes + much less sense than "--all --no-tags"). + + * "git log/diff/format-patch --stat" showed the "N line(s) added" + comment in user's locale and caused careless submitters to send + patches with such a line in them to projects whose project language + is not their language, mildly irritating others. Localization to + the line has been disabled for now. + + * "git log --all-match --grep=A --grep=B" ought to show commits that + mention both A and B, but when these three options are used with + --author or --committer, it showed commits that mention either A or + B (or both) instead. + + * The subcommand to remove the definition of a remote in "git remote" + was named "rm" even though all other subcommands were spelled out. + Introduce "git remote remove" to remove confusion, and keep "rm" as + a backward compatible synonym. + +Also contains a handful of documentation updates. diff --git a/Documentation/RelNotes/1.7.12.3.txt b/Documentation/RelNotes/1.7.12.3.txt new file mode 100644 index 0000000000..ecda427a35 --- /dev/null +++ b/Documentation/RelNotes/1.7.12.3.txt @@ -0,0 +1,34 @@ +Git 1.7.12.3 Release Notes +========================== + +Fixes since v1.7.12.2 +--------------------- + + * "git am" mishandled a patch attached as application/octet-stream + (e.g. not text/*); Content-Transfer-Encoding (e.g. base64) was not + honored correctly. + + * It was unclear in the documentation for "git blame" that it is + unnecessary for users to use the "--follow" option. + + * A repository created with "git clone --single" had its fetch + refspecs set up just like a clone without "--single", leading the + subsequent "git fetch" to slurp all the other branches, defeating + the whole point of specifying "only this branch". + + * "git fetch" over http had an old workaround for an unlikely server + misconfiguration; it turns out that this hurts debuggability of the + configuration in general, and has been reverted. + + * "git fetch" over http advertised that it supports "deflate", which + is much less common, and did not advertise the more common "gzip" on + its Accept-Encoding header. + + * "git receive-pack" (the counterpart to "git push") did not give + progress output while processing objects it received to the puser + when run over the smart-http protocol. + + * "git status" honored the ignore=dirty settings in .gitmodules but + "git commit" didn't. + +Also contains a handful of documentation updates. diff --git a/Documentation/RelNotes/1.7.12.txt b/Documentation/RelNotes/1.7.12.txt new file mode 100644 index 0000000000..010d8c7de4 --- /dev/null +++ b/Documentation/RelNotes/1.7.12.txt @@ -0,0 +1,136 @@ +Git v1.7.12 Release Notes +========================= + +Updates since v1.7.11 +--------------------- + +UI, Workflows & Features + + * Git can be told to normalize pathnames it read from readdir(3) and + all arguments it got from the command line into precomposed UTF-8 + (assuming that they come as decomposed UTF-8), in order to work + around issues on Mac OS. + + I think there still are other places that need conversion + (e.g. paths that are read from stdin for some commands), but this + should be a good first step in the right direction. + + * Per-user $HOME/.gitconfig file can optionally be stored in + $HOME/.config/git/config instead, which is in line with XDG. + + * The value of core.attributesfile and core.excludesfile default to + $HOME/.config/git/attributes and $HOME/.config/git/ignore respectively + when these files exist. + + * Logic to disambiguate abbreviated object names have been taught to + take advantage of object types that are expected in the context, + e.g. XXXXXX in the "git describe" output v1.2.3-gXXXXXX must be a + commit object, not a blob nor a tree. This will help us prolong + the lifetime of abbreviated object names. + + * "git apply" learned to wiggle the base version and perform three-way + merge when a patch does not exactly apply to the version you have. + + * Scripted Porcelain writers now have access to the credential API via + the "git credential" plumbing command. + + * "git help" used to always default to "man" format even on platforms + where "man" viewer is not widely available. + + * "git clone --local $path" started its life as an experiment to + optionally use link/copy when cloning a repository on the disk, but + we didn't deprecate it after we made the option a no-op to always + use the optimization. The command learned "--no-local" option to + turn this off, as a more explicit alternative over use of file:// + URL. + + * "git fetch" and friends used to say "remote side hung up + unexpectedly" when they failed to get response they expect from the + other side, but one common reason why they don't get expected + response is that the remote repository does not exist or cannot be + read. The error message in this case was updated to give better + hints to the user. + + * "git help -w $cmd" can show HTML version of documentation for + "git-$cmd" by setting help.htmlpath to somewhere other than the + default location where the build procedure installs them locally; + the variable can even point at a http:// URL. + + * "git rebase [-i] --root $tip" can now be used to rewrite all the + history leading to "$tip" down to the root commit. + + * "git rebase -i" learned "-x <cmd>" to insert "exec <cmd>" after + each commit in the resulting history. + + * "git status" gives finer classification to various states of paths + in conflicted state and offer advice messages in its output. + + * "git submodule" learned to deal with nested submodule structure + where a module is contained within a module whose origin is + specified as a relative URL to its superproject's origin. + + * A rather heavy-ish "git completion" script has been split to create + a separate "git prompting" script, to help lazy-autoloading of the + completion part while making prompting part always available. + + * "gitweb" pays attention to various forms of credits that are + similar to "Signed-off-by:" lines in the commit objects and + highlights them accordingly. + + +Foreign Interface + + * "mediawiki" remote helper (in contrib/) learned to handle file + attachments. + + * "git p4" now uses "Jobs:" and "p4 move" when appropriate. + + * vcs-svn has been updated to clean-up compilation, lift 32-bit + limitations, etc. + + +Performance, Internal Implementation, etc. (please report possible regressions) + + * Some tests showed false failures caused by a bug in ecryptofs. + + * We no longer use AsciiDoc7 syntax in our documentation and favor a + more modern style. + + * "git am --rebasing" codepath was taught to grab authorship, log + message and the patch text directly out of existing commits. This + will help rebasing commits that have confusing "diff" output in + their log messages. + + * "git index-pack" and "git pack-objects" use streaming API to read + from the object store to avoid having to hold a large blob object + in-core while they are doing their thing. + + * Code to match paths with exclude patterns learned to avoid calling + fnmatch() by comparing fixed leading substring literally when + possible. + + * "git log -n 1 -- rarely-touched-path" was spending unnecessary + cycles after showing the first change to find the next one, only to + discard it. + + * "git svn" got a large-looking code reorganization at the last + minute before the code freeze. + + +Also contains minor documentation updates and code clean-ups. + + +Fixes since v1.7.11 +------------------- + +Unless otherwise noted, all the fixes since v1.7.11 in the maintenance +releases are contained in this release (see release notes to them for +details). + + * "git submodule add" was confused when the superproject did not have + its repository in its usual place in the working tree and GIT_DIR + and GIT_WORK_TREE was used to access it. + + * "git commit --amend" let the user edit the log message and then died + when the human-readable committer name was given insufficiently by + getpwent(3). diff --git a/Documentation/config.txt b/Documentation/config.txt index b49feb582e..122e3c4996 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -159,9 +159,10 @@ advice.*:: specified a refspec that isn't your current branch) and it resulted in a non-fast-forward error. statusHints:: - Directions on how to stage/unstage/add shown in the - output of linkgit:git-status[1] and the template shown - when writing commit messages. + Show directions on how to proceed from the current + state in the output of linkgit:git-status[1] and in + the template shown when writing commit messages in + linkgit:git-commit[1]. commitBeforeMerge:: Advice shown when linkgit:git-merge[1] refuses to merge to avoid overwriting local changes. @@ -213,6 +214,15 @@ The default is false, except linkgit:git-clone[1] or linkgit:git-init[1] will probe and set core.ignorecase true if appropriate when the repository is created. +core.precomposeunicode:: + This option is only used by Mac OS implementation of git. + When core.precomposeunicode=true, git reverts the unicode decomposition + of filenames done by Mac OS. This is useful when sharing a repository + between Mac OS and Linux or Windows. + (Git for Windows 1.7.10 or higher is needed, or git under cygwin 1.7). + When false, file names are handled fully transparent by git, + which is backward compatible with older versions of git. + core.trustctime:: If false, the ctime differences between the index and the working tree are ignored; useful when the inode change time @@ -486,7 +496,9 @@ core.excludesfile:: '.git/info/exclude', git looks into this file for patterns of files which are not meant to be tracked. "`~/`" is expanded to the value of `$HOME` and "`~user/`" to the specified user's - home directory. See linkgit:gitignore[5]. + home directory. Its default value is $XDG_CONFIG_HOME/git/ignore. + If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore + is used instead. See linkgit:gitignore[5]. core.askpass:: Some commands (e.g. svn and http interfaces) that interactively @@ -501,7 +513,9 @@ core.attributesfile:: In addition to '.gitattributes' (per-directory) and '.git/info/attributes', git looks into this file for attributes (see linkgit:gitattributes[5]). Path expansions are made the same - way as for `core.excludesfile`. + way as for `core.excludesfile`. Its default value is + $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME is either not + set or empty, $HOME/.config/git/attributes is used instead. core.editor:: Commands such as `commit` and `tag` that lets you edit @@ -545,8 +559,9 @@ core.whitespace:: * `space-before-tab` treats a space character that appears immediately before a tab character in the initial indent part of the line as an error (enabled by default). -* `indent-with-non-tab` treats a line that is indented with 8 or more - space characters as an error (not enabled by default). +* `indent-with-non-tab` treats a line that is indented with space + characters instead of the equivalent tabs as an error (not enabled by + default). * `tab-in-indent` treats a tab character in the initial indent part of the line as an error (not enabled by default). * `blank-at-eof` treats blank lines added at the end of file as an error @@ -883,7 +898,7 @@ column.ui:: make equal size columns -- + - This option defaults to 'never'. +This option defaults to 'never'. column.branch:: Specify whether to output branch listing in `git branch` in columns. @@ -1723,6 +1738,7 @@ push.default:: 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 branches having the same name in both ends. This is for those who prepare all the branches into a publishable @@ -1742,12 +1758,13 @@ push.default:: option and is well-suited for beginners. It will become the default in Git 2.0. * `current` - push the current branch to a branch of the same name. - + - The `simple`, `current` and `upstream` modes are for those who want to - push out a single branch after finishing work, even when the other - branches are not yet ready to be pushed out. If you are working with - other people to push into the same shared repository, you would want - to use one of these. +-- ++ +The `simple`, `current` and `upstream` modes are for those who want to +push out a single branch after finishing work, even when the other +branches are not yet ready to be pushed out. If you are working with +other people to push into the same shared repository, you would want +to use one of these. rebase.stat:: Whether to show a diffstat of what changed upstream since the last diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 39d326abc6..b4d6476ac8 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -10,7 +10,8 @@ --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. + to the specified number of commits from the tip of each remote + branch history. Tags for the deepened commits are not fetched. ifndef::git-pull[] --dry-run:: diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 9c1d395722..fd9e36b99f 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -155,7 +155,7 @@ Configuration The optional configuration variable `core.excludesfile` indicates a path to a file containing patterns of file names to exclude from git-add, similar to $GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to -those in info/exclude. See linkgit:gitrepository-layout[5]. +those in info/exclude. See linkgit:gitignore[5]. EXAMPLES diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt index afd2c9ae59..634b84e4b9 100644 --- a/Documentation/git-apply.txt +++ b/Documentation/git-apply.txt @@ -9,7 +9,7 @@ git-apply - Apply a patch to files and/or to the index SYNOPSIS -------- [verse] -'git apply' [--stat] [--numstat] [--summary] [--check] [--index] +'git apply' [--stat] [--numstat] [--summary] [--check] [--index] [--3way] [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse] [--allow-binary-replacement | --binary] [--reject] [-z] [-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached] @@ -72,6 +72,15 @@ OPTIONS cached data, apply the patch, and store the result in the index without using the working tree. This implies `--index`. +-3:: +--3way:: + When the patch does not apply cleanly, fall back on 3-way merge if + the patch records the identity of blobs it is supposed to apply to, + and we have those blobs available locally, possibly leaving the + conflict markers in the files in the working tree for the user to + resolve. This option implies the `--index` option, and is incompatible + with the `--reject` and the `--cached` options. + --build-fake-ancestor=<file>:: Newer 'git diff' output has embedded 'index information' for each blob to help identify the original version that diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index 7ee923629e..e44173f66a 100644 --- a/Documentation/git-blame.txt +++ b/Documentation/git-blame.txt @@ -20,6 +20,12 @@ last modified the line. Optionally, start annotating from the given revision. The command can also limit the range of lines annotated. +The origin of lines is automatically followed across whole-file +renames (currently there is no option to turn the rename-following +off). To follow lines moved from one file to another, or to follow +lines that were copied and pasted from another file, etc., see the +`-C` and `-M` options. + The report does not tell you anything about lines which have been deleted or replaced; you need to use a tool such as 'git diff' or the "pickaxe" interface briefly mentioned in the following paragraph. diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 47235bea04..4f441311c2 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -129,11 +129,13 @@ This option is only applicable in non-verbose mode. use `git branch --list <pattern>` to list matching branches. -v:: +-vv:: --verbose:: When in list mode, show sha1 and commit subject line for each head, along with relationship to upstream branch (if any). If given twice, print - the name of the upstream branch, as well. + the name of the upstream branch, as well (see also `git remote + show <remote>`). -q:: --quiet:: diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt index 79fb984144..9f42c0d0e6 100644 --- a/Documentation/git-clean.txt +++ b/Documentation/git-clean.txt @@ -63,6 +63,10 @@ OPTIONS Remove only files ignored by git. This may be useful to rebuild everything from scratch, but keep manually created files. +SEE ALSO +-------- +linkgit:gitignore[5] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index 6e22522c4f..6d98ef3d2a 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -29,7 +29,8 @@ currently active branch. After the clone, a plain `git fetch` without arguments will update all the remote-tracking branches, and a `git pull` without arguments will in addition merge the remote master branch into the -current master branch, if any. +current master branch, if any (this is untrue when "--single-branch" +is given; see below). This default configuration is achieved by creating references to the remote branch heads under `refs/remotes/origin` and @@ -46,13 +47,18 @@ OPTIONS mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under `.git/objects/` directory are hardlinked - to save space when possible. This is now the default when - the source repository is specified with `/path/to/repo` - syntax, so it essentially is a no-op option. To force - copying instead of hardlinking (which may be desirable - if you are trying to make a back-up of your repository), - but still avoid the usual "git aware" transport - mechanism, `--no-hardlinks` can be used. + to save space when possible. ++ +If the repository is specified as a local path (e.g., `/path/to/repo`), +this is the default, and --local is essentially a no-op. If the +repository is specified as a URL, then this flag is ignored (and we +never use the local optimizations). Specifying `--no-local` will +override the default when `/path/to/repo` is given, using the regular +git transport instead. ++ +To force copying instead of hardlinking (which may be desirable if you +are trying to make a back-up of your repository), but still avoid the +usual "git aware" transport mechanism, `--no-hardlinks` can be used. --no-hardlinks:: Optimize the cloning process from a repository on a @@ -147,9 +153,10 @@ objects from the source repository into a pack in the cloned repository. -b <name>:: Instead of pointing the newly created HEAD to the branch pointed to by the cloned repository's HEAD, point to `<name>` branch - instead. `--branch` can also take tags and treat them like - detached HEAD. In a non-bare repository, this is the branch - that will be checked out. + instead. In a non-bare repository, this is the branch that will + be checked out. + `--branch` can also take tags and detaches the HEAD at that commit + in the resulting repository. --upload-pack <upload-pack>:: -u <upload-pack>:: @@ -188,6 +195,11 @@ objects from the source repository into a pack in the cloned repository. clone with the `--depth` option, this is the default, unless `--no-single-branch` is given to fetch the histories near the tips of all branches. + Further fetches into the resulting repository will only update the + remote tracking branch for the branch this option was used for the + initial cloning. If the HEAD at the remote did not point at any + branch when `--single-branch` clone was made, no remote tracking + branch is created. --recursive:: --recurse-submodules:: diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 4622297ec9..9594ac8e9d 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -389,8 +389,10 @@ DISCUSSION Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. -Tools that turn commits into email, for example, use the first line -on the Subject: line and the rest of the commit in the body. +The text up to the first blank line in a commit message is treated +as the commit title, and that title is used throughout git. +For example, linkgit:git-format-patch[1] turns a commit into email, and it uses +the title on the Subject line and the rest of the commit in the body. include::i18n.txt[] diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index 21b8f6110b..eaea079165 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -97,10 +97,11 @@ OPTIONS --global:: For writing options: write to global ~/.gitconfig file rather than - the repository .git/config. + the repository .git/config, write to $XDG_CONFIG_HOME/git/config file + if this file exists and the ~/.gitconfig file doesn't. + -For reading options: read only from global ~/.gitconfig rather than -from all available files. +For reading options: read only from global ~/.gitconfig and from +$XDG_CONFIG_HOME/git/config rather than from all available files. + See also <<FILES>>. @@ -194,7 +195,7 @@ See also <<FILES>>. FILES ----- -If not set explicitly with '--file', there are three files where +If not set explicitly with '--file', there are four files where 'git config' will search for configuration options: $GIT_DIR/config:: @@ -204,6 +205,14 @@ $GIT_DIR/config:: User-specific configuration file. Also called "global" configuration file. +$XDG_CONFIG_HOME/git/config:: + Second user-specific configuration file. If $XDG_CONFIG_HOME is not set + or empty, $HOME/.config/git/config will be used. Any single-valued + variable set in this file will be overwritten by whatever is in + ~/.gitconfig. It is a good idea not to create this file if + you sometimes use older versions of Git, as support for this + file was added fairly recently. + $(prefix)/etc/gitconfig:: System-wide configuration file. diff --git a/Documentation/git-credential-cache--daemon.txt b/Documentation/git-credential-cache--daemon.txt index 11edc5a173..d15db42d43 100644 --- a/Documentation/git-credential-cache--daemon.txt +++ b/Documentation/git-credential-cache--daemon.txt @@ -3,7 +3,7 @@ git-credential-cache--daemon(1) NAME ---- -git-credential-cache--daemon - temporarily store user credentials in memory +git-credential-cache--daemon - Temporarily store user credentials in memory SYNOPSIS -------- diff --git a/Documentation/git-credential-cache.txt b/Documentation/git-credential-cache.txt index f3d09c5d51..eeff5fa989 100644 --- a/Documentation/git-credential-cache.txt +++ b/Documentation/git-credential-cache.txt @@ -3,7 +3,7 @@ git-credential-cache(1) NAME ---- -git-credential-cache - helper to temporarily store passwords in memory +git-credential-cache - Helper to temporarily store passwords in memory SYNOPSIS -------- diff --git a/Documentation/git-credential-store.txt b/Documentation/git-credential-store.txt index 31093467d1..b27c03c361 100644 --- a/Documentation/git-credential-store.txt +++ b/Documentation/git-credential-store.txt @@ -3,7 +3,7 @@ git-credential-store(1) NAME ---- -git-credential-store - helper to store credentials on disk +git-credential-store - Helper to store credentials on disk SYNOPSIS -------- diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt new file mode 100644 index 0000000000..810e957124 --- /dev/null +++ b/Documentation/git-credential.txt @@ -0,0 +1,154 @@ +git-credential(1) +================= + +NAME +---- +git-credential - Retrieve and store user credentials + +SYNOPSIS +-------- +------------------ +git credential <fill|approve|reject> +------------------ + +DESCRIPTION +----------- + +Git has an internal interface for storing and retrieving credentials +from system-specific helpers, as well as prompting the user for +usernames and passwords. The git-credential command exposes this +interface to scripts which may want to retrieve, store, or prompt for +credentials in the same manner as git. The design of this scriptable +interface models the internal C API; see +link:technical/api-credentials.txt[the git credential API] for more +background on the concepts. + +git-credential takes an "action" option on the command-line (one of +`fill`, `approve`, or `reject`) and reads a credential description +on stdin (see <<IOFMT,INPUT/OUTPUT FORMAT>>). + +If the action is `fill`, git-credential will attempt to add "username" +and "password" attributes to the description by reading config files, +by contacting any configured credential helpers, or by prompting the +user. The username and password attributes of the credential +description are then printed to stdout together with the attributes +already provided. + +If the action is `approve`, git-credential will send the description +to any configured credential helpers, which may store the credential +for later use. + +If the action is `reject`, git-credential will send the description to +any configured credential helpers, which may erase any stored +credential matching the description. + +If the action is `approve` or `reject`, no output should be emitted. + +TYPICAL USE OF GIT CREDENTIAL +----------------------------- + +An application using git-credential will typically use `git +credential` following these steps: + + 1. Generate a credential description based on the context. ++ +For example, if we want a password for +`https://example.com/foo.git`, we might generate the following +credential description (don't forget the blank line at the end; it +tells `git credential` that the application finished feeding all the +infomation it has): + + protocol=https + host=example.com + path=foo.git + + 2. Ask git-credential to give us a username and password for this + description. This is done by running `git credential fill`, + feeding the description from step (1) to its standard input. The complete + credential description (including the credential per se, i.e. the + login and password) will be produced on standard output, like: + + protocol=https + host=example.com + username=bob + password=secr3t ++ +In most cases, this means the attributes given in the input will be +repeated in the output, but git may also modify the credential +description, for example by removing the `path` attribute when the +protocol is HTTP(s) and `credential.useHttpPath` is false. ++ +If the `git credential` knew about the password, this step may +not have involved the user actually typing this password (the +user may have typed a password to unlock the keychain instead, +or no user interaction was done if the keychain was already +unlocked) before it returned `password=secr3t`. + + 3. Use the credential (e.g., access the URL with the username and + password from step (2)), and see if it's accepted. + + 4. Report on the success or failure of the password. If the + credential allowed the operation to complete successfully, then + it can be marked with an "approve" action to tell `git + credential` to reuse it in its next invocation. If the credential + was rejected during the operation, use the "reject" action so + that `git credential` will ask for a new password in its next + invocation. In either case, `git credential` should be fed with + the credential description obtained from step (2) (which also + contain the ones provided in step (1)). + +[[IOFMT]] +INPUT/OUTPUT FORMAT +------------------- + +`git credential` reads and/or writes (depending on the action used) +credential information in its standard input/output. This information +can correspond either to keys for which `git credential` will obtain +the login/password information (e.g. host, protocol, path), or to the +actual credential data to be obtained (login/password). + +The credential is split into a set of named attributes, with one +attribute per line. Each attribute is +specified by a key-value pair, separated by an `=` (equals) sign, +followed by a newline. The key may contain any bytes except `=`, +newline, or NUL. The value may contain any bytes except newline or NUL. +In both cases, all bytes are treated as-is (i.e., there is no quoting, +and one cannot transmit a value with newline or NUL in it). The list of +attributes is terminated by a blank line or end-of-file. +Git understands the following attributes: + +`protocol`:: + + The protocol over which the credential will be used (e.g., + `https`). + +`host`:: + + The remote hostname for a network credential. + +`path`:: + + The path with which the credential will be used. E.g., for + accessing a remote https repository, this will be the + repository's path on the server. + +`username`:: + + The credential's username, if we already have one (e.g., from a + URL, from the user, or from a previously run helper). + +`password`:: + + The credential's password, if we are asking it to be stored. + +`url`:: + + When this special attribute is read by `git credential`, the + value is parsed as a URL and treated as if its constituent parts + were read (e.g., `url=https://example.com` would behave as if + `protocol=https` and `host=example.com` had been provided). This + can help callers avoid parsing URLs themselves. Note that any + components which are missing from the URL (e.g., there is no + username in the example above) will be set to empty; if you want + to provide a URL and override some attributes, provide the URL + attribute first, followed by any overrides. diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 2620d28b4b..6603a7ab73 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -39,6 +39,10 @@ OPTIONS See ``Date Formats'' below for details about which formats are supported, and their syntax. +-- done:: + Terminate with error if there is no 'done' command at the + end of the stream. + --force:: Force updating modified existing branches, even if doing so would cause commits to be lost (as the new commit does @@ -1047,7 +1051,9 @@ done:: Error out if the stream ends without a 'done' command. Without this feature, errors causing the frontend to end abruptly at a convenient point in the stream can go - undetected. + undetected. This may occur, for example, if an import + front end dies in mid-operation without emitting SIGTERM + or SIGKILL at its subordinate git fast-import instance. `option` ~~~~~~~~ diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 15e7ac80c0..e2301f5c01 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -304,6 +304,11 @@ committed a merge between P1 and P2, it will be propagated properly and all children of the merge will become merge commits with P1,P2 as their parents instead of the merge commit. +*NOTE* the changes introduced by the commits, and which are not reverted +by subsequent commits, will still be in the rewritten branch. If you want +to throw out _changes_ together with the commits, you should use the +interactive mode of 'git rebase'. + You can rewrite the commit log messages using `--msg-filter`. For example, 'git svn-id' strings in a repository created by 'git svn' can be removed this way: @@ -314,11 +319,6 @@ git filter-branch --msg-filter ' ' ------------------------------------------------------- -To restrict rewriting to only part of the history, specify a revision -range in addition to the new branch name. The new branch name will -point to the top-most revision that a 'git rev-list' of this range -will print. - If you need to add 'Acked-by' lines to, say, the last 10 commits (none of which is a merge), use this command: @@ -329,11 +329,10 @@ git filter-branch --msg-filter ' ' HEAD~10..HEAD -------------------------------------------------------- -*NOTE* the changes introduced by the commits, and which are not reverted -by subsequent commits, will still be in the rewritten branch. If you want -to throw out _changes_ together with the commits, you should use the -interactive mode of 'git rebase'. - +To restrict rewriting to only part of the history, specify a revision +range in addition to the new branch name. The new branch name will +point to the top-most revision that a 'git rev-list' of this range +will print. Consider this history: diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index c872b883ba..db55a4e0bb 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -102,9 +102,10 @@ Fields that have name-email-date tuple as its value (`author`, and `date` to extract the named component. The complete message in a commit and tag object is `contents`. -Its first line is `contents:subject`, the remaining lines -are `contents:body` and the optional GPG signature -is `contents:signature`. +Its first line is `contents:subject`, where subject is the concatenation +of all lines of the commit message up to the first blank line. The next +line is 'contents:body', where body is all of the lines after the first +blank line. Finally, the optional GPG signature is `contents:signature`. For sorting purposes, fields with numeric values sort in numeric order (`objectsize`, `authordate`, `committerdate`, `taggerdate`). diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 04c7346e3e..6d43f56279 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -58,10 +58,13 @@ output, unless the `--stdout` option is specified. If `-o` is specified, output files are created in <dir>. Otherwise they are created in the current working directory. -By default, the subject of a single patch is "[PATCH] First Line" and -the subject when multiple patches are output is "[PATCH n/m] First -Line". To force 1/1 to be added for a single patch, use `-n`. To omit -patch numbers from the subject, use `-N`. +By default, the subject of a single patch is "[PATCH] " followed by +the concatenation of lines from the commit message up to the first blank +line (see the DISCUSSION section of linkgit:git-commit[1]). + +When multiple patches are output, the subject prefix will instead be +"[PATCH n/m] ". To force 1/1 to be added for a single patch, use `-n`. +To omit patch numbers from the subject, use `-N`. If given `--thread`, `git-format-patch` will generate `In-Reply-To` and `References` headers to make the second and subsequent patch mails appear diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 1f906208f9..585dac40ba 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -24,10 +24,6 @@ each commit introduces are shown. OPTIONS ------- --<n>:: - Limits the number of commits to show. - Note that this is a commit limiting option, see below. - <since>..<until>:: Show only commits between the named two commits. When either <since> or <until> is omitted, it defaults to @@ -137,6 +133,8 @@ Examples This makes sense only when following a strict policy of merging all topic branches when staying on a single integration branch. +`git log -3`:: + Limits the number of commits to show to 3. Discussion ---------- diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 7a9b86a58a..774de5e9d9 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -42,6 +42,11 @@ OPTIONS it successfully talked with the remote repository, whether it found any matching refs. +--get-url:: + Expand the URL of the given remote repository taking into account any + "url.<base>.insteadOf" config setting (See linkgit:git-config[1]) and + exit without talking to the remote. + <repository>:: Location of the repository. The shorthand defined in $GIT_DIR/branches/ can be used. Use "." (dot) to list references in diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt index fe1f49bc6f..8228f33e3f 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -255,7 +255,7 @@ These options can be used to modify 'git p4 submit' behavior. p4. By default, this is the most recent p4 commit reachable from 'HEAD'. --M[<n>]:: +-M:: Detect renames. See linkgit:git-diff[1]. Renames will be represented in p4 using explicit 'move' operations. There is no corresponding option to detect copies, but there are @@ -465,13 +465,15 @@ git-p4.useClientSpec:: Submit variables ~~~~~~~~~~~~~~~~ git-p4.detectRenames:: - Detect renames. See linkgit:git-diff[1]. + Detect renames. See linkgit:git-diff[1]. This can be true, + false, or a score as expected by 'git diff -M'. git-p4.detectCopies:: - Detect copies. See linkgit:git-diff[1]. + Detect copies. See linkgit:git-diff[1]. This can be true, + false, or a score as expected by 'git diff -C'. git-p4.detectCopiesHarder:: - Detect copies harder. See linkgit:git-diff[1]. + Detect copies harder. See linkgit:git-diff[1]. A boolean. git-p4.preserveUser:: On submit, re-author changes to reflect the git author, diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index feb51a6ea3..fd535b06ab 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -8,9 +8,9 @@ git-rebase - Forward-port local commits to the updated upstream head SYNOPSIS -------- [verse] -'git rebase' [-i | --interactive] [options] [--onto <newbase>] +'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] [<upstream>] [<branch>] -'git rebase' [-i | --interactive] [options] --onto <newbase> +'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] --root [<branch>] 'git rebase' --continue | --skip | --abort @@ -210,7 +210,7 @@ rebase.autosquash:: OPTIONS ------- -<newbase>:: +--onto <newbase>:: Starting point at which to create the new commits. If the --onto option is not specified, the starting point is <upstream>. May be any valid commit, and not just an @@ -344,14 +344,36 @@ This uses the `--interactive` machinery internally, but combining it with the `--interactive` option explicitly is generally not a good idea unless you know what you are doing (see BUGS below). +-x <cmd>:: +--exec <cmd>:: + Append "exec <cmd>" after each line creating a commit in the + final history. <cmd> will be interpreted as one or more shell + commands. ++ +This option can only be used with the `--interactive` option +(see INTERACTIVE MODE below). ++ +You may execute several commands by either using one instance of `--exec` +with several commands: ++ + git rebase -i --exec "cmd1 && cmd2 && ..." ++ +or by giving more than one `--exec`: ++ + git rebase -i --exec "cmd1" --exec "cmd2" --exec ... ++ +If `--autosquash` is used, "exec" lines will not be appended for +the intermediate commits, and will only appear at the end of each +squash/fixup series. --root:: Rebase all commits reachable from <branch>, instead of limiting them with an <upstream>. This allows you to rebase - the root commit(s) on a branch. Must be used with --onto, and + the root commit(s) on a branch. When used with --onto, it will skip changes already contained in <newbase> (instead of - <upstream>). When used together with --preserve-merges, 'all' - root commits will be rewritten to have <newbase> as parent + <upstream>) whereas without --onto it will operate on every change. + When used together with both --onto and --preserve-merges, + 'all' root commits will be rewritten to have <newbase> as parent instead. --autosquash:: @@ -521,6 +543,24 @@ in `$SHELL`, or the default shell if `$SHELL` is not set), so you can use shell features (like "cd", ">", ";" ...). The command is run from the root of the working tree. +---------------------------------- +$ git rebase -i --exec "make test" +---------------------------------- + +This command lets you check that intermediate commits are compilable. +The todo list becomes like that: + +-------------------- +pick 5928aea one +exec make test +pick 04d0fda two +exec make test +pick ba46169 three +exec make test +pick f4593f9 four +exec make test +-------------------- + SPLITTING COMMITS ----------------- diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index a308f4c79f..e8c396b5f9 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -12,7 +12,7 @@ SYNOPSIS 'git remote' [-v | --verbose] 'git remote add' [-t <branch>] [-m <master>] [-f] [--tags|--no-tags] [--mirror=<fetch|push>] <name> <url> 'git remote rename' <old> <new> -'git remote rm' <name> +'git remote remove' <name> 'git remote set-head' <name> (-a | -d | <branch>) 'git remote set-branches' [--add] <name> <branch>... 'git remote set-url' [--push] <name> <newurl> [<oldurl>] @@ -85,6 +85,7 @@ In case <old> and <new> are the same, and <old> is a file under `$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to the configuration file format. +'remove':: 'rm':: Remove the remote named <name>. All remote-tracking branches and diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index 4cc3e9586f..3c63561f02 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -101,6 +101,12 @@ OPTIONS The option core.warnAmbiguousRefs is used to select the strict abbreviation mode. +--disambiguate=<prefix>:: + Show every object whose name begins with the given prefix. + The <prefix> must be at least 4 hexadecimal digits long to + avoid listing each and every object in the repository by + mistake. + --all:: Show all refs found in `refs/`. diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index 01d8417316..afeb4cdf16 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -14,8 +14,7 @@ git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w] DESCRIPTION ----------- Summarizes 'git log' output in a format suitable for inclusion -in release announcements. Each commit will be grouped by author and -the first line of the commit message will be shown. +in release announcements. Each commit will be grouped by author and title. Additionally, "[PATCH]" will be stripped from the commit description. diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 2de7bf0900..b4683bba1b 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -112,7 +112,6 @@ status:: initialized, `+` if the currently checked out submodule commit does not match the SHA-1 found in the index of the containing repository and `U` if the submodule has merge conflicts. - This command is the default command for 'git submodule'. + If `--recursive` is specified, this command will recurse into nested submodules, and show their status as well. diff --git a/Documentation/git.txt b/Documentation/git.txt index 65c37c4544..d1d227a32d 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -22,18 +22,17 @@ unusually rich command set that provides both high-level operations and full access to internals. See linkgit:gittutorial[7] to get started, then see -link:everyday.html[Everyday Git] for a useful minimum set of commands, and -"man git-commandname" for documentation of each command. CVS users may -also want to read linkgit:gitcvs-migration[7]. See -the link:user-manual.html[Git User's Manual] for a more in-depth -introduction. +link:everyday.html[Everyday Git] for a useful minimum set of +commands. The link:user-manual.html[Git User's Manual] has a more +in-depth introduction. -The '<command>' is either a name of a Git command (see below) or an alias -as defined in the configuration file (see linkgit:git-config[1]). +After you mastered the basic concepts, you can come back to this +page to learn what commands git offers. You can learn more about +individual git commands with "git help command". linkgit:gitcli[7] +manual page gives you an overview of the command line command syntax. -Formatted and hyperlinked version of the latest git -documentation can be viewed at -`http://www.kernel.org/pub/software/scm/git/docs/`. +Formatted and hyperlinked version of the latest git documentation +can be viewed at `http://git-htmldocs.googlecode.com/git/git.html`. ifdef::stalenotes[] [NOTE] @@ -44,6 +43,14 @@ unreleased) version of git, that is available from 'master' branch of the `git.git` repository. Documentation for older releases are available here: +* link:v1.7.12.3/git.html[documentation for release 1.7.12.3] + +* release notes for + link:RelNotes/1.7.12.3.txt[1.7.12.3], + link:RelNotes/1.7.12.2.txt[1.7.12.2], + link:RelNotes/1.7.12.1.txt[1.7.12.1], + link:RelNotes/1.7.12.txt[1.7.12]. + * link:v1.7.11.7/git.html[documentation for release 1.7.11.7] * release notes for @@ -408,24 +415,6 @@ help ...`. linkgit:git-replace[1] for more information. -FURTHER DOCUMENTATION ---------------------- - -See the references above to get started using git. The following is -probably more detail than necessary for a first-time user. - -The link:user-manual.html#git-concepts[git concepts chapter of the -user-manual] and linkgit:gitcore-tutorial[7] both provide -introductions to the underlying git architecture. - -See linkgit:gitworkflows[7] for an overview of recommended workflows. - -See also the link:howto-index.html[howto] documents for some useful -examples. - -The internals are documented in the -link:technical/api-index.html[GIT API documentation]. - GIT COMMANDS ------------ @@ -845,6 +834,29 @@ The index is also capable of storing multiple entries (called "stages") for a given pathname. These stages are used to hold the various unmerged version of a file when a merge is in progress. +FURTHER DOCUMENTATION +--------------------- + +See the references in the "description" section to get started +using git. The following is probably more detail than necessary +for a first-time user. + +The link:user-manual.html#git-concepts[git concepts chapter of the +user-manual] and linkgit:gitcore-tutorial[7] both provide +introductions to the underlying git architecture. + +See linkgit:gitworkflows[7] for an overview of recommended workflows. + +See also the link:howto-index.html[howto] documents for some useful +examples. + +The internals are documented in the +link:technical/api-index.html[GIT API documentation]. + +Users migrating from CVS may also want to +read linkgit:gitcvs-migration[7]. + + Authors ------- Git was started by Linus Torvalds, and is currently maintained by Junio diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 80120ea14f..52ab93d2c2 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -66,6 +66,11 @@ is from the path in question, the lower its precedence). Finally global and system-wide files are considered (they have the lowest precedence). +When the `.gitattributes` file is missing from the work tree, the +path in the index is used as a fall-back. During checkout process, +`.gitattributes` in the index is used and then the file in the +working tree is used as a fall-back. + If you wish to affect only a single repository (i.e., to assign attributes to files that are particular to one user's workflow for that repository), then @@ -75,6 +80,8 @@ repositories (i.e., attributes of interest to all users) should go into `.gitattributes` files. Attributes that should affect all repositories for a single user should be placed in a file specified by the `core.attributesfile` configuration option (see linkgit:git-config[1]). +Its default value is $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME +is either not set or empty, $HOME/.config/git/attributes is used instead. Attributes for all users on a system should be placed in the `$(prefix)/etc/gitattributes` file. @@ -925,7 +932,7 @@ file at the toplevel (i.e. not in any subdirectory). The built-in macro attribute "binary" is equivalent to: ------------ -[attr]binary -diff -text +[attr]binary -diff -merge -text ------------ diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 9d893369a0..5325c5a7d5 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -956,12 +956,11 @@ $ git show-branch --topo-order --more=1 master mybranch ------------------------------------------------ The first two lines indicate that it is showing the two branches -and the first line of the commit log message from their -top-of-the-tree commits, you are currently on `master` branch -(notice the asterisk `*` character), and the first column for -the later output lines is used to show commits contained in the +with the titles of their top-of-the-tree commits, you are currently on +`master` branch (notice the asterisk `*` character), and the first +column for the later output lines is used to show commits contained in the `master` branch, and the second column for the `mybranch` -branch. Three commits are shown along with their log messages. +branch. Three commits are shown along with their titles. All of them have non blank characters in the first column (`*` shows an ordinary commit on the current branch, `-` is a merge commit), which means they are now part of the `master` branch. Only the "Some diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 2e7328b830..96639e02bd 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -41,16 +41,24 @@ precedence, the last matching pattern decides the outcome): variable 'core.excludesfile'. Which file to place a pattern in depends on how the pattern is meant to -be used. Patterns which should be version-controlled and distributed to -other repositories via clone (i.e., files that all developers will want -to ignore) should go into a `.gitignore` file. Patterns which are -specific to a particular repository but which do not need to be shared -with other related repositories (e.g., auxiliary files that live inside -the repository but are specific to one user's workflow) should go into -the `$GIT_DIR/info/exclude` file. Patterns which a user wants git to -ignore in all situations (e.g., backup or temporary files generated by -the user's editor of choice) generally go into a file specified by -`core.excludesfile` in the user's `~/.gitconfig`. +be used. + + * Patterns which should be version-controlled and distributed to + other repositories via clone (i.e., files that all developers will want + to ignore) should go into a `.gitignore` file. + + * Patterns which are + specific to a particular repository but which do not need to be shared + with other related repositories (e.g., auxiliary files that live inside + the repository but are specific to one user's workflow) should go into + the `$GIT_DIR/info/exclude` file. + + * Patterns which a user wants git to + ignore in all situations (e.g., backup or temporary files generated by + the user's editor of choice) generally go into a file specified by + `core.excludesfile` in the user's `~/.gitconfig`. Its default value is + $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or + empty, $HOME/.config/git/ignore is used instead. The underlying git plumbing tools, such as 'git ls-files' and 'git read-tree', read diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index dee050567e..f1cb6f3be6 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -139,9 +139,11 @@ them to the index, and commit, all in one step. A note on commit messages: Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more -thorough description. Tools that turn commits into email, for -example, use the first line on the Subject: line and the rest of the -commit in the body. +thorough description. The text up to the first blank line in a commit +message is treated as the commit title, and that title is used +throughout git. For example, linkgit:git-format-patch[1] turns a +commit into email, and it uses the title on the Subject line and the +rest of the commit in the body. Git tracks content not files ---------------------------- diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index 595a3cf1a7..66db80296f 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -32,13 +32,14 @@ ours;; This option forces conflicting hunks to be auto-resolved cleanly by favoring 'our' version. Changes from the other tree that do not conflict with our side are reflected to the merge result. + For a binary file, the entire contents are taken from our side. + This should not be confused with the 'ours' merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring 'our' history contains all that happened in it. theirs;; - This is opposite of 'ours'. + This is the opposite of 'ours'. patience;; With this option, 'merge-recursive' spends a little extra time diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index e3d8a83b23..d9eddedc72 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -130,6 +130,9 @@ The placeholders are: - '%b': body - '%B': raw body (unwrapped subject and body) - '%N': commit notes +- '%GG': raw verification message from GPG for a signed commit +- '%G?': show either "G" for Good or "B" for Bad for a signed commit +- '%GS': show the name of the signer for a signed commit - '%gD': reflog selector, e.g., `refs/stash@{1}` - '%gd': shortened reflog selector, e.g., `stash@{1}` - '%gn': reflog identity name diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt index 2a3dc8664f..5e499421a4 100644 --- a/Documentation/pretty-options.txt +++ b/Documentation/pretty-options.txt @@ -66,3 +66,7 @@ being displayed. Examples: "--notes=foo" will show only notes from --[no-]standard-notes:: These options are deprecated. Use the above --notes/--no-notes options instead. + +--show-signature:: + Check the validity of a signed commit object by passing the signature + to `gpg --verify` and show the output. diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index def1340ac7..1fc2a18404 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -3,12 +3,20 @@ Commit Limiting Besides specifying a range of commits that should be listed using the special notations explained in the description, additional commit -limiting may be applied. Note that they are applied before commit -ordering and formatting options, such as '--reverse'. +limiting may be applied. + +Using more options generally further limits the output (e.g. +`--since=<date1>` limits to commits newer than `<date1>`, and using it +with `--grep=<pattern>` further limits to commits whose log message +has a line that matches `<pattern>`), unless otherwise noted. + +Note that these are applied before commit +ordering and formatting options, such as `--reverse`. -- --n 'number':: +-<number>:: +-n <number>:: --max-count=<number>:: Limit the number of commits to output. @@ -38,16 +46,22 @@ endif::git-rev-list[] --committer=<pattern>:: Limit the commits output to ones with author/committer - header lines that match the specified pattern (regular expression). + header lines that match the specified pattern (regular + expression). With more than one `--author=<pattern>`, + commits whose author matches any of the given patterns are + chosen (similarly for multiple `--committer=<pattern>`). --grep=<pattern>:: Limit the commits output to ones with log message that - matches the specified pattern (regular expression). + matches the specified pattern (regular expression). With + more than one `--grep=<pattern>`, commits whose message + matches any of the given patterns are chosen (but see + `--all-match`). --all-match:: Limit the commits output to ones that match all given --grep, - --author and --committer instead of ones that match at least one. + instead of ones that match at least one. -i:: --regexp-ignore-case:: @@ -636,10 +650,14 @@ These options are mostly targeted for packing of git repositories. Only useful with '--objects'; print the object IDs that are not in packs. ---no-walk:: +--no-walk[=(sorted|unsorted)]:: - Only show the given revs, but do not traverse their ancestors. - This has no effect if a range is specified. + Only show the given commits, but do not traverse their ancestors. + This has no effect if a range is specified. If the argument + "unsorted" is given, the commits are show in the order they were + given on the command line. Otherwise (if "sorted" or no argument + was given), the commits are show in reverse chronological order + by commit time. --do-walk:: diff --git a/Documentation/technical/api-argv-array.txt b/Documentation/technical/api-argv-array.txt index 1b7d8f140c..1a797812fb 100644 --- a/Documentation/technical/api-argv-array.txt +++ b/Documentation/technical/api-argv-array.txt @@ -46,6 +46,10 @@ Functions Format a string and push it onto the end of the array. This is a convenience wrapper combining `strbuf_addf` and `argv_array_push`. +`argv_array_pop`:: + Remove the final element from the array. If there are no + elements in the array, do nothing. + `argv_array_clear`:: Free all memory associated with the array and return it to the initial, empty state. diff --git a/Documentation/technical/api-credentials.txt b/Documentation/technical/api-credentials.txt index adb6f0c896..5977b58e57 100644 --- a/Documentation/technical/api-credentials.txt +++ b/Documentation/technical/api-credentials.txt @@ -241,42 +241,9 @@ appended to its command line, which is one of: Remove a matching credential, if any, from the helper's storage. The details of the credential will be provided on the helper's stdin -stream. The credential is split into a set of named attributes. -Attributes are provided to the helper, one per line. Each attribute is -specified by a key-value pair, separated by an `=` (equals) sign, -followed by a newline. The key may contain any bytes except `=`, -newline, or NUL. The value may contain any bytes except newline or NUL. -In both cases, all bytes are treated as-is (i.e., there is no quoting, -and one cannot transmit a value with newline or NUL in it). The list of -attributes is terminated by a blank line or end-of-file. - -Git will send the following attributes (but may not send all of -them for a given credential; for example, a `host` attribute makes no -sense when dealing with a non-network protocol): - -`protocol`:: - - The protocol over which the credential will be used (e.g., - `https`). - -`host`:: - - The remote hostname for a network credential. - -`path`:: - - The path with which the credential will be used. E.g., for - accessing a remote https repository, this will be the - repository's path on the server. - -`username`:: - - The credential's username, if we already have one (e.g., from a - URL, from the user, or from a previously run helper). - -`password`:: - - The credential's password, if we are asking it to be stored. +stream. The exact format is the same as the input/output format of the +`git credential` plumbing command (see the section `INPUT/OUTPUT +FORMAT` in linkgit:git-credential[7] for a detailed specification). For a `get` operation, the helper should produce a list of attributes on stdout in the same format. A helper is free to produce a subset, or diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index 49cdc571cd..d51e20f352 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -259,8 +259,10 @@ a positive depth, this step is skipped. ---- If the client has requested a positive depth, the server will compute -the set of commits which are no deeper than the desired depth, starting -at the client's wants. The server writes 'shallow' lines for each +the set of commits which are no deeper than the desired depth. The set +of commits start at the client's wants. + +The server writes 'shallow' lines for each commit whose parents will not be sent as a result. The server writes an 'unshallow' line for each commit which the client has indicated is shallow, but is no longer shallow at the currently requested depth diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 03d95dc290..85651b57ae 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1136,9 +1136,12 @@ Creating good commit messages Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough -description. Tools that turn commits into email, for example, use -the first line on the Subject line and the rest of the commit in the -body. +description. The text up to the first blank line in a commit +message is treated as the commit title, and that title is used +throughout git. For example, linkgit:git-format-patch[1] turns a +commit into email, and it uses the title on the Subject line and the +rest of the commit in the body. + [[ignoring-files]] Ignoring files |