git-rebase: Clarify usage statement and copy it into the actual documentation.

I found a paper thin man page for git-rebase, but was quite happy to
see something much more useful in the usage statement of the script
when I went there to find out how this thing worked. Here it is
cleaned up slightly and expanded a bit into the actual documentation.

Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This commit is contained in:
Carl Worth 2006-02-21 17:10:12 -08:00 committed by Junio C Hamano
parent 6643688867
commit 69a60af5d0
2 changed files with 56 additions and 12 deletions

View File

@ -7,14 +7,54 @@ git-rebase - Rebase local commits to new upstream head.
SYNOPSIS
--------
'git-rebase' <upstream> [<head>]
'git-rebase' [--onto <newbase>] <upstream> [<branch>]
DESCRIPTION
-----------
Rebases local commits to the new head of the upstream tree.
git-rebase applies to <upstream> (or optionally to <newbase>) commits
from <branch> that do not appear in <upstream>. When <branch> is not
specified it defaults to the current branch (HEAD).
When git-rebase is complete, <branch> will be updated to point to the
newly created line of commit objects, so the previous line will not be
accessible unless there are other references to it already.
Assume the following history exists and the current branch is "topic":
A---B---C topic
/
D---E---F---G master
From this point, the result of the following commands:
git-rebase master
git-rebase master topic
would be:
A'--B'--C' topic
/
D---E---F---G master
While, starting from the same point, the result of the following
commands:
git-rebase --onto master~1 master
git-rebase --onto master~1 master topic
would be:
A'--B'--C' topic
/
D---E---F---G master
OPTIONS
-------
<newbase>::
Starting point at which to create the new commits. If the
--onto option is not specified, the starting point is
<upstream>.
<upstream>::
Upstream branch to compare against.

View File

@ -4,24 +4,28 @@
#
USAGE='[--onto <newbase>] <upstream> [<branch>]'
LONG_USAGE='If <branch> is specified, switch to that branch first. Then,
extract commits in the current branch that are not in <upstream>,
and reconstruct the current on top of <upstream>, discarding the original
development history. If --onto <newbase> is specified, the history is
reconstructed on top of <newbase>, instead of <upstream>. For example,
while on "topic" branch:
LONG_USAGE='git-rebase applies to <upstream> (or optionally to <newbase>) commits
from <branch> that do not appear in <upstream>. When <branch> is not
specified it defaults to the current branch (HEAD).
When git-rebase is complete, <branch> will be updated to point to the
newly created line of commit objects, so the previous line will not be
accessible unless there are other references to it already.
Assuming the following history:
A---B---C topic
/
D---E---F---G master
$ '"$0"' --onto master~1 master topic
The result of the following command:
would rewrite the history to look like this:
git-rebase --onto master~1 master topic
would be:
A'\''--B'\''--C'\'' topic
/
A'\''--B'\''--C'\'' topic
/
D---E---F---G master
'