SZEDER Gábor <[email protected]> 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
