Hi Junio On Tue, 13 Dec 2022, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > The hard-coded object IDs break the `linux-sha256` job, as pointed out in > > https://github.com/git/git/blob/6ab7651d8669/whats-cooking.txt#L522-L537. > > > > Please squash this in to address this (Junio, please feel free to > > cherry-pick this on top of `tl/ls-tree--pattern` to reduce the number of > > CI failures): > > These days, I gather topics with known CI breakages near the tip of > 'seen', and push out only the good bottom half of 'seen' until such > a topic gets rerolled, at which time it gets added back to the set > of topics pushed out on 'seen' again (and then ejected if it CI > breaks). I excluded the part with the topic from last night's > pushout. > > By the way do you know anything about xterm-256color error in win > test(6)? > > https://github.com/git/git/actions/runs/3676139624/jobs/6216575838#step:5:196 Unfortunately by the time I got back to this mail, the log had expired. Here is a link to the same symptom in a newer build: https://github.com/git/git/actions/runs/4523517641/jobs/7966768829#step:6:63 > I do not think we hard-code any specific terminal name (other than > dumb and possibly vt100) in our tests or binaries, so it may be > coming from the CI runner environment---some parts incorrectly think > xterm-256color is available there while there is no support for the > particular terminal? The TERM is hard-coded in the MSYS2 runtime: https://github.com/git-for-windows/msys2-runtime/commit/bd627864ab4189984cdb0892c00f91e39c4e8243 Note: The MSYS2 runtime merely wants to ensure that `TERM` is set; If it already has a value, that value remains unchanged. And to save on bandwidth/time (in a desperate attempt to counter the ever-growing runtimes of Git's CI builds), I liberally exclude files from the "minimal subset of Git for Windows' SDK", e.g. `/usr/lib/terminfo/` and `/usr/share/terminfo/`. That's why `tput` cannot figure out what to do with this `TERM` value. If these `tput` errors become too much of a sore in your eye, I see two ways forward: - Set `TERM=dumb` for the Windows jobs - Use a simple shim like this one in `ci/` (and maybe even in `t/test-lib.sh`): tput() { printf '\e[%sm%s'"$(test sgr0 != $1 || echo '\x0f')" "$( \ case $1 in bold) echo 1;; dim) echo 2;; rev) echo 7;; setaf) echo 3$2;; setab) echo 4$2;; esac \ )" } Personally, I do not really want to work on this, not before much bigger fish are fed first. For example, the friction regarding the CI build times is becoming quite crushing. Ciao, Johannes