* 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
gitlink:git-svn[1]::
Bidirectional operation between a single Subversion branch and git.
-gitlink:git-svnimport[1]::
- Import a SVN repository into git.
-
to resolve and what the merge is all about:</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git merge "Merge work in mybranch" HEAD mybranch</tt></pre>\r
+<pre><tt>$ git merge -m "Merge work in mybranch" mybranch</tt></pre>\r
</div></div>\r
<p>where the first argument is going to be used as the commit message if\r
the merge can be resolved automatically.</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ git checkout mybranch\r
-$ git merge "Merge upstream changes." HEAD master</tt></pre>\r
+$ git merge -m "Merge upstream changes." master</tt></pre>\r
</div></div>\r
<p>This outputs something like this (the actual commit object names\r
would be different)</p>\r
<em>commit-fix</em> next, like this:</p>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ git merge 'Merge fix in diff-fix' master diff-fix\r
-$ git merge 'Merge fix in commit-fix' master commit-fix</tt></pre>\r
+<pre><tt>$ git merge -m 'Merge fix in diff-fix' diff-fix\r
+$ git merge -m 'Merge fix in commit-fix' commit-fix</tt></pre>\r
</div></div>\r
<p>Which would result in:</p>\r
<div class="listingblock">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 30-Oct-2007 08:23:11 UTC\r
+Last updated 31-Oct-2007 05:56:51 UTC\r
</div>\r
</div>\r
</body>\r
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
------------
$ 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
'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:
<div class="literalblock">\r
<div class="content">\r
<pre><tt>git bisect start [<bad> [<good>...]] [--] [<paths>...]\r
-git bisect bad <rev>\r
-git bisect good <rev>\r
+git bisect bad [<rev>]\r
+git bisect good [<rev>...]\r
+git bisect skip [<rev>...]\r
git bisect reset [<branch>]\r
git bisect visualize\r
git bisect replay <logfile>\r
</div></div>\r
<p>Then compile and test the one you chose to try. After that, tell\r
bisect what the result was as usual.</p>\r
+<h3>Bisect skip</h3>\r
+<p>Instead of choosing by yourself a nearby commit, you may just want git\r
+to do it for you using:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git bisect skip # Current version cannot be tested</tt></pre>\r
+</div></div>\r
+<p>But computing the commit to test may be slower afterwards and git may\r
+eventually not be able to tell the first bad among a bad and one or\r
+more "skip"ped commits.</p>\r
<h3>Cutting down bisection by giving more parameters to bisect start</h3>\r
<p>You can further cut down the number of trials if you know what part of\r
the tree is involved in the problem you are tracking down, by giving\r
<pre><tt>$ git bisect run my_script</tt></pre>\r
</div></div>\r
<p>Note that the "run" script (<tt>my_script</tt> in the above example) should\r
-exit with code 0 in case the current source code is good and with a\r
-code between 1 and 127 (included) in case the current source code is\r
-bad.</p>\r
+exit with code 0 in case the current source code is good. Exit with a\r
+code between 1 and 127 (inclusive), except 125, if the current\r
+source code is bad.</p>\r
<p>Any other exit code will abort the automatic bisect process. (A\r
program that does "exit(-1)" leaves $? = 255, see exit(3) manual page,\r
the value is chopped with "& 0377".)</p>\r
+<p>The special exit code 125 should be used when the current source code\r
+cannot be tested. If the "run" script exits with this code, the current\r
+revision will be skipped, see <tt>git bisect skip</tt> above.</p>\r
<p>You may often find that during bisect you want to have near-constant\r
tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or\r
"revision that does not have this commit needs this patch applied to\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:31 UTC\r
+Last updated 31-Oct-2007 05:56:47 UTC\r
</div>\r
</div>\r
</body>\r
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>
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------
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
<pre><tt>$ export GIT_DIR=~/project/.git\r
$ cd ~/project_cvs_checkout\r
$ git-cvsexportcommit -v <commit-sha1>\r
-$ cvs commit -F .mgs <files></tt></pre>\r
+$ cvs commit -F .msg <files></tt></pre>\r
</div></div>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 25-Aug-2007 03:53:07 UTC\r
+Last updated 31-Oct-2007 05:56:47 UTC\r
</div>\r
</div>\r
</body>\r
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
$ git-cvsexportcommit -v <commit-sha1>
-$ cvs commit -F .mgs <files>
+$ cvs commit -F .msg <files>
------------
Merge pending patches into CVS automatically -- only if you really know what you are doing::
<div class="sectionbody">\r
<div class="verseblock">\r
<div class="content"><em>git-merge</em> [-n] [--summary] [--no-commit] [--squash] [-s <strategy>]…\r
- [-m <msg>] <remote> <remote>…</div></div>\r
+ [-m <msg>] <remote> <remote>…\r
+<em>git-merge</em> <msg> HEAD <remote>…</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
<p>This is the top-level interface to the merge machinery\r
which drives multiple merge strategy scripts.</p>\r
+<p>The second syntax (<msg> <tt>HEAD</tt> <remote>) is supported for\r
+historical reasons. Do not use it from the command line or in\r
+new scripts. It is the same as <tt>git merge -m <msg> <remote></tt>.</p>\r
</div>\r
<h2>OPTIONS</h2>\r
<div class="sectionbody">\r
</p>\r
</dd>\r
<dt>\r
-<msg>\r
+-m <msg>\r
</dt>\r
<dd>\r
<p>\r
</p>\r
</dd>\r
<dt>\r
-<head>\r
-</dt>\r
-<dd>\r
-<p>\r
- Our branch head commit. This has to be <tt>HEAD</tt>, so new\r
- syntax does not require it\r
-</p>\r
-</dd>\r
-<dt>\r
<remote>\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2007 12:03:50 UTC\r
+Last updated 31-Oct-2007 05:56:48 UTC\r
</div>\r
</div>\r
</body>\r
[verse]
'git-merge' [-n] [--summary] [--no-commit] [--squash] [-s <strategy>]...
[-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
-------
include::merge-options.txt[]
-<msg>::
+-m <msg>::
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.
-<head>::
- Our branch head commit. This has to be `HEAD`, so new
- syntax does not require it
-
<remote>::
Other branch head merged into our branch. You need at
least one <remote>. Specifying more than one <remote>
[ --pretty | --header ]\r
[ --bisect ]\r
[ --bisect-vars ]\r
+ [ --bisect-all ]\r
[ --merge ]\r
[ --reverse ]\r
[ --walk-reflogs ]\r
we are bisecting right now to <tt>bisect_all</tt>.\r
</p>\r
</dd>\r
+<dt>\r
+--bisect-all\r
+</dt>\r
+<dd>\r
+<p>\r
+This outputs all the commit objects between the included and excluded\r
+commits, ordered by their distance to the included and excluded\r
+commits. The farthest from them is displayed first. (This is the only\r
+one displayed by <tt>--bisect</tt>.)\r
+</p>\r
+<p>This is useful because it makes it easy to choose a good commit to\r
+test when you want to avoid to test some of them for some reason (they\r
+may not compile for example).</p>\r
+<p>This option can be used along with <tt>--bisect-vars</tt>, in this case,\r
+after all the sorted commit objects, there will be the same text as if\r
+<tt>--bisect-vars</tt> had been used alone.</p>\r
+</dd>\r
</dl>\r
<h3>Commit Ordering</h3>\r
<p>By default, the commits are shown in reverse chronological order.</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 25-Aug-2007 03:53:13 UTC\r
+Last updated 31-Oct-2007 05:56:48 UTC\r
</div>\r
</div>\r
</body>\r
[ \--pretty | \--header ]
[ \--bisect ]
[ \--bisect-vars ]
+ [ \--bisect-all ]
[ \--merge ]
[ \--reverse ]
[ \--walk-reflogs ]
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
+++ /dev/null
-git-svnimport(1)
-================
-v0.1, July 2005
-
-NAME
-----
-git-svnimport - Import a SVN repository into git
-
-
-SYNOPSIS
---------
-[verse]
-'git-svnimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ]
- [ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
- [ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
- [ -s start_chg ] [ -m ] [ -r ] [ -M regex ]
- [ -I <ignorefile_name> ] [ -A <author_file> ]
- [ -R <repack_each_revs>] [ -P <path_from_trunk> ]
- <SVN_repository_URL> [ <path> ]
-
-
-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 <target-dir>::
- The GIT repository to import to. If the directory doesn't
- exist, it will be created. Default is the current directory.
-
--s <start_rev>::
- 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 <trunk_subdir>::
- Name the SVN trunk. Default "trunk".
-
--t <tag_subdir>::
- Name the SVN subdirectory for tags. Default "tags".
-
--b <branch_subdir>::
- Name the SVN subdirectory for branches. Default "branches".
-
--o <branch-for-HEAD>::
- 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 <ignorefile_name>::
- 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 <author_file>::
- Read a file with lines on the form
-+
-------
- username = User's Full Name <email@addr.es>
-
-------
-+
-and use "User's Full Name <email@addr.es>" 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 <regex>::
- 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 <max_rev>::
- 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 <repack_each_revs>::
- 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 <path_from_trunk>::
- 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 "<path>" 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 "<path>" 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.
-
-<SVN_repository_URL>::
- 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".
-
-<path>::
- 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 <smurf@smurf.noris.de>, with help from
-various participants of the git-list <git@vger.kernel.org>.
-
-Based on a cvs2git script by the same author.
-
-Documentation
---------------
-Documentation by Matthias Urlichs <smurf@smurf.noris.de>.
-
-GIT
----
-Part of the gitlink:git[7] suite
Bidirectional operation between a single Subversion branch and git.\r
</p>\r
</dd>\r
-<dt>\r
-<a href="git-svnimport.html">git-svnimport(1)</a>\r
-</dt>\r
-<dd>\r
-<p>\r
- Import a SVN repository into git.\r
-</p>\r
-</dd>\r
</dl>\r
</div>\r
<h2>Low-level commands (plumbing)</h2>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 24-Oct-2007 11:51:42 UTC\r
+Last updated 31-Oct-2007 05:56:51 UTC\r
</div>\r
</div>\r
</body>\r
projects / git.git / commitdiff