git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] tests: fix incorrect --write-junit-xml code
Date: Mon, 8 Aug 2022 15:40:09 +0200 (CEST)	[thread overview]
Message-ID: <s4s2qr56-2948-p025-rrq7-qq56p9oo844r@tzk.qr> (raw)
In-Reply-To: <xmqq35f38yeb.fsf@gitster.g>

Hi Junio,

On Thu, 14 Jul 2022, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> >     Unfortunately, I noticed this regression no earlier than when I needed
> >     to validate Git for Windows v2.37.1. Since v2.37.1 was an embargoed
> >     release, I could not use GitHub Actions for the CI testing, so I had to
> >     reinstate Git's Azure Pipeline.
>
> I wonder if it would make your life easier

It would make my life easier if Chesterton's Fences were left alone ;-)

> if the same GitHub Actions CI stuff were available for the Cabal
> repository we use for embargoed work, by allowing you to use the same
> validation for usual releases and the enbargoed ones?

GitHub Actions are available in the Cabal repository. The problem is that
due to the private nature of said repository, the number of included build
minutes is limited.

I did manage to get GitHub to sponsor the Git project specifically to
increase said build minutes. But that only scratches the problem at the
surface.

I still think that we need to slow the heck down with refactoring for
refactoring's sake because it's not only the CI builds that are affected.
I pay a lot of time to accommodate for those refactorings, and so do
others, and the benefit of most of those refactorings escapes me. My best
guess is that they adapt Git's source code to individual tastes, which is
of course a losing game because too many individuals with too many
different tastes are involved in the Git project. Unless we start valuing
particular individuals' tastes over others', which I believe we should not
do.

You asked me in private to provide more reviews for those refactorings so
that they see some push-back, but I lack the bandwidth for that.

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> >  t/test-lib-junit.sh | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/t/test-lib-junit.sh b/t/test-lib-junit.sh
> > index c959183c7e2..79c31c788b9 100644
> > --- a/t/test-lib-junit.sh
> > +++ b/t/test-lib-junit.sh
> > @@ -46,7 +46,7 @@ finalize_test_case_output () {
> >  	shift
> >  	case "$test_case_result" in
> >  	ok)
> > -		set "$*"
> > +		set -- "$*"
> >  		;;
> >  	failure)
> >  		junit_insert="<failure message=\"not ok $test_count -"
> > @@ -65,17 +65,17 @@ finalize_test_case_output () {
> >  			junit_insert="$junit_insert<system-err>$(xml_attr_encode \
> >  				"$(cat "$GIT_TEST_TEE_OUTPUT_FILE")")</system-err>"
> >  		fi
> > -		set "$1" "      $junit_insert"
> > +		set -- "$1" "      $junit_insert"
> >  		;;
> >  	fixed)
> > -		set "$* (breakage fixed)"
> > +		set -- "$* (breakage fixed)"
> >  		;;
> >  	broken)
> > -		set "$* (known breakage)"
> > +		set -- "$* (known breakage)"
> >  		;;
> >  	skip)
> >  		message="$(xml_attr_encode --no-lf "$skipped_reason")"
> > -		set "$1" "      <skipped message=\"$message\" />"
> > +		set -- "$1" "      <skipped message=\"$message\" />"
> >  		;;
> >  	esac
>
> OK.  Ancient shells did not understand "--" and it was idiomatic to
> say "set x ...; shift", but we already do assume "set --" is usable
> everywhere we care about in many of our scripts and tests.
>
> Looks good to me.
>
> Thanks.  Will queue.

Thank you,
Dscho

  parent reply	other threads:[~2022-08-08 13:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-14  9:00 [PATCH] tests: fix incorrect --write-junit-xml code Johannes Schindelin via GitGitGadget
2022-07-14 16:14 ` Junio C Hamano
2022-07-15  9:25   ` Ævar Arnfjörð Bjarmason
2022-08-08 13:40   ` Johannes Schindelin [this message]
2022-08-08 16:47     ` Junio C Hamano
2022-08-09  8:42       ` Johannes Schindelin
2022-08-10 18:44         ` Junio C Hamano
2022-08-12 21:00           ` Johannes Schindelin
2022-07-15  9:35 ` never refactor v.s. testing (was: [PATCH] tests: fix incorrect --write-junit-xml code) Ævar Arnfjörð Bjarmason

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=s4s2qr56-2948-p025-rrq7-qq56p9oo844r@tzk.qr \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).