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

Johannes Schindelin [off-list ref] writes:

On Thu, 2 Aug 2007, Matthieu Moy wrote:

quoted

quoted

If the feature still makes sense in the modern world is a
different story, but I do find it useful.

I understand that it can be usefull, but I really don't like having it
by default (is there a way to deactivate it BTW?).

Yes.  Just call "git status" and be done with it.

That's not what I mean (my original message mentionned that already
BTW). By "deactivate", I mean "make git-diff never show empty diffs".
I don't want to run two commands where I need only one.

-- 
Matthieu

Hi,

On Thu, 2 Aug 2007, Matthieu Moy wrote:

Johannes Schindelin [off-list ref] writes:

quoted

On Thu, 2 Aug 2007, Matthieu Moy wrote:

quoted

quoted

If the feature still makes sense in the modern world is a
different story, but I do find it useful.

I understand that it can be usefull, but I really don't like having it
by default (is there a way to deactivate it BTW?).

Yes.  Just call "git status" and be done with it.

That's not what I mean (my original message mentionned that already
BTW). By "deactivate", I mean "make git-diff never show empty diffs".
I don't want to run two commands where I need only one.

Then don't touch the files you do not want to touch!  Or if you want to 
have it convenient, and have a script that touches everything, even if it 
does not change the contents, just add "git add -u" at the end of the 
script".  Not that difficult.

Ciao,
Dscho

I find comments like this to be counter productive.
Admin it, git porcelain still has some work to be done.  We can't  
expect new users to know the git internals workflow before they can  
use git effectively.  We can expect new users to read the man pages,  
but not necessarely expect them to understand all the plumbing  
implied by what they read.  Here I think M.Moy understand the  
plumbing and could silently deal with it.  But instead he decided to  
help improve git and decided to raise a flag about inconsistencies he  
faced.  We should never answer request for improvement with ' Just do  
X and be done with it'.  This is a 'geek' answer to a legitime comment.

I know the goal of git is not to reign over the world of vcs, but  
it's not a reason to refuse to improve it when constructive comments  
are made about it.

- jfv

Le 07-08-02 à 06:48, Johannes Schindelin a écrit :

Hi,

On Thu, 2 Aug 2007, Matthieu Moy wrote:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

On Thu, 2 Aug 2007, Matthieu Moy wrote:

quoted

quoted

If the feature still makes sense in the modern world is a
different story, but I do find it useful.

I understand that it can be usefull, but I really don't like  
having it
by default (is there a way to deactivate it BTW?).

Yes.  Just call "git status" and be done with it.

That's not what I mean (my original message mentionned that already
BTW). By "deactivate", I mean "make git-diff never show empty diffs".
I don't want to run two commands where I need only one.

Then don't touch the files you do not want to touch!  Or if you  
want to
have it convenient, and have a script that touches everything, even  
if it
does not change the contents, just add "git add -u" at the end of the
script".  Not that difficult.

Ciao,
Dscho

Hi,

[please do not top-post.  Either comment on what you quote, or delete it.]

On Thu, 2 Aug 2007, Jean-Fran?ois Veillette wrote:

Admin it, git porcelain still has some work to be done.

No need to argue there, I admit it.

We can't expect new users to know the git internals workflow before they 
can use git effectively.

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.

At least we do not commit empty changes like CVS did all too happily.

Ciao,
Dscho

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? If I check to see what 
files I've modified/added (for which I run git-status) why does that 
automatically imply I am no longer interested in being reminded that I 
have saved a file without making changes, especially given that such 
files *don't* show up in the git-status output? git-status is silently 
losing information here; it gives you no indication that it has 
refreshed the index for those touched-but-not-edited files.

Now, I happen to think throwing away that information is just fine, 
because I don't think I have ever once cared to know that I touched a 
file but didn't change it. But fundamentally it's either a piece of 
information we care about (in which case we shouldn't go silently 
discarding it) or not (in which case it is just clutter in git-diff).

In the meantime, though, it's trivial enough to put a wrapper around 
git-diff to filter out the diffless files. I haven't cared enough to 
bother, but if I did it'd be just a few lines of Perl, no big deal.

-Steve

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

The default is now to not show the diff --git header line if the file's
timestamp has changed but the contents and/or file mode haven't.

