Re: git-diff on touched files: bug or feature?

Johannes Schindelin wrote:

Someone who has used, say, Subversion might have a perfectly reasonable expectation that "git diff" will show differences in content, and when there are no differences in content, will not mention a file at all. Other version control systems have "diff" commands that ignore touched files.

I admit I also thought the empty diffs were a bug (albeit a minor one not worth making noise about) until this thread. Now I understand why it happens, though I still think we'd be better off just not displaying the filename in git-diff until we know there's an actual diff to display.

I certainly don't think the "it's a feature: it reminds you when you've edited a file without changing it" argument holds any water at all. If that were truly the intent, if we truly considered that to be useful information a developer would want to get at after the fact, then why would git-status throw away that information? If I check to see what files I've modified/added (for which I run git-status) why does that automatically imply I am no longer interested in being reminded that I have saved a file without making changes, especially given that such files *don't* show up in the git-status output? git-status is silently losing information here; it gives you no indication that it has refreshed the index for those touched-but-not-edited files.

Now, I happen to think throwing away that information is just fine, because I don't think I have ever once cared to know that I touched a file but didn't change it. But fundamentally it's either a piece of information we care about (in which case we shouldn't go silently discarding it) or not (in which case it is just clutter in git-diff).

In the meantime, though, it's trivial enough to put a wrapper around git-diff to filter out the diffless files. I haven't cared enough to bother, but if I did it'd be just a few lines of Perl, no big deal.

-Steve