git-commit-vandalism/t/t3400-rebase.sh

423 lines
11 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2005 Amos Waterland
#
test_description='git rebase assorted tests
This test runs git rebase and checks that the author information is not lost
among other things.
'
. ./test-lib.sh
GIT_AUTHOR_NAME=author@name
GIT_AUTHOR_EMAIL=bogus@email@address
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
test_expect_success 'prepare repository with topic branches' '
git config core.logAllRefUpdates true &&
echo First >A &&
git update-index --add A &&
git commit -m "Add A." &&
git checkout -b force-3way &&
echo Dummy >Y &&
git update-index --add Y &&
git commit -m "Add Y." &&
git checkout -b filemove &&
git reset --soft master &&
mkdir D &&
git mv A D/A &&
git commit -m "Move A." &&
git checkout -b my-topic-branch master &&
echo Second >B &&
git update-index --add B &&
git commit -m "Add B." &&
git checkout -f master &&
echo Third >>A &&
git update-index A &&
git commit -m "Modify A." &&
git checkout -b side my-topic-branch &&
echo Side >>C &&
git add C &&
git commit -m "Add C" &&
git checkout -f my-topic-branch &&
git tag topic
'
test_expect_success 'rebase on dirty worktree' '
echo dirty >>A &&
test_must_fail git rebase master
'
test_expect_success 'rebase on dirty cache' '
git add A &&
test_must_fail git rebase master
'
test_expect_success 'rebase against master' '
git reset --hard HEAD &&
git rebase master
'
test_expect_success 'rebase sets ORIG_HEAD to pre-rebase state' '
git checkout -b orig-head topic &&
pre="$(git rev-parse --verify HEAD)" &&
git rebase master &&
test_cmp_rev "$pre" ORIG_HEAD &&
test_cmp_rev ! "$pre" HEAD
'
test_expect_success 'rebase, with <onto> and <upstream> specified as :/quuxery' '
test_when_finished "git branch -D torebase" &&
git checkout -b torebase my-topic-branch^ &&
upstream=$(git rev-parse ":/Add B") &&
onto=$(git rev-parse ":/Add A") &&
git rebase --onto $onto $upstream &&
git reset --hard my-topic-branch^ &&
git rebase --onto ":/Add A" ":/Add B" &&
git checkout my-topic-branch
'
test_expect_success 'the rebase operation should not have destroyed author information' '
! (git log | grep "Author:" | grep "<>")
'
test_expect_success 'the rebase operation should not have destroyed author information (2)' "
git log -1 |
grep 'Author: $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL>'
"
test_expect_success 'HEAD was detached during rebase' '
test $(git rev-parse HEAD@{1}) != $(git rev-parse my-topic-branch@{1})
'
test_expect_success 'rebase from ambiguous branch name' '
git checkout -b topic side &&
git rebase master
'
test_expect_success 'rebase off of the previous branch using "-"' '
git checkout master &&
git checkout HEAD^ &&
git rebase @{-1} >expect.messages &&
git merge-base master HEAD >expect.forkpoint &&
git checkout master &&
git checkout HEAD^ &&
git rebase - >actual.messages &&
git merge-base master HEAD >actual.forkpoint &&
test_cmp expect.forkpoint actual.forkpoint &&
# the next one is dubious---we may want to say "-",
# instead of @{-1}, in the message
test_i18ncmp expect.messages actual.messages
'
test_expect_success 'rebase a single mode change' '
git checkout master &&
git branch -D topic &&
echo 1 >X &&
git add X &&
test_tick &&
git commit -m prepare &&
git checkout -b modechange HEAD^ &&
echo 1 >X &&
git add X &&
test_chmod +x A &&
test_tick &&
git commit -m modechange &&
GIT_TRACE=1 git rebase master
'
test_expect_success 'rebase is not broken by diff.renames' '
test_config diff.renames copies &&
git checkout filemove &&
GIT_TRACE=1 git rebase force-3way
'
test_expect_success 'setup: recover' '
test_might_fail git rebase --abort &&
git reset --hard &&
git checkout modechange
'
2009-02-09 06:40:42 +01:00
test_expect_success 'Show verbose error when HEAD could not be detached' '
>B &&
test_when_finished "rm -f B" &&
test_must_fail git rebase topic 2>output.err >output.out &&
test_i18ngrep "The following untracked working tree files would be overwritten by checkout:" output.err &&
test_i18ngrep B output.err
2009-02-09 06:40:42 +01:00
'
test_expect_success 'fail when upstream arg is missing and not on branch' '
git checkout topic &&
test_must_fail git rebase
'
test_expect_success 'fail when upstream arg is missing and not configured' '
git checkout -b no-config topic &&
test_must_fail git rebase
'
test_expect_success 'rebase works with format.useAutoBase' '
test_config format.useAutoBase true &&
git checkout topic &&
git rebase master
'
test_expect_success 'default to common base in @{upstream}s reflog if no upstream arg (--merge)' '
git checkout -b default-base master &&
git checkout -b default topic &&
git config branch.default.remote . &&
git config branch.default.merge refs/heads/default-base &&
git rebase --merge &&
git rev-parse --verify default-base >expect &&
git rev-parse default~1 >actual &&
test_cmp expect actual &&
git checkout default-base &&
git reset --hard HEAD^ &&
git checkout default &&
git rebase --merge &&
git rev-parse --verify default-base >expect &&
git rev-parse default~1 >actual &&
test_cmp expect actual
'
rebase: rename the two primary rebase backends Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-15 22:36:41 +01:00
test_expect_success 'default to common base in @{upstream}s reflog if no upstream arg (--apply)' '
git checkout -B default-base master &&
git checkout -B default topic &&
git config branch.default.remote . &&
git config branch.default.merge refs/heads/default-base &&
rebase: rename the two primary rebase backends Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-15 22:36:41 +01:00
git rebase --apply &&
git rev-parse --verify default-base >expect &&
git rev-parse default~1 >actual &&
test_cmp expect actual &&
git checkout default-base &&
git reset --hard HEAD^ &&
git checkout default &&
rebase: rename the two primary rebase backends Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-15 22:36:41 +01:00
git rebase --apply &&
git rev-parse --verify default-base >expect &&
git rev-parse default~1 >actual &&
test_cmp expect actual
'
2009-02-09 06:40:42 +01:00
rebase: omit patch-identical commits with --fork-point When the `--fork-point` argument was added to `git rebase`, we changed the value of $upstream to be the fork point instead of the point from which we want to rebase. When $orig_head..$upstream is empty this does not change the behaviour, but when there are new changes in the upstream we are no longer checking if any of them are patch-identical with changes in $upstream..$orig_head. Fix this by introducing a new variable to hold the fork point and using this to restrict the range as an extra (negative) revision argument so that the set of desired revisions becomes (in fork-point mode): git rev-list --cherry-pick --right-only \ $upstream...$orig_head ^$fork_point This allows us to correctly handle the scenario where we have the following topology: C --- D --- E <- dev / B <- master@{1} / o --- B' --- C* --- D* <- master where: - B' is a fixed-up version of B that is not patch-identical with B; - C* and D* are patch-identical to C and D respectively and conflict textually if applied in the wrong order; - E depends textually on D. The correct result of `git rebase master dev` is that B is identified as the fork-point of dev and master, so that C, D, E are the commits that need to be replayed onto master; but C and D are patch-identical with C* and D* and so can be dropped, so that the end result is: o --- B' --- C* --- D* --- E <- dev If the fork-point is not identified, then picking B onto a branch containing B' results in a conflict and if the patch-identical commits are not correctly identified then picking C onto a branch containing D (or equivalently D*) results in a conflict. This change allows us to handle both of these cases, where previously we either identified the fork-point (with `--fork-point`) but not the patch-identical commits *or* (with `--no-fork-point`) identified the patch-identical commits but not the fact that master had been rewritten. Reported-by: Ted Felix <ted@tedfelix.com> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-16 21:23:49 +02:00
test_expect_success 'cherry-picked commits and fork-point work together' '
git checkout default-base &&
echo Amended >A &&
git commit -a --no-edit --amend &&
test_commit B B &&
test_commit new_B B "New B" &&
test_commit C C &&
git checkout default &&
git reset --hard default-base@{4} &&
test_commit D D &&
git cherry-pick -2 default-base^ &&
test_commit final_B B "Final B" &&
git rebase &&
echo Amended >expect &&
test_cmp expect A &&
rebase: omit patch-identical commits with --fork-point When the `--fork-point` argument was added to `git rebase`, we changed the value of $upstream to be the fork point instead of the point from which we want to rebase. When $orig_head..$upstream is empty this does not change the behaviour, but when there are new changes in the upstream we are no longer checking if any of them are patch-identical with changes in $upstream..$orig_head. Fix this by introducing a new variable to hold the fork point and using this to restrict the range as an extra (negative) revision argument so that the set of desired revisions becomes (in fork-point mode): git rev-list --cherry-pick --right-only \ $upstream...$orig_head ^$fork_point This allows us to correctly handle the scenario where we have the following topology: C --- D --- E <- dev / B <- master@{1} / o --- B' --- C* --- D* <- master where: - B' is a fixed-up version of B that is not patch-identical with B; - C* and D* are patch-identical to C and D respectively and conflict textually if applied in the wrong order; - E depends textually on D. The correct result of `git rebase master dev` is that B is identified as the fork-point of dev and master, so that C, D, E are the commits that need to be replayed onto master; but C and D are patch-identical with C* and D* and so can be dropped, so that the end result is: o --- B' --- C* --- D* --- E <- dev If the fork-point is not identified, then picking B onto a branch containing B' results in a conflict and if the patch-identical commits are not correctly identified then picking C onto a branch containing D (or equivalently D*) results in a conflict. This change allows us to handle both of these cases, where previously we either identified the fork-point (with `--fork-point`) but not the patch-identical commits *or* (with `--no-fork-point`) identified the patch-identical commits but not the fact that master had been rewritten. Reported-by: Ted Felix <ted@tedfelix.com> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-16 21:23:49 +02:00
echo "Final B" >expect &&
test_cmp expect B &&
rebase: omit patch-identical commits with --fork-point When the `--fork-point` argument was added to `git rebase`, we changed the value of $upstream to be the fork point instead of the point from which we want to rebase. When $orig_head..$upstream is empty this does not change the behaviour, but when there are new changes in the upstream we are no longer checking if any of them are patch-identical with changes in $upstream..$orig_head. Fix this by introducing a new variable to hold the fork point and using this to restrict the range as an extra (negative) revision argument so that the set of desired revisions becomes (in fork-point mode): git rev-list --cherry-pick --right-only \ $upstream...$orig_head ^$fork_point This allows us to correctly handle the scenario where we have the following topology: C --- D --- E <- dev / B <- master@{1} / o --- B' --- C* --- D* <- master where: - B' is a fixed-up version of B that is not patch-identical with B; - C* and D* are patch-identical to C and D respectively and conflict textually if applied in the wrong order; - E depends textually on D. The correct result of `git rebase master dev` is that B is identified as the fork-point of dev and master, so that C, D, E are the commits that need to be replayed onto master; but C and D are patch-identical with C* and D* and so can be dropped, so that the end result is: o --- B' --- C* --- D* --- E <- dev If the fork-point is not identified, then picking B onto a branch containing B' results in a conflict and if the patch-identical commits are not correctly identified then picking C onto a branch containing D (or equivalently D*) results in a conflict. This change allows us to handle both of these cases, where previously we either identified the fork-point (with `--fork-point`) but not the patch-identical commits *or* (with `--no-fork-point`) identified the patch-identical commits but not the fact that master had been rewritten. Reported-by: Ted Felix <ted@tedfelix.com> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-16 21:23:49 +02:00
echo C >expect &&
test_cmp expect C &&
rebase: omit patch-identical commits with --fork-point When the `--fork-point` argument was added to `git rebase`, we changed the value of $upstream to be the fork point instead of the point from which we want to rebase. When $orig_head..$upstream is empty this does not change the behaviour, but when there are new changes in the upstream we are no longer checking if any of them are patch-identical with changes in $upstream..$orig_head. Fix this by introducing a new variable to hold the fork point and using this to restrict the range as an extra (negative) revision argument so that the set of desired revisions becomes (in fork-point mode): git rev-list --cherry-pick --right-only \ $upstream...$orig_head ^$fork_point This allows us to correctly handle the scenario where we have the following topology: C --- D --- E <- dev / B <- master@{1} / o --- B' --- C* --- D* <- master where: - B' is a fixed-up version of B that is not patch-identical with B; - C* and D* are patch-identical to C and D respectively and conflict textually if applied in the wrong order; - E depends textually on D. The correct result of `git rebase master dev` is that B is identified as the fork-point of dev and master, so that C, D, E are the commits that need to be replayed onto master; but C and D are patch-identical with C* and D* and so can be dropped, so that the end result is: o --- B' --- C* --- D* --- E <- dev If the fork-point is not identified, then picking B onto a branch containing B' results in a conflict and if the patch-identical commits are not correctly identified then picking C onto a branch containing D (or equivalently D*) results in a conflict. This change allows us to handle both of these cases, where previously we either identified the fork-point (with `--fork-point`) but not the patch-identical commits *or* (with `--no-fork-point`) identified the patch-identical commits but not the fact that master had been rewritten. Reported-by: Ted Felix <ted@tedfelix.com> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-16 21:23:49 +02:00
echo D >expect &&
test_cmp expect D
rebase: omit patch-identical commits with --fork-point When the `--fork-point` argument was added to `git rebase`, we changed the value of $upstream to be the fork point instead of the point from which we want to rebase. When $orig_head..$upstream is empty this does not change the behaviour, but when there are new changes in the upstream we are no longer checking if any of them are patch-identical with changes in $upstream..$orig_head. Fix this by introducing a new variable to hold the fork point and using this to restrict the range as an extra (negative) revision argument so that the set of desired revisions becomes (in fork-point mode): git rev-list --cherry-pick --right-only \ $upstream...$orig_head ^$fork_point This allows us to correctly handle the scenario where we have the following topology: C --- D --- E <- dev / B <- master@{1} / o --- B' --- C* --- D* <- master where: - B' is a fixed-up version of B that is not patch-identical with B; - C* and D* are patch-identical to C and D respectively and conflict textually if applied in the wrong order; - E depends textually on D. The correct result of `git rebase master dev` is that B is identified as the fork-point of dev and master, so that C, D, E are the commits that need to be replayed onto master; but C and D are patch-identical with C* and D* and so can be dropped, so that the end result is: o --- B' --- C* --- D* --- E <- dev If the fork-point is not identified, then picking B onto a branch containing B' results in a conflict and if the patch-identical commits are not correctly identified then picking C onto a branch containing D (or equivalently D*) results in a conflict. This change allows us to handle both of these cases, where previously we either identified the fork-point (with `--fork-point`) but not the patch-identical commits *or* (with `--no-fork-point`) identified the patch-identical commits but not the fact that master had been rewritten. Reported-by: Ted Felix <ted@tedfelix.com> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-16 21:23:49 +02:00
'
rebase: rename the two primary rebase backends Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-15 22:36:41 +01:00
test_expect_success 'rebase --apply -q is quiet' '
git checkout -b quiet topic &&
rebase: rename the two primary rebase backends Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-15 22:36:41 +01:00
git rebase --apply -q master >output.out 2>&1 &&
test_must_be_empty output.out
'
test_expect_success 'rebase --merge -q is quiet' '
git checkout -B quiet topic &&
git rebase --merge -q master >output.out 2>&1 &&
test_must_be_empty output.out
'
test_expect_success 'Rebase a commit that sprinkles CRs in' '
(
echo "One" &&
echo "TwoQ" &&
echo "Three" &&
echo "FQur" &&
echo "Five"
) | q_to_cr >CR &&
git add CR &&
test_tick &&
git commit -a -m "A file with a line with CR" &&
git tag file-with-cr &&
git checkout HEAD^0 &&
git rebase --onto HEAD^^ HEAD^ &&
git diff --exit-code file-with-cr:CR HEAD:CR
'
test_expect_success 'rebase can copy notes' '
git config notes.rewrite.rebase true &&
git config notes.rewriteRef "refs/notes/*" &&
test_commit n1 &&
test_commit n2 &&
test_commit n3 &&
git notes add -m"a note" n3 &&
git rebase --onto n1 n2 &&
test "a note" = "$(git notes show HEAD)"
'
test_expect_success 'rebase -m can copy notes' '
git reset --hard n3 &&
git rebase -m --onto n1 n2 &&
test "a note" = "$(git notes show HEAD)"
'
test_expect_success 'rebase commit with an ancient timestamp' '
git reset --hard &&
>old.one && git add old.one && test_tick &&
git commit --date="@12345 +0400" -m "Old one" &&
>old.two && git add old.two && test_tick &&
git commit --date="@23456 +0500" -m "Old two" &&
>old.three && git add old.three && test_tick &&
git commit --date="@34567 +0600" -m "Old three" &&
git cat-file commit HEAD^^ >actual &&
grep "author .* 12345 +0400$" actual &&
git cat-file commit HEAD^ >actual &&
grep "author .* 23456 +0500$" actual &&
git cat-file commit HEAD >actual &&
grep "author .* 34567 +0600$" actual &&
git rebase --onto HEAD^^ HEAD^ &&
git cat-file commit HEAD >actual &&
grep "author .* 34567 +0600$" actual
'
test_expect_success 'rebase with "From " line in commit message' '
git checkout -b preserve-from master~1 &&
cat >From_.msg <<EOF &&
Somebody embedded an mbox in a commit message
This is from so-and-so:
From a@b Mon Sep 17 00:00:00 2001
From: John Doe <nobody@example.com>
Date: Sat, 11 Nov 2017 00:00:00 +0000
Subject: not this message
something
EOF
>From_ &&
git add From_ &&
git commit -F From_.msg &&
git rebase master &&
git log -1 --pretty=format:%B >out &&
test_cmp From_.msg out
'
rebase: rename the two primary rebase backends Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-15 22:36:41 +01:00
test_expect_success 'rebase --apply and --show-current-patch' '
test_create_repo conflict-apply &&
(
cd conflict-apply &&
test_commit init &&
echo one >>init.t &&
git commit -a -m one &&
echo two >>init.t &&
git commit -a -m two &&
git tag two &&
rebase: rename the two primary rebase backends Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-15 22:36:41 +01:00
test_must_fail git rebase --apply -f --onto init HEAD^ &&
GIT_TRACE=1 git rebase --show-current-patch >/dev/null 2>stderr &&
grep "show.*$(git rev-parse two)" stderr
)
'
rebase: rename the two primary rebase backends Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-15 22:36:41 +01:00
test_expect_success 'rebase --apply and .gitattributes' '
test_create_repo attributes &&
(
cd attributes &&
test_commit init &&
git config filter.test.clean "sed -e '\''s/smudged/clean/g'\''" &&
git config filter.test.smudge "sed -e '\''s/clean/smudged/g'\''" &&
test_commit second &&
git checkout -b test HEAD^ &&
echo "*.txt filter=test" >.gitattributes &&
git add .gitattributes &&
test_commit third &&
echo "This text is smudged." >a.txt &&
git add a.txt &&
test_commit fourth &&
git checkout -b removal HEAD^ &&
git rm .gitattributes &&
git add -u &&
test_commit fifth &&
git cherry-pick test &&
git checkout test &&
git rebase master &&
grep "smudged" a.txt &&
git checkout removal &&
git reset --hard &&
git rebase master &&
grep "clean" a.txt
)
'
test_expect_success 'rebase--merge.sh and --show-current-patch' '
test_create_repo conflict-merge &&
(
cd conflict-merge &&
test_commit init &&
echo one >>init.t &&
git commit -a -m one &&
echo two >>init.t &&
git commit -a -m two &&
git tag two &&
test_must_fail git rebase --merge --onto init HEAD^ &&
git rebase --show-current-patch >actual.patch &&
GIT_TRACE=1 git rebase --show-current-patch >/dev/null 2>stderr &&
grep "show.*REBASE_HEAD" stderr &&
test "$(git rev-parse REBASE_HEAD)" = "$(git rev-parse two)"
)
'
rebase: remove the rebase.useBuiltin setting Remove the rebase.useBuiltin setting, which was added as an escape hatch to disable the builtin version of rebase first released with Git 2.20. See [1] for the initial implementation of rebase.useBuiltin, and [2] and [3] for the documentation and corresponding GIT_TEST_REBASE_USE_BUILTIN option. Carrying the legacy version is a maintenance burden as seen in 7e097e27d3 ("legacy-rebase: backport -C<n> and --whitespace=<option> checks", 2018-11-20) and 9aea5e9286 ("rebase: fix regression in rebase.useBuiltin=false test mode", 2019-02-13). Since the built-in version has been shown to be stable enough let's remove the legacy version. As noted in [3] having use_builtin_rebase() shell out to get its config doesn't make any sense anymore, that was done for the purposes of spawning the legacy rebase without having modified any global state. Let's instead handle this case in rebase_config(). There's still a bunch of references to git-legacy-rebase in po/*.po, but those will be dealt with in time by the i18n effort. Even though this configuration variable only existed two releases let's not entirely delete the entry from the docs, but note its absence. Individual versions of git tend to be around for a while due to distro packaging timelines, so e.g. if we're "lucky" a given version like 2.21 might be installed on say OSX for half a decade. That'll mean some people probably setting this in config, and then when they later wonder if it's needed they can Google search the config option name or check it in git-config. It also allows us to refer to the docs from the warning for details. 1. 55071ea248 ("rebase: start implementing it as a builtin", 2018-08-07) 2. d8d0a546f0 ("rebase doc: document rebase.useBuiltin", 2018-11-14) 3. 62c23938fa ("tests: add a special setup where rebase.useBuiltin is off", 2018-11-14) 3. https://public-inbox.org/git/nycvar.QRO.7.76.6.1903141544110.41@tvgsbejvaqbjf.bet/ Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-18 12:01:52 +01:00
test_expect_success 'rebase -c rebase.useBuiltin=false warning' '
expected="rebase.useBuiltin support has been removed" &&
# Only warn when the legacy rebase is requested...
test_must_fail git -c rebase.useBuiltin=false rebase 2>err &&
test_i18ngrep "$expected" err &&
test_must_fail env GIT_TEST_REBASE_USE_BUILTIN=false git rebase 2>err &&
test_i18ngrep "$expected" err &&
# ...not when we would have used the built-in anyway
test_must_fail git -c rebase.useBuiltin=true rebase 2>err &&
test_must_be_empty err &&
test_must_fail env GIT_TEST_REBASE_USE_BUILTIN=true git rebase 2>err &&
test_must_be_empty err
'
test_expect_success 'switch to branch checked out here' '
git checkout master &&
git rebase master master
'
test_expect_success 'switch to branch not checked out' '
git checkout master &&
git branch other &&
git rebase master other
'
test_expect_success 'refuse to switch to branch checked out elsewhere' '
git checkout master &&
git worktree add wt &&
test_must_fail git -C wt rebase master master 2>err &&
test_i18ngrep "already checked out" err
'
test_done