Signed-off-by: Steven Grimm <redacted>
---

	Okay, enough arguing about whether the empty diff lines are
	useful or not -- here's a patch to get rid of them.

	This passes all the existing "diff" tests, with one minor tweak
	to the symlink test (since it expected the old behavior.)
	If someone can find a case where this will spit out an actual
	diff but not the "diff --git" line, please tell me how to make
	that happen. The code *looks* like it has such a path, but I was
	unable to make it happen in my ad-hoc testing and it doesn't
	happen in any of the existing diff test cases.

	Personally I'm in favor of doing away with the option altogether
	and having the code always work the way it works by default with
	this patch, but if some people find the old behavior useful they
	can still get at it with the new option.

	My xmalloc() call allocates a few more bytes than strictly
	needed, but I found it was less readable to subtract out the
	space taken by the "%s" tokens in the format string.

 Documentation/diff-options.txt |    4 ++
 diff.c                         |   46 ++++++++++++++++++++++++++----
 diff.h                         |    3 +-
 t/t4011-diff-symlink.sh        |    2 +-
 t/t4021-diff-untouched.sh      |   61 ++++++++++++++++++++++++++++++++++++++++
 5 files changed, 108 insertions(+), 8 deletions(-)
 create mode 100755 t/t4021-diff-untouched.sh

diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 228ccaf..12ad048 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt

@@ -185,5 +185,9 @@
 --no-ext-diff::
 	Disallow external diff drivers.
 
+--show-touched::
+	Display the "diff --git" message for files whose modification
+	timestamps have changed, even if the contents don't differ.
+
 For more detailed explanation on these common options, see also
 link:diffcore.html[diffcore documentation].

diff --git a/diff.c b/diff.c
index a5fc56b..e1112e5 100644
--- a/diff.c
+++ b/diff.c

@@ -1260,6 +1260,9 @@ static const char *diff_funcname_pattern(struct diff_filespec *one)
 	return NULL;
 }
 
