Neal Kreitzinger <nkreitzinger@xxxxxxxxx> 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. -- 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