Subject: Some information that git diff saves and that git status does not

From: Sergio <[email-masked]>
Date: Mon, 8 Mar 2010 10:46:51 +0000 (UTC)

Hi,

I happen to work with a (possibly somehow unusual) configuration where 2 laptops
are syncronized via unison (a widely used file syncronizer).

This means that git worktrees and repos are copied around as they are, rather
than transferred through git protocols.  The thing may appear weird, but it
makes sense, since the two laptops need to carry completely identical stuff all
the time (one, say "A", is a lightweight one good for travel, the other one, say
"B" is a desktop replacement).

If I work on "A" in worktree "WT", when I then sync the two machines, WT and the
associated object store and git data remains unchanged in A and gets updated in
B in such a way that git cannot know about it.

As a matter of fact, git copes with all this amazingly well, with the following
quirk:

1) The tree appears dirty on B, even if it was not on A before starting the
sync. I guess this is because the index may contain data that does not make
complete sense on B. As a consequence, gitk shows the tree as containing local
changes even if it does not.

2) By running git status, you make git realize that in fact there are no local
changes in the tree.  After a git status, also gitk is happy.

3) When you run git status, to find out that the local tree is in fact clean,
git status needs to do a significant amount of work.  If filters are defined,
git status runs all the filters on all the files that need to be filtered
(revealed by GIT_TRACE). This can take a significant amount of time.

4) Once git has done that, you would expect git status not to need doing the
filter job any longer.  However, if you run git status again and again, git
again and again spends a significant amount of time re-running all the filters.

5) If rather than running git status, you run git diff, git runs the filters as
for git status, however some info now gets saved about this activity.  After a
git diff, git status becomes almost istantaneous, no filters are run any longer.

It would be nice if:

a) git status could save the same info that git diff saves, so after the first
git status which needs to take a long time, all the subsequent git status are
fast. If I remember properly, this was indeed the behavior before the rewrite of
git status; and

b) before saying that you have local changes, gitk could run git status to be
truly sure about that.

Would a) and b) be easy and sensible changes? Or conversely, would they have
nasty implications and side effects?

Sergio