diff options
Diffstat (limited to 'Documentation')
42 files changed, 1062 insertions, 351 deletions
diff --git a/Documentation/Makefile b/Documentation/Makefile index 04f69cf64e..a4c4063e50 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 gitworkflows.txt + gitdiffcore.txt gitrevisions.txt gitworkflows.txt MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT)) diff --git a/Documentation/RelNotes-1.7.2.txt b/Documentation/RelNotes-1.7.2.txt new file mode 100644 index 0000000000..f24b3876af --- /dev/null +++ b/Documentation/RelNotes-1.7.2.txt @@ -0,0 +1,155 @@ +Git v1.7.2 Release Notes (draft) +================================ + +Updates since v1.7.1 +-------------------- + + * core.eol configuration and text/eol attributes are the new way to control + the end of line conventions for files in the working tree. + + * core.autocrlf has been made safer - it will now only handle line + endings for new files and files that are LF-only in the + repository. To normalize content that has been checked in with + CRLF, use the new eol/text attributes. + + * The whitespace rules used in "git apply --whitespace" and "git diff" + gained a new member in the family (tab-in-indent) to help projects with + policy to indent only with spaces. + + * When working from a subdirectory, by default, git does not look for its + metadirectory ".git" across filesystems, primarily to help people who + have invocations of git in their custom PS1 prompts, as being outside + of a git repository would look for ".git" all the way up to the root + directory, and NFS mounts are often slow. DISCOVERY_ACROSS_FILESYSTEM + environment variable can be used to tell git not to stop at a + filesystem boundary. + + * Usage help messages generated by parse-options library (i.e. most + of the Porcelain commands) are sent to the standard output now. + + * ':/<string>' notation to look for a commit now takes regular expression + and it is not anchored at the beginning of the commit log message + anymore (this is a backward incompatible change). + + * "git" wrapper learned "-c name=value" option to override configuration + variable from the command line. + + * Improved portability for various platforms including older SunOS, + HP-UX 10/11, AIX, Tru64, etc. and platforms with Python 2.4. + + * The message from "git am -3" has been improved when conflict + resolution ended up making the patch a no-op. + + * "git blame" applies the textconv filter to the contents it works + on, when available. + + * "git checkout --orphan newbranch" is similar to "-b newbranch" but + prepares to create a root commit that is not connected to any existing + commit. + + * "git cherry-pick" learned to pick a range of commits + (e.g. "cherry-pick A..B" and "cherry-pick --stdin"), so did "git + revert"; these do not support the nicer sequencing control "rebase + [-i]" has, though. + + * "git cherry-pick" and "git revert" learned --strategy option to specify + the merge strategy to be used when performing three-way merges. + + * "git cvsserver" can be told to use pserver; its password file can be + stored outside the repository. + + * The output from the textconv filter used by "git diff" can be cached to + speed up their reuse. + + * "git diff --word-diff=<mode>" extends the existing "--color-words" + option, making it more useful in color-challenged environments. + + * The regexp to detect function headers used by "git diff" for PHP has + been enhanced for visibility modifiers (public, protected, etc.) to + better support PHP5. + + * "diff.noprefix" configuration variable can be used to implicitly + ask for "diff --no-prefix" behaviour. + + * "git for-each-ref" learned "%(objectname:short)" that gives the object + name abbreviated. + + * "git format-patch" learned --signature option and format.signature + configuration variable to customize the e-mail signature used in the + output. + + * Various options to "git grep" (e.g. --count, --name-only) work better + with binary files. + + * "git grep" learned "-Ovi" to open the files with hits in your editor. + + * "git help -w" learned "chrome" and "chromium" browsers. + + * "git log --decorate" shows commit decorations in various colours. + + * "git log --follow <path>" follows across copies (it used to only follow + renames). This may make the processing more expensive. + + * "git log --pretty=format:<template>" specifier learned "% <something>" + magic that inserts a space only when %<something> expands to a + non-empty string; this is similar to "%+<something>" magic, but is + useful in a context to generate a single line output. + + * "git notes prune" learned "-n" (dry-run) and "-v" options, similar to + what "git prune" has. + + * "git patch-id" can be fed a mbox without getting confused by the + signature line in the format-patch output. + + * "git remote" learned "set-branches" subcommand. + + * "git rev-list A..B" learned --ancestry-path option to further limit + the result to the commits that are on the ancestry chain between A and + B (i.e. commits that are not descendants of A are excluded). + + * "git show -5" is equivalent to "git show --do-walk 5"; this is similar + to the update to make "git show master..next" walk the history, + introduced in 1.6.4. + + * "git status [-s] --ignored" can be used to list ignored paths. + + * "git status -s -b" shows the current branch in the output. + + * "git status" learned "--ignore-submodules" option. + + * Various "gitweb" enhancements and clean-ups, including syntax + highlighting, "plackup" support for instaweb, .fcgi suffix to run + it as FastCGI script, etc. + + * The test harness has been updated to produce TAP-friendly output. + + +Fixes since v1.7.1 +------------------ + +All of the fixes in v1.7.1.X maintenance series are included in this +release, unless otherwise noted. + + * We didn't URL decode "file:///path/to/repo" correctly when path/to/repo + had percent-encoded characters (638794c, 9d2e942, ce83eda, 3c73a1d). + + * "git clone" did not configure remote.origin.url correctly for bare + clones (df61c889). + + * "git diff --graph" works better with "--color-words" and other options + (81fa024..4297c0a). + + * "git diff" could show ambiguous abbreviation of blob object names on + its "index" line (3e5a188). + + * "git reset --hard" started from a wrong directory and a working tree in + a nonstandard location is in use got confused (560fb6a1). + + * "git read-tree -m A B" used to switch to branch B while retaining + local changes added an incorrect cache-tree information (b1f47514). + +-- +exec >/var/tmp/1 +O=v1.7.2-rc2-17-gc9a9766 +echo O=$(git describe HEAD) +git shortlog --no-merges HEAD ^maint ^$O diff --git a/Documentation/config.txt b/Documentation/config.txt index 1029bc46ca..e75434b3ef 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -196,20 +196,17 @@ core.quotepath:: quoted without `-z` regardless of the setting of this variable. -core.autocrlf:: - If true, makes git convert `CRLF` at the end of lines in text files to - `LF` when reading from the work tree, and convert in reverse when - writing to the work tree. The variable can be set to - 'input', in which case the conversion happens only while - reading from the work tree but files are written out to the work - tree with `LF` at the end of lines. A file is considered - "text" (i.e. be subjected to the autocrlf mechanism) based on - the file's `crlf` attribute, or if `crlf` is unspecified, - based on the file's contents. See linkgit:gitattributes[5]. +core.eol:: + Sets the line ending type to use in the working directory for + files that have the `text` property set. Alternatives are + 'lf', 'crlf' and 'native', which uses the platform's native + line ending. The default value is `native`. See + linkgit:gitattributes[5] for more information on end-of-line + conversion. core.safecrlf:: - If true, makes git check if converting `CRLF` as controlled by - `core.autocrlf` is reversible. Git will verify if a command + If true, makes git check if converting `CRLF` is reversible when + end-of-line conversion is active. Git will verify if a command modifies a file in the work tree either directly or indirectly. For example, committing a file followed by checking out the same file should yield the original file in the work tree. If @@ -219,7 +216,7 @@ core.safecrlf:: irreversible conversion but continue the operation. + CRLF conversion bears a slight chance of corrupting data. -autocrlf=true will convert CRLF to LF during commit and LF to +When it is enabled, git will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by git. For text files this is the right thing to do: it corrects line endings @@ -243,15 +240,25 @@ converting CRLFs corrupts data. + Note, this safety check does not mean that a checkout will generate a file identical to the original file for a different setting of -`core.autocrlf`, but only for the current one. For example, a text -file with `LF` would be accepted with `core.autocrlf=input` and could -later be checked out with `core.autocrlf=true`, in which case the +`core.eol` and `core.autocrlf`, but only for the current one. For +example, a text file with `LF` would be accepted with `core.eol=lf` +and could later be checked out with `core.eol=crlf`, in which case the resulting file would contain `CRLF`, although the original file contained `LF`. However, in both work trees the line endings would be consistent, that is either all `LF` or all `CRLF`, but never mixed. A file with mixed line endings would be reported by the `core.safecrlf` mechanism. +core.autocrlf:: + Setting this variable to "true" is almost the same as setting + the `text` attribute to "auto" on all files except that text + files are not guaranteed to be normalized: files that contain + `CRLF` in the repository will not be touched. Use this + setting if you want to have `CRLF` line endings in your + working directory even though the repository does not have + normalized line endings. This variable can be set to 'input', + in which case no output conversion is performed. + core.symlinks:: If false, symbolic links are checked out as small plain files that contain the link text. linkgit:git-update-index[1] and @@ -481,6 +488,8 @@ core.whitespace:: 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). +* `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 (enabled by default). * `trailing-space` is a short-hand to cover both `blank-at-eol` and @@ -681,6 +690,11 @@ color.diff.<slot>:: (highlighting whitespace errors). The values of these variables may be specified as in color.branch.<slot>. +color.decorate.<slot>:: + Use customized color for 'git log --decorate' output. `<slot>` is one + of `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local + branches, remote tracking branches, tags, stash and HEAD, respectively. + color.grep:: When set to `always`, always highlight matches. When `false` (or `never`), never. When set to `true` or `auto`, use color only @@ -790,6 +804,8 @@ diff.mnemonicprefix:: 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: +diff.noprefix:: + If set, 'git diff' does not show any source or destination prefix. `git diff`;; compares the (i)ndex and the (w)ork tree; `git diff HEAD`;; @@ -880,6 +896,12 @@ format.subjectprefix:: The default for format-patch is to output files with the '[PATCH]' subject prefix. Use this variable to change that prefix. +format.signature:: + The default for format-patch is to output a signature containing + the git version number. Use this variable to change that default. + Set this variable to the empty string ("") to suppress + signature generation. + 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 @@ -940,13 +962,19 @@ gc.pruneexpire:: unreachable objects immediately. gc.reflogexpire:: +gc.<pattern>.reflogexpire:: 'git reflog expire' removes reflog entries older than - this time; defaults to 90 days. + this time; defaults to 90 days. With "<pattern>" (e.g. + "refs/stash") in the middle the setting applies only to + the refs that match the <pattern>. gc.reflogexpireunreachable:: +gc.<ref>.reflogexpireunreachable:: 'git reflog expire' removes reflog entries older than this time and are not reachable from the current tip; - defaults to 30 days. + defaults to 30 days. With "<pattern>" (e.g. "refs/stash") + in the middle, the setting applies only to the refs that + match the <pattern>. gc.rerereresolved:: Records of conflicted merge you resolved earlier are @@ -971,13 +999,15 @@ gitcvs.logfile:: various stuff. See linkgit:git-cvsserver[1]. gitcvs.usecrlfattr:: - If true, the server will look up the `crlf` attribute for - files to determine the '-k' modes to use. If `crlf` is set, - the '-k' mode will be left blank, so cvs clients will - treat it as text. If `crlf` is explicitly unset, the file + If true, the server will look up the end-of-line conversion + attributes for files to determine the '-k' modes to use. If + the attributes force git to treat a file as text, + the '-k' mode will be left blank so cvs clients will + treat it as text. If they suppress text conversion, the file will be set with '-kb' mode, which suppresses any newline munging - the client might otherwise do. If `crlf` is not specified, - then 'gitcvs.allbinary' is used. See linkgit:gitattributes[5]. + the client might otherwise do. If the attributes do not allow + the file type to be determined, then 'gitcvs.allbinary' is + used. See linkgit:gitattributes[5]. gitcvs.allbinary:: This is used if 'gitcvs.usecrlfattr' does not resolve @@ -1264,6 +1294,13 @@ log.date:: following alternatives: {relative,local,default,iso,rfc,short}. See linkgit:git-log[1]. +log.decorate:: + Print out the ref names of any commits that are shown by the log + command. 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. + This is the same as the log commands '--decorate' option. + log.showroot:: If true, the initial commit will be shown as a big creation event. This is equivalent to a diff against an empty tree. @@ -1462,6 +1499,16 @@ pager.<cmd>:: it takes precedence over this option. To disable pagination for all commands, set `core.pager` or `GIT_PAGER` to `cat`. +pretty.<name>:: + Alias for a --pretty= format string, as specified in + linkgit:git-log[1]. Any aliases defined here can be used just + as the built-in pretty formats could. For example, + running `git config pretty.changelog "format:{asterisk} %H %s"` + would cause the invocation `git log --pretty=changelog` + to be equivalent to running `git log "--pretty=format:{asterisk} %H %s"`. + Note that an alias with the same name as a built-in format + will be silently ignored. + pull.octopus:: The default merge strategy to use when pulling multiple branches at once. @@ -1574,7 +1621,9 @@ remote.<name>.uploadpack:: remote.<name>.tagopt:: Setting this value to \--no-tags disables automatic tag following when - fetching from remote <name> + fetching from remote <name>. Setting it to \--tags will fetch every + tag from remote <name>, even if they are not reachable from remote + branch heads. remote.<name>.vcs:: Setting this to a value <vcs> will cause git to interact with @@ -1685,6 +1734,15 @@ status.submodulesummary:: summary of commits for modified submodules will be shown (see --summary-limit option of linkgit:git-submodule[1]). +submodule.<name>.path:: +submodule.<name>.url:: +submodule.<name>.update:: + The path within this project, URL, and the updating strategy + for a submodule. These variables are initially populated + by 'git submodule init'; edit them to override the + URL and other values found in the `.gitmodules` file. See + linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. + tar.umask:: This variable can be used to restrict the permission bits of tar archive entries. The default is 0002, which turns off the diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 3070dddfe2..2371262b10 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -21,6 +21,7 @@ endif::git-format-patch[] ifndef::git-format-patch[] -p:: -u:: +--patch:: Generate patch (see section on generating patches). {git-diff? This is the default.} endif::git-format-patch[] @@ -126,11 +127,39 @@ any of those replacements occurred. gives the default to color output. Same as `--color=never`. ---color-words[=<regex>]:: - Show colored word diff, i.e., color words which have changed. - By default, words are separated by whitespace. +--word-diff[=<mode>]:: + Show a word diff, using the <mode> to delimit changed words. + By default, words are delimited by whitespace; see + `--word-diff-regex` below. The <mode> defaults to 'plain', and + must be one of: ++ +-- +color:: + Highlight changed words using only colors. Implies `--color`. +plain:: + Show words as `[-removed-]` and `{+added+}`. Makes no + attempts to escape the delimiters if they appear in the input, + so the output may be ambiguous. +porcelain:: + Use a special line-based format intended for script + consumption. Added/removed/unchanged runs are printed in the + usual unified diff format, starting with a `+`/`-`/` ` + character at the beginning of the line and extending to the + end of the line. Newlines in the input are represented by a + tilde `~` on a line of its own. +none:: + Disable word diff again. +-- ++ +Note that despite the name of the first mode, color is used to +highlight the changed parts in all modes if enabled. + +--word-diff-regex=<regex>:: + Use <regex> to decide what a word is, instead of considering + runs of non-whitespace to be a word. Also implies + `--word-diff` unless it was already enabled. + -When a <regex> is specified, every non-overlapping match of the +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 @@ -142,6 +171,10 @@ 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. + +--color-words[=<regex>]:: + Equivalent to `--word-diff=color` plus (if a regex was + specified) `--word-diff-regex=<regex>`. endif::git-format-patch[] --no-renames:: @@ -295,8 +328,14 @@ endif::git-format-patch[] --no-ext-diff:: Disallow external diff drivers. ---ignore-submodules:: - Ignore changes to submodules in the diff generation. +--ignore-submodules[=<when>]:: + Ignore changes to submodules in the diff generation. <when> can be + either "untracked", "dirty" or "all", which is the default. When + "untracked" is used submodules are not considered dirty when they only + contain untracked content (but they are still scanned for modified + content). Using "dirty" ignores all changes to the work tree of submodules, + only changes to the commits stored in the superproject are shown (this was + the behavior until 1.7.0). Using "all" hides all changes to submodules. --src-prefix=<prefix>:: Show the given source prefix instead of "a/". diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt index 58c8d65772..a3f56b07fd 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -9,14 +9,15 @@ git-cat-file - Provide content or type and size information for repository objec SYNOPSIS -------- [verse] -'git cat-file' (-t | -s | -e | -p | <type>) <object> +'git cat-file' (-t | -s | -e | -p | <type> | --textconv ) <object> 'git cat-file' (--batch | --batch-check) < <list-of-objects> DESCRIPTION ----------- In its first form, the command provides the content or the type of an object in the repository. The type is required unless '-t' or '-p' is used to find the -object type, or '-s' is used to find the object size. +object type, or '-s' is used to find the object size, or '--textconv' is used +(which implies type "blob"). In the second form, a list of objects (separated by linefeeds) is provided on stdin, and the SHA1, type, and size of each object is printed on stdout. @@ -26,7 +27,7 @@ OPTIONS <object>:: The name of the object to show. For a more complete list of ways to spell object names, see - the "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. + the "SPECIFYING REVISIONS" section in linkgit:gitrevisions[1]. -t:: Instead of the content, show the object type identified by @@ -51,6 +52,11 @@ OPTIONS or to ask for a "blob" with <object> being a tag object that points at it. +--textconv:: + Show the content as transformed by a textconv filter. In this case, + <object> has be of the form <treeish>:<path>, or :<path> in order + to apply the filter to the content recorded in the index at <path>. + --batch:: Print the SHA1, type, size, and contents of each object provided on stdin. May not be combined with any other options or arguments. diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index 379eee6734..f5c2e0601d 100644 --- a/Documentation/git-check-ref-format.txt +++ b/Documentation/git-check-ref-format.txt @@ -49,7 +49,7 @@ git imposes the following rules on how references are named: These rules make it easy for shell script based tools to parse reference names, pathname expansion by the shell when a reference name is used unquoted (by mistake), and also avoids ambiguities in certain -reference name expressions (see linkgit:git-rev-parse[1]): +reference name expressions (see linkgit:gitrevisions[1]): . A double-dot `..` is often used as in `ref1..ref2`, and in some contexts this notation means `{caret}ref1 ref2` (i.e. not in diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 7b83162223..1bacd2e104 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -9,7 +9,7 @@ SYNOPSIS -------- [verse] 'git checkout' [-q] [-f] [-m] [<branch>] -'git checkout' [-q] [-f] [-m] [-b <new_branch>] [<start_point>] +'git checkout' [-q] [-f] [-m] [[-b|--orphan] <new_branch>] [<start_point>] 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>... 'git checkout' --patch [<tree-ish>] [--] [<paths>...] @@ -98,6 +98,31 @@ explicitly give a name with '-b' in such a case. Create the new branch's reflog; see linkgit:git-branch[1] for details. +--orphan:: + Create a new 'orphan' branch, named <new_branch>, started from + <start_point> and switch to it. The first commit made on this + new branch will have no parents and it will be the root of a new + history totally disconnected from all the other branches and + commits. ++ +The index and the working tree are adjusted as if you had previously run +"git checkout <start_point>". This allows you to start a new history +that records a set of paths similar to <start_point> by easily running +"git commit -a" to make the root commit. ++ +This can be useful when you want to publish the tree from a commit +without exposing its full history. You might want to do this to publish +an open source branch of a project whose current tree is "clean", but +whose full history contains proprietary or otherwise encumbered bits of +code. ++ +If you want to start a disconnected history that records a set of paths +that is totally different from the one of <start_point>, then you should +clear the index and the working tree right after creating the orphan +branch by running "git rm -rf ." from the top level of the working tree. +Afterwards you will be ready to prepare your new files, repopulating the +working tree, by copying them from elsewhere, extracting a tarball, etc. + -m:: --merge:: When switching branches, diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index d71607a85d..2cef579316 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -3,24 +3,28 @@ git-cherry-pick(1) NAME ---- -git-cherry-pick - Apply the change introduced by an existing commit +git-cherry-pick - Apply the changes introduced by some existing commits SYNOPSIS -------- -'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit> +'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>... DESCRIPTION ----------- -Given one existing commit, apply the change the patch introduces, and record a -new commit that records it. This requires your working tree to be clean (no -modifications from the HEAD commit). + +Given one or more existing commits, apply the change each one +introduces, recording a new commit for each. This requires your +working tree to be clean (no modifications from the HEAD commit). OPTIONS ------- -<commit>:: - Commit to cherry-pick. - For a more complete list of ways to spell commits, see the - "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. +<commit>...:: + Commits to cherry-pick. + For a more complete list of ways to spell commits, see + linkgit:gitrevisions[1]. + Sets of commits can be passed but no traversal is done by + default, as if the '--no-walk' option was specified, see + linkgit:git-rev-list[1]. -e:: --edit:: @@ -55,10 +59,10 @@ OPTIONS -n:: --no-commit:: - Usually the command automatically creates a commit. - This flag applies the change necessary to cherry-pick - the named commit to your working tree and the index, - but does not make the commit. In addition, when this + Usually the command automatically creates a sequence of commits. + This flag applies the changes necessary to cherry-pick + each named commit to your working tree and the index, + without making any commit. In addition, when this option is used, your index does not have to match the HEAD commit. The cherry-pick is done against the beginning state of your index. @@ -75,6 +79,47 @@ effect to your index in a row. cherry-pick'ed commit, then a fast forward to this commit will be performed. +EXAMPLES +-------- +git cherry-pick master:: + + Apply the change introduced by the commit at the tip of the + master branch and create a new commit with this change. + +git cherry-pick ..master:: +git cherry-pick ^HEAD master:: + + Apply the changes introduced by all commits that are ancestors + of master but not of HEAD to produce new commits. + +git cherry-pick master\~4 master~2:: + + Apply the changes introduced by the fifth and third last + commits pointed to by master and create 2 new commits with + these changes. + +git cherry-pick -n master~1 next:: + + Apply to the working tree and the index the changes introduced + by the second last commit pointed to by master and by the last + commit pointed to by next, but do not create any commit with + these changes. + +git cherry-pick --ff ..next:: + + If history is linear and HEAD is an ancestor of next, update + the working tree and advance the HEAD pointer to match next. + Otherwise, apply the changes introduced by those commits that + are in next but not HEAD to the current branch, creating a new + commit for each new change. + +git rev-list --reverse master \-- README | git cherry-pick -n --stdin:: + + Apply the changes introduced by all commits on the master + branch that touched README to the working tree and index, + so the result can be inspected and made into a single new + commit if suitable. + Author ------ Written by Junio C Hamano <gitster@pobox.com> @@ -83,6 +128,10 @@ Documentation -------------- Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. +SEE ALSO +-------- +linkgit:git-revert[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 69eb86e450..c28603ecf5 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -10,7 +10,7 @@ SYNOPSIS [verse] 'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run] [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author] - [--allow-empty] [--no-verify] [-e] [--author=<author>] + [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=<author>] [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--] [[-i | -o ]<file>...] @@ -132,6 +132,12 @@ OPTIONS from making such a commit. This option bypasses the safety, and is primarily for use by foreign scm interface scripts. +--allow-empty-message:: + Like --allow-empty this command is primarily for use by foreign + scm interface scripts. It allows you to create a commit with an + empty commit message without using plumbing commands like + linkgit:git-commit-tree[1]. + --cleanup=<mode>:: This option sets how the commit message is cleaned up. The '<mode>' can be one of 'verbatim', 'whitespace', 'strip', diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt index dbb053ee17..7004dd2dec 100644 --- a/Documentation/git-cvsserver.txt +++ b/Documentation/git-cvsserver.txt @@ -72,9 +72,6 @@ plugin. Most functionality works fine with both of these clients. LIMITATIONS ----------- -Currently cvsserver works over SSH connections for read/write clients, and -over pserver for anonymous CVS access. - CVS clients cannot tag, branch or perform GIT merges. 'git-cvsserver' maps GIT branches to CVS modules. This is very different @@ -84,7 +81,7 @@ one or more directories. INSTALLATION ------------ -1. If you are going to offer anonymous CVS access via pserver, add a line in +1. If you are going to offer CVS access via pserver, add a line in /etc/inetd.conf like + -- @@ -101,6 +98,38 @@ looks like cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver ------ + +Only anonymous access is provided by pserve by default. To commit you +will have to create pserver accounts, simply add a gitcvs.authdb +setting in the config file of the repositories you want the cvsserver +to allow writes to, for example: + +------ + + [gitcvs] + authdb = /etc/cvsserver/passwd + +------ +The format of these files is username followed by the crypted password, +for example: + +------ + myuser:$1Oyx5r9mdGZ2 + myuser:$1$BA)@$vbnMJMDym7tA32AamXrm./ +------ +You can use the 'htpasswd' facility that comes with Apache to make these +files, but Apache's MD5 crypt method differs from the one used by most C +library's crypt() function, so don't use the -m option. + +Alternatively you can produce the password with perl's crypt() operator: +----- + perl -e 'my ($user, $pass) = @ARGV; printf "%s:%s\n", $user, crypt($user, $pass)' $USER password +----- + +Then provide your password via the pserver method, for example: +------ + cvs -d:pserver:someuser:somepassword <at> server/path/repo.git co <HEAD_name> +------ No special setup is needed for SSH access, other than having GIT tools in the PATH. If you have clients that do not accept the CVS_SERVER environment variable, you can rename 'git-cvsserver' to `cvs`. @@ -340,16 +369,13 @@ By default the server leaves the '-k' mode blank for all files, which causes the cvs client to treat them as a text files, subject to crlf conversion on some platforms. -You can make the server use `crlf` attributes to set the '-k' modes -for files by setting the `gitcvs.usecrlfattr` config variable. -In this case, if `crlf` is explicitly unset ('-crlf'), then the -server will set '-kb' mode for binary files. If `crlf` is set, -then the '-k' mode will explicitly be left blank. See -also linkgit:gitattributes[5] for more information about the `crlf` -attribute. +You can make the server use the end-of-line conversion attributes to +set the '-k' modes for files by setting the `gitcvs.usecrlfattr` +config variable. See linkgit:gitattributes[5] for more information +about end-of-line conversion. Alternatively, if `gitcvs.usecrlfattr` config is not enabled -or if the `crlf` attribute is unspecified for a filename, then +or the attributes do not allow automatic detection for a filename, then the server uses the `gitcvs.allbinary` config for the default setting. If `gitcvs.allbinary` is set, then file not otherwise specified will default to '-kb' mode. Otherwise the '-k' mode diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index 723a64872f..08fd4099ad 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -68,11 +68,11 @@ for the last two forms that use ".." notations, can be any <tree-ish>. For a more complete list of ways to spell <commit>, see -"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. +"SPECIFYING REVISIONS" section in linkgit:gitrevisions[1]. However, "diff" is about comparing two _endpoints_, not ranges, and the range notations ("<commit>..<commit>" and "<commit>\...<commit>") do not mean a range as defined in the -"SPECIFYING RANGES" section in linkgit:git-rev-parse[1]. +"SPECIFYING RANGES" section in linkgit:gitrevisions[1]. OPTIONS ------- diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 19082b04eb..77a0a2481a 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -439,7 +439,7 @@ Marks must be declared (via `mark`) before they can be used. * A complete 40 byte or abbreviated commit SHA-1 in hex. * Any valid Git SHA-1 expression that resolves to a commit. See - ``SPECIFYING REVISIONS'' in linkgit:git-rev-parse[1] for details. + ``SPECIFYING REVISIONS'' in linkgit:gitrevisions[1] for details. The special case of restarting an incremental import from the current branch value should be written as: diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 7e83288d18..390d85ccae 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -86,6 +86,7 @@ objectsize:: objectname:: The object name (aka SHA-1). + For a non-ambiguous abbreviation of the object name append `:short`. upstream:: The name of a local ref which can be considered ``upstream'' diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 835fb7135b..4b3f5ba535 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -13,6 +13,7 @@ SYNOPSIS [--no-thread | --thread[=<style>]] [(--attach|--inline)[=<boundary>] | --no-attach] [-s | --signoff] + [--signature=<signature> | --no-signature] [-n | --numbered | -N | --no-numbered] [--start-number <n>] [--numbered-files] [--in-reply-to=Message-Id] [--suffix=.<sfx>] @@ -38,7 +39,7 @@ There are two ways to specify which commits to operate on. that leads to the <since> to be output. 2. Generic <revision range> expression (see "SPECIFYING - REVISIONS" section in linkgit:git-rev-parse[1]) means the + REVISIONS" section in linkgit:gitrevisions[1]) means the commits in the specified range. The first rule takes precedence in the case of a single <commit>. To @@ -180,6 +181,12 @@ will want to ensure that threading is disabled for `git send-email`. containing the shortlog and the overall diffstat. You can fill in a description in the file before sending it out. +--[no]-signature=<signature>:: + Add a signature to each message produced. Per RFC 3676 the signature + is separated from the body by a line with '-- ' on it. If the + signature option is omitted the signature defaults to the git version + number. + --suffix=.<sfx>:: Instead of using `.patch` as the suffix for generated filenames, use specified suffix. A common alternative is diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index cbe74d531a..315f07ef1c 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -88,6 +88,16 @@ commits prior to the amend or rebase occurring. Since these changes are not part of the current project most users will want to expire them sooner. This option defaults to '30 days'. +The above two configuration variables can be given to a pattern. For +example, this sets non-default expiry values only to remote tracking +branches: + +------------ +[gc "refs/remotes/*"] + reflogExpire = never + reflogexpireUnreachable = 3 days +------------ + The optional configuration variable 'gc.rerereresolved' indicates how long records of conflicted merge you resolved earlier are kept. This defaults to 60 days. diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt index 912bddd7b6..5474dd7f94 100644 --- a/Documentation/git-grep.txt +++ b/Documentation/git-grep.txt @@ -14,6 +14,7 @@ SYNOPSIS [-E | --extended-regexp] [-G | --basic-regexp] [-F | --fixed-strings] [-n] [-l | --files-with-matches] [-L | --files-without-match] + [(-O | --open-files-in-pager) [<pager>]] [-z | --null] [-c | --count] [--all-match] [-q | --quiet] [--max-depth <depth>] @@ -104,6 +105,13 @@ OPTIONS For better compatibility with 'git diff', `--name-only` is a synonym for `--files-with-matches`. +-O [<pager>]:: +--open-files-in-pager [<pager>]:: + Open the matching files in the pager (not the output of 'grep'). + If the pager happens to be "less" or "vi", and the user + specified only one pattern, the first file is positioned at + the first match automatically. + -z:: --null:: Output \0 instead of the character that normally follows a diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt index a1f17df074..2c3c4d2994 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 apache2, lighttpd, mongoose and webrick are supported. + Currently apache2, lighttpd, mongoose, plackup and webrick are supported. (Default: lighttpd) -m:: diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index d7f6a9cc3e..e970664fe1 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -23,9 +23,6 @@ each commit introduces are shown. OPTIONS ------- -:git-log: 1 -include::diff-options.txt[] - -<n>:: Limits the number of commits to show. @@ -34,10 +31,14 @@ include::diff-options.txt[] either <since> or <until> is omitted, it defaults to `HEAD`, i.e. the tip of the current branch. For a more complete list of ways to spell <since> - and <until>, see "SPECIFYING REVISIONS" section in - linkgit:git-rev-parse[1]. + and <until>, see linkgit:gitrevisions[1]. + +--follow:: + Continue listing the history of a file beyond renames + (works only for a single file). ---decorate[=short|full]:: +--no-decorate:: +--decorate[=short|full|no]:: 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 @@ -55,9 +56,6 @@ include::diff-options.txt[] the specified paths; this means that "<path>..." limits only commits, and doesn't limit diff for those commits. ---follow:: - Continue listing the history of a file beyond renames. - --log-size:: Before the log message print out its size in bytes. Intended mainly for porcelain tools consumption. If git is unable to @@ -71,6 +69,11 @@ include::diff-options.txt[] to be prefixed with "\-- " to separate them from options or refnames. +Common diff options +~~~~~~~~~~~~~~~~~~~ + +:git-log: 1 +include::diff-options.txt[] include::rev-list-options.txt[] diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index de63ef0745..5540af5d16 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -15,7 +15,7 @@ SYNOPSIS 'git notes' edit [<object>] 'git notes' show [<object>] 'git notes' remove [<object>] -'git notes' prune +'git notes' prune [-n | -v] DESCRIPTION @@ -128,6 +128,13 @@ OPTIONS 'GIT_NOTES_REF' and the "core.notesRef" configuration. The ref is taken to be in `refs/notes/` if it is not qualified. +-n:: + Do not remove anything; just report the object names whose notes + would be removed. + +-v:: + Report all object names whose notes are removed. + DISCUSSION ---------- diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 48570242fb..b68abff28a 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -41,7 +41,7 @@ OPTIONS[[OPTIONS]] + 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]). +`HEAD` (see linkgit:gitrevisions[1]). + The <dst> tells which ref on the remote side is updated with this push. Arbitrary expressions cannot be used here, an actual ref must diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt index 4eaa62b691..5a0451aaf3 100644 --- a/Documentation/git-reflog.txt +++ b/Documentation/git-reflog.txt @@ -40,7 +40,7 @@ see linkgit:git-log[1]. The reflog is useful in various git commands, to specify the old value of a reference. For example, `HEAD@\{2\}` means "where HEAD used to be two moves ago", `master@\{one.week.ago\}` means "where master used to -point to one week ago", and so on. See linkgit:git-rev-parse[1] for +point to one week ago", and so on. See linkgit:gitrevisions[1] for more details. To delete single entries from the reflog, use the subcommand "delete" diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index 3fc599c0c7..aa021b0cb8 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -10,10 +10,11 @@ SYNOPSIS -------- [verse] 'git remote' [-v | --verbose] -'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url> +'git remote add' [-t <branch>] [-m <master>] [-f] [--tags|--no-tags] [--mirror] <name> <url> 'git remote rename' <old> <new> 'git remote rm' <name> 'git remote set-head' <name> (-a | -d | <branch>) +'git remote set-branches' <name> [--add] <branch>... 'git remote set-url' [--push] <name> <newurl> [<oldurl>] 'git remote set-url --add' [--push] <name> <newurl> 'git remote set-url --delete' [--push] <name> <url> @@ -51,6 +52,12 @@ update remote-tracking branches <name>/<branch>. With `-f` option, `git fetch <name>` is run immediately after the remote information is set up. + +With `--tags` option, `git fetch <name>` imports every tag from the +remote repository. ++ +With `--no-tags` option, `git fetch <name>` does not import tags from +the remote repository. ++ With `-t <branch>` option, instead of the default glob refspec for the remote to track all branches under `$GIT_DIR/remotes/<name>/`, a refspec to track only `<branch>` @@ -104,6 +111,18 @@ remote set-head origin master" will set `$GIT_DIR/refs/remotes/origin/HEAD` to `refs/remotes/origin/master` already exists; if not it must be fetched first. + +'set-branches':: + +Changes the list of branches tracked by the named remote. +This can be used to track a subset of the available remote branches +after the initial setup for a remote. ++ +The named branches will be interpreted as if specified with the +`-t` option on the 'git remote add' command line. ++ +With `--add`, instead of replacing the list of currently tracked +branches, adds to that list. + 'set-url':: Changes URL remote points to. Sets first URL remote points to matching diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index 833a2a29cc..0727f431c6 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -174,205 +174,7 @@ shown. If the pattern does not contain a globbing character (`?`, Flags and parameters to be parsed. -SPECIFYING REVISIONS --------------------- - -A revision parameter typically, but not necessarily, names a -commit object. They use what is called an 'extended SHA1' -syntax. Here are various ways to spell object names. The -ones listed near the end of this list are to name trees and -blobs contained in a commit. - -* The full SHA1 object name (40-byte hexadecimal string), or - a substring of such that is unique within the repository. - E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both - name the same commit object if there are no other object in - your repository whose object name starts with dae86e. - -* An output from 'git describe'; i.e. a closest tag, optionally - followed by a dash and a number of commits, followed by a dash, a - `g`, and an abbreviated object name. - -* A symbolic ref name. E.g. 'master' typically means the commit - object referenced by refs/heads/master. If you - happen to have both heads/master and tags/master, you can - explicitly say 'heads/master' to tell git which one you mean. - When ambiguous, a `<name>` is disambiguated by taking the - first match in the following rules: - - . if `$GIT_DIR/<name>` exists, that is what you mean (this is usually - useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD` and `MERGE_HEAD`); - - . otherwise, `refs/<name>` if exists; - - . otherwise, `refs/tags/<name>` if exists; - - . otherwise, `refs/heads/<name>` if exists; - - . otherwise, `refs/remotes/<name>` if exists; - - . otherwise, `refs/remotes/<name>/HEAD` if exists. -+ -HEAD names the commit your changes in the working tree is based on. -FETCH_HEAD records the branch you fetched from a remote repository -with your last 'git fetch' invocation. -ORIG_HEAD is created by commands that moves your HEAD in a drastic -way, to record the position of the HEAD before their operation, so that -you can change the tip of the branch back to the state before you ran -them easily. -MERGE_HEAD records the commit(s) you are merging into your branch -when you run 'git merge'. -+ -Note that any of the `refs/*` cases above may come either from -the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file. - -* A ref followed by the suffix '@' with a date specification - enclosed in a brace - pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1 - second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value - of the ref at a prior point in time. This suffix may only be - used immediately following a ref name and the ref must have an - existing log ($GIT_DIR/logs/<ref>). Note that this looks up the state - of your *local* ref at a given time; e.g., what was in your local - `master` branch last week. If you want to look at commits made during - certain times, see `--since` and `--until`. - -* A ref followed by the suffix '@' with an ordinal specification - enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify - the n-th prior value of that ref. For example 'master@\{1\}' - is the immediate prior value of 'master' while 'master@\{5\}' - is the 5th prior value of 'master'. This suffix may only be used - immediately following a ref name and the ref must have an existing - log ($GIT_DIR/logs/<ref>). - -* You can use the '@' construct with an empty ref part to get at a - reflog of the current branch. For example, if you are on the - branch 'blabla', then '@\{1\}' means the same as 'blabla@\{1\}'. - -* The special construct '@\{-<n>\}' means the <n>th branch checked out - before the current one. - -* The suffix '@\{upstream\}' to a ref (short form 'ref@\{u\}') refers to - the branch the ref is set to build on top of. Missing ref defaults - to the current branch. - -* A suffix '{caret}' to a revision parameter (e.g. 'HEAD{caret}') means the first parent of - that commit object. '{caret}<n>' means the <n>th parent (i.e. - 'rev{caret}' - is equivalent to 'rev{caret}1'). As a special rule, - 'rev{caret}0' means the commit itself and is used when 'rev' is the - object name of a tag object that refers to a commit object. - -* A suffix '{tilde}<n>' to a revision parameter means the commit - object that is the <n>th generation grand-parent of the named - commit object, following only the first parent. I.e. rev~3 is - equivalent to rev{caret}{caret}{caret} which is equivalent to - rev{caret}1{caret}1{caret}1. See below for a illustration of - the usage of this form. - -* A suffix '{caret}' followed by an object type name enclosed in - brace pair (e.g. `v0.99.8{caret}\{commit\}`) means the object - could be a tag, and dereference the tag recursively until an - object of that type is found or the object cannot be - dereferenced anymore (in which case, barf). `rev{caret}0` - introduced earlier is a short-hand for `rev{caret}\{commit\}`. - -* A suffix '{caret}' followed by an empty brace pair - (e.g. `v0.99.8{caret}\{\}`) means the object could be a tag, - and dereference the tag recursively until a non-tag object is - found. - -* A colon, followed by a slash, followed by a text (e.g. `:/fix nasty bug`): this names - a commit whose commit message starts with the specified text. - This name returns the youngest matching commit which is - reachable from any ref. If the commit message starts with a - '!', you have to repeat that; the special sequence ':/!', - followed by something else than '!' is reserved for now. - -* A suffix ':' followed by a path (e.g. `HEAD:README`); this names the blob or tree - at the given path in the tree-ish object named by the part - before the colon. - ':path' (with an empty part before the colon, e.g. `:README`) - is a special case of the syntax described next: content - recorded in the index at the given path. - -* A colon, optionally followed by a stage number (0 to 3) and a - colon, followed by a path (e.g. `:0:README`); this names a blob object in the - index at the given path. Missing stage number (and the colon - that follows it, e.g. `:README`) names a stage 0 entry. During a merge, stage - 1 is the common ancestor, stage 2 is the target branch's version - (typically the current branch), and stage 3 is the version from - the branch being merged. - -Here is an illustration, by Jon Loeliger. Both commit nodes B -and C are parents of commit node A. Parent commits are ordered -left-to-right. - -........................................ -G H I J - \ / \ / - D E F - \ | / \ - \ | / | - \|/ | - B C - \ / - \ / - A -........................................ - - A = = A^0 - B = A^ = A^1 = A~1 - C = A^2 = A^2 - D = A^^ = A^1^1 = A~2 - E = B^2 = A^^2 - F = B^3 = A^^3 - G = A^^^ = A^1^1^1 = A~3 - H = D^2 = B^^2 = A^^^2 = A~2^2 - I = F^ = B^3^ = A^^3^ - J = F^2 = B^3^2 = A^^3^2 - - -SPECIFYING RANGES ------------------ - -History traversing commands such as 'git log' operate on a set -of commits, not just a single commit. To these commands, -specifying a single revision with the notation described in the -previous section means the set of commits reachable from that -commit, following the commit ancestry chain. - -To exclude commits reachable from a commit, a prefix `{caret}` -notation is used. E.g. `{caret}r1 r2` means commits reachable -from `r2` but exclude the ones reachable from `r1`. - -This set operation appears so often that there is a shorthand -for it. When you have two commits `r1` and `r2` (named according -to the syntax explained in SPECIFYING REVISIONS above), you can ask -for commits that are reachable from r2 excluding those that are reachable -from r1 by `{caret}r1 r2` and it can be written as `r1..r2`. - -A similar notation `r1\...r2` is called symmetric difference -of `r1` and `r2` and is defined as -`r1 r2 --not $(git merge-base --all r1 r2)`. -It is the set of commits that are reachable from either one of -`r1` or `r2` but not from both. - -Two other shorthands for naming a set that is formed by a commit -and its parent commits exist. The `r1{caret}@` notation means all -parents of `r1`. `r1{caret}!` includes commit `r1` but excludes -all of its parents. - -Here are a handful of examples: - - D G H D - D F G H I J D F - ^G D H D - ^D B E I J F B - B...C G H D E B C - ^D B C E I J F B C - C^@ I J F - F^! D G H D F +include::revisions.txt[] PARSEOPT -------- diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt index c66bf8072e..b7d9ef7e47 100644 --- a/Documentation/git-revert.txt +++ b/Documentation/git-revert.txt @@ -3,20 +3,22 @@ git-revert(1) NAME ---- -git-revert - Revert an existing commit +git-revert - Revert some existing commits SYNOPSIS -------- -'git revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit> +'git revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>... DESCRIPTION ----------- -Given one existing commit, revert the change the patch introduces, and record a -new commit that records it. This requires your working tree to be clean (no -modifications from the HEAD commit). -Note: 'git revert' is used to record a new commit to reverse the -effect of an earlier commit (often a faulty one). If you want to +Given one or more existing commits, revert the changes that the +related patches introduce, and record some new commits that record +them. This requires your working tree to be clean (no modifications +from the HEAD commit). + +Note: 'git revert' is used to record some new commits to reverse the +effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see linkgit:git-reset[1], particularly the '--hard' option. If you want to extract specific files as they were in another commit, you @@ -26,10 +28,13 @@ both will discard uncommitted changes in your working directory. OPTIONS ------- -<commit>:: - Commit to revert. +<commit>...:: + Commits to revert. For a more complete list of ways to spell commit names, see - "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. + linkgit:gitrevisions[1]. + Sets of commits can also be given but no traversal is done by + default, see linkgit:git-rev-list[1] and its '--no-walk' + option. -e:: --edit:: @@ -59,11 +64,11 @@ more details. -n:: --no-commit:: - Usually the command automatically creates a commit with - a commit log message stating which commit was - reverted. This flag applies the change necessary - to revert the named commit to your working tree - and the index, but does not make the commit. In addition, + Usually the command automatically creates some commits with + commit log messages stating which commits were + reverted. This flag applies the changes necessary + to revert the named commits to your working tree + and the index, but does not make the commits. In addition, when this option is used, your index does not have to match the HEAD commit. The revert is done against the beginning state of your index. @@ -75,6 +80,20 @@ effect to your index in a row. --signoff:: Add Signed-off-by line at the end of the commit message. +EXAMPLES +-------- +git revert HEAD~3:: + + Revert the changes specified by the fourth last commit in HEAD + and create a new commit with the reverted changes. + +git revert -n master\~5..master~2:: + + Revert the changes done by commits from the fifth last commit + in master (included) to the third last commit in master + (included), but do not create any commit with the reverted + changes. The revert only modifies the working tree and the + index. Author ------ @@ -84,6 +103,10 @@ Documentation -------------- Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. +SEE ALSO +-------- +linkgit:git-cherry-pick[1] + GIT --- Part of the linkgit:git[1] suite diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt index f1499bba88..81ba29669c 100644 --- a/Documentation/git-show-branch.txt +++ b/Documentation/git-show-branch.txt @@ -32,7 +32,7 @@ no <rev> nor <glob> is given on the command line. OPTIONS ------- <rev>:: - Arbitrary extended SHA1 expression (see linkgit:git-rev-parse[1]) + Arbitrary extended SHA1 expression (see linkgit:gitrevisions[1]) that typically names a branch head or a tag. <glob>:: diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt index 55e687a7c7..0002bfb045 100644 --- a/Documentation/git-show.txt +++ b/Documentation/git-show.txt @@ -36,7 +36,7 @@ OPTIONS <object>...:: The names of objects to show. For a more complete list of ways to spell object names, see - "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. + "SPECIFYING REVISIONS" section in linkgit:gitrevisions[1]. include::pretty-options.txt[] diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index 2d4bbfcaf4..2fd054c104 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -27,6 +27,10 @@ OPTIONS --short:: Give the output in the short-format. +-b:: +--branch:: + Show the branch and tracking info even in short-format. + --porcelain:: Give the output in a stable, easy-to-parse format for scripts. Currently this is identical to --short output, but is guaranteed @@ -49,6 +53,17 @@ See linkgit:git-config[1] for configuration variable used to change the default for when the option is not specified. +--ignore-submodules[=<when>]:: + Ignore changes to submodules when looking for changes. <when> can be + either "untracked", "dirty" or "all", which is the default. When + "untracked" is used submodules are not considered dirty when they only + contain untracked content (but they are still scanned for modified + content). Using "dirty" ignores all changes to the work tree of submodules, + only changes to the commits stored in the superproject are shown (this was + the behavior before 1.7.0). Using "all" hides all changes to submodules + (and suppresses the output of submodule summaries when the config option + `status.submodulesummary` is set). + -z:: Terminate entries with NUL, instead of LF. This implies the `--porcelain` output format if no other format is given. @@ -120,6 +135,10 @@ Ignored files are not listed. ? ? untracked ------------------------------------------------- +If -b is used the short-format status is preceded by a line + +## branchname tracking info + There is an alternate -z format recommended for machine parsing. In that format, the status field is the same, but some other things change. First, the '->' is omitted from rename entries and the field @@ -128,7 +147,7 @@ order is reversed (e.g 'from -> to' becomes 'to from'). Second, a NUL and the terminating newline (but a space still separates the status field from the first filename). Third, filenames containing special characters are not specially formatted; no quoting or -backslash-escaping is performed. +backslash-escaping is performed. Fourth, there is no branch line. CONFIGURATION ------------- diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 2502531a3d..76a832a3ac 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -95,6 +95,10 @@ is the superproject and submodule repositories will be kept together in the same relative location, and only the superproject's URL needs to be provided: git-submodule will correctly locate the submodule using the relative URL in .gitmodules. ++ +The submodule will be added with "git add --force <path>". I.e. git +doesn't care if the new path is in a `gitignore`. Your invocation of +"git submodule add" is considered enough to override it. status:: Show the status of the submodules. This will print the SHA-1 of the @@ -145,10 +149,12 @@ summary:: foreach:: Evaluates an arbitrary shell command in each checked out submodule. - The command has access to the variables $name, $path and $sha1: + The command has access to the variables $name, $path, $sha1 and + $toplevel: $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. + superproject, $sha1 is the commit as recorded in the superproject, + and $toplevel is the absolute path to the top-level of the superproject. Any submodules defined in the superproject but not checked out are ignored by this command. Unless given --quiet, foreach prints the name of each submodule before evaluating the command. diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 99f3c1ea6c..b09bd9761f 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -243,7 +243,7 @@ where <name> is the name of the SVN repository as specified by the -R option to --username;; Specify the SVN username to perform the commit as. This option overrides - configuration property 'username'. + the 'username' configuration property. --commit-url;; Use the specified URL to connect to the destination Subversion diff --git a/Documentation/git.txt b/Documentation/git.txt index c4024d0edd..12066ab3fc 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -12,6 +12,7 @@ SYNOPSIS 'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path] [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] + [-c name=value] [--help] COMMAND [ARGS] DESCRIPTION @@ -43,9 +44,10 @@ 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.1/git.html[documentation for release 1.7.1] +* link:v1.7.1.1/git.html[documentation for release 1.7.1.1] * release notes for + link:RelNotes-1.7.1.1.txt[1.7.1.1], link:RelNotes-1.7.1.txt[1.7.1]. * link:v1.7.0.6/git.html[documentation for release 1.7.0.6] @@ -228,6 +230,12 @@ displayed. See linkgit:git-help[1] for more information, because `git --help ...` is converted internally into `git help ...`. +-c <name>=<value>:: + Pass a configuration parameter to the command. The value + given will override values from configuration files. + The <name> is expected in the same format as listed by + 'git config' (subkeys separated by dots). + --exec-path:: Path to wherever your core git programs are installed. This can also be controlled by setting the GIT_EXEC_PATH @@ -471,7 +479,7 @@ HEAD:: (i.e. the contents of `$GIT_DIR/refs/heads/<head>`). For a more complete list of ways to spell object names, see -"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. +"SPECIFYING REVISIONS" section in linkgit:gitrevisions[1]. File/Directory Structure @@ -538,6 +546,16 @@ git so take care if using Cogito etc. a GIT_DIR set on the command line or in the environment. (Useful for excluding slow-loading network directories.) +'GIT_DISCOVERY_ACROSS_FILESYSTEM':: + When run in a directory that does not have ".git" repository + directory, git tries to find such a directory in the parent + directories to find the top of the working tree, but by default it + does not cross filesystem boundaries. This environment variable + can be set to true to tell git not to stop at filesystem + boundaries. Like 'GIT_CEILING_DIRECTORIES', this will not affect + an explicit repository directory set via 'GIT_DIR' or on the + command line. + git Commits ~~~~~~~~~~~ 'GIT_AUTHOR_NAME':: diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index d892e642ed..564586b943 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -92,53 +92,154 @@ such as 'git checkout' and 'git merge' run. They also affect how git stores the contents you prepare in the working tree in the repository upon 'git add' and 'git commit'. -`crlf` +`text` ^^^^^^ -This attribute controls the line-ending convention. +This attribute enables and controls end-of-line normalization. When a +text file is normalized, its line endings are converted to LF in the +repository. To control what line ending style is used in the working +directory, use the `eol` attribute for a single file and the +`core.eol` configuration variable for all text files. Set:: - Setting the `crlf` attribute on a path is meant to mark - the path as a "text" file. 'core.autocrlf' conversion - takes place without guessing the content type by - inspection. + Setting the `text` attribute on a path enables end-of-line + normalization and marks the path as a text file. End-of-line + conversion takes place without guessing the content type. Unset:: - Unsetting the `crlf` attribute on a path tells git not to + Unsetting the `text` attribute on a path tells git not to attempt any end-of-line conversion upon checkin or checkout. +Set to string value "auto":: + + When `text` is set to "auto", the path is marked for automatic + end-of-line normalization. If git decides that the content is + text, its line endings are normalized to LF on checkin. + Unspecified:: - Unspecified `crlf` attribute tells git to apply the - `core.autocrlf` conversion when the file content looks - like text. + If the `text` attribute is unspecified, git uses the + `core.autocrlf` configuration variable to determine if the + file should be converted. -Set to string value "input":: +Any other value causes git to act as if `text` has been left +unspecified. - This is similar to setting the attribute to `true`, but - also forces git to act as if `core.autocrlf` is set to - `input` for the path. +`eol` +^^^^^ -Any other value set to `crlf` attribute is ignored and git acts -as if the attribute is left unspecified. +This attribute sets a specific line-ending style to be used in the +working directory. It enables end-of-line normalization without any +content checks, effectively setting the `text` attribute. +Set to string value "crlf":: -The `core.autocrlf` conversion -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + This setting forces git to normalize line endings for this + file on checkin and convert them to CRLF when the file is + checked out. + +Set to string value "lf":: + + This setting forces git to normalize line endings to LF on + checkin and prevents conversion to CRLF when the file is + checked out. + +Backwards compatibility with `crlf` attribute +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For backwards compatibility, the `crlf` attribute is interpreted as +follows: + +------------------------ +crlf text +-crlf -text +crlf=input eol=lf +------------------------ + +End-of-line conversion +^^^^^^^^^^^^^^^^^^^^^^ + +While git normally leaves file contents alone, it can be configured to +normalize line endings to LF in the repository and, optionally, to +convert them to CRLF when files are checked out. + +Here is an example that will make git normalize .txt, .vcproj and .sh +files, ensure that .vcproj files have CRLF and .sh files have LF in +the working directory, and prevent .jpg files from being normalized +regardless of their content. + +------------------------ +*.txt text +*.vcproj eol=crlf +*.sh eol=lf +*.jpg -text +------------------------ + +Other source code management systems normalize all text files in their +repositories, and there are two ways to enable similar automatic +normalization in git. + +If you simply want to have CRLF line endings in your working directory +regardless of the repository you are working with, you can set the +config variable "core.autocrlf" without changing any attributes. -If the configuration variable `core.autocrlf` is false, no -conversion is done. +------------------------ +[core] + autocrlf = true +------------------------ + +This does not force normalization of all text files, but does ensure +that text files that you introduce to the repository have their line +endings normalized to LF when they are added, and that files that are +already normalized in the repository stay normalized. + +If you want to interoperate with a source code management system that +enforces end-of-line normalization, or you simply want all text files +in your repository to be normalized, you should instead set the `text` +attribute to "auto" for _all_ files. + +------------------------ +* text=auto +------------------------ + +This ensures that all files that git considers to be text will have +normalized (LF) line endings in the repository. The `core.eol` +configuration variable controls which line endings git will use for +normalized files in your working directory; the default is to use the +native line ending for your platform, or CRLF if `core.autocrlf` is +set. + +NOTE: When `text=auto` normalization is enabled in an existing +repository, any text files containing CRLFs should be normalized. If +they are not they will be normalized the next time someone tries to +change them, causing unfortunate misattribution. From a clean working +directory: + +------------------------------------------------- +$ echo "* text=auto" >>.gitattributes +$ rm .git/index # Remove the index to force git to +$ git reset # re-scan the working directory +$ git status # Show files that will be normalized +$ git add -u +$ git add .gitattributes +$ git commit -m "Introduce end-of-line normalization" +------------------------------------------------- + +If any files that should not be normalized show up in 'git status', +unset their `text` attribute before running 'git add -u'. -When `core.autocrlf` is true, it means that the platform wants -CRLF line endings for files in the working tree, and you want to -convert them back to the normal LF line endings when checking -in to the repository. +------------------------ +manual.pdf -text +------------------------ -When `core.autocrlf` is set to "input", line endings are -converted to LF upon checkin, but there is no conversion done -upon checkout. +Conversely, text files that git does not detect can have normalization +enabled manually. + +------------------------ +weirdchars.txt text +------------------------ If `core.safecrlf` is set to "true" or "warn", git verifies if the conversion is reversible for the current setting of @@ -223,11 +324,11 @@ Interaction between checkin/checkout attributes In the check-in codepath, the worktree file is first converted with `filter` driver (if specified and corresponding driver defined), then the result is processed with `ident` (if -specified), and then finally with `crlf` (again, if specified +specified), and then finally with `text` (again, if specified and applicable). In the check-out codepath, the blob content is first converted -with `crlf`, and then `ident` and fed to `filter`. +with `text`, and then `ident` and fed to `filter`. Generating diff text @@ -360,7 +461,7 @@ patterns are available: Customizing word diff ^^^^^^^^^^^^^^^^^^^^^ -You can customize the rules that `git diff --color-words` uses to +You can customize the rules that `git diff --word-diff` 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 @@ -414,6 +515,26 @@ 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. +Because text conversion can be slow, especially when doing a +large number of them with `git log -p`, git provides a mechanism +to cache the output and use it in future diffs. To enable +caching, set the "cachetextconv" variable in your diff driver's +config. For example: + +------------------------ +[diff "jpg"] + textconv = exif + cachetextconv = true +------------------------ + +This will cache the result of running "exif" on each blob +indefinitely. If you change the textconv config variable for a +diff driver, git will automatically invalidate the cache entries +and re-run the textconv filter. If you want to invalidate the +cache manually (e.g., because your version of "exif" was updated +and now produces better output), you can remove the cache +manually with `git update-ref -d refs/notes/textconv/jpg` (where +"jpg" is the name of the diff driver, as in the example above). Performing a three-way merge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -631,7 +752,7 @@ You do not want any end-of-line conversions applied to, nor textual diffs produced for, any binary file you track. You would need to specify e.g. ------------ -*.jpg -crlf -diff +*.jpg -text -diff ------------ but that may become cumbersome, when you have many attributes. Using @@ -644,7 +765,7 @@ the same time. The system knows a built-in attribute macro, `binary`: which is equivalent to the above. Note that the attribute macros can only be "Set" (see the above example that sets "binary" macro as if it were an -ordinary attribute --- setting it in turn unsets "crlf" and "diff"). +ordinary attribute --- setting it in turn unsets "text" and "diff"). DEFINING ATTRIBUTE MACROS @@ -655,7 +776,7 @@ at the toplevel (i.e. not in any subdirectory). The built-in attribute macro "binary" is equivalent to: ------------ -[attr]binary -diff -crlf +[attr]binary -diff -text ------------ diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index f7815e96a2..ed3ddc92cb 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -971,7 +971,7 @@ commits from the master branch. The string inside brackets before the commit log message is a short name you can use to name the commit. In the above example, 'master' and 'mybranch' are branch heads. 'master^' is the first parent of 'master' -branch head. Please see linkgit:git-rev-parse[1] if you want to +branch head. Please see linkgit:gitrevisions[1] if you want to see more complex cases. [NOTE] diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index 99baa24a2d..05ac1c79f7 100644 --- a/Documentation/gitk.txt +++ b/Documentation/gitk.txt @@ -69,7 +69,7 @@ frequently used options. the form "'<from>'..'<to>'" to show all revisions between '<from>' and back to '<to>'. Note, more advanced revision selection can be applied. For a more complete list of ways to spell object names, see - "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1]. + linkgit:gitrevisions[1]. <path>...:: diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt index 5daf750d19..72a13d18e0 100644 --- a/Documentation/gitmodules.txt +++ b/Documentation/gitmodules.txt @@ -29,6 +29,9 @@ submodule.<name>.path:: submodule.<name>.url:: Defines an url from where the submodule repository can be cloned. + This may be either an absolute URL ready to be passed to + linkgit:git-clone[1] or (if it begins with ./ or ../) a location + relative to the superproject's origin repository. submodule.<name>.update:: Defines what to do when the submodule is updated by the superproject. diff --git a/Documentation/gitrevisions.txt b/Documentation/gitrevisions.txt new file mode 100644 index 0000000000..fc4789f98e --- /dev/null +++ b/Documentation/gitrevisions.txt @@ -0,0 +1,35 @@ +gitrevisions(7) +================ + +NAME +---- +gitrevisions - specifying revisions and ranges for git + +SYNOPSIS +-------- +gitrevisions + + +DESCRIPTION +----------- + +Many Git commands take revision parameters as arguments. Depending on +the command, they denote a specific commit or, for commands which +walk the revision graph (such as linkgit:git-log[1]), all commits which can +be reached from that commit. In the latter case one can also specify a +range of revisions explicitly. + +In addition, some Git commands (such as linkgit:git-show[1]) also take +revision parameters which denote other objects than commits, e.g. blobs +("files") or trees ("directories of files"). + +include::revisions.txt[] + + +SEE ALSO +-------- +linkgit:git-rev-parse[1] + +GIT +--- +Part of the linkgit:git[1] suite diff --git a/Documentation/install-webdoc.sh b/Documentation/install-webdoc.sh index 2135a8ee1f..34d02a2418 100755 --- a/Documentation/install-webdoc.sh +++ b/Documentation/install-webdoc.sh @@ -12,7 +12,7 @@ do then : did not match elif test -f "$T/$h" && - diff -u -I'Last updated [0-9][0-9]-[A-Z][a-z][a-z]-' "$T/$h" "$h" + $DIFF -u -I'Last updated [0-9][0-9]-[A-Z][a-z][a-z]-' "$T/$h" "$h" then :; # up to date else diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index c85a52c0cc..561cc9f7d7 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -11,7 +11,12 @@ have limited your view of history: for example, if you are only interested in changes related to a certain directory or file. -Here are some additional details for each format: +There are several built-in formats, and you can define +additional formats by setting a pretty.<name> +config option to either another format name, or a +'format:' string, as described below (see +linkgit:git-config[1]). Here are the details of the +built-in formats: * 'oneline' @@ -123,6 +128,7 @@ The placeholders are: - '%s': subject - '%f': sanitized subject line, suitable for a filename - '%b': body +- '%B': raw body (unwrapped subject and body) - '%N': commit notes - '%gD': reflog selector, e.g., `refs/stash@\{1\}` - '%gd': shortened reflog selector, e.g., `stash@\{1\}` @@ -153,6 +159,10 @@ If you add a `-` (minus sign) after '%' of a placeholder, line-feeds that immediately precede the expansion are deleted if and only if the placeholder expands to an empty string. +If you add a ` ` (space) after '%' of a placeholder, a space +is inserted immediately before the expansion if and only if the +placeholder expands to a non-empty string. + * 'tformat:' + The 'tformat:' format works exactly like 'format:', except that it diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index b9fb7a86bd..cc562a057a 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -98,6 +98,15 @@ you would get an output like this: This implies the '--topo-order' option by default, but the '--date-order' option may also be specified. +ifdef::git-rev-list[] +--count:: + Print a number stating how many commits would have been + listed, and suppress all other output. When used together + with '--left-right', instead print the counts for left and + right commits, separated by a tab. +endif::git-rev-list[] + + ifndef::git-rev-list[] Diff Formatting ~~~~~~~~~~~~~~~ @@ -384,6 +393,14 @@ Default mode:: merges from the resulting history, as there are no selected commits contributing to this merge. +--ancestry-path:: + + When given a range of commits to display (e.g. 'commit1..commit2' + or 'commit2 {caret}commit1'), only display commits that exist + directly on the ancestry chain between the 'commit1' and + 'commit2', i.e. commits that are both descendants of 'commit1', + and ancestors of 'commit2'. + A more detailed explanation follows. Suppose you specified `foo` as the <paths>. We shall call commits @@ -440,7 +457,7 @@ This results in: + ----------------------------------------------------------------------- .-A---N---O - / / + / / / I---------D ----------------------------------------------------------------------- + @@ -511,8 +528,6 @@ 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 @@ -554,6 +569,46 @@ Note the major differences in `N` and `P` over '\--full-history': removed completely, because it had one parent and is TREESAME. -- +Finally, there is a fifth simplification mode available: + +--ancestry-path:: + + Limit the displayed commits to those directly on the ancestry + chain between the "from" and "to" commits in the given commit + range. I.e. only display commits that are ancestor of the "to" + commit, and descendants of the "from" commit. ++ +As an example use case, consider the following commit history: ++ +----------------------------------------------------------------------- + D---E-------F + / \ \ + B---C---G---H---I---J + / \ + A-------K---------------L--M +----------------------------------------------------------------------- ++ +A regular 'D..M' computes the set of commits that are ancestors of `M`, +but excludes the ones that are ancestors of `D`. This is useful to see +what happened to the history leading to `M` since `D`, in the sense +that "what does `M` have that did not exist in `D`". The result in this +example would be all the commits, except `A` and `B` (and `D` itself, +of course). ++ +When we want to find out what commits in `M` are contaminated with the +bug introduced by `D` and need fixing, however, we might want to view +only the subset of 'D..M' that are actually descendants of `D`, i.e. +excluding `C` and `K`. This is exactly what the '\--ancestry-path' +option does. Applied to the 'D..M' range, it results in: ++ +----------------------------------------------------------------------- + E-------F + \ \ + G---H---I---J + \ + L--M +----------------------------------------------------------------------- + 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 diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt new file mode 100644 index 0000000000..fe846f043c --- /dev/null +++ b/Documentation/revisions.txt @@ -0,0 +1,199 @@ +SPECIFYING REVISIONS +-------------------- + +A revision parameter typically, but not necessarily, names a +commit object. They use what is called an 'extended SHA1' +syntax. Here are various ways to spell object names. The +ones listed near the end of this list are to name trees and +blobs contained in a commit. + +* The full SHA1 object name (40-byte hexadecimal string), or + a substring of such that is unique within the repository. + E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both + name the same commit object if there are no other object in + your repository whose object name starts with dae86e. + +* An output from 'git describe'; i.e. a closest tag, optionally + followed by a dash and a number of commits, followed by a dash, a + `g`, and an abbreviated object name. + +* A symbolic ref name. E.g. 'master' typically means the commit + object referenced by refs/heads/master. If you + happen to have both heads/master and tags/master, you can + explicitly say 'heads/master' to tell git which one you mean. + When ambiguous, a `<name>` is disambiguated by taking the + first match in the following rules: + + . if `$GIT_DIR/<name>` exists, that is what you mean (this is usually + useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD` and `MERGE_HEAD`); + + . otherwise, `refs/<name>` if exists; + + . otherwise, `refs/tags/<name>` if exists; + + . otherwise, `refs/heads/<name>` if exists; + + . otherwise, `refs/remotes/<name>` if exists; + + . otherwise, `refs/remotes/<name>/HEAD` if exists. ++ +HEAD names the commit your changes in the working tree is based on. +FETCH_HEAD records the branch you fetched from a remote repository +with your last 'git fetch' invocation. +ORIG_HEAD is created by commands that moves your HEAD in a drastic +way, to record the position of the HEAD before their operation, so that +you can change the tip of the branch back to the state before you ran +them easily. +MERGE_HEAD records the commit(s) you are merging into your branch +when you run 'git merge'. ++ +Note that any of the `refs/*` cases above may come either from +the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file. + +* A ref followed by the suffix '@' with a date specification + enclosed in a brace + pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1 + second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value + of the ref at a prior point in time. This suffix may only be + used immediately following a ref name and the ref must have an + existing log ($GIT_DIR/logs/<ref>). Note that this looks up the state + of your *local* ref at a given time; e.g., what was in your local + `master` branch last week. If you want to look at commits made during + certain times, see `--since` and `--until`. + +* A ref followed by the suffix '@' with an ordinal specification + enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify + the n-th prior value of that ref. For example 'master@\{1\}' + is the immediate prior value of 'master' while 'master@\{5\}' + is the 5th prior value of 'master'. This suffix may only be used + immediately following a ref name and the ref must have an existing + log ($GIT_DIR/logs/<ref>). + +* You can use the '@' construct with an empty ref part to get at a + reflog of the current branch. For example, if you are on the + branch 'blabla', then '@\{1\}' means the same as 'blabla@\{1\}'. + +* The special construct '@\{-<n>\}' means the <n>th branch checked out + before the current one. + +* The suffix '@\{upstream\}' to a ref (short form 'ref@\{u\}') refers to + the branch the ref is set to build on top of. Missing ref defaults + to the current branch. + +* A suffix '{caret}' to a revision parameter (e.g. 'HEAD{caret}') means the first parent of + that commit object. '{caret}<n>' means the <n>th parent (i.e. + 'rev{caret}' + is equivalent to 'rev{caret}1'). As a special rule, + 'rev{caret}0' means the commit itself and is used when 'rev' is the + object name of a tag object that refers to a commit object. + +* A suffix '{tilde}<n>' to a revision parameter means the commit + object that is the <n>th generation grand-parent of the named + commit object, following only the first parent. I.e. rev~3 is + equivalent to rev{caret}{caret}{caret} which is equivalent to + rev{caret}1{caret}1{caret}1. See below for a illustration of + the usage of this form. + +* A suffix '{caret}' followed by an object type name enclosed in + brace pair (e.g. `v0.99.8{caret}\{commit\}`) means the object + could be a tag, and dereference the tag recursively until an + object of that type is found or the object cannot be + dereferenced anymore (in which case, barf). `rev{caret}0` + introduced earlier is a short-hand for `rev{caret}\{commit\}`. + +* A suffix '{caret}' followed by an empty brace pair + (e.g. `v0.99.8{caret}\{\}`) means the object could be a tag, + and dereference the tag recursively until a non-tag object is + found. + +* A colon, followed by a slash, followed by a text (e.g. `:/fix nasty bug`): this names + a commit whose commit message starts with the specified text. + This name returns the youngest matching commit which is + reachable from any ref. If the commit message starts with a + '!', you have to repeat that; the special sequence ':/!', + followed by something else than '!' is reserved for now. + +* A suffix ':' followed by a path (e.g. `HEAD:README`); this names the blob or tree + at the given path in the tree-ish object named by the part + before the colon. + ':path' (with an empty part before the colon, e.g. `:README`) + is a special case of the syntax described next: content + recorded in the index at the given path. + +* A colon, optionally followed by a stage number (0 to 3) and a + colon, followed by a path (e.g. `:0:README`); this names a blob object in the + index at the given path. Missing stage number (and the colon + that follows it, e.g. `:README`) names a stage 0 entry. During a merge, stage + 1 is the common ancestor, stage 2 is the target branch's version + (typically the current branch), and stage 3 is the version from + the branch being merged. + +Here is an illustration, by Jon Loeliger. Both commit nodes B +and C are parents of commit node A. Parent commits are ordered +left-to-right. + +........................................ +G H I J + \ / \ / + D E F + \ | / \ + \ | / | + \|/ | + B C + \ / + \ / + A +........................................ + + A = = A^0 + B = A^ = A^1 = A~1 + C = A^2 = A^2 + D = A^^ = A^1^1 = A~2 + E = B^2 = A^^2 + F = B^3 = A^^3 + G = A^^^ = A^1^1^1 = A~3 + H = D^2 = B^^2 = A^^^2 = A~2^2 + I = F^ = B^3^ = A^^3^ + J = F^2 = B^3^2 = A^^3^2 + + +SPECIFYING RANGES +----------------- + +History traversing commands such as 'git log' operate on a set +of commits, not just a single commit. To these commands, +specifying a single revision with the notation described in the +previous section means the set of commits reachable from that +commit, following the commit ancestry chain. + +To exclude commits reachable from a commit, a prefix `{caret}` +notation is used. E.g. `{caret}r1 r2` means commits reachable +from `r2` but exclude the ones reachable from `r1`. + +This set operation appears so often that there is a shorthand +for it. When you have two commits `r1` and `r2` (named according +to the syntax explained in SPECIFYING REVISIONS above), you can ask +for commits that are reachable from r2 excluding those that are reachable +from r1 by `{caret}r1 r2` and it can be written as `r1..r2`. + +A similar notation `r1\...r2` is called symmetric difference +of `r1` and `r2` and is defined as +`r1 r2 --not $(git merge-base --all r1 r2)`. +It is the set of commits that are reachable from either one of +`r1` or `r2` but not from both. + +Two other shorthands for naming a set that is formed by a commit +and its parent commits exist. The `r1{caret}@` notation means all +parents of `r1`. `r1{caret}!` includes commit `r1` but excludes +all of its parents. + +Here are a handful of examples: + + D G H D + D F G H I J D F + ^G D H D + ^D B E I J F B + B...C G H D E B C + ^D B C E I J F B C + C^@ I J F + F^! D G H D F diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt index 44876fa703..f18b4f4817 100644 --- a/Documentation/technical/api-run-command.txt +++ b/Documentation/technical/api-run-command.txt @@ -231,8 +231,9 @@ The function pointer in .proc has the following signature: There are serious restrictions on what the asynchronous function can do -because this facility is implemented by a pipe to a forked process on -UNIX, but by a thread in the same address space on Windows: +because this facility is implemented by a thread in the same address +space on most platforms (when pthreads is available), but by a pipe to +a forked process otherwise: . It cannot change the program's state (global variables, environment, etc.) in a way that the caller notices; in other words, .in and .out diff --git a/Documentation/technical/api-string-list.txt b/Documentation/technical/api-string-list.txt index 6d8c24bb1e..3f575bdcff 100644 --- a/Documentation/technical/api-string-list.txt +++ b/Documentation/technical/api-string-list.txt @@ -38,8 +38,8 @@ struct string_list list; int i; memset(&list, 0, sizeof(struct string_list)); -string_list_append("foo", &list); -string_list_append("bar", &list); +string_list_append(&list, "foo"); +string_list_append(&list, "bar"); for (i = 0; i < list.nr; i++) printf("%s\n", list.items[i].string) ---- diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index fe6fb722da..22aee34d4a 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -397,7 +397,7 @@ is usually a shortcut for the HEAD branch in the repository "origin". For the complete list of paths which git checks for references, and the order it uses to decide which to choose when there are multiple references with the same shorthand name, see the "SPECIFYING -REVISIONS" section of linkgit:git-rev-parse[1]. +REVISIONS" section of linkgit:gitrevisions[1]. [[Updating-a-repository-With-git-fetch]] Updating a repository with git fetch @@ -568,7 +568,7 @@ We have seen several ways of naming commits already: - HEAD: refers to the head of the current branch There are many more; see the "SPECIFYING REVISIONS" section of the -linkgit:git-rev-parse[1] man page for the complete list of ways to +linkgit:gitrevisions[1] man page for the complete list of ways to name revisions. Some examples: ------------------------------------------------- @@ -909,7 +909,7 @@ commits reachable from some head but not from any tag in the repository: $ gitk $( git show-ref --heads ) --not $( git show-ref --tags ) ------------------------------------------------- -(See linkgit:git-rev-parse[1] for explanations of commit-selecting +(See linkgit:gitrevisions[1] for explanations of commit-selecting syntax such as `--not`.) [[making-a-release]] @@ -1635,7 +1635,7 @@ you've checked out. The reflogs are kept by default for 30 days, after which they may be pruned. See linkgit:git-reflog[1] and linkgit:git-gc[1] to learn how to control this pruning, and see the "SPECIFYING REVISIONS" -section of linkgit:git-rev-parse[1] for details. +section of linkgit:gitrevisions[1] for details. Note that the reflog history is very different from normal git history. While normal history is shared by every repository that works on the |