All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Kirillov <max@max630.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 2/2] t: git-show: adapt tests to fixed 'git show'
Date: Tue, 13 May 2014 23:09:50 +0300	[thread overview]
Message-ID: <20140513200910.GB6857@wheezy.local> (raw)
In-Reply-To: <xmqqiop9o4y5.fsf@gitster.dls.corp.google.com>

On Tue, May 13, 2014 at 12:26:42PM -0700, Junio C Hamano wrote:
> Hmph.  Having these as two separate commits would mean that 1/2
> alone will break the test, hurting bisectability a little bit.  The
> necessary adjustments in this patch is small enough that we may be
> better off squashing them into one.

Ok, will squash them.

>>  t/t1507-rev-parse-upstream.sh |  2 +-
>>  t/t7600-merge.sh              | 11 +++++------
>>  2 files changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/t/t1507-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh
>> index 2a19e79..672280b 100755
>> --- a/t/t1507-rev-parse-upstream.sh
>> +++ b/t/t1507-rev-parse-upstream.sh
>> @@ -100,7 +100,7 @@ test_expect_success 'merge my-side@{u} records the correct name' '
>>  	git branch -D new ;# can fail but is ok
>>  	git branch -t new my-side@{u} &&
>>  	git merge -s ours new@{u} &&
>> -	git show -s --pretty=format:%s >actual &&
>> +	git show -s --pretty=tformat:%s >actual &&
>>  	echo "Merge remote-tracking branch ${sq}origin/side${sq}" >expect &&
>>  	test_cmp expect actual
>>  )
> 
> This seems to me that it is updating how the output is produced, not
> updating the expected outputs from commands with arguments we have
> been testing.  I have been expecting to see changes to the pieces of
> the code that prepare the expected output, so that we can compare
> old expectations, which would have been expecting something strange,
> with new expectations from the updated code, which would show that
> the new behaviour is a welcome change because it would produce more
> sensible output.
> 
> Having said all that, for this particular test piece, I agree with
> the patch that using --pretty=tformat:%s is a lot more sensible and
> using --pretty=format:%s and expecting its output to be terminated
> with the newline was an unrealistic test.  After all, "tformat" is
> the version with "line terminator" semantics, as opposed to "item
> separator" semantics offered by "--pretty=format:", and the test
> merely was depending on the bug to expect a complete line output
> (i.e. "echo" without "-n"), which you fixed.  The new test makes a
> lot more sense and is relevant to the real world use, and I would
> have preferred to see it explained as such in the log message.

In analogous cases with non-merge commits I have found the
form "--format=...", in t3505-cherry-pick-empty.sh for
example, so I have decided that merges should also use it. The
form "--pretty=tformat:..." seems more explicit to me, so I
have chosen this one.

Will add the message as you have suggested.

>> diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
>> index 10aa028..b164621 100755
>> --- a/t/t7600-merge.sh
>> +++ b/t/t7600-merge.sh
>> @@ -57,11 +57,10 @@ create_merge_msgs () {
>>  		git log --no-merges ^HEAD c2 c3
>>  	} >squash.1-5-9 &&
>>  	: >msg.nologff &&
>> -	echo >msg.nolognoff &&
>> +	: >msg.nolognoff &&
>>  	{
>>  		echo "* tag 'c3':" &&
>> -		echo "  commit 3" &&
>> -		echo
>> +		echo "  commit 3"
>>  	} >msg.log
>>  }
> 
> These are updating the expectation.  We used to expect an
> unnecessary trailing blank line, and now we do not, which clearly
> shows that the previous fix is a welcome change.
> 
>> @@ -71,7 +70,7 @@ verify_merge () {
>>  	git diff --exit-code &&
>>  	if test -n "$3"
>>  	then
>> -		git show -s --pretty=format:%s HEAD >msg.act &&
>> +		git show -s --pretty=tformat:%s HEAD >msg.act &&
>>  		test_cmp "$3" msg.act
>>  	fi
>>  }
> 
> It is hard to judge what is fed as "$3" here without context, but
> this is in line with the "--pretty=tformat aka --format is the
> normal thing to use" we saw in 1507.  The same for the other hunk.
> 
>> @@ -620,10 +619,10 @@ test_expect_success 'merge early part of c2' '
>>  	git tag c6 &&
>>  	git branch -f c5-branch c5 &&
>>  	git merge c5-branch~1 &&
>> -	git show -s --pretty=format:%s HEAD >actual.branch &&
>> +	git show -s --pretty=tformat:%s HEAD >actual.branch &&
>>  	git reset --keep HEAD^ &&
>>  	git merge c5~1 &&
>> -	git show -s --pretty=format:%s HEAD >actual.tag &&
>> +	git show -s --pretty=tformat:%s HEAD >actual.tag &&
>>  	test_cmp expected.branch actual.branch &&
>>  	test_cmp expected.tag actual.tag
>>  '
> 
> How about squashing these two into a single patch, and at the end of
> the log message for 1/2, add this to explain the changes to the
> test:
> 
>     Also existing tests are updated to demonstrate the new
>     behaviour.  Earlier, the tests that used "git show -s
>     --pretty=format:%s", even though "--pretty=format:%s" calls for
>     item separator semantics and does not ask for the terminating
>     newline after the last item, expected the output to end with
>     such a newline.  They were relying on the buggy behaviour.  Use
>     of "--format=%s", which is equivalent to "--pretty=tformat:%s"
>     that asks for a terminating newline after each item, is a more
>     realistic way to use the command.
> 
>     The update to verify_merge in t7600 adjusts the the merge
>     message that used to expect an extra blank line in the output,
>     which has been eliminated with this fix.
> 
> or something like that?
> 
> 

      reply	other threads:[~2014-05-13 20:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-12 23:09 [PATCH v2 0/2] fix 'git show -s' to not add extra terminator after merge commit Max Kirillov
2014-05-12 23:10 ` [PATCH v2 1/2] git-show: " Max Kirillov
2014-05-13  5:57   ` Johannes Sixt
2014-05-13 20:15     ` Max Kirillov
2014-05-12 23:11 ` [PATCH v2 2/2] t: git-show: adapt tests to fixed 'git show' Max Kirillov
2014-05-13 19:26   ` Junio C Hamano
2014-05-13 20:09     ` Max Kirillov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140513200910.GB6857@wheezy.local \
    --to=max@max630.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.