fast-export: re-define expectation with "no-exact refs"

In 25e0ca5 (Add new fast-export testcases, 2009-06-25), we
introduced a test where `fast-export` was called with a commit range
whose positive side was not a ref name, but a revision that refers to
the parent of a ref.

In such a case, the result of `fast-export` cannot be piped to
`fast-import` to essentially recreate the same revisions because we do
not have a proper ref name to work with.

The introduced test case set the expectation that Git should
transmogrify the `main~1` into `refs/heads/master`, and because it
doesn't, the test case was marked as demonstrating a breakage.

However, it would be improper to perform that conversion: the overall
expectation of `fast-export` is that when piping it to `fast-import`,
you get an identical result. And no matter how you hold the tool, `git
fast-export main~2..main~1` will never be able to perform that trick
because there is simply insufficient information.

It would seem that `fast-export` Does The Right Thing here by using
`main~1` as the "ref name", even if `fast-import` would stumble over
that: At least the output documents properly which commit was exported,
even if the result is not a valid `fast-import` script.

So let's turn the test case around into documenting that the current
behavior is actually expected and not at all a breakage that needs
fixing.

Signed-off-by: Johannes Schindelin <[email protected]>

Author: dscho

t/t9350-fast-export.sh

@@ -470,8 +470,7 @@ mark :2
 data 3
 hi
 
-reset refs/heads/main
-commit refs/heads/main
+commit main~1
 mark :3
 author A U Thor <[email protected]> 1112912713 -0700
 committer C O Mitter <[email protected]> 1112912713 -0700
@@ -482,7 +481,7 @@ M 100644 :2 there
 
 EOF
 
-test_expect_failure 'no exact-ref revisions included' '
+test_expect_success 'no exact-ref revisions included' '
 	(
 		cd limit-by-paths &&
 		git fast-export main~2..main~1 > output &&