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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html