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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 1, 2007, 17:26 UTC
Message-ID: <7v4pjj5fp6.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <vpqwswf8c1i.fsf@bauges.imag.fr>

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

Show 10 quoted lines

> $ touch bar
> $ git diff
> diff --git a/bar b/bar         <--- here ---<
> $ git status
> # On branch master
> nothing to commit (working directory clean)
> $ git diff                     <--- status updated
>                                     the stat in the index.
>
> Is this intended,

Yes. Very much so, intentionally, from very early days of git. This serves as a reminder to the user that he started editing but changed his mind to end up with the same contents as the original, until the next "update-index --refresh" (which is internally invoked from "status").

If the feature still makes sense in the modern world is a different story, but I do find it useful.

Not the made-up "touch" example, but often in real life, I explore a solution by first making changes to one part of the system, realizing a better way is to change the caller of what I initially thought should be changed, edit the file back and modify the caller which is in another file. The former file will show that empty "header-only" diff as the reminder of what I did.

After that, when I reach the point to run "git status", because I have been reminded, I already know about these "tried but discarded" changes, and I find the fact that the they are forgot by that operation very convenient.