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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Thu, 2 Aug 2007, Matthieu Moy wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > The default should be tuned for users who perform manual editing
> > with status checks.  And power users like yourself who run "bulk
> > touch indiscriminately but modify only some" scripts should
> > learn to run git-status (or "update-index --refresh") after such
> > operation.  Swapping the defaults to optimize for the abnormal
> > case is madness.
> 
> I fully agree that git should be optimized for the common case. But
> even for the common case, I also find the feature strange. You didn't
> answer that part of my message, but I still fail to see a rationale
> for making "git-diff; git-status" different from "git-status; git-diff".

For performance reasons, git always compares the files' stat information 
with that stored in the index.

By updating the file, you make that check fail always.

Without updating the index (which is not a read-only operation, and 
therefore must not be done when doing a read-only operation like diff), 
you will therefore _destroy_ the main reason of git's kick-ass 
performance.

So when you do "git diff" and it tells you all those diff lines, while no 
file was really changed, it tells you "get your act together!  You just 
_willfully_ slowed down git's performance".

Okay?

Ciao,
Dscho

P.S.: I wish we had something similar for the cases that you did not "git 
gc", so that people, posting to their blogs all over the world that they 
became benchmark experts overnight and tested git and it sucks, would know 
that it is not git that sucks.