git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Tiago Botelho <tiagonbotelho@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org, christian.couder@gmail.com,
	haraldnordgren@gmail.com,
	Tiago Botelho <tiagonbotelho@hotmail.com>
Subject: Re: [PATCH v6] Implement --first-parent for git rev-list --bisect
Date: Tue, 28 Aug 2018 13:45:19 -0700	[thread overview]
Message-ID: <xmqqbm9mfcf4.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <xmqqy3cqfi8c.fsf@gitster-ct.c.googlers.com> (Junio C. Hamano's message of "Tue, 28 Aug 2018 11:39:47 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> I would have preferred to reuse the already existing commits generated in
>> the `setup` phase rather than generating yet another batch, and to not
>> introduce an inconsistent way to present a commit graph (compare your
>> diagram with the one in
>> https://github.com/git/git/blob/v2.18.0/t/t6002-rev-list-bisect.sh#L64-L90
>> i.e. *in the same file*)
>
> As I already said in the previous round, I do agree with these.
> That is, ...
>
>>>  
>>> +# We generate the following commit graph:
>>> +#
>>> +#   B ------ C
> ... the above graph construction should not be necessary.  An
> earlier part of t6002 would have already created a history of
> suitable shape to use for writing the following tests.

Something like the following, perhaps?  I have a feeling that use of
test-output-expect-success is trying to be too cute without making
the result easier to read, and also makes it harder to debug the
test script when it does not work as expected (e.g. you need to see
where the output from the actual command is stored by going to the
definition of the shell function), and would have preferred to see
these three tests written without it (and instead using explicit
'expect' vs 'actual' comparison), but at least the patch below shows
what I meant when I suggested updating the tests to reuse the
existing history (I do not speak for Johannes, but I am guessing we
are on the same page on this one).

Thanks.

 t/t6002-rev-list-bisect.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/t/t6002-rev-list-bisect.sh b/t/t6002-rev-list-bisect.sh
index a661408038..d27d0087d6 100755
--- a/t/t6002-rev-list-bisect.sh
+++ b/t/t6002-rev-list-bisect.sh
@@ -263,4 +263,50 @@ test_expect_success 'rev-parse --bisect can default to good/bad refs' '
 	test_cmp expect.sorted actual.sorted
 '
 
+# See the drawing near the top --- e4 is in the middle of the first parent chain
+printf "%s\n" e4 |
+test_output_expect_success '--bisect --first-parent' '
+	git rev-list --bisect --first-parent E ^F
+'
+
+printf "%s\n" E e1 e2 e3 e4 e5 e6 e7 e8 |
+test_output_expect_success "--first-parent" '
+	git rev-list --first-parent E ^F
+'
+
+test_output_expect_success '--bisect-vars --first-parent' '
+	git rev-list --bisect-vars --first-parent E ^F
+' <<-EOF
+	bisect_rev='e5'
+	bisect_nr=4
+	bisect_good=4
+	bisect_bad=3
+	bisect_all=9
+	bisect_steps=2
+EOF
+
+test_expect_success '--bisect-all --first-parent' '
+	cat >expect <<-EOF &&
+	$(git rev-parse tags/e5) (dist=4)
+	$(git rev-parse tags/e4) (dist=4)
+	$(git rev-parse tags/e6) (dist=3)
+	$(git rev-parse tags/e3) (dist=3)
+	$(git rev-parse tags/e7) (dist=2)
+	$(git rev-parse tags/e2) (dist=2)
+	$(git rev-parse tags/e8) (dist=1)
+	$(git rev-parse tags/e1) (dist=1)
+	$(git rev-parse tags/E) (dist=0)
+	EOF
+
+	# Make sure we have the same entries, nothing more, nothing less
+	git rev-list --bisect-all --first-parent E ^F >actual &&
+	sort actual >actual.sorted &&
+	sort expect >expect.sorted &&
+	test_cmp expect.sorted actual.sorted &&
+	# Make sure the entries are sorted in the dist order
+	sed -e "s/.*(dist=\([1-9]*[0-9]\)).*/\1/" actual >actual.dists &&
+	sort -r -n actual.dists >actual.dists.sorted &&
+	test_cmp actual.dists.sorted actual.dists
+'
+
 test_done

  reply	other threads:[~2018-08-28 20:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-28 12:32 [PATCH v6] Implement --first-parent for git rev-list --bisect Tiago Botelho
2018-08-28 13:21 ` Johannes Schindelin
2018-08-28 18:39   ` Junio C Hamano
2018-08-28 20:45     ` Junio C Hamano [this message]
2018-08-28 21:24       ` Junio C Hamano
2018-08-28 16:45 ` Junio C Hamano
2018-09-02  7:34   ` Duy Nguyen
2018-09-02  7:42     ` [PATCH] bisect.c: make show_list() build again Nguyễn Thái Ngọc Duy
2018-09-02  7:57       ` Christian Couder
2018-09-03 17:31         ` Duy Nguyen
2018-09-04 11:13           ` Christian Couder
2018-09-04 19:32     ` [PATCH v6] Implement --first-parent for git rev-list --bisect Junio C Hamano

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=xmqqbm9mfcf4.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=haraldnordgren@gmail.com \
    --cc=tiagonbotelho@gmail.com \
    --cc=tiagonbotelho@hotmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).