Re: win+VS environment has "cut" but not "paste"?

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Mar 4, 2022, 09:04 UTC
Message-ID: <220304.86mti6f4ny.gmgdl@evledraar.gmail.com>
In-Reply-To: <xmqqee3i2mlw.fsf_-_@gitster.g>

On Thu, Mar 03 2022, Junio C Hamano wrote:

Show 10 quoted lines

> GitHub CI seems to fail due to lack of "paste" for win+VS job.  This
> was somewhat unexpected, as our test scripts seem to make liberal
> use of "cut" that goes together with it.
>
>     https://github.com/git/git/runs/5415486631?check_suite_focus=true#step:5:6199
>
> The particular failure at the URL comes from the use of "paste" in
> 5ea4f3a5 (name-rev: use generation numbers if available,
> 2022-02-28), but it hardly is the first use of the command.  There
> is one use of it in t/aggregate-results.sh in 'master/main' already.

I think it's the first use, the t/aggregate-results.sh is run on "DEFAULT_TEST_TARGET=test make -C t", but we use "DEFAULT_TEST_TARGET=prove".

Re your upthread:

> I personally do not care about the initial latency when viewing the
> output from CI run that may have happened a few dozens of minutes
> ago (I do not sit in front of GitHub CI UI and wait until it
> finishes).

I think this URL is a good example of what I noted in [1]. Your link loads relatively quickly, but I then saw a "linux-TEST-vars" failure and clicked on it, wanting to see why that fails.

It opens relatively quickly, but no failure can be seen. It stalls with a spinner next to "t/run-build-and-test.sh", and stalled like that for 75[2] seconds before finally loading past line ~3.5k to line ~70k showing the relevant failure in t6120*.sh.

I really don't think it's a reasonable claim to say that only "veterans" of git development[3] are likely to find the workflow of seeing a CI failure right away useful, or wanting to browse through the N different "job" failures without having to pre-open them, go find something else to do, then come back to it etc.

I also noted in [1] that it takes a lot more CPU now, so even if that is your workflow for looking at CI you'll need a fairly performant machine if you have a few job failures (which isn't a typical), as each tab will be pegging a CPU core at ~100% for a while.

I have fairly normally spec'd quad-core laptop that I almost never hear, and this new CI UI is pretty reliable in making it sound as though it's about to take flight.

1. https://lore.kernel.org/git/220222.86tucr6kz5.gmgdl@evledraar.gmail.com/
2. I reported large N seconds, but nothing so bad before. For some reason
   this one's particularly bad, but in [1] it was the same CPU use with ~20s
   etc (but that one was 1/2 the amount of lines)
3. https://lore.kernel.org/git/nycvar.QRO.7.76.6.2203011111150.11118@tvgsbejvaqbjf.bet/