On 20 July 2016 at 17:47, Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> wrote: > On 07/20/2016 11:30 AM, Jakub Narębski wrote: >> W dniu 2016-07-20 o 00:10, Jeff Hostetler pisze: >>> >>> +test_expect_success pre_initial_commit_0 ' >>> + printf "## branch: (initial) master\n" >expected && >>> + printf "?? actual\n" >>expected && >>> + printf "?? dir1/\n" >>expected && >>> + printf "?? expected\n" >>expected && >>> + printf "?? file_x\n" >>expected && >>> + printf "?? file_y\n" >>expected && >>> + printf "?? file_z\n" >>expected && >> >> Why not use heredoc syntax (cat <<\EOF), or prepare a file >> with expected output in the testsuite? > > The tests involving renames needed to embed a tab character > in the output and hiding a tab character in a heredoc seemed > error prone. So to be consistent I made them all printf-style. Ah, so that's the case for series of printf. I think in some other cases the Git testsuite simply uses HT variable for the TAB character. I guess that "\t" for TAB is available in POSIX and all shells that Git is run on? See t3300-funny-names.sh, t3902-quoted.sh, t4213-log-tabexpand.sh > Also, some of the tests include SHAs for the commit and for > file content, so having pre-computed expected output is awkward. > Granted we could hard code the file SHAs, but not the commits. Right... but heredoc can include variable expansion (or rather it includes variable expansion by default, and you can prevent it by quoting end-of-heredoc marker). -- Jakub Narębski -- 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