mirrors/git
0
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-12-27 10:44:37 +08:00
Code Issues Packages Projects Releases Wiki Activity
a34edae68a
git/t/t3432-rebase-fast-forward.sh

142 lines
5.0 KiB
Bash
Raw Normal View History

t3432: test rebase fast-forward behavior When rebase is run on a branch that can be fast-forwarded, this should automatically be done. Create test to ensure this behavior happens. There are some cases that currently don't pass. The first case is where a feature and master have diverged, running "git rebase master... master" causes a full rebase to happen even though a fast-forward should happen. The second case is when we are doing "git rebase --fork-point" and a fork-point commit is found. Once again, a full rebase happens even though a fast-forward should happen. Mark these cases as failure so we can fix it later. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:00 +08:00
#!/bin/sh
#
# Copyright (c) 2019 Denton Liu
#
test_description='ensure rebase fast-forwards commits when possible'
t34*: adjust the references to the default branch name "main" Carefully excluding t3404, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t34*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t34*.sh && git checkout HEAD -- t34\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:25 +08:00
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
tests: mark tests relying on the current default for `init.defaultBranch` In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:19 +08:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
t3432: test rebase fast-forward behavior When rebase is run on a branch that can be fast-forwarded, this should automatically be done. Create test to ensure this behavior happens. There are some cases that currently don't pass. The first case is where a feature and master have diverged, running "git rebase master... master" causes a full rebase to happen even though a fast-forward should happen. The second case is when we are doing "git rebase --fork-point" and a fork-point commit is found. Once again, a full rebase happens even though a fast-forward should happen. Mark these cases as failure so we can fix it later. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:00 +08:00
. ./test-lib.sh
test_expect_success setup '
test_commit A &&
test_commit B &&
test_commit C &&
test_commit D &&
git checkout -t -b side
'
test_rebase_same_head () {
t3432: test for --no-ff's interaction with fast-forward Add more stress tests for the can_fast_forward() case in rebase.c. These tests are getting rather verbose, but now we can see under --ff and --no-ff whether we skip work, or whether we're forced to run the rebase. These tests aren't supposed to endorse the status quo, just test for what we're currently doing. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27 13:37:53 +08:00
status_n="$1" &&
shift &&
what_n="$1" &&
shift &&
cmp_n="$1" &&
shift &&
status_f="$1" &&
shift &&
what_f="$1" &&
shift &&
cmp_f="$1" &&
shift &&
t3432: test `--merge' with `rebase.abbreviateCommands = true', too When fast forwarding, `git --merge' should act the same whether `rebase.abbreviateCommands' is set or not, but so far it was not the case. This duplicates the tests ensuring that `--merge' works when fast forwarding to check if it also works with abbreviated commands. Signed-off-by: Alban Gruin <alban.gruin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-30 20:42:36 +08:00
test_rebase_same_head_ $status_n $what_n $cmp_n 0 " --apply" "$*" &&
test_rebase_same_head_ $status_f $what_f $cmp_f 0 " --apply --no-ff" "$*"
test_rebase_same_head_ $status_n $what_n $cmp_n 0 " --merge" "$*" &&
test_rebase_same_head_ $status_f $what_f $cmp_f 0 " --merge --no-ff" "$*"
test_rebase_same_head_ $status_n $what_n $cmp_n 1 " --merge" "$*" &&
test_rebase_same_head_ $status_f $what_f $cmp_f 1 " --merge --no-ff" "$*"
t3432: test for --no-ff's interaction with fast-forward Add more stress tests for the can_fast_forward() case in rebase.c. These tests are getting rather verbose, but now we can see under --ff and --no-ff whether we skip work, or whether we're forced to run the rebase. These tests aren't supposed to endorse the status quo, just test for what we're currently doing. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27 13:37:53 +08:00
}
test_rebase_same_head_ () {
t3432: test rebase fast-forward behavior When rebase is run on a branch that can be fast-forwarded, this should automatically be done. Create test to ensure this behavior happens. There are some cases that currently don't pass. The first case is where a feature and master have diverged, running "git rebase master... master" causes a full rebase to happen even though a fast-forward should happen. The second case is when we are doing "git rebase --fork-point" and a fork-point commit is found. Once again, a full rebase happens even though a fast-forward should happen. Mark these cases as failure so we can fix it later. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:00 +08:00
status="$1" &&
shift &&
t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests Change "same head" introduced in the preceding commit to check whether the rebase.c code lands in the can_fast_forward() case in, and thus prints out an "is up to date" and aborts early. In some of these cases we make it past that and to "rewinding head", then do a rebase, only to find out there's nothing to change so HEAD stays at the same OID. These tests presumed these two cases were the same thing. In terms of where HEAD ends up they are, but we're not only interested in rebase semantics, but also whether or not we're needlessly doing work when we could avoid it entirely. I'm adding "same" and "diff" here because I'll follow-up and add --no-ff tests, where some of those will be "diff"-erent, so add the "diff" code already. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:02 +08:00
what="$1" &&
shift &&
cmp="$1" &&
shift &&
t3432: test `--merge' with `rebase.abbreviateCommands = true', too When fast forwarding, `git --merge' should act the same whether `rebase.abbreviateCommands' is set or not, but so far it was not the case. This duplicates the tests ensuring that `--merge' works when fast forwarding to check if it also works with abbreviated commands. Signed-off-by: Alban Gruin <alban.gruin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-30 20:42:36 +08:00
abbreviate="$1" &&
shift &&
t3432: test for --no-ff's interaction with fast-forward Add more stress tests for the can_fast_forward() case in rebase.c. These tests are getting rather verbose, but now we can see under --ff and --no-ff whether we skip work, or whether we're forced to run the rebase. These tests aren't supposed to endorse the status quo, just test for what we're currently doing. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27 13:37:53 +08:00
flag="$1"
shift &&
t3432: test `--merge' with `rebase.abbreviateCommands = true', too When fast forwarding, `git --merge' should act the same whether `rebase.abbreviateCommands' is set or not, but so far it was not the case. This duplicates the tests ensuring that `--merge' works when fast forwarding to check if it also works with abbreviated commands. Signed-off-by: Alban Gruin <alban.gruin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-30 20:42:36 +08:00
if test $abbreviate -eq 1
then
msg="git rebase$flag $* (rebase.abbreviateCommands = true) with $changes is $what with $cmp HEAD"
else
msg="git rebase$flag $* with $changes is $what with $cmp HEAD"
fi &&
test_expect_$status "$msg" "
if test $abbreviate -eq 1
then
test_config rebase.abbreviateCommands true
fi &&
t3432: test rebase fast-forward behavior When rebase is run on a branch that can be fast-forwarded, this should automatically be done. Create test to ensure this behavior happens. There are some cases that currently don't pass. The first case is where a feature and master have diverged, running "git rebase master... master" causes a full rebase to happen even though a fast-forward should happen. The second case is when we are doing "git rebase --fork-point" and a fork-point commit is found. Once again, a full rebase happens even though a fast-forward should happen. Mark these cases as failure so we can fix it later. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:00 +08:00
oldhead=\$(git rev-parse HEAD) &&
test_when_finished 'git reset --hard \$oldhead' &&
t3432: use git-reflog to inspect the reflog for HEAD Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-11 01:19:51 +08:00
git reflog HEAD >expect &&
t3432: test for --no-ff's interaction with fast-forward Add more stress tests for the can_fast_forward() case in rebase.c. These tests are getting rather verbose, but now we can see under --ff and --no-ff whether we skip work, or whether we're forced to run the rebase. These tests aren't supposed to endorse the status quo, just test for what we're currently doing. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27 13:37:53 +08:00
git rebase$flag $* >stdout &&
t3432: use git-reflog to inspect the reflog for HEAD Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-11 01:19:51 +08:00
git reflog HEAD >actual &&
t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests Change "same head" introduced in the preceding commit to check whether the rebase.c code lands in the can_fast_forward() case in, and thus prints out an "is up to date" and aborts early. In some of these cases we make it past that and to "rewinding head", then do a rebase, only to find out there's nothing to change so HEAD stays at the same OID. These tests presumed these two cases were the same thing. In terms of where HEAD ends up they are, but we're not only interested in rebase semantics, but also whether or not we're needlessly doing work when we could avoid it entirely. I'm adding "same" and "diff" here because I'll follow-up and add --no-ff tests, where some of those will be "diff"-erent, so add the "diff" code already. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:02 +08:00
if test $what = work
then
t3432: make these tests work with either am or merge backends t3432 had several stress tests for can_fast_forward(), whose intent was to ensure we were using the optimization of just fast forwarding when possible. However, these tests verified that fast forwards had happened based on the output that rebase printed to the terminal. We can instead test more directly that we actually fast-forwarded by checking the reflog, which also has the side effect of making the tests applicable for the merge/interactive backend. This change does lose the distinction between "noop" and "noop-force", but as stated in commit c9efc216830f ("t3432: test for --no-ff's interaction with fast-forward", 2019-08-27) which introduced that distinction: "These tests aren't supposed to endorse the status quo, just test for what we're currently doing.". This change does not actually run these tests with the merge/interactive backend; instead this is just a preparatory commit. A subsequent commit which fixes can_fast_forward() to work with that backend will then also change t3432 to add tests of that backend as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:30 +08:00
old=\$(wc -l <expect) &&
t3432: use git-reflog to inspect the reflog for HEAD Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-11 01:19:51 +08:00
test_line_count '-gt' \$old actual
t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests Change "same head" introduced in the preceding commit to check whether the rebase.c code lands in the can_fast_forward() case in, and thus prints out an "is up to date" and aborts early. In some of these cases we make it past that and to "rewinding head", then do a rebase, only to find out there's nothing to change so HEAD stays at the same OID. These tests presumed these two cases were the same thing. In terms of where HEAD ends up they are, but we're not only interested in rebase semantics, but also whether or not we're needlessly doing work when we could avoid it entirely. I'm adding "same" and "diff" here because I'll follow-up and add --no-ff tests, where some of those will be "diff"-erent, so add the "diff" code already. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:02 +08:00
elif test $what = noop
then
t3432: use git-reflog to inspect the reflog for HEAD Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-11 01:19:51 +08:00
test_cmp expect actual
t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests Change "same head" introduced in the preceding commit to check whether the rebase.c code lands in the can_fast_forward() case in, and thus prints out an "is up to date" and aborts early. In some of these cases we make it past that and to "rewinding head", then do a rebase, only to find out there's nothing to change so HEAD stays at the same OID. These tests presumed these two cases were the same thing. In terms of where HEAD ends up they are, but we're not only interested in rebase semantics, but also whether or not we're needlessly doing work when we could avoid it entirely. I'm adding "same" and "diff" here because I'll follow-up and add --no-ff tests, where some of those will be "diff"-erent, so add the "diff" code already. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:02 +08:00
fi &&
t3432: test rebase fast-forward behavior When rebase is run on a branch that can be fast-forwarded, this should automatically be done. Create test to ensure this behavior happens. There are some cases that currently don't pass. The first case is where a feature and master have diverged, running "git rebase master... master" causes a full rebase to happen even though a fast-forward should happen. The second case is when we are doing "git rebase --fork-point" and a fork-point commit is found. Once again, a full rebase happens even though a fast-forward should happen. Mark these cases as failure so we can fix it later. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:00 +08:00
newhead=\$(git rev-parse HEAD) &&
t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests Change "same head" introduced in the preceding commit to check whether the rebase.c code lands in the can_fast_forward() case in, and thus prints out an "is up to date" and aborts early. In some of these cases we make it past that and to "rewinding head", then do a rebase, only to find out there's nothing to change so HEAD stays at the same OID. These tests presumed these two cases were the same thing. In terms of where HEAD ends up they are, but we're not only interested in rebase semantics, but also whether or not we're needlessly doing work when we could avoid it entirely. I'm adding "same" and "diff" here because I'll follow-up and add --no-ff tests, where some of those will be "diff"-erent, so add the "diff" code already. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:02 +08:00
if test $cmp = same
then
test_cmp_rev \$oldhead \$newhead
elif test $cmp = diff
then
t: teach test_cmp_rev to accept ! for not-equals In the case where we are using test_cmp_rev() to report not-equals, we write `! test_cmp_rev`. However, since test_cmp_rev() contains r1=$(git rev-parse --verify "$1") && r2=$(git rev-parse --verify "$2") && `! test_cmp_rev` will succeed if any of the rev-parses fail. This behavior is not desired. We want the rev-parses to _always_ be successful. Rewrite test_cmp_rev() to optionally accept "!" as the first argument to do a not-equals comparison. Rewrite `! test_cmp_rev` to `test_cmp_rev !` in all tests to take advantage of this new functionality. Also, rewrite the rev-parse logic to end with a `|| return 1` instead of &&-chaining into the rev-comparison logic. This makes it obvious to future readers that we explicitly intend on returning early if either of the rev-parses fail. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-13 07:07:45 +08:00
test_cmp_rev ! \$oldhead \$newhead
t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests Change "same head" introduced in the preceding commit to check whether the rebase.c code lands in the can_fast_forward() case in, and thus prints out an "is up to date" and aborts early. In some of these cases we make it past that and to "rewinding head", then do a rebase, only to find out there's nothing to change so HEAD stays at the same OID. These tests presumed these two cases were the same thing. In terms of where HEAD ends up they are, but we're not only interested in rebase semantics, but also whether or not we're needlessly doing work when we could avoid it entirely. I'm adding "same" and "diff" here because I'll follow-up and add --no-ff tests, where some of those will be "diff"-erent, so add the "diff" code already. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:02 +08:00
fi
t3432: test rebase fast-forward behavior When rebase is run on a branch that can be fast-forwarded, this should automatically be done. Create test to ensure this behavior happens. There are some cases that currently don't pass. The first case is where a feature and master have diverged, running "git rebase master... master" causes a full rebase to happen even though a fast-forward should happen. The second case is when we are doing "git rebase --fork-point" and a fork-point commit is found. Once again, a full rebase happens even though a fast-forward should happen. Mark these cases as failure so we can fix it later. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:00 +08:00
"
}
changes='no changes'
rebase: fast-forward --fork-point in more cases Before, when we rebased with a --fork-point invocation where the fork-point wasn't empty, we would be setting options.restrict_revision. The fast-forward logic would automatically declare that the rebase was not fast-forwardable if it was set. However, this was painting with a very broad brush. Refine the logic so that we can fast-forward in the case where the restricted revision is equal to the merge base, since we stop rebasing at the merge base anyway. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27 13:38:01 +08:00
test_rebase_same_head success noop same success work same
t34*: adjust the references to the default branch name "main" Carefully excluding t3404, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t34*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t34*.sh && git checkout HEAD -- t34\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:25 +08:00
test_rebase_same_head success noop same success work same main
t3432: make these tests work with either am or merge backends t3432 had several stress tests for can_fast_forward(), whose intent was to ensure we were using the optimization of just fast forwarding when possible. However, these tests verified that fast forwards had happened based on the output that rebase printed to the terminal. We can instead test more directly that we actually fast-forwarded by checking the reflog, which also has the side effect of making the tests applicable for the merge/interactive backend. This change does lose the distinction between "noop" and "noop-force", but as stated in commit c9efc216830f ("t3432: test for --no-ff's interaction with fast-forward", 2019-08-27) which introduced that distinction: "These tests aren't supposed to endorse the status quo, just test for what we're currently doing.". This change does not actually run these tests with the merge/interactive backend; instead this is just a preparatory commit. A subsequent commit which fixes can_fast_forward() to work with that backend will then also change t3432 to add tests of that backend as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:30 +08:00
test_rebase_same_head success noop same success work diff --onto B B
test_rebase_same_head success noop same success work diff --onto B... B
t34*: adjust the references to the default branch name "main" Carefully excluding t3404, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t34*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t34*.sh && git checkout HEAD -- t34\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:25 +08:00
test_rebase_same_head success noop same success work same --onto main... main
test_rebase_same_head success noop same success work same --keep-base main
t3432: make these tests work with either am or merge backends t3432 had several stress tests for can_fast_forward(), whose intent was to ensure we were using the optimization of just fast forwarding when possible. However, these tests verified that fast forwards had happened based on the output that rebase printed to the terminal. We can instead test more directly that we actually fast-forwarded by checking the reflog, which also has the side effect of making the tests applicable for the merge/interactive backend. This change does lose the distinction between "noop" and "noop-force", but as stated in commit c9efc216830f ("t3432: test for --no-ff's interaction with fast-forward", 2019-08-27) which introduced that distinction: "These tests aren't supposed to endorse the status quo, just test for what we're currently doing.". This change does not actually run these tests with the merge/interactive backend; instead this is just a preparatory commit. A subsequent commit which fixes can_fast_forward() to work with that backend will then also change t3432 to add tests of that backend as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:30 +08:00
test_rebase_same_head success noop same success work same --keep-base
test_rebase_same_head success noop same success work same --no-fork-point
test_rebase_same_head success noop same success work same --keep-base --no-fork-point
t34*: adjust the references to the default branch name "main" Carefully excluding t3404, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t34*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t34*.sh && git checkout HEAD -- t34\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:25 +08:00
test_rebase_same_head success noop same success work same --fork-point main
rebase: fast-forward --fork-point in more cases Before, when we rebased with a --fork-point invocation where the fork-point wasn't empty, we would be setting options.restrict_revision. The fast-forward logic would automatically declare that the rebase was not fast-forwardable if it was set. However, this was painting with a very broad brush. Refine the logic so that we can fast-forward in the case where the restricted revision is equal to the merge base, since we stop rebasing at the merge base anyway. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27 13:38:01 +08:00
test_rebase_same_head success noop same success work diff --fork-point --onto B B
test_rebase_same_head success noop same success work diff --fork-point --onto B... B
t34*: adjust the references to the default branch name "main" Carefully excluding t3404, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t34*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t34*.sh && git checkout HEAD -- t34\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:25 +08:00
test_rebase_same_head success noop same success work same --fork-point --onto main... main
test_rebase_same_head success noop same success work same --keep-base --keep-base main
t3432: test rebase fast-forward behavior When rebase is run on a branch that can be fast-forwarded, this should automatically be done. Create test to ensure this behavior happens. There are some cases that currently don't pass. The first case is where a feature and master have diverged, running "git rebase master... master" causes a full rebase to happen even though a fast-forward should happen. The second case is when we are doing "git rebase --fork-point" and a fork-point commit is found. Once again, a full rebase happens even though a fast-forward should happen. Mark these cases as failure so we can fix it later. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:00 +08:00
t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests Change "same head" introduced in the preceding commit to check whether the rebase.c code lands in the can_fast_forward() case in, and thus prints out an "is up to date" and aborts early. In some of these cases we make it past that and to "rewinding head", then do a rebase, only to find out there's nothing to change so HEAD stays at the same OID. These tests presumed these two cases were the same thing. In terms of where HEAD ends up they are, but we're not only interested in rebase semantics, but also whether or not we're needlessly doing work when we could avoid it entirely. I'm adding "same" and "diff" here because I'll follow-up and add --no-ff tests, where some of those will be "diff"-erent, so add the "diff" code already. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:02 +08:00
test_expect_success 'add work same to side' '
t3432: test rebase fast-forward behavior When rebase is run on a branch that can be fast-forwarded, this should automatically be done. Create test to ensure this behavior happens. There are some cases that currently don't pass. The first case is where a feature and master have diverged, running "git rebase master... master" causes a full rebase to happen even though a fast-forward should happen. The second case is when we are doing "git rebase --fork-point" and a fork-point commit is found. Once again, a full rebase happens even though a fast-forward should happen. Mark these cases as failure so we can fix it later. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:00 +08:00
test_commit E
'
changes='our changes'
rebase: fast-forward --fork-point in more cases Before, when we rebased with a --fork-point invocation where the fork-point wasn't empty, we would be setting options.restrict_revision. The fast-forward logic would automatically declare that the rebase was not fast-forwardable if it was set. However, this was painting with a very broad brush. Refine the logic so that we can fast-forward in the case where the restricted revision is equal to the merge base, since we stop rebasing at the merge base anyway. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27 13:38:01 +08:00
test_rebase_same_head success noop same success work same
t34*: adjust the references to the default branch name "main" Carefully excluding t3404, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t34*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t34*.sh && git checkout HEAD -- t34\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:25 +08:00
test_rebase_same_head success noop same success work same main
t3432: make these tests work with either am or merge backends t3432 had several stress tests for can_fast_forward(), whose intent was to ensure we were using the optimization of just fast forwarding when possible. However, these tests verified that fast forwards had happened based on the output that rebase printed to the terminal. We can instead test more directly that we actually fast-forwarded by checking the reflog, which also has the side effect of making the tests applicable for the merge/interactive backend. This change does lose the distinction between "noop" and "noop-force", but as stated in commit c9efc216830f ("t3432: test for --no-ff's interaction with fast-forward", 2019-08-27) which introduced that distinction: "These tests aren't supposed to endorse the status quo, just test for what we're currently doing.". This change does not actually run these tests with the merge/interactive backend; instead this is just a preparatory commit. A subsequent commit which fixes can_fast_forward() to work with that backend will then also change t3432 to add tests of that backend as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:30 +08:00
test_rebase_same_head success noop same success work diff --onto B B
test_rebase_same_head success noop same success work diff --onto B... B
t34*: adjust the references to the default branch name "main" Carefully excluding t3404, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t34*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t34*.sh && git checkout HEAD -- t34\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:25 +08:00
test_rebase_same_head success noop same success work same --onto main... main
test_rebase_same_head success noop same success work same --keep-base main
t3432: make these tests work with either am or merge backends t3432 had several stress tests for can_fast_forward(), whose intent was to ensure we were using the optimization of just fast forwarding when possible. However, these tests verified that fast forwards had happened based on the output that rebase printed to the terminal. We can instead test more directly that we actually fast-forwarded by checking the reflog, which also has the side effect of making the tests applicable for the merge/interactive backend. This change does lose the distinction between "noop" and "noop-force", but as stated in commit c9efc216830f ("t3432: test for --no-ff's interaction with fast-forward", 2019-08-27) which introduced that distinction: "These tests aren't supposed to endorse the status quo, just test for what we're currently doing.". This change does not actually run these tests with the merge/interactive backend; instead this is just a preparatory commit. A subsequent commit which fixes can_fast_forward() to work with that backend will then also change t3432 to add tests of that backend as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:30 +08:00
test_rebase_same_head success noop same success work same --keep-base
test_rebase_same_head success noop same success work same --no-fork-point
test_rebase_same_head success noop same success work same --keep-base --no-fork-point
t34*: adjust the references to the default branch name "main" Carefully excluding t3404, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t34*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t34*.sh && git checkout HEAD -- t34\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:25 +08:00
test_rebase_same_head success noop same success work same --fork-point main
rebase: fast-forward --fork-point in more cases Before, when we rebased with a --fork-point invocation where the fork-point wasn't empty, we would be setting options.restrict_revision. The fast-forward logic would automatically declare that the rebase was not fast-forwardable if it was set. However, this was painting with a very broad brush. Refine the logic so that we can fast-forward in the case where the restricted revision is equal to the merge base, since we stop rebasing at the merge base anyway. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27 13:38:01 +08:00
test_rebase_same_head success noop same success work diff --fork-point --onto B B
test_rebase_same_head success noop same success work diff --fork-point --onto B... B
t34*: adjust the references to the default branch name "main" Carefully excluding t3404, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t34*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t34*.sh && git checkout HEAD -- t34\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:25 +08:00
test_rebase_same_head success noop same success work same --fork-point --onto main... main
test_rebase_same_head success noop same success work same --fork-point --keep-base main
t3432: test rebase fast-forward behavior When rebase is run on a branch that can be fast-forwarded, this should automatically be done. Create test to ensure this behavior happens. There are some cases that currently don't pass. The first case is where a feature and master have diverged, running "git rebase master... master" causes a full rebase to happen even though a fast-forward should happen. The second case is when we are doing "git rebase --fork-point" and a fork-point commit is found. Once again, a full rebase happens even though a fast-forward should happen. Mark these cases as failure so we can fix it later. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:00 +08:00
t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests Change "same head" introduced in the preceding commit to check whether the rebase.c code lands in the can_fast_forward() case in, and thus prints out an "is up to date" and aborts early. In some of these cases we make it past that and to "rewinding head", then do a rebase, only to find out there's nothing to change so HEAD stays at the same OID. These tests presumed these two cases were the same thing. In terms of where HEAD ends up they are, but we're not only interested in rebase semantics, but also whether or not we're needlessly doing work when we could avoid it entirely. I'm adding "same" and "diff" here because I'll follow-up and add --no-ff tests, where some of those will be "diff"-erent, so add the "diff" code already. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:02 +08:00
test_expect_success 'add work same to upstream' '
t34*: adjust the references to the default branch name "main" Carefully excluding t3404, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t34*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t34*.sh && git checkout HEAD -- t34\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:25 +08:00
git checkout main &&
t3432: test rebase fast-forward behavior When rebase is run on a branch that can be fast-forwarded, this should automatically be done. Create test to ensure this behavior happens. There are some cases that currently don't pass. The first case is where a feature and master have diverged, running "git rebase master... master" causes a full rebase to happen even though a fast-forward should happen. The second case is when we are doing "git rebase --fork-point" and a fork-point commit is found. Once again, a full rebase happens even though a fast-forward should happen. Mark these cases as failure so we can fix it later. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:00 +08:00
test_commit F &&
git checkout side
'
changes='our and their changes'
t3432: make these tests work with either am or merge backends t3432 had several stress tests for can_fast_forward(), whose intent was to ensure we were using the optimization of just fast forwarding when possible. However, these tests verified that fast forwards had happened based on the output that rebase printed to the terminal. We can instead test more directly that we actually fast-forwarded by checking the reflog, which also has the side effect of making the tests applicable for the merge/interactive backend. This change does lose the distinction between "noop" and "noop-force", but as stated in commit c9efc216830f ("t3432: test for --no-ff's interaction with fast-forward", 2019-08-27) which introduced that distinction: "These tests aren't supposed to endorse the status quo, just test for what we're currently doing.". This change does not actually run these tests with the merge/interactive backend; instead this is just a preparatory commit. A subsequent commit which fixes can_fast_forward() to work with that backend will then also change t3432 to add tests of that backend as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:30 +08:00
test_rebase_same_head success noop same success work diff --onto B B
test_rebase_same_head success noop same success work diff --onto B... B
t34*: adjust the references to the default branch name "main" Carefully excluding t3404, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t34*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t34*.sh && git checkout HEAD -- t34\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:25 +08:00
test_rebase_same_head success noop same success work diff --onto main... main
test_rebase_same_head success noop same success work diff --keep-base main
rebase: teach rebase --keep-base A common scenario is if a user is working on a topic branch and they wish to make some changes to intermediate commits or autosquash, they would run something such as git rebase -i --onto master... master in order to preserve the merge base. This is useful when contributing a patch series to the Git mailing list, one often starts on top of the current 'master'. While developing the patches, 'master' is also developed further and it is sometimes not the best idea to keep rebasing on top of 'master', but to keep the base commit as-is. In addition to this, a user wishing to test individual commits in a topic branch without changing anything may run git rebase -x ./test.sh master... master Since rebasing onto the merge base of the branch and the upstream is such a common case, introduce the --keep-base option as a shortcut. This allows us to rewrite the above as git rebase -i --keep-base master and git rebase -x ./test.sh --keep-base master respectively. Add tests to ensure --keep-base works correctly in the normal case and fails when there are multiple merge bases, both in regular and interactive mode. Also, test to make sure conflicting options cause rebase to fail. While we're adding test cases, add a missing set_fake_editor call to 'rebase -i --onto master...side'. While we're documenting the --keep-base option, change an instance of "merge-base" to "merge base", which is the consistent spelling. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27 13:38:06 +08:00
test_rebase_same_head success noop same success work diff --keep-base
t3432: test for --no-ff's interaction with fast-forward Add more stress tests for the can_fast_forward() case in rebase.c. These tests are getting rather verbose, but now we can see under --ff and --no-ff whether we skip work, or whether we're forced to run the rebase. These tests aren't supposed to endorse the status quo, just test for what we're currently doing. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27 13:37:53 +08:00
test_rebase_same_head failure work same success work diff --fork-point --onto B B
test_rebase_same_head failure work same success work diff --fork-point --onto B... B
t34*: adjust the references to the default branch name "main" Carefully excluding t3404, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t34*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t34*.sh && git checkout HEAD -- t34\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 07:44:25 +08:00
test_rebase_same_head success noop same success work diff --fork-point --onto main... main
test_rebase_same_head success noop same success work diff --fork-point --keep-base main
t3432: test rebase fast-forward behavior When rebase is run on a branch that can be fast-forwarded, this should automatically be done. Create test to ensure this behavior happens. There are some cases that currently don't pass. The first case is where a feature and master have diverged, running "git rebase master... master" causes a full rebase to happen even though a fast-forward should happen. The second case is when we are doing "git rebase --fork-point" and a fork-point commit is found. Once again, a full rebase happens even though a fast-forward should happen. Mark these cases as failure so we can fix it later. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-25 17:12:00 +08:00
test_done
Reference in New Issue Copy Permalink