On Fri, Jul 25, 2025 at 10:08:23AM +0200, hi@arnes.space wrote: > i understand, and i get why that's useful from a performance > perspective. but i think i'm arguing at a different level. > > i'm saying: `--name-only` can change whether a file appears in `git > diff`'s output or not. that is surprising, because the documentation > mentions nothing about this, nor does the flag itself sound like it > would. > > my argument is that the non-buggy behavior would be to make > `--name-only` more consistent with the rest of `git diff`, because it > would be less surprising. the fact that `git diff` does not look at file > contents when the flag is given to me is just an implementation detail. Yeah, that line of thinking makes sense to me. It's an optimization not to look at the file contents when we do not need to. But if you've asked to do a more specific content-level comparison, then we could do that. I think Junio's response earlier in the thread discusses this, and how we already respect "-w" for "--quiet". I'm not sure I agree with this part that he wrote, though: > It is just --raw, --name-only, --name-status, and --checkdiff output > formats that deliberately ignore content based ignore mechanisms. > > And I do not think it would be a good change to have them follow > "ignore" bits. When asked "has this path been modified?" "what are > the before and after blob object names?" etc., it does not make sense > for the answer to be different depending on the presense of -w or > --ignore-matching options. I can see how it gets weird when you ask for --raw, but the object ids we show do not necessarily reflect the content we actually compared. But it is even weirder to me that something like: git init echo 'foo' >file git add . && git commit -m base echo 'foo ' >file git diff -w --stat -p --name-only will show "file" in the name-only list, but not in the accompanying stat or patch! If the user has bothered to ask for a whitespace-only diff, then it feels to me like the least-bad thing is to apply that consistently to all output. I do wonder if changing it at this point would somehow break somebody's workflow or have unexpected fallout, though. -Peff
