Ilya Bobyr wrote: > On 4/21/2014 3:24 PM, Felipe Contreras wrote: > > Ilya Bobyr wrote: > >> On Mon, Apr 21, 2014 at 2:35 PM, Felipe Contreras < > >> felipe.contreras@xxxxxxxxx> wrote: > >>> Ilya Bobyr wrote: > >>>> test_expect_success 'setup' " > >>>> mkdir -p .git/hooks && > >>>> cat > .git/hooks/update-branch <<-\\EOF && > >>>> #!/bin/sh > >>>> echo \$@ > .git/update-branch.args > >>>> EOF > >>>> chmod +x .git/hooks/update-branch && > >>>> echo one > content && > >>>> git add content && > >>>> git commit -a -m one > >>>> " > >>> That is not maintainable at all. > >> Maybe you could explain how is this less maintainable, compared to a separate > >> function? > > Do I really have to explain that manually escaping a shell script is not > > maintainable? > > This is rude. So? I really don't see the need to explain that such a monstrosity would be unmaintainable, that's a given. > Here is how you can do it without escaping: > > test_expect_success 'setup' ' > mkdir -p .git/hooks && > cat > .git/hooks/update-branch <<-\EOF && > #!/bin/sh > echo $@ > .git/update-branch.args > EOF > chmod +x .git/hooks/update-branch && > echo one > content && > git add content && > git commit -a -m one > ' > > It is not different from most of the tests, I think. This is what I originally asked for. > >> This is how it is suggested by t/README and how it is done in the other > >> test suites. > >> I can not see how your case is different, but I might be missing something. > > Let's take a cursoy look at `git grep -l "'EOF'" t`. > > > > [...] > > So the point is that some existing tests violate best practices? I don't know what you mean by "best practices", but these are Git's best practices. > I do not think this is a good justification to do the same for new tests. It is not a justification to reject a patch either, specially if no better alternative has been put forward. Fortunately a better alternative has been put forward, so this is moot. -- Felipe Contreras -- 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