+/* The message that gets printed at the top of a file's diffs */
+#define DIFF_MESSAGE_FORMAT_STRING "%sdiff --git %s %s%s\n"
+
 static void builtin_diff(const char *name_a,
 			 const char *name_b,
 			 struct diff_filespec *one,

@@ -1268,6 +1271,7 @@ static void builtin_diff(const char *name_a,
 			 struct diff_options *o,
 			 int complete_rewrite)
 {
+	char *diff_message;
 	mmfile_t mf1, mf2;
 	const char *lbl[2];
 	char *a_one, *b_two;

@@ -1278,25 +1282,50 @@ static void builtin_diff(const char *name_a,
 	b_two = quote_two("b/", name_b + (*name_b == '/'));
 	lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
 	lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
-	printf("%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
+
+	/*
+	 * Generate the "diff --git" status message. By default we only
+	 * show it if we have a difference to display, but the user can
+	 * optionally choose to show it for all files that we examine for
+	 * content differences (e.g. because their timestamps have changed.)
+	 */
+	diff_message = xmalloc(strlen(set) + strlen(reset) +
+			       strlen(a_one) + strlen(b_two) +
+			       sizeof(DIFF_MESSAGE_FORMAT_STRING));
+	sprintf(diff_message, DIFF_MESSAGE_FORMAT_STRING,
+	        set, a_one, b_two, reset);
+	if (o->show_touched) {
+		fputs(diff_message, stdout);
+		*diff_message = '\0';
+	}
+
 	if (lbl[0][0] == '/') {
 		/* /dev/null */
-		printf("%snew file mode %06o%s\n", set, two->mode, reset);
+		printf("%s%snew file mode %06o%s\n",
+		       diff_message, set, two->mode, reset);
+		*diff_message = '\0';
 		if (xfrm_msg && xfrm_msg[0])
 			printf("%s%s%s\n", set, xfrm_msg, reset);
 	}
 	else if (lbl[1][0] == '/') {
-		printf("%sdeleted file mode %06o%s\n", set, one->mode, reset);
+		printf("%s%sdeleted file mode %06o%s\n",
+		       diff_message, set, one->mode, reset);
+		*diff_message = '\0';
 		if (xfrm_msg && xfrm_msg[0])
 			printf("%s%s%s\n", set, xfrm_msg, reset);
 	}
 	else {
 		if (one->mode != two->mode) {
-			printf("%sold mode %06o%s\n", set, one->mode, reset);
+			printf("%s%sold mode %06o%s\n",
+			       diff_message, set, one->mode, reset);
 			printf("%snew mode %06o%s\n", set, two->mode, reset);
+			*diff_message = '\0';
+		}
+		if (xfrm_msg && xfrm_msg[0]) {
+			printf("%s%s%s%s\n",
+			       diff_message, set, xfrm_msg, reset);
+			*diff_message = '\0';
 		}
-		if (xfrm_msg && xfrm_msg[0])
-			printf("%s%s%s\n", set, xfrm_msg, reset);
 		/*
 		 * we do not run diff between different kind
 		 * of objects.

@@ -1304,6 +1333,8 @@ static void builtin_diff(const char *name_a,
 		if ((one->mode ^ two->mode) & S_IFMT)
 			goto free_ab_and_return;
 		if (complete_rewrite) {
+			fputs(diff_message, stdout);
+			*diff_message = '\0';
 			emit_rewrite_diff(name_a, name_b, one, two,
 					o->color_diff);
 			o->found_changes = 1;

@@ -1372,6 +1403,7 @@ static void builtin_diff(const char *name_a,
 	diff_free_filespec_data(two);
 	free(a_one);
 	free(b_two);
+	free(diff_message);
 	return;
 }
 

@@ -2381,6 +2413,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
 		options->allow_external = 1;
 	else if (!strcmp(arg, "--no-ext-diff"))
 		options->allow_external = 0;
+	else if (!strcmp(arg, "--show-touched"))
+		options->show_touched = 1;
 	else
 		return 0;
 	return 1;

diff --git a/diff.h b/diff.h
index 9fd6d44..e172ecf 100644
--- a/diff.h
+++ b/diff.h

@@ -61,7 +61,8 @@ struct diff_options {
 		 has_changes:1,
 		 quiet:1,
 		 allow_external:1,
-		 exit_with_status:1;
+		 exit_with_status:1,
+		 show_touched:1;
 	int context;
 	int break_opt;
 	int detect_rename;

diff --git a/t/t4011-diff-symlink.sh b/t/t4011-diff-symlink.sh
index c6d1369..910c6cc 100755
--- a/t/t4011-diff-symlink.sh
+++ b/t/t4011-diff-symlink.sh

@@ -60,7 +60,7 @@ test_expect_success \
     'diff identical, but newly created symlink' \
     'sleep 3 &&
     ln -s xyzzy frotz &&
-    git diff-index -M -p $tree > current &&
+    git diff-index --show-touched -M -p $tree > current &&
     compare_diff_patch current expected'
 
 cat > expected << EOF

diff --git a/t/t4021-diff-untouched.sh b/t/t4021-diff-untouched.sh
new file mode 100755
index 0000000..a8153e0
--- /dev/null
+++ b/t/t4021-diff-untouched.sh

@@ -0,0 +1,61 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Johannes Schindelin
+#
+
+test_description='Test display and suppression of unmodified files.
+
+'
+. ./test-lib.sh
+. ../diff-lib.sh
+
+touch empty
+
+test_expect_success 'no output when no changes' '
+
+	echo foobar > file1 &&
+	chmod 644 file1 &&
+	git add file1 &&
+	git commit -m "initial commit" &&
+	git diff > current &&
+	compare_diff_patch current empty
+'
+
+test_expect_success 'no output when file touched' '
+
+	sleep 1 &&
+	touch file1 &&
+	git diff > current &&
+	compare_diff_patch current empty
+'
+
+cat > expected << EOF
+diff --git a/file1 b/file1
+EOF
+
+test_expect_success 'output when --show-touched is used' '
+
+	git diff --show-touched > current &&
+	compare_diff_patch current expected
+'
+
+test_expect_success 'no output when index updated with touched file' '
+
+	git add file1 &&
+	git diff --cached > current &&
+	compare_diff_patch current empty
+'
+
+cat > expected << EOF
+diff --git a/file1 b/file1
+old mode 100644
+new mode 100755
+EOF
+
+test_expect_success 'output when mode is changed' '
+
+	chmod 755 file1 &&
+	git diff > current &&
+	compare_diff_patch current expected
+'
+test_done

-- 
1.5.3.rc2.4.g726f9

On Thu, 2 Aug 2007, Steven Grimm wrote:

The default is now to not show the diff --git header line if the file's
timestamp has changed but the contents and/or file mode haven't.

I don't mind this per se, but I'd *really* want some kind of warning that 
the index is not up-to-date.

Otherwise, git usage can be horrendously slow, and you're never even told 
why. The diffs just take lots of time (because it reads each file), but 
the output is empty.

	Personally I'm in favor of doing away with the option altogether
	and having the code always work the way it works by default with
	this patch, but if some people find the old behavior useful they
	can still get at it with the new option.

It's not that the old output is "useful" in itself, but it's important for 
people to know that the index is clean. So I'd suggest just setting a flag 
when the header isn't printed, and then printing out a single line at the 
end about "git index not up-to-date" or something.

Doing a "git diff" cannot actually update the index (since it very much 
has to work on a read-only setup too), which is why the index _stays_ 
stale unless something is done (eg "git status") to refresh it. And it's 
that stale index that continues to make for bad performance without any 
indication of why that is a problem.

			Linus

Linus Torvalds wrote:

It's not that the old output is "useful" in itself, but it's important for 
people to know that the index is clean. So I'd suggest just setting a flag 
when the header isn't printed, and then printing out a single line at the 
end about "git index not up-to-date" or something.
  

Or even a count of the number of files whose index data is unclean. I'd 
be fine with that as a suffix to the diff output.

Doing a "git diff" cannot actually update the index (since it very much 
has to work on a read-only setup too), which is why the index _stays_ 
stale unless something is done (eg "git status") to refresh it. And it's 
that stale index that continues to make for bad performance without any 
indication of why that is a problem.
  

I totally agree that there needs to be a way to tell if the index is 
clean or not. I do wonder if the default output of "git diff" is the 
right place for that information, but if the notification can be 
collapsed to a line or two (rather than the unbounded number of lines 
that it potentially outputs now) then that's probably good enough.

Actually, though this will probably make people roll their eyes, before 
this discussion I would have guessed that "git status" would be the 
command that would tell you the index was out of date, and that there'd 
be a separate command (say, "git update-index"?) that you could then use 
to sync things up again. The fact that "git status" is really "git 
update index a little bit then show status" was not something I 
expected; it presents itself as a query utility, not an update utility, 
so I would have expected it to be read-only. Its index-modifying 
behavior is not even hinted at in the documentation (a patch for which 
follows.)

-Steve

Signed-off-by: Steven Grimm <redacted>
---
 Documentation/git-status.txt |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 6f16eb0..8fd0fc6 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt

@@ -27,6 +27,13 @@ The command takes the same set of options as `git-commit`; it
 shows what would be committed if the same options are given to
 `git-commit`.
 
+If any paths have been touched in the working tree (that is,
+their modification times have changed) but their contents and
+permissions are identical to those in the index file, the command
+updates the index file. Running `git-status` can thus speed up
+subsequent operations such as `git-diff` if the working tree
+contains many paths that have been touched but not modified.
+
 
 OUTPUT
 ------

-- 
1.5.3.rc2.4.g726f9

Signed-off-by: Steven Grimm <redacted>
---
	This is based on (and includes) Junio's patch. This should
	hopefully address the "I want to know when my index is very
	stale" problem with both his original patch and mine.

	If we are running a pager, I output the warning to standard
	output so it doesn't get immediately scrolled off the screen by
	the paged diff output. Otherwise I output to standard error
	which is really the more appropriate place for the warning.
	Obviously that is no good if the user is running his own pager,
	but I'm not sure how to detect that and not cause problems for
	diffs that are piped into other programs.

 diff.c     |   59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
 diffcore.h |    1 +
 2 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/diff.c b/diff.c
index a5fc56b..7b11195 100644
--- a/diff.c
+++ b/diff.c

@@ -2979,7 +2979,7 @@ int diff_flush_patch_id(struct diff_options *options, unsigned char *sha1)
 
 	free(q->queue);
 	q->queue = NULL;
-	q->nr = q->alloc = 0;
+	q->nr = q->alloc = q->removed = 0;
 
 	return result;
 }

@@ -3015,6 +3015,17 @@ void diff_flush(struct diff_options *options)
 	int i, output_format = options->output_format;
 	int separator = 0;
 
+	if (q->removed > 0 && ! (output_format & DIFF_FORMAT_NO_OUTPUT)) {
+		char *format = "Warning: %d %s touched but not modified. "
+			       "Consider running git-status.\n";
+		char *plural = q->removed == 1 ? "path" : "paths";
+
+		if (pager_in_use)
+			printf(format, q->removed, plural);
+		else
+			fprintf(stderr, format, q->removed, plural);
+	}
+
 	/*
 	 * Order: raw, stat, summary, patch
 	 * or:    name/name-status/checkdiff (other bits clear)

@@ -3084,7 +3095,7 @@ void diff_flush(struct diff_options *options)
 free_queue:
 	free(q->queue);
 	q->queue = NULL;
-	q->nr = q->alloc = 0;
+	q->nr = q->alloc = q->removed = 0;
 }
 
 static void diffcore_apply_filter(const char *filter)

@@ -3093,7 +3104,7 @@ static void diffcore_apply_filter(const char *filter)
 	struct diff_queue_struct *q = &diff_queued_diff;
 	struct diff_queue_struct outq;
 	outq.queue = NULL;
-	outq.nr = outq.alloc = 0;
+	outq.nr = outq.alloc = outq.removed = 0;
 
 	if (!filter)
 		return;

@@ -3143,6 +3154,47 @@ static void diffcore_apply_filter(const char *filter)
 	*q = outq;
 }
 
+static void diffcore_remove_empty(void)
+{
+	int i;
+	struct diff_queue_struct *q = &diff_queued_diff;
+	struct diff_queue_struct outq;
+	outq.queue = NULL;
+	outq.nr = outq.alloc = outq.removed = 0;
+
+	for (i = 0; i < q->nr; i++) {
+		struct diff_filepair *p = q->queue[i];
+
+		/*
+		 * 1. Keep the ones that cannot be diff-files
+		 *    "false" match that are only queued due to
+		 *    cache dirtyness.
+		 *
+		 * 2. Modified, same size and mode, and the object
+		 *    name of one side is unknown.  If they do not
+		 *    have identical contents, keep them.
+		 *    They are different.
+		 */
+		if ((p->status != DIFF_STATUS_MODIFIED) || /* (1) */
+		    (p->one->sha1_valid && p->two->sha1_valid) ||
+		    (p->one->mode != p->two->mode) ||
+
+		    diff_populate_filespec(p->one, 1) || /* (2) */
+		    diff_populate_filespec(p->two, 1) ||
+		    (p->one->size != p->two->size) ||
+		    diff_populate_filespec(p->one, 0) ||
+		    diff_populate_filespec(p->two, 0) ||
+		    memcmp(p->one->data, p->two->data, p->one->size))
+			diff_q(&outq, p);
+		else {
+			diff_free_filepair(p);
+			outq.removed++;
+		}
+	}
+	free(q->queue);
+	*q = outq;
+}
+
 void diffcore_std(struct diff_options *options)
 {
 	if (options->quiet)

@@ -3160,6 +3212,7 @@ void diffcore_std(struct diff_options *options)
 		diffcore_order(options->orderfile);
 	diff_resolve_rename_copy();
 	diffcore_apply_filter(options->filter);
+	diffcore_remove_empty();
 
 	options->has_changes = !!diff_queued_diff.nr;
 }

diff --git a/diffcore.h b/diffcore.h
index eef17c4..e5a9244 100644
--- a/diffcore.h
+++ b/diffcore.h

@@ -81,6 +81,7 @@ struct diff_queue_struct {
 	struct diff_filepair **queue;
 	int alloc;
 	int nr;
+	int removed;
 };
 
 extern struct diff_queue_struct diff_queued_diff;

-- 
1.5.3.rc2.4.g726f9

Linus Torvalds wrote:

Doing a "git diff" cannot actually update the index (since it very much 
has to work on a read-only setup too), which is why the index _stays_ 
stale unless something is done (eg "git status") to refresh it. 

Another thought: How about if git-diff *tries* to update the index if 
needed, but failure to do so is not treated as an error condition? That 
seems like the best of both worlds to me: git would self-correct a 
potential performance problem without user intervention, while still 
working properly in a read-only environment.

-Steve

On Tue, 7 Aug 2007, Steven Grimm wrote:

Actually, though this will probably make people roll their eyes, before this
discussion I would have guessed that "git status" would be the command that
would tell you the index was out of date, and that there'd be a separate
command (say, "git update-index"?) that you could then use to sync things up
again.

Well, historically, you literally would just do

	git update-index --refresh

to do that.

"git status" is fairly newfangled, and is purely because users from other 
SCM's expected that kind of command to exist. The fact that as part of it 
running it does that update-index is really just a side effect.

		Linus