diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/RelNotes/1.7.10.3.txt | 26 | ||||
-rw-r--r-- | Documentation/RelNotes/1.7.11.txt | 28 | ||||
-rw-r--r-- | Documentation/git-index-pack.txt | 10 | ||||
-rw-r--r-- | Documentation/git-submodule.txt | 6 | ||||
-rw-r--r-- | Documentation/git-svn.txt | 41 | ||||
-rw-r--r-- | Documentation/technical/pack-protocol.txt | 4 |
6 files changed, 66 insertions, 49 deletions
diff --git a/Documentation/RelNotes/1.7.10.3.txt b/Documentation/RelNotes/1.7.10.3.txt new file mode 100644 index 0000000000..9c9ec25946 --- /dev/null +++ b/Documentation/RelNotes/1.7.10.3.txt @@ -0,0 +1,26 @@ +Git v1.7.10.3 Release Notes +=========================== + +Fixes since v1.7.10.2 +--------------------- + + * Running "git checkout" on an unborn branch used to corrupt HEAD. + + * When checking out another commit from an already detached state, we + used to report all commits that are not reachable from any of the + refs as lossage, but some of them might be reachable from the new + HEAD, and there is no need to warn about them. + + * Some time ago, "git clone" lost the progress output for its + "checkout" phase; when run without any "--quiet" option, it should + give progress to the lengthy operation. + + * "log -z --pretty=tformat:..." did not terminate each record with + NUL. The fix is not entirely correct when the output also asks for + --patch and/or --stat, though. + + * The DWIM behaviour for "log --pretty=format:%gd -g" was somewhat + broken and gave undue precedence to configured log.date, causing + "git stash list" to show "stash@{time stamp string}". + +Also contains minor fixes and documentation updates. diff --git a/Documentation/RelNotes/1.7.11.txt b/Documentation/RelNotes/1.7.11.txt index 9ef7e18ca5..94c3615ef9 100644 --- a/Documentation/RelNotes/1.7.11.txt +++ b/Documentation/RelNotes/1.7.11.txt @@ -85,6 +85,10 @@ Performance and Internal Implementation (please report possible regressions) * "git archive" learned to produce its output without reading the blob object it writes out in memory in its entirety. + * "git index-pack" that runs when fetching or pushing objects to + complete the packfile on the receiving end learned to use multiple + threads to do its job when available. + * The code to compute hash values for lines used by the internal diff engine was optimized on little-endian machines, using the same trick the kernel folks came up with. @@ -116,25 +120,6 @@ Unless otherwise noted, all the fixes since v1.7.10 in the maintenance releases are contained in this release (see release notes to them for details). - * The DWIM behaviour for "log --pretty=format:%gd -g" was somewhat - broken and gave undue precedence to configured log.date, causing - "git stash list" to show "stash@{time stamp string}". - (merge 55ccf85 jk/maint-reflog-walk-count-vs-time later to maint). - - * Running "git checkout" on an unborn branch used to corrupt HEAD. - (merge 8338f77 ef/checkout-empty later to maint). - - * When checking out another commit from an already detached state, we - used to report all commits that are not reachable from any of the - refs as lossage, but some of them might be reachable from the new - HEAD, and there is no need to warn about them. - (merge 5d88639 js/checkout-detach-count later to maint). - - * Some time ago, "git clone" lost the progress output for its - "checkout" phase; when run without any "--quiet" option, it should - give progress to the lengthy operation. - (merge 8f63da1 ef/maint-clone-progress-fix later to maint). - * "git status --porcelain" ignored "--branch" option by mistake. The output for "git status --branch -z" was also incorrect and did not terminate the record for the current branch name with NUL as asked. @@ -143,8 +128,3 @@ details). * "git diff --stat" used to fully count a binary file with modified execution bits whose contents is unmodified, which was not quite right. - - * "log -z --pretty=tformat:..." did not terminate each record with - NUL. The fix is not entirely correct when the output also asks for - --patch and/or --stat, though. - (merge fafd382 jk/maint-tformat-with-z later to maint). diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt index 909687fed4..39e6d0ddd8 100644 --- a/Documentation/git-index-pack.txt +++ b/Documentation/git-index-pack.txt @@ -74,6 +74,16 @@ OPTIONS --strict:: Die, if the pack contains broken objects or links. +--threads=<n>:: + Specifies the number of threads to spawn when resolving + deltas. This requires that index-pack be compiled with + pthreads otherwise this option is ignored with a 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 use maximum 3 threads. + Note ---- diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index c83a856574..9e488c0aad 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -43,9 +43,9 @@ if you choose to go that route. Submodules are composed from a so-called `gitlink` tree entry in the main repository that refers to a particular commit object within the inner repository that is completely separate. -A record in the `.gitmodules` file at the root of the source -tree assigns a logical name to the submodule and describes -the default URL the submodule shall be cloned from. +A record in the `.gitmodules` (see linkgit:gitmodules[5]) file at the +root of the source tree assigns a logical name to the submodule and +describes the default URL the submodule shall be cloned from. The logical name can be used for overriding this URL within your local repository configuration (see 'submodule init'). diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 34ee785064..cfe8d2b5df 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -189,18 +189,16 @@ and have no uncommitted changes. last fetched commit from the upstream SVN. 'dcommit':: - Commit each diff from a specified head directly to the SVN + Commit each diff from the current branch directly to the SVN repository, and then rebase or reset (depending on whether or not there is a diff between SVN and head). This will create a revision in SVN for each commit in git. - It is recommended that you run 'git svn' fetch and rebase (not - pull or merge) your commits against the latest changes in the - SVN repository. - An optional revision or branch argument may be specified, and - causes 'git svn' to do all work on that revision/branch - instead of HEAD. - This is advantageous over 'set-tree' (below) because it produces - cleaner, more linear history. ++ +When an optional git branch name (or a git commit object name) +is specified as an argument, the subcommand works on the specified +branch, not on the current branch. ++ +Use of 'dcommit' is preferred to 'set-tree' (below). + --no-rebase;; After committing, do not rebase or reset. @@ -572,6 +570,8 @@ config key: svn.repackflags --merge:: -s<strategy>:: --strategy=<strategy>:: +-p:: +--preserve-merges:: These are only used with the 'dcommit' and 'rebase' commands. + Passed directly to 'git rebase' when using 'dcommit' if a @@ -800,18 +800,19 @@ have each person clone that repository with 'git clone': REBASE VS. PULL/MERGE --------------------- - -Originally, 'git svn' recommended that the 'remotes/git-svn' branch be -pulled or merged from. This is because the author favored +Prefer to use 'git svn rebase' or 'git rebase', rather than +'git pull' or 'git merge' to synchronize unintegrated commits with a 'git svn' +branch. Doing so will keep the history of unintegrated commits linear with +respect to the upstream SVN repository and allow the use of the preferred +'git svn dcommit' subcommand to push unintegrated commits back into SVN. + +Originally, 'git svn' recommended that developers pulled or merged from +the 'git svn' branch. This was because the author favored `git svn set-tree B` to commit a single head rather than the -`git svn set-tree A..B` notation to commit multiple commits. - -If you use `git svn set-tree A..B` to commit several diffs and you do -not have the latest remotes/git-svn merged into my-branch, you should -use `git svn rebase` to update your work branch instead of `git pull` or -`git merge`. `pull`/`merge` can cause non-linear history to be flattened -when committing into SVN, which can lead to merge commits reversing -previous commits in SVN. +`git svn set-tree A..B` notation to commit multiple commits. Use of +'git pull' or 'git merge' with `git svn set-tree A..B` will cause non-linear +history to be flattened when committing into SVN and this can lead to merge +commits unexpectedly reversing previous commits in SVN. MERGE TRACKING -------------- diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index 546980c0a4..49cdc571cd 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -351,7 +351,7 @@ Then the server will start sending its packfile data. A simple clone may look like this (with no 'have' lines): ---- - C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\0multi_ack \ + C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \ side-band-64k ofs-delta\n C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n @@ -367,7 +367,7 @@ A simple clone may look like this (with no 'have' lines): An incremental update (fetch) response might look like this: ---- - C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\0multi_ack \ + C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \ side-band-64k ofs-delta\n C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n |