diff options
author | Shawn O. Pearce <spearce@spearce.org> | 2007-02-17 04:31:50 -0500 |
---|---|---|
committer | Junio C Hamano <junkio@cox.net> | 2007-02-17 10:08:21 -0800 |
commit | 5ca2db53763ed93a75de7ddbda753fc09327d7aa (patch) | |
tree | ea2566b2f62de6956b08a2d3b4e03238dcd6b6f5 | |
parent | 185c975faaa790a98a4e00f124461473283500d6 (diff) | |
download | git-5ca2db53763ed93a75de7ddbda753fc09327d7aa.tar.gz git-5ca2db53763ed93a75de7ddbda753fc09327d7aa.tar.xz |
Attempt to improve git-rebase lead-in description.
It was mentioned on #git this morning that the lead-in description
of git-rebase is very confusing. Too many branch this and branch
that in a very short run of text.
This new description attempts to walk the user through the command
syntax, while also describing exactly what git-rebase is doing to
their repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
-rw-r--r-- | Documentation/git-rebase.txt | 22 |
1 files changed, 14 insertions, 8 deletions
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index f2ef1f7dc..a66b2d73c 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -13,11 +13,20 @@ SYNOPSIS DESCRIPTION ----------- -git-rebase replaces <branch> with a new branch of the same name. When -the --onto option is provided the new branch starts out with a HEAD equal -to <newbase>, otherwise it is equal to <upstream>. It then attempts to -create a new commit for each commit from the original <branch> that does -not exist in the <upstream> branch. +If <branch> is specified, git-rebase will perform an automatic +`git checkout <branch>` before doing anything else. Otherwise +it remains on the current branch. + +All changes made by commits in the current branch but that are not +in <upstream> are saved to a temporary area. This is the same set +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>). + +The commits that were previously saved into the temporary area are +then reapplied to the current branch, one by one, in order. It is possible that a merge failure will prevent this process from being completely automatic. You will have to resolve any such merge failure @@ -26,9 +35,6 @@ that caused the merge failure with `git rebase --skip`. To restore the original <branch> and remove the .dotest working files, use the command `git rebase --abort` instead. -Note that if <branch> is not specified on the command line, the currently -checked out branch is used. - Assume the following history exists and the current branch is "topic": ------------ |