summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 2c162b5)
raw | patch | inline | side by side (parent: 2c162b5)
author | Andrew Wong <andrew.kw.w@gmail.com> | |
Sat, 18 Jun 2011 22:12:01 +0000 (18:12 -0400) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Sun, 19 Jun 2011 21:37:23 +0000 (14:37 -0700) |
Consider this graph:
D---E (topic, HEAD)
/ /
A---B---C (master)
\
F (topic2)
and the following three commands:
1. git rebase -i -p A
2. git rebase -i -p --onto F A
3. git rebase -i -p B
Currently, (1) and (2) will pick B, D, C, and E onto A and F,
respectively. However, (3) will only pick D and E onto B, but not C,
which is inconsistent with (1) and (2). As a result, we cannot modify C
during the interactive-rebase.
The current behavior also creates a bug if we do:
4. git rebase -i -p C
In (4), E is never picked. And since interactive-rebase resets "HEAD"
to "onto" before picking any commits, D and E are lost after the
interactive-rebase.
This patch fixes the inconsistency and bug by ensuring that all children
of upstream are always picked. This essentially reverts the commit:
d80d6bc146232d81f1bb4bc58e5d89263fd228d4
When compiling the todo list, commits reachable from "upstream" should
never be skipped under any conditions. Otherwise, we lose the ability
to modify them like (3), and create a bug like (4).
Two of the tests contain a scenario like (3). Since the new behavior
added more commits for picking, these tests need to be updated to
account for the additional pick lines. A new test has also been added
for (4).
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
D---E (topic, HEAD)
/ /
A---B---C (master)
\
F (topic2)
and the following three commands:
1. git rebase -i -p A
2. git rebase -i -p --onto F A
3. git rebase -i -p B
Currently, (1) and (2) will pick B, D, C, and E onto A and F,
respectively. However, (3) will only pick D and E onto B, but not C,
which is inconsistent with (1) and (2). As a result, we cannot modify C
during the interactive-rebase.
The current behavior also creates a bug if we do:
4. git rebase -i -p C
In (4), E is never picked. And since interactive-rebase resets "HEAD"
to "onto" before picking any commits, D and E are lost after the
interactive-rebase.
This patch fixes the inconsistency and bug by ensuring that all children
of upstream are always picked. This essentially reverts the commit:
d80d6bc146232d81f1bb4bc58e5d89263fd228d4
When compiling the todo list, commits reachable from "upstream" should
never be skipped under any conditions. Otherwise, we lose the ability
to modify them like (3), and create a bug like (4).
Two of the tests contain a scenario like (3). Since the new behavior
added more commits for picking, these tests need to be updated to
account for the additional pick lines. A new test has also been added
for (4).
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
index 65690af89307abd72749123caddce9e6c4692383..c6ba7c15510935353bd17b2b8d8188fe16052907 100644 (file)
# parents to rewrite and skipping dropped commits would
# prematurely end our probe
merges_option=
- first_after_upstream="$(git rev-list --reverse --first-parent $upstream..$orig_head | head -n 1)"
else
merges_option="--no-merges --cherry-pick"
fi
preserve=t
for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -s -f2-)
do
- if test -f "$rewritten"/$p -a \( $p != $onto -o $sha1 = $first_after_upstream \)
+ if test -f "$rewritten"/$p
then
preserve=f
fi
index 47c8371c7edfe7945ded380bb6f96a00d26c04eb..8538813d1d0dfa72008da1d711cf2c042796a6ee 100755 (executable)
'
test_expect_success 'edit ancestor with -p' '
- FAKE_LINES="1 edit 2 3 4" git rebase -i -p HEAD~3 &&
+ FAKE_LINES="1 2 edit 3 4" git rebase -i -p HEAD~3 &&
echo 2 > unrelated-file &&
test_tick &&
git commit -m L2-modified --amend unrelated-file &&
index 08201e2331d36af769d832e3d9551c48331b7033..6de4e2263f9ec65d2de2e28af6a12d5c1065f686 100755 (executable)
# \
# B2 <-- origin/topic
#
-# In all cases, 'topic' is rebased onto 'origin/topic'.
+# Clone 4 (merge using second parent as base):
+#
+# A1--A2--B3 <-- origin/master
+# \
+# B1--A3--M <-- topic
+# \ /
+# \--A4 <-- topic2
+# \
+# B2 <-- origin/topic
test_expect_success 'setup for merge-preserving rebase' \
'echo First > A &&
git merge origin/master
) &&
+ git clone ./. clone4 &&
+ (
+ cd clone4 &&
+ git checkout -b topic origin/topic &&
+ git merge origin/master
+ ) &&
+
echo Fifth > B &&
git add B &&
git commit -m "Add different B" &&
)
'
+test_expect_success 'rebase -p works when base inside second parent' '
+ (
+ cd clone4 &&
+ git fetch &&
+ git rebase -p HEAD^2 &&
+ test 1 = $(git rev-list --all --pretty=oneline | grep "Modify A" | wc -l) &&
+ test 1 = $(git rev-list --all --pretty=oneline | grep "Modify B" | wc -l) &&
+ test 1 = $(git rev-list --all --pretty=oneline | grep "Merge remote-tracking branch " | wc -l)
+ )
+'
+
test_done
index 14a23cd8726fbb33df480133ed0466177916b7fb..ace8e54e9b374688751cc470eeb9003ca7f5c48f 100755 (executable)
# -- C1 --
#
test_expect_success 'squash F1 into D1' '
- FAKE_LINES="1 squash 3 2" git rebase -i -p B1 &&
+ FAKE_LINES="1 squash 4 2 3" git rebase -i -p B1 &&
test "$(git rev-parse HEAD^2)" = "$(git rev-parse C1)" &&
test "$(git rev-parse HEAD~2)" = "$(git rev-parse B1)" &&
git tag E2