diff options
author | Jeff King <peff@peff.net> | 2007-10-15 00:47:30 -0400 |
---|---|---|
committer | Shawn O. Pearce <spearce@spearce.org> | 2007-10-16 01:18:43 -0400 |
commit | ff9054627c40082ad4a1cf16afebb140fcda41a2 (patch) | |
tree | 81890a8cdc5b40f00cc6722c822ed56f704cafd4 | |
parent | 5040beff0bacac79b305fbfa4df71e99c2f13ed8 (diff) | |
download | git-ff9054627c40082ad4a1cf16afebb140fcda41a2.tar.gz git-ff9054627c40082ad4a1cf16afebb140fcda41a2.tar.xz |
git-rebase: document suppression of duplicate commits
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>
-rw-r--r-- | Documentation/git-rebase.txt | 25 |
1 files changed, 24 insertions, 1 deletions
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index e8e75790f..e4326d332 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -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`. |