sorry about the other thread, I saw "extend whitespace checks" and I thought based on what Kartik wrote that `log --check` should have caught it, which is why I thought it might be appropriate there. On Mon Nov 25, 2024 at 03:56, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Bence Ferdinandy" <bence@xxxxxxxxxxxxxx> writes: > >>> At the least you should see `git log`'s output, but if there are issues >>> they should be shown inline. So when you say 'no output' do you mean you >>> see absolutely no output? >> >> Absolutely no output: >> https://asciinema.org/a/lsqp4e1bNst6cFWw9M2jX1IqC >> >> But I figured out why: the whitespace and the tabs were not mixed on the line, >> just across lines. As I read it, that is not an error to have tabs on one line >> and spaces on the next. > > Our .gitattribute starts like so: > > * whitespace=!indent,trail,space > *.[ch] whitespace=indent,trail,space diff=cpp > > so, unless otherwise specified, we frown upon trailing whitespace > and space before tab and indenting with non tab is permitted, but C > source and header files have further care about "indent" (short for > "indent-with-non-tab". > > So mixed or not, if you indented with spaces and not tabs, that > would be noticed. So `git log --check --pretty=format:"---% h% s"` was _not_ supposed to catch this? I ran the CI with this patch again: https://github.com/ferdinandyb/git/actions/runs/12031250376 and it's all green, so wherever this _should_ have been caught: it didn't work. > >> Anyhow that should be now cleared up, thanks. Gotta say, I was expecting to >> learn about internals doing this, but I also ended up picking up a couple of >> usage things as well, like --range-diff for format patch and such. > > I usually have "--whitespace=fix" so if you did "git log" on the > commits I made out of your patches, it is not surprising if your > "log --check" was silent. > > I re-applied your v14 with "git am -s --whitespace=nowarn" and here > is what I saw. > > commit 75a6a3e6597d5f3959eb269122e8c5f4e4baac0e > Author: Bence Ferdinandy <bence@xxxxxxxxxxxxxx> > Date: Thu Nov 21 23:55:03 2024 +0100 > > refs: standardize output of refs_read_symbolic_ref > > When the symbolic reference we want to read with refs_read_symbolic_ref > is actually not a symbolic reference, the files and the reftable > backends return different values (1 and -1 respectively). Standardize > the returned values so that 0 is success, -1 is a generic error and -2 > is that the reference was actually non-symbolic. > > Signed-off-by: Bence Ferdinandy <bence@xxxxxxxxxxxxxx> > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > > refs/reftable-backend.c:833: indent with spaces. > + if (ret) > refs/reftable-backend.c:834: indent with spaces. > + ret = -1; > refs/reftable-backend.c:835: indent with spaces. > + else if (ref.value_type == REFTABLE_REF_SYMREF) > refs/reftable-backend.c:837: indent with spaces. > + else > refs/reftable-backend.c:838: indent with spaces. > + ret = NOT_A_SYMREF; So this did find it. Maybe something is misconfigured in the CI? Best, Bence
