Re: 'git status' is not read-only fs friendly

Linus Torvalds <torvalds@linux-foundation.org> writes:

I think a one paragraph summary of your argument is:

 - index is a good thing -- it is what makes the difference
   between usable and unusable.

 - git-status needs to refresh the index in order to do its
   thing efficiently and usably _anyway_, so once it spends
   cycles to do so, it is senseless not to write the refreshed
   index out when it can.

I do not think anybody disputes that in a repository with 20k+ paths, it is sensible to leave the index stat-dirty for all paths. But I think your example

	read-tree HEAD

misses the point by stressing the importance of index too much. Index is important for the usability and I do not think anybody is disputing it.

The thing is, nobody switches the index that way without running "update-index --refresh" afterwards. Normal people would use git-reset to switch to a different tree object, and the command does that for you. If you are a hardcore, you would know to use "read-tree -m HEAD" at least to avoid making paths unnecessarily stat-dirty. Your example, while it is valid and demonstrates why the index is a good thing very well, is simply not part of a normal workflow and not very relevant when discussing the performance ramifications of what state "git-status" should leave the index in.

When I said "calling 'update-index --refresh' in git-status loses stat-dirtiness information", I was certainly _NOT_ talking about losing the information that 20k+ paths used to be stat-dirty because the user did "read-tree HEAD" earlier.

At least for me, it is very normal to do something like this.

 * start from a clean index.

 * edit cache.h, diff.h, and diff-lib.c.

 * stop, think, and realize that my earlier edit to change one
   function prototype in diff.h was not needed, and revert the
   change to that line still in the editor.

 * fix things up further by editing other files.

And then, I would run "git diff" to see where I am. I still remember that I touched diff.h and I also remember that I once changed a function prototype but then decided the change was not necessary after all, but I do not remember if I changed anything else in the file. It is _very_ assuring to see the emptiness that follows "git diff --git" header for diff.h in such a case. Seeing the path to be stat-dirty is a very good thing for me, because otherwise I might lose a few seconds thinking that what I thought I touched might have been cache.h and not diff.h.

To me, running "git status" is "wrapping things up" step. I do not need that stat-dirty assurance "git diff" gave me at that point. Not seeing diff.h in "modified but updated" list is a good thing. And in my workflow, after that 'wrapping things up" step, I do not need that stat-dirty assurance _anymore_.

I think Nico is correct to point out that "not _anymore_" part of the above reasoning of mine assumes _my_ workflow and preference, and I think that is a valid point. Not saving the refreshed index would make the stat-dirtiness for diff.h to come back, which would be inconvenient and annoying to me.

But the user might want to keep it stat-dirty after running "git-status". People in "not _anymore_" camp like me can throw the stat-dirtiness away by "update-index --refresh". I do not think he (or anybody) is advocating to keep 20k+ paths in stat-dirty state (arguably, "artificially" due to use of "read-tree HEAD"), so your example using "read-tree HEAD" only confuses the discussion.

Having said all that, I do agree with you that git-status should throw that stat-dirtiness information away by saving the refreshed index. Doing otherwise is annoying to me as I already said, and I do not think of a valid reason for the user to want to keep stat-dirtiness information after running "git-status", because to me the whole point of running "git-status" is to start wrapping things up.