From: Junio C Hamano Date: Wed, 31 Oct 2007 05:57:20 +0000 (+0000) Subject: Autogenerated HTML docs for v1.5.3.4-498-g9c514 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=1974bf2632180e353120c4cd1dca476df26c5bc0;p=git.git Autogenerated HTML docs for v1.5.3.4-498-g9c514 --- diff --git a/RelNotes-1.5.3.5.txt b/RelNotes-1.5.3.5.txt index e28d92f61..bf6a279ed 100644 --- a/RelNotes-1.5.3.5.txt +++ b/RelNotes-1.5.3.5.txt @@ -87,8 +87,14 @@ Fixes since v1.5.3.4 * A few workarounds to squelch false warnings from recent gcc have been added. + * "git-send-pack $remote frotz" segfaulted when there is nothing + named 'frotz' on the local end. + + * "git-rebase -interactive" did not handle its "--strategy" option + properly. + -- exec >/var/tmp/1 -O=v1.5.3.4-55-gf120ae2 +O=v1.5.3.4-65-gf91333d echo O=`git describe refs/heads/maint` git shortlog --no-merges $O..refs/heads/maint diff --git a/cmds-foreignscminterface.txt b/cmds-foreignscminterface.txt index 8880bb9db..f6bde74d2 100644 --- a/cmds-foreignscminterface.txt +++ b/cmds-foreignscminterface.txt @@ -25,6 +25,3 @@ gitlink:git-send-email[1]:: gitlink:git-svn[1]:: Bidirectional operation between a single Subversion branch and git. -gitlink:git-svnimport[1]:: - Import a SVN repository into git. - diff --git a/core-tutorial.html b/core-tutorial.html index 287b76380..4618ffce7 100644 --- a/core-tutorial.html +++ b/core-tutorial.html @@ -1098,7 +1098,7 @@ script called git merge, which wants to know which branches you want to resolve and what the merge is all about:

-
$ git merge "Merge work in mybranch" HEAD mybranch
+
$ git merge -m "Merge work in mybranch" mybranch

where the first argument is going to be used as the commit message if the merge can be resolved automatically.

@@ -1175,7 +1175,7 @@ to the master branch. Let's go back to mybranch, and run 
$ git checkout mybranch
-$ git merge "Merge upstream changes." HEAD master
+$ git merge -m "Merge upstream changes." master

This outputs something like this (the actual commit object names would be different)

@@ -1885,8 +1885,8 @@ in both of them. You could merge in diff-fix first and then commit-fix next, like this:

-
$ git merge 'Merge fix in diff-fix' master diff-fix
-$ git merge 'Merge fix in commit-fix' master commit-fix
+
$ git merge -m 'Merge fix in diff-fix' diff-fix
+$ git merge -m 'Merge fix in commit-fix' commit-fix

Which would result in:

@@ -1948,7 +1948,7 @@ to follow, not easier.

diff --git a/core-tutorial.txt b/core-tutorial.txt index d8e78ac8f..5df97a1f9 100644 --- a/core-tutorial.txt +++ b/core-tutorial.txt @@ -878,7 +878,7 @@ script called `git merge`, which wants to know which branches you want to resolve and what the merge is all about: ------------ -$ git merge "Merge work in mybranch" HEAD mybranch +$ git merge -m "Merge work in mybranch" mybranch ------------ where the first argument is going to be used as the commit message if @@ -965,7 +965,7 @@ to the `master` branch. Let's go back to `mybranch`, and run ------------ $ git checkout mybranch -$ git merge "Merge upstream changes." HEAD master +$ git merge -m "Merge upstream changes." master ------------ This outputs something like this (the actual commit object names @@ -1607,8 +1607,8 @@ in both of them. You could merge in 'diff-fix' first and then 'commit-fix' next, like this: ------------ -$ git merge 'Merge fix in diff-fix' master diff-fix -$ git merge 'Merge fix in commit-fix' master commit-fix +$ git merge -m 'Merge fix in diff-fix' diff-fix +$ git merge -m 'Merge fix in commit-fix' commit-fix ------------ Which would result in: diff --git a/git-bisect.html b/git-bisect.html index 105681297..87f8c1665 100644 --- a/git-bisect.html +++ b/git-bisect.html @@ -281,8 +281,9 @@ on the subcommand:

git bisect start [<bad> [<good>...]] [--] [<paths>...]
-git bisect bad <rev>
-git bisect good <rev>
+git bisect bad [<rev>]
+git bisect good [<rev>...]
+git bisect skip [<rev>...]
 git bisect reset [<branch>]
 git bisect visualize
 git bisect replay <logfile>
@@ -372,6 +373,16 @@ $ git reset --hard HEAD~3               # try 3 revs before what

