SZEDER Gábor <szeder.dev@xxxxxxxxx> writes: > On Wed, Jul 03, 2019 at 12:41:16PM -0400, Jeff King wrote: >> On Wed, Jul 03, 2019 at 11:12:25AM +0200, SZEDER Gábor wrote: >> >> > On Mon, Jul 01, 2019 at 09:18:15AM -0400, Jeff King wrote: >> > > diff --git a/t/t5618-alternate-refs.sh b/t/t5618-alternate-refs.sh >> > > new file mode 100755 >> > > index 0000000000..3353216f09 >> > > --- /dev/null >> > > +++ b/t/t5618-alternate-refs.sh >> > > @@ -0,0 +1,60 @@ >> > >> > > +test_expect_success 'log --source shows .alternate marker' ' >> > > + git log --oneline --source --remotes=origin >expect.orig && >> > > + sed "s/origin.* /.alternate /" <expect.orig >expect && >> > >> > Unnecessary redirection, 'sed' can open that file on its own as well. >> >> Sure, but is there a compelling reason not to feed it as stdin? > > Not really, other than there is no compelling reason to do so :) For this particular one, it would not make much difference, but when feeding a single file to a command that can take many instructions as command line arguments, I tend to prefer $ cmd <input \ -e 's/foo/bar/' \ -e 's/xyzzy/frotz/g' \ ... which I find slightly easier to read than $ cmd \ -e 's/foo/bar/' \ -e 's/xyzzy/frotz/g' \ ... \ input
