On Mon, Nov 13, 2017 at 5:21 PM, Stefan Beller <[email protected]> wrote:
> On Mon, Nov 13, 2017 at 4:57 PM, Elijah Newren <[email protected]> wrote:
> (slightly dreaming:)
> I wonder if we could teach our test suite to accept multiple test_done
> or restart_tests or such to resurrect the clean slate.
I'm dreaming now too; I would like that a lot more, although the
separate test_create_repo for each case isn't too bad and should be a
pretty mechanical switch.
>>>> + test 3 -eq $(git ls-files -s | wc -l) &&
>>>
>>> git ls-files >out &&
>>> test_line_count = 3 out &&
>>>
> I am not saying it was a cargo-culting reaction, but rather relaying
> a well discussed style issue to you. ;)
Ah, gotcha.
>> If you feel the return code of ls-files is important, perhaps I could
>> just have a separate
>> git ls-files -s >/dev/null &&
>> call before the others?
>
> I would prefer to not add any further calls; also (speaking generically)
> this would bring in potential racing issues (what if the second ls-files
> behaves differently than the first?)
Makes sense.
>> I'm not following. The "old" and "new" in the filenames were just
>> there so a human reading the testcase could easily tell which
>> filenames were related and involved in renames. There is no rename
>> associated with d, so why would I have called it "old" or "new"?
>
> because a user may be impressed by gits pattern matching in the
> rename detection:
>
> A: z/{oldb,oldc}
> B: z/{newb,newc}
> C: z/{oldb, oldc, oldd}
>
> Obviously A->B is z/{old->new}-* (not a directory rename,
> but just patterns), so one might be tempted to expect newd
> as the expectation. But that is nonsense(!?)
Ah, now I see where you were going. Thanks for explaining.
>> I think 2 is insanity.
>
> or the place where hooks/custom code shines. :)
:)