Then compile and test the one you chose to try. After that, tell bisect what the result was as usual.

+

Bisect skip

+

Instead of choosing by yourself a nearby commit, you may just want git +to do it for you using:

+
+
+
$ git bisect skip                 # Current version cannot be tested
+
+

But computing the commit to test may be slower afterwards and git may +eventually not be able to tell the first bad among a bad and one or +more "skip"ped commits.

Cutting down bisection by giving more parameters to bisect start

You can further cut down the number of trials if you know what part of the tree is involved in the problem you are tracking down, by giving @@ -398,12 +409,15 @@ or bad, you can automatically bisect using:

$ git bisect run my_script

Note that the "run" script (my_script in the above example) should -exit with code 0 in case the current source code is good and with a -code between 1 and 127 (included) in case the current source code is -bad.

+exit with code 0 in case the current source code is good. Exit with a +code between 1 and 127 (inclusive), except 125, if the current +source code is bad.

Any other exit code will abort the automatic bisect process. (A program that does "exit(-1)" leaves $? = 255, see exit(3) manual page, the value is chopped with "& 0377".)

+

The special exit code 125 should be used when the current source code +cannot be tested. If the "run" script exits with this code, the current +revision will be skipped, see git bisect skip above.

You may often find that during bisect you want to have near-constant tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or "revision that does not have this commit needs this patch applied to @@ -431,7 +445,7 @@ know the outcome.

diff --git a/git-bisect.txt b/git-bisect.txt index 1072fb87d..4795349c1 100644 --- a/git-bisect.txt +++ b/git-bisect.txt @@ -16,8 +16,9 @@ The command takes various subcommands, and different options depending on the subcommand: git bisect start [ [...]] [--] [...] - git bisect bad - git bisect good + git bisect bad [] + git bisect good [...] + git bisect skip [...] git bisect reset [] git bisect visualize git bisect replay @@ -134,6 +135,20 @@ $ git reset --hard HEAD~3 # try 3 revs before what Then compile and test the one you chose to try. After that, tell bisect what the result was as usual. +Bisect skip +~~~~~~~~~~~~ + +Instead of choosing by yourself a nearby commit, you may just want git +to do it for you using: + +------------ +$ git bisect skip # Current version cannot be tested +------------ + +But computing the commit to test may be slower afterwards and git may +eventually not be able to tell the first bad among a bad and one or +more "skip"ped commits. + Cutting down bisection by giving more parameters to bisect start ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -167,14 +182,18 @@ $ git bisect run my_script ------------ Note that the "run" script (`my_script` in the above example) should -exit with code 0 in case the current source code is good and with a -code between 1 and 127 (included) in case the current source code is -bad. +exit with code 0 in case the current source code is good. Exit with a +code between 1 and 127 (inclusive), except 125, if the current +source code is bad. Any other exit code will abort the automatic bisect process. (A program that does "exit(-1)" leaves $? = 255, see exit(3) manual page, the value is chopped with "& 0377".) +The special exit code 125 should be used when the current source code +cannot be tested. If the "run" script exits with this code, the current +revision will be skipped, see `git bisect skip` above. + You may often find that during bisect you want to have near-constant tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or "revision that does not have this commit needs this patch applied to diff --git a/git-cvsexportcommit.html b/git-cvsexportcommit.html index 7efb4aca1..4d233fab3 100644 --- a/git-cvsexportcommit.html +++ b/git-cvsexportcommit.html @@ -382,7 +382,7 @@ Merge one patch into CVS 
$ export GIT_DIR=~/project/.git
 $ cd ~/project_cvs_checkout
 $ git-cvsexportcommit -v <commit-sha1>
-$ cvs commit -F .mgs <files>
+$ cvs commit -F .msg <files>
@@ -412,7 +412,7 @@ $ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit diff --git a/git-cvsexportcommit.txt b/git-cvsexportcommit.txt index 4c8d1e638..c3922f923 100644 --- a/git-cvsexportcommit.txt +++ b/git-cvsexportcommit.txt @@ -73,7 +73,7 @@ Merge one patch into CVS:: $ export GIT_DIR=~/project/.git $ cd ~/project_cvs_checkout $ git-cvsexportcommit -v -$ cvs commit -F .mgs +$ cvs commit -F .msg ------------ Merge pending patches into CVS automatically -- only if you really know what you are doing:: diff --git a/git-merge.html b/git-merge.html index 329795b6a..f96f3ae3c 100644 --- a/git-merge.html +++ b/git-merge.html @@ -274,12 +274,16 @@ git-merge(1) Manual Page
git-merge [-n] [--summary] [--no-commit] [--squash] [-s <strategy>]… - [-m <msg>] <remote> <remote>…
+ [-m <msg>] <remote> <remote>… +git-merge <msg> HEAD <remote>…

