diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/RelNotes/1.8.3.3.txt | 15 | ||||
| -rw-r--r-- | Documentation/RelNotes/1.8.4.txt | 79 | ||||
| -rw-r--r-- | Documentation/config.txt | 88 | ||||
| -rw-r--r-- | Documentation/git-clone.txt | 12 | ||||
| -rw-r--r-- | Documentation/git-config.txt | 22 | ||||
| -rw-r--r-- | Documentation/git-p4.txt | 17 | ||||
| -rw-r--r-- | Documentation/git-pull.txt | 2 | ||||
| -rw-r--r-- | Documentation/git-stash.txt | 12 | ||||
| -rw-r--r-- | Documentation/git-submodule.txt | 2 | ||||
| -rw-r--r-- | Documentation/glossary-content.txt | 4 |
10 files changed, 193 insertions, 60 deletions
diff --git a/Documentation/RelNotes/1.8.3.3.txt b/Documentation/RelNotes/1.8.3.3.txt index 58a570ef3d..04289e793c 100644 --- a/Documentation/RelNotes/1.8.3.3.txt +++ b/Documentation/RelNotes/1.8.3.3.txt @@ -4,8 +4,23 @@ Git v1.8.3.3 Release Notes Fixes since v1.8.3.2 -------------------- + * "gitweb" forgot to clear a global variable $search_regexp upon each + request, mistakenly carrying over the previous search to a new one + when used as a persistent CGI. + + * The wildmatch engine did not honor WM_CASEFOLD option correctly. + + * "git log -c --follow $path" segfaulted upon hitting the commit that + renamed the $path being followed. + + * When a reflog notation is used for implicit "current branch", + e.g. "git log @{u}", we did not say which branch and worse said + "branch ''" in the error messages. + * Mac OS X does not like to write(2) more than INT_MAX number of bytes; work it around by chopping write(2) into smaller pieces. * Newer MacOS X encourages the programs to compile and link with their CommonCrypto, not with OpenSSL. + +Also contains various minor documentation updates. diff --git a/Documentation/RelNotes/1.8.4.txt b/Documentation/RelNotes/1.8.4.txt index b85f16b378..0e50df8064 100644 --- a/Documentation/RelNotes/1.8.4.txt +++ b/Documentation/RelNotes/1.8.4.txt @@ -1,11 +1,55 @@ Git v1.8.4 Release Notes ======================== +Backward compatibility notes (for Git 2.0) +------------------------------------------ + +When "git push [$there]" does not say what to push, we have used the +traditional "matching" semantics so far (all your branches were sent +to the remote as long as there already are branches of the same name +over there). In Git 2.0, the default will change to the "simple" +semantics that pushes: + + - only the current branch to the branch with the same name, and only + when the current branch is set to integrate with that remote + branch, if you are pushing to the same remote as you fetch from; or + + - only the current branch to the branch with the same name, if you + are pushing to a remote that is not where you usually fetch from. + +Use the user preference configuration variable "push.default" to +change this. If you are an old-timer who is used to the "matching" +semantics, you can set the variable to "matching" to keep the +traditional behaviour. If you want to live in the future early, you +can set it to "simple" today without waiting for Git 2.0. + +When "git add -u" (and "git add -A") is run inside a subdirectory and +does not specify which paths to add on the command line, it +will operate on the entire tree in Git 2.0 for consistency +with "git commit -a" and other commands. There will be no +mechanism to make plain "git add -u" behave like "git add -u .". +Current users of "git add -u" (without a pathspec) should start +training their fingers to explicitly say "git add -u ." +before Git 2.0 comes. A warning is issued when these commands are +run without a pathspec and when you have local changes outside the +current directory, because the behaviour in Git 2.0 will be different +from today's version in such a situation. + +In Git 2.0, "git add <path>" will behave as "git add -A <path>", so +that "git add dir/" will notice paths you removed from the directory +and record the removal. Versions before Git 2.0, including this +release, will keep ignoring removals, but the users who rely on this +behaviour are encouraged to start using "git add --ignore-removal <path>" +now before 2.0 is released. + + Updates since v1.8.3 -------------------- Foreign interfaces, subsystems and ports. + * "git rebase -i" now honors --strategy and -X options. + * Git-gui has been updated to its 0.18.0 version. * MediaWiki remote helper (in contrib/) has been updated to use the @@ -35,6 +79,11 @@ Foreign interfaces, subsystems and ports. UI, Workflows & Features + * The "push.default=simple" mode of "git push" has been updated to + behave like "current" without requiring a remote tracking + information, when you push to a remote that is different from where + you fetch from (i.e. a triangular workflow). + * Having multiple "fixup!" on a line in the rebase instruction sheet did not work very well with "git rebase -i --autosquash". @@ -63,9 +112,9 @@ UI, Workflows & Features * On Cygwin, "cygstart" is now recognised as a possible way to start a web browser (used in "help -w" and "instaweb" among others). -### * "git status" learned status.branch and status.short configuration -### variables to use --branch and --short options by default (override -### with --no-branch and --no-short options from the command line). + * "git status" learned status.branch and status.short configuration + variables to use --branch and --short options by default (override + with --no-branch and --no-short options from the command line). * "git cmd <name>", when <name> happens to be a 40-hex string, directly uses the 40-hex string as an object name, even if a ref @@ -188,6 +237,30 @@ Unless otherwise noted, all the fixes since v1.8.3 in the maintenance track are contained in this release (see release notes to them for details). + * "git diff" refused to even show difference when core.safecrlf is + set to true (i.e. error out) and there are offending lines in the + working tree files. + (merge 5430bb2 jc/maint-diff-core-safecrlf later to maint). + + * A test that should have failed but didn't revealed a bug that needs + to be corrected. + (merge 94d75d1 jc/t1512-fix later to maint). + + * An overlong path to a .git directory may have overflown the + temporary path buffer used to create a name for lockfiles. + (merge 2fbd4f9 mh/maint-lockfile-overflow later to maint). + + * Invocations of "git checkout" used internally by "git rebase" were + counted as "checkout", and affected later "git checkout -" to the + the user to an unexpected place. + (merge 3bed291 rr/rebase-checkout-reflog later to maint). + + * "git stash save", when your local change turns a tracked file into + a directory, has to remove files in that directory in order to + revert your working tree to a pristine state. This will lose + untracked files in such a directory, and the command now requires + you to "--force" it. + * The configuration variable column.ui was poorly documented. (merge 5e62cc1 rr/column-doc later to maint). diff --git a/Documentation/config.txt b/Documentation/config.txt index b4d4887bd7..81856dd5a2 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1844,39 +1844,59 @@ pull.twohead:: The default merge strategy to use when pulling a single branch. push.default:: - Defines the action `git push` should take if no refspec is given - on the command line, no refspec is configured in the remote, and - no refspec is implied by any of the options given on the command - line. Possible values are: + Defines the action `git push` should take if no refspec is + explicitly given. Different values are well-suited for + specific workflows; for instance, in a purely central workflow + (i.e. the fetch source is equal to the push destination), + `upstream` is probably what you want. Possible values are: + -- -* `nothing` - do not push anything. -* `matching` - push all branches having the same name in both ends. - This is for those who prepare all the branches into a publishable - shape and then push them out with a single command. It is not - appropriate for pushing into a repository shared by multiple users, - since locally stalled branches will attempt a non-fast forward push - if other users updated the branch. - + - This is currently the default, but Git 2.0 will change the default - to `simple`. -* `upstream` - push the current branch to its upstream branch - (`tracking` is a deprecated synonym for this). - With this, `git push` will update the same remote ref as the one which - is merged by `git pull`, making `push` and `pull` symmetrical. - See "branch.<name>.merge" for how to configure the upstream branch. -* `simple` - like `upstream`, but refuses to push if the upstream - branch's name is different from the local one. This is the safest - option and is well-suited for beginners. It will become the default - in Git 2.0. -* `current` - push the current branch to a branch of the same name. --- + +* `nothing` - do not push anything (error out) unless a refspec is + explicitly given. This is primarily meant for people who want to + avoid mistakes by always being explicit. + +* `current` - push the current branch to update a branch with the same + name on the receiving end. Works in both central and non-central + workflows. + +* `upstream` - push the current branch back to the branch whose + changes are usually integrated into the current branch (which is + called `@{upstream}`). This mode only makes sense if you are + pushing to the same repository you would normally pull from + (i.e. central workflow). + +* `simple` - in centralized workflow, work like `upstream` with an + added safety to refuse to push if the upstream branch's name is + different from the local one. ++ +When pushing to a remote that is different from the remote you normally +pull from, work as `current`. This is the safest option and is suited +for beginners. + -The `simple`, `current` and `upstream` modes are for those who want to -push out a single branch after finishing work, even when the other -branches are not yet ready to be pushed out. If you are working with -other people to push into the same shared repository, you would want -to use one of these. +This mode will become the default in Git 2.0. + +* `matching` - push all branches having the same name on both ends. + This makes the repository you are pushing to remember the set of + branches that will be pushed out (e.g. if you always push 'maint' + and 'master' there and no other branches, the repository you push + to will have these two branches, and your local 'maint' and + 'master' will be pushed there). ++ +To use this mode effectively, you have to make sure _all_ the +branches you would push out are ready to be pushed out before +running 'git push', as the whole point of this mode is to allow you +to push all of the branches in one go. If you usually finish work +on only one branch and push out the result, while other branches are +unfinished, this mode is not for you. Also this mode is not +suitable for pushing into a shared central repository, as other +people may add new branches there, or update the tip of existing +branches outside your control. ++ +This is currently the default, but Git 2.0 will change the default +to `simple`. + +-- rebase.stat:: Whether to show a diffstat of what changed upstream since the last @@ -2092,6 +2112,14 @@ status.relativePaths:: relative to the repository root (this was the default for Git prior to v1.5.4). +status.short:: + Set to true to enable --short by default in linkgit:git-status[1]. + The option --no-short takes precedence over this variable. + +status.branch:: + Set to true to enable --branch by default in linkgit:git-status[1]. + The option --no-branch takes precedence over this variable. + status.showUntrackedFiles:: By default, linkgit:git-status[1] and linkgit:git-commit[1] show files which are not currently tracked by Git. Directories which diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index 450f158779..85769b884e 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -182,11 +182,13 @@ objects from the source repository into a pack in the cloned repository. --depth <depth>:: Create a 'shallow' clone with a history truncated to the specified number of revisions. A shallow repository has a - number of limitations (you cannot clone or fetch from - it, nor push from nor into it), but is adequate if you - are only interested in the recent history of a large project - with a long history, and would want to send in fixes - as patches. + number of limitations (you cannot clone or fetch from it, nor + push into it), but is adequate if you are only interested in + the recent history of a large project with a long history. ++ +Pushing from a shallow clone should be avoided if the git version on +the receiver end is older than v1.7.10, or any other git +implementation that does not perform connectivity check. --[no-]single-branch:: Clone only the history leading to the tip of a single branch, diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index 19a7be0856..99dc497b6f 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -82,7 +82,7 @@ OPTIONS --get:: Get the value for a given key (optionally filtered by a regex matching the value). Returns error code 1 if the key was not - found and error code 2 if multiple key values were found. + found and the last value if multiple key values were found. --get-all:: Like get, but does not fail if the number of values for the key @@ -206,12 +206,8 @@ FILES If not set explicitly with '--file', there are four files where 'git config' will search for configuration options: -$GIT_DIR/config:: - Repository specific configuration file. - -~/.gitconfig:: - User-specific configuration file. Also called "global" - configuration file. +$(prefix)/etc/gitconfig:: + System-wide configuration file. $XDG_CONFIG_HOME/git/config:: Second user-specific configuration file. If $XDG_CONFIG_HOME is not set @@ -221,8 +217,12 @@ $XDG_CONFIG_HOME/git/config:: you sometimes use older versions of Git, as support for this file was added fairly recently. -$(prefix)/etc/gitconfig:: - System-wide configuration file. +~/.gitconfig:: + User-specific configuration file. Also called "global" + configuration file. + +$GIT_DIR/config:: + Repository specific configuration file. If no further options are given, all reading options will read all of these files that are available. If the global or the system-wide configuration @@ -230,6 +230,10 @@ file are not available they will be ignored. If the repository configuration file is not available or readable, 'git config' will exit with a non-zero error code. However, in neither case will an error message be issued. +The files are read in the order given above, with last value found taking +precedence over values read earlier. When multiple values are taken then all +values of a key from all files will be used. + All writing options will per default write to the repository specific configuration file. Note that this also affects options like '--replace-all' and '--unset'. *'git config' will only ever change one file at a time*. diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt index c579fbc2b8..8cba16d67f 100644 --- a/Documentation/git-p4.txt +++ b/Documentation/git-p4.txt @@ -176,13 +176,16 @@ Sync options These options can be used in the initial 'clone' as well as in subsequent 'sync' operations. ---branch <branch>:: - Import changes into given branch. If the branch starts with - 'refs/', it will be used as is. Otherwise if it does not start - with 'p4/', that prefix is added. The branch is assumed to - name a remote tracking, but this can be modified using - '--import-local', or by giving a full ref name. The default - branch is 'master'. +--branch <ref>:: + Import changes into <ref> instead of refs/remotes/p4/master. + If <ref> starts with refs/, it is used as is. Otherwise, if + it does not start with p4/, that prefix is added. ++ +By default a <ref> not starting with refs/ is treated as the +name of a remote-tracking branch (under refs/remotes/). This +behavior can be modified using the --import-local option. ++ +The default <ref> is "master". + This example imports a new remote "p4/proj2" into an existing Git repository: diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index 24ab07a3f8..6ef8d599d3 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -3,7 +3,7 @@ git-pull(1) NAME ---- -git-pull - Fetch from and merge with another repository or a local branch +git-pull - Fetch from and integrate with another repository or a local branch SYNOPSIS diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index db7e803038..7c8b648fbe 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git-stash.txt @@ -14,7 +14,8 @@ SYNOPSIS 'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>] 'git stash' branch <branchname> [<stash>] 'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] - [-u|--include-untracked] [-a|--all] [<message>]] + [-u|--include-untracked] [-a|--all] [-f|--force] + [<message>]] 'git stash' clear 'git stash' create [<message>] 'git stash' store [-m|--message <message>] [-q|--quiet] <commit> @@ -44,7 +45,7 @@ is also possible). OPTIONS ------- -save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]:: +save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [-f|--force] [<message>]:: Save your local modifications to a new 'stash', and run `git reset --hard` to revert them. The <message> part is optional and gives @@ -71,6 +72,13 @@ linkgit:git-add[1] to learn how to operate the `--patch` mode. + The `--patch` option implies `--keep-index`. You can use `--no-keep-index` to override this. ++ +In some cases, saving a stash could mean irretrievably removing some +data - if a directory with untracked files replaces a tracked file of +the same name, the new untracked files are not saved (except in case +of `--include-untracked`) but the original tracked file shall be restored. +By default, `stash save` will abort in such a case; `--force` will allow +it to remove the untracked files. list [<options>]:: diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index e5767134b1..bfff09062d 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -262,7 +262,7 @@ OPTIONS --remote:: This option is only valid for the update command. Instead of using the superproject's recorded SHA-1 to update the submodule, use the - status of the submodule's remote tracking branch. The remote used + status of the submodule's remote-tracking branch. The remote used is branch's remote (`branch.<name>.remote`), defaulting to `origin`. The remote branch used defaults to `master`, but the branch name may be overridden by setting the `submodule.<name>.branch` option in diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index db2a74df93..dba5062b37 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -113,7 +113,7 @@ Note that commands that operate on the history of the current branch while the HEAD is detached. They update the HEAD to point at the tip of the updated history without affecting any branch. Commands that update or inquire information _about_ the current branch (e.g. `git -branch --set-upstream-to` that sets what remote tracking branch the +branch --set-upstream-to` that sets what remote-tracking branch the current branch integrates with) obviously do not work, as there is no (real) current branch to ask about in this state. @@ -267,7 +267,7 @@ This commit is referred to as a "merge commit", or sometimes just a The default upstream <<def_repository,repository>>. Most projects have at least one upstream project which they track. By default 'origin' is used for that purpose. New upstream updates - will be fetched into remote <<def_remote_tracking_branch,remote-tracking branches>> named + will be fetched into <<def_remote_tracking_branch,remote-tracking branches>> named origin/name-of-upstream-branch, which you can see using `git branch -r`. |