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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 2, 2007, 15:23 UTC
Message-ID: <Pine.LNX.4.64.0708021614420.14781@racer.site>
In-Reply-To: <46B1F3F4.5030504@midwinter.com>

Hi,

On Thu, 2 Aug 2007, Steven Grimm wrote:

Show 21 quoted lines

> Johannes Schindelin wrote:
> > This use case has not much to do with new users.  A new user _has_ to know
> > that updating all files, even if their content does not change, is not
> > right.
> >   
> 
> Someone who has used, say, Subversion might have a perfectly reasonable
> expectation that "git diff" will show differences in content, and when there
> are no differences in content, will not mention a file at all. Other version
> control systems have "diff" commands that ignore touched files.
> 
> I admit I also thought the empty diffs were a bug (albeit a minor one not
> worth making noise about) until this thread. Now I understand why it happens,
> though I still think we'd be better off just not displaying the filename in
> git-diff until we know there's an actual diff to display.
> 
> I certainly don't think the "it's a feature: it reminds you when you've edited
> a file without changing it" argument holds any water at all. If that were
> truly the intent, if we truly considered that to be useful information a
> developer would want to get at after the fact, then why would git-status throw
> away that information?

Okay, I'll answer just this one, instead of pointing you to the thread that I've been pointing to twice now (because your ideas about how git should work are usually similar to mine, and by way of saying thanks for your contributions):

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.

But then, normal users do not touch all the files.  They don't.

So I doubt that in the common case the subject we are discussing matters at all.

Yes, "perl -pi" is something I used myself. Yes, I think it is a bug that it writes new files when it does not really change anything. And yes, I had a script lying somewhere on my backup hard disk which uses some evil "git diff --name-only | xargs bla" mantra (it does not even use the --quiet option, since that was not invented back then) to actually _undo_ the effects by setting the timestamps back, since the full compilation time in that project _hurt_.

But it is hardly an operation that I use daily. Hardly even twice a year.

Ciao, Dscho