David Turner <dturner@xxxxxxxxxxxxxxxx> writes:
> On Sun, 2015-05-10 at 09:06 +0200, Johannes Sixt wrote:
>> > + ln -s loop2 loop1 &&
>> > + git add . &&
>> > + git commit -am "test"
>> > +'
>>
>> These tests will fail on a file system that does not support symbolic
>> links, such as on Windows. Would you please separate the test cases
>> (that come after the setup) into two groups:
>>
>> 1. Those that inspect the filesystem and expect a symbolic link. Protect
>> these tests with a SYMLINKS prerequisite.
>
> I believe that none of these require that.
>
>> Note that you do not require a symlink enabled file system to generate a
>> repository with symlinks, i.e., you don't have to protect the setup code
>> with SYMLINKS. For this, you can use 'test_ln_s_add' instead of the
>> above sequence of 'ln -s' followed by a single 'git add .'.
>
> Will fix, thanks.
Yeah, thanks. There doesn't seem to be any reason to forbid this new
feature from being used on symlink-challenged filesystem (after all,
"cat-file --batch" should run fine in a bare repository) and the
suggestion makes sens to me.
>> > +
>> > +echo $hello_sha1 blob $hello_size > found
>>
>> This seems to be used only in the next test. Please move it inside
>> test_expect_success.
>
> This is used in a number of tests, e.g this one:
Perhaps then the preparetion of 'found' is part of this thing:
test_expect_success 'prep for symlink tests' '
A micronit on style; please drop SP between redirection and its
target (but have one before redirection), i.e.
echo ... >found
command <input
Thanks.
>
>> > +test_expect_success 'git cat-file --batch-check --follow-symlinks
>> > works for in-repo, same-dir links' '
>> > + echo HEAD:same-dir-link | git cat-file --batch-check --follow-symlinks > actual &&
>> > + test_cmp found actual
>> > +'
--
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