undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

git-rebase: document suppression of duplicate commits

Browse Source 
git-rebase uses format-patch's --ignore-if-in-upstream
option, but we never document the user-visible behavior. The
example is placed near the top of the example list rather
than at the bottom because it is:
  a. a simple example
  b. a reasonably common scenario for many projects (mail
     some patches which get accepted upstream, then rebase)

[sp: Corrected direction of 'HEAD..<upstream>' set comparsion]

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This commit is contained in:
Jeff King 2007-10-15 00:47:30 -04:00 committed by Shawn O. Pearce
parent 5040beff0b
commit ff9054627c
1 changed files with 24 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
Documentation/git-rebase.txt
View File

@ -28,7 +28,10 @@ The current branch is reset to <upstream>, or <newbase> if the
`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.
then reapplied to the current branch, one by one, in order. Note that
any commits in HEAD which introduce the same textual changes as a commit
in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream
with a different commit message or timestamp will be skipped).
It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
@ -62,6 +65,26 @@ would be:
The latter form is just a short-hand of `git checkout topic`
followed by `git rebase master`.
If the upstream branch already contains a change you have made (e.g.,
because you mailed a patch which was applied upstream), then that commit
will be skipped. For example, running `git-rebase master` on the
following history (in which A' and A introduce the same set of changes,
but have different committer information):
------------
A---B---C topic
/
D---E---A'---F master
------------
will result in:
------------
B'---C' topic
/
D---E---A'---F master
------------
Here is how you would transplant a topic branch based on one
branch to another, to pretend that you forked the topic branch
from the latter branch, using `rebase --onto`.