For git-rebase.sh, --no-ff is a synonym for --force-rebase.
For git-rebase--interactive.sh, --no-ff cherry-picks all the commits in
the rebased branch, instead of fast-forwarding over any unchanged commits.
--no-ff offers an alternative way to deal with reverted merges. Instead of
"reverting the revert" you can use "rebase --no-ff" to recreate the branch
with entirely new commits (they're new because at the very least the
committer time is different). This obviates the need to revert the
reversion, as you can re-merge the new topic branch directly. Added an
addendum to revert-a-faulty-merge.txt describing the situation and how to
use --no-ff to handle it.
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
maint
Marc Branchaud15 years agocommitted byJunio C Hamano
@ -142,6 +142,8 @@ different resolution strategies:
@@ -142,6 +142,8 @@ different resolution strategies:
revert of a merge was rebuilt from scratch (i.e. rebasing and fixing,
as you seem to have interpreted), then re-merging the result without
doing anything else fancy would be the right thing to do.
(See the ADDENDUM below for how to rebuild a branch from scratch
without changing its original branching-off point.)
However, there are things to keep in mind when reverting a merge (and
reverting such a revert).
@ -177,3 +179,91 @@ the answer is: "oops, I really shouldn't have merged it, because it wasn't
@@ -177,3 +179,91 @@ the answer is: "oops, I really shouldn't have merged it, because it wasn't
ready yet, and I really need to undo _all_ of the merge"). So then you
really should revert the merge, but when you want to re-do the merge, you
now need to do it by reverting the revert.
ADDENDUM
Sometimes you have to rewrite one of a topic branch's commits *and* you can't
change the topic's branching-off point. Consider the following situation:
P---o---o---M---x---x---W---x
\ /
A---B---C
where commit W reverted commit M because it turned out that commit B was wrong
and needs to be rewritten, but you need the rewritten topic to still branch
from commit P (perhaps P is a branching-off point for yet another branch, and
you want be able to merge the topic into both branches).
The natural thing to do in this case is to checkout the A-B-C branch and use
"rebase -i P" to change commit B. However this does not rewrite commit A,
because "rebase -i" by default fast-forwards over any initial commits selected
with the "pick" command. So you end up with this:
P---o---o---M---x---x---W---x
\ /
A---B---C <-- old branch
\
B'---C' <-- naively rewritten branch
To merge A-B'-C' into the mainline branch you would still have to first revert
commit W in order to pick up the changes in A, but then it's likely that the
changes in B' will conflict with the original B changes re-introduced by the
reversion of W.
However, you can avoid these problems if you recreate the entire branch,
including commit A:
A'---B'---C' <-- completely rewritten branch
/
P---o---o---M---x---x---W---x
\ /
A---B---C
You can merge A'-B'-C' into the mainline branch without worrying about first
reverting W. Mainline's history would look like this:
A'---B'---C'------------------
/ \
P---o---o---M---x---x---W---x---M2
\ /
A---B---C
But if you don't actually need to change commit A, then you need some way to
recreate it as a new commit with the same changes in it. The rebase commmand's
--no-ff option provides a way to do this:
$ git rebase [-i] --no-ff P
The --no-ff option creates a new branch A'-B'-C' with all-new commits (all the
SHA IDs will be different) even if in the interactive case you only actually
modify commit B. You can then merge this new branch directly into the mainline
branch and be sure you'll get all of the branch's changes.
You can also use --no-ff in cases where you just add extra commits to the topic
to fix it up. Let's revisit the situation discussed at the start of this howto:
Marc Branchaud
15 years ago
committed by