diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/RelNotes-1.5.6.4.txt | 43 | ||||
| -rw-r--r-- | Documentation/RelNotes-1.6.0.txt | 18 | ||||
| -rw-r--r-- | Documentation/SubmittingPatches | 2 | ||||
| -rw-r--r-- | Documentation/git-add.txt | 5 | ||||
| -rw-r--r-- | Documentation/git-am.txt | 10 | ||||
| -rw-r--r-- | Documentation/git-branch.txt | 27 | ||||
| -rw-r--r-- | Documentation/git-cherry-pick.txt | 10 | ||||
| -rw-r--r-- | Documentation/git-merge.txt | 4 | ||||
| -rw-r--r-- | Documentation/git-rebase.txt | 5 | ||||
| -rw-r--r-- | Documentation/git-revert.txt | 16 | ||||
| -rw-r--r-- | Documentation/git-submodule.txt | 36 | ||||
| -rw-r--r-- | Documentation/gittutorial.txt | 54 | ||||
| -rw-r--r-- | Documentation/pretty-formats.txt | 2 | ||||
| -rw-r--r-- | Documentation/user-manual.txt | 2 |
14 files changed, 176 insertions, 58 deletions
diff --git a/Documentation/RelNotes-1.5.6.4.txt b/Documentation/RelNotes-1.5.6.4.txt new file mode 100644 index 0000000000..130418864e --- /dev/null +++ b/Documentation/RelNotes-1.5.6.4.txt @@ -0,0 +1,43 @@ +GIT v1.5.6.4 Release Notes +========================== + +Fixes since v1.5.6.3 +-------------------- + +* Various commands could overflow its internal buffer on a platform + with small PATH_MAX value in a repository that has contents with + long pathnames. + +* There wasn't a way to make --pretty=format:%<> specifiers to honor + .mailmap name rewriting for authors and committers. Now you can with + %aN and %cN. + +* Bash completion wasted too many cycles; this has been optimized to be + usable again. + +* Bash completion lost ref part when completing something like "git show + pu:Makefile". + +* "git-cvsserver" did not clean up its temporary working area after annotate + request. + +* "git-daemon" called syslog() from its signal handler, which was a + no-no. + +* "git-fetch" into an empty repository used to remind that the fetch will + be huge by saying "no common commits", but this was an unnecessary + noise; it is already known by the user anyway. + +* "git-mailinfo" (hence "git-am") did not correctly handle in-body [PATCH] + line to override the commit title taken from the mail Subject header. + +* "git-rebase -i -p" lost parents that are not involved in the history + being rewritten. + +Contains other various documentation fixes. + +-- +exec >/var/tmp/1 +echo O=$(git describe maint) +O=v1.5.6.3-21-gebcce31 +git shortlog --no-merges $O..maint diff --git a/Documentation/RelNotes-1.6.0.txt b/Documentation/RelNotes-1.6.0.txt index 9125ee01a6..89ea1e9385 100644 --- a/Documentation/RelNotes-1.6.0.txt +++ b/Documentation/RelNotes-1.6.0.txt @@ -110,6 +110,9 @@ Updates since v1.5.6 * "git-add -i" has a new action 'e/dit' to allow you edit the patch hunk manually. +* git-am records the original tip of the branch in ORIG_HEAD before it + starts applying patches. + * git-apply can handle a patch that touches the same path more than once much better than before. @@ -126,6 +129,14 @@ Updates since v1.5.6 similar to the way git-checkout reports by how many commits your branch is ahead/behind. +* git-branch's --contains option used to always require a commit parameter + to limit the branches with; it now defaults to list branches that + contains HEAD if this parameter is omitted. + +* git-branch's --merged and --no-merged option used to always limit the + branches relative to the HEAD, but they can now take an optional commit + argument that is used in place of HEAD. + * git-bundle can read the revision arguments from the standard input. * git-cherry-pick can replay a root commit now. @@ -144,6 +155,9 @@ Updates since v1.5.6 * fast-export learned to export and import marks file; this can be used to interface with fast-import incrementally. +* git-rebase records the original tip of branch in ORIG_HEAD before it is + rewound. + * "git rerere" can be told to update the index with auto-reused resolution with rerere.autoupdate configuration variable. @@ -152,6 +166,8 @@ Updates since v1.5.6 * git-send-mail can talk not just over SSL but over TLS now. +* git-shortlog honors custom output format specified with "--pretty=format:". + * "git-stash save" learned --keep-index option. This lets you stash away the local changes and bring the changes staged in the index to your working tree for examination and testing. @@ -185,6 +201,6 @@ this release, unless otherwise noted. --- exec >/var/tmp/1 -O=v1.5.6.3-315-g10ce020 +O=v1.5.6.3-350-g499027b 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 b1164753e1..fdfa536441 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -301,7 +301,7 @@ If it does not apply correctly, there can be various reasons. patch appropriately. * Your MUA corrupted your patch; "am" would complain that - the patch does not apply. Look at .dotest/ subdirectory and + the patch does not apply. Look at .git/rebase/ subdirectory and see what 'patch' file contains and check for the common corruption patterns mentioned above. diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 46dd56c12a..3558905a92 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -187,8 +187,9 @@ update:: "Update>>". When the prompt ends with double '>>', you can make more than one selection, concatenated with whitespace or comma. Also you can say ranges. E.g. "2-5 7,9" to choose - 2,3,4,5,7,9 from the list. You can say '*' to choose - everything. + 2,3,4,5,7,9 from the list. If the second number in a range is + omitted, all remaining patches are taken. E.g. "7-" to choose + 7,8,9 from the list. You can say '*' to choose everything. + What you chose are then highlighted with '*', like this: diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt index eeb23b25b0..2d7f162594 100644 --- a/Documentation/git-am.txt +++ b/Documentation/git-am.txt @@ -140,11 +140,17 @@ aborts in the middle,. You can recover from this in one of two ways: the index file to bring it in a state that the patch should have produced. Then run the command with '--resolved' option. -The command refuses to process new mailboxes while `.dotest` +The command refuses to process new mailboxes while `.git/rebase` directory exists, so if you decide to start over from scratch, -run `rm -f -r .dotest` before running the command with mailbox +run `rm -f -r .git/rebase` before running the command with mailbox names. +Before any patches are applied, ORIG_HEAD is set to the tip of the +current branch. This is useful if you have problems with multiple +commits, like running 'git am' on the wrong branch or an error in the +commits that is more easily fixed by changing the mailbox (e.g. +errors in the "From:" lines). + SEE ALSO -------- diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index b3e62ed011..fc5a4a602f 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -8,24 +8,27 @@ git-branch - List, create, or delete branches SYNOPSIS -------- [verse] -'git branch' [--color | --no-color] [-r | -a] [--merged | --no-merged] - [-v [--abbrev=<length> | --no-abbrev]] - [--contains <commit>] +'git branch' [--color | --no-color] [-r | -a] + [-v [--abbrev=<length> | --no-abbrev]] + [(--merged | --no-merged | --contains) [<commit>]] 'git branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>] 'git branch' (-m | -M) [<oldbranch>] <newbranch> 'git branch' (-d | -D) [-r] <branchname>... DESCRIPTION ----------- -With no arguments given a list of existing branches -will be shown, the current branch will be highlighted with an asterisk. -Option `-r` causes the remote-tracking branches to be listed, -and option `-a` shows both. -With `--contains <commit>`, shows only the branches that -contains the named commit (in other words, the branches whose -tip commits are descendant of the named commit). -With `--merged`, only branches merged into HEAD will be listed, and -with `--no-merged` only branches not merged into HEAD will be listed. + +With no arguments, existing branches are listed, the current branch will +be highlighted with an asterisk. Option `-r` causes the remote-tracking +branches to be listed, and option `-a` shows both. + +With `--contains`, shows only the branches that contains the named commit +(in other words, the branches whose tip commits are descendant of the +named commit). With `--merged`, only branches merged into the named +commit (i.e. the branches whose tip commits are reachable from the named +commit) will be listed. With `--no-merged` only branches not merged into +the named commit will be listed. Missing <commit> argument defaults to +'HEAD' (i.e. the tip of the current branch). In its second form, a new branch named <branchname> will be created. It will start out with a head equal to the one given as <start-point>. diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index a691173ba1..50fb3d5d54 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -58,14 +58,14 @@ OPTIONS Usually the command automatically creates a commit with a commit log message stating which commit was cherry-picked. This flag applies the change necessary - to cherry-pick the named commit to your working tree, - but does not make the commit. In addition, when this - option is used, your working tree does not have to match + to cherry-pick the named commit to your working tree + and the index, but does not make the 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 working tree. + beginning state of your index. + This is useful when cherry-picking more than one commits' -effect to your working tree in a row. +effect to your index in a row. -s:: --signoff:: diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 62f99b5f3b..019e4ca8f5 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -81,7 +81,9 @@ Otherwise, merge will refuse to do any harm to your repository (that is, it may fetch the objects from remote, and it may even update the local branch used to keep track of the remote branch with `git pull remote rbranch:lbranch`, but your working tree, -`.git/HEAD` pointer and index file are left intact). +`.git/HEAD` pointer and index file are left intact). In addition, +merge always sets `.git/ORIG_HEAD` to the original state of HEAD so +a problematic merge can be removed by using `git reset ORIG_HEAD`. You may have local modifications in the working tree files. In other words, 'git-diff' is allowed to report changes. diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index f3459c7de7..51afc87e17 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -26,7 +26,8 @@ of commits that would be shown by `git log <upstream>..HEAD`. The current branch is reset to <upstream>, or <newbase> if the --onto option was supplied. This has the exact same effect as -`git reset --hard <upstream>` (or <newbase>). +`git reset --hard <upstream>` (or <newbase>). ORIG_HEAD is set +to point at the tip of the branch before the reset. The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order. Note that @@ -38,7 +39,7 @@ It is possible that a merge failure will prevent this process from being completely automatic. You will have to resolve any such merge failure and run `git rebase --continue`. Another option is to bypass the commit that caused the merge failure with `git rebase --skip`. To restore the -original <branch> and remove the .dotest working files, use the command +original <branch> and remove the .git/rebase working files, use the command `git rebase --abort` instead. Assume the following history exists and the current branch is "topic": diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt index 5411edca96..271850f511 100644 --- a/Documentation/git-revert.txt +++ b/Documentation/git-revert.txt @@ -43,16 +43,16 @@ OPTIONS -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, but does not make the - commit. In addition, when this option is used, your - working tree does not have to match the HEAD commit. - The revert is done against the beginning state of your - working tree. + 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, + 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. + This is useful when reverting more than one commits' -effect to your working tree in a row. +effect to your index in a row. -s:: --signoff:: diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 105fc2dcdc..76702a0a5a 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules SYNOPSIS -------- [verse] -'git submodule' [--quiet] add [-b branch] [--] <repository> [<path>] +'git submodule' [--quiet] add [-b branch] [--] <repository> <path> 'git submodule' [--quiet] status [--cached] [--] [<path>...] 'git submodule' [--quiet] init [--] [<path>...] 'git submodule' [--quiet] update [--init] [--] [<path>...] @@ -20,14 +20,31 @@ COMMANDS -------- add:: Add the given repository as a submodule at the given path - to the changeset to be committed next. If path is a valid - repository within the project, it is added as is. Otherwise, - repository is cloned at the specified path. path is added to the - changeset and registered in .gitmodules. If no path is - specified, the path is deduced from the repository specification. - If the repository url begins with ./ or ../, it is stored as - given but resolved as a relative path from the main project's - url when cloning. + to the changeset to be committed next to the current + project: the current project is termed termed the "superproject". ++ +This requires two arguments: <repository> and <path>. ++ +<repository> is the URL of the new submodule's origin repository. +This may be either an absolute URL, or (if it begins with ./ +or ../), the location relative to the superproject's origin +repository. ++ +<path> is the relative location for the cloned submodule to +exist in the superproject. If <path> does not exist, then the +submodule is created by cloning from the named URL. If <path> does +exist and is already a valid git repository, then this is added +to the changeset without cloning. This second form is provided +to ease creating a new submodule from scratch, and presumes +the user will later push the submodule to the given URL. ++ +In either case, the given URL is recorded into .gitmodules for +use by subsequent users cloning the superproject. If the URL is +given relative to the superproject's repository, the presumption +is the superproject and submodule repositories will be kept +together in the same relative location, and only the +superproject's URL need be provided: git-submodule will correctly +locate the submodule using the relative URL in .gitmodules. status:: Show the status of the submodules. This will print the SHA-1 of the @@ -85,6 +102,7 @@ OPTIONS <path>:: Path to submodule(s). When specified this will restrict the command to only operate on the submodules found at the specified paths. + (This argument is required with add). FILES ----- diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index e71b561172..48d1454a90 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -274,7 +274,7 @@ same machine, wants to contribute. Bob begins with: ------------------------------------------------ -$ git clone /home/alice/project myrepo +bob$ git clone /home/alice/project myrepo ------------------------------------------------ This creates a new directory "myrepo" containing a clone of Alice's @@ -285,7 +285,7 @@ Bob then makes some changes and commits them: ------------------------------------------------ (edit files) -$ git commit -a +bob$ git commit -a (repeat as necessary) ------------------------------------------------ @@ -293,8 +293,8 @@ When he's ready, he tells Alice to pull changes from the repository at /home/bob/myrepo. She does this with: ------------------------------------------------ -$ cd /home/alice/project -$ git pull /home/bob/myrepo master +alice$ cd /home/alice/project +alice$ git pull /home/bob/myrepo master ------------------------------------------------ This merges the changes from Bob's "master" branch into Alice's @@ -306,21 +306,47 @@ is the default.) The "pull" command thus performs two operations: it fetches changes from a remote branch, then merges them into the current branch. +Note that in general, Alice would want her local changes committed before +initiating this "pull". If Bob's work conflicts with what Alice did since +their histories forked, Alice will use her working tree and the index to +resolve conflicts, and existing local changes will interfere with the +conflict resolution process (git will still perform the fetch but will +refuse to merge --- Alice will have to get rid of her local changes in +some way and pull again when this happens). + +Alice can peek at what Bob did without merging first, using the "fetch" +command; this allows Alice to inspect what Bob did, using a special +symbol "FETCH_HEAD", in order to determine if he has anything worth +pulling, like this: + +------------------------------------------------ +alice$ git fetch /home/bob/myrepo master +alice$ git log -p ..FETCH_HEAD +------------------------------------------------ + +This operation is safe even if Alice has uncommitted local changes. + +After inspecting what Bob did, if there is nothing urgent, Alice may +decide to continue working without pulling from Bob. If Bob's history +does have something Alice would immediately need, Alice may choose to +stash her work-in-progress first, do a "pull", and then finally unstash +her work-in-progress on top of the resulting history. + When you are working in a small closely knit group, it is not unusual to interact with the same repository over and over again. By defining 'remote' repository shorthand, you can make it easier: ------------------------------------------------ -$ git remote add bob /home/bob/myrepo +alice$ git remote add bob /home/bob/myrepo ------------------------------------------------ -With this, Alice can perform the first operation alone using the +With this, Alice can perform the first part of the "pull" operation alone using the 'git-fetch' command without merging them with her own branch, using: ------------------------------------- -$ git fetch bob +alice$ git fetch bob ------------------------------------- Unlike the longhand form, when Alice fetches from Bob using a @@ -329,7 +355,7 @@ fetched is stored in a remote tracking branch, in this case `bob/master`. So after this: ------------------------------------- -$ git log -p master..bob/master +alice$ git log -p master..bob/master ------------------------------------- shows a list of all the changes that Bob made since he branched from @@ -339,14 +365,14 @@ After examining those changes, Alice could merge the changes into her master branch: ------------------------------------- -$ git merge bob/master +alice$ git merge bob/master ------------------------------------- This `merge` can also be done by 'pulling from her own remote tracking branch', like this: ------------------------------------- -$ git pull . remotes/bob/master +alice$ git pull . remotes/bob/master ------------------------------------- Note that git pull always merges into the current branch, @@ -355,7 +381,7 @@ regardless of what else is given on the command line. Later, Bob can update his repo with Alice's latest changes using ------------------------------------- -$ git pull +bob$ git pull ------------------------------------- Note that he doesn't need to give the path to Alice's repository; @@ -364,7 +390,7 @@ repository in the repository configuration, and that location is used for pulls: ------------------------------------- -$ git config --get remote.origin.url +bob$ git config --get remote.origin.url /home/alice/project ------------------------------------- @@ -376,7 +402,7 @@ Git also keeps a pristine copy of Alice's master branch under the name "origin/master": ------------------------------------- -$ git branch -r +bob$ git branch -r origin/master ------------------------------------- @@ -384,7 +410,7 @@ If Bob later decides to work from a different host, he can still perform clones and pulls using the ssh protocol: ------------------------------------- -$ git clone alice.org:/home/alice/project myrepo +bob$ git clone alice.org:/home/alice/project myrepo ------------------------------------- Alternatively, git has a native protocol, or can use rsync or http; diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index 69e6d2fa44..c11d495771 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -101,6 +101,7 @@ The placeholders are: - '%P': parent hashes - '%p': abbreviated parent hashes - '%an': author name +- '%aN': author name (respecting .mailmap) - '%ae': author email - '%ad': author date - '%aD': author date, RFC2822 style @@ -108,6 +109,7 @@ The placeholders are: - '%at': author date, UNIX timestamp - '%ai': author date, ISO 8601 format - '%cn': committer name +- '%cN': committer name (respecting .mailmap) - '%ce': committer email - '%cd': committer date - '%cD': committer date, RFC2822 style diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 92d400753d..8761ee7e7d 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2431,7 +2431,7 @@ $ git rebase origin ------------------------------------------------- This will remove each of your commits from mywork, temporarily saving -them as patches (in a directory named ".dotest"), update mywork to +them as patches (in a directory named ".git/rebase"), update mywork to point at the latest version of origin, then apply each of the saved patches to the new mywork. The result will look like: |