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

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

Hi,

On Thu, 2 Aug 2007, Steven Grimm wrote:

> 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