DESCRIPTION

This is the top-level interface to the merge machinery which drives multiple merge strategy scripts.

+

The second syntax (<msg> HEAD <remote>) is supported for +historical reasons. Do not use it from the command line or in +new scripts. It is the same as git merge -m <msg> <remote>.

OPTIONS

@@ -375,7 +379,7 @@ which drives multiple merge strategy scripts.

-<msg> +-m <msg>

@@ -385,15 +389,6 @@ which drives multiple merge strategy scripts.

-<head> -
-
-

- Our branch head commit. This has to be HEAD, so new - syntax does not require it -

-
-
<remote>
@@ -653,7 +648,7 @@ Resolve the conflicts. git-diff would report only the diff --git a/git-merge.txt b/git-merge.txt index bca4212e5..eabd7ef33 100644 --- a/git-merge.txt +++ b/git-merge.txt @@ -11,26 +11,27 @@ SYNOPSIS [verse] 'git-merge' [-n] [--summary] [--no-commit] [--squash] [-s ]... [-m ] ... +'git-merge' HEAD ... DESCRIPTION ----------- This is the top-level interface to the merge machinery which drives multiple merge strategy scripts. +The second syntax ( `HEAD` ) is supported for +historical reasons. Do not use it from the command line or in +new scripts. It is the same as `git merge -m `. + OPTIONS ------- include::merge-options.txt[] -:: +-m :: The commit message to be used for the merge commit (in case it is created). The `git-fmt-merge-msg` script can be used to give a good default for automated `git-merge` invocations. -:: - Our branch head commit. This has to be `HEAD`, so new - syntax does not require it - :: Other branch head merged into our branch. You need at least one . Specifying more than one diff --git a/git-rev-list.html b/git-rev-list.html index 46863a4d3..36d93a3c7 100644 --- a/git-rev-list.html +++ b/git-rev-list.html @@ -298,6 +298,7 @@ git-rev-list(1) Manual Page [ --pretty | --header ] [ --bisect ] [ --bisect-vars ] + [ --bisect-all ] [ --merge ] [ --reverse ] [ --walk-reflogs ] @@ -753,6 +754,23 @@ turns out to be bad to bisect_bad, and the number of commits we are bisecting right now to bisect_all.

+
+--bisect-all +
+
+

+This outputs all the commit objects between the included and excluded +commits, ordered by their distance to the included and excluded +commits. The farthest from them is displayed first. (This is the only +one displayed by --bisect.) +

+

This is useful because it makes it easy to choose a good commit to +test when you want to avoid to test some of them for some reason (they +may not compile for example).

+

This option can be used along with --bisect-vars, in this case, +after all the sorted commit objects, there will be the same text as if +--bisect-vars had been used alone.

+

Commit Ordering

By default, the commits are shown in reverse chronological order.

@@ -1144,7 +1162,7 @@ and the git-list <git@vger.kernel.org>.

