From: Junio C Hamano Date: Sun, 16 Mar 2008 08:03:16 +0000 (-0700) Subject: Merge branch 'maint' X-Git-Tag: v1.5.5-rc0~2 X-Git-Url: https://git.tokkee.org/?a=commitdiff_plain;h=1eaa541f5fbda3fc30085da4f75e99dfae4ec9b3;hp=81d66500c1e47d19c18d643ef074e0475dc90eb1;p=git.git Merge branch 'maint' * maint: Start draft ReleaseNotes for 1.5.4.5 rebase -m: do not trigger pre-commit verification Conflicts: RelNotes --- diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 000000000..6b9c715d2 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,2 @@ +* whitespace=!indent,trail,space +*.[ch] whitespace diff --git a/.gitignore b/.gitignore index 7f8421dcd..4ff2fec27 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ +GIT-BUILD-OPTIONS GIT-CFLAGS GIT-GUI-VARS GIT-VERSION-FILE @@ -50,7 +51,6 @@ git-gc git-get-tar-commit-id git-grep git-hash-object -git-help--browse git-http-fetch git-http-push git-imap-send @@ -136,6 +136,7 @@ git-upload-pack git-var git-verify-pack git-verify-tag +git-web--browse git-whatchanged git-write-tree git-core-*/?* diff --git a/.mailmap b/.mailmap index a32d9e2a3..f88ae77a1 100644 --- a/.mailmap +++ b/.mailmap @@ -17,6 +17,7 @@ H. Peter Anvin H. Peter Anvin H. Peter Anvin Horst H. von Brand +Jay Soffian Joachim Berdal Haga Jon Loeliger Jon Seymour diff --git a/Documentation/.gitattributes b/Documentation/.gitattributes new file mode 100644 index 000000000..ddb030137 --- /dev/null +++ b/Documentation/.gitattributes @@ -0,0 +1 @@ +*.txt whitespace diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 3b042db62..994eb9159 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -53,6 +53,18 @@ For shell scripts specifically (not exhaustive): - We do not write the noiseword "function" in front of shell functions. + - As to use of grep, stick to a subset of BRE (namely, no \{m,n\}, + [::], [==], nor [..]) for portability. + + - We do not use \{m,n\}; + + - We do not use -E; + + - We do not use ? nor + (which are \{0,1\} and \{1,\} + respectively in BRE) but that goes without saying as these + are ERE elements not BRE (note that \? and \+ are not even part + of BRE -- making them accessible from BRE is a GNU extension). + For C programs: - We use tabs to indent, and interpret tabs as taking up to diff --git a/Documentation/RelNotes-1.5.5.txt b/Documentation/RelNotes-1.5.5.txt new file mode 100644 index 000000000..874dad9a4 --- /dev/null +++ b/Documentation/RelNotes-1.5.5.txt @@ -0,0 +1,173 @@ +GIT v1.5.5 Release Notes +======================== + +Updates since v1.5.4 +-------------------- + +(subsystems) + + * Comes with git-gui 0.9.3 + +(performance) + + * On platforms with suboptimal qsort(3) implementation, there + is an option to use more reasonable substitute we ship with + our software. + + * New configuration variable "pack.packsizelimit" can be used + in place of command line option --max-pack-size. + + * "git fetch" over the native git protocol used to make a + connection to find out the set of current remote refs and + another to actually download the pack data. We now use only + one connection for these tasks. + + * "git commit" does not run lstat(2) more than necessary + anymore. + +(usability, bells and whistles) + + * You can be warned when core.autocrlf conversion is applied in + such a way that results in an irreversible conversion. + + * A catch-all "color.ui" configuration variable can be used to + enable coloring of all color-capable commands, instead of + individual ones such as "color.status" and "color.branch". + + * The commands refused to take absolute pathnames where they + require pathnames relative to the work tree or the current + subdirectory. They now can take absolute pathnames in such a + case as long as the pathnames do not refer outside of the + work tree. E.g. "git add $(pwd)/foo" now works. + + * Error messages used to be sent to stderr, only to get hidden, + when $PAGER was in use. They now are sent to stdout along + with the command output to be shown in the $PAGER. + + * A pattern "foo/" in .gitignore file now matches a directory + "foo". Pattern "foo" also matches as before. + + * bash completion's prompt helper function can talk about + operation in-progress (e.g. merge, rebase, etc.). + + * Configuration variables "url..insteadof = " can be + used to tell "git-fetch" and "git-push" to use different URL than what + is given from the command line. + + * "git push HEAD" and "git push +HEAD" works as + expected; they push the current branch (and only the current branch). + In addition, HEAD can be written as the value of "remote..push" + configuration variable. + + * "git add -i" behaves better even before you make an initial commit. + + * "git am" refused to run from a subdirectory without a good reason. + + * After "git apply --whitespace=fix" fixes whitespace errors in a patch, + a line before the fix can appear as a context or preimage line in a + later patch, causing the patch not to apply. The command now knows to + see through whitespace fixes done to context lines to successfully + apply such a patch series. + + * "git branch" (and "git checkout -b") to branch from a local branch can + optionally set "branch..merge" to mark the new branch to build on + the other local branch, when "branch.autosetupmerge" is set to + "always". By default, this does not happen when branching from a local + branch. + + * "git checkout" to switch to a branch that has "branch..merge" set + (i.e. marked to build on another branch) reports how much the branch + and the other branch diverged. + + * When "git checkout" has to update a lot of paths, it used to be silent + for 4 seconds before it showed any progress report. It is now a bit + more impatient and starts showing progress report early. + + * "git commit" learned a new hook "prepare-commit-msg" that can + inspect what is going to be committed and prepare the commit + log message template to be edited. + + * "git cvsimport" can now take more than one -M options. + + * "git describe" learned to limit the tags to be used for + naming with --match option. + + * "git describe --contains" now barfs when the named commit + cannot be described. + + * "git describe --exact-match" describes only commits that are tagged. + + * "git describe --long" describes a tagged commit as $tag-0-$sha1, + instead of just showing the exact tagname. + + * "git describe" warns when using a tag whose name and path contradict + with each other. + + * "git diff" learned "--relative" option to limit and output paths + relative to the current directory when working in a subdirectory. + + * "git diff" learned "--dirstat" option to show birds-eye-summary of + changes more concisely than "--diffstat". + + * "git format-patch" learned --cover-letter option to generate a cover + letter template. + + * "git gc" learned --quiet option. + + * "git grep" now knows "--name-only" is a synonym for the "-l" option. + + * "git help " now reports "'git ' is alias to ", + instead of saying "No manual entry for git-". + + * "git log --grep=" learned "--fixed-strings" option to look for + without treating it as a regular expression. + + * "git gui" learned an auto-spell checking. + + * "git send-email" learned to prompt for passwords + interactively. + + * "git send-email" learned an easier way to suppress CC + recipients. + + * When the configuration variable "pack.threads" is set to 0, "git + repack" auto detects the number of CPUs and uses that many threads. + + * Various "git cvsimport", "git cvsexportcommit", "git svn" and + "git p4" improvements. + +(internal) + + * Duplicated code between git-help and git-instaweb that + launches user's preferred browser has been refactored. + + * It is now easier to write test scripts that records known + breakages. + + * "git checkout" is rewritten in C. + + * Two conflict hunks that are separated by a very short span of common + lines are now coalesced into one larger hunk, to make the result easier + to read. + + * Run-command API's use of file descriptors is documented clearer and + is more consistent now. + + +Fixes since v1.5.4 +------------------ + +All of the fixes in v1.5.4 maintenance series are included in +this release, unless otherwise noted. + + * "git-http-push" did not allow deletion of remote ref with the usual + "push :" syntax. + + * "git-rebase --abort" did not go back to the right location if + "git-reset" was run during the "git-rebase" session. + +--- +exec >/var/tmp/1 +O=v1.5.4.3-428-g6b48990 +echo O=`git describe refs/heads/master` +git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index de08d094e..0e155c936 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -34,9 +34,9 @@ Checklist (and a short version for the impatient): - if your name is not writable in ASCII, make sure that you send off a message in the correct encoding. - send the patch to the list (git@vger.kernel.org) and the - maintainer (gitster@pobox.com). If you use - git-send-email(1), please test it first by sending - email to yourself. + maintainer (gitster@pobox.com) if (and only if) the patch + is ready for inclusion. If you use git-send-email(1), + please test it first by sending email to yourself. Long version: @@ -112,7 +112,12 @@ lose tabs that way if you are not careful. It is a common convention to prefix your subject line with [PATCH]. This lets people easily distinguish patches from other -e-mail discussions. +e-mail discussions. Use of additional markers after PATCH and +the closing bracket to mark the nature of the patch is also +encouraged. E.g. [PATCH/RFC] is often used when the patch is +not ready to be applied but it is for discussion, [PATCH v2], +[PATCH v3] etc. are often seen when you are sending an update to +what you have previously sent. "git format-patch" command follows the best current practice to format the body of an e-mail message. At the beginning of the @@ -157,7 +162,8 @@ Note that your maintainer does not necessarily read everything on the git mailing list. If your patch is for discussion first, send it "To:" the mailing list, and optionally "cc:" him. If it is trivially correct or after the list reached a consensus, send -it "To:" the maintainer and optionally "cc:" the list. +it "To:" the maintainer and optionally "cc:" the list for +inclusion. Also note that your maintainer does not actively involve himself in maintaining what are in contrib/ hierarchy. When you send fixes and @@ -210,10 +216,53 @@ then you just add a line saying This line can be automatically added by git if you run the git-commit command with the -s option. -Some people also put extra tags at the end. They'll just be ignored for -now, but you can do this to mark internal company procedures or just -point out some special detail about the sign-off. +Notice that you can place your own Signed-off-by: line when +forwarding somebody else's patch with the above rules for +D-C-O. Indeed you are encouraged to do so. Do not forget to +place an in-body "From: " line at the beginning to properly attribute +the change to its true author (see (2) above). +Some people also put extra tags at the end. + +"Acked-by:" says that the patch was reviewed by the person who +is more familiar with the issues and the area the patch attempts +to modify. "Tested-by:" says the patch was tested by the person +and found to have the desired effect. + +------------------------------------------------ +An ideal patch flow + +Here is an ideal patch flow for this project the current maintainer +suggests to the contributors: + + (0) You come up with an itch. You code it up. + + (1) Send it to the list and cc people who may need to know about + the change. + + The people who may need to know are the ones whose code you + are butchering. These people happen to be the ones who are + most likely to be knowledgeable enough to help you, but + they have no obligation to help you (i.e. you ask for help, + don't demand). "git log -p -- $area_you_are_modifying" would + help you find out who they are. + + (2) You get comments and suggestions for improvements. You may + even get them in a "on top of your change" patch form. + + (3) Polish, refine, and re-send to the list and the people who + spend their time to improve your patch. Go back to step (2). + + (4) The list forms consensus that the last round of your patch is + good. Send it to the list and cc the maintainer. + + (5) A topic branch is created with the patch and is merged to 'next', + and cooked further and eventually graduates to 'master'. + +In any time between the (2)-(3) cycle, the maintainer may pick it up +from the list and queue it to 'pu', in order to make it easier for +people play with it without having to pick up and apply the patch to +their trees themselves. ------------------------------------------------ MUA specific hints diff --git a/Documentation/config.txt b/Documentation/config.txt index 531ec46e9..0865f4e01 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -139,6 +139,51 @@ core.autocrlf:: "text" (i.e. be subjected to the autocrlf mechanism) is decided purely based on the contents. +core.safecrlf:: + If true, makes git check if converting `CRLF` as controlled by + `core.autocrlf` is reversible. Git will verify if a command + modifies a file in the work tree either directly or indirectly. + For example, committing a file followed by checking out the + same file should yield the original file in the work tree. If + this is not the case for the current setting of + `core.autocrlf`, git will reject the file. The variable can + be set to "warn", in which case git will only warn about an + irreversible conversion but continue the operation. ++ +CRLF conversion bears a slight chance of corrupting data. +autocrlf=true will convert CRLF to LF during commit and LF to +CRLF during checkout. A file that contains a mixture of LF and +CRLF before the commit cannot be recreated by git. For text +files this is the right thing to do: it corrects line endings +such that we have only LF line endings in the repository. +But for binary files that are accidentally classified as text the +conversion can corrupt data. ++ +If you recognize such corruption early you can easily fix it by +setting the conversion type explicitly in .gitattributes. Right +after committing you still have the original file in your work +tree and this file is not yet corrupted. You can explicitly tell +git that this file is binary and git will handle the file +appropriately. ++ +Unfortunately, the desired effect of cleaning up text files with +mixed line endings and the undesired effect of corrupting binary +files cannot be distinguished. In both cases CRLFs are removed +in an irreversible way. For text files this is the right thing +to do because CRLFs are line endings, while for binary files +converting CRLFs corrupts data. ++ +Note, this safety check does not mean that a checkout will generate a +file identical to the original file for a different setting of +`core.autocrlf`, but only for the current one. For example, a text +file with `LF` would be accepted with `core.autocrlf=input` and could +later be checked out with `core.autocrlf=true`, in which case the +resulting file would contain `CRLF`, although the original file +contained `LF`. However, in both work trees the line endings would be +consistent, that is either all `LF` or all `CRLF`, but never mixed. A +file with mixed line endings would be reported by the `core.safecrlf` +mechanism. + core.symlinks:: If false, symbolic links are checked out as small plain files that contain the link text. linkgit:git-update-index[1] and @@ -308,6 +353,10 @@ 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). +* `cr-at-eol` treats a carriage-return at the end of line as + part of the line terminator, i.e. with it, `trailing-space` + does not trigger if the character before such a carriage-return + is not a whitespace (not enabled by default). alias.*:: Command aliases for the linkgit:git[1] command wrapper - e.g. @@ -330,10 +379,14 @@ apply.whitespace:: branch.autosetupmerge:: Tells `git-branch` and `git-checkout` to setup new branches - so that linkgit:git-pull[1] will appropriately merge from that - remote branch. Note that even if this option is not set, + so that linkgit:git-pull[1] will appropriately merge from the + starting point branch. Note that even if this option is not set, this behavior can be chosen per-branch using the `--track` - and `--no-track` options. This option defaults to true. + and `--no-track` options. The valid settings are: `false` -- no + automatic setup is done; `true` -- automatic setup is done when the + starting point is a remote branch; `always` -- automatic setup is + done when the starting point is either a local branch or remote + branch. This option defaults to true. branch..remote:: When in branch , it tells `git fetch` which remote to fetch. @@ -367,6 +420,11 @@ branch..rebase:: it unless you understand the implications (see linkgit:git-rebase[1] for details). +browser..cmd:: + Specify the command to invoke the specified browser. The + specified command is evaluated in shell with the URLs passed + as arguments. (See linkgit:git-web--browse[1].) + browser..path:: Override the path for the given tool that may be used to browse HTML help (see '-w' option in linkgit:git-help[1]) or a @@ -444,6 +502,13 @@ color.status.:: commit.template:: Specify a file to use as the template for new commit messages. +color.ui:: + When set to `always`, always use colors in all git commands which + are capable of colored output. When false (or `never`), never. When + set to `true` or `auto`, use colors only when the output is to the + terminal. When more specific variables of color.* are set, they always + take precedence over this setting. Defaults to false. + diff.autorefreshindex:: When using `git diff` to compare with work tree files, do not consider stat-only change as changed. @@ -496,6 +561,11 @@ format.suffix:: `.patch`. Use this variable to change that suffix (make sure to include the dot if you want it). +format.pretty:: + The default pretty format for log/show/whatchanged command, + See linkgit:git-log[1], linkgit:git-show[1], + linkgit:git-whatchanged[1]. + gc.aggressiveWindow:: The window size parameter used in the delta compression algorithm used by 'git gc --aggressive'. This defaults @@ -525,6 +595,10 @@ gc.packrefs:: at some stage, and setting this to `false` will continue to prevent `git pack-refs` from being run from `git gc`. +gc.pruneexpire:: + When `git gc` is run, it will call `prune --expire 2.weeks.ago`. + Override the grace period with this config variable. + gc.reflogexpire:: `git reflog expire` removes reflog entries older than this time; defaults to 90 days. @@ -683,14 +757,20 @@ log.showroot:: Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which normally hide the root commit will now show it. True by default. +man.viewer:: + Specify the programs that may be used to display help in the + 'man' format. See linkgit:git-help[1]. + 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 - linkgit:git-mergetool[1]. Valid values are: "kdiff3", "tkdiff", - "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and "opendiff". + linkgit:git-mergetool[1]. Valid built-in values are: "kdiff3", + "tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and + "opendiff". Any other value is treated is custom merge tool + and there must be a corresponing mergetool..cmd option. merge.verbosity:: Controls the amount of output shown by the recursive merge @@ -717,6 +797,31 @@ mergetool..path:: Override the path for the given tool. This is useful in case your tool is not in the PATH. +mergetool..cmd:: + Specify the command to invoke the specified merge tool. The + specified command is evaluated in shell with the following + variables available: 'BASE' is the name of a temporary file + containing the common base of the files to be merged, if available; + 'LOCAL' is the name of a temporary file containing the contents of + the file on the current branch; 'REMOTE' is the name of a temporary + file containing the contents of the file from the branch being + merged; 'MERGED' contains the name of the file to which the merge + tool should write the results of a successful merge. + +mergetool..trustExitCode:: + For a custom merge command, specify whether the exit code of + the merge command can be used to determine whether the merge was + successful. If this is not set to true then the merge target file + timestamp is checked and the merge assumed to have been successful + if the file has been updated, otherwise the user is prompted to + indicate the success of the merge. + +mergetool.keepBackup:: + After performing a merge, the original file with conflict markers + can be saved as a file with a `.orig` extension. If this variable + is set to `false` then this file is not preserved. Defaults to + `true` (i.e. keep the backup files). + pack.window:: The size of the window used by linkgit:git-pack-objects[1] when no window size is given on the command line. Defaults to 10. @@ -756,6 +861,8 @@ pack.threads:: warning. This is meant to reduce packing time on multiprocessor machines. The required amount of memory for the delta search window is however multiplied by the number of threads. + Specifying 0 will cause git to auto-detect the number of CPU's + and set the number of threads accordingly. pack.indexVersion:: Specify the default pack index version. Valid values are 1 for @@ -766,6 +873,12 @@ pack.indexVersion:: whenever the corresponding pack is larger than 2 GB. Otherwise the default is 1. +pack.packSizeLimit:: + The default maximum size of a pack. This setting only affects + packing to a file, i.e. the git:// protocol is unaffected. It + can be overridden by the `\--max-pack-size` option of + linkgit:git-repack[1]. + pull.octopus:: The default merge strategy to use when pulling multiple branches at once. @@ -835,6 +948,17 @@ tar.umask:: archiving user's umask will be used instead. See umask(2) and linkgit:git-archive[1]. +url..insteadOf:: + Any URL that starts with this value will be rewritten to + start, instead, with . In cases where some site serves a + large number of repositories, and serves them with multiple + access methods, and some users need to use different access + methods, this feature allows people to specify any of the + equivalent URLs and have git automatically rewrite the URL to + the best alternative for the particular user, even for a + never-before-seen repository on the site. When more than one + insteadOf strings match a given URL, the longest match is used. + user.email:: Your email address to be recorded in any newly created commits. Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 8d35cbd60..8dc5b001c 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -170,6 +170,14 @@ endif::git-format-patch[] Swap two inputs; that is, show differences from index or on-disk file to tree contents. +--relative[=]:: + When run from a subdirectory of the project, it can be + told to exclude changes outside the directory and show + pathnames relative to it with this option. When you are + not in a subdirectory (e.g. in a bare repository), you + can name which subdirectory to make the output relative + to by giving a as an argument. + --text:: Treat all files as text. diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index e640fc75c..2387a8d6c 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -9,7 +9,7 @@ git-am - Apply a series of patches from a mailbox SYNOPSIS -------- [verse] -'git-am' [--signoff] [--dotest=] [--keep] [--utf8 | --no-utf8] +'git-am' [--signoff] [--keep] [--utf8 | --no-utf8] [--3way] [--interactive] [--binary] [--whitespace=