diff options
Diffstat (limited to 'Documentation')
37 files changed, 1071 insertions, 399 deletions
diff --git a/Documentation/RelNotes-1.5.1.txt b/Documentation/RelNotes-1.5.1.txt new file mode 100644 index 0000000000..f78cf56bc8 --- /dev/null +++ b/Documentation/RelNotes-1.5.1.txt @@ -0,0 +1,165 @@ +GIT v1.5.1 Release Notes +======================== + +Updates since v1.5.0 +-------------------- + +* Deprecated commands and options. + + - git-diff-stages and git-resolve have been removed. + +* New commands and options. + + - "git log" and friends take --reverse. This makes output + that typically goes reverse order in chronological order. + "git shortlog" usually lists commits in chronological order, + but with "--reverse", they are shown in reverse + chronological order. + + - "git diff" learned --ignore-space-at-eol. This is a weaker + form of --ignore-space-change. + + - "git diff --no-index pathA pathB" can be used as diff + replacement with git specific enhancements. + + - "git diff --pretty=format:<string>" to allow more flexible + custom log output. + + - "git diff --no-index" can read from '-' (standard input). + + - "git diff" also learned --exit-code to exit with non-zero + status when it found differences. In the future we might + want to make this the default but that would be a rather big + backward incompatible change; it will stay as an option for + now. + + - "git branch --track" can be used to set up configuration + variables to help it easier to base your work on branches + you track from a remote site. + + - "git format-patch --attach" now emits attachments. Use + --inline to get an inlined multipart/mixed. + + - "git name-rev" learned --refs=<pattern>, to limit the tags + used for naming the given revisions only to the ones + matching the given pattern. + + - "git remote update" is to run "git fetch" for defined remotes + to update tracking branches. + + - "git cvsimport" can now take '-d' to talk with a CVS + repository different from what are recorded in CVS/Root + (overriding it with environment CVSROOT does not work). + + - "git bundle" can help sneaker-netting your changes between + repositories. + + - "git mergetool" can help 3-way file-level conflict + resolution with your favorite graphical merge tools. + + - A new configuration "core.symlinks" can be used to disable + symlinks on filesystems that do not support them; they are + checked out as regular files instead. + + +* Updated behaviour of existing commands. + + - "git fsck" does not barf on corrupt loose objects. + + - "git archimport" allows remapping when coming up with git + branch names from arch names. + + - git-svn got almost a rewrite. + + - core.autocrlf configuration, when set to 'true', makes git + to convert CRLF at the end of lines in text files to LF when + reading from the filesystem, and convert in reverse when + writing to the filesystem. The variable can be set to + 'input', in which case the conversion happens only while + reading from the filesystem but files are written out with + LF at the end of lines. Currently, which paths to consider + 'text' (i.e. be subjected to the autocrlf mechanism) is + decided purely based on the contents, but the plan is to + allow users to explicitly override this heuristic based on + paths. + + - The behaviour of 'git-apply', when run in a subdirectory, + without --index nor --cached were inconsistent with that of + the command with these options. This was fixed to match the + behaviour with --index. A patch that is meant to be applied + with -p1 from the toplevel of the project tree can be + applied with any custom -p<n> option. A patch that is not + relative to the toplevel needs to be applied with -p<n> + option with or without --index (or --cached). + + - "git diff" outputs a trailing HT when pathnames have embedded + SP on +++/--- header lines, in order to help "GNU patch" to + parse its output. "git apply" was already updated to accept + this modified output format since ce74618d (Sep 22, 2006). + + - "git cvsserver" runs hooks/update and honors its exit status. + + - "git cvsserver" can be told to send everything with -kb. + + - "git diff --check" also honors the --color output option. + + - "git name-rev" used to stress the fact that a ref is a tag too + much, by saying something like "v1.2.3^0~22". It now says + "v1.2.3~22" in such a case (it still says "v1.2.3^0" if it does + not talk about an ancestor of the commit that is tagged, which + makes sense). + + - "git rev-list --boundary" now shows boundary markers for the + commits omitted by --max-age and --max-count condition. + + - The configuration mechanism now reads $(prefix)/etc/gitconfig. + + - "git apply --verbose" shows what preimage lines were wanted + when it couldn't find them. + + - "git status" in a read-only repository got a bit saner. + + - "git fetch" (hence "git clone" and "git pull") are less + noisy when the output does not go to tty. + + - "git fetch" between repositories with many refs were slow + even when there are not many changes that needed + transferring. This has been sped up by partially rewriting + the heaviest parts in C. + + - "git mailinfo" which splits an e-mail into a patch and the + metainformation was rewritten, thanks to Don Zickus. It + handles nested multipart better. + + - send-email learned configurable bcc and chain-reply-to. + + - Using objects from packs is now seriouly optimized by clever + use of a cache. This should be most noticeable in git-log + family of commands that involve reading many tree objects. + In addition, traversing revisions while filtering changes + with pathspecs is made faster by terminating the comparison + between the trees as early as possible. + + +* Hooks + + - The sample update hook to show how to send out notification + e-mail was updated to show only new commits that appeared in + the repository. Earlier, it showed new commits that appeared + on the branch. + + +* Others + + - git-revert, git-gc and git-cherry-pick are now built-ins. + + +-- +exec >/var/tmp/1 +O=v1.5.0.5-446-g5d86501 +echo O=`git describe master` +git shortlog --no-merges $O..master ^maint + +# Local Variables: +# mode: text +# End: diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl index 75f4791055..b54382b2bf 100755 --- a/Documentation/cmd-list.perl +++ b/Documentation/cmd-list.perl @@ -70,6 +70,7 @@ git-archive mainporcelain git-bisect mainporcelain git-blame ancillaryinterrogators git-branch mainporcelain +git-bundle mainporcelain git-cat-file plumbinginterrogators git-checkout-index plumbingmanipulators git-checkout mainporcelain @@ -90,7 +91,6 @@ git-describe mainporcelain git-diff-files plumbinginterrogators git-diff-index plumbinginterrogators git-diff mainporcelain -git-diff-stages plumbinginterrogators git-diff-tree plumbinginterrogators git-fast-import ancillarymanipulators git-fetch mainporcelain @@ -124,6 +124,7 @@ git-merge-index plumbingmanipulators git-merge mainporcelain git-merge-one-file purehelpers git-merge-tree ancillaryinterrogators +git-mergetool ancillarymanipulators git-mktag plumbingmanipulators git-mktree plumbingmanipulators git-mv mainporcelain @@ -150,7 +151,6 @@ git-remote ancillarymanipulators git-request-pull foreignscminterface git-rerere ancillaryinterrogators git-reset mainporcelain -git-resolve mainporcelain git-revert mainporcelain git-rev-list plumbinginterrogators git-rev-parse ancillaryinterrogators diff --git a/Documentation/config.txt b/Documentation/config.txt index d9c12f14b9..cf1e040381 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -5,7 +5,8 @@ The git configuration file contains a number of variables that affect the git command's behavior. `.git/config` file for each repository is used to store the information for that repository, and `$HOME/.gitconfig` is used to store per user information to give -fallback values for `.git/config` file. +fallback values for `.git/config` file. The file `/etc/gitconfig` +can be used to store system-wide defaults. They can be used by both the git plumbing and the porcelains. The variables are divided into sections, where @@ -116,6 +117,13 @@ core.fileMode:: the working copy are ignored; useful on broken filesystems like FAT. See gitlink:git-update-index[1]. True by default. +core.symlinks:: + If false, symbolic links are checked out as small plain files that + contain the link text. gitlink:git-update-index[1] and + gitlink:git-add[1] will not change the recorded type to regular + file. Useful on filesystems like FAT that do not support + symbolic links. True by default. + core.gitProxy:: A "proxy command" to execute (as 'command host port') instead of establishing direct connection to the remote server when @@ -232,6 +240,19 @@ the largest projects. You probably do not need to adjust this value. + Common unit suffixes of 'k', 'm', or 'g' are supported. +core.deltaBaseCacheLimit:: + Maximum number of bytes to reserve for caching base objects + that multiple deltafied objects reference. By storing the + entire decompressed base objects in a cache Git is able + to avoid unpacking and decompressing frequently used base + objects multiple times. ++ +Default is 16 MiB on all platforms. This should be reasonable +for all users/operating systems, except on the largest projects. +You probably do not need to adjust this value. ++ +Common unit suffixes of 'k', 'm', or 'g' are supported. + alias.*:: Command aliases for the gitlink:git[1] command wrapper - e.g. after defining "alias.last = cat-file commit HEAD", the invocation @@ -264,6 +285,10 @@ branch.<name>.merge:: `git fetch`) to lookup the default branch for merging. Without this option, `git pull` defaults to merge the first refspec fetched. Specify multiple values to get an octopus merge. + If you wish to setup `git pull` so that it merges into <name> from + another branch in the local repository, you can point + branch.<name>.merge to the desired branch, and use the special setting + `.` (a period) for branch.<name>.remote. color.branch:: A boolean to enable/disable color in the output of @@ -445,6 +470,11 @@ merge.summary:: Whether to include summaries of merged commits in newly created merge commit messages. False by default. +merge.tool:: + Controls which merge resolution program is used by + gitlink:git-mergetool[l]. Valid values are: "kdiff3", "tkdiff", + "meld", "xxdiff", "emerge", "vimdiff" + merge.verbosity:: Controls the amount of output shown by the recursive merge strategy. Level 0 outputs nothing except a final error @@ -475,6 +505,10 @@ remote.<name>.push:: The default set of "refspec" for gitlink:git-push[1]. See gitlink:git-push[1]. +remote.<name>.skipDefaultUpdate:: + If true, this remote will be skipped by default when updating + using the remote subcommand of gitlink:git-remote[1]. + remote.<name>.receivepack:: The default program to execute on the remote side when pushing. See option \--exec of gitlink:git-push[1]. @@ -483,6 +517,14 @@ remote.<name>.uploadpack:: The default program to execute on the remote side when fetching. See option \--exec of gitlink:git-fetch-pack[1]. +remote.<name>.tagopt:: + Setting this value to --no-tags disables automatic tag following when fetching + from remote <name> + +remotes.<group>:: + The list of remotes which are fetched by "git remote update + <group>". See gitlink:git-remote[1]. + repack.usedeltabaseoffset:: Allow gitlink:git-repack[1] to create packs that uses delta-base offset. Defaults to false. diff --git a/Documentation/core-intro.txt b/Documentation/core-intro.txt index 6bee448e7d..eea44d9d56 100644 --- a/Documentation/core-intro.txt +++ b/Documentation/core-intro.txt @@ -588,4 +588,5 @@ stages to temporary files and calls a "merge" script on it: git-merge-index git-merge-one-file hello.c -and that is what higher level `git resolve` is implemented with. +and that is what higher level `git merge -s resolve` is implemented +with. diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt index 9c28bea62e..97cdb90cb4 100644 --- a/Documentation/core-tutorial.txt +++ b/Documentation/core-tutorial.txt @@ -977,7 +977,7 @@ see more complex cases. Now, let's pretend you are the one who did all the work in `mybranch`, and the fruit of your hard work has finally been merged to the `master` branch. Let's go back to `mybranch`, and run -resolve to get the "upstream changes" back to your branch. +`git merge` to get the "upstream changes" back to your branch. ------------ $ git checkout mybranch @@ -996,7 +996,7 @@ Fast forward ---------------- Because your branch did not contain anything more than what are -already merged into the `master` branch, the resolve operation did +already merged into the `master` branch, the merge operation did not actually do a merge. Instead, it just updated the top of the tree of your branch to that of the `master` branch. This is often called 'fast forward' merge. @@ -1099,11 +1099,11 @@ programs, which are 'commit walkers'; they outlived their usefulness when git Native and SSH transports were introduced, and not used by `git pull` or `git push` scripts. -Once you fetch from the remote repository, you `resolve` that +Once you fetch from the remote repository, you `merge` that with your current branch. However -- it's such a common thing to `fetch` and then -immediately `resolve`, that it's called `git pull`, and you can +immediately `merge`, that it's called `git pull`, and you can simply do ---------------- diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 019a39f2bf..77a3f78dd7 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -140,6 +140,9 @@ -a:: Shorthand for "--text". +--ignore-space-at-eol:: + Ignore changes in white spaces at EOL. + --ignore-space-change:: Ignore changes in amount of white space. This ignores white space at line end, and consider all other sequences of one or @@ -156,5 +159,10 @@ -w:: Shorthand for "--ignore-all-space". +--exit-code:: + Make the program exit with codes similar to diff(1). + That is, it exits with 1 if there were differences and + 0 means no differences. + For more detailed explanation on these common options, see also link:diffcore.html[diffcore documentation]. diff --git a/Documentation/diffcore.txt b/Documentation/diffcore.txt index cb4e562004..34cd306bb1 100644 --- a/Documentation/diffcore.txt +++ b/Documentation/diffcore.txt @@ -6,8 +6,8 @@ June 2005 Introduction ------------ -The diff commands git-diff-index, git-diff-files, git-diff-tree, and -git-diff-stages can be told to manipulate differences they find in +The diff commands git-diff-index, git-diff-files, and git-diff-tree +can be told to manipulate differences they find in unconventional ways before showing diff(1) output. The manipulation is collectively called "diffcore transformation". This short note describes what they are and how to use them to produce diff outputs @@ -30,9 +30,6 @@ files: - git-diff-tree compares contents of two "tree" objects; - - git-diff-stages compares contents of blobs at two stages in an - unmerged index file. - In all of these cases, the commands themselves compare corresponding paths in the two sets of files. The result of comparison is passed from these commands to what is internally diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt index 5a13187a87..82cb41d279 100644 --- a/Documentation/git-archimport.txt +++ b/Documentation/git-archimport.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git-archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir] - <archive/branch> [ <archive/branch> ] + <archive/branch>[:<git-branch>] ... DESCRIPTION ----------- @@ -39,6 +39,19 @@ directory. To follow the development of a project that uses Arch, rerun `git-archimport` with the same parameters as the initial import to perform incremental imports. +While git-archimport will try to create sensible branch names for the +archives that it imports, it is also possible to specify git branch names +manually. To do so, write a git branch name after each <archive/branch> +parameter, separated by a colon. This way, you can shorten the Arch +branch names and convert Arch jargon to git jargon, for example mapping a +"PROJECT--devo--VERSION" branch to "master". + +Associating multiple Arch branches to one git branch is possible; the +result will make the most sense only if no commits are made to the first +branch, after the second branch is created. Still, this is useful to +convert Arch repositories that had been rotated periodically. + + MERGES ------ Patch merge data from Arch is used to mark merges in git as well. git @@ -73,7 +86,9 @@ OPTIONS Use this for compatibility with old-style branch names used by earlier versions of git-archimport. Old-style branch names were category--branch, whereas new-style branch names are - archive,category--branch--version. + archive,category--branch--version. In both cases, names given + on the command-line will override the automatically-generated + ones. -D <depth>:: Follow merge ancestry and attempt to import trees that have been diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index aa1fdd402a..603f87f3b5 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -8,8 +8,9 @@ git-branch - List, create, or delete branches SYNOPSIS -------- [verse] -'git-branch' [--color | --no-color] [-r | -a] [-v [--abbrev=<length>]] -'git-branch' [-l] [-f] <branchname> [<start-point>] +'git-branch' [--color | --no-color] [-r | -a] + [-v [--abbrev=<length> | --no-abbrev]] +'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>] 'git-branch' (-m | -M) [<oldbranch>] <newbranch> 'git-branch' (-d | -D) [-r] <branchname>... @@ -25,6 +26,13 @@ It will start out with a head equal to the one given as <start-point>. If no <start-point> is given, the branch will be created with a head equal to that of the currently checked out branch. +When a local branch is started off a remote branch, git can setup the +branch so that gitlink:git-pull[1] will appropriately merge from that +remote branch. If this behavior is desired, it is possible to make it +the default using the global `branch.autosetupmerge` configuration +flag. Otherwise, it can be chosen per-branch using the `--track` +and `--no-track` options. + With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>. If <oldbranch> had a corresponding reflog, it is renamed to match <newbranch>, and a reflog entry is created to remember the branch @@ -80,6 +88,9 @@ OPTIONS Alter minimum display length for sha1 in output listing, default value is 7. +--no-abbrev:: + Display the full sha1s in output listing rather than abbreviating them. + <branchname>:: The name of the branch to create or delete. The new branch name must pass all checks defined by diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt new file mode 100644 index 0000000000..92e7a68722 --- /dev/null +++ b/Documentation/git-bundle.txt @@ -0,0 +1,139 @@ +git-bundle(1) +============= + +NAME +---- +git-bundle - Move objects and refs by archive + + +SYNOPSIS +-------- +'git-bundle' create <file> [git-rev-list args] +'git-bundle' verify <file> +'git-bundle' list-heads <file> [refname...] +'git-bundle' unbundle <file> [refname...] + +DESCRIPTION +----------- + +Some workflows require that one or more branches of development on one +machine be replicated on another machine, but the two machines cannot +be directly connected so the interactive git protocols (git, ssh, +rsync, http) cannot be used. This command provides support for +git-fetch and git-pull to operate by packaging objects and references +in an archive at the originating machine, then importing those into +another repository using gitlink:git-fetch[1] and gitlink:git-pull[1] +after moving the archive by some means (i.e., by sneakernet). As no +direct connection between repositories exists, the user must specify a +basis for the bundle that is held by the destination repository: the +bundle assumes that all objects in the basis are already in the +destination repository. + +OPTIONS +------- + +create <file>:: + Used to create a bundle named 'file'. This requires the + git-rev-list arguments to define the bundle contents. + +verify <file>:: + Used to check that a bundle file is valid and will apply + cleanly to the current repository. This includes checks on the + bundle format itself as well as checking that the prerequisite + commits exist and are fully linked in the current repository. + git-bundle prints a list of missing commits, if any, and exits + with non-zero status. + +list-heads <file>:: + Lists the references defined in the bundle. If followed by a + list of references, only references matching those given are + printed out. + +unbundle <file>:: + Passes the objects in the bundle to gitlink:git-index-pack[1] + for storage in the repository, then prints the names of all + defined references. If a reflist is given, only references + matching those in the given list are printed. This command is + really plumbing, intended to be called only by + gitlink:git-fetch[1]. + +[git-rev-list-args...]:: + A list of arguments, acceptable to git-rev-parse and + git-rev-list, that specify the specific objects and references + to transport. For example, "master~10..master" causes the + current master reference to be packaged along with all objects + added since its 10th ancestor commit. There is no explicit + limit to the number of references and objects that may be + packaged. + + +[refname...]:: + A list of references used to limit the references reported as + available. This is principally of use to git-fetch, which + expects to receive only those references asked for and not + necessarily everything in the pack (in this case, git-bundle is + acting like gitlink:git-fetch-pack[1]). + +SPECIFYING REFERENCES +--------------------- + +git-bundle will only package references that are shown by +git-show-ref: this includes heads, tags, and remote heads. References +such as master~1 cannot be packaged, but are perfectly suitable for +defining the basis. More than one reference may be packaged, and more +than one basis can be specified. The objects packaged are those not +contained in the union of the given bases. Each basis can be +specified explicitly (e.g., ^master~10), or implicitly (e.g., +master~10..master, master --since=10.days.ago). + +It is very important that the basis used be held by the destination. +It is okay to err on the side of conservatism, causing the bundle file +to contain objects already in the destination as these are ignored +when unpacking at the destination. + +EXAMPLE +------- + +Assume two repositories exist as R1 on machine A, and R2 on machine B. +For whatever reason, direct connection between A and B is not allowed, +but we can move data from A to B via some mechanism (CD, email, etc). +We want to update R2 with developments made on branch master in R1. +We set a tag in R1 (lastR2bundle) after the previous such transport, +and move it afterwards to help build the bundle. + +in R1 on A: +$ git-bundle create mybundle master ^lastR2bundle +$ git tag -f lastR2bundle master + +(move mybundle from A to B by some mechanism) + +in R2 on B: +$ git-bundle verify mybundle +$ git-fetch mybundle refspec + +where refspec is refInBundle:localRef + + +Also, with something like this in your config: + +[remote "bundle"] + url = /home/me/tmp/file.bdl + fetch = refs/heads/*:refs/remotes/origin/* + +You can first sneakernet the bundle file to ~/tmp/file.bdl and +then these commands: + +$ git ls-remote bundle +$ git fetch bundle +$ git pull bundle + +would treat it as if it is talking with a remote side over the +network. + +Author +------ +Written by Mark Levedahl <mdl123@verizon.net> + +GIT +--- +Part of the gitlink:git[7] suite diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 1ae77be450..f5b2d5017b 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -8,7 +8,7 @@ git-checkout - Checkout and switch to a branch SYNOPSIS -------- [verse] -'git-checkout' [-q] [-f] [-b <new_branch> [-l]] [-m] [<branch>] +'git-checkout' [-q] [-f] [-b [--track | --no-track] <new_branch> [-l]] [-m] [<branch>] 'git-checkout' [<tree-ish>] <paths>... DESCRIPTION @@ -18,7 +18,8 @@ When <paths> are not given, this command switches branches by updating the index and working tree to reflect the specified branch, <branch>, and updating HEAD to be <branch> or, if specified, <new_branch>. Using -b will cause <new_branch> to -be created. +be created; in this case you can use the --track or --no-track +options, which will be passed to `git branch`. When <paths> are given, this command does *not* switch |