summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2007-10-15 00:47:30 -0400
committerLibravatar Shawn O. Pearce <spearce@spearce.org>2007-10-16 01:18:43 -0400
commitff9054627c40082ad4a1cf16afebb140fcda41a2 (patch)
tree81890a8cdc5b40f00cc6722c822ed56f704cafd4
parentDocumentation/git-tag.txt: Document how to backdate tags (diff)
downloadtgif-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.txt25
1 files changed, 24 insertions, 1 deletions
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index e8e75790fc..e4326d3322 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`.