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

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Aug 2, 2007, 15:45 UTC
Message-ID: <vpqtzrivt2n.fsf@bauges.imag.fr>
In-Reply-To: <Pine.LNX.4.64.0708021614420.14781@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

Show 12 quoted lines

> 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