mirror of
https://github.com/git/git
synced 2024-08-24 18:26:02 +00:00
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>
This commit is contained in:
parent
5040beff0b
commit
ff9054627c
|
@ -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`.
|
||||
|
|
Loading…
Reference in a new issue