Junio C Hamano venit, vidit, dixit 03.03.2015 23:26: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: >> >>> Signed-off-by: Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> >>> --- >>> t/t7508-status.sh | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/t/t7508-status.sh b/t/t7508-status.sh >>> index 8ed5788..4989e98 100755 >>> --- a/t/t7508-status.sh >>> +++ b/t/t7508-status.sh >>> @@ -133,6 +133,12 @@ test_expect_success 'status with status.displayCommentPrefix=false' ' >>> test_i18ncmp expect output >>> ' >>> >>> +test_expect_success 'status -v' ' >>> + git diff --cached >>expect && >> >> This makes the test rely on the previous one succeeding. Do we >> care, or is reproducing what ought to be in 'expect' at this step >> too expensive? > > Ahh, OK. The way the existing tests prepare 'expect' is "by hand". > > So I think what is wrong with this new test is not that relies on > the current contents of 'expect', but that it modifies it (imagine > being a merge/patch monkey who has to accept this change while a > change from somebody else that wants to add another test that relies > on the original 'expect' intact and then have to scratch his or her > head when the two topics are merged, wondering why the latter test > starts failing). > > Perhaps > > ( cat expect && git diff --cached ) >expect-with-v && > git status -v >actual && > test_cmp expect-with-v actual > > or something? That's what I had first, but the new file shows up as untracked file in the status output... I don't mind setting this one up by hand also, if you prefer. Michael -- 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