Stephen Haberman <stephen@xxxxxxxxxxxxxxxx> writes: > +# set up two branches like this: > +# > +# A1 - B1 - D1 - E1 - F1 > +# \ / > +# -- C1 -- > ... > +test_expect_success 'setup' ' > ... > +' > + > +# Should result in: > +# > +# A1 - B1 - D2 - E2 > +# \ / > +# -- C1 -- > +# > +test_expect_success 'squash F1 into D1' ' > + FAKE_LINES="1 squash 3 2" git rebase -i -p B1 && > + test "$(git rev-parse HEAD^2)" = "$(git rev-parse branch)" && > + test "$(git rev-parse HEAD~2)" = "$(git rev-parse B1)" && > + git tag E2 > +' Very nicely written test sequence with pictures. I wish all the tests were written like this. > +# Start with: > +# > +# A1 - B1 - D2 - E2 > +# \ > +# G1 ---- L1 ---- M1 > +# \ / > +# H1 -- J1 -- K1 > +# \ / > +# -- I1 -- > +# > +# And rebase G1..M1 onto E3 I think s/E3/E2/ is what you meant. If this is the first one in the series, you may want to mark these tests with test_expect_failure and make a later patch that changes the behaviour of rebase-i-p include updates to the test script to turn expect-failure into expect-success. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
