From: Junio C Hamano Date: Wed, 01 Aug 2007 17:26:29 GMT Subject: Re: git-diff on touched files: bug or feature? Message-ID: <7v4pjj5fp6.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Matthieu Moy writes: > $ 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.