Re: git-diff on touched files: bug or feature?
From: Matthieu Moy <hidden>
Date: 2016-06-15 22:43:25
Johannes Schindelin [off-list ref] writes:
Okay, I'll answer just this one, instead of pointing you to the thread that I've been pointing to twice now
The link was probably not the right one since I saw only two [PATCH] message, but yes, I remember a thread pointing out why git-status had to update the index. I'm not arguing against that, I'm happy with the current git-status behavior, but I find the git-diff one inconsistant with git-status, and still don't understand any reason why a normal user would want a difference.
When is the time to say "git status"? It is just before committing. I.e when you really think that you're done editing, and want to have the end picture. "git status" only gives you names, and therefore it _has_ to update the index if it got out of sync, to show meaningful results. When is the time to say "git diff"? Much more often. In the middle of your work. And there it would be _disruptive_ if it updated the index all the time, especially if you have a quite large working tree.
That's your point of view, but I do not share it. Depending on the kind of things I'm doing, I usually run status regularly, because it's short to read, and it shows me both staged and unstaged changes. git-status tells me if I did something obviously totally wrong (changing a file on which I was not working, deleting something important ...), and after that, git-diff gives me a finer-grained vision of what I did. Does this really sound so much irreasonable to you? -- Matthieu