On Sun, Jan 10, 2016 at 6:08 PM, David Greene <greened@xxxxxxxxxxxxx> wrote:
> From: "David A. Greene" <greened@xxxxxxxxxxxxx>
>
> This test merges an external tree in as a subtree, makes some commits
> on top of it and splits it back out. In the process the added commits
> are lost or the rebase aborts with an internal error. The tests are
> marked to expect failure so that we don't forget to fix it.
This version looks better. A few minor comments below (not necessarily
deserving a re-roll)...
> Signed-off-by: David A. Greene <greened@xxxxxxxxxxxxx>
> ---
> diff --git a/t/t3427-rebase-subtree.sh b/t/t3427-rebase-subtree.sh
> @@ -0,0 +1,79 @@
> +#!/bin/sh
> +
> +test_description='git rebase tests for -Xsubtree
> +
> +This test runs git rebase and tests the subtree strategy.
> +'
> +. ./test-lib.sh
> +. "$TEST_DIRECTORY"/lib-rebase.sh
> +
> +check_equal() {
> + test_debug 'echo'
> + test_debug "echo \"check a:\" \"{$1}\""
> + test_debug "echo \" b:\" \"{$2}\""
> + test "$1" = "$2"
> +}
I'm still curious as to why check_equal() is preferred over
test-lib-functions.sh:verbose().
> +last_commit_message() {
> + git log --pretty=format:%s -1
> +}
> +
> +test_expect_success 'setup' '
> + test_commit README &&
> + mkdir files &&
> + (
> + cd files &&
> + git init &&
> + test_commit master1 &&
> + test_commit master2 &&
> + test_commit master3
> + ) &&
> + test_debug "echo Add project master to master" &&
Are these test_debug invocations still useful now that the test has
been fully developed?
> + git fetch files master &&
> + git branch files-master FETCH_HEAD &&
> + test_debug "echo Add subtree master to master via subtree" &&
> + git read-tree --prefix=files_subtree files-master &&
> + git checkout -- files_subtree &&
> + tree=$(git write-tree) &&
> + head=$(git rev-parse HEAD) &&
> + rev=$(git rev-parse --verify files-master^0) &&
> + commit=$(git commit-tree -p $head -p $rev -m "Add subproject master" $tree) &&
> + git reset $commit &&
> + (
> + cd files_subtree &&
> + test_commit master4
> + ) &&
> + test_commit files_subtree/master5
> +'
> +
> +# Does not preserve master4 and master5.
This comment is explaining why the test is marked "failure", right?
When someone gets around to fixing the breakage and toggling this to
"success", there is a reasonably good chance that the comment will be
overlooked and thus become stale. Perhaps prefixing the comment with a
bold "FAILURE:" would serve as a reminder that the comment should be
dropped when the problem is fixed?
> +test_expect_failure 'Rebase -Xsubtree --preserve-merges --onto' '
> + reset_rebase &&
> + git checkout -b rebase-preserve-merges master &&
> + git filter-branch --prune-empty -f --subdirectory-filter files_subtree &&
> + git commit -m "Empty commit" --allow-empty &&
> + git rebase -Xsubtree=files_subtree --preserve-merges --onto files-master master &&
> + check_equal "$(last_commit_message)" "files_subtree/master5"
> +'
> +
> +# Does not preserve master4, master5 and empty.
> +test_expect_failure 'Rebase -Xsubtree --keep-empty --preserve-merges --onto' '
> + reset_rebase &&
> + git checkout -b rebase-keep-empty master &&
> + git filter-branch --prune-empty -f --subdirectory-filter files_subtree &&
> + git commit -m "Empty commit" --allow-empty &&
> + git rebase -Xsubtree=files_subtree --keep-empty --preserve-merges --onto files-master master &&
> + check_equal "$(last_commit_message)" "Empty commit"
> +'
> +
> +# fatal: Could not parse object
> +test_expect_failure 'Rebase -Xsubtree --onto' '
> + reset_rebase &&
> + git checkout -b rebase-onto master &&
> + git filter-branch --prune-empty -f --subdirectory-filter files_subtree &&
> + git commit -m "Empty commit" --allow-empty &&
> + git rebase -Xsubtree=files_subtree --onto files-master master &&
> + check_equal "$(last_commit_message)" "Empty commit"
> +'
> +
> +test_done
> --
> 2.6.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html