From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 03 Jul 2019 17:05:56 GMT
Subject: Re: [PATCH v2 2/2] check_everything_connected: assume alternate ref tips are valid
Message-ID: <xmqqwogz1217.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190703165036.GS21574@szeder.dev>

SZEDER Gábor <szeder.dev@gmail.com> 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