Re: suggestion: git status = restored

Neal Kreitzinger [off-list ref] writes:

I see your point about the current worktree/index/HEAD.  I'm not a git
developer, but my idea is based on the concept that the sha-1 of the
content already exists in the object store regardless of its
path(s). I'm talking about identical blob sha-1's, not "similar"
content.

One thing you seem to be missing is that you would need to prove that a
commit that had that blob existed in the ancestor of the commit you are
standing on in order to call that restore.  You cannot restore something
that you didn't lose, and if you never had it in your history, there is no
way you lost it in the first place.  And that means you have to run around
in the history potentially digging down to the root.

Also a file that happens to have the same content is not necessarily
"restore".  If you are using a boilerplate to start a new file in a
verbose language, you may "git add" the initial state of such a file
before you start adding your own lines (perhaps adding a real method
implementation to a class), and then run another "git add" to record your
changes.  It wouldn't be surprising if such an initial snapshot for
different paths were identical.

A more trivial example would be a .gitignore file that has '*.o'; that can
appear in src/ and then in lib/ but the project may not want to have it at
the toplevel of the source tree.