diff --git a/git-rev-list.txt b/git-rev-list.txt index 7cd0e8913..485280423 100644 --- a/git-rev-list.txt +++ b/git-rev-list.txt @@ -34,6 +34,7 @@ SYNOPSIS [ \--pretty | \--header ] [ \--bisect ] [ \--bisect-vars ] + [ \--bisect-all ] [ \--merge ] [ \--reverse ] [ \--walk-reflogs ] @@ -354,6 +355,21 @@ the expected number of commits to be tested if `bisect_rev` turns out to be bad to `bisect_bad`, and the number of commits we are bisecting right now to `bisect_all`. +--bisect-all:: + +This outputs all the commit objects between the included and excluded +commits, ordered by their distance to the included and excluded +commits. The farthest from them is displayed first. (This is the only +one displayed by `--bisect`.) + +This is useful because it makes it easy to choose a good commit to +test when you want to avoid to test some of them for some reason (they +may not compile for example). + +This option can be used along with `--bisect-vars`, in this case, +after all the sorted commit objects, there will be the same text as if +`--bisect-vars` had been used alone. + -- Commit Ordering diff --git a/git-svnimport.txt b/git-svnimport.txt deleted file mode 100644 index 71aad8b45..000000000 --- a/git-svnimport.txt +++ /dev/null @@ -1,179 +0,0 @@ -git-svnimport(1) -================ -v0.1, July 2005 - -NAME ----- -git-svnimport - Import a SVN repository into git - - -SYNOPSIS --------- -[verse] -'git-svnimport' [ -o ] [ -h ] [ -v ] [ -d | -D ] - [ -C ] [ -i ] [ -u ] [-l limit_rev] - [ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ] - [ -s start_chg ] [ -m ] [ -r ] [ -M regex ] - [ -I ] [ -A ] - [ -R ] [ -P ] - [ ] - - -DESCRIPTION ------------ -Imports a SVN repository into git. It will either create a new -repository, or incrementally import into an existing one. - -SVN access is done by the SVN::Perl module. - -git-svnimport assumes that SVN repositories are organized into one -"trunk" directory where the main development happens, "branches/FOO" -directories for branches, and "/tags/FOO" directories for tags. -Other subdirectories are ignored. - -git-svnimport creates a file ".git/svn2git", which is required for -incremental SVN imports. - -OPTIONS -------- --C :: - The GIT repository to import to. If the directory doesn't - exist, it will be created. Default is the current directory. - --s :: - Start importing at this SVN change number. The default is 1. -+ -When importing incrementally, you might need to edit the .git/svn2git file. - --i:: - Import-only: don't perform a checkout after importing. This option - ensures the working directory and index remain untouched and will - not create them if they do not exist. - --T :: - Name the SVN trunk. Default "trunk". - --t :: - Name the SVN subdirectory for tags. Default "tags". - --b :: - Name the SVN subdirectory for branches. Default "branches". - --o :: - The 'trunk' branch from SVN is imported to the 'origin' branch within - the git repository. Use this option if you want to import into a - different branch. - --r:: - Prepend 'rX: ' to commit messages, where X is the imported - subversion revision. - --u:: - Replace underscores in tag names with periods. - --I :: - Import the svn:ignore directory property to files with this - name in each directory. (The Subversion and GIT ignore - syntaxes are similar enough that using the Subversion patterns - directly with "-I .gitignore" will almost always just work.) - --A :: - Read a file with lines on the form -+ ------- - username = User's Full Name - ------- -+ -and use "User's Full Name " as the GIT -author and committer for Subversion commits made by -"username". If encountering a commit made by a user not in the -list, abort. -+ -For convenience, this data is saved to $GIT_DIR/svn-authors -each time the -A option is provided, and read from that same -file each time git-svnimport is run with an existing GIT -repository without -A. - --m:: - Attempt to detect merges based on the commit message. This option - will enable default regexes that try to capture the name source - branch name from the commit message. - --M :: - Attempt to detect merges based on the commit message with a custom - regex. It can be used with -m to also see the default regexes. - You must escape forward slashes. - --l :: - Specify a maximum revision number to pull. -+ -Formerly, this option controlled how many revisions to pull, -due to SVN memory leaks. (These have been worked around.) - --R :: - Specify how often git repository should be repacked. -+ -The default value is 1000. git-svnimport will do import in chunks of 1000 -revisions, after each chunk git repository will be repacked. To disable -this behavior specify some big value here which is mote than number of -revisions to import. - --P :: - Partial import of the SVN tree. -+ -By default, the whole tree on the SVN trunk (/trunk) is imported. -'-P my/proj' will import starting only from '/trunk/my/proj'. -This option is useful when you want to import one project from a -svn repo which hosts multiple projects under the same trunk. - --v:: - Verbosity: let 'svnimport' report what it is doing. - --d:: - Use direct HTTP requests if possible. The "" argument is used - only for retrieving the SVN logs; the path to the contents is - included in the SVN log. - --D:: - Use direct HTTP requests if possible. The "" argument is used - for retrieving the logs, as well as for the contents. -+ -There's no safe way to automatically find out which of these options to -use, so you need to try both. Usually, the one that's wrong will die -with a 40x error pretty quickly. - -:: - The URL of the SVN module you want to import. For local - repositories, use "file:///absolute/path". -+ -If you're using the "-d" or "-D" option, this is the URL of the SVN -repository itself; it usually ends in "/svn". - -:: - The path to the module you want to check out. - --h:: - Print a short usage message and exit. - -OUTPUT ------- -If '-v' is specified, the script reports what it is doing. - -Otherwise, success is indicated the Unix way, i.e. by simply exiting with -a zero exit status. - -Author ------- -Written by Matthias Urlichs , with help from -various participants of the git-list . - -Based on a cvs2git script by the same author. - -Documentation --------------- -Documentation by Matthias Urlichs . - -GIT ---- -Part of the gitlink:git[7] suite diff --git a/git.html b/git.html index 6750abeb5..1a5c7ca94 100644 --- a/git.html +++ b/git.html @@ -971,14 +971,6 @@ people via patch over e-mail.

Bidirectional operation between a single Subversion branch and git.

-
-git-svnimport(1) -
-
-

- Import a SVN repository into git. -

-

Low-level commands (plumbing)

@@ -1957,7 +1949,7 @@ contributors on the git-list <git@vger.kernel.org>.