2013-06-07 14:11:37 +08:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='basic rebase topology tests'
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
. "$TEST_DIRECTORY"/lib-rebase.sh
|
|
|
|
|
|
|
|
|
|
# a---b---c
|
|
|
|
|
# \
|
|
|
|
|
# d---e
|
|
|
|
|
test_expect_success 'setup' '
|
|
|
|
|
test_commit a &&
|
|
|
|
|
test_commit b &&
|
|
|
|
|
test_commit c &&
|
|
|
|
|
git checkout b &&
|
|
|
|
|
test_commit d &&
|
|
|
|
|
test_commit e
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "simple rebase $*" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* c e &&
|
|
|
|
|
test_cmp_rev c HEAD~2 &&
|
|
|
|
|
test_linear_range 'd e' c..
|
|
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
2013-06-07 14:11:37 +08:00
|
|
|
test_run_rebase success -m
|
|
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
2013-06-07 14:11:37 +08:00
|
|
|
|
2019-08-27 13:38:04 +08:00
|
|
|
test_expect_success 'setup branches and remote tracking' '
|
|
|
|
|
git tag -l >tags &&
|
|
|
|
|
for tag in $(cat tags)
|
|
|
|
|
do
|
|
|
|
|
git branch branch-$tag $tag || return 1
|
|
|
|
|
done &&
|
|
|
|
|
git remote add origin "file://$PWD" &&
|
|
|
|
|
git fetch origin
|
|
|
|
|
'
|
|
|
|
|
|
2013-06-07 14:11:37 +08:00
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* is no-op if upstream is an ancestor" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* b e &&
|
|
|
|
|
test_cmp_rev e HEAD
|
|
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
2013-06-07 14:11:37 +08:00
|
|
|
test_run_rebase success -m
|
|
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
2013-06-07 14:11:37 +08:00
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* -f rewrites even if upstream is an ancestor" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* -f b e &&
|
2019-11-13 07:07:45 +08:00
|
|
|
test_cmp_rev ! e HEAD &&
|
2013-06-07 14:11:37 +08:00
|
|
|
test_cmp_rev b HEAD~2 &&
|
|
|
|
|
test_linear_range 'd e' b..
|
|
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
2019-08-27 13:38:04 +08:00
|
|
|
test_run_rebase success --fork-point
|
2013-06-07 14:11:37 +08:00
|
|
|
test_run_rebase success -m
|
|
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase failure -p
|
2013-06-07 14:11:37 +08:00
|
|
|
|
2019-08-27 13:38:04 +08:00
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* -f rewrites even if remote upstream is an ancestor" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* -f branch-b branch-e &&
|
2019-11-13 07:07:45 +08:00
|
|
|
test_cmp_rev ! branch-e origin/branch-e &&
|
2019-08-27 13:38:04 +08:00
|
|
|
test_cmp_rev branch-b HEAD~2 &&
|
|
|
|
|
test_linear_range 'd e' branch-b..
|
|
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
2019-08-27 13:38:04 +08:00
|
|
|
test_run_rebase success --fork-point
|
|
|
|
|
test_run_rebase success -m
|
|
|
|
|
test_run_rebase success -i
|
|
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
|
|
|
|
|
2013-06-07 14:11:37 +08:00
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* fast-forwards from ancestor of upstream" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* e b &&
|
|
|
|
|
test_cmp_rev e HEAD
|
|
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
2019-08-27 13:38:04 +08:00
|
|
|
test_run_rebase success --fork-point
|
2013-06-07 14:11:37 +08:00
|
|
|
test_run_rebase success -m
|
|
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
2013-06-07 14:11:37 +08:00
|
|
|
|
2013-06-07 14:11:38 +08:00
|
|
|
# f
|
|
|
|
|
# /
|
|
|
|
|
# a---b---c---g---h
|
|
|
|
|
# \
|
2013-06-18 15:28:07 +08:00
|
|
|
# d---gp--i
|
2013-06-07 14:11:38 +08:00
|
|
|
#
|
2013-06-18 15:28:07 +08:00
|
|
|
# gp = cherry-picked g
|
2013-06-07 14:11:38 +08:00
|
|
|
# h = reverted g
|
|
|
|
|
#
|
|
|
|
|
# Reverted patches are there for tests to be able to check if a commit
|
|
|
|
|
# that introduced the same change as another commit is
|
|
|
|
|
# dropped. Without reverted commits, we could get false positives
|
|
|
|
|
# because applying the patch succeeds, but simply results in no
|
|
|
|
|
# changes.
|
|
|
|
|
test_expect_success 'setup of linear history for range selection tests' '
|
|
|
|
|
git checkout c &&
|
|
|
|
|
test_commit g &&
|
|
|
|
|
revert h g &&
|
|
|
|
|
git checkout d &&
|
2013-06-18 15:28:07 +08:00
|
|
|
cherry_pick gp g &&
|
2013-06-07 14:11:38 +08:00
|
|
|
test_commit i &&
|
|
|
|
|
git checkout b &&
|
|
|
|
|
test_commit f
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* drops patches in upstream" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* h i &&
|
|
|
|
|
test_cmp_rev h HEAD~2 &&
|
|
|
|
|
test_linear_range 'd i' h..
|
|
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
rebase: implement --merge via the interactive machinery
As part of an ongoing effort to make rebase have more uniform behavior,
modify the merge backend to behave like the interactive one, by
re-implementing it on top of the latter.
Interactive rebases are implemented in terms of cherry-pick rather than
the merge-recursive builtin, but cherry-pick also calls into the
recursive merge machinery by default and can accept special merge
strategies and/or special strategy options. As such, there really is
not any need for having both git-rebase--merge and
git-rebase--interactive anymore. Delete git-rebase--merge.sh and
instead implement it in builtin/rebase.c.
This results in a few deliberate but small user-visible changes:
* The progress output is modified (see t3406 and t3420 for examples)
* A few known test failures are now fixed (see t3421)
* bash-prompt during a rebase --merge is now REBASE-i instead of
REBASE-m. Reason: The prompt is a reflection of the backend in use;
this allows users to report an issue to the git mailing list with
the appropriate backend information, and allows advanced users to
know where to search for relevant control files. (see t9903)
testcase modification notes:
t3406: --interactive and --merge had slightly different progress output
while running; adjust a test to match the new expectation
t3420: these test precise output while running, but rebase--am,
rebase--merge, and rebase--interactive all were built on very
different commands (am, merge-recursive, cherry-pick), so the
tests expected different output for each type. Now we expect
--merge and --interactive to have the same output.
t3421: --interactive fixes some bugs in --merge! Wahoo!
t9903: --merge uses the interactive backend so the prompt expected is
now REBASE-i.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-12 00:11:39 +08:00
|
|
|
test_run_rebase success -m
|
2013-06-07 14:11:38 +08:00
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
2013-06-07 14:11:38 +08:00
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* can drop last patch if in upstream" "
|
|
|
|
|
reset_rebase &&
|
2013-06-18 15:28:07 +08:00
|
|
|
git rebase $* h gp &&
|
2013-06-07 14:11:38 +08:00
|
|
|
test_cmp_rev h HEAD^ &&
|
|
|
|
|
test_linear_range 'd' h..
|
|
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
rebase: implement --merge via the interactive machinery
As part of an ongoing effort to make rebase have more uniform behavior,
modify the merge backend to behave like the interactive one, by
re-implementing it on top of the latter.
Interactive rebases are implemented in terms of cherry-pick rather than
the merge-recursive builtin, but cherry-pick also calls into the
recursive merge machinery by default and can accept special merge
strategies and/or special strategy options. As such, there really is
not any need for having both git-rebase--merge and
git-rebase--interactive anymore. Delete git-rebase--merge.sh and
instead implement it in builtin/rebase.c.
This results in a few deliberate but small user-visible changes:
* The progress output is modified (see t3406 and t3420 for examples)
* A few known test failures are now fixed (see t3421)
* bash-prompt during a rebase --merge is now REBASE-i instead of
REBASE-m. Reason: The prompt is a reflection of the backend in use;
this allows users to report an issue to the git mailing list with
the appropriate backend information, and allows advanced users to
know where to search for relevant control files. (see t9903)
testcase modification notes:
t3406: --interactive and --merge had slightly different progress output
while running; adjust a test to match the new expectation
t3420: these test precise output while running, but rebase--am,
rebase--merge, and rebase--interactive all were built on very
different commands (am, merge-recursive, cherry-pick), so the
tests expected different output for each type. Now we expect
--merge and --interactive to have the same output.
t3421: --interactive fixes some bugs in --merge! Wahoo!
t9903: --merge uses the interactive backend so the prompt expected is
now REBASE-i.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-12 00:11:39 +08:00
|
|
|
test_run_rebase success -m
|
2013-06-07 14:11:38 +08:00
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
2013-06-07 14:11:38 +08:00
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* --onto drops patches in upstream" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* --onto f h i &&
|
|
|
|
|
test_cmp_rev f HEAD~2 &&
|
|
|
|
|
test_linear_range 'd i' f..
|
|
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
rebase: implement --merge via the interactive machinery
As part of an ongoing effort to make rebase have more uniform behavior,
modify the merge backend to behave like the interactive one, by
re-implementing it on top of the latter.
Interactive rebases are implemented in terms of cherry-pick rather than
the merge-recursive builtin, but cherry-pick also calls into the
recursive merge machinery by default and can accept special merge
strategies and/or special strategy options. As such, there really is
not any need for having both git-rebase--merge and
git-rebase--interactive anymore. Delete git-rebase--merge.sh and
instead implement it in builtin/rebase.c.
This results in a few deliberate but small user-visible changes:
* The progress output is modified (see t3406 and t3420 for examples)
* A few known test failures are now fixed (see t3421)
* bash-prompt during a rebase --merge is now REBASE-i instead of
REBASE-m. Reason: The prompt is a reflection of the backend in use;
this allows users to report an issue to the git mailing list with
the appropriate backend information, and allows advanced users to
know where to search for relevant control files. (see t9903)
testcase modification notes:
t3406: --interactive and --merge had slightly different progress output
while running; adjust a test to match the new expectation
t3420: these test precise output while running, but rebase--am,
rebase--merge, and rebase--interactive all were built on very
different commands (am, merge-recursive, cherry-pick), so the
tests expected different output for each type. Now we expect
--merge and --interactive to have the same output.
t3421: --interactive fixes some bugs in --merge! Wahoo!
t9903: --merge uses the interactive backend so the prompt expected is
now REBASE-i.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-12 00:11:39 +08:00
|
|
|
test_run_rebase success -m
|
2013-06-07 14:11:38 +08:00
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
2013-06-07 14:11:38 +08:00
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* --onto does not drop patches in onto" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* --onto h f i &&
|
|
|
|
|
test_cmp_rev h HEAD~3 &&
|
2013-06-18 15:28:07 +08:00
|
|
|
test_linear_range 'd gp i' h..
|
2013-06-07 14:11:38 +08:00
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
2013-06-07 14:11:38 +08:00
|
|
|
test_run_rebase success -m
|
|
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
2013-06-07 14:11:38 +08:00
|
|
|
|
2013-06-07 14:11:39 +08:00
|
|
|
# a---b---c---j!
|
|
|
|
|
# \
|
|
|
|
|
# d---k!--l
|
|
|
|
|
#
|
|
|
|
|
# ! = empty
|
|
|
|
|
test_expect_success 'setup of linear history for empty commit tests' '
|
|
|
|
|
git checkout c &&
|
|
|
|
|
make_empty j &&
|
|
|
|
|
git checkout d &&
|
|
|
|
|
make_empty k &&
|
|
|
|
|
test_commit l
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
rebase (interactive-backend): make --keep-empty the default
Different rebase backends have different treatment for commits which
start empty (i.e. have no changes relative to their parent), and the
--keep-empty option was added at some point to allow adjusting behavior.
The handling of commits which start empty is actually quite similar to
commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default,
2018-06-27), which pointed out that the behavior for various backends is
often more happenstance than design. The specific change made in that
commit is actually quite relevant as well and much of the logic there
directly applies here.
It makes a lot of sense in 'git commit' to error out on the creation of
empty commits, unless an override flag is provided. However, once
someone determines that there is a rare case that merits using the
manual override to create such a commit, it is somewhere between
annoying and harmful to have to take extra steps to keep such
intentional commits around. Granted, empty commits are quite rare,
which is why handling of them doesn't get considered much and folks tend
to defer to existing (accidental) behavior and assume there was a reason
for it, leading them to just add flags (--keep-empty in this case) that
allow them to override the bad defaults. Fix the interactive backend so
that --keep-empty is the default, much like we did with
--allow-empty-message. The am backend should also be fixed to have
--keep-empty semantics for commits that start empty, but that is not
included in this patch other than a testcase documenting the failure.
Note that there was one test in t3421 which appears to have been written
expecting --keep-empty to not be the default as correct behavior. This
test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of
empty commits", 2013-06-06), which was part of a series focusing on
rebase topology and which had an interesting original cover letter at
https://lore.kernel.org/git/1347949878-12578-1-git-send-email-martinvonz@gmail.com/
which noted
Your input especially appreciated on whether you agree with the
intent of the test cases.
and then went into a long example about how one of the many tests added
had several questions about whether it was correct. As such, I believe
most the tests in that series were about testing rebase topology with as
many different flags as possible and were not trying to state in general
how those flags should behave otherwise.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:24 +08:00
|
|
|
test_expect_$result "rebase $* keeps begin-empty commits" "
|
2013-06-07 14:11:39 +08:00
|
|
|
reset_rebase &&
|
rebase (interactive-backend): make --keep-empty the default
Different rebase backends have different treatment for commits which
start empty (i.e. have no changes relative to their parent), and the
--keep-empty option was added at some point to allow adjusting behavior.
The handling of commits which start empty is actually quite similar to
commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default,
2018-06-27), which pointed out that the behavior for various backends is
often more happenstance than design. The specific change made in that
commit is actually quite relevant as well and much of the logic there
directly applies here.
It makes a lot of sense in 'git commit' to error out on the creation of
empty commits, unless an override flag is provided. However, once
someone determines that there is a rare case that merits using the
manual override to create such a commit, it is somewhere between
annoying and harmful to have to take extra steps to keep such
intentional commits around. Granted, empty commits are quite rare,
which is why handling of them doesn't get considered much and folks tend
to defer to existing (accidental) behavior and assume there was a reason
for it, leading them to just add flags (--keep-empty in this case) that
allow them to override the bad defaults. Fix the interactive backend so
that --keep-empty is the default, much like we did with
--allow-empty-message. The am backend should also be fixed to have
--keep-empty semantics for commits that start empty, but that is not
included in this patch other than a testcase documenting the failure.
Note that there was one test in t3421 which appears to have been written
expecting --keep-empty to not be the default as correct behavior. This
test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of
empty commits", 2013-06-06), which was part of a series focusing on
rebase topology and which had an interesting original cover letter at
https://lore.kernel.org/git/1347949878-12578-1-git-send-email-martinvonz@gmail.com/
which noted
Your input especially appreciated on whether you agree with the
intent of the test cases.
and then went into a long example about how one of the many tests added
had several questions about whether it was correct. As such, I believe
most the tests in that series were about testing rebase topology with as
many different flags as possible and were not trying to state in general
how those flags should behave otherwise.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:24 +08:00
|
|
|
git rebase $* j l &&
|
|
|
|
|
test_cmp_rev c HEAD~4 &&
|
|
|
|
|
test_linear_range 'j d k l' c..
|
2013-06-07 14:11:39 +08:00
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase failure --apply
|
2013-06-07 14:11:39 +08:00
|
|
|
test_run_rebase success -m
|
|
|
|
|
test_run_rebase success -i
|
rebase (interactive-backend): make --keep-empty the default
Different rebase backends have different treatment for commits which
start empty (i.e. have no changes relative to their parent), and the
--keep-empty option was added at some point to allow adjusting behavior.
The handling of commits which start empty is actually quite similar to
commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default,
2018-06-27), which pointed out that the behavior for various backends is
often more happenstance than design. The specific change made in that
commit is actually quite relevant as well and much of the logic there
directly applies here.
It makes a lot of sense in 'git commit' to error out on the creation of
empty commits, unless an override flag is provided. However, once
someone determines that there is a rare case that merits using the
manual override to create such a commit, it is somewhere between
annoying and harmful to have to take extra steps to keep such
intentional commits around. Granted, empty commits are quite rare,
which is why handling of them doesn't get considered much and folks tend
to defer to existing (accidental) behavior and assume there was a reason
for it, leading them to just add flags (--keep-empty in this case) that
allow them to override the bad defaults. Fix the interactive backend so
that --keep-empty is the default, much like we did with
--allow-empty-message. The am backend should also be fixed to have
--keep-empty semantics for commits that start empty, but that is not
included in this patch other than a testcase documenting the failure.
Note that there was one test in t3421 which appears to have been written
expecting --keep-empty to not be the default as correct behavior. This
test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of
empty commits", 2013-06-06), which was part of a series focusing on
rebase topology and which had an interesting original cover letter at
https://lore.kernel.org/git/1347949878-12578-1-git-send-email-martinvonz@gmail.com/
which noted
Your input especially appreciated on whether you agree with the
intent of the test cases.
and then went into a long example about how one of the many tests added
had several questions about whether it was correct. As such, I believe
most the tests in that series were about testing rebase topology with as
many different flags as possible and were not trying to state in general
how those flags should behave otherwise.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:24 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase failure -p
|
2013-06-07 14:11:39 +08:00
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
rebase: reinstate --no-keep-empty
Commit d48e5e21da ("rebase (interactive-backend): make --keep-empty the
default", 2020-02-15) turned --keep-empty (for keeping commits which
start empty) into the default. The logic underpinning that commit was:
1) 'git commit' errors out on the creation of empty commits without an
override flag
2) Once someone determines that the override is worthwhile, it's
annoying and/or harmful to required them to take extra steps in
order to keep such commits around (and to repeat such steps with
every rebase).
While the logic on which the decision was made is sound, the result was
a bit of an overcorrection. Instead of jumping to having --keep-empty
being the default, it jumped to making --keep-empty the only available
behavior. There was a simple workaround, though, which was thought to
be good enough at the time. People could still drop commits which
started empty the same way the could drop any commits: by firing up an
interactive rebase and picking out the commits they didn't want from the
list. However, there are cases where external tools might create enough
empty commits that picking all of them out is painful. As such, having
a flag to automatically remove start-empty commits may be beneficial.
Provide users a way to drop commits which start empty using a flag that
existed for years: --no-keep-empty. Interpret --keep-empty as
countermanding any previous --no-keep-empty, but otherwise leaving
--keep-empty as the default.
This might lead to some slight weirdness since commands like
git rebase --empty=drop --keep-empty
git rebase --empty=keep --no-keep-empty
look really weird despite making perfect sense (the first will drop
commits which become empty, but keep commits that started empty; the
second will keep commits which become empty, but drop commits which
started empty). However, --no-keep-empty was named years ago and we are
predominantly keeping it for backward compatibility; also we suspect it
will only be used rarely since folks already have a simple way to drop
commits they don't want with an interactive rebase.
Reported-by: Bryan Turner <bturner@atlassian.com>
Reported-by: Sami Boukortt <sami@boukortt.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-11 10:44:25 +08:00
|
|
|
test_expect_$result "rebase $* --no-keep-empty drops begin-empty commits" "
|
2013-06-07 14:11:39 +08:00
|
|
|
reset_rebase &&
|
rebase: reinstate --no-keep-empty
Commit d48e5e21da ("rebase (interactive-backend): make --keep-empty the
default", 2020-02-15) turned --keep-empty (for keeping commits which
start empty) into the default. The logic underpinning that commit was:
1) 'git commit' errors out on the creation of empty commits without an
override flag
2) Once someone determines that the override is worthwhile, it's
annoying and/or harmful to required them to take extra steps in
order to keep such commits around (and to repeat such steps with
every rebase).
While the logic on which the decision was made is sound, the result was
a bit of an overcorrection. Instead of jumping to having --keep-empty
being the default, it jumped to making --keep-empty the only available
behavior. There was a simple workaround, though, which was thought to
be good enough at the time. People could still drop commits which
started empty the same way the could drop any commits: by firing up an
interactive rebase and picking out the commits they didn't want from the
list. However, there are cases where external tools might create enough
empty commits that picking all of them out is painful. As such, having
a flag to automatically remove start-empty commits may be beneficial.
Provide users a way to drop commits which start empty using a flag that
existed for years: --no-keep-empty. Interpret --keep-empty as
countermanding any previous --no-keep-empty, but otherwise leaving
--keep-empty as the default.
This might lead to some slight weirdness since commands like
git rebase --empty=drop --keep-empty
git rebase --empty=keep --no-keep-empty
look really weird despite making perfect sense (the first will drop
commits which become empty, but keep commits that started empty; the
second will keep commits which become empty, but drop commits which
started empty). However, --no-keep-empty was named years ago and we are
predominantly keeping it for backward compatibility; also we suspect it
will only be used rarely since folks already have a simple way to drop
commits they don't want with an interactive rebase.
Reported-by: Bryan Turner <bturner@atlassian.com>
Reported-by: Sami Boukortt <sami@boukortt.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-11 10:44:25 +08:00
|
|
|
git rebase $* --no-keep-empty c l &&
|
|
|
|
|
test_cmp_rev c HEAD~2 &&
|
|
|
|
|
test_linear_range 'd l' c..
|
2013-06-07 14:11:39 +08:00
|
|
|
"
|
|
|
|
|
}
|
2018-03-20 19:10:57 +08:00
|
|
|
test_run_rebase success -m
|
2013-06-07 14:11:39 +08:00
|
|
|
test_run_rebase success -i
|
rebase (interactive-backend): make --keep-empty the default
Different rebase backends have different treatment for commits which
start empty (i.e. have no changes relative to their parent), and the
--keep-empty option was added at some point to allow adjusting behavior.
The handling of commits which start empty is actually quite similar to
commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default,
2018-06-27), which pointed out that the behavior for various backends is
often more happenstance than design. The specific change made in that
commit is actually quite relevant as well and much of the logic there
directly applies here.
It makes a lot of sense in 'git commit' to error out on the creation of
empty commits, unless an override flag is provided. However, once
someone determines that there is a rare case that merits using the
manual override to create such a commit, it is somewhere between
annoying and harmful to have to take extra steps to keep such
intentional commits around. Granted, empty commits are quite rare,
which is why handling of them doesn't get considered much and folks tend
to defer to existing (accidental) behavior and assume there was a reason
for it, leading them to just add flags (--keep-empty in this case) that
allow them to override the bad defaults. Fix the interactive backend so
that --keep-empty is the default, much like we did with
--allow-empty-message. The am backend should also be fixed to have
--keep-empty semantics for commits that start empty, but that is not
included in this patch other than a testcase documenting the failure.
Note that there was one test in t3421 which appears to have been written
expecting --keep-empty to not be the default as correct behavior. This
test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of
empty commits", 2013-06-06), which was part of a series focusing on
rebase topology and which had an interesting original cover letter at
https://lore.kernel.org/git/1347949878-12578-1-git-send-email-martinvonz@gmail.com/
which noted
Your input especially appreciated on whether you agree with the
intent of the test cases.
and then went into a long example about how one of the many tests added
had several questions about whether it was correct. As such, I believe
most the tests in that series were about testing rebase topology with as
many different flags as possible and were not trying to state in general
how those flags should behave otherwise.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:24 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
2013-06-07 14:11:39 +08:00
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* --keep-empty keeps empty even if already in upstream" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* --keep-empty j l &&
|
|
|
|
|
test_cmp_rev j HEAD~3 &&
|
|
|
|
|
test_linear_range 'd k l' j..
|
|
|
|
|
"
|
|
|
|
|
}
|
2018-03-20 19:10:57 +08:00
|
|
|
test_run_rebase success -m
|
2018-03-20 18:03:14 +08:00
|
|
|
test_run_rebase success -i
|
rebase (interactive-backend): make --keep-empty the default
Different rebase backends have different treatment for commits which
start empty (i.e. have no changes relative to their parent), and the
--keep-empty option was added at some point to allow adjusting behavior.
The handling of commits which start empty is actually quite similar to
commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default,
2018-06-27), which pointed out that the behavior for various backends is
often more happenstance than design. The specific change made in that
commit is actually quite relevant as well and much of the logic there
directly applies here.
It makes a lot of sense in 'git commit' to error out on the creation of
empty commits, unless an override flag is provided. However, once
someone determines that there is a rare case that merits using the
manual override to create such a commit, it is somewhere between
annoying and harmful to have to take extra steps to keep such
intentional commits around. Granted, empty commits are quite rare,
which is why handling of them doesn't get considered much and folks tend
to defer to existing (accidental) behavior and assume there was a reason
for it, leading them to just add flags (--keep-empty in this case) that
allow them to override the bad defaults. Fix the interactive backend so
that --keep-empty is the default, much like we did with
--allow-empty-message. The am backend should also be fixed to have
--keep-empty semantics for commits that start empty, but that is not
included in this patch other than a testcase documenting the failure.
Note that there was one test in t3421 which appears to have been written
expecting --keep-empty to not be the default as correct behavior. This
test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of
empty commits", 2013-06-06), which was part of a series focusing on
rebase topology and which had an interesting original cover letter at
https://lore.kernel.org/git/1347949878-12578-1-git-send-email-martinvonz@gmail.com/
which noted
Your input especially appreciated on whether you agree with the
intent of the test cases.
and then went into a long example about how one of the many tests added
had several questions about whether it was correct. As such, I believe
most the tests in that series were about testing rebase topology with as
many different flags as possible and were not trying to state in general
how those flags should behave otherwise.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16 05:36:24 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
2018-04-25 20:29:14 +08:00
|
|
|
test_run_rebase success --rebase-merges
|
2013-06-07 14:11:39 +08:00
|
|
|
|
2013-06-07 14:11:40 +08:00
|
|
|
# m
|
|
|
|
|
# /
|
|
|
|
|
# a---b---c---g
|
|
|
|
|
#
|
2013-06-18 15:28:07 +08:00
|
|
|
# x---y---bp
|
2013-06-07 14:11:40 +08:00
|
|
|
#
|
2013-06-18 15:28:07 +08:00
|
|
|
# bp = cherry-picked b
|
2013-06-07 14:11:40 +08:00
|
|
|
# m = reverted b
|
|
|
|
|
#
|
|
|
|
|
# Reverted patches are there for tests to be able to check if a commit
|
|
|
|
|
# that introduced the same change as another commit is
|
|
|
|
|
# dropped. Without reverted commits, we could get false positives
|
|
|
|
|
# because applying the patch succeeds, but simply results in no
|
|
|
|
|
# changes.
|
|
|
|
|
test_expect_success 'setup of linear history for test involving root' '
|
|
|
|
|
git checkout b &&
|
|
|
|
|
revert m b &&
|
|
|
|
|
git checkout --orphan disjoint &&
|
|
|
|
|
git rm -rf . &&
|
|
|
|
|
test_commit x &&
|
|
|
|
|
test_commit y &&
|
2013-06-18 15:28:07 +08:00
|
|
|
cherry_pick bp b
|
2013-06-07 14:11:40 +08:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* --onto --root" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* --onto c --root y &&
|
|
|
|
|
test_cmp_rev c HEAD~2 &&
|
|
|
|
|
test_linear_range 'x y' c..
|
|
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
2016-04-21 02:20:56 +08:00
|
|
|
test_run_rebase success -m
|
2013-06-07 14:11:40 +08:00
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
2013-06-07 14:11:40 +08:00
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* without --onto --root with disjoint history" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* c y &&
|
|
|
|
|
test_cmp_rev c HEAD~2 &&
|
|
|
|
|
test_linear_range 'x y' c..
|
|
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
2016-04-21 02:20:56 +08:00
|
|
|
test_run_rebase success -m
|
2013-06-07 14:11:40 +08:00
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase failure -p
|
2013-06-07 14:11:40 +08:00
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* --onto --root drops patch in onto" "
|
|
|
|
|
reset_rebase &&
|
2013-06-18 15:28:07 +08:00
|
|
|
git rebase $* --onto m --root bp &&
|
2013-06-07 14:11:40 +08:00
|
|
|
test_cmp_rev m HEAD~2 &&
|
|
|
|
|
test_linear_range 'x y' m..
|
|
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
rebase: implement --merge via the interactive machinery
As part of an ongoing effort to make rebase have more uniform behavior,
modify the merge backend to behave like the interactive one, by
re-implementing it on top of the latter.
Interactive rebases are implemented in terms of cherry-pick rather than
the merge-recursive builtin, but cherry-pick also calls into the
recursive merge machinery by default and can accept special merge
strategies and/or special strategy options. As such, there really is
not any need for having both git-rebase--merge and
git-rebase--interactive anymore. Delete git-rebase--merge.sh and
instead implement it in builtin/rebase.c.
This results in a few deliberate but small user-visible changes:
* The progress output is modified (see t3406 and t3420 for examples)
* A few known test failures are now fixed (see t3421)
* bash-prompt during a rebase --merge is now REBASE-i instead of
REBASE-m. Reason: The prompt is a reflection of the backend in use;
this allows users to report an issue to the git mailing list with
the appropriate backend information, and allows advanced users to
know where to search for relevant control files. (see t9903)
testcase modification notes:
t3406: --interactive and --merge had slightly different progress output
while running; adjust a test to match the new expectation
t3420: these test precise output while running, but rebase--am,
rebase--merge, and rebase--interactive all were built on very
different commands (am, merge-recursive, cherry-pick), so the
tests expected different output for each type. Now we expect
--merge and --interactive to have the same output.
t3421: --interactive fixes some bugs in --merge! Wahoo!
t9903: --merge uses the interactive backend so the prompt expected is
now REBASE-i.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-12 00:11:39 +08:00
|
|
|
test_run_rebase success -m
|
2013-06-07 14:11:40 +08:00
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
2013-06-07 14:11:40 +08:00
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* --onto --root with merge-base does not go to root" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* --onto m --root g &&
|
|
|
|
|
test_cmp_rev m HEAD~2 &&
|
|
|
|
|
test_linear_range 'c g' m..
|
|
|
|
|
"
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
2013-06-07 14:11:40 +08:00
|
|
|
test_run_rebase success -m
|
|
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase failure -p
|
2013-06-07 14:11:40 +08:00
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* without --onto --root with disjoint history drops patch in onto" "
|
|
|
|
|
reset_rebase &&
|
2013-06-18 15:28:07 +08:00
|
|
|
git rebase $* m bp &&
|
2013-06-07 14:11:40 +08:00
|
|
|
test_cmp_rev m HEAD~2 &&
|
|
|
|
|
test_linear_range 'x y' m..
|
|
|
|
|
"
|
|
|
|
|
}
|
2020-02-16 05:36:41 +08:00
|
|
|
test_run_rebase success --apply
|
rebase: implement --merge via the interactive machinery
As part of an ongoing effort to make rebase have more uniform behavior,
modify the merge backend to behave like the interactive one, by
re-implementing it on top of the latter.
Interactive rebases are implemented in terms of cherry-pick rather than
the merge-recursive builtin, but cherry-pick also calls into the
recursive merge machinery by default and can accept special merge
strategies and/or special strategy options. As such, there really is
not any need for having both git-rebase--merge and
git-rebase--interactive anymore. Delete git-rebase--merge.sh and
instead implement it in builtin/rebase.c.
This results in a few deliberate but small user-visible changes:
* The progress output is modified (see t3406 and t3420 for examples)
* A few known test failures are now fixed (see t3421)
* bash-prompt during a rebase --merge is now REBASE-i instead of
REBASE-m. Reason: The prompt is a reflection of the backend in use;
this allows users to report an issue to the git mailing list with
the appropriate backend information, and allows advanced users to
know where to search for relevant control files. (see t9903)
testcase modification notes:
t3406: --interactive and --merge had slightly different progress output
while running; adjust a test to match the new expectation
t3420: these test precise output while running, but rebase--am,
rebase--merge, and rebase--interactive all were built on very
different commands (am, merge-recursive, cherry-pick), so the
tests expected different output for each type. Now we expect
--merge and --interactive to have the same output.
t3421: --interactive fixes some bugs in --merge! Wahoo!
t9903: --merge uses the interactive backend so the prompt expected is
now REBASE-i.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-12 00:11:39 +08:00
|
|
|
test_run_rebase success -m
|
2013-06-07 14:11:40 +08:00
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase failure -p
|
2013-06-07 14:11:40 +08:00
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* --root on linear history is a no-op" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* --root c &&
|
|
|
|
|
test_cmp_rev c HEAD
|
|
|
|
|
"
|
|
|
|
|
}
|
rebase -i --root: let the sequencer handle even the initial part
In this developer's earlier attempt to accelerate interactive rebases by
converting large parts from Unix shell script into portable, performant
C, the --root handling was specifically excluded (to simplify the task a
little bit; it still took over a year to get that reduced set of patches
into Git proper).
This patch ties up that loose end: now only --preserve-merges uses the
slow Unix shell script implementation to perform the interactive rebase.
As the rebase--helper reports progress to stderr (unlike the scripted
interactive rebase, which reports it to stdout, of all places), we have
to adjust a couple of tests that did not expect that for `git rebase -i
--root`.
This patch fixes -- at long last! -- the really old bug reported in
6a6bc5bdc4d (add tests for rebasing root, 2013-06-06) that rebasing with
--root *always* rewrote the root commit, even if there were no changes.
The bug still persists in --preserve-merges mode, of course, but that
mode will be deprecated as soon as the new --rebase-merges mode
stabilizes, anyway.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-04 07:01:18 +08:00
|
|
|
test_run_rebase success ''
|
|
|
|
|
test_run_rebase success -m
|
|
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase failure -p
|
2013-06-07 14:11:40 +08:00
|
|
|
|
|
|
|
|
test_run_rebase () {
|
|
|
|
|
result=$1
|
|
|
|
|
shift
|
|
|
|
|
test_expect_$result "rebase $* -f --root on linear history causes re-write" "
|
|
|
|
|
reset_rebase &&
|
|
|
|
|
git rebase $* -f --root c &&
|
2019-11-13 07:07:45 +08:00
|
|
|
test_cmp_rev ! a HEAD~2 &&
|
2013-06-07 14:11:40 +08:00
|
|
|
test_linear_range 'a b c' HEAD
|
|
|
|
|
"
|
|
|
|
|
}
|
|
|
|
|
test_run_rebase success ''
|
|
|
|
|
test_run_rebase success -m
|
|
|
|
|
test_run_rebase success -i
|
2018-11-01 04:02:02 +08:00
|
|
|
test_have_prereq !REBASE_P || test_run_rebase success -p
|
2013-06-07 14:11:40 +08:00
|
|
|
|
2013-06-07 14:11:37 +08:00
|
|
|
test_done
|
