Hi,
On Thu, 2 Aug 2007, Steven Grimm wrote:
Johannes Schindelin wrote:
quoted
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