Linus Torvalds wrote:
It's not that the old output is "useful" in itself, but it's important for people to know that the index is clean. So I'd suggest just setting a flag when the header isn't printed, and then printing out a single line at the end about "git index not up-to-date" or something.
Or even a count of the number of files whose index data is unclean. I'd be fine with that as a suffix to the diff output.
Doing a "git diff" cannot actually update the index (since it very much has to work on a read-only setup too), which is why the index _stays_ stale unless something is done (eg "git status") to refresh it. And it's that stale index that continues to make for bad performance without any indication of why that is a problem.
I totally agree that there needs to be a way to tell if the index is clean or not. I do wonder if the default output of "git diff" is the right place for that information, but if the notification can be collapsed to a line or two (rather than the unbounded number of lines that it potentially outputs now) then that's probably good enough.
Actually, though this will probably make people roll their eyes, before this discussion I would have guessed that "git status" would be the command that would tell you the index was out of date, and that there'd be a separate command (say, "git update-index"?) that you could then use to sync things up again. The fact that "git status" is really "git update index a little bit then show status" was not something I expected; it presents itself as a query utility, not an update utility, so I would have expected it to be read-only. Its index-modifying behavior is not even hinted at in the documentation (a patch for which follows.)
-Steve - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
