How to force git-status to check differences using hashes?

Question

git-status is known to find out that the object has changed via checking its size and modification time. Sometimes it is not working, e.g. for repos on restrictive filesystems, etc. How to force git-status to check the actual differences via counting SHA-1 sums? This will be way longer but is still a solution for mentioned use cases.

Answer 1

TL;DR

With Git, there is often more than one way to accomplish a given task. In this case, you don't need to compare object hashes; you can use git-diff to compare files or directories for the information that you need.

Check Status of Working Tree with Git Diff

Depending on what it is that you're actually trying to show in your output, you might consider using git-diff with the --name-status flag instead of relying on the internal implementation of git-status. For example:

$ git diff --name-status HEAD^
M       foo.sh
D       bar.rb

This would show that foo.sh has been modified, and bar.rb has been deleted. This is generally what you really want to know about your current working directory, anyway: what files are dirty, and what is going to be added or removed when you commit.

Check for Unstaged Changes with GNU Diff and Git Diff

The above approach is great for determining whether your working tree is dirty. However, it won't tell you whether specific changes are already staged or not the way git-status would. To do that, you actually have to diff the working tree against the cached index. For example, let's assume that you already staged the deletion of bar.rb with git rm bar.rb, but made changes to foo.sh with an editor but have not yet staged the modified file. In that case, you need something like:

$ diff -u <(git diff --name-status --staged HEAD^) <(git diff --name-status HEAD^)
--- /dev/fd/63  2015-02-19 01:56:22.000000000 -0500
+++ /dev/fd/62  2015-02-19 01:56:22.000000000 -0500
@@ -1 +1,2 @@
 D  bar.rb
+M  foo.sh

to see that the the deletion is staged, but the modifications have not yet been added to the staging area. Obviously, the output is not as attractive or as intuitive as the output from git-status, but if git-status doesn't meet your needs for some reason, then this alternate approach should enable you to compare the actual contents of the working directory against the index without relying on timestamps or file sizes.