Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> > > > > I just need to know if current working directory is clean and report >> > > > > back to qgit user, so read-only access would be ok for me. >> >> [... talking about a patch to introduce --refresh to git-status ...] >> >> Well, I tested the patch and indeed it helps a lot ;-) > > Not really. The thing is, git-status does a lot more than what you need. > And what you need is _only_ what "git diff --name-only HEAD" does already! > > It _also_ checks the index, it _also_ only checks the files with different > stat information, but it does _not_ try to update the index and prepare a > message to be displayed when committing. > > So, what is the big problem about accepting that patching git-status for > one obscure use is wrong, wrong, wrong, when git-diff already does what is > needed??? It really depends on what Marco means by "if cwd is clean". If by "clean" Marco means "no differences after discarding cache cleanliness information", "git-diff" is not quite it, as it shows the differences including the cleanliness of the cache entry. "git-status", as Marco found out in the message that started this thread, loses the cache cleanliness information when it runs [*1*]. If he cares about cache cleanliness information, "git-diff" is the right thing to use, and using "git status" is wrong -- it not only does more than he needs (as you pointed out), it loses information, which may be worse, depending on why he wants to know. [Footnote] *1* To achieve that, it has to write into the repository. Is it wrong for "git-status" to be losing the cache cleanliness information? The intended audience of that program is those who are about to make a commit in the repository, as they are asking "what would I be committing?" Up to that point, they may have cared about the reminder they get from "git diff" that they edited a file and then ended up reverting the whole edit they did to that file (I find that empty diff from "git diff" often very useful, although I felt "Huh?" when I was new to git). But when they ask "git status", they care more about the real change, and at that point (since they feel they may be ready to make a commit -- and that is the whole point of running "git-status") they do want to lose the cache cleanliness information. So "git-status" to be read-write application to discard the cache-cleanliness information is probably a good thing. - 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