Re: [PATCH v6] status: long status advice adapted to recent capabilities

[Rudy Rigot <rudy.rigot@gmail.com>]

> Most likely it wasn't a glitch, but rather (I'd guess) that Windows CI
> uses "main" already, whereas Unix CI's still use "master".

My intuition was that it was something like that indeed.

> you might write the commit message like this

The current phrasing was initially copied as is from a past review
feedback; I have no issues at all replacing it with yours.

> So, if there is an existing test script in which
> these new tests might fit, it's better to add them to that script
> instead

Oh, sorry about that, it hadn't occurred to me that there could be a
downside to using new test script numbers.

I'm 100% on board with the thinking, but I'm struggling quite a bit to
implement it. There are several existing test scripts where these new
tests would fit very well semantically (t7060-wtstatus.sh,c,
t7512-status-help.sh, t7519-status-fsmonitor.sh, ...), and I spent
quite some time yesterday trying to move the 3 news tests to those.
For some reason, test_cmp is not giving me a diff anymore when working
in those script files, so I feel in the dark about what the tests are
failing about, and I'm stumped about what to try next.

What I mean: for instance, if I introduce an intentional mistake in
the test and run './t7065-wtstatus-slow.sh -v', I get this section
that clarifies what the issue is:

--- expected    2022-11-21 23:46:00.000000000 +0000
+++ actual    2022-11-21 23:46:00.000000000 +0000
@@ -1,4 +1,4 @@
-On branch maine
+On branch main

Here is a gist https://gist.github.com/rudyrigot/b31fcb6384e829ca7586818758e48d0b,
with:

- the patch as I currently have it on t7508-status.sh (it's a bit
longer than it was, without the isolation in a separate script I've
had to do a few things to mitigate the side effects from other tests
in the script)
- the end of what I get when running 'sh ./t7508-status.sh -v':
https://gist.github.com/rudyrigot/ee80f3d59231f25698c9dd6c48d8ab85. It
seems like 2 of my 3 tests are failing, but the output isn't very
helpful to figure out why.

Would you (or someone else) have pointers to help me get through this one?

I'm tempted to throw in the towel, since it sounded like it wasn't too
huge a deal if this lived in its separate script file, and that other
people's bandwidth (which I'm aware is what I'm requesting here) is an
even more scarce resource. So I'll submit a new patch with everything
else but this, so there's the option to still proceed with it if
that's the most sensible path forward. But I have to admit I'm quite
frustrated that I couldn't figure this last one out by myself, so I'm
more than happy to dig more into it, if anyone has guidance.

Thanks a lot.