[chrishill89]

The git-restore(1) implementation looks like about 35 lines of code. Then add a little more complexity for some apparent common functions that needed to be factored out.

For a dedicated "restore" it's worth it to me... (who will not maintain it)

[throwaway27448]

At the hidden cost of educating millions of users how git actually operates once they can't restore a file

[chrishill89]

Neither of these two commands are any more really-operates than the other.

[throwaway27448]

How do you figure? Are you discarding the semantics of how people invoke git? If so why advocate for "restore" to begin with?

[chrishill89]

I don’t know what the semantics of invoking Git means?

These two commands operate on the same level of abstraction. And they should be equally powerful, which means that whichever you choose to learn will be able to serve all of your restore-content needs. That's what I mean.

Of course there is always the pedagogic cost of having two similar commands.

[throwaway27448]

Well surely people who use git and who also know english will think of restoring something. You want to restore what from when? Git offers no concept of time and in fact believing that it does will hamstring your efforts to use it. That's the cost. Why cater to this concept of before and after when this undermines usage?