Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
> 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)...
I'll re-roll because I think your comments make sense.
>> 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().
I can change it. Better to use standard tools when available. I like
the output from test_debug when I want to look at it but that's a
relatively minor thing.
>> +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?
Yeah, I'll remove these.
>> + 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?
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?
Good idea.
-David
--
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