Matthieu Moy <Matthieu.Moy@xxxxxxx> writes: Matthieu Moy <Matthieu.Moy@xxxxxxx> writes: >> "git-status $args" on the other hand is a preview of "what would >> happen if I say 'git-commit $args'", and in order to compute >> that, you would fundamentally need to be able to write into the >> object store. In a special case of giving empty $args it can be >> read-only. > > Can you give an example where it _could_ not be read-only? Think of what "git commit -a" would have to do. It needs to hash and deposit a new object for blobs that have been modified. Where do those new blob object go? > In the same way, I expect git-status to be read-only for the user. You > say "what _would_ happen _if_ I say commit $args". But you don't > commit, the sentence is conditionnal. I don't expect any tool to have > visible side-effects when I say "what would happen if ...". By running git-status the user is asking to get the overall picture, discarding the "touched but not modified" information. Once you _HAVE TO_ refresh the index for whatever reason, it is better to keep the result of the effort and cycles spent for that refresh operation for obvious performance reasons in practice, and that is what we have now in git-status. IOW, we are practical bunch. Maybe in a theoretical ideal world, you might prefer to reverting back to the stat-dirty original index to make git-status appear a read-only operation, with continued degraded performance. You are welcome to reimplement it that way, and the patch should be trivial (while git-commit.sh is still a script, at least) but that is not what we did. - 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
