karthik nayak <karthik.188@xxxxxxxxx> writes: > With v14, running `git log --check --pretty=format:"---% h% s" master..` > gives me: > ... > --- fed56bc6cc refs: standardize output of refs_read_symbolic_ref > refs/reftable-backend.c:833: indent with spaces. > + if (ret) > refs/reftable-backend.c:834: indent with spaces. > + ret = -1; > ... Thanks, the above matches what I saw in my message Bence responded to (to which you are responding). I was unsure if/how the status of each "diff --check" is propagated up to the driving "git log", but the job is reading from the output of the command and not using the exit status of "git log --check", so even if "git log --check" did not signal a check failure with its status, it did not matter ;-) A quick local check says "git log --check" does exit with 2 if there is an offending commit in the range, so we should be OK. By the way, I appreciate the cuteness of "% s" but I do not see the point of "% h", as I do not think of a situation where '%h' can ever be empty. It seems that this was carried from the first day when GitHub CI learned the whitespace checks 32c83afc (ci: github action - add check for whitespace errors, 2020-09-22).
